The other navigation that allows focus moves (window.open) already goes
through the popup blocker, so that one is fine.
I think given how weird yet conservative other browsers are, this should
be a good trade-off to avoid false positives.
Differential Revision: https://phabricator.services.mozilla.com/D110196
Previously, a transform with a negative scale would result in a
new coordinate system being created when updating the spatial
tree.
This meant that a primitive in that space with a clip in a parent
space would create a clip mask (and was thus unable to be promoted
to a compositor surface).
This change allows negative scales to be part of the same coord
system (since they are still axis-aligned with the parent) and
avoid a clip mask in this case.
Differential Revision: https://phabricator.services.mozilla.com/D109580
WalkTheStack* is the function that is being called to print stacks to
the user on e.g. MOZ_CRASH on debug builds. Until bug 1699375, some
cases weren't covered, which now cause unwanted side-effects with e.g.
fuzzing. At least as a stop-gap, allow to runtime-disable the behavior
via an environment variable.
Other uses of the stack-walker, like the profiler's, are not affected
when setting the environment variable.
Differential Revision: https://phabricator.services.mozilla.com/D110199
* More const
* RAII wrapper instead of macro wrappers
* Add function name to X ERROR spew
* Reduce buffer size, because 100 is plenty. (usual len is <10)
Differential Revision: https://phabricator.services.mozilla.com/D110340
If we specialize OSR-only phis to `MIRType::Value` during conversion, then it is possible for `adjustPhiInputs` to see a phi that is still `MIRType::None`. On x86, this ends up with us crashing while trying to box a Value.
It's more robust to do a separate pass at the end of phi specialization, before we start converting.
Differential Revision: https://phabricator.services.mozilla.com/D109976
Doing so results in unexpected load events for the initial about:blank
document, which the frame script implementation did not see.
Differential Revision: https://phabricator.services.mozilla.com/D110173
This enables the following configuration on autoland and mozilla-central:
> test-windows10-64-qr/debug-mochitest-media-fis-e10s
Differential Revision: https://phabricator.services.mozilla.com/D110161
This enables the following tasks on autoland and central:
> test-linux1804-64-tsan/opt-mochitest-media-fis-e10s
Depends on D110159
Differential Revision: https://phabricator.services.mozilla.com/D110160
Also remove the What's New links from the notifications that had those, along
with the associated string, since the new designs do not include those links.
Differential Revision: https://phabricator.services.mozilla.com/D110189
At the same time, the initialization and storage of private methods is changed
to what the PrivateOpEmitter expects.
There are some barely-observable differences in behavior, resulting in two jit-test changes:
* fields/bug1683784.js - An error message changed. Not really better or worse.
* js/src/jit-test/tests/parser/script-source-extent.js - The debugger is able
to observe initializers as individual scripts. We are no longer using
initializers for private methods that can be optimized, and the debugger
therefore observes the change. I adjusted the test to expect the new
behavior.
All js/src/tests pass.
Depends on D108300
Differential Revision: https://phabricator.services.mozilla.com/D108301
The diff is a mess, but this is very straightforward--we have a combination of
if-statements and a switch that could just be a single switch.
Depends on D108295
Differential Revision: https://phabricator.services.mozilla.com/D108296
In order to correctly support this with the optimized storage for methods we
would need new bytecode like GetAliasedVar which is able to traverse
non-EnvironmentObject environments like DebugEnvironmentProxy.
Unfortunately, for safety this means we will ultimately disable this for a number of
different private field and accessor invocations.
Differential Revision: https://phabricator.services.mozilla.com/D109402
By storing NameLocations we also get a BindingKind, which allows us to disambiguate between
PrivateMethods and Synthetics.
Differential Revision: https://phabricator.services.mozilla.com/D109401
This would cause private methods to be marked as such on scopes, except that
the parser still declares them as `DeclarationKind::Synthetic` for now.
Depends on D108293
Differential Revision: https://phabricator.services.mozilla.com/D108294
This affects bytecode, as Synthetic bindings do not get TDZ checks.
This patch also tightens up some assertions when creating ScopeData. There are
several methods that create ScopeData, and they had gotten out of sync. The
assertions check that the ScopeData is not silently dropping bindings that were
present in ParseContext::Scope::declared_.
Depends on D108292
Differential Revision: https://phabricator.services.mozilla.com/D108293
This is currently used only by the bindings in a ClassBodyScope.
The behavior of these bindings is like Var bindings. There is no longer a TDZ
check, and we don't bother marking them as Uninitialized. So the special case
introduced in bug 1683746, peeking at the binding name to see if we should skip
the TDZ check, is no longer needed.
Depends on D108290
Differential Revision: https://phabricator.services.mozilla.com/D108291
This adds a hasPrivateBrand bit to the MemberInitializers struct in the
stencil. It is necessary to persist this bit across compilation units because
emitInitializeInstanceMembers can be called in direct eval code inside a
derived-class constructor.
Since .privateBrand is currently a `let` binding, this currently emits an
unnecessary CheckAliasedLexical instruction in the constructor for each class
that has nonstatic private methods. We'll eliminate these later on.
Depends on D108289
Differential Revision: https://phabricator.services.mozilla.com/D108290
Not every class gets this special binding. It will be needed for all classes
that have any nonstatic private methods, getters, or setters. With this patch,
we create a .privateBrand binding in the scopes for such classes, and populate
it with a symbol when initializing the class. However, it is not yet being used
anywhere; the constructor does not yet stamp instances with the private brand.
Depends on D108288
Differential Revision: https://phabricator.services.mozilla.com/D108289
It is a copy of BlockLexicalEnvironmentObject. Note that
- ClassBodyScope is *not* a LexicalScope, BUT
- ClassBodyLexicalEnvironmentObject *is* a LexicalEnvironmentObject
This is strictly a matter of how much implementation is shared. The word
"Lexical" in LexicalEnvironmentObject, and to some extent throughout
SpiderMonkey, is alas already pretty meaningless. In the language
specification, all environments are lexical environments.
Depends on D108286
Differential Revision: https://phabricator.services.mozilla.com/D108287