[Webkit-unassigned] [Bug 78575] Web Inspector: Provide InspectorFrontendHost.canAttachWindow to hide attach / dock button

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Joseph Pecoraro <joepeck at webkit.org>  2012-02-14 16:11:35 PST ---
 (In reply to comment #2)
> We can't do synchronous canAttach, so we have asynchronous requestAttach instead.
> We should add InspectorFrontendAPI::setDockAvailable signal that would hide
> corresponding action instead.

Does the asynchronous nature matter? If the WebView being inspected and the inspector
WebView are in two difference processes, if you check the size of the inspected WebView's
main frame it could change by the time that you've gotten the value.


(In reply to comment #4)
> InspectorFrontendAPI is called from within the WebKit layer, i.e. it bypasses the
> protocol and talks directly Embedder -> Frontend View -> Frontend Page. Check
> out usages of other methods there (the Develop menu plumbing)

canAttachWindow and attachWindow check or adjust the inspected page's main frame's
FrameView. As far as I can tell, that FrameView's size can change with layout.
The InspectorFrontendAPI seems to be very port specific (InspectorFrontendClient).
If I add API to this, would I have to update each port in some way in didLayout?

My original plan was to have the trigger be at the end FrameView::performPostLayoutTasks.
There is already "resize" code there, and it is shared by all ports. If I trigger the frontend
API from here it looks pretty ugly:

  - to get to the InspectorFrontendClient I could go through InspectorController + InspectorClient,
    but going through InspectorController like this is frowned on.

Your asynchronous comment was probably about the unreliability of fetching that state?
If so, would it be fine to instead have a setDockingAvailable(bool) message in the Inspector
domain? As long as the events arrive in the order they are sent the this looks okay to me.

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