1597255 - [meta] Ensure that toolboxes only use one thread front per machine thread

Status: NEW

(DevTools :: Framework, task, P3)

Description

[Brian Hackett [Laid off!]]

Right now, when the OBT interacts with a tab, targets for the tab's process are created in multiple ways. When the inspector accesses DOM content in the tab, it uses browsing context target fronts, and when the debugger accesses JS content in the tab, it uses content process targets. From what I understand per conversations in slack, the plan is to stop using content process targets for the latter, except when exposing content with no associated window like chrome sandboxes. (I haven't been able to find a bug stating this explicitly though, maybe bug 1565197 is the closest?)

When a toolbox is using multiple browsing context targets to interact with content that is running in the same process, it is not appropriate to create thread fronts for those targets. If the toolbox has multiple thread fronts for actors that are running on the same machine thread, it cannot control those thread fronts independently.

Suppose thread fronts A and B are for the main thread of the same process. If front A pauses, then front B runs some code and pauses as well, it is impossible to unpause front A without also unpausing front B --- the stack on the server will contain code associated with front A, then a nested event loop, then code associated with front B, then another nested event loop, and these have to be popped in the order they were pushed.

Handling this in the toolbox client would add a lot of complexity if we want to provide a consistent debugging experience for users. It is much better if this situation cannot arise in the first place, which will be the case if there is only one thread front created by the toolbox for each process main thread. As far as I can tell, this is the current situation; the OBT does not seem to try to interact with thread fronts for the browsing context targets, so they don't get created. We should make sure it stays the situation though as architectural changes are made to the devtools, and hopefully by adding runtime checks that ensure we don't create multiple thread fronts for the same process main thread.

Comment 1

[Chris Peterson [:cpeterson]]

Tracking Fission DevTools bugs for Fission Nightly (M6)

Comment 2

[Chris Peterson [:cpeterson]]

Adding dt-fission whiteboard tag to DevTools bugs that mention Fission or block Fission meta bugs but don't already have a dt-fission whiteboard tag.

Comment 3

[Chris Peterson [:cpeterson]]

Moving these DevTools Fission bugs from Fission's old M6 Nightly milestone to M7 Beta. I am assuming these bugs would have the dt-fission-m2-mvp whiteboard tag if they were Fission Nightly blockers.

Comment 4

[Neha Kochar [:neha]]

Bulk change of all bugs with whiteboard tag of dt-fission to Fission MVP milestone.

Comment 5

[Chris Peterson [:cpeterson]]

Moving old "dt-fission" bugs to "dt-fission-future" because they don't block Fission MVP.