If aFromParser == dom::NOT_FROM_PARSER, it trivially also implies
aFromParser != dom::FROM_PARSER_FRAGMENT.
Differential Revision: https://phabricator.services.mozilla.com/D69652
--HG--
extra : moz-landing-system : lando
This matches closer the behavior of the HTML parser, which doesn't run custom
element constructors, among other things.
Differential Revision: https://phabricator.services.mozilla.com/D69653
--HG--
extra : moz-landing-system : lando
This will prevent the glitch we were seeing because the SmartTrace
component delays its initial rendering by a hundred ms.
Differential Revision: https://phabricator.services.mozilla.com/D69577
--HG--
extra : moz-landing-system : lando
The comment got accidentally truncated in bug 1613490 when it should've just
been removed.
Differential Revision: https://phabricator.services.mozilla.com/D69692
--HG--
extra : moz-landing-system : lando
When our detour processes instructions, we pass `ReadOnlyTargetFunction` to
`CountPrefixBytes` to determine whether a lock prefix exists or not.
In that case, we don't need to pass both `ReadOnlyTargetFunction` and an offset
as a parameter because `ReadOnlyTargetFunction` has an offset as a member.
Differential Revision: https://phabricator.services.mozilla.com/D69360
--HG--
extra : moz-landing-system : lando
Note that it only runs jit-tests (not jsapi-tests and the slower jstests) and
only two jit-test configurations. This makes the job very fast, I see it finish
in just 12-13 minutes on Try.
When this lands it should be green. For now it's tier 2 and only runs on central.
When WarpBuilder gets closer to shipping we can consider changing that (and probably
run more tests).
Differential Revision: https://phabricator.services.mozilla.com/D69512
--HG--
extra : moz-landing-system : lando
This fixes the last test failure. The debugger can collect "allocation metadata"
for allocated objects. This test is checking that the objects in the array have
different allocation sites associated with them.
Ion can fail this test because MNewArray is marked as non-effectful so it doesn't
get its own resume point, resulting in the allocation site matching that of the
object literal before it.
We could fix this by making MNewArray* and similar instructions effectful, but
I'm concerned about the perf impact of changing that just for the unlikely event
the memory profiler is being used. Since this is a pre-existing issue, this tweaks
the test to work around it.
Differential Revision: https://phabricator.services.mozilla.com/D69506
--HG--
extra : moz-landing-system : lando
There is no need to store the current testTabID, given
that we can always query for it. Also it would prevent
unforseen behavior in case of undefined or the custom
code for the default value 0.
Because Raptor always works with the current tab, lets
query for the current tab id whenever some tab action
is triggered.
Differential Revision: https://phabricator.services.mozilla.com/D69569
--HG--
extra : moz-landing-system : lando
Separates the checks for completion and the final clean-up steps
to simplify the code.
Also the same interval for checking for results is used across
all the test types now.
Differential Revision: https://phabricator.services.mozilla.com/D69568
--HG--
extra : moz-landing-system : lando
Various setTimeout usages to delay code execution causes multi-level
code stacking. By using the newly introduced sleep function, the code
can be streamlined and simplified a lot.
Using setTimeout also prevented us for correclty handling possible
Javascript errors, so that those weren't correctly propagated up the
stack. As such no webext_error gets send to the control server, which
should force an application shutdown. Instead Raptor would hang forever
until the application timeout happens.
Differential Revision: https://phabricator.services.mozilla.com/D69567
--HG--
extra : moz-landing-system : lando
This has been removed by bug 1620827 without any effect. As
such it has to be re-added to be consistent with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D69566
--HG--
extra : moz-landing-system : lando
For GeckoView vehicles no additional tab is created during the
initialization. As such one and only open tab cannot be closed.
Differential Revision: https://phabricator.services.mozilla.com/D69564
--HG--
extra : moz-landing-system : lando
To start the scenario timer as close as possible to the page
timeout alarm, it needs to be called before "collectResults".
Differential Revision: https://phabricator.services.mozilla.com/D69563
--HG--
extra : moz-landing-system : lando
When awaiting the promise to be resolved, the returned Tab object
will contain the neccessary reference to the id. As such no separate
listeners have to be defined. Side-effect with listeners is that those
are async and could cause race conditions in the sync program flow.
Differential Revision: https://phabricator.services.mozilla.com/D69562
--HG--
extra : moz-landing-system : lando
Not awaiting the promises to be resolved will cause race conditions,
which clearly lead to test failures.
Differential Revision: https://phabricator.services.mozilla.com/D69561
--HG--
extra : moz-landing-system : lando
It seems that first rendering to SwapChain was not handled by IDCompositionVisual2. Then, as shot term fix, force to do WR rendering twice during disabling WR native compositor. It could mitigate black flashing problem.
Differential Revision: https://phabricator.services.mozilla.com/D69677
--HG--
extra : moz-landing-system : lando
Note that the sticky-top test still fails on non-WebRender, but that's outside
the scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D69560
--HG--
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-fixed-top-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-bottom-1.html
rename : layout/reftests/async-scrolling/dynamic-toolbar-fixed-bottom-1.html => layout/reftests/async-scrolling/dynamic-toolbar-sticky-top-1.html
extra : moz-landing-system : lando
This makes the existing test for this codepath start passing on geckoview-qr.
Differential Revision: https://phabricator.services.mozilla.com/D69558
--HG--
extra : moz-landing-system : lando
Also use this to restrict when we send fixed-position data to APZ with WR
enabled, since we only need it when there's a dynamic toolbar involved.
Differential Revision: https://phabricator.services.mozilla.com/D69556
--HG--
extra : moz-landing-system : lando
This patch is pretty uninteresting, just building the pipe to move data
from the main-thread to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D69555
--HG--
extra : moz-landing-system : lando
The GetIsStickyPosition function isn't really needed since we can distinguish
whether or not a layer is sticky via NULL_SCROLL_ID as the container id. Also
ensure we have proper AtBottomLayer checks where needed for fixed and sticky
data.
Differential Revision: https://phabricator.services.mozilla.com/D69554
--HG--
extra : moz-landing-system : lando
Botond Ballo
Emilio Cobos Álvarez
Coroiu Cristina
Itiel
Cosmin Sabou
Sylvestre Ledru
Dave Townsend
Florian Quèze
Stepan Stava
Nicolas Chevobbe
Toshihito Kikuchi
aarushivij
Jan de Mooij
jayati
Ciure Andrei
Henrik Skupin
sotaro
Narcis Beleuzu
Kris Taeleman
Kartikaya Gupta