search

YaLTeR / niri

A scrollable-tiling Wayland compositor.
https://matrix.to/#/#niri:matrix.org
GNU General Public License v3.0
4.12k stars 123 forks source link

skip keyboard focus for layer shell surfaces not... #818

Open cmeissl opened 2 days ago

cmeissl commented 2 days ago

...requesting keyboard interactivity

I have seen clients reacting weird when receiving keyboard focus unexpectedly. The last time it was about implicit focus for popups in firefox, which immediately dismissed the popup. Looks like the same applies to layer surfaces not requesting keyboard interactivity.

fixes #311

YaLTeR commented 1 day ago

Hmm, so what is actually causing the issue here? xdg-popup grab docs say (emphasis mine):

During a popup grab, the client owning the grab will receive pointer and touch events for all their surfaces as normal (similar to an "owner-events" grab in X11 parlance), while the top most grabbing popup will always have keyboard focus.

It seems that currently, keyboard navigation does work in Waybar popup menus on niri. Though, on sway it doesn't—keyboard events keep going to the window instead.

While the grab is active, niri will keep setting keyboard focus to the root layer surface, which PopupKeyboardGrab will ignore. When the popup is dismissed, niri sets the keyboard focus straight to something else, i.e. the layout.

(in fact, AFAICT, with this PR, niri will set the keyboard focus to the root layer surface in update_keyboard_focus() with no grab to stop it, so I'm not sure why it helps)

Could it be that the problem is caused by PopupKeyboardGrab restoring the keyboard focus to the root layer surface briefly when the popup is dismissed, like through here or elsewhere? (I'm not sure I entirely understand what code runs when dismissing the popup by pressing Escape, which also sometimes triggers the issue.) Though, I'm not sure why the problem only happens sometimes.