Script object-literal singletons are only generated for top-level run-once
scripts which both XDR and cloning no longer need to support. As a result,
the `cloneSingletons` mechanism is no longer needed and can be removed.
We can simplify the Interpreter and JITs handling of JSOp::Object to no
longer worry about cloneSingletons as a result. They also lets us remove the
`setSingletonsAsValues` code since we no longer have realm-wide poison bits.
Differential Revision: https://phabricator.services.mozilla.com/D91365
Use the same conditions for EncodeScript as we do for CopyScriptImpl. This
involves checking if the top-level script was compiled as run-once. This
check applies regardless of whether the script has been run on not (which is
a stricter test than might otherwise be required). This lets us avoid the
"cloneSingletons" mechanism altogether.
This is more consistent with browser use-cases of EncodeScript which do not
mark scripts as run-once.
We change test behavior to not use the run-once flag for non-incremental
mode. Cases that are testing run-once-only features now use incremental XDR
which is consisten with what the browser actually does.
Depends on D91363
Differential Revision: https://phabricator.services.mozilla.com/D91364
The JSOp::Object opcode is only for "run-once singleton contexts" which
require the run-once CompileOption to be set. We will use this invariant to
eventually remove the cloneSingletons mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D91363
This change allows to retrieve `arguments[Symbol.iterator]` without calling the
resolve hook and without actually adding the iterator function to the arguments
object.
Differential Revision: https://phabricator.services.mozilla.com/D91031
Both arguments objects resolve hook were defining the iterator property, but
didn't set the corresponding `ITERATOR_OVERRIDDEN_BIT` flag. We don't need to
apply a similar change for the other resolved properties, because they're
using the `(Un)MappedArgGetter` and `(Un)MappedArgSetter` property functions.
In preparation for part two, the code to retrieve `ArrayValues` was already
moved into a separate function.
Differential Revision: https://phabricator.services.mozilla.com/D91030
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
In order to support building with relative paths to third-party code we need
to normalize the non-unified source paths prior to comparing them to incoming
source paths during moz.build file generation.
Depends on D91319
Differential Revision: https://phabricator.services.mozilla.com/D91320
As it's too slow (specially on Android and WebRender) and causes tests
to timeout semi-randomly.
In order to do that, implement nsIBrowserDOMWindow in the reftest
window, in a way that keeps the existing behavior for all other things
we care about.
While at it, remove the renderroot attribute which is just leftover (no
longer exists).
Differential Revision: https://phabricator.services.mozilla.com/D91186
The bug doesn't affect every user. It at least affects fedora users running freetype 2.10.2 with the system font Cantarell regular. If FT_Get_Var_Design_Coordinates isn't called on the original FT_Face before FT_Set_Var_Design_Coordinates is called, the new font face with variations gets into an invalid state, causing FT_Load_Glyph to fail with the Invalid font error (0x3). FT_Get_Var_Design_Coordinates was not called on the parent/gpu process because it is done on a face built from the same font on the content process. The workaround is to call it and ignore the result.
Differential Revision: https://phabricator.services.mozilla.com/D91306
