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

• Figure out and build the transport layer between the chrome and content protocol implementations (IPDL?).

• Get the remote debugging protocol server running in content processes, and listing tabs hosted in that process, proxied through the chrome process but without the protocol forwarding bits.

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).

Web Console

Introduction

The Web Console code will need to continue to run as chrome.

It should be easy to make the Web Console work with the attached xul:browser, given that most of the Web Console code uses async listeners for errors, warnings, window.console API, network events and so on. We just need to update these receivers and the senders to use new APIs that work with e10s.

Master bug: 673148.

Requirements/analysis

We need analysis to find answers to the following questions:

• Do we continue to have a JavaScript sandbox in each content process? We should have a Cu.Sandbox() in content processes.

• We need the same or similar network-related APIs that allow us to listen for network requests, for retrieving request and response headers and bodies. We currently use the nsIHttpActivityDistributor, nsIRequestObservers and the http-on-examine-response notification.

• We need to know if the window.console API implementation needs to change in any way for e10s. see dom/browser/ConsoleAPI.js.

• Are there changes to the way the nsIConsoleService behaves? Are there changes to how we receive nsIScriptErrors?

• Do nsIWebProgressListeners continue to work? We use these to log local file:// requests.

• Do we use the remote debugging protocol or do we go for barebones e10s code? We need to check if RDP is mature enough and if it will not slow our work down (the main goal being that of getting the Web Console e10s-ready ASAP).

During work or before we start work on the e10s migration code ... we might want to pick some of the most important Web Console cleanup bugs. See bug 592463. We should keep in mind some of those goals while we reshuffle the code in HUDService.

Planning

• Remove HUDService.windowInitializer().

• No longer observe "content-document-global-created", see HUDWindowObserver.

• Update HUDService.registerDisplay()/unregisterDisplay() to work without relying on the tab content window object. This pretty much means we will do the much-needed rewrite of the Web Console initialization code, cleaner, simpler and e10s-ready.

• Make changes to the ConsoleProgressListener (the nsIWebProgressListener) needed for e10s, if anything.

• Update the network code to use any new e10s APIs and to no longer rely on window objects. We should be able to tie network requests to window IDs. See ResponseListener in HUDService.jsm, NetworkPanel, HUDService.httpResponseExaminer() and the HUDService.startHTTPObservation() method with its fancy code.

• It should be noted that we could end up having a lot of traffic between the content and chrome processes for network requests, which is ugly. We should keep this to a minimum, if possible.

• If there are nsIConsoleService changes we need to cater to, update the HUDConsoleObserver for e10s.

• Update JSTerm to create a sandbox in the content process and evaluate the code there. Here we can use the new Message Manager to communicate between the chrome and content processes. We just need to make sure we can have a sandbox in the content process. See JSPropertyProvider which gives us the autocomplete results (the object properties). See JSTermHelper ... these methods might end up living in the content process (or mix-and-match :) ). And finally, check the JSTerm.createSandbox() and evalInSandbox() methods.

• The PropertyPanel (the Object Inspector) might need to live in the content process, since it mainly deals with the content object being inspected.

• Updates through out the HUDService.jsm code to drop refs to contentWindow and anything related.

• Update all tests accordingly. It should be noted that tests have most of the same e10s problems to tackle as the HUDService code does.

Highlighter

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. bug 669698

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…