stderr does not go anywhere by default on Android. Debugging output is
conventionally sent to the Android log via special functions like
__android_log_print.
We already have logic for handling this in nsCRTGlue's printf_stderr, but
I don't think we can use that in MFBT.
Differential Revision: https://phabricator.services.mozilla.com/D26985
--HG--
extra : moz-landing-system : lando
Stop running Tss(tp6) and T(bcv) on ccov builds on central -- the remaining 2 cases
missed in the previous bug.
Differential Revision: https://phabricator.services.mozilla.com/D27313
--HG--
extra : moz-landing-system : lando
Add Android 7.0 gtests, opt and debug, running against the geckoview
TestRunnerActivity.
Differential Revision: https://phabricator.services.mozilla.com/D27016
--HG--
extra : moz-landing-system : lando
Adds remotegtests.py, like rungtests.py, but for Android. Unlike some other test harnesses, remotegtests is not a sub-class of rungtests: There wasn't much code that could be re-used.
The code to wait for the test app and collect and display the log is derived from and similar to existing code in remoteautomation.py: I didn't want to increase reliance on remoteautomation; I don't mind a bit of code duplication.
There is a TODO item related to libxul.so. gtest runs in the browser, but with tests compiled into a gtest-specific version of libxul.so. remotegtests.py patches the installed app by pushing the libxul.so to the installation directory of the app -- root required and fragile, but works fine on the emulator. I think the "right" way to do this is to create a gtest-specific apk; I plan to file a follow-up bug and petition build folks to help sort that out.
I have been running this locally with:
mach gtest (builds gtests, then errors out)
mach python testing/gtest/remotegtests.py --libxul=/home/gbrown/objdirs/x86_64/dist/bin/gtest/libxul.so
Work-in-progress on 'mach gtest' will make this much simpler.
Differential Revision: https://phabricator.services.mozilla.com/D26835
--HG--
extra : moz-landing-system : lando
Applying the attribute early enough allows us to avoid rebinding the urlbar,
plus a few checks to ensure "popup" windows, without a visible toolbar, work
properly.
Differential Revision: https://phabricator.services.mozilla.com/D27253
--HG--
extra : moz-landing-system : lando
There are slight differences produced between the earlier 422 output surface and the 420; interestingly the image is sharper with 420.
Differential Revision: https://phabricator.services.mozilla.com/D27020
--HG--
extra : moz-landing-system : lando
No color space was defined for these videos, making any correct rendering impossible.
We modify the h264 stream metadata, by marking it as being bt601.
This is done with the ffmpeg command:
ffmpeg -i dom/media/test/short.mp4 -codec copy -bsf:v h264_metadata=colour_primaries=6:transfer_characteristics=6:matrix _coefficients=6 -map 0
Differential Revision: https://phabricator.services.mozilla.com/D26871
--HG--
extra : moz-landing-system : lando
It allows for more readable code, not having to store multiple times different storage type across multiple objects.
Now each class does one task and only deal with a single texture data type.
Differential Revision: https://phabricator.services.mozilla.com/D26473
--HG--
extra : moz-landing-system : lando
Those classes use raw pointers or references to construction objets. They can only be used while the objects they reference still exist.
While RAII doesn't fully cover this use case, it's close enough. Mark them as such to prevent shooting ourselves in the future.
Differential Revision: https://phabricator.services.mozilla.com/D26471
--HG--
extra : moz-landing-system : lando
It allows for use of default constructor/destructor and leaves no room to incorrectly modify the union members with a wrong type.
Differential Revision: https://phabricator.services.mozilla.com/D26061
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
It would have been nicer and more logical to use a MacIOSurfaceImage to store the colorspace information, however the data passed around is a IOSurface Id via a SurfaceDescriptorMacIOSurface; the original data structure isn't kept; so we must transit the data at the same time as the IOSurface Id.
Also remove unnecessary test (new operator is infallible).
Differential Revision: https://phabricator.services.mozilla.com/D26058
--HG--
extra : moz-landing-system : lando