skip keyboard focus for layer shell surfaces not...

[cmeissl]

...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]

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.

[cmeissl]

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.

Yeah, because the layer keyboard interactivity is set to None. Out of waybar, ironbar and lxqt-panel which I tested only lxqt-panel requested keyboard interactivity.

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.

imo it should also exclude layer surfaces not requesting keyboard interactivity here. I updated the PR to do that, so now it behaves the same as in sway.

(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.

No, it has nothing to do with restoring the focus imo. imo it just worked by chance. But it seems the issue is worse when the popup unexpectedly receives keyboard focus then when only the layer surface receives it. (Which happened in the previous version of this PR which only ignored the keyboard grab).