| Summary: | keyboard focus can be stolen by whatever is under the pointer | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Oded Arbel <oded> |
| Component: | Application Dashboard widget | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | nate, niccolo |
| Priority: | NOR | Keywords: | accessibility, usability |
| Version First Reported In: | 6.4.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Oded Arbel
2025-10-19 06:41:31 UTC
Actually I think initial focus depend on where the pointer is. Whatever elements it begins over appears to get focus. Regardless, I agree that focus should be on the Favorites grid. Currently keyboard focus is not on the categories but on the textbox, which is correct since that's where you can type to search. Having the keyboard focus not be on the textbox but on the favorites section and then redirect the keypresses can cause issues with e.g. the compose key. Is the search field actually focused on open? It eats text events and becomes focused, but I don't see that it actually starts with focus. Thus, it suffers from the same issue as Bug 459269. I've opened Bug 510871 to track this. (In reply to Niccolò Venerandi from comment #2) > Currently keyboard focus is not on the categories but on the textbox If you mean the search at the top of the screen, then it isn't a text box: it has no border or inset, there's no text cursor and it doesn't look focused. It looks like a label that says "Type to search...", and when you start typing it changes to "Searching for '{TEXT}'" - so it doesn't behave like a text box either. Compare with the search text box in the overview. The element that visibly has the focus is the "Recent Applications" category, and when I press LEFT, the last application on the first row of the recent applications list is focused - as one would expect - which doesn't prevent the search functionality from responding to typing. (In reply to Nate Graham from comment #1) > Actually I think initial focus depend on where the pointer is. Whatever > elements it begins over appears to get focus. Correct, if the mouse pointer is locate somewhere that when the application dashboard appears, there's something under the cursor - it will be in focus. On a system were the mouse is seldomly used - such as a home theater PC - the mouse pointer position is rarely relevant for this behavior, and if it is - that behavior is probably unexpected and unwanted. I would even make the assertion that this behavior is always wrong - when the application dashboard is opened by a keyboard shortcut, the mouse pointer position should be ignored until (and if) the mouse is moved. The dashboard should behave as if the mouse pointer doesn't exist (until the mouse moves): this is how application menus behave - if you press ALT+F to access the "File" menu, even if the mouse pointer is where the menu appears, pressing DOWN will focus the first entry in the menu regardless of which entry the mouse pointer is over. It seems like there are two issues here: 1. Focus is *supposed to* be on the search field by default, but it isn't for the first launch. That's Bug 510871. 2. Focus can be stolen by whatever is under the pointer The search field looks more like a normal search field in Plasma 6.5. Let's use this bug report to track #2. Now that I have 6.5, I can see the new search UI, and the behavior there isn't great: - If the search box isn't focused, pressing RIGHT ARROW gets you to the first favorite (this is good), or pressing DOWN ARROW gets you the last favorite on the first line (this is not great). - If the search box is focused, pressing the arrow keys does nothing (compare with Application Launcher where pressing the arrow keys on an empty search box moves the Favorites selection), while pressing Tab brings you to the first item in the "Applications" list (not the Favorites - this is bad). Should I open a new ticket to track this behavior? Yes please! (In reply to Nate Graham from comment #7) > Yes please! created bug #511146 |