When the mouse pointer is over an application that uses XInput2 for scroll event handling, Desktop Zoom is enabled, and a Mouse wheel modifier is set for it, zooming in also scrolls the window contents up, and zooming out scrolls the window contents down.
Non-XInput2 applications are not affected, but this is a shrinking list as more applications adopt XInput2 for pixel-perfect scrolling, gestures, etc.
This issue has been reported a handful of times on the Cinnamon issue tracker, but I believe it is a bug in Muffin specifically.
Set <Alt> as the Desktop Zoom → Mouse wheel modifier (other modifiers have the same problem, but scroll events may cause different behaviors depending on the modifier used)
Position the mouse cursor over a window for an XInput2-aware application with scrollable contents. (e.g. Chrome, Chromium, any Electron app, cinnamon-settings, Firefox if MOZ_USER_XINPUT2=1 is set, Emacs 29.1 if compiled with --use-xinput2)
Hold <Alt>
Send scroll events (e.g. spin your mouse's scroll wheel, two-finger-drag your touch pad)
Expected behavior
The Desktop Zoom magnification level changes, but the contents of the window under the mouse pointer does not scroll.
Actual behavior:
The application under the mouse cursor reacts to the scrolling events as well. The modifier being held may affect how the application responds. For example, Emacs will scroll window contents when <Alt> is the modifier, but not <Super>, and Firefox will scroll the window contents with <Super> but cycle through the browser history with <Alt>.
(Added bonus bug: if <Super> is the selected modifier, and is also the menu activation modifier, the Cinnamon menu will pop up when you release <Super>, even if you've used the mouse wheel to modify the Desktop Zoom magnification)
Additional information
My evidence that this is related to XInput2 support:
Firefox can be told whether or not to use XInput2 by setting the environment variable MOZ_USE_XINPUT2=1. This bug only affects Firefox for me when using XInput2.
I made two builds of Emacs 29.1, with the only difference being whether ./configure was called with --with-xinput2 or --without-xinput2. This bug effects the --with-xinput2 build, but not the --without-xinput2 build.
xev, which reports Core Pointer events (buttons 4 and 5 for scrolling), doesn't report any scroll events when the zoom modifier is held down and I scroll to change the zoom level. xinput test-xi2 2 however, continues to receive valuator 3 XI_Motion events regardless of whether I'm holding down the zoom modifier.
I don't understand completely how to resolve this, but I have some guesses about why it's happening. Prior to XInput2, scroll up and down events were reported as mouse buttons 4 and 5 ButtonPress/ButtonRelease event pairs. These events are properly grabbed by src/core/keybindings.c:meta_display_window_buttons(), which sets up a passive grab on Mod+Button4 and Mod+Button5.
XInput2 applications, however, get scroll events as XI_Motion events on a valuator associated with a vertical type XIScrollClass (valuator 3 for the default Virtual Core Pointer, at least on my machine). These don't seem to be grabbed successfully. meta_change_button_grab() does include XI_Motion in the mask of events it passes to XIGrabButton(), but I don't think XIGrabButton() allows setting up passive grabs on XI_Motion events that way.
Distribution
Manjaro 24.0.2
Package version
6.0.1
Graphics hardware in use
AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
Frequency
Always
Bug description
When the mouse pointer is over an application that uses XInput2 for scroll event handling, Desktop Zoom is enabled, and a Mouse wheel modifier is set for it, zooming in also scrolls the window contents up, and zooming out scrolls the window contents down.
Non-XInput2 applications are not affected, but this is a shrinking list as more applications adopt XInput2 for pixel-perfect scrolling, gestures, etc.
This issue has been reported a handful of times on the Cinnamon issue tracker, but I believe it is a bug in Muffin specifically.
Related Cinnamon issue tickets:
Steps to reproduce
cinnamon-settingsAccessibility → Visual<Alt>as the Desktop Zoom → Mouse wheel modifier (other modifiers have the same problem, but scroll events may cause different behaviors depending on the modifier used)cinnamon-settings, Firefox ifMOZ_USER_XINPUT2=1is set, Emacs 29.1 if compiled with--use-xinput2)<Alt>Expected behavior
The Desktop Zoom magnification level changes, but the contents of the window under the mouse pointer does not scroll.
Actual behavior: The application under the mouse cursor reacts to the scrolling events as well. The modifier being held may affect how the application responds. For example, Emacs will scroll window contents when
<Alt>is the modifier, but not<Super>, and Firefox will scroll the window contents with<Super>but cycle through the browser history with<Alt>.(Added bonus bug: if
<Super>is the selected modifier, and is also the menu activation modifier, the Cinnamon menu will pop up when you release<Super>, even if you've used the mouse wheel to modify the Desktop Zoom magnification)Additional information
My evidence that this is related to XInput2 support:
MOZ_USE_XINPUT2=1. This bug only affects Firefox for me when using XInput2../configurewas called with--with-xinput2or--without-xinput2. This bug effects the--with-xinput2build, but not the--without-xinput2build.xev, which reports Core Pointer events (buttons 4 and 5 for scrolling), doesn't report any scroll events when the zoom modifier is held down and I scroll to change the zoom level.xinput test-xi2 2however, continues to receive valuator 3XI_Motionevents regardless of whether I'm holding down the zoom modifier.I don't understand completely how to resolve this, but I have some guesses about why it's happening. Prior to XInput2, scroll up and down events were reported as mouse buttons 4 and 5
ButtonPress/ButtonReleaseevent pairs. These events are properly grabbed bysrc/core/keybindings.c:meta_display_window_buttons(), which sets up a passive grab on Mod+Button4 and Mod+Button5.XInput2 applications, however, get scroll events as
XI_Motionevents on a valuator associated with a vertical typeXIScrollClass(valuator 3 for the default Virtual Core Pointer, at least on my machine). These don't seem to be grabbed successfully.meta_change_button_grab()does includeXI_Motionin the mask of events it passes toXIGrabButton(), but I don't thinkXIGrabButton()allows setting up passive grabs onXI_Motionevents that way.