In md files and code comments and mostly from common js files.
I'm moving away from require to load sys.mjs files so that we are closer
to what we do in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D154073
Change `ShouldInitFixedSlots` so we can use it for `LNewPlainObject` by directly
passing the shape and the number of fixed slots.
All fixed slots for `LNewPlainObject` are initialised to `Undefined`, so we can
remove the first loop which iterates over all fixed slots. Between `MNewPlainObject`
and the `MStoreFixedSlot` instructions, we may have some (hoisted) constants and
a `MGuardShape` instruction, which we need to skip. The `MStoreFixedSlot` aren't
scattered over multiple blocks, so we can remove the `MGoto` handling. Also remove
the `MNop` handling, because we no longer emit `MNop` except for
`assertRecoveredOnBailoutResult()`. (We should probably rename `MNop` at this
point.)
Differential Revision: https://phabricator.services.mozilla.com/D156055
There are three callers to `ShouldInitFixedSlots()`:
1. `LNewObject`:
The non-VM call instruction is only used for `Object.create` calls, in which
case any following store instruction definitely won't be `MFixedStore`, but
instead `MAddAndStoreSlot`. That means any optimisations from `ShouldInitFixedSlots`
don't apply for this case.
2. `LNewNamedLambdaObject`:
The template object contains a fixed slot which holds an Object value (the
callee function), so `ShouldInitFixedSlots` won't perform any optimisations.
(`ShouldInitFixedSlots` requires that all fixed slots have `Undefined` as their
initial value.)
3. `LNewCallObject`:
The template object contains a fixed slot which holds either an Object or a Null
value (the enclosing environment object), so `ShouldInitFixedSlots` won't perform
any optimisations.
That means all current callers of `ShouldInitFixedSlots` are actually no-ops.
`MacroAssembler::initGCSlots()` is now always called with `initContents=true`,
so we can remove the parameter.
Depends on D156053
Differential Revision: https://phabricator.services.mozilla.com/D156054
We don't need to hide/show GDK_WINDOW_TYPE_HINT_UTILITY popup type to change it's position.
Hide it only if we need to set correct popup type as such change is done in map event.
Differential Revision: https://phabricator.services.mozilla.com/D156305
Checks the module status unconditionally and throws an error if it is not as
expected.
This now includes the unexpected status in the error to help debugging and bug
reported.
Differential Revision: https://phabricator.services.mozilla.com/D156293
This rendering of the tabs with emulated flexbox enabled (modern flexbox
behavior with min-width: auto is giving at least minimum content size).
It doesn't have any negative impact on XUL rendering, so do it
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D156383
This patch adds reverts back to having distint context menu items for 'Resend' and 'Edit and Resend'
but this is using the new http custom request functionality.
Differential Revision: https://phabricator.services.mozilla.com/D155159
This is a follow-up of 1788645, removing the font weight/style reset in
MathMLTextRunFactory when the mathvariant transform is not none. A WPT
test for mathvariant="double-struck" is added to exercise this case.
Differential Revision: https://phabricator.services.mozilla.com/D156400
be -> 4218d795b4a60187eb4a6b2fe1175ab76de97b7b
ca -> 25bc6fa19f6506d615c206f51ccd94ad4c428b71
es-ES -> 77c9bfe1a7d38986ff65624961cb0916d0923345
eu -> a21c10396896d8c1dfe5cc1e14433ff97665066c
fi -> 1b498c77acea807d29e5f06d87424eb694d050df
sk -> 579d0ce2e85aeb3bccb46b264694a47f1b516e93
zh-CN -> 5da886406a81d43b5efcd5cce069a4c8f77b8e58
JAWS won't expose MathML without this.
We can't fully support it; we don't cache info about namespaces, for example.
However, this implementation is enough to get MathML working with JAWS.
Differential Revision: https://phabricator.services.mozilla.com/D156150
There is no easy way to inject failures like OOM during the JSON generation
process, except from markers, which have direct access to the
SpliceableJSONWriter that may now use a fallible FailureLatchSource.
Differential Revision: https://phabricator.services.mozilla.com/D155664
Because JITFrameInfo objects are creating *during* profiling, they need to have
their own fallible FailureLatchSource, so that any error can be safely handled
even before we know which FailureLatch will be used in the final JSON
generation work.
Differential Revision: https://phabricator.services.mozilla.com/D155655
This will help with forwarding the chosen FailureLatch to the code and
structures gathering per-thread samples and markers.
Differential Revision: https://phabricator.services.mozilla.com/D155654
When something goes wrong, the most likely cause is running out of memory, so
we clear our data to try and free some memory ASAP, to hopefully reduce the
likelihood of a terminating OOM elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D155653
