This will help transition to ES Modules as we won't be able to expose a magic "chrome" ESM.
Also, most of these symbols are exposed as global already.
All but:
* `components` which is `Components`,
* `CC` which is `Components.Constructor`,
* `Cm` which is `Components.manager`.
$ sed -ie "/require(.chrome.)/d" $(git grep -l 'require("chrome")' devtools/)
+ manual edits for all three exceptions
Differential Revision: https://phabricator.services.mozilla.com/D156936
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.Services.)/d" $(git grep -l 'require("Services")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .Services./d" $(git grep -l 'loader.lazyRequireGetter(this, "Services"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js
+ manual eslint fixes
+ removal of devtools-services in the debugger, except for jest tests
Differential Revision: https://phabricator.services.mozilla.com/D156401
As we are already filtering the JS Globals via _shouldAddNewGlobalAsDebuggee,
there is no need to filter out the JS Sources.
We do want all the sources for all the WebExtension globals.
Differential Revision: https://phabricator.services.mozilla.com/D136507
In target-actor-mixin, we were calling `setActiveEventBreakpoints` only with the
new events we were receiving, which mean if the user was clicking a first event in
the UI, and then a second one, only the second one would have a functioning event breakpoint.
Also, we were not handling removing event breakpoints at all.
We're adding `(add|remove)EventBreakpoints` to the thread actor so it's easier
to update the list of event breakpoints.
The existing event breakpoints test is modified to ensure we don't regress such behaviour.
The call to `setEventListenerBreakpoints` is moved before dispatch the `UPDATE_EVENT_LISTENERS`
action so we can properly wait for the breakpoint to be set in tests.
Differential Revision: https://phabricator.services.mozilla.com/D135216
Regression from bug 1643540.
Debugger.findSourceURLs is recording all sources except the one having an `introductionScript` defined.
i.e. the one being added dynamically and not part of the original HTML content (at least that the expectation of findSourceURLs)
It is important to use the same filtering in ThreadActor, otherwise we may not populate `urlMap`
correctly and call resurrectSource for sources that were recorded by findSourceURLs.
This would introduce duplicated Debugger.Source and SourceActor for the same URL.
Differential Revision: https://phabricator.services.mozilla.com/D132218
Regression from bug 1643540.
Debugger.findSourceURLs is recording all sources except the one having an `introductionScript` defined.
i.e. the one being added dynamically and not part of the original HTML content (at least that the expectation of findSourceURLs)
It is important to use the same filtering in ThreadActor, otherwise we may not populate `urlMap`
correctly and call resurrectSource for sources that were recorded by findSourceURLs.
This would introduce duplicated Debugger.Source and SourceActor for the same URL.
Differential Revision: https://phabricator.services.mozilla.com/D132218
We're using the new `force` parameter for `insertAnonymousContent` to force creating a container
for the anonymous content, and we add a new option to the CanvasAnonymousHelper so highlighter
can choose to not wait for the dom to load.
For now we only use it for the paused debugger overlay as the other highlighters might need
an inspector front, which may require the dom to be ready.
We enable the assertions in browser_dbg-paused-overlay-loading.js to check that the
highlighter is visible.
This required a few changes in the highlighter test actor.
First, it was waiting for an inspector front in its initialize method, which was
waiting indefinitely in our test as the document is paused. As this was only done
to retrieve the inspector actorID, we simply remove it and retrieve the actorID
through the connection and the target form when it's needed (for the eye dropper).
Secondly, the isPausedDebuggerOverlayVisible method was returning true even when
the highlighter wasn't displayed, so we check a few additional attributes.
Depends on D132034
Differential Revision: https://phabricator.services.mozilla.com/D132116
At the moment, the overlay can't be displayed if the DOM isn't loaded,
and we were waiting for that state before trying to show the overlay.
But we can't move forward in the document loading process until we resume,
which mean we could end up in weird state with the overlay, where the
page wasn't paused anymore, but we'd display it.
In this patch, we simply bail out if the document isn't ready.
Differential Revision: https://phabricator.services.mozilla.com/D131884
At the moment, the overlay can't be displayed if the DOM isn't loaded,
and we were waiting for that state before trying to show the overlay.
But we can't move forward in the document loading process until we resume,
which mean we could end up in weird state with the overlay, where the
page wasn't paused anymore, but we'd display it.
In this patch, we simply bail out if the document isn't ready.
Differential Revision: https://phabricator.services.mozilla.com/D131884
At the moment, the overlay can't be displayed if the DOM isn't loaded,
and we were waiting for that state before trying to show the overlay.
But we can't move forward in the document loading process until we resume,
which mean we could end up in weird state with the overlay, where the
page wasn't paused anymore, but we'd display it.
In this patch, we simply bail out if the document isn't ready.
Differential Revision: https://phabricator.services.mozilla.com/D131884
I don't think it was any useful to block synchronously on the call to `doResume`.
In the past it used to send an event to the client synchronously,
it may have been important back then.
test_nesting-03.js is still covering nested event loop by using two clients.
Differential Revision: https://phabricator.services.mozilla.com/D118173
Depends on D118470
The ThreadActor is storing frame actors in a local map, on top of the regular pools managed by the framework.
If a frame corresponding to an already destroyed actor needs to be handled and returned again by the thread actor, it should create a completely new Actor instead of attempting to reuse an already destroyed object.
Differential Revision: https://phabricator.services.mozilla.com/D118471
This was causing _priorPause to be reset unexpectedly,
leading to lastPausedPacket being null and missing "paused" THREAD_STATE resource.
Differential Revision: https://phabricator.services.mozilla.com/D103068
Stop unregistering onExceptionUnwind on navigation (will-navigate) and pauses.
So that we no longer have to re-register it on window-ready and resume.
Instead, only check that we aren't paused when processing an exception.
Regarding navigation, I don't think we want to ignore any exception during the process of navigating to another page.
I would rather say we want to catch anything that happen during this process!
Differential Revision: https://phabricator.services.mozilla.com/D101651
This is no longer necessary as attach is no longer entering in a nested event loop.
And so we can have attach to complete and return its value as any other request.
Differential Revision: https://phabricator.services.mozilla.com/D100045
We always used to pause when "attaching" the thread actor.
We ought to call ThreadActor's attach method first before using it.
And this method do various things:
* Initialize the Debugger API, enable it, register various listeners, so that breakpoint can work,
* Pause the current thread by starting a nested event loop
So that we also ought to resume the thread, by calling ThreadActor's resume right after attach.
Otherwise the page would be paused as soon as we open the DevTools.
Which sounds like something we might have wanted a very long time ago.
But sounds like pure legacy behavior from today's perspective.
Differential Revision: https://phabricator.services.mozilla.com/D99919
When pausing in a content process script in the Browser Toolbox (e.g. somewhere
in devtools/server), we tried to display the PausedDebuggerOverlay, which was
causing an error to be displayed in the CanvasFrameAnonymousContentHelper, as
we didn't have access to a documentElement property it needed.
This happens because the _canShowOverlay method in the thread actor was only
checking for the presence of a window property on the target actor.
Unfortunately, the ContentProcessTargetActor does expose a window getter, which
is a Sandbox, and thus doesn't have a document.
This patch modifies the _canShowOverlay function to check that we do have access
to a documentElement.
Differential Revision: https://phabricator.services.mozilla.com/D99899
Before showing the pause overlay, we wait for the page to be fully loaded.
This introduced some delay, and at the moment we were showing the overlay, the
debugger could not be paused anymore.
This patch adds another check to ensure the debugger is paused, as well as a
test to avoid regression."
Differential Revision: https://phabricator.services.mozilla.com/D97778
In Bug 1673328, the signature of the resume function was modified,
but we missed that the function was called from the paused overlay,
which means we didn't pass the correct signature anymore, and buttons
of the paused overlay weren't working at all.
This patch fixes the callsite and adds a mochitest where we go
through a simple case of pausing and then stepping and resuming
by clicking on the overlay buttons.
Since the pause overlay is different from the other highlighters
for which we already had test helpers, we needed to add dedicated
test helpers for the pause overlay, in the test actor.
Differential Revision: https://phabricator.services.mozilla.com/D97757
The function wasn't used, except in a test that this patch removes.
Since it was also the only use of the getSourcesManager hook, we're able to
remove it as well.
Differential Revision: https://phabricator.services.mozilla.com/D95989
This was hacking the internals of RDP/protocol.js in order to provide
different names to the actor prototype.
I had to rename existing `skipBreakpoints` getter in order to avoid
name collision with the RDP method of the same name.
I also had to tweak a few method arguments as they weren't following protocol.js spec.
They were called without protocol.js automatic marshalling of values.
Finally, hack something in protocol.js in order to avoid duplicated response for ThreadActor.attach.
Differential Revision: https://phabricator.services.mozilla.com/D94958
Alexandre Poirot
Mark Banner
criss
Yury Delendik
Tooru Fujisawa
Nicolas Chevobbe
Noemi Erli
Cosmin Sabou
Cristian Tuns
Julian Descottes
Butkovits Atila