move windows when disconnecting secondary monitors

move windows when disconnecting secondary monitors

BUG=123160
TEST=root_window_controller_unittest.cc

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

[oshima, 2012-06-25 21:34:09]

jamescook -> window_animatinos.cc
sky -> see my comment in root_window_controller_unittest.cc
derat -> everything.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
File ash/root_window_controller_unittest.cc (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller_unittest.cc:92: // why.
Scott, do you have any clue what's causing this? If not, I'll look into this in
separate CL.

[James Cook, 2012-06-25 21:38:56]

window_animations.cc lgtm

[sky, 2012-06-25 22:05:14]

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:256: menu_controller->OnWidgetActivationChanged();
Why do you have to explicitly do this? Doesn't the deactivation handle it for
you?

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller.h
File ash/root_window_controller.h (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.h:69: // Moves child windows to the |dest|.
remove 'the'.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
File ash/root_window_controller_unittest.cc (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller_unittest.cc:92: // why.
On 2012/06/25 21:34:09, oshima wrote:
> Scott, do you have any clue what's causing this? If not, I'll look into this
in
> separate CL.

I don't know exactly what the bug is. The code should end up in
ScreenAsh::GetMaximizedWindowBounds which seems to be multi-mon aware, so I'm
not sure.

[Daniel Erat, 2012-06-25 22:09:33]

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:46: const int* ids,
nit: mind switching this to be a reference to a vector<int>?  it feels a bit
cleaner and i think it'll actually save you a line on the MoveWindowsTo() side.

also, please rename to something like container_ids.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:258: // Windows moves only from secondary displays
to the primary
nit: s/moves/move/

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:272: } else if (active) {
will focusing the window automatically update activation?

[oshima, 2012-06-25 22:42:27]

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:46: const int* ids,
On 2012/06/25 22:09:33, Daniel Erat wrote:
> nit: mind switching this to be a reference to a vector<int>?  it feels a bit
> cleaner and i think it'll actually save you a line on the MoveWindowsTo()
side.
> 
> also, please rename to something like container_ids.

move container_ids from caller to callee because this is just a utility
function.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:250: if (root_window_->Contains(focused) ||
root_window_->Contains(active))
I removed this and changed to always deactivate because I want to close any
menu/bubble windows to simplify the transition.
active window should be restored at the end of this function if any.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:256: menu_controller->OnWidgetActivationChanged();
On 2012/06/25 22:05:14, sky wrote:
> Why do you have to explicitly do this? Doesn't the deactivation handle it for
> you?

A desktop context menu can be opened without activation and this necessar to
close such context menu.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:258: // Windows moves only from secondary displays
to the primary
On 2012/06/25 22:09:33, Daniel Erat wrote:
> nit: s/moves/move/

Done.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:272: } else if (active) {
On 2012/06/25 22:09:33, Daniel Erat wrote:
> will focusing the window automatically update activation?

Yes. this is "else if" , in case there is an active window without focus. (don't
have an example, but it's technically possible.)

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller.h
File ash/root_window_controller.h (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.h:69: // Moves child windows to the |dest|.
On 2012/06/25 22:05:14, sky wrote:
> remove 'the'.

Done.

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
File ash/root_window_controller_unittest.cc (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller_unittest.cc:92: // why.
On 2012/06/25 22:05:14, sky wrote:
> On 2012/06/25 21:34:09, oshima wrote:
> > Scott, do you have any clue what's causing this? If not, I'll look into this
> in
> > separate CL.
> 
> I don't know exactly what the bug is. The code should end up in
> ScreenAsh::GetMaximizedWindowBounds which seems to be multi-mon aware, so I'm
> not sure.
Never miond. I rewrite the test and it seems to be working, so I probably had
some bug in the old test code.

[Daniel Erat, 2012-06-25 23:13:36]

lgtm

http://codereview.chromium.org/10659006/diff/1005/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/1005/ash/root_window_controller....
ash/root_window_controller.cc:49: const int container_ids_to_move[] = {
nit: kContainerIdsToMove

[sky, 2012-06-25 23:58:33]

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
ash/root_window_controller.cc:256: menu_controller->OnWidgetActivationChanged();
On 2012/06/25 22:42:28, oshima wrote:
> On 2012/06/25 22:05:14, sky wrote:
> > Why do you have to explicitly do this? Doesn't the deactivation handle it
for
> > you?
> 
> A desktop context menu can be opened without activation and this necessar to
> close such context menu.

I don't like the direct dependency. Some event should be triggered that
MenuController can listen for and hide itself.

[oshima, 2012-06-26 01:36:27]

On 2012/06/25 23:58:33, sky wrote:
>
http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller.cc
> File ash/root_window_controller.cc (right):
> 
>
http://codereview.chromium.org/10659006/diff/10008/ash/root_window_controller...
> ash/root_window_controller.cc:256:
menu_controller->OnWidgetActivationChanged();
> On 2012/06/25 22:42:28, oshima wrote:
> > On 2012/06/25 22:05:14, sky wrote:
> > > Why do you have to explicitly do this? Doesn't the deactivation handle it
> for
> > > you?
> > 
> > A desktop context menu can be opened without activation and this necessar to
> > close such context menu.
> 
> I don't like the direct dependency. Some event should be triggered that
> MenuController can listen for and hide itself.

I changed to explicitly close the background menu using ShellContextMenu because
that's what's causing the issue. Please let me know what you think.

[oshima, 2012-06-26 02:14:40]

james, can you check window_animation change again?
CrossFade test was using old_layer to verify the behavior and causing the crash
with my change.

[sky, 2012-06-26 04:10:44]

http://codereview.chromium.org/10659006/diff/12020/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/12020/ash/root_window_controller...
ash/root_window_controller.cc:259: Shell::GetInstance()->HideBackgroundMenu();
I don't want anything special like this. There should be something the menu code
observes to properly clean things up.

[James Cook, 2012-06-26 13:45:40]

window_animations.cc LGTM.  Sorry I didn't notice the problem before.  Yes, the
tests require the old layer to stay around, whereas the production code does
not.  Memory management for that class is tricky.  :-(

[oshima, 2012-06-26 15:06:32]

On 2012/06/26 04:10:44, sky wrote:
>
http://codereview.chromium.org/10659006/diff/12020/ash/root_window_controller.cc
> File ash/root_window_controller.cc (right):
> 
>
http://codereview.chromium.org/10659006/diff/12020/ash/root_window_controller...
> ash/root_window_controller.cc:259: Shell::GetInstance()->HideBackgroundMenu();
> I don't want anything special like this. There should be something the menu
code
> observes to properly clean things up.

Actually, I could (and should) just release the capture and that should takes
care of it. PTAL.

[sky, 2012-06-26 15:34:01]

I'm was just thinking about releasing capture today on the way to work!

  -Scott

http://codereview.chromium.org/10659006/diff/7011/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/7011/ash/root_window_controller....
ash/root_window_controller.cc:253: 
nit: remove newline.

http://codereview.chromium.org/10659006/diff/7011/ash/root_window_controller....
ash/root_window_controller.cc:267: if (focused && dst->Contains(focused)) {
I'm a little nervous about if the focused window gets destroyed between when you
record it, then deactivate/release capture. Is it worth adding an observer to
verify it isn't destroyed?

[oshima, 2012-06-26 18:12:15]

http://codereview.chromium.org/10659006/diff/7011/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/7011/ash/root_window_controller....
ash/root_window_controller.cc:253: 
On 2012/06/26 15:34:01, sky wrote:
> nit: remove newline.

Done.

http://codereview.chromium.org/10659006/diff/7011/ash/root_window_controller....
ash/root_window_controller.cc:267: if (focused && dst->Contains(focused)) {
On 2012/06/26 15:34:01, sky wrote:
> I'm a little nervous about if the focused window gets destroyed between when
you
> record it, then deactivate/release capture. Is it worth adding an observer to
> verify it isn't destroyed?

Yes, that's why I added ->Contains, but looks like this isn't enough. Added
WindowLifeTracker. I kept Contains in case it's detached from root in between.

[sky, 2012-06-26 20:01:49]

LGTM

http://codereview.chromium.org/10659006/diff/5007/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/5007/ash/root_window_controller....
ash/root_window_controller.cc:50: tracking_windows_.erase(iter);
window->RemoveObserver(this);

http://codereview.chromium.org/10659006/diff/5007/ash/root_window_controller....
ash/root_window_controller.cc:66: DISALLOW_COPY_AND_ASSIGN(WindowLifeTracker);
nit: newline between 65/66.

[oshima, 2012-06-26 20:58:31]

http://codereview.chromium.org/10659006/diff/5007/ash/root_window_controller.cc
File ash/root_window_controller.cc (right):

http://codereview.chromium.org/10659006/diff/5007/ash/root_window_controller....
ash/root_window_controller.cc:50: tracking_windows_.erase(iter);
On 2012/06/26 20:01:49, sky wrote:
> window->RemoveObserver(this);

Done.

http://codereview.chromium.org/10659006/diff/5007/ash/root_window_controller....
ash/root_window_controller.cc:66: DISALLOW_COPY_AND_ASSIGN(WindowLifeTracker);
On 2012/06/26 20:01:49, sky wrote:
> nit: newline between 65/66.

Done.

[commit-bot: I haz the power, 2012-06-27 15:00:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10659006/25001

[commit-bot: I haz the power, 2012-06-27 16:21:28]

Change committed as 144467