These just do a Shape guard against a Shape stored in the Realm. If the guard
fails we do a callWithABI to a function that updates the shape.
Differential Revision: https://phabricator.services.mozilla.com/D79265
We attempt to reduce the number of event loop iterations, which would bring us back to a similar behaviour to the pre-DocumentChannel days.
This prevent some tests to have increase intermittent failures.
While ideally, we would prefer to fix or re-write those tests properly, the extra work would block us for too long.
All those increased intermittents already have bug logged about them; so we aren't hiding dust under the rust.
Differential Revision: https://phabricator.services.mozilla.com/D78489
The earlier changes make this unnecessary. The load will start and will automatically resume once the PDocumentChannelParent::RedirectToRealChannel promise gets resolved when a DocumentChannel claim the DocumentLoadListener.
Differential Revision: https://phabricator.services.mozilla.com/D78488
When chaining a MozPromise set to be dispatched via the direct task queue (or synchronous), it makes sense for the chained promise to be dispatched in the same fashion.
All MozPromises generated by the IPC bindings are set to use the direct task queue in order to prevent the then runnable to run out of order with other IPC tasks.
We want to preserve that task ordering by default.
Differential Revision: https://phabricator.services.mozilla.com/D78178
This prevent being able to assert in the AutoTaskDispatcher that we are using it from the right thread/taskqueue as the SimpleTaskQueue object isn't thread-safe.
We want to assert that all nsIDirectTaskDispatcher methods are only ever accessed on the underlying thread. To do so require that the scope of AutoTaskDispatcher to terminate prior the AutoTaskGuard one.
Differential Revision: https://phabricator.services.mozilla.com/D79096
It will simply forward the interface to the main thread.
This is the final step required to remove AbstractThread support here.
Differential Revision: https://phabricator.services.mozilla.com/D79095
We extract the dealing of direct tasks from the TailDispatcher object and move into to the existing nsThread and TaskQueue classes.
TaskQueue is made to work with do_QueryInterface.
We continue accessing the direct tasks dispatcher via the TailDispatcher for now, which itself will forward the dealing of such tasks to the underlying thread.
Differential Revision: https://phabricator.services.mozilla.com/D79093
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One affect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
converts:
* security.sandbox.rdd.win32k-disable
* security.sandbox.gmp.win32k-disable
I'm assuming the pattern established by the other, newer, win32k StaticPrefs can
be followed here, and the xpcom checks aren't needed.
Differential Revision: https://phabricator.services.mozilla.com/D78933
The promises are rejected before shutting down threads so that they don't need
to wait for nested event loops to exit.
Differential Revision: https://phabricator.services.mozilla.com/D76807
The key change here is that AudioContextOperation promises for the same
AudioContext are resolved in order as long as the graph is running.
There is one remaining case where AudioContextOperation promises can be
resolved out of order, which is when
AudioContextOperationControlMessage::RunDuringShutdown() resolves a Close
operation shortly after Run() has queued its update via mUpdateRunnables.
mUpdateRunnables are run after controlMessagesToRunDuringShutdown.
https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/dom/media/MediaTrackGraph.cpp#1793,1803
Pending resume operations are now stored on the graph instead of on
mNextDriver. This means there is no need to move operations between drivers
when switching from one mNextDriver to another, the code for which was
previously missing.
Suspend operations are performed immediately, because even a callback driver
can render nothing. Tracks are not resumed until either there is an
AudioCallbackDriver to deliver the rendered audio or the Resume operation is
canceled by a subsequent Suspend.
While the graph is running, DispatchToMainThreadStableState() is used
consistently, whereas previously this was mixed with direct Dispatch() to the
main thread, which could have the runnable Run() before main thread state had
been updated for rendering up to the time of a Suspend.
Differential Revision: https://phabricator.services.mozilla.com/D76806
This provides that a new track does not start processing before existing
tracks in the AudioContext, which may not be resumed until an
AudioCallbackDriver is running.
Depends on D79048
Differential Revision: https://phabricator.services.mozilla.com/D79049
Moved info icon from after text to before text.
Matched the spacing between the icon and text to the spacing between the icon and text in the Console.
Updated relevant WhyPaused snapshot tests.
Differential Revision: https://phabricator.services.mozilla.com/D78601
This is a short-term step to ensure all tests pass with the mvm pref
turned on. It disables the visual viewport setting codepath for visual-only
MVM instances, unless the APZ zooming pref is also set (because other APZ
zooming code relies on this).
Differential Revision: https://phabricator.services.mozilla.com/D79229
If there's no meta-viewport handling, the MVM shouldn't need to do reflows
because it shouldn't be changing the layout viewport. Also there should be
no need for the MVM to adjust the resolution on the presShell since the
user will be driving those changes via user input. The MVM now just updates
the visual viewport sizing in response to changes.
It may turn out that some these conditions need to be tweaked later, but for
now this seems like a reasonable starting point.
Differential Revision: https://phabricator.services.mozilla.com/D79226
Allowing the MVM to control the reflow means that the requested reflow size
is ignored, and instead the existing CSS/layout viewport is used. This is
undesirable for calls to SizeToContent(), where the intent is to do a reflow
to figure out the smallest amount of space the content fits in.
In general though unless we are using mobile viewport sizing we shouldn't be
needing the MVM to drive reflows.
Differential Revision: https://phabricator.services.mozilla.com/D79225
The MVM is needed for both handling of meta-viewport tags and APZ zooming.
However, the set of functionality needed in the two modes are not the same.
This patch adds a mechanism to create an MVM with a flag that lets it know
which mode it is operating in. Eventually we may want to split this into two
or more classes but for now this seems like a reasonable way forward.
The flag is currently set on the MVM on creation based on whether or not the
meta-viewport support is needed. There's no code that meaningfully *uses* the
flag yet, so this patch should have no functional change. The bulk of the
patch is ensuring that we appropriately destroy and re-create the MVM if the
flag required changes.
Differential Revision: https://phabricator.services.mozilla.com/D79224
Daisuke Akatsuka
Kriyszig
Jan de Mooij
Jean-Yves Avenard
Noemi Erli
Nils Ohlmeier [:drno]
Logan Smyth
Alexis Beingessner
Karl Tomlinson
Razvan Maries
Kyle Knaggs
Kartikaya Gupta
Ben Hearsum