GNOME Bugzilla – Bug 440079
Orca cannot arrow past certain combo boxes in Firefox
Last modified: 2008-07-22 19:27:03 UTC
Steps to reproduce: 1. Launch GMail and switch to the basic HTML view 2. Attempt to use Down Arrow to move beyond the "More Actions" combo box Expected results: You'd continue to move down through the page content Actual results: You get stuck, with each press of Down Arrow causing Orca to say "More Actions... Menu item, More Actions... combo box" I'm seeing a similar behavior trying to Down Arrow past the GNOME version combo box in bugzilla. In that case, focus keeps bouncing back to the GNOME version link.
You know, I think this is one of those things that slipped through the cracks. I went quite a ways back in Firefox and Orca and merely arrowing to a combo box was never quite right when Orca is controlling the caret. Oops! Now that I'm looking at making it right, I realize that I don't know what "right" is. It seems there are two possible user experiences: 1. If you arrow to a combo box, that combo box should get focus so that you can start selecting things in it. Advantage: Seems to make sense (i.e. you've found a combo box and Up/Down Arrow is how you select things in combo boxes). Disadvantage: If you were just "passing by," you probably don't want to be arrowing through all of the items, especially if there are a lot of them (e.g. the Product combo box in GNOME's bugzilla). 2. If you arrow to a combo box but did not explicitly give it focus by moving there with Tab/Shift+Tab or Orca_Modifier+Tab/Orca_Modifier+Shift+Tab, Down Arrowing should move you off of it. Advantage: You don't suddenly find yourself in a combo box you didn't want to be in. Disadvantage: What if you wanted to be in that combo box? Mike please let me know what should occur. Thanks!
> > 1. If you arrow to a combo box, that combo box should get focus so that you can > start selecting things in it. Advantage: Seems to make sense (i.e. you've > found a combo box and Up/Down Arrow is how you select things in combo boxes). > Disadvantage: If you were just "passing by," you probably don't want to be > arrowing through all of the items, especially if there are a lot of them (e.g. > the Product combo box in GNOME's bugzilla). This option fills me with much sadness and I fear users would be quite frustrated with this possibility. > > 2. If you arrow to a combo box but did not explicitly give it focus by moving > there with Tab/Shift+Tab or Orca_Modifier+Tab/Orca_Modifier+Shift+Tab, Down > Arrowing should move you off of it. Advantage: You don't suddenly find > yourself in a combo box you didn't want to be in. Disadvantage: What if you > wanted to be in that combo box? I think this is a good idea with one addition. I believe that on the web alt+up and down arrow are always intended to close and open comboboxes. How about if we also allow this to happen if a user arrows to a combobox with orca controling the caret? >
Created attachment 88905 [details] [review] Part 1 of the fix This is part 1 of the fix: Don't get stuck, don't bounce around, don't speak the wrong things, etc. Part 2 will be to try to work on the Alt+Down Arrow override that Mike has suggested. (Will if you have any thoughts on that, please let me know. Otherwise, I'll see what I can come up with.) In the meantime, Mike please test; Will please review. Will, I tried to document everything in detail in the comments within the patch. The one thing I didn't document there is the removal of the ROLE_MENU_ITEM check from useCaretNavigationalModel(). 1. If we're not in the document frame, we're already returning False, so this applies only to menu items in the web page. 2. Because of recent changes in Firefox, the only menu items in web pages seem to be items within combo boxes. 3. If a combo box has focus, we get events from the combo box rather than the menu item. 4. Gecko's caret browsing mode doesn't allow you to arrow to such a menu item. Ergo, if we've managed to find a menu item, the combo box doesn't have focus, and Orca is controlling the caret and needs to handle it because Firefox can't.
This looks great as you have it so far. I am now not getting stuck or bouncing around.
> In the meantime, Mike please test; Will please review. The logic looks fine to me. The only anal retentive coding conventions change I'd make would be changing the following from: + if obj.role == rolenames.ROLE_MENU_ITEM and not \ + obj.state.count(atspi.Accessibility.STATE_FOCUSED): to (moving the 'and not' to the beginning of the next line): + if obj.role == rolenames.ROLE_MENU_ITEM \ + and not obj.state.count(atspi.Accessibility.STATE_FOCUSED): Any hoot, we definitely have to special case a lot of code for Gecko. :-(
> The logic looks fine to me. The only anal retentive coding conventions change Done. Thanks! > Any hoot, we definitely have to special case a lot of code for Gecko. :-( Yup... :-( I'm going to file a bug to ask for the SHOWING state, which I believe was taken out as part of the overall a11y combo box cleanup Aaron did. However, it doesn't seem like we're doing any checks based on SHOWING or not -- presumably because we're not getting useful and/or correct info that way. If you have better ideas for how to go about generalizing this stuff, I'm all ears! In the meantime, patch committed.
Created attachment 88978 [details] [review] Part 2 of the fix This patch adds a new keybinding to do the "let's pretend we're on a combo box even though we're really not on a combo box, because we're sorta on a combo box and, gosh, we really would like to expand even though it doesn't have focus" thang. :-) :-) :-) In order to test this, you have to be able to arrow to a line in which the first thing on that line is a combo box. There aren't too many of these because labels usually come first. A nice one you can use, however, is the combo box on bugzilla's Create New Attachment page. It's right after the line that reads, "Initial status: Select the initial status for the attachment, if any". When you land in it, Orca should say "menu item none" because technically the thing with focus is the menu item and not the combo box. At that point, press Alt Down Arrow. Orca should give focus to the combo box and then expand it -- just like we were on it for real. :-) Thoughts?
> any". When you land in it, Orca should say "menu item none" because > technically the thing with focus is the menu item and not the combo box. At > that point, press Alt Down Arrow. Orca should give focus to the combo box and > then expand it -- just like we were on it for real. :-) For speech, the user experience for comboboxes is something like: [label] <selected item> 'combo box' Where [label] is the label (if it exists), <selected item> is the item showing in the combobox, and 'combo box' is the role name. If we end up saying 'menu item none', this seems to reverse the order in which things are spoken and it also doesn't let the user know they are on a combobox. In the case where we are in a menu item that's a child of a combobox, should we just speak the combobox logic instead of menu item? PS - comboboxes have been and always will be screwy.
> In the case where we are in a menu item that's a child of a combobox, should we > just speak the combobox logic instead of menu item? Even though this is not exactly what is going on I think speaking these as if they were just comboboxes is the right thing to do.
I just spoke with Mike about this. The original bug -- and the reason for the urgent/major status -- is the fact that we could not get past certain combo boxes. This has been fixed and the patch checked in. In working on the "part 2" aspect of this problem, I discovered that the various and sundry changes that have been -- and still are -- taking place with respect to combo boxes in Firefox necessitate a refactor. Therefore, I've opened bug 442709 for that with a target of 2.19.4 and am closing this one as FIXED.