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
Ben Delevingne
Csoregi Natalia
Nicolas Chevobbe
Alexandre Poirot
Daisuke Akatsuka
Jan Odvarko
Narcis Beleuzu
Julian Descottes
JulianWels
Mihai Alexandru Michis
Razvan Maries
Andreea Pavel