This requires some changes to LambdaFunctionInfo:
* Don't use LambdaFunctionInfo for MFunctionWithProto as the JSFunction is just passed to a C++ call.
* Make the callers pass the values to the constructor so that WarpBuilder can construct LambdaFunctionInfo from the snapshot.
* Use better static types now that we have FunctionFlags and BaseScript.
* Move the assert in LambdaFunctionInfo's constructor to CodeGenerator::visitLambda.
It's not clear if LambdaFunctionInfo is still required now that the function's
BaseScript* pointer is a constant, but long-term we probably want to move to a
model like this for all template objects anyway.
Differential Revision: https://phabricator.services.mozilla.com/D67814
--HG--
extra : moz-landing-system : lando
This adds buildInitPropOp instead of reusing buildSetPropOp because there are
some subtle differences between Init and Set. Longer term we should consider
splitting the MIR and CacheIR code as well so it becomes easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D67804
--HG--
extra : moz-landing-system : lando
This patch adds a few JSDoc comments, renames some variables,
and changes the structure of the stored thread (`actor` becomes
`actorID`), in order to make it more clear what we're dealing
with and avoid confusion.
Differential Revision: https://phabricator.services.mozilla.com/D67627
--HG--
extra : moz-landing-system : lando
ClientChannelHelperParent is the thing creating the ClientInfos which aren't
backed by existing ClientSources, so it may make sense for CCHP to tell the
ClientManagerService (CMS) to "expect" or "forget" a "future"
ClientSource(Parent).
When such a ClientInfo is created, CCHP notifies the CMS that a future
ClientSource may be created. This notification has to be observed before any
ClientHandles try to query CMS to a ClientSourceParent, which is the case
because the notification as well as ClientHandleParent constructors occur over
PBackground, and the notification sending method is called first.
CMS is told to forget the future ClientSource whenever a redirect occurs that
would result in the creation of a new ClientSource (i.e. a new ClientInfo). It's
also possible that the ClientInfo's LoadInfo's channel is cancelled. To account
for this, CHCP stores the most recent ClientInfo it's created and tells CMS
to _possibly_ forget the associated future ClientSource in its destructor. It's
possible that the channel completed its load, in which case this notification
is a no-op. This also relies on CHCP being destroyed after the reserved
ClientSource has a chance to both be created and register its
ClientSourceParent.
Differential Revision: https://phabricator.services.mozilla.com/D66529
--HG--
extra : moz-landing-system : lando
The changes only make it possible for ClientManagerService to store
FutureClientSourceParents, but it will not actually store them until
following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66145
--HG--
extra : moz-landing-system : lando
Also implements SourceTableEntry and nsIDHasher to switch ClientManagerService's
nsDataHashTable to a mozilla::HashMap<nsID, SourceTableEntry> in following
changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66144
--HG--
extra : moz-landing-system : lando
A `ProfileBufferChunk` represents a single chunk of memory, with an optional
link to the next chunk.
In the new Fission-compatible profiler storage, chunks will be allocated by a
chunk manager, filled with data by the profiler, and then released back to the
chunk manager.
The chunk manager may decide to destroy or recycle old chunks based on memory
limits (per process, or for the entire Firefox app).
Differential Revision: https://phabricator.services.mozilla.com/D67272
--HG--
extra : moz-landing-system : lando
Let's use GtkInputPurpose and GtkInputHints by inputmode for software keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D67771
--HG--
extra : moz-landing-system : lando
Since we cannot use HTMLInputElement.GetInputMode since we still support
mozAwesomebar, inputmode attribute isn't sanitized. Since I would like to reduce
comparing cost, it should be lower case except to mozAwesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D67770
--HG--
extra : moz-landing-system : lando
When we calculate the repeating tile size, errors can be introduced,
such that there are cases it should be the same as the bounds, but is
slightly different. This can cause a new repetition where we did not
expect one. This patch makes the comparison when may force the tile size
to be the same as the snapped bounds more fuzzy.
Differential Revision: https://phabricator.services.mozilla.com/D67620
--HG--
extra : moz-landing-system : lando
The top-level document containing the iframe in which the test runs can be
scrolled by things that happen in previous tests (e.g. a zoomToFocusedInput
in a previous test), causing the target element to be outside of the visual
viewport.
After bug 1556556, event synthesization functions will no longer support
targeting elements outside the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D67523
--HG--
extra : moz-landing-system : lando
The tests don't have a reliable mechanism to wait for a potential zoom
animation to end, leading to flakiness due to a zoom animation form a previous
sub-case interfering with the current sub-case.
Differential Revision: https://phabricator.services.mozilla.com/D67522
--HG--
extra : moz-landing-system : lando
The coordinate values are chosen to target the first pixel of a target frame.
However, due to rounding error during the event synthesization code path,
they can miss the frame by a fraction of a pixel.
Differential Revision: https://phabricator.services.mozilla.com/D67520
--HG--
extra : moz-landing-system : lando
This ensures that CSS coordinates (which is what the synthesizeTap test case
passes to GeckoSessionTestRule.synthesizeTap()) are equal to Screen coordinates
(which is what that function expects).
An alternative approach would be to query the resolution and convert from CSS
to Screen coordinates, either in the test case or inside synthesizeTap().
Differential Revision: https://phabricator.services.mozilla.com/D67519
--HG--
extra : moz-landing-system : lando
Presumably, the intention of the test is to hit the middle of the target. To
this end, the test specifies an offset of half the target's dimensions
relative to the origin of the target.
However, when pointerMove() is given an element as origin, it already uses
the element's center as the origin point, so we end up actually targeting
the bottom right pixel which is prone to rounding issues.
Differential Revision: https://phabricator.services.mozilla.com/D67518
--HG--
extra : moz-landing-system : lando
