wiki:ProposedWebInspectorRearchitecting

Version 6 (modified by timothy@apple.com, 14 years ago) (diff)

Define some of the Console API.

Rearchitecting the Web Inspector

The main goal here is to divorce the web inspector from having direct access to any objects on the page. This will allow for moving the inspector into it's own process (required for Chromium), but also to increase confidence of security (e.g. JSWrapper objects should no longer be needed).

The long-term goal is to have a well-defined API that speaks JSON between the Inspector's JS and the underlying representation of the page. At first, that underlying representation of the page will be written entirely in JS and access the inspected page's DOM directly. Eventually, we can start moving appropriate bits to C++, or in Chromium's case IPC, as necessary.

The eventual stack will look something like this:

Inspector JS


API Shim JS


InspectorController C++ Give this a generic client (InspectorControllerClient?) that Chromium can implement as IPC.


Possibly an IPC layer


C++ Receives calls from the InspectorControllerClient


Inspected Page's JS

APIs to implement

We'll put all these as objects on the InspectorController. These bits are probably easier to spec out when actually looking at making the change in the code. We can fill in these bits as we get to them.

Console

Functions

InspectorController.Console.evaluate(expression)
evaluates the expression in the global context of the inspected page

InspectorController.Console.messages()
requests an array of all recent messages up to the messageLimit

InspectorController.Console.clearMessages()
requests that all messages should be removed

InspectorController.Console.messageLimit()
requests the current message limit

InspectorController.Console.setMessageLimit(limit)
requests the current message limit

Responses

The evaluate, messages and messageLimit functions above will have responses that are sent to any message observers. (We need to define a message observer API.)

Define what is contained in each of the responses for the above functions.

Profiler

InspectorController.Profiler.?

Resources

InspectorController.Resources.?

DOM

InspectorController.DOM.getChildren(node)

InspectorController.DOM.getParent(node)

node here is a JS object that has a one-to-one mapping with the DOM node in the page. Everything above this API layer only knows about the node JS object. Somewhere in the implementation of the API there needs to be a mapping. Initially, it can just be an in JS map. Eventually, the map will probably move to C++, at the very least it will for the IPC-based version.

Database

InspectorController.Database.getCurrentStack() ?

InspectorConteoller.Database.?

Debugger

InspectorController.Debugger.?

Miscellaneous other notes

Objects viewed in the console should be snapshots (i.e. not live). In addition to matching user expectations better, this means we don't need to worry about objects on the page getting GCed. Similarly, any live objects in the debugger should not be GCable.

For making sure the inspector has zero impact on page load times and minimal impact on memory usage we agreed on a few UI changes. Network monitoring and possibly debugging should be opt-in per-site. The console should only keep around XXX messages unless the user opts-in to keep more (all?) messages for that site. Currently, Chromium has XXX==100, but that was a relatively arbitrary decision. As a side note, the Chromium/V8 debugger is already zero cost until a debug statement is actually hit, so Chromium doesn't actually care about the debugger being opt-in.

BUGS FILED

https://bugs.webkit.org/show_bug.cgi?id=20804 - Objects viewable in debugger should not be garbage collectable

https://bugs.webkit.org/show_bug.cgi?id=20803 - Console objects being snapshots

https://bugs.webkit.org/show_bug.cgi?id=20800 - Network monitoring opt-in

https://bugs.webkit.org/show_bug.cgi?id=20801 - Infinite console logging opt-in