In bug 1572651 we put in place a new architecture for rendering DevTools highlighters in the inspected page that is compatible with Fission.
Specifically, we extracted all of the highlighter rendering logic from the content process so that part would only measure the DOM nodes to be highlighted. We moved all of the rendering logic into Firefox's parent process.

How will this work with GeckoView-based software?
In Firefox desktop, we create an iframe, give it a class of devtools-highlighter-renderer and append it inside the browser.xhtml DOM structure as a child of the .browserStack element.

GeckoView does not have a browser.xhtml file, and the DOM structure that it uses for its UI is different from the Firefox desktop one. So we need to do some work for the new parent-process renderers to work there too.

The good thing is that GeckoView has a similar process structure as Firefox desktop in that there is also a parent process where the UI runs.
The file named geckoview.xul is the equivalent of Firefox's browser.xhtml. It is basically just <window><browser/></window> with some JS. It can probably be converted to html fairly easily too if that's needed.

The main difference from desktop is there is no tabbed browser. There are as many windows as there are tabs.

:snorp is the right person to talk to to learn more about GeckoView's architecture.

Here are the relevant files:

• geckoview.xul
• geckoview.js (in particular the startup, createBrowser and ModuleManager.init functions are of interest to see how the <browser> XUL element gets created).

Tracking Fission DevTools bugs for Fission Nightly (M6)

dt-fission-m2-reserve bugs do not need to block Fission Nightly (M6). For now, let's track them for Fission riding the trains to Beta (M7) so we revisit these bugs before we ship Fission.

Bulk move of all dt-fission-m2-reserve bugs to Fission MVP milestone.

We've taken a different approach with Bug 1646028 whereby we keep highlighters rendering in the content process in their respective frames and reconcile which one is visible on the client.

This obsoletes all bugs required to make highlighters work in the parent process and cross-process communication.