You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Linux version: Arch Linux (2025-02-25)
- Kernel Version: 6.13.0-1-mainline-um5606
- GPU Model: Radeon 880M
- Mesa/GPU Driver Version: 24.3.4
- Window Manager and Version: KWin 6.3.1
- Source of mpv: ALHP Repo
- Latest known working version: -
- Issue started after the following happened: -
Reproduction Steps
I'd suspect it'd might be necessary to use a wayland compositor to reproduce
OSC=always (not necessary but easier)
move window to the top left with titlebar+borders offscreen
remember the absolute position on screen where OSC elements are
move the window anywhere
enter fullscreen
move the mouse to some position from step 3
exit fullscreen without moving the mouse one pixel (keyboard and double click works)
single click as often as you'd like on OSC elements while the cursor is somewhere else.
Expected Behavior
mpv should update the cursor position after entering/exiting fullscreen, because it will have moved relative to the window.
Actual Behavior
mpv seems to remember the position where the mouse was relative to the window origin while in fullscreen mode. If you then use left mbtn mpv registers the click as the same distance relative to the window origin as in fullscreen, disregarding the fact that exiting fullscreen moved the window relative to the cursor. If there is an OSC UI element now, it will get clicked even though the cursor isn't there.
If that was a bit confusing, I hope the video demo (uploaded as sample) clears it up.
I want to emphasize here that this isn't just a theoretical problem. If you're in fullscreen, grab the mouse and triple- instead of double click to exit, you will involuntarily seek somewhere if you're unlucky, even if the cursor hasn't significantly moved since entering fullscreen and is nowhere near the the OSC.
I carefully read all instruction and confirm that I did the following:
I tested with the latest mpv version to validate that the issue is not already fixed.
I provided all required information including system and mpv version.
I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
I attached the full, untruncated log file.
I attached the backtrace in the case of a crash.
The text was updated successfully, but these errors were encountered:
Setting the mouse position always updates the cursor visibility state in
the core, but that's not always desired by the caller. Make it optional.
In practice, this is for wayland. Fixesmpv-player#15967.
mpv Information
Other Information
Reproduction Steps
I'd suspect it'd might be necessary to use a wayland compositor to reproduce
Expected Behavior
mpv should update the cursor position after entering/exiting fullscreen, because it will have moved relative to the window.
Actual Behavior
mpv seems to remember the position where the mouse was relative to the window origin while in fullscreen mode. If you then use left mbtn mpv registers the click as the same distance relative to the window origin as in fullscreen, disregarding the fact that exiting fullscreen moved the window relative to the cursor. If there is an OSC UI element now, it will get clicked even though the cursor isn't there.
If that was a bit confusing, I hope the video demo (uploaded as sample) clears it up.
I want to emphasize here that this isn't just a theoretical problem. If you're in fullscreen, grab the mouse and triple- instead of double click to exit, you will involuntarily seek somewhere if you're unlucky, even if the cursor hasn't significantly moved since entering fullscreen and is nowhere near the the OSC.
Log File
output.txt
Sample Files
Screencast_20250226_051111.mp4
I carefully read all instruction and confirm that I did the following:
--log-file=output.txt
.The text was updated successfully, but these errors were encountered: