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
The cleanup work done from didDestroy was only calling `unwatch` on the Watcher classes,
which was typically unregistering the platform listeners.
We were missing calling `destroyTargetsForWatcher` on them which is meant to destroy
the target actors, which can also register platform listeners and be leaking data.
Differential Revision: https://phabricator.services.mozilla.com/D210366
Stop unregistering the JS Process actor when removing the last watched target/resource type.
Instead only unregister it when the Watcher Actor is destroyed.
It prevents some race condition where unwatch request (which aren't awaited for)
unregister the actor late and the next test/next toolbox opening would have its actor
unregistered by late destruction code related to the previously closed toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D210365
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
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
The cleanup work done from didDestroy was only calling `unwatch` on the Watcher classes,
which was typically unregistering the platform listeners.
We were missing calling `destroyTargetsForWatcher` on them which is meant to destroy
the target actors, which can also register platform listeners and be leaking data.
Differential Revision: https://phabricator.services.mozilla.com/D210366
Stop unregistering the JS Process actor when removing the last watched target/resource type.
Instead only unregister it when the Watcher Actor is destroyed.
It prevents some race condition where unwatch request (which aren't awaited for)
unregister the actor late and the next test/next toolbox opening would have its actor
unregistered by late destruction code related to the previously closed toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D210365
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
Error were thrown when trying to fetch headers and cookies, which was preventing inspecting them fully.
Fixing that, enable seeing about:neterror requests which were trigerring a file:// URI request (at least on local builds).
So that we now have to explicitly ignore these error requests.
Differential Revision: https://phabricator.services.mozilla.com/D210319
Instead, we use the new CSSStyleRule.querySelectorAll method to retrieve the
elements to highlight.
We still compute a "selector", which is basically a concatenation of the
ancestor rules, so we can still mark the rule as highlighted when we display a
different StyleRule front for a rule that was previously highlighted.
Differential Revision: https://phabricator.services.mozilla.com/D208364
This is done to avoid a performance issue with deeply nested rules,
where computing the desugared selector can be super expensive.
This should help overall since we're doing a bit less work, as well
as returning smaller data.
Differential Revision: https://phabricator.services.mozilla.com/D207727
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
In order to abort eager evaluation when executing a resolve hook with side-effect,
especially the Services' hook which imports ES module, which is not undo-able,
introduce a dedicate debugger flag to ask to avoid side-effectful operation in
the resolve hook.
Differential Revision: https://phabricator.services.mozilla.com/D208970
Recursively traverse css rules so we can collect
keyframes rules nested in other rules, which should
behave as regular rules.
We also don't collect ancestor rules for keyframe rules,
as they can only be direct child of @keyframes rules, and
we'd rather display the @keyframes ancestor data at some
point.
Differential Revision: https://phabricator.services.mozilla.com/D209354
In order to abort eager evaluation when executing a resolve hook with side-effect,
especially the Services' hook which imports ES module, which is not undo-able,
introduce a dedicate debugger flag to ask to avoid side-effectful operation in
the resolve hook.
Differential Revision: https://phabricator.services.mozilla.com/D208970
This feature is added as "recommended", and added to every presets. This will
allow us to disable it if we really want to.
If the "native allocations" feature is enabled, we still force the installation
of the memory hooks even if we don't have this feature to not break the native
allocations feature.
Differential Revision: https://phabricator.services.mozilla.com/D206789
This feature is added as "recommended", and added to every presets. This will
allow us to disable it if we really want to.
If the "native allocations" feature is enabled, we still force the installation
of the memory hooks even if we don't have this feature to not break the native
allocations feature.
Differential Revision: https://phabricator.services.mozilla.com/D206789
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 JavaScriptTracer class for now only supports being instantiated once per thread.
So that we shouldn't try to instantiate it for WindowGlobal/<iframe> that run in the same
process as their parent document. The `isProcessRoot` will be true for the top document
and false for children running in the same process as their parent document.
Also address a noisy exception happening when debugging Google Doc.
Differential Revision: https://phabricator.services.mozilla.com/D208321
We shouldn't try to request target actor's form late during the destroy sequence.
This would force to re-create the Lazy Target Scoped Actors via LazyPool,
which would ultimately force to re-instantiate a new _targetScopedActorsPool
which wouldn't be destroyed as it is created post-destruction.
Avoid re-instantiating the target scoped actors when we detect that the actor is being destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D207487
When picking nodes while holding Shift, we're calling
nodesFromRect, which returns a list of nodes, in no
particular order.
Instead of randomly picking the first one in the list,
return the first one that is not a parent of any of the
other matching elements.
This should potentially give us the deepest element (even
if in some situation we might miss "deeper" nodes from other
branches than the first "only child").
Differential Revision: https://phabricator.services.mozilla.com/D207256
When picking nodes while holding Shift, we're calling
nodesFromRect, which returns a list of nodes, in no
particular order.
Instead of randomly picking the first one in the list,
return the first one that is not a parent of any of the
other matching elements.
This should potentially give us the deepest element (even
if in some situation we might miss "deeper" nodes from other
branches than the first "only child").
Differential Revision: https://phabricator.services.mozilla.com/D207256
- Guard Services.prefs as this isn't available in workers
- Pass worker's global to getAvailableEventBreakpoints when in worker toolbox
- Check that global exists before checking property on it
Differential Revision: https://phabricator.services.mozilla.com/D207257
We were getting a line byte index for the
actual char matching the line we want, but
we actually need the index _after_ that
new line char.
A test case is added to cover this fix.
Differential Revision: https://phabricator.services.mozilla.com/D207156
Cristian Tuns