A bug (?) in the zoom accessibility tool

[kolayne]

 * Cinnamon 4.0.10
 * Distribution - Mint 19.1
 * 64 bit

Issue
When using the zoom accessibility tool, mouse scrolling is caught by an opened window, on which the cursor is.

Steps to reproduce
Switch on the zoom tool in the accessibility system settings
Start using it (Alt + scrolling), holding the cursor on any window

Expected behaviour
Screen image becomes zoomed, nothing else happens

Actual behaviour
Screen image becomes zoomed, the window content under cursor scrolls

[sshimko]

Chiming in to say this is an issue for me as well. It is an annoyance, not a show-stopper. Trying to zoom in to read a webpage results in the page scrolling. Once you are done zooming, you have to fix the page position to pick up where you left off.

Cinnamon 4.2.3
Fedora 30
64 bit

I glanced through the zoom and magnifier code including dbus/gio/js and nothing was immediately apparent, but if someone can point me in the right direction I can take a crack at a fix and submit a PR.

As an aside - I tried all the major window managers and all of their accessibility support was either broken (gnome-shell) or not featureful enough to make it an acceptable solution (Kwin). Cinnamon’s great. Thank you!

[kolayne]

Cinnamon 4.4.8. Not fixed yet :(

[kolayne]

Can reproduce in Cinnamon 4.6.6

[KreerC]

I've noticed this too, but only when using the chromium browser (including any Electron apps etc.), so I'm guessing this is an issue with the way that engine handles input. It has become a mayor annoyance for me as I started using lots of different electron apps recently, like vscode. Perhaps we should open an issue with the Chromium team and hope they'll fix it and the change propagates quickly to Electron and other dependants (hopefully within years, not decades) -- or implement a solution where the system would catch the zoom shortcut and cancel the event before other applications even see it. But the latter would be a bit weird as other native apps (tested with Gnome Terminal, Firefox, Thunderbird and Telegram Desktop) are not affected by this issue.

Update: Cinnamons UI is affected by this, too.

[kolayne]

so I'm guessing this is an issue with the way that engine handles input

I believe this kind of input should not get to applications at all. I mean, if I'm holding the Alt key and scrolling, cinnamon should capture this input, process it but not forward to the application my mouse is hovering above (of course, this should only happen if zoom is enabled).
Cinnamon does a similar thing already for hotkeys, containing the combination used for keyboard layout switching (Alt+Shift in my case). I can't use a hotkey containing Alt+Shift in other programs (for example, if I press Alt+Shift+A in a program, my keyboard layout is switched, and the program receives the Alt+A hotkey) (which, by the way, may be a bug too, but if it is the expected behavior, I expect Alt+scrolling to be not forwarded to applications too)

[KreerC]

Yes, but cinnamon does that. The issue here lies with the way chromium reacts to scrolling even when it is not in focus. If it would follow standards, it would work fine. The real problem for us as users is that many applications are based on browsers nowadays and that a fix would take a very long time to propagate. Maybe the maintainers @mtwebster and @clefebvre are able to comment on this more clearly or suggest a hacky fix of some sort.

[kolayne]

Yes, but cinnamon does that.

I think we misunderstood each other. I am not familiar with the architecture of GUI on Linux at all, but I thought any application which is displayed via a graphical shell gets all the input information from that graphical shell (just like with hotkeys: when I click several keys, my graphical shell captures it and either does something with it itself or forwards it to applications), don't they?

The issue here lies with the way chromium reacts to scrolling even when it is not in focus.

If what I described above is correct, then it can't be a chromium issue, because chromium shouldn't even know I was scrolling, because cinnamon shouldn't have forwarded this input to chromium.
By the way, it seems like it has nothing to do with the focus: I expect the same behavior both when my cursor is above a focused and an unfocused window

[KreerC]

Input is handled by X11 directly, not Cinnamon.

However, I've found a workaround. I've edited line 87 of /usr/share/cinnamon/cinnamon-settings/modules/cs_accessibility.py to include the Shift key in the settings:

zoom_key_options = [["", _("Disabled")], ["<Alt>", "<Alt>"],["<Super>", "<Super>"],["<Control>", "<Control>"], ["<Shift>", "<Shift>"]]

Blink/chromium applications do not seem to respond to scrolling when Shift is pressed, but using that might have some unintended side effects that I must still discover in regular use. But of course this is only a hack, not a permanent fix for the underlying issue. Edit: It seems like Shift triggers horizontal scrolling using the mousewheel. Depending on the applications this might be a deal breaker as well 😞

During my digging, I've found that the chromium team is working on "Unified scrolling", which to my understanding removes scroll handling from the blink engine completely and offloads it to some other component. Let's hope that'll fix the problem for the future.

[tgrushka]

This issue is 5 years old now. I'm thinking of opening a new one again because it seems to have been forgotten. I'm legally blind and use zoom all the time, and it has nothing to do with chromium or any underlying app, it is because libinput or whatever in X11 is passing through the scroll event instead of capturing it. It's definitely an issue with X11, but Wayland seems so bad with a11y, and everyone is moving to it anyhow, without addressing the a11y issues.

[dkaraush]

I fixed it here: linuxmint/muffin#838