actorhasMethod had several technical limitations making it hard to use consistently. We now removed all the call sites for this method. This changeset removes the method and all its dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D95861
The test was failing on Beta because we weren't setting the devtools.webconsole.input.context
pref, which is true only on Nightly.
This patch flip this pref in the test, which seems to make the test pass.
Differential Revision: https://phabricator.services.mozilla.com/D96061
This supports one manifestparser expression per line in the 'skip-if',
'fail-if' and 'run-if' keys. As a side effect the:
skip-if = foo ||
bar
syntax is no longer supported. Instead it can be:
skip-if =
foo # bug 123
bar # bug 456
Differential Revision: https://phabricator.services.mozilla.com/D95927
Use the generic "highlighter-shown" / "highlighter-hidden" events and check for highlighter type.
Use generic helpers in tests.
Fix an unrelated leftover nit from D92802
Differential Revision: https://phabricator.services.mozilla.com/D95835
The `dom.worker.console.dispatch_events_to_main_thread` pref is used by platform
code to check if console API messages in the worker thread should be dispatched
to the main thread. If so, the message parameters are cloned, or stringified if
they can't be. This is currently the default behavior.
The pref is checked on the server side and added as a trait to the root actor.
On the client, if the pref isn't true, then we accept messages coming from
worker targets in the console. We can't accept them without condition, otherwise
we would get duplicated message (from the main thread AND the worker thread).
The browser_webconsole_console_logging_workers_api.js test is repurposed for
worker logging since it was disabled on e10s anyway. We add a few test case
to check we can get cached and live message, and that non-clonable object, like
worker scope, are displayed like regular objects when the pref is false.
Differential Revision: https://phabricator.services.mozilla.com/D85397
The SELECTABLE_TEXT state is currently under-utilized and probably wrong, since it simply relies on testing if a hypertext has any text. A more correct reflection of the state should be taken from layout's IsSelectable method.
Note, even if an element is styled `user-select: none`, the text will still be keyboard selectable if it is editable (eg. input or contenteditable), so we should consider that SELECTABLE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D95783
Depends on D95685
Keep the isFissionContentToolboxEnabled method but always return true to effectively enable all fission related behavior for all content toolboxes.
Differential Revision: https://phabricator.services.mozilla.com/D95686
This changeset only starts the FrameWatcher for any content toolbox.
The stack will progressively phase out the devtools.contenttoolbox.fission preference.
Differential Revision: https://phabricator.services.mozilla.com/D95685
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
Depends on D95299
The actors/stylesheets.js file contained three actors.
This change moves each actor in its own file.
Differential Revision: https://phabricator.services.mozilla.com/D95328
Depends on D95297
After moving actors to individual files, we should also do the same with specs.
Both actors are using shared types, which are moved to a shared types file.
Differential Revision: https://phabricator.services.mozilla.com/D95298
The actors/styles.js file contained two actors.
This change moves each actor in its own file.
A shared actors/utils/style-utils file is also created to host shared helpers.
Differential Revision: https://phabricator.services.mozilla.com/D95297
These are the presets that I think are most likely in use by people
who report performance bugs with the browser.
The SwComposite thread is used when software webrender is enabled,
except on macOS where it is never used. In those configurations, the
samples from the SwComposite thread are interesting in the same cases
when the samples from the Renderer thread are interesting, i.e. whenever
the performance bottleneck is on the rendering side.
However, we do not need to profile the SwComposite thread in all cases where
we profile the Renderer thread, because in some configurations the Renderer
thread is only profiled so that the screenshot markers are captured. The
SwComposite thread does not have screenshot markers.
Differential Revision: https://phabricator.services.mozilla.com/D95546
This allows to run the performance-new typescript checks via
"node devtools/client/bin/devtools-node-test-runner.js --suite=performance"
Differential Revision: https://phabricator.services.mozilla.com/D95232
Depends on D95035
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode` and `hideBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95036
Depends on D95034
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode` and `hideBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95035
Depends on D95033
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode` and `hideBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95034
Depends on D79556
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode`, `hideBoxModelHighlighter` and `showBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95033
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
We no longer need to manuall call threadActor.exit from Target Actors
as the ThreadActor is managed by the Target Actors, so that managed children
will be destroyed when the target actor is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D94957
Similarly to the frontend, I'm introducing a mixin in order to share code between at target actors.
We might be able to share more, like sources. But at least we share new addition related to watcher and resources.
This would probably have been easier if Actor were using ES Classes.
Differential Revision: https://phabricator.services.mozilla.com/D94948
Add a needed top-level error boundary component to the Net Monitor panel
in DevTools, to catch errors that would otherwise render the pane blank.
Differential Revision: https://phabricator.services.mozilla.com/D91511
The panel was using the `highlighterFront` property of the nodeFront, but it was
removed in Bug 1623667, and as a result, highlighting was broken.
To be consistent with the other panels having such capabilities (console, debugger, …),
we now use the toolbox `getHighlighter` function.
This wasn't caught because there wasn't any test covering this behavior; this patch
adds one, that was failing without the fix in Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D95030
Depends on D95035
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode` and `hideBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95036
Depends on D95034
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode` and `hideBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95035
Depends on D95033
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode` and `hideBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95034
Depends on D79556
This patch is using the approach introduced in D79556 to dispatch thunks (functions) to the Redux store to show/hide the box model highlighter from individual React components instead of passing down the methods through deeply nested trees of components that don't use them.
The Redux `dispatch()` method is passed down via the component tree instead. This enables further usage of dispatching thunks for other scenarios avoiding prop drilling.
The `showBoxModelHighlighterForNode`, `hideBoxModelHighlighter` and `showBoxModelHighlighter` props and methods are removed in favor of the corresponding thunks.
Differential Revision: https://phabricator.services.mozilla.com/D95033
Traits support was added to the storage actor in FF80.
Firefox release is now FF81 so we can cleanup the related backward compatibility code.
Differential Revision: https://phabricator.services.mozilla.com/D93081
Those fixtures aren't needed anymore since the l10n module supports
Node environment.
Tests and stubs were updated accordingly so we now have the actual
properties values instead of their keys.
Depends on D94571
Differential Revision: https://phabricator.services.mozilla.com/D94572
Now that the l10n module handles node environment, we no
longer need the existing fixtures for the mocha tests.
A couple tests needed to be updated to pass.
Depends on D94570
Differential Revision: https://phabricator.services.mozilla.com/D94571
In most of our node tests (jest and mocha), we need to rely on fixtures for the
l10n modules because in its current shape, the module couldn't load the properties
files properly.
This patch fixes that by detecting if we're in a Node environment, and in such
case load the file using `readFileSync`.
We are also able to remove the specific code we had for webpack as it doesn't
seem to be used anymore.
The Spectrum.js file needed to be updated to fix the paths it was using.
Differential Revision: https://phabricator.services.mozilla.com/D94568
We have to manually call `ThreadActor#exit` as calling `destroy` won't completely
destroy it, since it does not call `Actor#destroy`, whereas `ThreadActor#exit` does.
Differential Revision: https://phabricator.services.mozilla.com/D94835
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
Depends on D94711
We might fold this in the first changeset after review.
Updated the links color of the whole panel to use a theme variable.
Used another theme variable for the button hover/active background color.
Differential Revision: https://phabricator.services.mozilla.com/D94747
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Check that when removing iframes, we're notified about the worker unregistration,
and check that the target list works as expected when we have multiple iframes
on same origin (both remote and same-origin as main document).
The test documents are modified so we can avoid spawning shared and/or service
workers (in the case of this test, this seems to prevent some memory leaks/crashes).
Differential Revision: https://phabricator.services.mozilla.com/D88769
This patch adds support for dedicated worker targets in the Watcher actor.
Shared and Service workers are not handled yet.
In a similar manner to what we already have for frame targets, we add a worker-helper
file that will communicate with a JsWindowActor pair spawned on each document,
that will manage workers (DevToolsWorkerParent/DevToolsWorkerChild).
For a given document, the DevToolsWorkerChild will enumerate the existing workers
related to it, as well as add an event listener to be notified when workers are
being registered and unregistered, and communicate that back to the DevToolsWorkerParent
on the main thread, so worker targets creation and destruction are notified by
the Watcher actor (via target-available-form and target-destroyed-form events).
When a worker is created, the DevToolsWorkerChild for the document the worker
was spawned from will create a WorkerTargetActor, that will live in the worker
thread (using worker-connector.js), passing it resources the Watcher is currently
listening for. It will also handle communication between the main thread and the
worker thread, when the watcher listen to new resources (or stop watching resources).
A WorkerTargetFront is created so the client can be notified about available
resources (via the resource-available-form event, emitted from the worker target).
Tests are added in the next patches of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D85399
This may prevent logging a few exception or error messages.
But thanks to the other patch of this bug, we should try to stop listening
for sources as soon as the thread actor is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D94484
We have to manually call `exit` as calling `destroy` won't completely destroy it.
ThreadActor.destroy do not call protocoljs.Actor.destroy, ThreadActor.exit does it.
Differential Revision: https://phabricator.services.mozilla.com/D94483
Update the SetLine / ColSpan source-notes to be relative to the script's
initial line and column number. This allows for more bytecode sharing.
Differential Revision: https://phabricator.services.mozilla.com/D94116
Update the SetLine / ColSpan source-notes to be relative to the script's
initial line and column number. This allows for more bytecode sharing.
Differential Revision: https://phabricator.services.mozilla.com/D94116
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
NOTE: Depends on D92634
This patch adds:
- A simple test for `localStorage` working on Fission
- Adapts `openTab` and `finishTests` helpers on `head.js`, that are used by all the storage mochitests.
However, by enabling the `openTab` helper to work on Fission, some tests that were previously failing early that were marked with `fail-if = fission` were finishing their setup, but _not_ their cleanup, which messed with following tests, since some of the HTML pages are shared a lot. In order to fix that, I've modified the problematic HTML pages so before doing their setup, they run their cleanup just in case. We can probably remove this once Fission is fully working.
Differential Revision: https://phabricator.services.mozilla.com/D93808
Depends on D92223
The Inspector sidebar extensions and corresponding tests have access to the Inspector client in order to access methods to invoke highlighters so there is no need for the Toolbox shortcut introduced in D92222.
Differential Revision: https://phabricator.services.mozilla.com/D92224
Depends on D92222
Update the DOM panel and tests to use the Toolbox shortcut to the highlighter introduced in D92222.
Differential Revision: https://phabricator.services.mozilla.com/D92223
Depends on D92221
The `HighlighterActor/Front` was accessed by the Debugger, Web Console and other panels via a shortcut on the Toolbox: `toolbox.getHighlighter()`. This returned two helper methods: `highlight()` and `unhighlight()` scoped to `InspectorFront.HighlighterFront` so that consumers wouldn't have to handle that instantiation themselves.
This patch keeps the shortcut on Toolbox for consumers to use, but it updates it to point to `HighlightersOverlay` on the Inspector client. That is the new Fission-ready highlighter manager which can toggle highlighters in the appropriate browsing contexts. The `highlight()` and `unhighlight()` methods are proxies for showing/hiding the Box Model Highlighter, which is the same highlighter used within the Inspector to highlight nodes.
In addition to the `highlight()` and `unhighlight()` methods, we add two more helpers to react to the show/hide events fired by this highlighter. These are now used just in tests. The reason to add these is to avoid having individual non-Inspector tests go through the trouble of instantiating the Inspector client so they can listen to events themselves, like we did in D85862.
After migrating all highlighter accessors (ex: Grid, Flexbox, Shapes) from `HighlightersOverlay` to use the new process-agnostic approach introduced in D81526, we could potentially decouple `HighlightersOverlay` from Inspector client and put it directly on the Toolbox instance. Then, this shortcut wouldn't have to instantiate an Inspector client in order to invoke highlighters. But, for now, this works and is minimally invasive. The consumers in Debugger, Web Console, etc don't have to change their call signatures.
Differential Revision: https://phabricator.services.mozilla.com/D92222
Depends on D92220
Rephrasing of code comments and cleanup of documentation to reflect that `CustomHighlighterActor` is now the only actor which deals with highlighting stuff after removing `HighlighterActor` in D92220. No functionality is changed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D92221
This patch completely removes the `HighlighterActor` and its accessors.
The rest of the patches in this commit series update the consumers and tests to use the new highlighter manager added to `HighlightersOverlay` in D81526. [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) updated all consumers within the **Inspector** panel to use this approach. Now, we're updating the rest of the consumers outside the Inspector.
### Why remove HighlighterActor?
The changes introduced in D81526 for [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) make it possible to highlight nodes using the `CustomHighligtherActor` with the **Box Model Highlighter** implementation.
The `HighlighterActor` was itself a wrapper around **Box Model Highlighter** and Simple Outline Highlighter, and exposed node picking functionality. Simple Outline Highlighter was removed with [Bug 1650094](https://bugzilla.mozilla.org/show_bug.cgi?id=1650094). The node picking functionality was decoupled from `HighlighterActor`in [Bug 1607756](https://bugzilla.mozilla.org/show_bug.cgi?id=1607756).
After those changes, `HighlighterActor` is no longer special. It can be removed in favor of a single generic actor, `CustomHighligtherActor`, with the Box Model Highlighter implementation.
Differential Revision: https://phabricator.services.mozilla.com/D92220
It looks like we are destroying the target actor immediately, without having time
to call _watchDocshells. And given that removeObserver throws if there is no matching listener
already registered, it prevent detaching the target correctly, and, introduces a leak.
Differential Revision: https://phabricator.services.mozilla.com/D94452
For now, resource watcher tests were only testing resources from a single tab.
This test targets the main process, like the browser toolbox and so will listen to all targets,
including content process targets.
Differential Revision: https://phabricator.services.mozilla.com/D93734
Before, targets were created on-demand, from the frontend, by calling ProcessDescriptor.getTarget
when the root actor informed the frontend of a creation of a content process via processListChanged event
and the notification of a new ProcessDescriptor.
This previous behavior was making so that the target actor was created very late and did not allow
recording for resources (console messages for ex), nor setting breakpoints very early during the process startup.
With this new implementation, the watcher actor allows knowing if the frontend cares about content process target or not.
We should only create these targets if the browser toolbox is opened, and typically not if we are only debugging a tab via a regular web toolbox.
We do that via WatcherActor.watchTarget and sharedData object.
content-process-script.js is loaded in all processes. Process script are loaded quite early during process startup.
Soonish after `sharedData` is passed to the content process.
So that it is hopefully executed before most privileged javascript runs.
Javascript code where we possibly want to debug/observe/set a breakpoint on.
This setup allows us to create the Content Process Target actor much earlier than the previous setup.
When created, the target actor immediately start listening for resources (console message and others) via its `addWatcherDataEntry` method.
In a near future, breakpoints will also be set via this method.
We should also followup to use something else than Process Script and sharedData
in order to create the target earlier, before any JS runs.
Differential Revision: https://phabricator.services.mozilla.com/D65529
For now, we were emitting the "tabDetached" event on message-manager-close (=process shutdown),
or when the DevToolsServerConnection closes (=client closes the connection).
But not when the target is being destroyed by the frontend when calling ResourceWatcher.unwatchTargets,
which is calling process-helper's destroyTargets.
This was introducing test failure (browser_target_list_watchTargets.js) with never resolving RDP requests.
Differential Revision: https://phabricator.services.mozilla.com/D91559
The two functions we were using, makeBundle and copyFile, were simple
enough so we could directly inline them in the script.
The task run as before, but for some reason the order of some modules
changed in the resulting bundles.
Differential Revision: https://phabricator.services.mozilla.com/D94108
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
The regression was caused because it incorrectly started treating user
stylesheets as "system" sheets, which can't be modified.
Fix the regression by properly using SharedCssLogic.isAgentStylesheet
instead.
Also fix the check for whether chrome rules apply to handle user
stylesheets and inline style attributes in chrome documents correctly,
see the comment.
Differential Revision: https://phabricator.services.mozilla.com/D93088
We weren't waiting for assertion function to be evaluated in the console.
This can later lead to ok/is functions being undefined when calling Toolbox.spawn.
Differential Revision: https://phabricator.services.mozilla.com/D94279
NOTE: Depends on D92634
This patch adds:
- A simple test for `localStorage` working on Fission
- Adapts `openTab` and `finishTests` helpers on `head.js`, that are used by all the storage mochitests.
However, by enabling the `openTab` helper to work on Fission, some tests that were previously failing early that were marked with `fail-if = fission` were finishing their setup, but _not_ their cleanup, which messed with following tests, since some of the HTML pages are shared a lot. In order to fix that, I've modified the problematic HTML pages so before doing their setup, they run their cleanup just in case. We can probably remove this once Fission is fully working.
Differential Revision: https://phabricator.services.mozilla.com/D93808
It's not 100% clear how long this command will live, but it doesn't look
immediately removable, and it was easy to add python3 support.
Differential Revision: https://phabricator.services.mozilla.com/D94179
`boostrapApp` had a check for supporting the Launchpad, that we can now remove.
And since `renderPanel` is only called from there, we can safely inline it.
Differential Revision: https://phabricator.services.mozilla.com/D94083
Depends on D93817
There should no longer be new message managers during the lifecycle of the actor.
We can simplify the storage actor thanks to this.
Differential Revision: https://phabricator.services.mozilla.com/D93819
Depends on D93817
There should no longer be new message managers during the lifecycle of the actor.
We can simplify the storage actor thanks to this.
Differential Revision: https://phabricator.services.mozilla.com/D93819
Depends on D92223
The Inspector sidebar extensions and corresponding tests have access to the Inspector client in order to access methods to invoke highlighters so there is no need for the Toolbox shortcut introduced in D92222.
Differential Revision: https://phabricator.services.mozilla.com/D92224
Depends on D92222
Update the DOM panel and tests to use the Toolbox shortcut to the highlighter introduced in D92222.
Differential Revision: https://phabricator.services.mozilla.com/D92223
Depends on D92221
The `HighlighterActor/Front` was accessed by the Debugger, Web Console and other panels via a shortcut on the Toolbox: `toolbox.getHighlighter()`. This returned two helper methods: `highlight()` and `unhighlight()` scoped to `InspectorFront.HighlighterFront` so that consumers wouldn't have to handle that instantiation themselves.
This patch keeps the shortcut on Toolbox for consumers to use, but it updates it to point to `HighlightersOverlay` on the Inspector client. That is the new Fission-ready highlighter manager which can toggle highlighters in the appropriate browsing contexts. The `highlight()` and `unhighlight()` methods are proxies for showing/hiding the Box Model Highlighter, which is the same highlighter used within the Inspector to highlight nodes.
In addition to the `highlight()` and `unhighlight()` methods, we add two more helpers to react to the show/hide events fired by this highlighter. These are now used just in tests. The reason to add these is to avoid having individual non-Inspector tests go through the trouble of instantiating the Inspector client so they can listen to events themselves, like we did in D85862.
After migrating all highlighter accessors (ex: Grid, Flexbox, Shapes) from `HighlightersOverlay` to use the new process-agnostic approach introduced in D81526, we could potentially decouple `HighlightersOverlay` from Inspector client and put it directly on the Toolbox instance. Then, this shortcut wouldn't have to instantiate an Inspector client in order to invoke highlighters. But, for now, this works and is minimally invasive. The consumers in Debugger, Web Console, etc don't have to change their call signatures.
Differential Revision: https://phabricator.services.mozilla.com/D92222
Depends on D92220
Rephrasing of code comments and cleanup of documentation to reflect that `CustomHighlighterActor` is now the only actor which deals with highlighting stuff after removing `HighlighterActor` in D92220. No functionality is changed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D92221
This patch completely removes the `HighlighterActor` and its accessors.
The rest of the patches in this commit series update the consumers and tests to use the new highlighter manager added to `HighlightersOverlay` in D81526. [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) updated all consumers within the **Inspector** panel to use this approach. Now, we're updating the rest of the consumers outside the Inspector.
### Why remove HighlighterActor?
The changes introduced in D81526 for [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) make it possible to highlight nodes using the `CustomHighligtherActor` with the **Box Model Highlighter** implementation.
The `HighlighterActor` was itself a wrapper around **Box Model Highlighter** and Simple Outline Highlighter, and exposed node picking functionality. Simple Outline Highlighter was removed with [Bug 1650094](https://bugzilla.mozilla.org/show_bug.cgi?id=1650094). The node picking functionality was decoupled from `HighlighterActor`in [Bug 1607756](https://bugzilla.mozilla.org/show_bug.cgi?id=1607756).
After those changes, `HighlighterActor` is no longer special. It can be removed in favor of a single generic actor, `CustomHighligtherActor`, with the Box Model Highlighter implementation.
Differential Revision: https://phabricator.services.mozilla.com/D92220
`boostrapApp` had a check for supporting the Launchpad, that we can now remove.
And since `renderPanel` is only called from there, we can safely inline it.
Differential Revision: https://phabricator.services.mozilla.com/D94083
This is a test for the bug fix that landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1671959
A new test is added, forked from devtools/client/framework/test/browser_toolbox_window_reload_target.js
Most of the testReload helper from the original test is moved to the head.js of the folder.
The new test relies on a simple sjs file which simply prints the value of the cache-control header.
Differential Revision: https://phabricator.services.mozilla.com/D94041
Check that when removing iframes, we're notified about the worker unregistration,
and check that the target list works as expected when we have multiple iframes
on same origin (both remote and same-origin as main document).
Differential Revision: https://phabricator.services.mozilla.com/D88769
This patch adds support for dedicated worker targets in the Watcher actor.
Shared and Service workers are not handled yet.
In a similar manner to what we already have for frame targets, we add a worker-helper
file that will communicate with a JsWindowActor pair spawned on each document,
that will manage workers (DevToolsWorkerParent/DevToolsWorkerChild).
For a given document, the DevToolsWorkerChild will enumerate the existing workers
related to it, as well as add an event listener to be notified when workers are
being registered and unregistered, and communicate that back to the DevToolsWorkerParent
on the main thread, so worker targets creation and destruction are notified by
the Watcher actor (via target-available-form and target-destroyed-form events).
When a worker is created, the DevToolsWorkerChild for the document the worker
was spawned from will create a WorkerTargetActor, that will live in the worker
thread (using worker-connector.js), passing it resources the Watcher is currently
listening for. It will also handle communication between the main thread and the
worker thread, when the watcher listen to new resources (or stop watching resources).
A WorkerTargetFront is created so the client can be notified about available
resources (via the resource-available-form event, emitted from the worker target).
Tests are added in the next patches of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D85399
There was an image folder, relic of an ancient time where
we needed to support the launchpad. We don't use those images anymore,
so the folder is removed.
The remaining files in the tset folder weren't used, so we remove
this folder as well.
Finally, there was a redux middleware folder, containing a thunk
and a waituntilService middleware. Those 2 modules already exist
in the codebase, so we can use those from the test that were using
the reps-specific version (with little adjustments).
This marks the end of the work for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D93488
This turns all the existing reps modules into AMD modules,
so they can be loaded in the JSON Viewer without trouble.
This means we had to change the test configuration so Reps
jest test can run.
Differential Revision: https://phabricator.services.mozilla.com/D93394
This allows the jest tests for the shared components to be run in the devtools-node task.
For some reason, the snapshots needed to be updated (it looked like we were
missing some bits?).
Differential Revision: https://phabricator.services.mozilla.com/D93376
The file should now only impact reps, and not mention ObjectInspector or Tree.
The ObjectInspector.css and Tree.css files are added into jar.mn.
Panels using the object inspector component (console and debugger), need to import
all 3 css files, while panels only using reps benefit from a lighter reps.css file.
Differential Revision: https://phabricator.services.mozilla.com/D93374
We should only assert `updates` attribute on resource-updated,
as we aren't guaranteed how many updates we will have in resource-available.
That's because of resource throttling. Updates may be coalesced into available,
but we can't predict how many.
Differential Revision: https://phabricator.services.mozilla.com/D93337
This test was failing on Beta because we are using the targetList to wait for
a given source to be available, in order to avoid pending connection to the
server (that were happening when the targetList was trying to attach the thread
of the target), but on Beta, for the browser console, we don't listen for anything
with the targetList if the Browser Toolbox fission pref is disabled.
To fix the test, we check the pref and wait for the target only if it's enabled.
Differential Revision: https://phabricator.services.mozilla.com/D92877
This test was using the browser console targetList to wait for a specific worker
target to be available. This was failing on Beta because for the Browser Console,
we only listen for workers if the browser toolbox fission pref is enabled, which
is the case on Nightly, but not on Beta.
To fix the test, we check the pref and wait for the target only if it's enabled.
Differential Revision: https://phabricator.services.mozilla.com/D92876
This test perma fails on Fission since session-history-in-parent was enabled.
The test asserts workers retrieved from BrowsingContext targets as follows:
- go to page1, check we can get worker1
- go to page2, check we can get worker2
- go back to page1, check we can get worker1
On the last step, after navigating back, we are unable to retrieve the worker1 on page1
Differential Revision: https://phabricator.services.mozilla.com/D93251
Merge `thunk-with-options` behavior directly into `thunk`, update `thunk` and `thunk-with-options` callsites and finally remove now unused `thunk-with-options` (as well as netmonitor's own `thunk`)
Depends on D92888
Differential Revision: https://phabricator.services.mozilla.com/D93195
In short, thunk actions are changing from a signature with 2 parameters (dispatch and getState): `(dispatch, getState)`, to an object that contains those properties: `({ dispatch, getState })`.
This is done so we can merge thunk and thunk-with-options
Differential Revision: https://phabricator.services.mozilla.com/D92888
Depends on D92756
Detach errors can happen when a target is being destroyed.
Historically, those errors were swallowed in the TargetFront mixin.
However this logic became outdated when we started purging requests during Front::destroy.
This results in non-actionable error messages logged frequently while using DevTools.
This changeset updates the logic in target-mixin.js in order to swallow errors due to purged requests.
Differential Revision: https://phabricator.services.mozilla.com/D92757
Depends on D93030
All Front requests are purged before the Front is destroyed.
In theory there is no reason to process packets after the Front has been destroyed.
It will only create cryptic error messages.
Differential Revision: https://phabricator.services.mozilla.com/D92756
Depends on D93029
Emitting "forwardingCancelled" will result in purging requests on the target front, which almost equates to destroying the front.
We should emit the "tabDetached" event before that to avoid emitting events on already destroyed fronts.
Differential Revision: https://phabricator.services.mozilla.com/D93030
Emitting "forwardingCancelled" will result in purging requests on the target front, which almost equates to destroying the front.
We should emit the "tabDetached" event before that to avoid emitting events on already destroyed fronts.
Differential Revision: https://phabricator.services.mozilla.com/D93029
When a navigation message is added into the store, reset the currentGroup property
This adds a test to ensure the fix works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D92778
Bug 1440068 - Fix filtering on console groups.
implement more thorough check of collapsed group messages
expand test suite
Differential Revision: https://phabricator.services.mozilla.com/D91065
When a page is refreshed, the inspector fonts associated with targets within are destroyed and recreated.
The node picker didn't observe for this behavior. When a page was refreshed, it kept picking against dead fronts and ignored the newly created fronts, thus leaving users confused. This is an issue in popular web dev workflows like Hot Module Reloading, where the page may end up being refreshed. See [Bug1352121#c4](https://bugzilla.mozilla.org/show_bug.cgi?id=1352121#c4)
This patch makes the node picker listen for targets and inspector fronts as they become available or get destroyed. If node picking isn't explicitly stopped by either clicking a node or pressing the Escape key, node picking continues onto the refreshed page or to new page (same behavior as in Firefox Release).
Differential Revision: https://phabricator.services.mozilla.com/D92779
This is a timing test that includes checks on whether an event happened "fast
enough". Those checks are too hard to dial in between short enough to be
relevant and long enough to ensure it's never intermittent. This change takes
them out while preserving the rest of the test, including the checks that some
events happen after a "slow enough" delay.
Differential Revision: https://phabricator.services.mozilla.com/D92954
Remote debugging in those method names and comments refered to e10s.
Nowadays remote debugging is rather used to talk about remote "browser" debugging, via about:debugging.
The comments give the false impression that those events are only used for about:debugging, which is not true.
Differential Revision: https://phabricator.services.mozilla.com/D93063
When a page is refreshed, the inspector fonts associated with targets within are destroyed and recreated.
The node picker didn't observe for this behavior. When a page was refreshed, it kept picking against dead fronts and ignored the newly created fronts, thus leaving users confused. This is an issue in popular web dev workflows like Hot Module Reloading, where the page may end up being refreshed. See [Bug1352121#c4](https://bugzilla.mozilla.org/show_bug.cgi?id=1352121#c4)
This patch makes the node picker listen for targets and inspector fronts as they become available or get destroyed. If node picking isn't explicitly stopped by either clicking a node or pressing the Escape key, node picking continues onto the refreshed page or to new page (same behavior as in Firefox Release).
Differential Revision: https://phabricator.services.mozilla.com/D92779
The WebConsoleActor tries to destroy it via a debug:destroy-network-monitor.
But as it is done during the destruction of the target actor, typically when there is a
top level target switching, this message doesn't reach the parent process.
So, ensure destroying this actor from the parent process side, when we see that the
frame target is being destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D92654
- Rename `id` to a more explicit `forwardingPrefix` property
- Add comments to why we need to handle a list of connections
- Remove the `rpcs` property from the connections object
- Turn `rpcDeferred` from an array to an object, as it's used like one.
Differential Revision: https://phabricator.services.mozilla.com/D92752
When requesting a highlighter instance, the inspector front returns one from its cache if present, otherwise it sends a request to the server create a new one.
But if multiple requests come in very quickly before the server responds to the original request, the cache is still empty so the front fires a few more requests. How many? It's arbitrary. As many as fit before the original request's promise resolves and the cache is set. This is the root cause for the issue of seeing duplicate highlighters.
The issue is more pronounced when there is congestion: many microtasks in the queue, for example when loading a heavy tool like the Inspector on a complex page.
To solve this, we store the unsettled promise to create a highlighter and explicitly wait for it to resolve while ignoring subsequent requests.
Differential Revision: https://phabricator.services.mozilla.com/D92802
Depends on D92499
Tweak an existing mock in the main process about:debugging test to check that we are not creating any target.
Differential Revision: https://phabricator.services.mozilla.com/D92553
This changeset focuses on dependencies, but surprisingly, it has an impact on bundles.
Looks like one dependency uses another revision.
Differential Revision: https://phabricator.services.mozilla.com/D92736
This changeset focus on devDependencies, but a similar work can probably be done on dependencies.
Many dependencies are justifies solely because of jest.
In order to run flow, we only need flow, and we need very few things for bin/bundle.
For me, the three things to keep working are:
* flow
* jest
* bin/bundle to rebuild vendors, reps, worker modules
The debugger frontend itself (src/ folder) is built without involving yarn/package.json.
Differential Revision: https://phabricator.services.mozilla.com/D92735