GNOME Bugzilla – Bug 472029
Cannot arrow into autocompletes in HTML forms if Orca is controlling the caret
Last modified: 2007-10-07 15:54:43 UTC
Steps to reproduce: 1. Locate an entry in a form which you have previously used (e.g. Google search entry). 2. Type a letter or two that matches a value you had typed in that entry before (old search term). At this point an autocomplete will appear beneath the entry. If Orca is controlling the caret, you cannot arrow into it; if Gecko is, you can.
Created attachment 94678 [details] [review] patch to solve the reported problem This solves the reported problem. There was one case I wasn't sure how to handle: If you are in an entry and haven't typed anything and Orca is not controlling the caret, pressing Down Arrow causes an autocomplete to appear. If a user happens to be in an empty entry and presses Down Arrow to move off of that entry, suddenly finding him/herself in the list of previously entered values might be confusing/unwanted. By the same token, a user might intentionally press Down Arrow to get into the list and can't without switching to a Gecko-controlled caret. So.... I just didn't address that case. :-) The other thing I was wondering is do we want to speak anything when the autocomplete list appears so that the user knows there's something he/she can Down Arrow into? Mike, please test the patch and also give some guidance on what if anything we want to do about the case I didn't handle and whether or not we should announce the appearance of the list (post string freeze of course). Thanks!
This looks like a good patch for trunk and gnome-2-20. I'm not sure what to do about the case when arrowing down in an autocomplete when the autocomplete menu is not up -- we skip the list when Orca is controlling the caret and enter it when Gecko is controlling the caret. For Mike, I think some additional/rephrased questions include: 1) Is it OK for down arrow to not pop up the autocomplete list when Orca is controlling the caret? The current patch does this. 2) If it is not OK, the implication is that we may end up with a situation where the only way out of the autocomplete entry is left/right/tab. Up/down will be used for the autocomplete list. Is that OK? Joanie - in the event #1 is not OK, is there an attribute we can look at that can help us make more decisions about what to do? I see an attribute of 'tag:INPUT', but I'm not sure this implies autocomplete.
> > For Mike, I think some additional/rephrased questions include: > > 1) Is it OK for down arrow to not pop up the autocomplete list when > Orca is controlling the caret? The current patch does this. Yes I'd much rather have the current behavior. I think pulling down the list when the user has typed nothing would really confuse navigation. >
So Mike have you tested the patch and like the patch?
Created attachment 94734 [details] [review] changes to trunk were causing the patch to fail Same patch, trunk friendly. :-)
This looks good for 2.20. I want to have us look at a couple improvements for trunk but that can wait.
In light of a Mozilla bug I just discovered, is this still something we want to commit? (It's not committed to either trunk or the 2.20 branch currently). See: https://bugzilla.mozilla.org/show_bug.cgi?id=394547 The impact of the Mozilla bug is this: If we give focus to the list, then return to the entry, and then press left/right arrow to review the characters in the entry, Orca says nothing. We're fine outside of the entry. We can resume being fine in the entry by moving focus off of it and back. We don't have a problem if we just select an item and move on. And we don't have a problem if we choose not to down arrow into the list. In other words, one has to work a bit to trigger the bug, but once triggered it's not much fun. Thoughts?
> In light of a Mozilla bug I just discovered, is this still something we want to > commit? (It's not committed to either trunk or the 2.20 branch currently). If the Mozilla bug is fixed, will this patch still work? If so, I think the usability gains from this patch are worth it and it should be checked in.
(In reply to comment #8) > > In light of a Mozilla bug I just discovered, is this still something we want to > > commit? (It's not committed to either trunk or the 2.20 branch currently). > > If the Mozilla bug is fixed, will this patch still work? If so, I think the > usability gains from this patch are worth it and it should be checked in. Mike, what's your opinion on the usability risk here? On one hand, we get access to the autocomplete list, making form entries much more convenient. On the other hand, we get flakey behavior from FF until they fix their bug.
I aggree with Will. If it is likely that the firefox bug will be fixed this is worth taking the risk and committing it.
Okie dokie guys, done for both trunk and the 2.20 branch. Mike, shall we keep this bug open for the additional work you want to do post 2.20 or open a new bug for that?
Lets just keep this one open.
I think this one is now OK to close. I don't think there is any more I want to add here.
Thanks Mike! I just shouted across the room to Mike and he said close this as FIXED rather than move it to pending. Done.