The previous patch stops us from firing the load event if we abort a load. We have a few crashtests that abort loads (either by directly calling stop(), or by starting a new navigation before load completes).
This switches the reftest harness to use web progress to determine when we've finished loading a test.
Differential Revision: https://phabricator.services.mozilla.com/D73995
Make it show the contents of style sheets (as it used to before Stylo)
and make it work in --disable-debug --enable-layout-debugger builds.
Differential Revision: https://phabricator.services.mozilla.com/D76640
The previous patch stops us from firing the load event if we abort a load. We have a few crashtests that abort loads (either by directly calling stop(), or by starting a new navigation before load completes).
This switches the reftest harness to use web progress to determine when we've finished loading a test.
Differential Revision: https://phabricator.services.mozilla.com/D73995
The previous patch stops us from firing the load event if we abort a load. We have a few crashtests that abort loads (either by directly calling stop(), or by starting a new navigation before load completes).
This switches the reftest harness to use web progress to determine when we've finished loading a test.
Differential Revision: https://phabricator.services.mozilla.com/D73995
* update paths to test manifest and user.js after Bug 1596567.
* make sure to use root=True when checking for existence of reftest.log.
* work around permissions errors when pushing to /data/local/tests.
* Properly handle symbolic links to the JavaScript tests for desktop
and remote Android tests.
Differential Revision: https://phabricator.services.mozilla.com/D69313
The startup script starts by searching a window by its type; how the window type parameter is only available once the window's document element has been created.
The main window has already been created however and it is in an in-between state which means that you can't find it by its type nor will domwindowcreated be fired.
So we listen to either initial-document-element-inserted which indicates when it's okay to search for the main window by type again and we are ready to start the reftest.
Differential Revision: https://phabricator.services.mozilla.com/D72142
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
Various updates to the custom retrigger action so that, without any custom changes to
parameters, the retriggered task runs with the same parameters as the original task.
Several issues were found and corrected, notably:
- parameters like --allow-software-gl-layers were ignored
- MOZHARNESS_TEST_PATHS was ignored
- many parameter customizations in the desktop mozharness configs were ignored
- mochitest suite/subsuite/flavor selection was not always correct
- using repeat=1 by default meant that each test ran twice
Differential Revision: https://phabricator.services.mozilla.com/D70457
This sets the env vars when running with WR enabled in reftests or WPT,
which is where the errors seem to be manifesting.
Differential Revision: https://phabricator.services.mozilla.com/D71375
Use finer granularity for some reftest/mochitest SCHEDULES.exclusive entries,
so that reftest-plain does not run when only crashtests are modified, and
vice versa; similarly, break up mochitest into mochitest/browser-chrome/chrome/
a11y. Use schedules-component instead of category.
Differential Revision: https://phabricator.services.mozilla.com/D60085
--HG--
extra : moz-landing-system : lando
Remove the remainder of automation.py.in and the build support for generating
automation.py.
Some of this functionality was in use, especially for android tests.
Some code was moved or re-implemented in remoteautomation.py or in the affected
harness(es). Some features were removed: There are some minor changes in behavior.
For instance, instead of using a different server startup timeout for debug builds,
one value is used for all builds (due to performance improvements over time,
the longer timeout is no longer needed).
Differential Revision: https://phabricator.services.mozilla.com/D66839
--HG--
extra : moz-landing-system : lando
These have been broken for a while, because we don't run them on automation...
The way we import PDFJS in reftest.jsm was broken. And PDFJS updates caused
breakage.
Differential Revision: https://phabricator.services.mozilla.com/D66669
--HG--
extra : moz-landing-system : lando
Remove unused code from automation.py.in, move some android-specific code from
automation.py.in to remoteautomation.py, and eliminate some other easily-replaced
code. In the long term we want to eliminate automation.py.in completely; I may
attempt that once these changes have landed.
Differential Revision: https://phabricator.services.mozilla.com/D66306
--HG--
extra : moz-landing-system : lando
Currently the RefTest manifest parser has 5 possible statuses:
0 => EXPECTED_PASS
1 => EXPECTED_FAIL
2 => EXPECTED_RANDOM
3 => EXPECTED_DEATH (aka skip)
4 => EXPECTED_FUZZY
In the manifests, the last status annotation that appears on the line will take
precedence. For example:
skip-if(true) fails-if(true) == test1.html ref.html
fails-if(true) skip-if(true) == test2.html ref.html
The first test will have an expected status equal to EXPECTED_FAIL, whereas the
second one will be EXPECTED_DEATH. The same holds true for any combination of
'fail/random/skip/fuzzy' annotations. This means developers need to be very
careful about the order they specify these annotations as getting the order
wrong can easily lead to unexpected behaviour.
With the introduction of defaults in bug 1616368, the risk of unexpected behaviour
is far greater. Since defaults are simply prepended to the test line, a manifest
that looks like:
defaults skip-if(true)
== test1.html ref.html
fails-if(true) == test2.html ref.html
will actually skip the first test, but run the second (since the fails-if
overwrites EXPECTED_DEATH with EXPECTED_FAIL).
The root of the problem appears to be that 'skip' and 'fuzzy' are not actually
test statuses. They are modifiers that affect how we run the test, but don't
actually affect whether the test is expected to pass or fail.
Therefore, this patch solves the problem by making 'skip/skip-if' its own thing
that does not get overwritten by other failure types. In otherwords, a 'skip-if'
can appear before or after a 'fails-if' and it will have the same meaning.
Differential Revision: https://phabricator.services.mozilla.com/D64457
--HG--
extra : moz-landing-system : lando
Hiroyuki Ikezoe
Bob Clary
Matt Woodrow
Geoff Brown
Joel Maher
Cameron McCormack
Butkovits Atila
Bob Owen
Mihai Alexandru Michis
Kartikaya Gupta
Timothy Nikkel
Oana Pop Rus
Jean-Yves Avenard
Emilio Cobos Álvarez
Botond Ballo
Tooru Fujisawa
aarushivij
Andrea Marchesini
Razvan Maries
Coroiu Cristina
Ting-Yu Lin
Simon Giesecke
Nicholas Nethercote
Brendan Dahl
Mike Shal
Daniel Varga
Andrew Halberstadt