[Webkit-unassigned] [Bug 88473] Web Inspector: Implement ExtensionPanel.show() method

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jun 8 08:11:55 PDT 2012


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





--- Comment #9 from Andrey Kosyakov <caseq at chromium.org>  2012-06-08 08:11:54 PST ---
(In reply to comment #6)
> In general, given one event -- link clicked or breakpoint hit -- we want only one UI result. We don't want panels to fight over 'show' or 'breakpoint'. 

Absolutely! This is why "open resource" is not a usual event and we came up with a notion of handler, where only one of the installed handlers will fire.

> 
> We can reuse this idea for the breakpoint use case: a Settings panel entry for "Open Breakpoints In". 

One of the reasons we don't have debugger API exposed yet is that giving extensions access to breakpoints requires careful consideration of how multiple extension will co-exist.

> We still have (at least ;-) two problems:
> 
>   1) do we allow show() to be called outside of a handler?  I think this is ok, the extension does not get control except through events (either fired at it by WebInspector or when the panel is visible).  

Those of the events that were not produced by the user gesture (e.g. network ones, or evaluation callbacks) should probably not cause focus change. I guess breakpoints/JS exception would be an exception from that rule.

>   2) will extension handlers want to be called but not want to do UI operations? For example I can imagine that a network analysis panel wants all events so it can store data, but it need not do UI unless the panel is selected by the user.  

Totally agree.

>This means that we would like the Settings entry to control the UI operations not the handler calls. For example, two extensions might both get "breakpoint hit", both would call panel.show(), but only the one selected in Settings will succeed.

Yup, that's definitely a good options. May be just "Active debugger".

> I think we should look through the existing events to see if we can divide them into "will need to do UI" and "no UI needed".  If they divide cleanly then we can use the one-handler-only solution.

+1.

-- 
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