[BUG] Scrolling up/down while zooming in/out

[CHJ85]

I have enabled the built in Zoom to hotkey ALT+Mousewheel. In some apps such as Nemo and Rhythmbox, zooming in / out also scrolls up and own. Also, setting zoom to CTRL instead of ALT, causes the icons in Nemo to increase. This is a major bug and very annoying, especially if you're visually impaired. Can't believe this hasn't been fixed yet. I tried to use Shift as a workaround and use xbindkeys to send shift+mousewheel to alt+mousewheel. But this obviously doesn't work as shift is being used for capitalizing letters and changes + to ? and - to _. Super doesn't work either because every time I release the super key after zooming, the start menu pops up. Actually, you should look into that too. So I guess there are 2 bugs here. Prevent the start menu from launching whenever another key is being pressed in addition to super. Prevent alt+mousewheel from scrolling up and down while zooming in and out. And I guess remove CTRL from zoom options as it collides with other web browser zoom, Nemo's increase/decrease icons and the terminal's increase/decrease font size. Also, you should add the option to set Ctrl+Alt+Mousewheel, Ctrl+Super+Mousewheel and Shift+Ctrl+Mousewheel in addition to the ones that exist now. And also add the ability to include multiple zoom hotkeys and not just one with mousewheel. Because like I said earlier, different applications use different function keys with mousewheel.

Please take this seriously as this is a legit problem for people that need to use desktop zoom. Thank you for your time.

[igarca]

I have the same problem. Zoom hotkey should be "standarized", so when it's pressed, it becomes unusable/blocked for the app you're zooming in or out.

[selimachour]

Same problem which is driving me nuts. The only combination that works is [shift]+wheel. Using [alt] or [super] scrolls the content at the same time. It's an old problem as mentioned in issue 5163

[CHJ85]

Right. I mean, just the fact that this issue has been around for so many years, makes me wonder how many of us Linux desktop users are there really? Because if you enable desktop zoom (doesn't matter which desktop environment), you are gonna notice this bug on a regular basis and it'll drive you crazy.

[malsyned]

I'm pretty sure this bug only happens to applications that use the XInput2 extension, and is related to the difference between how XInput2 handles scrolling events, vs. XInput1 or X Core Pointer/Keyboard events.

Here are the clues that make me think so:

• 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 I passed --with-xinput2 or --without-xinput2 to ./configure. 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 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 this is 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 muffin/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. 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.