Bug 24806 - form autocompletion focus
Summary: form autocompletion focus
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml forms (show other bugs)
Version: 2.2-alpha
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 51333 63987 67771 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-04-26 11:48 UTC by cristid
Modified: 2004-05-06 21:10 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed patch to make Enter accept completion and advance focus (958 bytes, patch)
2003-09-18 18:01 UTC, Paul Pogonyshev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cristid 2001-04-26 11:34:30 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           konqueror
Version:           2.2alpha1 (using KDE 2.2.0 \6alpha1)
Severity:          normal
Installed from:    compiled sources
Compiler:          gcc version 2.95.3 20010315 (release)
OS:                Linux (i686) release 2.4.3
OS/Compiler notes: 

When the list of autocompletion items for a form field shows up typing <tab> autocompletes the currently selected item and pressing it again doesn't move the focus to the next field but instead does absolutely nothing.
I'm submitting this as a bug because I think the tab key should do something there... After autocompletion I think it should move the focus to the next field. So pressing tab twice should perhaps autocomplete the entry and move to the next field.

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Carsten Pfeiffer 2001-04-26 23:17:13 UTC
On Donnerstag 26. April 2001 13:34 cristid@chip.ro wrote:

> When the list of autocompletion items for a form field shows up typing
> <tab> autocompletes the currently selected item and pressing it again
> doesn't move the focus to the next field but instead does absolutely
> nothing. I'm submitting this as a bug because I think the tab key should do
> something there... After autocompletion I think it should move the focus
> to the next field. So pressing tab twice should perhaps autocomplete the
> entry and move to the next field.

I can't reproduce this this works just fine for me. Pressing tab always 
advances to the next item in the completion-box. Anyone else who can 
reproduce this?

Cheers
Carsten Pfeiffer
Comment 2 Malte Starostik 2001-04-27 11:03:04 UTC
On Freitag 27. April 2001 01:17 Carsten Pfeiffer wrote:
> On Donnerstag 26. April 2001 13:34 cristid@chip.ro wrote:
> > When the list of autocompletion items for a form field shows up typing
> > <tab> autocompletes the currently selected item and pressing it again
> > doesn't move the focus to the next field but instead does absolutely
> > nothing. I'm submitting this as a bug because I think the tab key should
> > do something there... After autocompletion I think it should move the
> > focus to the next field. So pressing tab twice should perhaps
> > autocomplete the entry and move to the next field.
>
> I can't reproduce this this works just fine for me. Pressing tab always
> advances to the next item in the completion-box. Anyone else who can
> reproduce this?
Yes Tab while the completion popup is visible does nothing here.
-Malte
Comment 3 David Walser 2002-11-02 06:45:01 UTC
I can reproduce the bug too.  It worked in KDE 2.2.2  It's definately a problem. 
Comment 4 Pascal Cavy 2003-01-25 17:27:53 UTC
kde 3.1 rc6 
<TAB> with popup list completion allow to go from one choice to the other 
on the list 
What is not clear is how do we select the choice we want and go to the 
other input field then ? 
 
TAB does not go to the new input field in the form (but selects the next 
available auto completion choice) 
 
ENTER selects and enters the choice in input field BUT ENTER is then 
passed to the FORM wich is submitted   
THIS SHOULD NOT HAPPEN I think the bug is here 
Comment 5 cristid 2003-01-27 13:06:01 UTC
Reopening this because of Pascal's comments, I cannot test myself at the 
moment.
Comment 6 wjl 2003-01-29 16:31:06 UTC
The main problem I have with the current non-intuitive context-sensitive behavior is as 
follows: 
 
If you are filling out a new form (i.e. no autocomplete comes up for any fields) you can 
just do: 
 
type -> TAB (next field) -> type -> TAB -> type -> TAB -> type -> ENTER (submit) 
 
Unfortunately, if the autocompletion pops up, it's: 
 
type -> ENTER (select autocomplete) -> type -> TAB (whoops! I wanted to go to the 
next field, but instead it selects the next autocompletion!) -> ENTER (select 
autocomplete) -> type -> ENTER (having gotten used to autocomplete come up and 
knowing that pressing TAB will select the next entry, whereas I know I want the first 
one--except WHOOPS! it didn't come up this time, so instead this SUBMITS the form, 
even though I'm not nearly done filling it out!) 
 
If ENTER is going to submit the form, it should *always* submit the form. If TAB is 
going to go to the next field, it should *always* go to the next field, or at the least, 
select the highlighted auto-complete, so you could at least just press TAB-TAB to go to 
the next field. 
Comment 7 Dawit Alemayehu 2003-04-23 05:58:15 UTC
 
If you simply want to select an item from the completion box without activating it, 
simply use Shift+Enter to select the item.  This will consume the enter event and 
hence no activation of item. 
 
Regards, 
Dawit A. 
Comment 8 Kai Lahmann 2003-06-15 13:57:00 UTC
*** Bug 51333 has been marked as a duplicate of this bug. ***
Comment 9 Melvyn Sopacua 2003-07-02 20:35:32 UTC
Tab should just navigate fields, nothing more, nothing less. Using a tab with 
autocompletion is counter productive. Remember also, that HTML defines the 
'TABindex' attribute. 
 
What's wrong with using 'arrows' only for autocompletion (and yes, enter as selecting a 
value). Arrows and 'enter' are on the right of the keyboard and tab on the left, so it's 
very convenient. 
Comment 10 hughjonesd 2003-07-09 13:25:26 UTC
The reason we want tab to do the autocompletion is as wjl described above - it
makes moving around form items easier and more intuitive. "tab should just
navigate fields", "tab with autocompletion is counter productive": why? Also,
why is HTML's tabindex relevant? The tabindex ordering will still work fine.
Comment 11 David Walser 2003-07-09 14:24:21 UTC
Subject: Re:  form autocompletion focus         

--- hughjonesd@yahoo.co.uk wrote:
> The reason we want tab to do the autocompletion is
> as wjl described above - it
> makes moving around form items easier and more
> intuitive.

That couldn't be farther from the truth.

> "tab should just
> navigate fields",

And that's the standard in any application.

> "tab with autocompletion is
> counter productive"

Simple, the most productive way to navigate forms is
with the Tab key.  The current behavior breaks that
completely.  Even after it's done the autocompletion,
it still won't go to the next field!  It's easy enough
to just use a different key for the autocompletion,
instead of breaking standard behavior.

> why?

The burden of explanation is on you all who want to
break standard behavior.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Comment 12 wjl 2003-07-09 15:54:14 UTC
I think I might have been misunderstood. In any case, let me clairify. My 
comment was trying to show how it is currently broken. The main point of my 
post was, (if I can quote myself ;): 
 
"If ENTER is going to submit the form, it should *always* submit the form. If 
TAB is going to go to the next field, it should *always* go to the next 
field..." 
 
I'm all for standard behavior. I mentioned that if the group was vehemently 
against standard behavior, that "you could at least just press TAB-TAB to go to  
 the next field." That would make it better than it is now, but it still would 
be non-standard and would still be annoying. 
 
Basically to be standard, 
 
  1) TAB should go to the next field. Always. ALWAYS. 
  2) ENTER should submit the form. Always. ALWAYS. 
 
And to support autocompletion intuitively, 
 
  3) UP and DOWN arrows should select auto-completions. 
 
You might pick different bindings for #3, although I can't think of anything 
better that doesn't break something else. 
 
Comment 13 David Walser 2003-07-09 16:40:35 UTC
Subject: Re:  form autocompletion focus         

wjl - I agree 100% with everything you just said. 
Thank you for posting that.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Comment 14 Arend Bayer 2003-07-09 17:17:03 UTC
Let me add my 2 cents. 1) For people that do not want to use autocompletion, they shouldn't notice autocompletion at all. 2) By now, you have to press 3 keys to use autocompletion and move forward to the next field (Tab, Enter, Tab -- and it took me 3 years of using konqueror to find this out!). With the alternative suggestion, it's Down, Tab, only 2 keys. So even experienced users, the alternate solution would still be better.  IMHO, 1) is already a killer argument against the current solution. Maybe this is not a well-liked argument here, but pls also give some thought to the fact that the mozilla people (which have many more resources in terms of UI specialists) chose exactly wjl's suggestion.  I wonder what the kde-usability list would have to say on this bug.  Arend 
Comment 15 Leif Huhn 2003-07-09 21:21:20 UTC
I absolutely agree that TAB should ALWAYS go to the next field.  I shouldn't have to watch 
my screen to notice that the program just popped up an autocompletion field and now I have 
to hit tab twice. 
 
 
Comment 16 Ellis Whitehead 2003-07-09 22:36:33 UTC
I'm just repeating what's already been said by many, but since I consider the 
current Tab/Enter setup to be in dire need of being fixed: context-based shortcuts 
are sometimes ok; unpredictable context-based shortcuts are almost always very, 
very bad.  Since the autocompletion popups are often unpredictable, I place them in 
the "very, very bad" category. *grin*  Even when a person knows that 
autocompletion will pop up (e.g. when entering your username on a webmail page 
that you regularly visit), the change of shortcut meaning is nonetheless quite 
unfortunate -- because the context does not change radically enough to justify such 
a radical change of meaning (i.e., Enter for "submit" changing to Enter for "select").  
Please follow the suggestion for Up/Down changing the selection and leave Tab 
and Enter to their normal interpretation. 
Comment 17 hughjonesd 2003-07-09 23:31:06 UTC
I agree with wjl, there is just one thing that I want to clear up: if you have
an autocompletion selected from a dropdown list, does tab "choose it and move on
to the next field" or does it just "move on to the next field" cancelling the
autocompletion?

I would prefer the former, but I can see there are arguments on both sides -
basically, it would depend on whether you selected the autocompletion manually
or if it was automatically selected for you. If you selected it, presumably you
don't want your choice to be cancelled just because you want to go to the next
field; OTOH if it's automatically selected, you might want to get rid of it.
AFAICS current behaviour is not to autoselect an option but perhaps this changes
with the dropdown/automatic combo currently in CVS.

In any case, I certainly think the current TAB behaviour of "select next
autocompletion" is wrong.

There's also a separate issue with the up and down buttons, for which I've
created bug #61012 . 

Dave
Comment 18 Melvyn Sopacua 2003-07-10 00:05:21 UTC
Tab and autocompletion really shouldn't mix. Please get that outof your state of 
thoughts. The only 'valid' reason for using tab in autocompletion, is the desire to 
non-conform. That might be a valid enough reason in terms of security, but certainly not 
in user interfaces, especially when it's non-intuitive. 
If you're worried about backwards compatibility - don't be - cause getting over this is 
really much easier than getting used to it. 
 
The biggest problem is not even *using* an autocompletion value with this behavior, but 
it's using a *partial* of an autocompletion value. For instance, if you strip a keyword 
from a search engine and want to move to the next field (say 'language' or nr. of 
results or whatever) - you'll end up in autocompletion *again*. 
 
Really - it should changed or in *nix spirit: "A bug is a feature that can't be configured". 
Comment 19 Rene Horn 2003-07-11 10:06:32 UTC
Re:hughjonesd's comment about std. behavior of tab 
 
The former ("choose it and move on to the next field") is the default behavior for all the applications 
I've worked with, except in KDE/Konqueror, of course. 
Comment 20 kdebugs 2003-07-26 06:13:52 UTC
Well, just to be a contrarian here, while I agree about the TAB behavior, what my muscle 
memory keep trying to to with RETURN is to use it to indicate to the auto-completion that I 
have selected a choice, and it should fill the current box and stay there, ie: 
 
type.. dropdown... arrows to select.. enter to choose (have focus stay in text entry)... TAB to 
next field 
 
So while I think "tab always goes to the next field" feels right, "enter always submits" does not. 
In a sense, what my poor brain has created as a mental model is that the dropdown has 
created a *sub entry dialog* that enter completes, so I can continue on with the *outer* 
dialog. 
 
In other words, a RETURN while a completion dropdown is open should NOT submit the form, 
just the "autocomplete subform"... 
 
 
Comment 21 David Walser 2003-07-26 06:18:57 UTC
Carl, I don't think you're being contrarian.  Most of us agree with you.  
While the "cursor" per se is in the drop-down of completion choices, Enter 
should select it, yes.  Tab should also select it, as well as moving onto the 
next field.  Enter should only submit the form if the cursor is in the text 
entry field itself, I don't imagine many would disagree with you on that. 
Comment 22 wjl 2003-07-26 15:05:45 UTC
I would agree that *if* you had pressed an explicitly up/down arrow key to 
select a choice, then enter could select it and not submit the form; that seems 
pretty unsurprising, and much less harmful than the current behavior. =) Just 
as long as the simple fact that autocompletions were available and a drop down 
popped up didn't change the symantics of the enter key from submit. 
 
But what if you use the up/down arrows to select autocompletions, they were 
updated immediately on-the-fly in the text field and the cursor *stayed* in the 
the text field? (i.e. if you type "mis" and the autocompletion box pops up with 
"miss/missy/mississippi" and you press the down arrow key, your text 
IMMEDIATELY changes to "miss", you press it again, it IMMEDIATELY changes to 
"missy", etc--all the time the cursor remains focused in the text field). Thus 
you've eliminated some unnecessary modality from form entry.  
 
I think this would be a much better solution. However, I'm not against enter 
selecting an autocompletion *only after* you've pressed an up or down arrow key 
to select an autocompletion if it's obvious that the cursor focus has left the 
text field and that you are in a "autocompletion selection" mode. 
 
Well, anyway, I hope we can find a sane resolution here; I think we're 
beginning to converge. ;) 
Comment 23 kdebugs 2003-08-09 05:01:07 UTC
Yes, that makes tremendous sense. If you are flying through, ignoring the 
autocompletion, it is transparent, yet if you stop to interact with the 
autocompletion (unless it can remain modeless, which would be way cool), the 
semantics change, you have entered autocompletion mode. 
 
By the way, it seems like this logic should apply to elements outside of Konq 
as well. It should work the same in any app that does autocompletion, has 
tabbed fields, enter for "submit", etc. 
 
I will say, however, that having it work this way in the Location bar would 
feel counterintuitive, perhaps because it's a "one field form". There, I want 
it to navigate to the site I choose right away, not require me to "leave 
autocompletion mode" and then "submit location form". 
Comment 24 Maksim Orlovich 2003-09-10 00:17:28 UTC
*** Bug 63987 has been marked as a duplicate of this bug. ***
Comment 25 Paul Pogonyshev 2003-09-18 18:01:12 UTC
Created attachment 2501 [details]
Proposed patch to make Enter accept completion and advance focus

I'm not familiar with KDE/Qt programming, so you might want to revise the
patch.

This is my most hated bug recently.
Comment 26 Ingo Klöcker 2003-09-20 17:27:12 UTC
The fact that the completion (I'm using the dropdown) isn't accepted anymore if Return is 
pressed is a regression (in comparison to KDE HEAD from a few weeks ago). So this is 
actually a new bug. IMO this is currenly the most annoying bug in Konqueror. 
Comment 27 Paul Pogonyshev 2003-09-22 01:30:01 UTC
Yes, and that is bug 63987.  I guess it was marked a duplicate just like "text, completion, in 
forms - ah, that sounds familiar".  Meanwhile, if you have the sources, you can apply the patch 
i posted (comment #25) to the file `kdelibs/khtml/rendering/render_form.cpp'.  It works nicely 
here :) 
Comment 28 dpavlotzky 2003-10-16 01:39:09 UTC
Just my 2 cents. The standard key combination for submiting in KDE is CTRL-<enter>. This works in Kmail as well as in Kopete (any other "submitting" programs?).

This is different from others *cough*windows*cough* (don't know about GNOME), but it makes multi-line messages in Kopete easy and makes it possible to submit emails wihout touching my mouse.

CTRL-<enter> makes sence to me, but I can see some upset power users (I'll call them power users 'cause I'm surprised how many people still get their mouse to push the submit button...) that enter won't submit their form.

On the flipside it would be more consistent with other submitting applications 
Comment 29 Oded Arbel 2003-10-29 00:57:57 UTC
Current behaviour in CVS (2003.10.28):

Tab: moves to the next tab w/o autocompleting - that is, if the auto-completion popup is displayed but an entry is not selected, the current field remains the same.
Cursor keys: select an entry in the auto-complet menu and automaticly feeds it in the field.
Esc & Shift-Enter: dismisses the auto-completion box w/o changing the current field (it may have already been changed by cursor keys selecting an entry in the menu), *and stays in the field*
Enter & Ctrl-Enter: if the menu is open does nothing, otherwise it submits the form

I think this is almost correct, all that needs to be done now is either of two things:
a. Make sure that enter does the same as shift-enter - dismisses the menu and keeps you on the same field. optionally, change shift-enter to dismiss the menu and move to the next field (for power users).
- or -
b. Change the cursor keys not to auto-feed the auto-completion value to the field, but just to highlight the entry. use Enter to close the menu and feed the selected entry to the field, and optionally shift-enter to feed the selected entry to the field and move to the next field (for power users).

if you want to dismiss the menu w/o selecting an entry - press Esc.

I personnally prefer method (b), as it's the way all other auto-completion capable stuff work, i.e. Mozilla and IE.
Comment 30 Ingo Klöcker 2003-10-29 01:31:36 UTC
Subject: Re:  form autocompletion focus

On Wednesday 29 October 2003 00:58, Oded Arbel wrote:
> I think this is almost correct, all that needs to be done now is
> either of two things: 
> a. Make sure that enter does the same as 
> shift-enter - dismisses the menu and keeps you on the same field.

The following simple patch fixes the problem that Enter is simply
ignored:
Index: render_form.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/rendering/render_form.cpp,v
retrieving revision 1.249
diff -u -3 -p -r1.249 render_form.cpp
--- render_form.cpp     25 Oct 2003 15:25:43 -0000      1.249
+++ render_form.cpp     29 Oct 2003 00:27:01 -0000
@@ -458,8 +458,10 @@ void RenderLineEdit::slotReturnPressed()
 {
     // don't submit the form when return was pressed in a completion-popup
     KCompletionBox *box = widget()->completionBox(false);
-    if ( box && box->isVisible() && box->currentItem() != -1 )
-       return;
+    if ( box && box->isVisible() && box->currentItem() != -1 ) {
+               box->hide();
+               return;
+       }

     // Emit onChange if necessary
     // Works but might not be enough, dirk said he had another solution at

Comment 31 Oded Arbel 2003-10-29 01:58:39 UTC
Thank you - this patch works for me. 
I suggest to commit this patch to CVS and close this bug. if someone thinks that option (b) in my description or any other behavior should be implemented, then I suggest a new wishlist item be opened.
Comment 32 Dirk Mueller 2003-11-02 18:02:18 UTC
*** Bug has been marked as fixed ***.
Comment 33 Ingo Klöcker 2003-11-07 22:06:54 UTC
Reopened because the bug is not fixed. Dirk's
-            edit->completionBox()->setTabHandling( false );
doesn't have any effect. Instead I still have to use the patch from comment #30.

That it's not fixed has been confirmed by Lukáš Tinkl.
Comment 34 Oded Arbel 2003-11-09 14:12:31 UTC
Not only it has not been fixed by the last commit - its been broken more:
Now pressing TAB in auto-completin popups instead of moving to the next field (w/ or w/o filling in the autocompleted value), it moves to the next option in the popup box !

Please revert Dirk's patch and commit Ingo Kloecker's instead. Thanks.
Comment 35 Stephan Kulow 2003-11-10 14:31:48 UTC
*** Bug 67771 has been marked as a duplicate of this bug. ***
Comment 36 Dawit Alemayehu 2003-12-18 06:40:34 UTC
Works fine in current CVS. Was fixed on Nov 13 by Dirk. See the commit message for Revision 1.254 commit message below:

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/khtml/rendering/render_form.cpp
Comment 37 Paul Pogonyshev 2004-05-06 21:10:58 UTC
This bug has reappeared in recent CVS.  Can you guys make up your mind on what to do with forms, autocompletion box, Tab and focus?

Current behaviour is intolerable: a completion is only selectable with mouse, 'cause Enter submits and Tab moves between completions.