Bugzilla

Similarly to bug 1593937 and bug 1620248, which will help creating the BrowsingContextTargetActor before the process or document starts loading, we should do the same with WorkerTargetActor.
We should use the new watchTargets API on the actor side and do what is necessary on the server codebase to spawn the WorkerTargetActor the earliest. Then, the created targets will be notified to the frontend via the TargetList API.

Similarly to bug 1593937 and bug 1620248, which will help creating the BrowsingContextTargetActor before the process or document starts loading, we should do the same with WorkerTargetActor.

We should introduce a "worker target helper" over here:
https://searchfox.org/mozilla-central/source/devtools/server/actors/descriptors/watcher/target-helpers/
Which exposes 4 methods:
* createTargets
* destroyTargets
* watchResources
* unwatchResources
The `createTargets` and `destroyTargets` should create and destroy the Worker Targets for the worker that already exists.
`watchResources` and `unwatchResources` should communicate the new watched/unwatched resources for all existing worker targets.

In parallel to that, we should have some code, which would watch all:
* new worker being created and call [WatcherActor.notifyTargetCreated](https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/devtools/server/actors/descriptors/watcher/watcher.js#138)
* workers that have been destroyed and call [WatcherActor.notifyTargetDestroyed](https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/devtools/server/actors/descriptors/watcher/watcher.js#142-147)
We might have to hook up into [WatcherRegistry](https://searchfox.org/mozilla-central/source/devtools/server/actors/descriptors/watcher/WatcherRegistry.jsm) in order to register/unregister this "worker watching" code. Similarly to how we register/unregister the DevToolsFrame JSWindow Actor. (Or see my other approach for content process target, `maybeRegisterMessageListeners` in [this patch](https://phabricator.services.mozilla.com/D65529?vs=on&id=290273#toc))

The goal here would be to start by only supporting Tab Target. So only when `WatcherActor._browser`/`WatcherActor.browsingContextID` are set. And so only when we focus on just one BrowsingContext. Supporting the browser toolbox means having to inspect all the processes, while for one tab, we can focus on just one process at a time. (We may support navigation to another process in a followup)

Compared to the current implementation, using legacy listeners and `TabTarget.listWorkers`, here, we should avoid involving TabTarget/BrowsingContextTargetActor. We might have to introduce a new JS Window Actor, or reuse DevToolsFrame JS Window Actor (if relevant).

You might want to contribute to the existing TargetList test specific to Worker targets:
https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/devtools/shared/resources/tests/browser_target_list_workers.js#190-234
In order to support more usecases:
* destruction
* workers created after the call to watchTargets
* may be have two distinct test files? One for BrowserToolbox codepath and another one for Tabs?

Last but not list, a quick note about the existing codebase.
The code watching for new workers and workers being destroyed should be inspired from [WorkerTargetActorList](https://searchfox.org/mozilla-central/source/devtools/server/actors/worker/worker-target-actor-list.js).
* `matchWorkerDebugger` should be tweaked to check WatcherActor's BrowsingContextID instead of window.
* WorkerPauser should be kept until we address bug 1573327
WorkerPauser is actually including a very important bit that is a bit convoluted and not very well known.
[Right here](https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/devtools/server/actors/worker/worker-target-actor-list.js#87-89), on every Worker instantiation, we pause the worker immediately, from the main thread, preventing it to run anything. And much later on, [there](https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/devtools/server/connectors/worker-connector.js#40), we resume it, still from the main thread. But the path between these two callsites is convoluted!
1) the worker just get created and we immediately call worker.setDebuggerReady(false), this is done by WorkerPauser
2) Completely independently of that, we start creating the WorkerTargetActor, on demand, via listWorkers and WorkerTargetActorList
3) We use WorkerConnector to create the WorkerTargetActor from the Worker thread
4) The frontend receive the worker target
5) The frontend attach the ThreadActor
6) [Some magic code](https://searchfox.org/mozilla-central/source/devtools/server/startup/worker.js#105) from the worker thread notify the main thread that the Thread Actor is attached
7) [Some other magic code](https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/devtools/server/connectors/worker-connector.js#37-41) in the main thread receive this message and resume the worker

All this "magic" (complexity) relates to bug 1573327 as it will allow to pass the breakpoint to the Watcher Actor, and stop having to freeze the worker untils ThreadActor.attach is called. Today, we pass the breakpoint via this thread actor method. We will pass the breakpoints as we pass the "watched resource types" to all processes and threads.