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.

Debug Protocol

Introduction

The Remote Debugging Protocol is currently under development, as part of the Script Debugger. The debug protocol exposes a tree of named Actors, which communicate with the client using JSON packets.

Debugger clients connect to a protocol implementation running in the chrome process (the client currently under development also runs in the chrome process). The client then asks the root actor running in this process for a list of actors for the currently open tabs, and then sends an "attach" request to the chrome-process protocol actor for the tab it's interested in.

When the attached tab is running in a content process, the chrome-process actor will request a connection to the content's protocol implementation (which may require starting one up) over the messageManager and get a reference to a content-side tab actor for the given tab.

Actor IDs will be prefixed with a unique identifier for each content process. The chrome process's protocol server will handle requests intended for chrome-process actors, and will dispatch requests to content actors over the connection to the content process.

The chrome-side tab actor will exist before it is attached, and before we've connected to a protocol implementation on the content side. After attaching, that actor will need to manually forward requests to the content-side actor for the tab.

Planning

Further Analysis

• Get the remote debugging protocol server running in content

 processes, and listing tabs hosted in that process.  Should be able
 to manually connect a debugger to a specific content process (over
 TCP) and debug that without involvement from the chrome process.

• Figure out and build the transport layer between the chrome and

 content protocol implementations (IPDL?).

Implementation

• Get tab attach to work over the chrome/content boundary.
• Get cross-navigation debugging to work correctly when the new

 location is hosted in a new content process (in the meantime we will
 treat that as a tab close).

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 it still makes 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…