This means that it'll happen even if the menu item is not visible. This will make
it possible to make a menu item visible after initial menu construction.
Differential Revision: https://phabricator.services.mozilla.com/D112448
When `document.execCommand("selectall")` is called, it should behave exactly
same as "Select All" in the UI for compatibility with the other browsers.
And also this patch fixes a bug of the WPT. `selectionchange` event should
be fired, but asynchronously. Therefore, Chrome also fails the check.
Differential Revision: https://phabricator.services.mozilla.com/D112307
The events being listened for here are mouse events, all of which
go through both the bubble and capture phases. It's not clear to
me why I originally added this listener in the capture phase; it
is more useful in the bubble phase because then it resolves the
promise after the event has triggered listeners registered on the
target element, rather than before.
Note also that prior to the promis-ification of this function, the
callback was called inside a setTimeout(0) wrapper, which would
automatically have deferred the callback to after the event dispatch
was completed. So technically the promis-ification of this function
introduced a functional change because now the promise can get
resolved before the event dispatch is complete, and in particular,
before listeners on the target element get run. This didn't affect
anything in practice because none of the existing callers actually
have such a listener on the target element. The next patch adds
one though, and exposed this behaviour difference when I rebased it
across the promis-ification change..
This patch removes the capture:true listener option, causing the
listener to get registered in the bubble phase.
Differential Revision: https://phabricator.services.mozilla.com/D112500
WebRenderBridgeParent::mPaused does not hold correct paused state, initial state of mPaused was always false. And CompositorBridgeParent already keeps correct paused state.
Differential Revision: https://phabricator.services.mozilla.com/D112518
https://drafts.csswg.org/css-images-4/#image-set-notation has:
> [...] it also specifies the image’s natural resolution, overriding any other
> source of data that might supply a natural resolution.
Astounding that there was literally no WPT for this at all. I added three: one
for backgrounds, one for list-style-image, and one for `content`. Cursor is not
handled on this patch because that one requires a fair amount of extra work.
Differential Revision: https://phabricator.services.mozilla.com/D112474
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
Note: This revision will have to be folded with Parts 3 and 4 before landing, as
the op PushLexicalEnv breaks here, and is replaced with PushClassBodyEnv in Part 4.
Depends on D108283
Differential Revision: https://phabricator.services.mozilla.com/D108284
This reverts commit e542e8826b92f70dbabaf577d80a32273c684d1b.
In hindsight, this was a pretty bad change. It introduces a third place where
the EventDispatcher can be shutdown (JavaScript) and doesn't do a good job at
communicating this across all consumers.
I introduced this change in Bug 1567341 to fix some leaks in xpcshell tests at
xpcom shutdown, and it was never meant to affect a normal browser use (turns
out, it does).
I ran the tests again in try and they are still green when reverting this
change, I suspect that the actual failures I was seeing were due to a separate
leak that I fixed while developing the patches.
Differential Revision: https://phabricator.services.mozilla.com/D112637