Bug 452993 - Using the the Tab button shifts active focus between visual elements in a haphazard, unpredictable way
Summary: Using the the Tab button shifts active focus between visual elements in a hap...
Status: RESOLVED DUPLICATE of bug 409540
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Open/save dialogs (other bugs)
Version First Reported In: 5.93.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2022-04-25 15:35 UTC by redashesyellowflowers
Modified: 2025-01-30 17:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description redashesyellowflowers 2022-04-25 15:35:53 UTC
SUMMARY
***
In KDialog, using the the Tab button, shifts active focus between visual elements in a haphazard, unpredictable way. This makes it difficult to predict and use. On top of that, if you switch focus to one particular element, the Directory Contents view, the arrow keys don't seem to work at navigating the contents of the folder! 
***


STEPS TO REPRODUCE
1. Open a browser (Brave used for testing), select a file and try to download it. KDialog opens up.
2. When KDialog first opens, the active focus is on the Name field. Hit Tab and it moves to the Filter field. After this, it gets weird.
3. If you hit Tab a second time, focus jumps to the Icon Size Changer thing. Why did you jump from the bottom of KDialog, skipping the Save and Cancel buttons to jump to this element? People who are trying to save files are probably uninterested in changing the size of icons in the Directory view. Moving focus to this element is unexpected and jarring. I would remove this from the list of active focuses.
4. If you hit Tab a third time, the focus jumps to the Directory Tree view on the left side of KDialog. Why did focus jump from the right of KDialog to the left? If I use arrow keys, I am able to navigate the directory tree. This works as expected. 
5. Hitting Tab a fourth time has unpredictable results; focus shifts to the Save button. Why did focus jump from the left side of KDialog to the very bottom?
6. The fifth Tab takes you to the Cancel button as expected. 
7. The seventh Tab push takes you from the bottom of KDialog back to the very top again, to the File Path field. What is happening? What is there no logical progression? Why is the active focus jumping from the left to the right, from the bottom to the top in a completely unpredictable way? 
8. The eight Tab doesn't take you to another field, it moves focus within the File path field. Which is weird, because the arrow keys do this too. If I wanted to move to the next element, I'd press Tab. If I wanted to move around with the File Path field, I'd use arrow keys. Please stop using Tab to move within the File Path field.
9. After repeatedly pressing Tab to move through File Path, focus shifts to the Directory Contents view. Not that you would know it because there is almost no visual indicator. And in a way that is the opposite of the File Path field, neither Tabs nor arrow keys seem to efficiently move through the field. There are stutters and gaps in this cycling that escape my understanding. May I recommend sticking to using the Tab button to move focus around and the arrow keys to move sub-focus (within Directory Contents view and File Path field)?


OBSERVED RESULT

To summarize, this is how focus switching works in KDialog right now. I have trouble understanding the logic behind it.

Starting Focus: Name field.
1st Tab: Filter field
2nd Tab: Icon Size Changer
3rd Tab: Directory Tree View
4th Tab: Save button
5th Tab: Cancel button
6th Tab: Directory Contents view
7th Tab: File Path field 
8th Tab+: Cycles Through File Path elements
Nth Tab: Cycles Back to Directory Contents view.
N+1 Tab: Focus Returns to File Path view.

From then on, focus switches back and forth between the File Path field and Directory Contents view.

This is not a optimal focus shift flow. Please rectify this by this deciding which elements in KDialog should have active focus. Keep it to a small number and make sure that hitting Tab predictably cycles through these elements. 

When the Directory Contents view is selected, shift sub-focus to directory elements. Provide a better visual indicator, perhaps by selecting the first element. Ensure that the user can use the arrow keys to navigate the directory's contents.

EXPECTED RESULT

Here is better active focus shift sequence. Rather the shift haphazardly, this sequence shifts focus from one element to another in logical sequence. As the user is probably interested in filling out the Name field, the focus starts there but moves logically from top to bottom and left to right. When the focus switches to the bottom-right of KDialog (the Cancel button), the next tab moves focus to the top-left of the screen (the Directory Tree view) and works its way downwards and rightwards again.

Starting Focus: Name field.
1st Tab: Filter field
2nd Tab: Save button
3rd Tab: Cancel button
4th Tab: Directory Tree view
5th Tab: File Path field (Arrow buttons can be used to navigate file path elements so remove the use of Tabs for this)
6th Tab: Directory Contents view (Enable the use of arrow buttons to navigate directory elements)
7th Tab: Name field again (starting the cycle anew)



SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: KDE Neon 20.04; Fedora 35 

[Fedora KDE 35 Version Numbers Below]
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2025-01-30 17:42:47 UTC
Marking as a duplicate of Bug 409540. The issue of navigation within the view not working properly is tracked by Bug 466206.

*** This bug has been marked as a duplicate of bug 409540 ***