GNOME Bugzilla – Bug 660599
Accessible icon with focus is not correctly reported
Last modified: 2021-06-18 15:17:34 UTC
Created attachment 197920 [details] test script Steps to reproduce: 1. Launch Nautilus 2. Launch the attached test script in a terminal 3. Alt+Tab back to Nautilus 4. Arrow once to move to a different icon 5. Continue arrowing amongst the icons Expected results: The icon just arrowed to would be reported as focused. Actual results: The icon arrowed to in step 4 is always reported as focused regardless of what icon was just arrowed to.
Is this also covered in bug 677509? "focused" is always empty when testing the script, even in the list view (which a11y implementation is handled directly in GTK).
Interestingly enough, it appears that your fix for bug 677509 also solved the problem which caused me to file this bug. So... Yay! (And thank you.) :) Having said that, the problem as reported in the opening comment of this bug still persists. Based on what you said in Comment 1, I guess this bug should be transferred to Gtk+?
I don't think so; it might just be that both GtkTreeView and NautilusIconContainer are broken wrt. handling of focused cells at the moment, or it might be a bug in the listener script or even somewhere else. Honestly I don't know enough about accessibility to figure out how this should work.
(In reply to comment #3) > I don't think so; it might just be that both GtkTreeView and > NautilusIconContainer are broken wrt. handling of focused cells at the moment, > or it might be a bug in the listener script or even somewhere else. Honestly I > don't know enough about accessibility to figure out how this should work. Hmmmm. Well then focusing (sorry) just on Nautilus for the time being: According to the AtkState documentation [1]: ATK_STATE_FOCUSED Indicates this object currently has the keyboard focus When the selection changes as a result of arrowing around, the selected icon arguably has keyboard focus. But this focused state is not indicated in the state set, nor are we seeing any accessible event announcing the focused state change. I *think* if you do the latter, the former will just happen. And if the former happens, the bug is solved. :) Fortunately, as the attachment in the opening report shows, Nautilus is correctly emitting the state-changed signal w.r.t. selection and the selected state is present as expected. Since in this particular case, selected and focused (as defined by Atk) coincide, could you emit a focus signal when selection changes? In terms of testing this to see the current lack of the expected event, just change the attached listener to listen for 'object:state-changed:focused' rather than 'object:state-changed:selected'. [1] http://developer.gnome.org/atk/stable/atk-AtkState.html#AtkStateType
Created attachment 216034 [details] Orca debug.out file I pulled now latest gnome-3-4 branch, and looked the actual state the position index spokening feature related. I think not always correct position index values spokened with Orca for example with my Nautilus desktop when I moving between the icons. Of course I sorted the icons. This debug.out shows following tests: 1. Moving between desktop icons. 2. Orca Where am I command results some icons. 3. My home folder moving between folders in icon view. Joanie, need any fix with Orca side, or need wayting this bug entire fixing to Orca always spokening correct position index values in icon view? Attila
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.