I am unable to reproduce the problem on ToT.

> ... in the way that when mouse is released, it is out of chrome window bounds.

Even if the mouse-cursor is outside the bounds of the window, the mouse events (including the mouse-release) should still go to chrome (because of the capture it gets on mouse-down). Otherwise, you wouldn't be able to increase the width/height of the browser window (because the mouse-moves after the mouse-down will by definition be outside the bounds of the window's current size). So in my mind, it makes sense to me that I am unable to repro on ToT.

But maybe this is dependent on the environment? What environment are you using (window-manager, versions etc.)?

@sadrul: please watch the video attached. It shows Chromium/X11 ToT on Ubuntu 17.10 / Gnome 3.26 / X11. In this scenario, bug is really easily reproducible (as per the video).

Deleted: chrome_x11_tooltip.mp4 5.4 MB

	chrome_x11_tooltip.mp4 5.4 MB View Download

Is this ozone-x11? Or regular x11?

This is regular chrome/x11. I just downloaded Google Chrome / Dev, and could also repro easily.

BTW, on Gnome 3.26 Wayland (default on Ubuntu 17.10), reproducing it trickier.

This is because XWayland apparently sends RELEASED events *occasionally* when

a) manual resize happens at a slow pace
b) mouse is released out of the chrome window (eg resize to a minimal and keep moving the mouse out of the chrome window bounds).

In (b), if user unclicks the mouse button (resize ends), and hovers over back to the chrome window, RELEASE is sent when mouse enters back the chrome window bounds.
However, if user user unclicks the mouse button (resize ends), then hovers over another app or the desktop area, and only then hovers over the chrome window, RELEASE is *not* sent when mouse enters the chrome window bounds.

PS: It is harder for me to record this scenario because stable screen recorders seem not to available on wayland environments yet.

+thomasanderson@ any thoughts on why the WM may not send the mouse-release to chrome after a drag-resize? Or how chrome can reset the state after the drag-resize ends?

The way that WM drag-resizing is implemented is with _NET_WM_MOVERESIZE.  Before sending that message, the client must release all pointer grabs so that the WM can take the grab for the resize.  So if the cursor is not over Chrome when the resize ends, only the WM will get the event.

Maybe it makes sense to set the mouse-state to unpressed before sending off the _NET_WM_MOVERESIZE?  Also, I thought many other mouse events like mouse-moves also had the pressed state, so we could probably update the state from that as well.