Bugzilla

We might want to keep on drawing highlighters inside the top document, so they can be drawn over the entire content area (rather than be limited to an iframe's boundaries).

However all highlighters get references to DOM nodes that may live in any frame, including out-of-process frames, and these highlighters need to access these nodes to (most of the time) measure them.

Server-side cross-process communication seems required here, as the DevTools client only uses a dumb highlighter API (show/hide).

Taking the example of the box-model highlighter:
This highlighter does only one thing with the highlighted node: getting its quads.
The quads is a plain object that can easily be serialized.
We could target the highlighter actor in the process where the DOM node exists so we can access it directly and get its quads, and then serialize this data and pass it up the tree up to the parent process for the highlighter that lives there to draw itself.
So splitting highlighters in 2 parts might make this easier: the first part that would be responsible for any part of the code that needs access to the DOM node, the second part that actually renders the highlighter, but that takes some sort of data about the node.
This could be done in 2 requests: first request to a new NodeActor method like getQuads and then second request to the top-level highlighter with the result to this. Will be causing performance regressions, especially when remote debugging or on low-end devices.

The main problem to solve here is that all of the DevTools highlighters get references to DOM nodes that may live in any frame, including out-of-process frames.
Highlighters need direct access to those DOM nodes in order to find their coordinates, measure them and respond to changes (if a node's position or size is animated for example).

Some form of server-side cross-process communication seems required here. Indeed the DevTools client only uses a very simple highlighter API (show/hide) and lets the server do the heavy lifting.

*Solution 1: Make the client do more work*

We could split the highlighter code in 2 parts: the first part would be responsible for accessing to the DOM node, finding its coordinates, etc. and then serializing this information. The second part would actually render the highlighter using this data.
This would be done in 2 requests: a first request to to get the data about the node (request sent to an actor living in the same process as the node), and then upon receiving the response, a second request to the highlighter to draw. 
The highlighter actor would live in the top-level content process, so it can keep on drawing over the entire page.

This would probably be really bad for performance, especially when debugging remote devices.
Most highlighters today try to "follow" the node when it moves around. This solution would introduce a noticeable lag.

*Solution 2: Make the server do this work*

Like today, we would send the request to draw the highlighter to the top-level content process.
The highlighter actor would then cross process boundaries by using whatever Fission message passing API exists to get the data required to draw the node from whatever content process it lives in.

This would probably be better in terms of performance, and has the advantage of living the client-side code untouched.
However this is probably a no-go in terms of security (content processes talking to other content processes).

*Solution 3: escaping the clipping that happens at the graphics level*

To be investigated, I'm not sure there is a way to do this.
Here we would always draw the highlighters in the process where the dom node they are highlighting live. So if we're trying to highlight a node that lives in an oop iframe, then we'd send the request to that iframe only.
And then we'd work with the layout and graphics engine people to find out whether it would be possible to not clip our special highlighter content but draw it on the entire content area.
Unlikely to be feasible, but I'm listing this for the sake of completeness.

This would be ideal for DevTools because we wouldn't change either the client or server code much. The only part that would change is the drawing offset code we add today to account for iframes and such.

*Solution 4: Drawing in the parent process instead*

In a way, this is going back to how highlighters used to work maybe 5 years ago.
Our highlighters code would live in the parent process (not the content process) and would draw there. That means finding a place in the browser UI markup to insert the DOM used to draw.
DevTools would send a request to whatever content process the DOM node lives in, and that process would send an IPC message to the parent process (communication between content process and parent process is totally OK). That message would contain enough information about the node for a highlighter to draw itself.
More messages would be sent in case of animations, reflows and what not.
The highlighter would just wait for these messages and draw itself in the parent process.

Performance should likely not be too much of an issue here.