When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the track sizes using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153623
Now that we transfer all type definitions to Metadata, we can
remove the special debugging case where we would transfer all
function types. Instead, we can just transfer the funcTypeIndex
and find the function type in Metadata.
Differential Revision: https://phabricator.services.mozilla.com/D153500
ValType needed to be pointer size to support (rtt) types. Now that
they have been removed, we can revert to 32-bit on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D153499
Metadata stores a vector of TypeDef that comes from the type section of the module.
We currently only transfer a type if it's a struct type, array type, or else a
function type that cannot fit in an immediate for call_indirect signature checks.
Because we filter out some types, this means we need to renumber the type index
space to match. This is a bit hacky, and is difficult to do consistently.
The original reason for only bringing function types that cannot fit in an
immediate was to reduce the size of metadata as most function types can fit in an
immediate. However, I discovered that we make a copies of function types for
FuncExport and FuncImport metadata. This can create multiple copies of the original
function type, e.g. when multiple exported functions reference the same type
definition.
If we instead transfer all types and store the index of the function type in
FuncExport/FuncImport we can reduce total metadata size, reduce allocations,
and remove type renumbering.
This commit does this by:
1. Transferring all type definitions to Metadata (WasmGenerator.cpp)
2. Removing the typeRenumbering vector
3. Replacing FuncType with typeIndex on FuncImport/FuncExport
4. Updating all users of FuncImport/FuncExport to get the FuncType using
the typeIndex and Metadata. This the bulk of the changes.
Differential Revision: https://phabricator.services.mozilla.com/D153498
While working on Bug 1777497 I bumped into a few things I would have done
differently that make it harder to misuse the site-scoped permissions.
These are just bugs waiting to happen, so I'm cleaning them up while I'm in here.
Differential Revision: https://phabricator.services.mozilla.com/D152760
It was a part of the initial skeleton code where the getters threw NOT_IMPLEMENTED. The methods are wrong anyway since `.forget()` will unset the fields.
Differential Revision: https://phabricator.services.mozilla.com/D153972
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
They just redirect to LogicalPixelSize's B/ISize(), which return floats.
So it seems pointless to return a double, and static analysis would
complain when storing the double as float for the last remembered size.
Depends on D154325
Differential Revision: https://phabricator.services.mozilla.com/D154473
