Fix docking behaviour for devtools windows that don't have an associated browser window

Fix docking behaviour for devtools windows that don't have an associated browser window

BUG=40090
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=43709

[Mattias Nissler (ping if slow), 2010-04-01 09:21:18]

Please review. I'm not sure about the synchronous message for checking whether
we can dock, is this ok?

[pfeldman, 2010-04-01 09:42:09]

On 2010/04/01 09:21:18, mnissler wrote:
> Please review. I'm not sure about the synchronous message for checking whether
> we can dock, is this ok?

You are right in not liking synchronous messages, we do it only in exceptional
cases. This one is not exceptional, so let us try to work around it.

Originally, canAttachWindow was introduced upstream to handle docking to a
window that has insufficient height. Given the WebKit's being synchronous, the
method itself was made synchronous. Now we have two options: 1) change it
upstream to be asynchronous 2) Push 'attachable' state to devtools_client some
time early upon front-end creation.

I think that the button state in the front-end should be always enabled, so that
we could tell user why docking is not happening / prohibited. Hence there is no
strict need for the canAttach query method. As a result we could get away with
dockIfPossible. Toolbar should change the looks in the 'ack' phase using
WebInspector.setAttachedWindow.

[Mattias Nissler (ping if slow), 2010-04-01 09:57:57]

On 2010/04/01 09:42:09, pfeldman wrote:
> On 2010/04/01 09:21:18, mnissler wrote:
> > Please review. I'm not sure about the synchronous message for checking
whether
> > we can dock, is this ok?
> 
> You are right in not liking synchronous messages, we do it only in exceptional
> cases. This one is not exceptional, so let us try to work around it.
> 
> Originally, canAttachWindow was introduced upstream to handle docking to a
> window that has insufficient height. Given the WebKit's being synchronous, the
> method itself was made synchronous. Now we have two options: 1) change it
> upstream to be asynchronous 2) Push 'attachable' state to devtools_client some
> time early upon front-end creation.
> 
> I think that the button state in the front-end should be always enabled, so
that
> we could tell user why docking is not happening / prohibited. Hence there is
no
> strict need for the canAttach query method. As a result we could get away with
> dockIfPossible. Toolbar should change the looks in the 'ack' phase using
> WebInspector.setAttachedWindow.

Just to make sure I understand you correctly: You propose to completely remove
the canAttachWindow() query method and make the UI changes when
setAttachedWindow() is called back from the InspectorFrontendClient? I like this
idea and will update the patch accordingly.

[pfeldman, 2010-04-01 10:04:14]

Exactly. I actually thought that front-end was querying it synchronously to make
dock button disabled, but I can now see that it is not. So that you will get
away with minimal changes to WebInspector.toggleAttach.

[use mnissler at chromium.org, 2010-04-01 10:09:02]

Ok, cool. Will do.

On Thu, Apr 1, 2010 at 12:04 PM, <pfeldman@chromium.org> wrote:

> Exactly. I actually thought that front-end was querying it synchronously to
> make
> dock button disabled, but I can now see that it is not. So that you will
> get
> away with minimal changes to WebInspector.toggleAttach.
>
>
> http://codereview.chromium.org/1567014
>

[Mattias Nissler (ping if slow), 2010-04-01 18:16:48]

Ok, new version. Note that this patch now should be landed before the webkit
patch (otherwise docking breaks completely).

[Mattias Nissler (ping if slow), 2010-04-06 12:30:23]

Another go. I'm sorry the last version was so poor, I hadn't fully understood
what you were suggesting.

Problem with this one is that no matter in which order you patch WebKit and
chromium, docking behavior will break. Any ideas on that?

[pfeldman, 2010-04-06 12:45:05]

LGTM. Please talk to me prior to landing this. I am on sheriff duty today, so
will be able to help you coordinating the landing.