Cannot cancel mouse button inputs by moving the cursor out of the window before releasing the mouse button

[UserNaem]

mpv version and platform

0.25.0, Windows 7 SP1

Reproduction steps

Add this to input.conf:
MOUSE_BTN1 quit
Run mpv.
Press and hold middle mouse button anywhere in the mpv window, move the mouse cursor out of the mpv window and release middle mouse button.

Expected behavior

mpv shouldn't execute the command assigned to middle mouse button.

Actual behavior

mpv executes the command (quits).

[hrxn]

Not sure if that would really be the expected behaviour...

[Pacoup]

I think, normally, moving away from the target area while pressing and holding, unless the press and hold is part of a drag and drop operation of some sort, cancels the event.

But it's more subtle than that. It only cancels the event if the mouse button is let go while off the target; i.e. it's possible to press and hold the button, move out of the target, move back in, let go of the mouse button, and activate the button.

I've observed this behaviour on Windows and iOS. I can test macOS as well when I get home, but I'm pretty sure it's the same, iirc.

[haasn]

+1 on this being expected behavior.

Clearly mpv should just be using a modern UI toolkit like gtk+ or wxwidgets instead of trying to NIH logic that has been solved for 20 years.

[Pacoup]

@haasn Isn't this something you handle manually regardless of the framework though? I mean, Cocoa, for instance, would handle your window border events automatically, but not the events of the content, like dragging from the video area in mpv.

[rossy]

Another +1 for this being expected behaviour, but it's tricky because it clashes with another expected behaviour. There are some "complex" commands in mpv that are activated when the mouse is pressed and when it's released. A demonstration of this is the seekbar in the OSC. When you press and hold the mouse on the seekbar, it begins seeking, and when you release the button it stops seeking, even if the mouse has moved outside the window. If it didn't, the mouse would be "stuck" down from mpv's perspective.

So, if a mouse button is pressed inside the window and it's bound to a "simple" command that only activates on mouse-up, the command should only activate if the mouse is inside the window when it's released. The behaviour for "complex" commands, like the seekbar, should be unchanged.

[haasn]

@rossy I don't see how that conflicts. “Stop seeking” and “cancel command” to me both imply “cancel”-like actions, i.e. “stop doing this thing”.

If anything, what needs to be augmented is an ability to distinguish between a “success-like release” and a “cancel-like release”, being defined by whether or not I released the cursor on the original element.

For the seekbar, both are the same - because the seekbar has already seeked by the point in time at which you're letting go of it. For a button, however, a “cancel”-type release means “don't press this button”. It does not mean “pretend this release never happened”, otherwise the button would get stuck in a ‘down’ state visually.

[rossy]

That's true. I was more saying the implementation would clash, even though semantically the user is "cancelling" the command in both cases. I like the idea of distinguishing between "success-like" and "cancel-like" releases. Most of mpv's built in commands would just do nothing when the mouse button is released with "cancel-like" semantics, but for script-bindings, the cancel-flag could be passed to the script, since the script's behaviour could be different depending on which user-interface element the user clicked on.

Also, mouse events could be "cancelled" by reasons other than releasing the mouse outside the window. For example, they could be marked as cancelled if another application steals focus and/or mouse capture while the mouse is down. The event's cancel flag could be set in this case as well.