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

[bugzilla-daemon at webkit.org]

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


johnjbarton <johnjbarton at johnjbarton.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johnjbarton at johnjbarton.com




--- Comment #6 from johnjbarton <johnjbarton at johnjbarton.com>  2012-06-07 12:48:59 PST ---
(In reply to comment #4)
> What if the extension panel is a debugger and the runtime hits a breakpoint?
> 
> Another solution would be to make handlers (like the open resource handler) return a panel ID to bring up, but I'm not sure if it's a good idea.

In discussing this with Jan we came up with another idea.  

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

The 'link-clicked' example already solves this problem: the Settings panel has "Open Link In" which selects the link handler to be called. Thus even if two panels both have showPanel() calls in their handler, only one handler and thus one panel.show() will fire. 

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

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

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

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.

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