@oshima could you take a look at this?

This is most likely because the device went to docked mode, in which case, windows are moved to the internal (laptop) display, in which case, WAI.

unmaximizing tries to restore the bounds to the original position, and
chrome is just trying to keep it visible. 

Obviously, WorksAsIntended is not correct for the overall behaviour (rather that just a 'docking' part), or the design is flawed, since it is nonsense behaviour from the users' point of view.

I understand that there are technically two steps here :

1. laptop put into docking mode and, for some reason attempts to move the windows to the laptop display; and,
2. when unmaximising, chrome attempts to restore to the original position.

My questions would be :

1. Why does it attempt to move it to the laptop display? Perhaps that is ok if the display is unplugged, but that isn't happening - the laptop is going to sleep before that happens (I think).
2. Under no circumstances should chrome move windows to non-visible/partially visible positions. Why would it not move them back onto the external screen (if still connected)? If that is somehow impossible, why not simply *not* try to move them and position them on the visible part of the screen.

Of course, I should note the 'background' complaint that it is impossible to move windows while they're maximised, meaning that, to move a window from the laptop screen to the TV, I need to: 1. unmaximise, 2. drag window, 3. maximise. This is quite different to other OSes I've used which I can just drag the top bar of a maximised windows down, then drag across to the other display, and up to the top to maximise it; all one fluid motion.

I didn't mean this bug itself is WAI. Sorry if it sounded that way.

1) No it doesn't go to sleep if you have external display connected, and Window has to move to the
   visible display, otherwise you can't use it. This is WAI.

2) It just restores to where it was. Since chrome doesn't know exactly when it
was saved, you can't really say it shouldn't move or not. (You might really have moved there,
then changed the display resolution, for example)

I do (did) have a plan to improve this, but never implemented due to the time/resource constraints.
I'll see if I can spare some time to work on this.

Excellent, thanks.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/92224ac504e06d16d48ceeb63eb3160519629ffc

commit 92224ac504e06d16d48ceeb63eb3160519629ffc
Author: oshima <oshima@chromium.org>
Date: Wed Feb 22 06:27:43 2017

Clamp the restore bounds to new workspace when a display is disconnected.

Reparent does adjust the bounds, but when it's partially offline, i can
push the window further to the different direction if the destination
display is larger.

BUG= 659925 
TEST=Updated the test to cover the scenario.

Review-Url: https://codereview.chromium.org/2703333003
Cr-Commit-Position: refs/heads/master@{#451899}

[modify] https://crrev.com/92224ac504e06d16d48ceeb63eb3160519629ffc/ash/root_window_controller.cc
[modify] https://crrev.com/92224ac504e06d16d48ceeb63eb3160519629ffc/ash/root_window_controller_unittest.cc

The window will be restored within the visible workspace now.