After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 127430 - Conflict between entry/completion key bindings
Conflict between entry/completion key bindings
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other Windows
: Normal normal
: ---
Assigned To: Kristian Rietveld
Kristian Rietveld
AP2
: 132436 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-11-19 22:41 UTC by Marco Pesenti Gritti
Modified: 2011-02-04 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Marco Pesenti Gritti 2003-11-19 22:41:20 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 :)
Comment 1 Dave Bordoley [Not Reading Bug Mail] 2003-11-19 22:43:42 UTC
ccing calum the master of keybindings.
Comment 2 Calum Benson 2003-12-01 14:10:12 UTC
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.
Comment 3 Dave Bordoley [Not Reading Bug Mail] 2003-12-01 17:38:56 UTC
calum yes this is what epiphany uses.
Comment 4 Marco Pesenti Gritti 2003-12-01 18:30:36 UTC
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 ...
Comment 5 Calum Benson 2003-12-01 18:46:17 UTC
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...?
Comment 6 bill.haneman 2003-12-03 11:24:48 UTC
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.
Comment 7 Calum Benson 2004-01-23 16:06:18 UTC
Updating status whiteboard to reflect a11y team's assessment of priority.
Comment 8 Christian Persch 2004-01-24 23:36:51 UTC
*** Bug 132436 has been marked as a duplicate of this bug. ***
Comment 9 bill.haneman 2004-01-26 10:52:55 UTC
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.
Comment 10 Matthias Clasen 2004-01-26 11:35:41 UTC
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
Comment 11 Calum Benson 2004-02-05 17:09:17 UTC
I vote for the IE way then :)  Am I missing any reasons why we
shouldn't want to do it like this?
Comment 12 Marco Pesenti Gritti 2004-02-05 18:05:55 UTC
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.
Comment 13 Matthias Clasen 2004-02-18 14:14:38 UTC
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...
Comment 14 Marco Pesenti Gritti 2004-02-18 19:31:54 UTC
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.
Comment 15 Matthias Clasen 2004-02-19 00:07:15 UTC
IE uses PgUp/PgDown as an alternative to move the list selection to
the extremes. 
Comment 16 Marco Pesenti Gritti 2004-02-20 10:39:14 UTC
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.
Comment 17 Matthias Clasen 2004-02-20 14:44:34 UTC
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.
Comment 18 Matthias Clasen 2004-02-25 12:42:29 UTC
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.
Comment 19 Matthias Clasen 2004-02-27 01:34:03 UTC
Fixed the immediate bug here. Entry completion keybindings will need
revisiting when we introduce scrolling.