window focus change lags, some keystrokes go to the wrong (old) window
This was previously reported as Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1814839
When focus policy is not click-to-focus, then merely moving the mouse into another window changes the keyboard focus; however keystrokes continue to be delivered to the old window for a short period after the mouse is moved to a new window.
This is extremely annoying for rapid-fire users who for example run vim in one window and a terminal emulator in another. If the user moves the mouse from vim to a terminal and then immediately types a command, the shell command (or part of it) is received by vim in the old window with sometime disastrous (or at least entertaining) effects.
This happens with Gnome+Xorg (gnome-shell 3.28.3). I don't know about Wayland.
STEPS TO REPRODUCE:
- Run gnome-tweaks, set Windows->Window Focus to "Secondary Click" or "Sloppy"
- Open two vertically-adjacent gnome-terminal windows
- Put cursor in the top window. Wait 2 seconds.
- Move mouse (with one hand) rapidly into the other window, then (immediately) type a character on the keyboard (with the other hand)
ACTUAL RESULTS: The keystroke appears in the first (wrong) window
EXPECTED RESULTS: Keystrokes always go to the window under where the mouse cursor appears on the screen, waiting if necessary for the Window Manager. In other words, "typeahead" should encompass both keystrokes and mouse movements.
The desired behavior is that keystrokes typed after the mouse moves outside of a previously-determined focus region are QUEUED until the Window Manager determines a new focus region if any. Queued keystrokes should probably be discarded if the focus moves to a modal/pop-up window, or any window which did not exist at the time the user moved the mouse out of the old focus region (because the user certainly did not anticipate moving the focus to such a window). Note that if keystrokes are queued, they were typed after the user moved the mouse outside the old window, signalling that the focus should be changed. Maybe queued characters should also be discarded after some delay (e.g. 1-2 seconds) if there no current focus, to more likely DWIM.
This can only happen if mouse-move events and keystrokes are kept coherent, either passed through a single queue or timestamped.
If keystrokes all pass through the Window Manager then it could trivially steer them to the correct window if mouse-movement and keystroke events are processed in-order. But I'm guessing that for efficiency, keystrokes are sent directly to the focused window and not through the WM. So...
The display of mouse-movement is necessarily optimized so that the mouse cursor moves faster than the Window Manager can track in real time. So perhaps the window-manager should give the lower-level code a rectangular focus region at the same time as the focus window is specified; the low-level code would deliver keystrokes while the mouse remains within that focus rectangle, but queue keystrokes (up to some limit) when the mouse is outside the focus rectangle, or until the window-manager changes the focus rectangle to cover where the mouse is. When using click-to-focus policy, the WM would always make the focus rectangle be the entire screen. Or something like that.