GNOME Bugzilla – Bug 512103
Orca speaks too much of the context in FF3
Last modified: 2009-03-10 00:04:42 UTC
This is a spin-off bug from bug 509394. In that bug, we were sometimes failing to speak the first focusable object when tabbing to it from the document frame when the document frame happens to be focusable. In fixing that, I noticed that we were speaking too much of the context when tabbing to the document frame. I came up with a hack to solve that problem, but the hack was in default.py and, upon closer examination, shouldn't have worked or been necessary. See http://bugzilla.gnome.org/show_bug.cgi?id=509394#c15 and the comments that follow. Something odd is going on, and my money is that it's going on in Firefox, but I haven't been able to figure it out yet (see aforementioned comments). IMHO, it's one thing to add Firefox hacks/workarounds to Gecko.py and another to add them to code that impacts all of Orca. Therefore, I nixed the hack. This bug is to get to the bottom of that issue and what's going on with the hierarchy.
Retargeting to FUTURE because we're just about at the "pencils down" point and, alas, I doubt I will have worked out what oddness is taking place with the accessibles in question in the hours between now and code freeze. :-(
First coarse pass at GNOME 2.24 planning.
Created attachment 109453 [details] [review] revision 1 This patch: 1. Speaks the context up to, but not including the document frame as well as internal frames. Thanks Will for the suggestion! Seems to work. :-) 2. Includes a little bit of clean up to getSpeechContext() 3. Adds autocomplete to the list of roles we want to skip. Currently we speak them unless they are in a toolbar (like location and search). In those instances, we say things like "Search using Google autocomplete, search using Google text." I spoke with Mike on the phone and he indicated that saying "Search using Google text" was fine. So how then does a user know that it's an autocomplete? a. If it's a single-line entry in Firefox and you can type in it, odds are that it's an autocomplete. :-) The Find toolbar seems to be the exception rather than the rule. b. What's important (I think) is not that there is *potential* for a list to appear, but rather that a list *has* appeared to which you can Down Arrow. When the autocomplete list appears, we do nothing to pass that fact along to the user. We probably should. :-) I opened an RFE (bug 528644) for that. This pylints. I am about to start the regression tests, but it would be nice if it had some functional testing in the meantime. Thanks!
So far with my testing this seems a lot better! Lets see how the tests play out but I'm liking the change so far.
Thanks Mike. The tests played out nicely with one minor exception: XUL combo boxes. Part of my "as long as I'm in there, let's clean things up" thang was to remove a small bit of code that a comment indicated was for "earlier versions of Firefox". Apparently it still applies. <smile> Or rather, it has an impact. I'll investigate that tomorrow and post a new patch.
Created attachment 109510 [details] [review] revision 2 This puts (a modified version) of the menu check back: If the parent is a menu and its parent is a combo box, the context to be spoken is the combo box and not the menu. Pylinted and regression tested. Please test.
This one seems like a nice improvement.
Thanks Mike. Committed to trunk. Moving to pending.