(*** 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)
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
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
I can reproduce the bug too. It worked in KDE 2.2.2 It's definately a problem.
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
Reopening this because of Pascal's comments, I cannot test myself at the moment.
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.
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.
*** Bug 51333 has been marked as a duplicate of this bug. ***
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.
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.
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
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.
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
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
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.
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.
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
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".
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.
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"...
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.
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. ;)
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".
*** Bug 63987 has been marked as a duplicate of this bug. ***
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.
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.
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 :)
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
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.
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
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.
*** Bug has been marked as fixed ***.
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.
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.
*** Bug 67771 has been marked as a duplicate of this bug. ***
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
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.