| Summary: | With Wayland menu keyboard navigation (left/right keys) closes all menu | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Mykola Krachkovsky <w01dnick> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nate |
| Priority: | NOR | ||
| Version First Reported In: | 5.26.90 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/aa01ae5a95de4f6639b103e9f706577d5393ec54 | Version Fixed/Implemented In: | 6.2.0 |
| Sentry Crash Report: | |||
| Attachments: |
Opened submenu
Window menu |
||
|
Description
Mykola Krachkovsky
2023-02-06 18:12:25 UTC
> Open context/hamburger menu
Can you be more specific please?
It's about Qt sub-menu keyboard navigation. when navigating to a sub-menu, pressing the left arrow key closes the whole menu structure, not just the sub-menu. I can confirm this in KDE apps with native menus. (In reply to Vlad Zahorodnii from comment #1) > > Open context/hamburger menu > > Can you be more specific please? Basically any context/hamburger menu in Qt5 Widget application, e.g. Dolphin hamburger&context menu menu, Falkon context menu, Krusader bookmarks menu, etc. As a test you can open Dolphin hamburger menu, then with keyboard navigate to Create (New?) submenu, and then press left go up level. And whole menu is closed not just submenu. I'll add a screenshot. Created attachment 156094 [details]
Opened submenu
If at this point you'll push left button to go back to upper menu, whole menu will be closed, not just submenu.
Created attachment 156095 [details]
Window menu
Also with regular menu, pressing Left or Right also closes menu instead of moving to previous/next item.
(In reply to Nate Graham from comment #2) > It's about Qt sub-menu keyboard navigation. when navigating to a sub-menu, > pressing the left arrow key closes the whole menu structure, not just the > sub-menu. I can confirm this in KDE apps with native menus. This sounds like a client bug (qmenu or qtwayland) not the compositor bug. (In reply to Vlad Zahorodnii from comment #6) > This sounds like a client bug (qmenu or qtwayland) not the compositor bug. I might have been wrong with this assessment, I can reproduce the issue, and I think I know what's causing it. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6544 Git commit 19c467147a06e12e511f7dfd9b89c6c73c50834b by Vlad Zahorodnii. Committed on 01/10/2024 at 18:52. Pushed by vladz into branch 'master'. Move keyboard focus to grabbing popup immediately It seems that QMenu expects to receive keyboard focus when it's mapped, otherwise keyboard input breaks when using pointer input. In either case, kwin should move keyboard focus immediately rather than do it on demand. M +2 -0 src/popup_input_filter.cpp https://invent.kde.org/plasma/kwin/-/commit/19c467147a06e12e511f7dfd9b89c6c73c50834b Git commit aa01ae5a95de4f6639b103e9f706577d5393ec54 by Vlad Zahorodnii. Committed on 02/10/2024 at 10:24. Pushed by vladz into branch 'Plasma/6.2'. Move keyboard focus to grabbing popup immediately It seems that QMenu expects to receive keyboard focus when it's mapped, otherwise keyboard input breaks when using pointer input. In either case, kwin should move keyboard focus immediately rather than do it on demand. (cherry picked from commit 19c467147a06e12e511f7dfd9b89c6c73c50834b) M +2 -0 src/popup_input_filter.cpp https://invent.kde.org/plasma/kwin/-/commit/aa01ae5a95de4f6639b103e9f706577d5393ec54 |