Move a window if the sceren bounds being set is in other display.

Move a window if the sceren bounds being set is in other display.

- Fix StackingController::GetDefaultParent so that it uses
 the same root window as its transient parent.
- Updated WorkspaceWindowResizer to move the dragged window to other display if the new destination matches it. This is short term, temporary solution until better drag&drop is implemented.

BUG=123160
TEST=ExtendedDesktopTest.MoveWindow/MoveWindowWithTransient


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

[sky, 2012-07-20 15:06:07]

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
File ash/display/screen_position_controller.cc (right):

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:25: void
MoveAllTransientChildToNewRoot(aura::RootWindow* dst_root,
Child->Children or MoveAllTransientsToNewRoot

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:28: for
(aura::Window::Windows::iterator iter = transient_children.begin();
I'm worried that all this moving might have side effects and change around
transient children. Similar concern for children below.

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:42: // Move transient children of the
child wnidows if any.
wnidows -> windows

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:83:
!window->parent()->GetProperty(internal::kUsesScreenCoordinatesKey)) {
Are you sure you want to make kUsesScreenCoordinatesKey equate to both use
screen coordinates, and move widgets? For example, it doesn't seems like we need
to logic below for things like the launcher container or menu container.

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:92: aura::Window* suggested_container
= NULL;
suggested_container -> dest_container

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:97: DCHECK_GE(container_id, 0);
DCHECK_GT

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:107: aura::WindowTracker tracker;
Why do you need to do this for focus/activation? If activation does change isn't
this going to lead to lots of unwanted events and side effects?

[oshima, 2012-07-20 17:03:11]

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
File ash/display/screen_position_controller.cc (right):

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:25: void
MoveAllTransientChildToNewRoot(aura::RootWindow* dst_root,
On 2012/07/20 15:06:07, sky wrote:
> Child->Children or MoveAllTransientsToNewRoot

Done.

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:28: for
(aura::Window::Windows::iterator iter = transient_children.begin();
On 2012/07/20 15:06:07, sky wrote:
> I'm worried that all this moving might have side effects and change around
> transient children. Similar concern for children below.


I do too, but transient children needs to be in the same root. Do you have good
suggestion? I just couldn't think of any and thought our best bet is to fix
such issues case by case basis.

That's being said, I do think creating a root windows per display
makes aura/ash way complicated. This is necessary right now
(due to X's and current compositor's architecture), but I have
some idea that may be able to fix this, and am hoping that I can
work on it later this year.

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:42: // Move transient children of the
child wnidows if any.
On 2012/07/20 15:06:07, sky wrote:
> wnidows -> windows

Done.

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:83:
!window->parent()->GetProperty(internal::kUsesScreenCoordinatesKey)) {
On 2012/07/20 15:06:07, sky wrote:
> Are you sure you want to make kUsesScreenCoordinatesKey equate to both use
> screen coordinates, and move widgets? For example, it doesn't seems like we
need
> to logic below for things like the launcher container or menu container.

phantom widgets are in launcher containers, and menu has transient
parent. I understand that there are exceptional cases (like launcher should stay
inside the same root) and will handle these cases separately.
(i'm thinking of using property like kStayInRootWindow)

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:92: aura::Window* suggested_container
= NULL;
On 2012/07/20 15:06:07, sky wrote:
> suggested_container -> dest_container

Done.

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:97: DCHECK_GE(container_id, 0);
On 2012/07/20 15:06:07, sky wrote:
> DCHECK_GT

Sorry, comment was wrong. 0 is valid container id. Updated the comment.

http://codereview.chromium.org/10795027/diff/8001/ash/display/screen_position...
ash/display/screen_position_controller.cc:107: aura::WindowTracker tracker;
On 2012/07/20 15:06:07, sky wrote:
> Why do you need to do this for focus/activation? If activation does change
isn't
> this going to lead to lots of unwanted events and side effects?

Moving window may reset the focus, and focused widget may
be deleted when moved (like bookmark bubble), so this is necessary.

[sky, 2012-07-20 23:16:54]

LGTM

[commit-bot: I haz the power, 2012-07-21 13:07:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/oshima@chromium.org/10795027/3013

[commit-bot: I haz the power, 2012-07-21 14:27:59]

Change committed as 147798