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
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79294
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79252
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79249
My patch from bug 1599160 changed timing in a way that makes this bug a
perma fail and I'd rather not get it backed out :)
Differential Revision: https://phabricator.services.mozilla.com/D79316
This attribute can only be toggled on top level BrowsingContext.
These are the top level window's, or tab's BrowsingContext.
From DevTools point of view, it should only be toggled by the
Parent Process or Tab target.
Differential Revision: https://phabricator.services.mozilla.com/D78860
The lack of specificity for script intro type has lead the debugger to need
to make use of 'source.introductionType' and 'source.element' in order to
determine whether a given script was injected, or inline or fetched, which
is entirely unnecessary of the loader itself clearly tells us what type
of script we are working with. It also allows us to cleanly handle the case
of XUL, which previously was "scriptElement" but has no ".element" passed
in, so we were unable to know whether a given source was inline or not.
Differential Revision: https://phabricator.services.mozilla.com/D78435
We were getting duplicated nsIScriptError in the Browser Toolbox console and the Browser Console
when the multiprocess pref is enabled, because error from content processes are forwarded to
the main process.
The previous patch of this queue added a isForwardedFromContentProcess flag to nsIScriptError,
that we use in this patch to _not_ handle forwarded messages in multiprocess browser console
and browser toolbox console.
Differential Revision: https://phabricator.services.mozilla.com/D78231
We were getting duplicated nsIScriptError in the Browser Toolbox console and the Browser Console
when the multiprocess pref is enabled, because error from content processes are forwarded to
the main process.
The previous patch of this queue added a isForwardedFromContentProcess flag to nsIScriptError,
that we use in this patch to _not_ handle forwarded messages in multiprocess browser console
and browser toolbox console.
Differential Revision: https://phabricator.services.mozilla.com/D78231
According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
This removes the Dev Tools A11y Panel code which explicitly allowed unlabelled descendants of role="img" <svg> elements, since we don't create descendants if they don't have a label now anyway.
The associated tests had to be tweaked as well, since now we don't create unlabelled descendants.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
OuterWindow ID is deprecated in a Fission world and we should rather use Browsing Context ID.
The outer window ID will change when navigating to another origin, loaded in a distinct process,
whereas Browsing Context ID will stay the same.
Differential Revision: https://phabricator.services.mozilla.com/D78253
Before this patch, we were not trying to cleanup anything when the process
was known to be in process of destruction. We assumed that everything would
be cleaned up anyway.
But mochitest is actually asserting that nothing is leaked on process shutdown,
and we are easily leaking many thing when not destroying the target actor!
Differential Revision: https://phabricator.services.mozilla.com/D76156
