GNOME Bugzilla – Bug 554002
Orca App-Preferences dialog page tabs are "off" by one in speech and braille
Last modified: 2008-11-24 06:33:40 UTC
From Rich C on the Orca list: ---------- Odd thing here: the entries in the tab list do not correspond to the actual tab panels. I.e. when you move to the key echo" tab, the braille page shows. When you move to the "magnifier" tab, the key echo page is displayed. etc... ---------- Confirmed, both for speech and braille when navigating the App Preferences dialogs.
Note to self: This issue does not seem to happen with trunk in OpenSolaris. It does happen reliably in Intrepid. Gtk+ issue??
Created attachment 120618 [details] [review] revision 1 In the app-specific preferences dialog (where we've decided not to show the General page), the accessible text associated with tab N is the accessible name of tab N - 1. If we use the actual name of the page tab (assuming there is a name) rather than its text, this Gtk+ bug seems to be worked-around (work-arounded?). This patch strikes me as being potentially high impact and presumed low risk. I'll start the regression tests, but unless I'm missing something fundamental, I'm leaning towards checking this in for 2.24.1 and then trying to pin down the exact Gtk+ (or Gail or ... ) which triggered this. Thoughts?
I ran the full set of gtk-demo tests, all the of the Web 2.0ish (aria and dojo) tests, and the xul page tab test. All passed. I can run the others, but I'm relatively certain that the other tests don't address page tabs. Unless some of the java tests do, but I've don't have a working access bridge installation atm. :-( Based on this, Will, please review. (And if there are any java tests that apply, and you have the time to run them against this patch, that would be awesome.) Thanks!
Looks good to me. Not terribly risk since tab names generally are the same as the accessible text. I'm curious how the tabs end up looking in flat review, though (not that I'm saying we should scramble to fix that, too, if it's still broken there).
> I'm curious how the tabs end up looking in flat review, Cuh-rap. Didn't occur to me to check that. Sorry! Yeah, they're messed up there as well. > though (not that I'm saying we should scramble to fix that, too, if it's still > broken there). Good. :-) Because I have DayJob stuff I really need to get back to atm. I assume it's going to be another, similar "quick fix" but I'd want to test it etc. What time today were you planning on doing the release? Anyhoo, the focus tracking patch has been committed to trunk.
I have just varified with a tieman voyager display that things appear fine now. Thank you
CC'ing Li Yuan on this to see if he has any ideas on why we might be seeing this bizarre tab behavior. Li - to reproduce this, you can press Ctrl+Insert+Space to bring up Orca's application specific preferences dialog. When you do so, Orca ends up getting the accessible text off by 1 tab.
I can see this bug by comment out the patch. I also tested "Profile Preference" in gnome-terminal, everything works fine. In accerciser, Orca's preferences dialog's tabs are shown correctly. And I found there is "General" page in the glade file but not shown when Orca is running, maybe relative to this bug?
(In reply to comment #8) > I can see this bug by comment out the patch. I also tested "Profile Preference" > in gnome-terminal, everything works fine. In accerciser, Orca's preferences > dialog's tabs are shown correctly. And I found there is "General" page in the > glade file but not shown when Orca is running, maybe relative to this bug? The "General" page is shown for the normal view of the preferences dialog (Insert+Space) ends up getting hidden when Orca brings up the app-specific preferences dialog (Ctrl+Insert+Space). As such, it's like that this hidden tab is tickling a bug somewhere. I'm trying to find a working GNOME 2.22 system I can test on, but I don't have easy access to one right now. I wonder if something might have changed in gail and/or GTK+ that might have caused the accessible text interface for a tab to behave differently in the presence of hidden tabs?
(In reply to comment #9) > I'm trying to find a working GNOME 2.22 system I can test on, but I don't have > easy access to one right now. I wonder if something might have changed in gail > and/or GTK+ that might have caused the accessible text interface for a tab to > behave differently in the presence of hidden tabs? I was able to test Orca from trunk on a GNOME 2.22.2 system (OpenSolaris b98). When I remove the patch, Orca still says the right thing for the pages. So, this does make me really wonder if something changed in GAIL or GTK+ to cause the new behavior to crop up. Li, do you have any ideas or recollection of things that might have changed?
Created attachment 122042 [details] Accerciser screen shot (In reply to comment #8) > In accerciser, Orca's preferences dialog's tabs are shown correctly. Not for me. In this screenshot the name is correct but the text is not. What's interesting is that the text seems to be the right length; just the wrong string.
(In reply to comment #10) > (In reply to comment #9) > > I'm trying to find a working GNOME 2.22 system I can test on, but I don't have > > easy access to one right now. I wonder if something might have changed in gail > > and/or GTK+ that might have caused the accessible text interface for a tab to > > behave differently in the presence of hidden tabs? > > I was able to test Orca from trunk on a GNOME 2.22.2 system (OpenSolaris b98). > When I remove the patch, Orca still says the right thing for the pages. So, > this does make me really wonder if something changed in GAIL or GTK+ to cause > the new behavior to crop up. Li, do you have any ideas or recollection of > things that might have changed? > I don't remember anything change in GAIL. I can take a look at GTK+. How does Orca hide the general page?
> I don't remember anything change in GAIL. I can take a look at GTK+. How does > Orca hide the general page? In app_gui_prefs.py, initAppGuiState does a remove_page.
Created attachment 123047 [details] [review] Patch to hide the tab instead of remove it This patch hides the general tab instead of removing it. It lets Orca do the right thing with respect to focus tracking and flat review. Committed to trunk and gnome-2-24.
Reassigning this to gail. I think there might be some signal being missed when a child is removed from a container. I'm not exactly sure where it might be occurring, but I wonder if the call to gtk_container_remove in the gtk_notebook_remove_page method of http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtknotebook.c?view=annotate is resulting in a signal that is handled by gail?
Created attachment 123087 [details] [review] patch Thanks for your hint Will! The simple patch works on my machine.
The problem is that gail accidentally update the children cache when the "remove" signal comes in. So the "children-changed::remove" sends out the child whose index is 0 _after_ the removal. (Orca is removing the first page in this case.)