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
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
Removes the instance of `WhyPaused` in `debugger/src/components/App.js` as the mark up that it returns does not contain useful information and is never visible to the user.
Differential Revision: https://phabricator.services.mozilla.com/D79144
When the autoclose bracket addon is enabled, quotes and ] are automatically
inserted, but that wasn't taken into account in the function that is in charge
of setting the input value when the user accept the autocompletion.
This patch should fix this, and add a few tests to makes sure we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D79126
The console editor uses the codeMirror autoclose bracket addon,
which when the user types a closing bracket and the next char
in the input is the same char, won't insert a new char, but will
only move the cursor.
In such case, the JsTerm code wasn't capturing this key event, and
it could happen that the autocomplete would still be displayed,
which would then lead to some weirdness when the user hits Enter.
In order to fix that, we listen for the keyHandled event, which
is fired one a keypress was handled, and that appear that be fired
for the case I exposed, and isn't triggered when the character is
simply inserted.
A test case is added in one of our test to make sure this works as
expected.
Differential Revision: https://phabricator.services.mozilla.com/D78935
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 patch adds a ResizeObserver to the input node, which when triggered
refreshes the codeMirror instance.
This is needed because codeMirror draws specific elements, like the cursor
and selection blocks, and they need to be re-computed if the editor size
changed (the line might have wrapped, and the cursor need to be in a new
position now).
Depends on D78649
Differential Revision: https://phabricator.services.mozilla.com/D78661
CodeMirror does not have an option to automatically remove
the selection when the editor is blurred, which means there
can be a kind-of weird visual glitch when there was a selection
and the user does another selection.
This patch listen for the blur event on the editor, and if there
was a selection, removes it.
The blur event need to be piped down from the sourceeditor.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D78649
Support for `goForward()` and `goBack()` has been removed for `mozbrowser` elements, which were methods that old-RDM used to handle backward/forward navigation. Since the custom implementation of the webNavigation object for old-RDM uses the `WebNavigation` actor as a fallback for APIs that are not supported by `mozbrowser`, we can also do the same for `goForward()` and `goBack()`.
Differential Revision: https://phabricator.services.mozilla.com/D78835
This broke when the main developer tools window was converted from XUL to XHTML. By adding the application role, the window is once again a window, not a document for the accessibility engine.
In addition, while I was here, I fixed the role of the focusable vbox because it is the first thing the user lands on when tabbing, to make it a semantic group, not an "unknown". Since this is probably supposed to be focusable for keyboard users, it is better to have an appropriate role.
Differential Revision: https://phabricator.services.mozilla.com/D79038
Support for `goForward()` and `goBack()` has been removed for `mozbrowser` elements, which were methods that old-RDM used to handle backward/forward navigation. Since the custom implementation of the webNavigation object for old-RDM uses the `WebNavigation` actor as a fallback for APIs that are not supported by `mozbrowser`, we can also do the same for `goForward()` and `goBack()`.
Differential Revision: https://phabricator.services.mozilla.com/D78835
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
