DevTools/e10s: Difference between revisions

Jump to navigation Jump to search
→‎Web Console: add the initial plan
(→‎Web Console: add the initial plan)
Line 48: Line 48:


== Web Console ==
== 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.
=== 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.
=== 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.


== Inspector ==
== Inspector ==
32

edits

Navigation menu