Bug 72808 – Web Inspector: [Extensions API] Allow extensions to have their own "inspector" behavior

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Steven Roussey]

When clicking on the magnifying glass, the user can hover over various parts of a page and see them outlined on the page and selected in the Elements panel when clicked.

In my Illuminations project, the user can use the same tool in Firebug and have it highlight the "objects" as they are represented in the page. Thus it does not select every DOM node -- only those corresponding to the objects in the view or widget hierarchy. The highligher can also change color based on the type of "object" (like a view vs an element). The highligher should also allow for multiple objects to be highlighted at once, and ideally with some having different colors than others. See http://www.illuminations-for-developers.com/about/ for a 1min example screencast.

[Pavel Feldman]

Could you instead add your own button to the status bar and highlight objects using CSS?

[Steven Roussey]

Hmmm.... create my own fork of the inspector then? I guess so. I'll have to dig into how the Web Inspector does it. Do you think the extension API has all the pieces I would need? Hmm, I wonder if I could just inject the Firebug inspect highlighter...

As for as the status bar, I don't mind showing my own magnifying glass, but I would want to hide the one that was there already.

[Pavel Feldman]

(In reply to comment #2)
> Hmmm.... create my own fork of the inspector then? I guess so. I'll have to dig into how the Web Inspector does it. Do you think the extension API has all the pieces I would need? Hmm, I wonder if I could just inject the Firebug inspect highlighter...
> 

Well, not really the own fork of the inspector - inspector uses native code for the highlight, while I am suggesting that you use CSS for your extension highlight. In either case, we don't expose DOM handles in the extensions API, so you would not be able to highlight the node you select.

> As for as the status bar, I don't mind showing my own magnifying glass, but I would want to hide the one that was there already.

My point was that your icon should look a bit differently and co-exist with the default one. That way user would expect behavior to be different as well.

[Steven Roussey]

> Well, not really the own fork of the inspector - inspector uses native code for the highlight, while I am suggesting that you use CSS for your extension highlight.

Thus why I wanted some API to highlight. :) In Firebug we have several kinds. It looks like WI uses just one though. I prefer the kind that will conform to the shape of the outlined object, so I probably need my own. That's some work... ;)

> In either case, we don't expose DOM handles in the extensions API, so you would not be able to highlight the node you select.

I'm feeling dense, sorry. I don't know what you mean by that statement.

To create my own highlighter, I would:

1) Add to the WI status bar.
2) Inject code into user's page when the status bar button is hit. Will need to inject JS, and that JS can create DOM nodes and style sheets as needed.
3) listen for my panel being hidden, in which case i turn off highlighter, remove content from user's page, etc.
4) Code injected into user page adds DOM elements to block clicking which would also stop highlighter, removing DOM nodes, style sheets and JS objects.
5) While tracking the mouse in the user's content page, I need to send data on where the cursor is back to the background page and to the dev-tools page so that it can update info in WI.

Does this sound like the correct approach?

[Timothy Hatcher]

Why can't our native code highlighter be exposed as API? I'm sure he is just wanting to highlight nodes after all, just found by his own hover heuristics.

[Pavel Feldman]

> Does this sound like the correct approach?

It does.

(In reply to comment #5)
> Why can't our native code highlighter be exposed as API? I'm sure he is just wanting to highlight nodes after all, just found by his own hover heuristics.

As I mentioned, we don't expose DOM handles in the extensions API: You can't highlight "nodes" in case you don't have "nodes" references / handles. Extensions extend the front-end, while nodes are running in the backend. We are using DOM node handles (WebInspector.DOMNodes) internally, but they are not exposed to the extensions.

[Steven Roussey]

> As I mentioned, we don't expose DOM handles in the extensions API: You can't highlight "nodes" in case you don't have "nodes" references / handles. Extensions extend the front-end, while nodes are running in the backend. We are using DOM node handles (WebInspector.DOMNodes) internally, but they are not exposed to the extensions.

Yeah, I have a list of things because of that. How do you uniquely identify elements for communication back and forth? Do you have a hidden id map? xpath? And I will want to use some of the Element side panels as my own side panels (including a element hierarchy itself), which means I'll have to tell them what node to display, etc. These are things for down the road I guess, but it was nice to have them available in Firebug when I was developing Illuminations because I got what looked like big things working with little effort. It was motivating. I still have more to go, like showing the SASS/SCSS source as well as the CSS for frameworks that use them, like ExtJS and SpoutCore. But that obviously takes a lot longer than being able to reuse the Styles side panel right away. But this all seems like a digression. I suppose this bug should depend on another that exposes WebInspector.DOMNodes to extensions, and assuming that is not forthcoming, then I will pull in chunks of Firebug to do the inspect/highlighter (and things like the Metrics side panel, etc). Or wait and see. I have a lot to do in the meantime.

[Andrey Kosyakov]

(In reply to comment #7)

> Yeah, I have a list of things because of that. How do you uniquely identify elements for communication back and forth? Do you have a hidden id map?

We maintain a map between the ids used by the inspector and DOM nodes on the backend. We're wary of exposing an API to access the DOM model that we use in the front-end because it would be quite a complicated interface, potentially expensive to maintain. So at the moment the extensions that need DOM access need to use content scripts. You can probably implement your own marshalling of the DOM nodes to the inspector front-end extension pages, similar to the way it's done by the inspector.

[Steven Roussey]

> So at the moment the extensions that need DOM access need to use content scripts. You can probably implement your own marshalling of the DOM nodes to the inspector front-end extension pages, similar to the way it's done by the inspector.

One would expect that extensions to the Web Inspector will want access to the page DOM, JS objects, CSS, etc. 

As for the DOM, I built something that ran on top of chrome-devtools (the Eclipse to Chrome API from a while back) and on top of CrossFire (something similar for Firebug to Eclipse).[1] But a DOM mutation cascade can make for a lot of data if you want to keep a copy, and only keeping pointer DOM nodes is vulnerable to a communications error (though since this is all inside the browser processes, one would hope that that is not an issue to worry about).

Then again, I'm not building the elements panel here (though I would like to open it at a specific element). It is this latter point that is similar to the point about using the native inspector/highlighter. Without a DOM node API, something like a proxy for it will be needed. Either an id (in the case where one exists), a CSS selector or XPATH.

Anyhow, chew on that and next week I'll add some more requests that are more specific on what I want to accomplish, and then we can open one on a lower level way of getting there.


[1] http://www.screencast.com/users/sroussey/folders/Jing/media/db863111-e556-437e-8246-794b61a7aeab

[Steven Roussey]

A "cheap" way around this, is if the console object had a highlight() method. Then I could inject into the page, and then you would would handle the DOM nodes internally. Perhaps non-enumeral and called _highlight() for the moment. Hmm... I like this. Maybe I can drop this into the next Firebug since I already have some ideas for an API.