Repository navigation
[Bug]: Constrained pan/zoom doesn't work on GNOME/Wayland #23436
Description
Bug summary
With any backend I've tested so far (TkAgg / QtAgg / GTK3Agg, installed from conda-forge), beginning a zoom and then press x or y stops input entirely. Pressing a key first before the mouse also prevents the mouse from moving. Once the key is released, the mouse can move again.
Actual outcome
Pressing any key (that doesn't trigger an immediate effect) actually freezes the mouse on Fedora Workstation (tested by me) and Ubuntu (tested by @matthewfeickert); both use GNOME on Wayland.
On Awesome over X, the key/mouse combo works (tested by @tacaswell).
Expected outcome
Zooming with x/y are constrained to the specified direction.
Additional information
If we could find someone running GNOME on X, or KDE on Wayland, we could determine whether this is specific to one or the other.
This also appears to happen in e.g., Firefox or GNOME Text Editor, so it's a general thing, but as you should be able to mix mouse events and keys in games, there should be a way somewhere to enable that. But if not, we may have to change constraints to use real modifier keys, i.e., shift/ctrl/alt.
Activity
anntzer commented on Jul 16, 2022
This works fine for me on KDE+Wayland+{gtk3,gtk4,qt,tk,wx}. On wxagg, however, pressing x/y after the pan starts has no effect (but that's also the case on X).
(The mouse has to be over the window when you press x/y, as that's detected by a key_press_event; there's generically no API to know what key is pressed at a given time other than by dead reckoning, except for modifier keys, which is the case #6159/#16931 (+ following to-be-made PRs) is trying to fix.)
QuLogic commented on Jul 21, 2022
So after thinking about it a bit, I think I figured out what's up. All of us were using our laptops at the sprints, with touch pads. GNOME disables touch pads when typing.
If I use the track point or external mouse instead, then the mouse does not stop moving while a key is pressed. I don't know that there is actually anything we can do about this, other than think about using real modifiers for these options.
matthewfeickert commented on Jul 21, 2022
Nice catch!
Same behavior for me (not surprising). I agree that I don't think there is anything matplotlib can do here (within reason, or even at all).
anntzer commented on Jul 21, 2022
Ah, that's annoying. Is there no way for a window to say that it wants to allow key+touchpad? (perhaps at least when no textbox is focused, which seems like a reasonable use case for general UIs, not just in matplotlib) FWIW I see https://wayland.freedesktop.org/libinput/doc/1.11.3/group__config.html#ga5e30865097b8fa273c3e3cbcdff51b0f.
Sure, we could have e.g. shift-click and alt-click instead of x-click and y-click (ctrl is already taken), but that's much less rememberable...
tacaswell commented on Jul 21, 2022
🤦🏻 I had an external mouse in my backpack we could have tested with.
rcomer commented on Oct 17, 2025
The proposal at #30554 negates the need for x/y keys for zoom.