It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
CLOSED TREE
Backed out changeset 8b21977bb2df (bug 1648453)
Backed out changeset 4cac71f274b8 (bug 1648453)
Backed out changeset a9ad01b4ab2e (bug 1648453)
The combination of clang-11, mingw builds, and the recent constructor refactorings in this file, have revealed a previously unseen compiler crash: https://bugs.llvm.org/show_bug.cgi?id=46738.
The underlying issue is present in older clangs but for some reason we haven't triggered the right conditions for it until now.
For now, the easiest way forward is to move the constructors inline. I don't feel so bad about using a code workaround in this case, because this makes the code read more naturally anyway.
Differential Revision: https://phabricator.services.mozilla.com/D83684
The changes in xpconnect are necessary because this is not being specified in
the usual way, with a getter. Ordinary data properties require an explicit
loophole to make them visible through X-ray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D77181
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 effect 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
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
This adds an extra pref for whether the cleanupSome method is exposed and renames the existing pref. We can turn on the pref to expose cleanupSome to get test262 coverage in the browser.
Differential Revision: https://phabricator.services.mozilla.com/D77267
This makes is easier to actually assert that we have the right exception value.
We do have similar tests already, but most of them aren't based directly
on nsIScriptError.
Differential Revision: https://phabricator.services.mozilla.com/D74528
We are adding support for the dotAll (/s) RegExp flag, so the list of expected properties on the RegExp prototype has to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D74149
Implements the spec changes from: https://github.com/tc39/proposal-weakrefs/pull/187
The spec change removes the `FinalizationRegistryCleanupIterator` in favour of
calling the clean-up callback for each finalised value. It also allows to call
`cleanupSome()` within the callback function.
`FinalizationRegistryObject::cleanupQueuedRecords()` has been changed to iterate
from back to front, because this allows us to call `GCVector::popCopy()`, which
makes it more efficient to remove entries from the `records` vector.
Differential Revision: https://phabricator.services.mozilla.com/D70821
Kris Maglione
Matthew Gaudet
Sebastian Streich
Simon Giesecke
Noemi Erli
Dorel Luca
Jon Coppeard
Razvan Maries
Mihai Alexandru Michis
David Major
Jason Orendorff
Narcis Beleuzu
Logan Smyth
Masatoshi Kimura
Tom Schuster
Tom Tung
Iain Ireland
André Bargull