GNOME Bugzilla – Bug 599097
For mouse and sloppy focus, return to "mouse mode" on motion
Last modified: 2020-11-06 20:07:08 UTC
The "mouse mode" idea that was introduced in bug 167545, and the handling of denied focus windows can leave the user with a mismatch between the mouse window and focus window. When the user returns to mousing they have no easy way to fix this. This patch attempts to fix this; its a little experimental, in that it seems like a good idea to me and works OK in some quick testing, but I'm a click-to-focus user myself. Assuming that it holds up to further testing, I'm planning to add this as a GConf-controlled option in our enterprise-Linux packages (it was created in response to problems customers were having), but the GConf option is just being conservative, and the patch here is unconditional, because I can't really think of any reason a user *wouldn't* want this; it seems like a straight-up improvement. Potential downsides: - Slight increase in CPU usage because of the polling with XQueryPointer. (It's done at 5hz here, which actually is a noticeable delay, it might be better to up that to 10hz, and eat a slightly greater overhead.) This would be worse if a user alt-tab'ed then left their computer without touching the mouse again; as soon as the mouse is touched after alt-tab, the timeout is removed. It's potentially possible to fix this by watching X idle time, but gnome-screensaver has had a lot of problems with that timer, and I doubt it is worth complexity. - If someone has a flaky mouse or keeps accidentally touching their touchpad and moving the pointer, keynav between windows could become more annoying, since the next time the mouse moved, the focus would go back. However, someone in that situation is also certainly using click-to-focus (or should be.) There's a requirement of moving the mouse 2 pixels in this patch to deal with a pointer that is jittering in place.
Created attachment 145885 [details] [review] For mouse and sloppy focus, return to "mouse mode" on motion For mouse and sloppy focus, there are various cases where the focus window can be moved away from the focus window. Mostly these relate to "display->mouse_mode = FALSE", which we enter when the user starts keynav'ing, but it can also occur if a window is focus-denied mapped and mapped under the pointer. Prior to this patch, there was no fast way for the user to start interacting with the window - if they just clicked on the window, the click would be passed through, and could disturb the windows contents, so the user had to either mouse out and then mouse back in, or go up and click on the titlebar. With this patch, when we get into this state, we add a timeout and poll for pointer motion with XQueryPointer. If the user then moves the pointer (more than a single pixel to handle jitter), we focus the window under the pointer and return to mouse mode.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.