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

commit ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3
Author: thomasanderson <thomasanderson@chromium.org>
Date: Tue Nov 01 20:31:03 2016

Revert of Linux Aura: Make tab dragging great again (patchset #4 id:60001 of https://codereview.chromium.org/2410773002/ )

Reason for revert:
Suspecting this is causing 661248, so conservatively reverting.

Original issue's description:
> Linux Aura: Make tab dragging great again
>
> This CL uses _NET_WM_MOVERESIZE to handle tab dragging for managed windows on
> select window managers.
>
> This fixes various issues I've seen with tab dragging including:
> * Window movement is no longer constrained by screen bounds
> * Windows animating in during tab dragging is minimized
> * Tab dragging is improved on tiling WMs
> * Better integration with desktop environment (you can now drag to the top of
>   the screen to maximize if the DE supports it, or drag left/right between
>   workspaces)
>
> BUG=416119,617806,635195
> R=erg@chromium.org,sky@chromium.org
>
> Committed: https://crrev.com/fbb8975f1693f4fb33d54f62bbef19a70a4bc724
> Cr-Commit-Position: refs/heads/master@{#424909}

TBR=erg@chromium.org,sky@chromium.org,derat@chromium.org,thomasanderson@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=416119,617806,635195

BUG= 661248 

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

[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/chrome/browser/ui/views/tabs/tab_drag_controller.cc
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/base/x/x11_util.cc
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/base/x/x11_util.h
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/views/BUILD.gn
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
[delete] https://crrev.com/4025c2cba57945b8b51ef021e2915906f3c71b0d/ui/views/widget/desktop_aura/x11_desktop_window_move_client_managed.cc
[delete] https://crrev.com/4025c2cba57945b8b51ef021e2915906f3c71b0d/ui/views/widget/desktop_aura/x11_desktop_window_move_client_managed.h
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/views/widget/desktop_aura/x11_window_event_filter.cc
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/views/widget/desktop_aura/x11_window_event_filter.h
[modify] https://crrev.com/ef7d2678befe4a66cb1e2293f12b7f8c9eac2fa3/ui/wm/public/window_move_client.h

Does it still happen if you keep the mouse button held down for a little bit longer before releasing it?

derat@ That's correct in my case.

I think we just need to send _NET_WM_MOVERESIZE_CANCEL if chrome gets the mouse release before the WM gets the grab.

We weren't doing this before, but I guess something in the CL made the race condition worse :S

I didn't look at the CL closely, but does it start the move/resize on mouse down, or only mouse-down-plus-dragged-X-pixels?

When dragging by the titlebar, it's on mousedown.

When dragging by a tab, it's mousedown+some pixels.  However, X11DesktopWindowMoveClientManaged sends a cancel request in this case

Re #3, it doesn't happen if I hold the mouse button down for a bit.

Jean-Marc