Video pauses when clicking progress bar

[Keith94]

I changed my mouse bindings so left click pauses the video (rather than right click) with MOUSE_BTN0 cycle pause. Unfortunately this makes this progress bar unusable because clicks will only pause the video. Is there any workaround for this?

[torque]

You can rebind the left-click binding to a different button in input.conf, e.g. MOUSE_BTN1 script-binding progressbar/left-click. This should really be bound to one your mouse buttons.

e: for clarification: when the left-click keybinding is triggered, it gets the mouse's current position and dispatches events as appropriate (e.g. seeking). This behavior is invariant of whether or not the event is bound to a mouse button or a keyboard button, so Unexpected Behavior may ensue if bound to not a mouse button.

[Keith94]

That's useful. Is it possible to have both cycle pause and script-binding progressbar/left-click bound to MOUSE_BTN0? It would be nice to use LMB for both pause and seek (only seeking when cursor is over the progress bar).

[torque]

This is a limitation of mpv's keybinding system: ~~a key can only be bound to a single action at a time. Lua scripts can work around this because key events result in a function call, which can perform an arbitrary number of actions.~~

e: the above is patently false. mpv can bind multiple actions to a single key with the syntax BUTTON command1; command2; command3. However this does not actually help in this case because there is no way to control event dispatch and propagation. All three commands will always be run for the above example, meaning at best you would be able to both seek and pause simultaneously.

While mpv-progressbar has the ability to dispatch click events internally, mpv cannot dispatch events to the script as well as to a normal command. Additionally, mpv has no idea where the script click zones are, so even if it could bind multiple commands, it would have no way to handle them appropriately. This is a major limitation of mpv's mouse handling.

The only way to do this currently would be to absorb the click-to-pause functionality into mpv-progressbar. This behavior is niche enough (I suspect), that I don't think it makes sense to implement it wholesale. However, it should be straightforward to add functionality that allows users to specify arbitrary mouse zones in a config file. I think this would be useful enough that I'll add it when I get a chance.

In the long term, I'd like to see mpv's mouse handling be improved in a way that such behavior could be supported more natively. While mpv has a deprecated private api that sort of tried to handle this use case, I recall trying it and having it not actually work correctly. I've also attempted to avoid using private apis as much as possible.

[Keith94]

That's a good idea. Thanks for your interest!

Would this feature also add the ability to drag the progress bar for seeking in real time (without having to release the button) and avoid dragging the window at the same time?

[avih]

it should be straightforward to add functionality that allows users to specify arbitrary mouse zones in a config file

The Zones[1] user-script already does exactly that. I'm pretty sure it can be used to solve this issue without any code changes at mpv-progressbar.

[1] https://github.com/mpv-player/mpv/wiki/User-Scripts

[torque]

The Zones[1] scripts already does exactly that. I'm pretty sure it can be used to solve this issue without any code changes at mpv-progressbar.

It would make more sense if you linked zones directly rather than making people look for it on the scripts page.

More importantly, and I may be wrong, I don't think zones would fix the problem at all because afaik, you still can't get around single target mouse dispatch. So the left click could go to zones, but then mpv-progressbar wouldn't receive the left clicks.

Additionally, I don't like zones much because it's very limited. It can only break the window into a grid of 9 zones. I am interested in allowing users to specify arbitrarily shaped/sized areas.

[avih]

More importantly, and I may be wrong, I don't think zones would fix the problem at all because afaik, you still can't get around single target mouse dispatch. So the left click could go to zones, but then mpv-progressbar wouldn't receive the left clicks.

But that's exactly what zones does - Dispatches different commands according to where the mouse pointer is when the trigger happens.

E.g. put zones.lua in your scripts folder, and add this to input.conf: MOUSE_BTN0 script_message_to zones commands "default: cycle pause" "bottom-*: script-binding progressbar/left-click"

It works (with the minor inconvenience that if you click at the bottom 20% but outside of the bar itself - nothing will happen. But the top 80% will trigger a pause, and clicking the bar would work as expected).

[edit] - minor fixes.

[lord-ne]

Here's a fairly simple solution, although it requires modifying the progressbar.lua file:

On lines 804 to 806 of progressbar.lua, you'll find the following text:

      if not (self:containsPoint(Mouse.clickX, Mouse.clickY)) then
        return 
      end

Immediately before that, add the following:

      if ((Window.h - Mouse.clickY) > settings['hover-zone-height']) then
        mp.command("cycle pause")
      end

So now lines 804-809 of progressbar.lua should look like this:

      if ((Window.h - Mouse.clickY) > settings['hover-zone-height']) then
        mp.command("cycle pause")
      end
      if not (self:containsPoint(Mouse.clickX, Mouse.clickY)) then
        return 
      end

Make sure the indentation is correct.

You can change "cycle pause" to whatever MPV command you want.

Disclaimer: I have no idea what I'm doing. I looked at the code for progressbar.lua and the code for zones.lua mentioned above and this is what I came up with. It seems to be working for me.

[N-R-K]

Should be possible to use mp.add_forced_key_binding() and override the user binding when progress-bar is hovered over - and unbind it once it's not.

That's (apparently) what the default osc does to listen for mouse clicks without interfering with user-binding when not focused.