After bug 916443 lands (remote highlighter), the next big refactor will be to make it compatible with e10s. e10s is a new challenge for the highlighter in the sense that the child process hosting the inspected webpage doesn't have an accessible browser parentNode that can be used to append the highlighter XUL markup to. Messages will need to be used to ask the parent process (containing the main UI) to append the highlighter and draw it where it needs to. With e10s, theoretically, the devtools UI toolbox should live in the parent process while the debugger server will be in the child process, meaning that it should fairly easy to send messages from the highlighter actor back to the toolbox so that the highlighter can be attached. However, there's a catch, in remote debugging mode, the toolbox UI doesn't live in the parent process, it lives in a distant (via TCP) browser. So a way to overcome this would be to have a "highlighter" event listener at tabbrowser.xml level which would simply load a devtools script that would take it from there. Of course, this is assuming the current, XUL-based, highlighter is kept. The other option is to draw the highlighter regions at gecko level directly, which would make this bug irrelevant and would also have the nice benefit of making the highlighter look the same across all devices.
From highlighter.js, it'll be easy enough to move the BoxModelHighlighter class to another file. Then the showBoxModel and pick actor methods will need to send events via the message manager.
Duplicate of bug 985597 which is where the real work has already started to happen for the e10s highlighter.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 985597
You need to log in before you can comment on or make changes to this bug.