That gives the profiler a chance to attach to a newly created content
process. There's no API for waiting for the profiler to be ready in a
just-created process, unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D43898
--HG--
extra : moz-landing-system : lando
Straight-forward addition of the --no-install option for reftest, just like
the existing option for mochitest. For gtest, I alos noticed the mach command
help needed some cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D43299
--HG--
extra : moz-landing-system : lando
scrollbars-in-landscape-content.html doesn't fail on environments where we don't
use overlay scrollbars because scrollbars for the visual viewport are not
rendered there.
Differential Revision: https://phabricator.services.mozilla.com/D40770
--HG--
extra : moz-landing-system : lando
Converts mozilla.widget.disable-native-theme varcache pref to a static pref and updates uses of its associated global variable with the pref. This also renames the pref to widget.disable-native-theme to group with other widget prefs.
Differential Revision: https://phabricator.services.mozilla.com/D40721
--HG--
extra : moz-landing-system : lando
Various cleanup:
- remove extraneous calls to grant_runtime_permissions
- remove unused legacy jimdb support code
- remove "This may take a while" logging
- emphasize x86/x86_64 capabilities of emulator
Differential Revision: https://phabricator.services.mozilla.com/D40302
--HG--
extra : moz-landing-system : lando
Many of these features are non-functional these days, but I'll keep them
hooked up in case we decide to fix them.
Differential Revision: https://phabricator.services.mozilla.com/D38413
--HG--
extra : moz-landing-system : lando
As far as I can tell, the intermittent suite_start failures are due to
stdout/stderr output interleaving -- a known issue for reftest logging,
without a clear way forward. Let's work around it the same way we did
on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D37023
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
As far as I can tell, the intermittent suite_start failures are due to
stdout/stderr output interleaving -- a known issue for reftest logging,
without a clear way forward. Let's work around it the same way we did
on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D37023
--HG--
extra : moz-landing-system : lando
Due to the sheer number of tests that exhibit a random fuzz with maxDifference=1
and maxDifference=2 with WR on Android, it's easier to just tweak the harness
to autofuzz these away. This adds machinery to do so, and also adds a new
annotation that can be used to disable the autofuzzing on specific tests.
Depends on D36794
Differential Revision: https://phabricator.services.mozilla.com/D36796
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
Use the geckoview TestRunnerActivity, org.mozilla.geckoview.test, by default
for all types of mochitests, reftests, and web-platform tests. TRA is already
the default for gtest and geckoview-junit. Fennec, based on ANDROID_PACKAGE_NAME,
remains the default for robocop and marionette-test and I have no plans to
change those. There is a related issue for xpcshell-test -- not the package
name, but the default apk -- but I am reluctant to handle that until bug 1553225
is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D35479
--HG--
extra : moz-landing-system : lando
When TV runs the reftest harness against an individual reftest, and the specified reftest
is in a sub-directory of its manifest location, the harness currently fails to run the
requested test, on Windows only. For example, the pathname in findManifest might be
"css-multicol\multicol-nested-002.xht", on Windows. Using posixpath changes pathname to
"css-multicol/multicol-nested-002.xht", regardless of platform, and that seems to work
everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D32361
--HG--
extra : moz-landing-system : lando
Logcat is available as a separate artifact anyway. This makes the test log
for successful runs much smaller: easier to read, cheaper to store.
Differential Revision: https://phabricator.services.mozilla.com/D31357
--HG--
extra : moz-landing-system : lando
