1873250 - [meta] Add worker support to MessageHandler framework

Status: NEW

(Remote Protocol :: WebDriver BiDi, task)

Description

[Julian Descottes [:jdescottes]]

MessageHandler currently only supports debugging windowglobal contexts.

In order to support worker contexts, we will need the following:

• new transport class to handle communication between the ParentProcess and a WorkerThread. Note that the worker thread might live in a content process, so we most likely need a transport that will first use a JSActor (JSProcessActor most likely) to communicate from parent to content, and then another transport to go from content process main thread to content process worker thread. For this last step, DevTools is currently using nsIWorkerDebugger which exposes an initialize method to load a script in a worker thread.
• a WorkerMessageHandler class which will have the same role as the WindowGlobalMessageHandler but for workers
• modules which can run in worker scope (with constraints such as no ChromeUtils support). For the most part, DevTools reuses the same actor code between windowglobal targets and worker targets, but has if statements to disable some features in worker scope (+ fallback when an API is missing). The way the MessageHandler framework is designed doesn't really encourage this, because worker modules should live in a modules/worker folder, while windowglobal ones are in modules/windowglobal. But we can still share code in other ways (inheritance, helpers, etc...)

In a first step, we can just create WorkerMessageHandlers on demand, when we receive a command which targets a specific worker.
In a second step, we need to add support for SessionData, meaning that we should watch for new workers and create MessageHandlers instances as early as possible to subscribe to events etc...