Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wf-panel does not lose keyboard focus when closing menu #2118

Closed
dkondor opened this issue Jan 31, 2024 · 2 comments · Fixed by #2119
Closed

wf-panel does not lose keyboard focus when closing menu #2118

dkondor opened this issue Jan 31, 2024 · 2 comments · Fixed by #2119
Labels

Comments

@dkondor
Copy link
Contributor

dkondor commented Jan 31, 2024

Describe the bug
I found it nice to have the new feature to open / close the menu with a keyboard shortcut (from #2097), but I found that when closing the menu with the keyboard, the panel retains the keyboard focus. To me, the natural behavior would be that the last focused app gets back the focus. I feel that this is actually the intended behavior, since wf-panel sends a zwlr_layer_surface_v1#40.set_keyboard_interactivity(0) request when the menu is closed. Also here, it is indicated that a refocus might happen as a consequence of changing keyboard-interactivity, but the arrange_layers() function does not seem to handle focus changes.

To Reproduce
Steps to reproduce the behavior:

  1. Run wf-panel and open the menu (with at least one open view).
  2. Close the menu with keyboard interaction (pressing ESC, or the shortcut set for wayfire-shell/toggle_menu).
  3. The panel keeps keyboard focus.

Expected behavior
The last focused view gets back the keyboard focus.

Wayfire version
latest git (9c9630d)

@dkondor dkondor added the bug label Jan 31, 2024
@ammen99
Copy link
Member

ammen99 commented Jan 31, 2024

That comment which says rearranging the layers will update cursor focus seems quite outdated. We probably need to simply refocus at the end of the function, if the interactivity has changed. We already have one such check, so probably it should just be extended to handle more cases.

@soreau
Copy link
Member

soreau commented Jan 31, 2024

Seems like a duplicate of #2047.

soreau added a commit that referenced this issue Feb 1, 2024
This effectively makes it so the view that had focus before interacting
with wf-shell apps, is focused after interactivity is complete.

Fixes #2118.
Fixes #2047.
soreau added a commit that referenced this issue Feb 4, 2024
 arranging layers

This effectively makes it so the view that had focus before interacting
with wf-shell apps, is focused after interactivity is complete.

Fixes #2118.
Fixes #2047.
ammen99 pushed a commit that referenced this issue Feb 4, 2024
 arranging layers

This effectively makes it so the view that had focus before interacting
with wf-shell apps, is focused after interactivity is complete.

Fixes #2118.
Fixes #2047.
ammen99 pushed a commit that referenced this issue Mar 13, 2024
 arranging layers

This effectively makes it so the view that had focus before interacting
with wf-shell apps, is focused after interactivity is complete.

Fixes #2118.
Fixes #2047.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants