Capture mouse on click

[raphlinus]

This is branched from #450, but has come up repeatedly, so I felt it needed its own issue.

Mouse move and up events are dropped when the mouse is clicked in window then dragged outside. This causes all kinds of problems, as widgets (reasonably) expect an eventual mouse up after a mouse down.

I think it needs to be solved at the druid-shell level. On Windows, we should be calling SetCapture (and ReleaseCapture). I'm not sure what the counterparts are on other systems; on macOS I think this may be handled by the platform.

When should the app grab mouse capture? One possibility is to always do this on mouse click. Another is to have it plumbed down from set_active (and there is a TODO in the source for this). If the behavior on macOS is to always capture, then I think the former route is more developer-friendly, as there's less risk of strange behavior when set_active is not called, and of course less platform variation.

[mendelt]

We could even send a mouse-up when the mouse leaves the window. That might be a solution for platforms that don't support mouse capture?

[cmyr]

Are there platforms that don't support mouse capture? Sending a mouse up sounds like it would cause other problems; what happens if the user drags briefly out off a button out of the window, then back onto the button and actually does mouse up?

[justinwilaby]

Hello -

After reading thought the linked documents, SetCapture looks most appropriate for certain circumstances. e.g. scroll thumb press and drag (since scrolling should still occur even if the mouse leaves the window after pressing the scroll thumb). If the plan is to implement drag and drop operations natively on widgets identified as drag or drop targets, DragDetect is promising.

For all other cases, this is what I've seen in the past:

1. User presses the left mouse down on a widget - the widget receives a MouseDown as per usual.
2. User drags the widget - if it's a drag target, a drag operation is initiated and DragMove events are triggered until the mouse is released regardless of where the release occurs.
3. If it is not a drag target and the mouse leaves the window and then is released sometime later, a MouseUpSomewhere event is dispatched, or some other event that distinguishes between a normal MouseUp. This prevents the normal MouseUp behavior but allows things like MouseMove and maybe the down or focused state to continue until the user releases the mouse.
4. If the user drags the mouse back over the original widget after leaving the window, a MouseUpSomewhere could still be dispatched if necessary and the is_hot flag could be used to determine if it should be treated as a normal MouseUp event.

Anyway. I hope this helps.

[xStrom]

Was this implemented on Linux? 🤔

[cmyr]

It may not be. This issue had a particularly windows-y tone; if this remains an issue on GTK I'm happy for us to open a new platform-specific issue then.