Do not release capture when starting a move loop on Desktop Linux

Do not release capture when starting a move loop on Desktop Linux.

ChromeOS does not release capture when starting a move loop either.
This CL fixes http://crbug.com/402301 as a side effect.

BUG=392480, 402301
TEST=None

Committed: https://crrev.com/2c2d6d613c5e6e326fb84018743bc3dc5e6d8b09
Cr-Commit-Position: refs/heads/master@{#292893}

[pkotwicz, 2014-08-10 18:58:50]

Elliot, can you please take a look? I think that this CL makes the move loop
logic easier to understand.

https://codereview.chromium.org/455553003/diff/160001/ui/views/widget/desktop...
File ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc (left):

https://codereview.chromium.org/455553003/diff/160001/ui/views/widget/desktop...
ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc:217:
GrabPointerAndKeyboard(cursor);
This comment sounds like a description of the "owner_events" parameter in
XGrabPointer(). Removed the comment because it is untrue.

https://codereview.chromium.org/455553003/diff/160001/ui/views/widget/desktop...
ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc:301: // is what GTK+
does, and I found a patch to KDE that did something similar.
This comment sounds like a description of the "owner_events" parameter in
XGrabPointer(). Removed the comment because it is untrue.

https://codereview.chromium.org/455553003/diff/160001/ui/views/widget/desktop...
File ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc (right):

https://codereview.chromium.org/455553003/diff/160001/ui/views/widget/desktop...
ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc:87: return
ui::POST_DISPATCH_PERFORM_DEFAULT;
I want to look into whether we can stop the propagation of all mouse events here
and in ToplevelWindowEventHandler during a drag (This is kind of confusing).

[pkotwicz, 2014-08-10 19:02:44]

This CL does depend on https://codereview.chromium.org/452413002/

[Elliot Glaysher, 2014-08-11 18:13:49]

lgtm

[pkotwicz, 2014-08-12 14:22:43]

tdresser@, can you please look at the ChromeOS comment changes in
tab_drag_controller.cc

[tdresser, 2014-08-12 14:35:35]

Comment changes in tab_drag_controller.cc LGTM.

[pkotwicz, 2014-08-13 17:21:31]

sky@ for tab_drag_controller.*

[sky, 2014-08-13 19:14:53]

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
File chrome/browser/ui/views/tabs/tab_drag_controller.cc (right):

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:240: can_release_capture_ =
false;
What about when running ash on linux (not chromeos)?

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:556: if (host_desktop_type_
== chrome::HOST_DESKTOP_TYPE_ASH) {
Why isn't this can_release_capture_?

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:595: // Ideally we would
always swap the tabs now, but on non-ash Windows, it
This is confusing now as it doesn't mention can_release_capture.

[pkotwicz, 2014-08-15 20:30:49]

Scott, can you please take another look?

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
File chrome/browser/ui/views/tabs/tab_drag_controller.cc (right):

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:240: can_release_capture_ =
false;
I moved the comments outside of the ifdefs. Should be clearer now.

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:556: if (host_desktop_type_
== chrome::HOST_DESKTOP_TYPE_ASH) {
The behavior described in the comment applies to ash only. Desktop Linux does
not end the move loop upon losing capture. (With or without this CL)

https://codereview.chromium.org/455553003/diff/160001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:595: // Ideally we would
always swap the tabs now, but on non-ash Windows, it
I changed the comment to make it more accurate. I am unsure whether the part of
the comment wrt to ChromeOS is still true.
On CrOS, line 609 does not activate the widget. http://crbug.com/402272

I can leave the comment as it was if you prefer. I can keep the variable named
|use_aura_capture_policy_| if you prefer too.

[sky, 2014-08-15 21:17:09]

LGTM

[pkotwicz, 2014-09-01 21:16:41]

The CQ bit was checked by pkotwicz@chromium.org

[commit-bot: I haz the power, 2014-09-01 21:17:25]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/pkotwicz@chromium.org/455553003/230001

[commit-bot: I haz the power, 2014-09-01 22:12:42]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_compile_dbg on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[commit-bot: I haz the power, 2014-09-01 23:11:07]

Committed patchset #3 (id:230001) as 790c5c0051feead3933f9f41c127c975635f114e

[commit-bot: I haz the power, 2014-09-10 03:17:33]

Patchset 3 (id:??) landed as
https://crrev.com/2c2d6d613c5e6e326fb84018743bc3dc5e6d8b09
Cr-Commit-Position: refs/heads/master@{#292893}