It looks like we left out some places in the inspector when we made it fission-compatible.
The color-picker, in particular, needs access to the selected node's computed style for its
color contrast logic.
We used to access this on the top-level target PageStyleFront. We just need to change this so
it uses the one contextual to the selected node.
Differential Revision: https://phabricator.services.mozilla.com/D55962
--HG--
extra : moz-landing-system : lando
We might as well do this for now to keep the tests passing when modern config is turned on. It doesn't actually matter what order these particular parameters are listed in.
Differential Revision: https://phabricator.services.mozilla.com/D55641
--HG--
extra : moz-landing-system : lando
This fixes quite a bit of historical baggage, and also goes
into a bit more details of what the l10n repacks actually do.
Differential Revision: https://phabricator.services.mozilla.com/D55807
--HG--
extra : moz-landing-system : lando
For now we still need the source note itself to determine the
stackPhiCount in IonBuilder. Hopefully we can fix that later.
Differential Revision: https://phabricator.services.mozilla.com/D55635
--HG--
extra : moz-landing-system : lando
Mechanical rename/merge for the most part.
When restarting a loop in IonBuilder, we skip the JSOP_LOOPHEAD so we
now re-add the interrupt check (this used to be done by JSOP_LOOPENTRY)
explicitly by calling emitLoopHeadInstructions.
Differential Revision: https://phabricator.services.mozilla.com/D55632
--HG--
extra : moz-landing-system : lando
This is necessary for the next patch: it will merge JSOP_LOOPHEAD
and JSOP_LOOPENTRY but that means there can be multiple callVMs for
that op and this confuses DebugModeOSR (interrupts can trigger debugger
recompilation).
Differential Revision: https://phabricator.services.mozilla.com/D55631
--HG--
extra : moz-landing-system : lando
In visitTestBackedge we can just get the backedge target from the
bytecode instruction.
Differential Revision: https://phabricator.services.mozilla.com/D55629
--HG--
extra : moz-landing-system : lando
All loops now use State::DoWhileLike so we can don't need to keep track of the
state anymore and can remove some more dead code.
Differential Revision: https://phabricator.services.mozilla.com/D55628
--HG--
extra : moz-landing-system : lando
All loops now have the same structure. A later patch in the stack
will remove this class.
Differential Revision: https://phabricator.services.mozilla.com/D55626
--HG--
extra : moz-landing-system : lando
This changes all loops to have the following bytecode structure:
```
JSOP_LOOPHEAD
JSOP_LOOPENTRY
...condition/body...
JSOP_GOTO/JSOP_IFEQ/JSOP_IFNE
```
This simplifies IonBuilder a lot because it can use the do-while code path
for all loops. For-in loops are also a bit simpler now because they no longer
need to have the next enumerated value on the stack across the backedge.
Later patches in the stack wil fold JSOP_LOOPENTRY into JSOP_LOOPHEAD,
simplify the source notes more and remove more code from IonBuilder.
I verified stepping/breakpoints for the different loop types works in the
debugger the same way as before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D55625
--HG--
extra : moz-landing-system : lando
The old code used the beforeLoopEntry bytecode pc, but this wasn't always
the correct pc and fixing that is a bit annoying (IonBuilder would have to
keep track of the last pc just for this).
Differential Revision: https://phabricator.services.mozilla.com/D55624
--HG--
extra : moz-landing-system : lando
The size of the visible region, for either a painted layer or a webrender blob
image, is calculated from the building rects of the contained display items, in
local-space. This should be restricted to the display port, to prevent the
visible regions growing too large leading to excessive memory usage.
For items within large scale transforms, the local-space visible region should
be very small. However, as we do not allow fractional sizes, the size of the
visible region will be rounded up to at least 1. This means that when we convert
the region back to screen-space, we are multiplying the extremely large scale by
at least one, rather than by a much smaller fraction. This can result in
incredibly large visible regions, and was causing OOM crashes.
To avoid this, we clamp the maximum chosen scale for these layers/blob images to
32k. Layers affected by this problem should have a visible region with
dimensions of 1 or 2, so this limits the resulting screen-space size for
those to an acceptable value. Layers with visible regions sized greater than
that should not have scales anywhere near this large, so will not be affected.
Differential Revision: https://phabricator.services.mozilla.com/D55691
--HG--
extra : moz-landing-system : lando
In bug 1531142 we made it so that when a spatial node is being pinch-zoomed we
use a local raster-space to avoid rerasterizing glyphs for every slight change
in zoom level. This makes it so that we also apply the same trick when
being asynchronously zoomed by a double-tap gesture.
Differential Revision: https://phabricator.services.mozilla.com/D55699
--HG--
extra : moz-landing-system : lando
This is part 2 of a series of revs that split up D41710 (for Wasm I64 to BigInt conversion) into smaller revs. This rev depends on the compile-time flag added in D43177 and adds a runtime flag to JSContext options that will toggle whether I64 to BigInt conversion is used. The flag will get used mostly in WasmInstance.cpp, but it also needs to be used to toggle I64 error checks in both Ion inlining code and in Wasm stub generation code. To pass that information along, the flag is also put in CompileArgs for WasmCompile and then copied to wasm module metadata (so that it can be read from lazy stub generation code).
Differential Revision: https://phabricator.services.mozilla.com/D43179
Icons added after the initial parsing are likely randomly generated to show badges,
thus they are not good for permanent storage, because they are transient and can
potentially flood the store.
Differential Revision: https://phabricator.services.mozilla.com/D55310
--HG--
extra : moz-landing-system : lando
Bug 1601233 made cranelift bump its syn dependency to 1.0, breaking the
workspace hack. Some of the features were also stale from presumably
other updates.
Differential Revision: https://phabricator.services.mozilla.com/D55897
--HG--
extra : moz-landing-system : lando