DevTools/e10s

DevTools e10s Work

This page is for the investigation and planning of the migration of Firefox' Developer Tools to a post-electrolysis world. The DevTools team is currently in an information-gathering phase. We are investigating requirements to convert our existing tools planning for future tools to be able to communicate across process boundaries within Firefox.

Inspector

Introduction

For the Inspector and it's associated tools, it should be possible to get an easy win by just pushing the code into the content process. The rationale for this is pretty simple: The Inspector lives very close to content and requires access to the entire DOM. Given that it could be very costly to ship the whole DOM over a process boundary using the Debug Protocol or something implemented on top of the message manager, it makes sense to move most of the Inspector code into the content process.

Requirements

There will be a need for an API to tell the content process to run a particular element or JS code in itself. Using this, we should be able to instantiate the Inspector UI as part of the content process and bootstrap it.

• need bug link

We will need a mechanism to refer to a DOM element in the content process from chrome.

Planning

First Phase - analysis

1. Begin testing with patches from bug 666713 installed. I think it's safe to assume that everything the Inspector does from startup to shutdown connects with content. There won't be much news here, but could provide some interesting feedback about this analysis tool itself.
2. Load the Inspector in an e10s build and watch it fail. Again, we'll learn a bit about limitations of our current implementation in e10s from this, but shouldn't be terribly surprising.

What are we hoping to accomplish in this phase? We should attempt to make as much of the inspector work as possible using the current implementation. We can likely prototype a good chunk of the work from Phase 2 during this phase. We don't want to spend much time doing this here, however, but it will likely verify assumptions made for Phase 2.

Phase 1.5 - re-assess

Based on discoveries during the first phase, we should re-assess the plan in Phase 2 - implementation to make sure they still make sense.

Second Phase - implementation

1. Using the above API to move elements to the content process, begin migrating the Inspector's HTML panel UI to that process.
2. Implement an in-content API to update the HTML panel's selection
3. Decouple InspectorUI from gBrowser
   1. Remove references of contentWindow and contentDocument
4. Implement chrome InspectorUI APIs using Message Manager.
   1. HighlightNode
   2. SelectNode
   3. GetAnnotation
   4. GetId
   5. GetClass
   6. GetLayoutInformation…