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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=72808





--- Comment #9 from Steven Roussey <sroussey at gmail.com>  2011-11-21 11:48:59 PST ---
> 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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.