There is some documentation in devtools/docs/backend/actor-hierarchy.md about how fronts are organized, but this only pertains to the root and targets and not the child thread, node, object, etc. fronts that client code is normally working with. Similar documentation for these other fronts does not seem to exist elsewhere. Documenting child fronts in this file, at least for the most commonly used fronts, would help a lot with understanding how this critical portion of the devtools is organized.

More than documentation is needed, however. Front ownership is not very carefully managed, and can lead to issues like the one fixed in bug 1571863 part 1, where the fact that source fronts were not marked with an owner prevented them from being torn down when the associated thread was detached. Lifetime management is one of the main runtime benefits that a well organized front hierarchy provides. Another is an identity guarantee for the client: it shouldn't be possible to create different fronts in a toolbox for the same piece of content, by using different owning fronts or targets for that content. Establishing this property helps devtools interoperate with each other and maintain the internal consistency of their state.

The front ownership hierarchy is especially important to establish in light of bug 1597255. With the requirements described in that bug, we'll want a single thread front for each process main thread which manages the JS state in that process --- frames, sources, objects, etc. With the current and planned architecture, toolboxes will use browsing context target fronts for accessing the DOM nodes and other state under the associated browsing context. If there are multiple browsing context target fronts for a process running in a tab, these targets can be different from the target used to manage JS state in the process, and server code which needs to interconvert between DOM and JS state (e.g. getting the DOM node for a JS object, or vice versa) needs to reach between actors associated with different targets. I don't think protocol.js supports this currently and this functionality might need to be added.

An option which would avoid this difficulty would be to use a single target actor in the toolbox for each process, and have fronts living under it for each browsing context that can manage the state associated with those browsing contexts. I like this option personally, but making such a change would be pretty disruptive to how the devtools are organized, and this is probably best to consider at a later date when things have settled down.

Regardless, establishing and then documenting the front hierarchy as it stands right now will help a lot in making such architectural changes in the future.

Tracking Fission DevTools bugs for Fission Nightly (M6)

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.

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.

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

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

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:ochameau, maybe it's time to close this bug?