Note that the ignore code for subprocess is being ported from the legacy worker watcher.
The Worker Target URL is now correctly set to the Absolute URL,
this has an impact on the context selector as we are displaying it.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
We seem to never wait for the breakpoint to be actually visibile before calling assertBreakpoint,
but it seems that it is relevant in this particular test, in the uncompressed codepath.
Differential Revision: https://phabricator.services.mozilla.com/D210991
We were waiting for Sources, which are resources, but not the targets,
which are updated with a different logic and timings.
Differential Revision: https://phabricator.services.mozilla.com/D210943
This patch
- Gets the search in file feature working for codemirror 6 (Use Ctrl/CMD F to open in the editor)
- Highlights search results in the editor, when using the search panel on the left.
- Includes the @codemirror/search package in the codemirror bundle. This enables using the `RegExpCursor`
Differential Revision: https://phabricator.services.mozilla.com/D208110
In some cases, we were getting null sourceId, which was causing an exception
to be thrown in `getFormattedSourceId` since it expects a string.
We add a simple guard in this function so we don't throw anymore.
But we shouldn't get null sourceId in the first place. It looks like for
some Wasm sources, the SavedFrame sourceId can be 0, which wasn't playing
well with some loose check we were doing in the sources manager.
Finally, the "Copy metadata" button we display when a console message crash
wasn't working. The message now includes the targetFront, which can be serialized
in JSON, so we simply ignore it.
Differential Revision: https://phabricator.services.mozilla.com/D206105
The previous patch explicitly prevents spawning JavaScriptTracer for same-process iframe,
as the JavaScriptTracer can only be spawn once per thread.
But then the JavaScriptTracer should ensure tracking DOM Events for these same-process iframe globals.
`DebuggerNotificationObserver` requires to connect to each individual WindowGlobal.
Connecting to the top WindowGlobal isn't enough to receive DOM Events for children WindowGlobals.
Differential Revision: https://phabricator.services.mozilla.com/D208468
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
Register them as soon as we open devtools, instead of waiting for debugger panel opening.
So that breakpoints can work even if we did not open debugger panel yet.
So far, only debugger statement would force the opening of the debugger.
This allows to remove the redundant code from debugger frontend.
Also clarify in this patch that thread-utils exports thread configurations.
Differential Revision: https://phabricator.services.mozilla.com/D205772
- Added the requirement for a new `id` property to markers passed to the `setLineGutterMarkers` API.
- Changed `gutterLineClassName` to `lineClassName` the API name already indicates that it is the gutter, no need to have gutter in the property name, this also amkes it consistent with `setLineContentMarker`
- Changed `createGutterLineElementNode` to `createLineElementNode` for same reason as above.
Differential Revision: https://phabricator.services.mozilla.com/D205435
In this patch
1) Adds the `setLineGutterMarkers` function to the editor which enables defining gutter markers
the line number gutter component. This also updates the line number gutter when the viewport (visible ranges)
change (This usually happens when the editor is scrolled).
2)The first use of the `setLineGutterMarkers` is for rendering empty lines
Differential Revision: https://phabricator.services.mozilla.com/D202716
In this patch
1) Adds the `setLineGutterMarkers` function to the editor which enables defining gutter markers
the line number gutter component. This also updates the line number gutter when the viewport (visible ranges)
change (This usually happens when the editor is scrolled).
2)The first use of the `setLineGutterMarkers` is for rendering empty lines
Differential Revision: https://phabricator.services.mozilla.com/D202716
Cristian Tuns