1944240 - Adapting DevTool WorkerDebugger with RemoteWorkerDebugger mechanism in the parent process

Status: NEW

(Core :: DOM: Workers, enhancement, P1)

Description

[Eden Chuang[:edenchuang]]

In bug 1899503, we provide a RemoteWorkerDebugger mechanism in the parent process. Therefore, to get rid of the local WorkerDebugger, we need to adapt the Devtool codes with RemoteWorkerDebugger.

Comment 1

[Alexandre Poirot [:ochameau]]

May be someone from devtools should be involved in this change?
Or do you expect to keep having things to tweak in WorkerDebugger c++ code?

Comment 2

[Eden Chuang[:edenchuang]]

Attachment: WIP: Bug 1944240 - P1 Instead of using RemoteWorkerDebugger, directly using WorkerDebuggerManager/WorkerDebugger for Workers in parent process. r=asuth

Comment 3

[Julian Descottes [:jdescottes]]

Hi Eden, I wanted to use the new parent process worker debugger manager to monitor all worker debugger register/unregister for WebDriver BiDi (Bug 1936766). I imagine this bug is required before we can get notifications about content process web workers from the parent process?

Could I try to rebase your patch and finish the work here - and do you have a rough idea of what else is needed beyond what you already did?

(In case that's important/relevant, at the moment I only need to create events to notify about the creation/destruction of worker realms)

Comment 4

[Julian Descottes [:jdescottes]]

Looking at the patch, I'm also not sure whether we can be in a situation where DevTools would keep using their legacy implementation listening and debugging workers from content process main thread, and WebDriver BiDi could use the new setup from the parent process, or if we need to migrate all at once?

Comment 5

[Eden Chuang[:edenchuang]]

Sorry for the late response. I would not suggest using RemoteWorkerDebugger for WebDriver BiDi only. The problem is that, in some situations, RemoteWorkerDebugger cannot coexist with WorkerDebugger. However, there is still work to be done to adapt DevTool to RemoteWorkerDebugger. Especially, what Devtool does in the content process main thread should move to the parent process main thread.

I am not sure if it is possible to make WebDriver Bidi using Devtool's legacy implementation to get Worker realm creation/destruction. If you only need the Worker realm related notifications, I guess it should be doable. And I will integrate them to RemoteWorkerDebugger.

Comment 6

[Julian Descottes [:jdescottes]]

(In reply to Eden Chuang[:edenchuang] from comment #5)

Sorry for the late response. I would not suggest using RemoteWorkerDebugger for WebDriver BiDi only. The problem is that, in some situations, RemoteWorkerDebugger cannot coexist with WorkerDebugger. However, there is still work to be done to adapt DevTool to RemoteWorkerDebugger. Especially, what Devtool does in the content process main thread should move to the parent process main thread.

I am not sure if it is possible to make WebDriver Bidi using Devtool's legacy implementation to get Worker realm creation/destruction. If you only need the Worker realm related notifications, I guess it should be doable. And I will integrate them to RemoteWorkerDebugger.

Alright thanks for the clarification!

I had an implementation a while ago for WebDriver BiDi which was working with the WorkerDebugger, so that should be fine for now. I will just spawn my listeners in content processes via JSProcessActors and forward the events to the parent process. We already have similar patterns for other events. Should be sufficient for now.

The other main feature we want to implement for workers in BiDi is to be able to evaluate script (Bug 1936776). Without going into too much details, enabling this with the current WorkerDebugger setup would have a bigger architecture impact and will probably make the migration to RemoteWorkerDebugger more costly. It's not planned for Q1 2026, but it is a candidate for Q2. I will block this work on this bug, let me know if I can help with the migration in any shape or form.

Comment 7

[Eden Chuang[:edenchuang]]

Got it, I will try to make RemoteWorkerDebugger workable in Q1.

Comment 8

[Julian Descottes [:jdescottes]]

For info, I landed all work planned for Q1 for worker support in BiDi. For script evaluation (Q2) I'm holding off to see if this bug can be resolved first, but until then I will not be adding any more usage of the legacy WorkerDebugger.

Comment 9

[Julian Descottes [:jdescottes]]

Hi Eden,

We're starting planning for our next milestone (Q2) so I'm checking if we can pick up additional worker-related items. Do you think this can be done in Q1, and can we help in any way (maybe we can pick up this bug with some mentoring?)

Thanks!