This is something that was implemented a long time ago, but it isn't covered in any spec, other browsers don't implement it and I don't know of any usage in the wild.
This doesn't work with OOP iframes, since what we're doing here requires the documents to be in the same process.
Given it isn't used or specified, the simplest solution is to just remove the behaviour altogether.
Differential Revision: https://phabricator.services.mozilla.com/D74628
We add `targetType` and `isTopLevel` properties on the target front, which
are set from the targetList and are used in the EvaluationContextSelector.
As a result we are able to directly call targetFront.targetType in a few
places instead of calling `getTargetType` again.
Differential Revision: https://phabricator.services.mozilla.com/D73890
This patch use the new `exception` and `hasException` field from nsIScriptError
so we can render the actual object in the message error instead of a stringified
version.
Error object are still displayed using the `customFormat` prop, so we display
only the type + message + stacktrace (but we'll have a way to inspect them
in the sidebar soon).
Existing tests were updated to fix failures, and some tests/test cases were
added to make sure we cover all the different kind of errors we can display
in the console.
Differential Revision: https://phabricator.services.mozilla.com/D71288
Allows defriending `AutoScroller` from `Selection` and removes the
direct dependency of `AutoScroller` to `Selection`.
Differential Revision: https://phabricator.services.mozilla.com/D74382
Make the WebAssembly ion compiler address incoming stack arguments from the frame pointer instead of from the stack pointer.
We have a plan to allow interstitial trampoline frames to be inserted between callers and callees, but only for cross-instance calls. This will mean offset to incoming stack arguments from SP is no longer a constant. The design has us instead address stack arguments from the frame pointer, as adding an interstitial trampoline frame won't modify the frame pointer.
Differential Revision: https://phabricator.services.mozilla.com/D73030
We still panic in a debug build, so that developers can notice when they
need to add a new static atom after modifying UA sheets.
We also add telemetry to note when this happens, add an app note to a
crash report, in case any crash later on occurs, and re-up the existing,
expired shared memory sheet telemetry probes so we can look at them
again.
Differential Revision: https://phabricator.services.mozilla.com/D73188
Previously, the spatial node index for a clip was stored as part
of the interning key.
However, if a new display list is sent where the clip has the same
transform, but the shape of the spatial-tree had changed (e.g.
due to a new transform being inserted due to a DOM change), this
could result in those clip(s) being detected as different. This
can cause unnecessary invalidations of picture cache tiles.
With this patch, the spatial node index is stored inside the
instance structures (ClipInstance and ClipChainNode), meaning that
picture cache tiles are no longer invalidated if the spatial
tree shape changes.
Differential Revision: https://phabricator.services.mozilla.com/D74363
The public clip API allows clips to be defined with either
a parent hierarchy, or via a clip-chain display item where
a list of clips are provided.
The WR internals represent both of these as an internal
clip-chain, where clips are parented and stored in a
linked list (although the elements themselves are in
a contiguous array).
Previously, WR would convert the public clip nodes into
clip-chains as soon as the clips were defined. However,
this complicates many other parts of the code. For example,
we want to be able to re-parent clips to the root clip
node of an iframe, and we need to extract shared clips
that can be handled by parent surfaces.
With this change, clips defined in the public API are
mapped into a ClipTemplate. The internal clip-chains
that WR uses are not created until the primitive is
defined. With this change, we can easily insert or
modify how the primitive's clip-chain is created. In
this patch, the `ClipChainBuilder` is used to add
the iframe clip root to any primitives inside the
iframe. In future patches, it will also be used to
handle clips from redundant stacking contexts, which
will allow the removal of all the Push/PopClipChain
display items.
Differential Revision: https://phabricator.services.mozilla.com/D74347