GNOME Bugzilla – Bug 127430
Conflict between entry/completion key bindings
Last modified: 2011-02-04 16:16:03 UTC
Using begin (?) and end keys to select first/last item in the autocompletion conflicts with the entry keybindings (goes at beginning and at the end of the text). If I remember correctly we thought to use begin/end instead of cycling which could have been bad for accessibility. Not really sure what to do here ... Dave, if you have no ideas too, maybe we can cc someone good on keybindings :)
ccing calum the master of keybindings.
Is this the widget that's now used in the Epiphany location bar, or is it using something different? Either way, looking at my last build of Epiphany, I expected Home/End to move around the entry field when the entry field was focused, and to select the first/last completions when something in the completion list was focused. I know that means one extra keystroke than is currently required if you want to select the last completion (you have to press down-End, rather than just End), but at least it's kind of consistent.
calum yes this is what epiphany uses.
The focus is actually ever in the entry. (I guess it's done that way so that you can continue to type also when a completion entry is selected. Mozilla does the same.). Implementation wise we could make a distinction between completion entry selected/no completion entry selected though. Just wanted to make sure this was not overlooked ...
Hmm, I can feel some accessibility fun coming on here... if things aren't focused when it looks like they are, we potentially have a bit of a 508 situation :) Any thoughts Bill, Peter et al...?
the onscreen focus indication _must_ correspond to what, from the user's perspective, is 'focussed', i.e. the UI component which will react to keyboard input. It's OK for the focus 'technically' to be somewhere else, as long as the end-user-visible effect is consistent. IOW, focus can go to some hidden window or anywhere at all, as long as the keyboard input causes the "apparently focussed" object to react, through redirection of some kind from the 'technically' focussed object to the widget in question. In short, the thing that 'looks' focussed to the user must 'act' focussed, and vice-versa.
Updating status whiteboard to reflect a11y team's assessment of priority.
*** Bug 132436 has been marked as a duplicate of this bug. ***
hmm, who owns this component? (kris?) I think we need to agree to a behavior (Calum, all) and approach (gtk+ team) before gnome 2.6 so we (a11y team) can assign somebody to fix the bug.
I've looked at the keybindings for similar widgets on Win32: - IE has the behaviour described by Calum above as "expected" - Opera always navigates in the entry
I vote for the IE way then :) Am I missing any reasons why we shouldn't want to do it like this?
FWIW my IE (WinXP) seem to behave like Opera (Home/End working only for the text entry). The focus, both in IE and gtk, is in the entry. Since the caret is visible IHMO the user expect the usual entry keybindings to work. Moving the focus in the list would have the disadvantage that you cannot edit the location entry directly anymore, you'd have to get back to it before. I dont know of any browser that behaves that way.
Marco is right about IE: Home and End are still moving the text cursor in the entry, while up, down, pgup, pgdown move the selected item in the completion popup. By the way, it never occurred to me that there are actually two different popups in the ie location line; the completion popup which comes up as you type is different from the combo box dropdown which you get when you click on the arrow. The completion window is resizable, but has no icons, while the dropdown is not resizable, but has icons. And guess what: the keybindings are different. If the completion window is shown, PgUp and PgDown move the visible caret in the entry. If the drowdown list is shown, the caret is hidden and PgUp and PgDown move the list selection. So what IE has amounts to ComboBoxEntry + EntryCompletion...
I wonder if we should just kill Home/End keybindings in the completion for now and figure out a way to move beginning/end fastly later. A possibility is to move at the bottom when pressing up in position 0 and to move at the top pressing down in last position. I sort of like to be able to keep pressing down until I reach the last position without being careful to not "overflow" though.
IE uses PgUp/PgDown as an alternative to move the list selection to the extremes.
Page Down seem to move at the end of the current completions page, not to the really last item. IE has the overflow thing btw.
Yes, the in the autocompletion window PgUp/Down move page-wise in the popup and cycle at the ends. Whereas in the combobox popup, they also move page-wise but do not cycle. Is there a rationale for this ? I just find it confusing.
I propose the following bindings for the completion list bindings for 2.4: * remove Home,End; leave them to the entry (like in IE) * make up, down, pageup, pagedown cycle (like in IE) Maybe we can add an extra twist to the cycling: stop at the ends of the list and require another key press before going to the other end. That would allow Marco to "keep pressing down" to go to the end without worrying, but would still make cycling available relatively conveniently.
Fixed the immediate bug here. Entry completion keybindings will need revisiting when we introduce scrolling.