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
This renames the pref to remove 'experimental' and turns it on by default.
For integration with the CC, any DOM objects that are the target of a WeakRef or registered with a FinalizationRegistry have their wrappers preserved. WeakRef.deref() checks whether any wrapper is still preserved and returns undefined if not, to avoid giving out references to wrappers whose DOM object has been cycle collected.
Tests exercising browser integration are under js/xpconnect/tests/mochitest/.
Differential Revision: https://phabricator.services.mozilla.com/D77656
WeakRef targets that are wrappers to DOM objects are preserved when the WeakRef is created. This checks whether the wrapper is still preserved in deref() and if it is found to have been released, the target is cleared.
The patch adds a new DOMJSClass hook to deal with getting the wrapper cache for non-nsISupports objects.
Differential Revision: https://phabricator.services.mozilla.com/D78061
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
This patch removes the dispatch of ReportGenericErrorRunnables when
a worker fails to start, since they were causing crashes and
weren't getting run anyway. It also adds an assertion that prevents
the creation of strong references to workers before they begin
their main loop.
Differential Revision: https://phabricator.services.mozilla.com/D76693
Currently, the worker's COEP value is saved in WorkerPrivate and it is not respected for fetch/cache API in workers.
This patch saving the COEP value which fetch/cache API should be respected when using in workers.
Notice that for the dedicated workers, it is not only respected to worker's COEP but also its owner's.
For fetch in workers, P2 will propagate the COEP value through nsILoadInfo to HttpChannels, such that COEP can be respected in parent process when calling ProcessCrossOriginResourcePolicyHeader() and ProcessCrossOriginEmbedderPolicyHeader().
For cache in workers. We handle it in bug 1603168. COEP will be propagated through CacheRequest to the parent process and respected in CacheOpParent::OnOpComplete().
Differential Revision: https://phabricator.services.mozilla.com/D73689
Using StaticRefPtr instead of a raw pointer for sSharedWorkerService in SharedWorkerService.cpp, and keeping sSharedWorkerService be alive until shutdown by registering sSharedWorkerService to ClearOnShutdown.
Since sSharedWorkerService is not raw pointer anymore, SharedWorkerService needs not to inherit from SupportsCheckedUnsafePtr<CheckIf<DiagnosticAssertEnabled>>
Differential Revision: https://phabricator.services.mozilla.com/D72379
This method can be and is used by derived classes as well as DOMEventTargetHelper
itself, so it does not need to be "Internal".
Differential Revision: https://phabricator.services.mozilla.com/D75246
WorkerGlobalScopeBase has no override for `BindToOwner()`, so there is no need
for the virtual call.
The DOMEventTargetHelper(nsIGlobalObject*) constructor is not suitable here
because the nsIGlobalObject would not have been constructed when the
DOMEventTargetHelper constructor would need it.
Depends on D75037
Differential Revision: https://phabricator.services.mozilla.com/D75039
Allows RemoteWorkerChild to clean up its data appropriately - objects
that must be released on the worker thread should never outlive the worker
thread, and the StrongWorkerRef/WorkerControlRunnable helps guarantee that.
Differential Revision: https://phabricator.services.mozilla.com/D72798
Bug 1594572 attempted to fix a shutdown edge-case where a worker that was
started late enough would fail to create a PBackground connection and
early return. This early return, however, left the worker never scheduled
for deletion, resulting in a shutdown hang. See my restating block at
https://phabricator.services.mozilla.com/D73134#2224963 for more context.
The problem with this was that the attempt to clear the main event queue
ran afoul of pre/post event-processing hooks intended to ensure that control
runnables are processed if some non-worker code goes and spins a nested
event loop on the worker thread. But because we never got around to
creating a cycle collected JS runtime on the thread, the call to get it
would return null and when we tried to get the recursion depth of a null
pointer, we would crash a little.
This patch addresses the immediate regression by adding a helper that returns
a depth of 1 in this edge-case. It also fixes another problem with the fix
that is now more obvious having reviewed bug 1636147... we were failing to
mark the status of the worker as dead and drain any control runnables, which
could have resulted in the CrashIfHangingRunnable usage not working out right.
(Note that CrashIfHangingRunnable does handle Cancel() correctly, so the
fact that we end up canceling the runnable shouldn't break things.)
Differential Revision: https://phabricator.services.mozilla.com/D75185
`RuntimeService::CrashIfHanging` uses `RuntimeService`'s registry
to determine which workers are still active. This approach is
flawed because the registry is updated on the main thread, so if
the main thread is stuck somewhere, dead workers could be reported
as active.
This commit adds an additional check: if dispatching a `Runnable`
to a worker fails, it assumes that the worker is dead. This way
main thread hangs would not be reported as worker hangs.
Differential Revision: https://phabricator.services.mozilla.com/D74256
This patch persists the CrossOriginEmbedderPolicy on the Document and
WindowContext.
The WindowContext's embedder policy is set in
WindowGlobalActor::BaseInitializer by either adopting the policy of the HTTP
channel that loaded the document, or in WindowGlobalChild::OnNewDocument
by inheriting the one from the browsingContext's windowContext.
Differential Revision: https://phabricator.services.mozilla.com/D46903
These pragmas can be used to influence stack trace filenames, and to affect
how and where files show up in developer tools. In some circumstances, it can
be nice to disable allof that functionality in order to ensure that you get
the stack trace and debug information as SpiderMonkey sees it.
Differential Revision: https://phabricator.services.mozilla.com/D72103
We add a configuration option for SIMD and apply ENABLE_WASM_SIMD
throughout the engine as appropriate, mostly to insert #error or
MOZ_CRASH where things need to be done in later patches or for
architectures that we won't currently consider.
We add a command line switch for the shell and an option for
about:config and plumb the value of this through the engine.
Differential Revision: https://phabricator.services.mozilla.com/D57940
CondVar already calls `AUTO_PROFILER_THREAD_SLEEP`, which shouldn't be called recursively.
mozilla::Monitor also uses CondVar, so it shouldn't be surrounded by `AUTO_PROFILER_THREAD_SLEEP` either.
Depends on D72850
Differential Revision: https://phabricator.services.mozilla.com/D72851
This requires adding a new JSOptions field (for internal use within the shell),
as well as a new browser pref (to support possible Cranelift benchmarking on
aarch64).
Differential Revision: https://phabricator.services.mozilla.com/D72907
If we try to start a worker too close to shutdown, the main runnable for its
thread runs after shutdown has begun, bails out early trying to create a
BackgroundChild for its thread. Unlike bail-outs in WorkerPrivate::DoRunLoop,
though, nothing winds up scheduling the deletion of the worker after it
returns, and afterwards the worker is stuck forever in a pending state.
Attempts to shut it down from the main thread just dispatch an impotent
notification to be processed by the workers main event loop (which, of course,
will not ever happen).
This patch fixes the behavior of WorkerThreadPrimaryRunnable to always call
ScheduleDeletion when it exits, rather than only doing so when it succeeds
in entering the worker's main loop.
Differential Revision: https://phabricator.services.mozilla.com/D73134
- Worker debugger globals gets a client with a null principal
- Ensure globals are created before script loads
- Introduce WorkerGlobalScopeBase to share code
- Transfer ClientSource ownership from WorkerPrivate to worker globals
- Require getting clients from the globals instead of WorkerPrivate with the
exception of getting the reserved client before the non-debugger global is
created
Differential Revision: https://phabricator.services.mozilla.com/D68936
Noemi Erli
Logan Smyth
Simon Giesecke
Andrea Marchesini
Butkovits Atila
Alexis Beingessner
Jon Coppeard
Tom Tung
Razvan Maries
Yaron Tausky
Csoregi Natalia
Kris Maglione
Masatoshi Kimura
Matt Woodrow
Bogdan Tara
Neil Deakin
Eden Chuang
Mihai Alexandru Michis
Peter Van der Beken
Tom Tung
Karl Tomlinson
Perry Jiang
Andrew Sutherland
Philip Chimento
Narcis Beleuzu
Jean-Yves Avenard
ssengupta
Alexandre Poirot
Valentin Gosu
Tom Schuster
Dorel Luca
Lars T Hansen
Gerald Squelart
Benjamin Bouvier
Cameron McCormack
Michael Kaply
Oana Pop Rus
Cosmin Sabou
Coroiu Cristina
Gijs Kruitbosch
Jeff Walden