Yes, confirmed in both 18.04 and 19.04. Although the mode changed names
from "Sloppy" to "Focus on Hover". It's still the same bug.
However I can see the window highlight change is also delayed. So I
expect that delay is the problem.
** Summary changed:
- keystrokes go to wrong window immediately after moving mouse to change window
focus
+ "Sloppy" or "Focus on Hover" window focus is slow to respond, some keystrokes
go to the wrong (old) window
** Changed in: gnome-shell (Ubuntu)
Status: Incomplete => Confirmed
** Changed in: mutter (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/1814839
Title:
"Sloppy" or "Focus on Hover" window focus is slow to respond, some
keystrokes go to the wrong (old) window
Status in gnome-shell package in Ubuntu:
Confirmed
Status in mutter package in Ubuntu:
Confirmed
Bug description:
Ubuntu 18.04. Gnome X11 session.
When window focus policy is set to follow the mouse, then if the mouse
is moved into a new window and keystrokes typed immediately
afterwards, the keystrokes go to the old window (invariably causing
application errors).
This is extremely annoying for rapid-fire developers, who for example
run vim in one window to edit a script and bash in another to test the
script; the sequence 1) save changes in vim; 2) move mouse to the bash
window; 3) type the command to run the script results in the shell
command (or part of it) being received by vim in the old window (with
occasionally-entertaining effects).
It seems like mouse-movement events are not kept in-order with respect
to keyboard events. I can see the mouse pointer move to the new
window before I type on the keyboard, so I know the mouse-move events
have been received before the keystrokes.
Speculations:
This might be a window-manager bug: Although the mouse cursor has
moved before I type, the window borders may not yet have changed to
indicate a changed focus (not certain because the sequence is so
quick). Therefore the window manager might be (erroneously)
continuing to pass keystrokes to the "current" (i.e. old) window after
the mouse moves into the new window. I'm assuming here that the
window manager is able to receive mouse-move and keyboard events in a
single stream, or timestamped, or otherwise marked so they can be
processed in the order they originally occurred.
Or maybe Xorg does not keep them in order or doesn't allow the window-
manager to know their relative order. Or maybe keystrokes are going
directly to the old window without filtering for the current mouse
position (if this is the case, then IMO xorg should be told to stop
delivering keystrokes if the mouse is outside a specified region until
the window-manager tells it to resume delivery; or some similar way to
allow the focus-change to occur first).
STEPS TO REPRODUCE:
1. Run gnome-tweaks, set Windows->Window Focus to "Sloppy"
2. Open two vertically-adjacent gnome-terminal windows
3. Put cursor in the top window. Wait 2 seconds.
4. Move mouse (with one hand) rapidly into the other window, then
(immediately) type a character into the other window (with the other hand)
ACTUAL RESULTS: The keystroke appears in the old window
EXPECTED RESULTS: Keystroke appears in the new window (i.e. the
keystroke is not processed at all until the window manager completes
the focus change). In other words, "typeahead" should encompass both
keystrokes and mouse movements.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1814839/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
