| Summary: | When tabbing through UI elements of almost all tray widgets, focus eventually gets stuck on the pin button | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | nilskemail+kde |
| Component: | System Tray widget | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cwo.kde, materka, nate |
| Priority: | NOR | Keywords: | accessibility, usability |
| Version: | 6.3.1 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/-/commit/3c629e29cb1340bd9b84bb87ca5e69f09297165e | Version Fixed In: | 6.3.3 |
| Sentry Crash Report: | |||
|
Description
nilskemail+kde
2025-02-24 23:44:05 UTC
Can confirm. Seems to happen for all System Tray widgets, in fact. (In reply to Nate Graham from comment #1) > Can confirm. Seems to happen for all System Tray widgets, in fact. The media widget seems to be an exception here That's true! (In reply to Nate Graham from comment #1) > Can confirm. Seems to happen for all System Tray widgets, in fact. Doesn't seem to happen in brightness for example, nor klipper (though klipper might want to have a tab stop for the history list added – it's not quite clear-cut though). I can confirm that several widgets sometimes get stuck on forward-tabbing. Though it seems to depend on the specific circumstances and state; sometimes it seems to work in the exact same widget where it didn't before. The invisible tab stops in the network widgets are focus landing on the buttons for one of the list entries; if you have a lot of networks near you this might be outside the visible area. I guss this could be a bit tricky to solve as the list of networks is asynchronous, otherwise it would make sense to always focus the first one but we wouldn't want focus to change as networks are found, and scrolling around might also not be a good idea. Though I guess in most cases, by the time the user has tabbed to the button, the top of the network list would have usually settled I guess. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5263 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5264 Git commit 28f14755fc51fc0cf84777c448c445e3f142ffb8 by Christoph Wolk. Committed on 28/02/2025 at 14:23. Pushed by cwo into branch 'master'. applets/systemtray: fix tab focus after pin button The tab focus in the expanded representation uses a rather complex assignment where KeyNavigation.backtab in the loaded representation is assigned to the backtab of its container. This actually works in the backtab direction quite well, but breaks poor KeyNavigations implicit reverse assignment, which does not get sufficiently updated when a new representation is loaded. Depending on the precise circumstances, it often ends up still assigned to the previously loaded representation which obviously can't be focused anymore, so focus just ends up stuck in tab direction. Instead, just set tab focus explicitly to the first entry in the representation's focus chain. This is not always the optimal tab chain experience by itself, but it's at least something generally reasonable that individual applets can build on. M +1 -0 applets/systemtray/package/contents/ui/ExpandedRepresentation.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/28f14755fc51fc0cf84777c448c445e3f142ffb8 Git commit 3c629e29cb1340bd9b84bb87ca5e69f09297165e by Christoph Wolk. Committed on 28/02/2025 at 16:04. Pushed by cwo into branch 'Plasma/6.3'. applets/systemtray: fix tab focus after pin button The tab focus in the expanded representation uses a rather complex assignment where KeyNavigation.backtab in the loaded representation is assigned to the backtab of its container. This actually works in the backtab direction quite well, but breaks poor KeyNavigations implicit reverse assignment, which does not get sufficiently updated when a new representation is loaded. Depending on the precise circumstances, it often ends up still assigned to the previously loaded representation which obviously can't be focused anymore, so focus just ends up stuck in tab direction. Instead, just set tab focus explicitly to the first entry in the representation's focus chain. This is not always the optimal tab chain experience by itself, but it's at least something generally reasonable that individual applets can build on. (cherry picked from commit 28f14755fc51fc0cf84777c448c445e3f142ffb8) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +1 -0 applets/systemtray/package/contents/ui/ExpandedRepresentation.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/3c629e29cb1340bd9b84bb87ca5e69f09297165e |