[Webkit-unassigned] [Bug 40425] Web Inspector: provide API for content scripts to interact with the inspector

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 27 11:04:32 PDT 2010


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





--- Comment #15 from Andrey Kosyakov <caseq at chromium.org>  2010-07-27 11:04:32 PST ---
(In reply to comment #13)
> > webinspector.panels.onSelectionChanged
> > Fired when an objects (script, resource, DOM element etc) is selected in the panel.
> 
> I don't see the usefulness of this. Wouldn't you know when someone is selected
> in your own panel? Was this added to handle a specific use case?
> 
> Or maybe I'm misreading this and it means when an element is selected in a
> native different Panel, like the Elements or Storage panel.

Exactly -- this is meant to let the extension know when inspector object is selected in inspector's panel, not extension panel. The primary use case for that is to update contents of sidebar panes or any other UI that depends on a currently selected item.

> > webinspector.panels.onShown
> 
> There is an onShown but not an onHidden? If an inspector extension wants to do
> something really wild, they may need to detect when a panel change is made.
> 

Yes, I'll add that. The intent of onShown was primarily to let the panel do some expensive stuff lazily only when it is shown, but I think having onHidden is good for consistency.

> > webinspector.consoleMessages
> 
> I think webInspector.console seems more appropriate. It would change the events
> to "addMessage" and "onMessageAdded", but it opens the door to future console
> related tasks.

This also makes sense. Anyway, console functionality only exists in the API draft at the moment, we need some more time to think over it.


> > webinspector.consoleMessages.add(ConsoleMessage message)
> 
> Directly using the WebInspector.ConsoleMessage type is nice, but it means that
> changing the internal ConsoleMessage type in the future could break extensions.
> Should there be an intermediate representation for conversion?

Sure, there definitely going to be an intermediate representation.

> This concern goes for all places where internal objects would be used directly.

We already do that for the only object type we support (which is resource).

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



More information about the webkit-unassigned mailing list