GNOME Bugzilla – Bug 672242
Orca presents an extra panel on places&devices and documents search result buttons
Last modified: 2012-06-01 14:12:04 UTC
STEPS TO REPRODUCE 1. Launch Orca 2. Move to Overview (Alt+F1) 3. Start a search with "Connect" 4. Navigate until "Connect to ..." under PLACES&DEVICES EXPECTED OUTCOME On "Network connections" Orca presents "Network connections PUSH BUTTON" On "Connect to ..." Orca presents "Connect to ... PUSH BUTTON" ACTUAL OUTCOME "Network connections" works fine With "Connect to ..." Orca present "Connect to ... PUSH BUTTON Panel"
Created attachment 209941 [details] [review] Sets role/label_actor on SearchResult.content Looking at searchDisplay.SearchResult, the last object that will receive the focus is not SearchResult.actor but SearchResult.content. And this is the reason it was working with applications and contacts. They both have a custom result actor as provider.createResultActor is not NULL. In both cases, those custom objects they have the proper role and label_actor (in the case of Contacts, added recently on bug 672047). But if no createResultActor is provided, SearchResult creates a default content, and the label_actor was set to SearchResult.actor instead of SearchResult.content. This patch sets the proper label_actor, and also set the proper role on content, as it will be the last one receiving focus. With this change Orca presents "Connect to ... PUSH BUTTON" as properly ignores the intermediate focus on SearchResult.actor (as it is not labeled, and there is a subsequent focus-in on a labeled object).
(In reply to comment #1) > With this change Orca presents "Connect to ... PUSH BUTTON" as properly ignores > the intermediate focus on SearchResult.actor (as it is not labeled, and there > is a subsequent focus-in on a labeled object). Sorry this doesn't happens, as SearchResult.actor has can_focus to false (anyway, the patch works properly). This leads me to think probably there is another way to solve this. Setting SearchResult.actor.can_focus to true, and content.can_focus to false, so the object that will receive the focus will be SearchResult.actor. Then you should set the proper SearchResult.actor.label_actor. Something that it is easy when you don't have a custom ResultActor, as you are creating the icon, but complex in any other case, as you would need to get the label from the custom ResultActor. Something than seems somewhat complex, and that could include some other collateral effects.
Taking into account that this is a minor issue, that today is Friday and next Monday is Code Freeze, and that we still have pending bug 671378, I will not push this bug to be a GNOME Target 3.4.
(In reply to comment #3) > Taking into account that this is a minor issue, that today is Friday and next > Monday is Code Freeze, and that we still have pending bug 671378, I will not > push this bug to be a GNOME Target 3.4. s/push/set
(In reply to comment #3) > Taking into account that this is a minor issue, that today is Friday and next > Monday is Code Freeze, and that we still have pending bug 671378, I will not > push this bug to be a GNOME Target 3.4. Understood and no worries. I am really, really grateful for all your work and all of Dan's and Florian's reviews which made it possible to keep getting fixes in. I think GNOME Shell 3.4 + Orca is going to turn out quite well. In the meantime, the extra panel really is annoying and is easy enough to work around safely in Orca. Therefore, I have done so, clearly marking the workaround. We can remove it once this bug is properly fixed. http://git.gnome.org/browse/orca/commit/?id=2604e3a2c214e828b453cbec3e5f3ad5050c9846 Thanks again!!!
(In reply to comment #3) > I will not push this bug to be a GNOME Target 3.4. => Removing the flag.
Review of attachment 209941 [details] [review]: Could use a more detailed commit message, looks good otherwise
(In reply to comment #7) > Review of attachment 209941 [details] [review]: > > Could use a more detailed commit message, looks good otherwise Commit message extended and committed. Closing bug. Thanks