Closed
Bug 241774
Opened 19 years ago
Closed 17 years ago
Change deletion of autocomplete entries from shift+del to just del button
Categories
(Firefox :: Address Bar, enhancement)
Firefox
Address Bar
Tracking
()
VERIFIED
FIXED
Firefox 2 alpha1
People
(Reporter: bugzilla, Assigned: Gavin)
References
(Blocks 1 open bug)
Details
(Keywords: fixed1.8.1, Whiteboard: parity-ie)
Attachments
(1 file)
2.35 KB,
patch
|
mconnor
:
review+
mconnor
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
Now that bug 204706 has been fixed you dont run into the problem described in bug 171605 comment 24 where just pressing delete would delete what you typed in + the autocomplete entry. Just pressing the delete button to delete an autocomplete entry is something that even my 67 (from today, yiha) old father figured out in IE. It would make it easier for IE users that switch to just have the delete button as IE has it. Steps to reproduce 1. Let a IE user try to delete an autocomplete entry 2. See how he confused he gets when he presses delete and nothing happends 3. Explain that shift + delete was decided for the reason that bug 204706 was not fixed yet Actual results: IE user looks completely confused when I start explaining what bugzilla bug number 204706 is. Expected results: Too see IE user switching to Firefox happy and not confused when he presses delete for an autocomplete entry.
If you hit delete on the dropdown item, it should delete it. If it has filled field, then it should delete a character. People are used to delete. Adding a modifier just confuses things.
Comment 2•19 years ago
|
||
Current behavior probably violates CUA, also (uses "Cut" keystrokes).
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.0?
Updated•19 years ago
|
Flags: blocking1.0? → blocking1.0-
Comment 3•19 years ago
|
||
Just curious as to whether this applies only to the adderss bar, or to stored form data as well.
Comment 5•19 years ago
|
||
From bug 171605: ------- Additional Comment #24 From Ben Goodger 2004-03-17 20:33 PDT [reply] ------- It's because Delete is an acceptable way of forward-deleting the selection. try this: Start typing: www.fo| this autocompletes: www.foo.com/ www.foo.com/bar/ www.foo.com/bar/foo/ you press down arrow twice, leaving yourself with: +- caret | v##selected## www.fo|o.com/bar/ www.foo.com/ ##www.foo.com/bar/############### www.foo.com/bar/foo/ You hit delete to clear the selected text. Instead, www.foo.com/bar/ disappears. Is that what you want to happen?
Comment 6•19 years ago
|
||
That makes sense. Firefox fills in the textbox when you select an autocomplete entry; Internet Explorer does not. I'm removing my vote.
Reporter | ||
Comment 7•19 years ago
|
||
(In reply to comment #5) Please correct me if I am wrong, but what is described in bug 171605, comment 24 happend before bug 204706 was fixed. Because the cursor stayed in the position you were in and selected the rest of the text that was autofilled. This does not happend anymore since bug 204706 has been fixed, when selecting something, the cursor goes to the end of the entry, not making it possible for the scenario in bug 171605, comment 24. I compared IE with Firefox, and they act the same, when you start typing, auto-complete entrie appears in the menu, when selecting one, the field is filled and the cursor goes to the end.
Assignee | ||
Comment 9•19 years ago
|
||
*** Bug 269219 has been marked as a duplicate of this bug. ***
Comment 10•18 years ago
|
||
*** Bug 280507 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•18 years ago
|
Assignee: bugs → nobody
Severity: normal → enhancement
QA Contact: davidpjames → location.bar
Version: unspecified → Trunk
Updated•18 years ago
|
Whiteboard: parity-ie
Comment 11•18 years ago
|
||
There is additional discussion of pretty much the same thing at: https://bugzilla.mozilla.org/show_bug.cgi?id=295792 I second the motion that it would be much easier to use if the DEL key would delete unwanted autocomplete entries. Also, need to increase ability to trap new entries on the same form, even if some autocomplete entries exist for that form.
Updated•18 years ago
|
Flags: blocking-aviary1.1?
Comment 12•18 years ago
|
||
This has some merit, but its too late to make UE changes in this cycle, especially ones that break documented shortcuts.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Comment 13•17 years ago
|
||
*** Bug 324799 has been marked as a duplicate of this bug. ***
Comment 14•17 years ago
|
||
Bug 310612, bug 276175, and bug 278285 are arguably also dups of this bug.
Flags: blocking-firefox2?
Comment 15•17 years ago
|
||
Yeah, let's get this done before a1, we can always revert if we hit other problems.
Flags: blocking-firefox2? → blocking-firefox2+
Keywords: helpwanted
Assignee | ||
Comment 16•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Keywords: helpwanted
Target Milestone: --- → Firefox 2 alpha1
Updated•17 years ago
|
Attachment #210258 -
Flags: review?(mconnor)
Attachment #210258 -
Flags: review+
Attachment #210258 -
Flags: branch-1.8.1+
Assignee | ||
Comment 17•17 years ago
|
||
Trunk: mozilla/toolkit/content/widgets/autocomplete.xml; 1.52; mozilla/toolkit/components/satchel/src/nsFormFillController.cpp; 1.59; 1.8 branch: mozilla/toolkit/content/widgets/autocomplete.xml; 1.44.2.2; mozilla/toolkit/components/satchel/src/nsFormFillController.cpp; 1.51.4.2;
Reporter | ||
Comment 18•17 years ago
|
||
Verified fixed with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060201 Firefox/1.6a1 Thanks for fixing this.
Status: RESOLVED → VERIFIED
Comment 19•6 years ago
|
||
This bug appears to be back... 52.0.1 (64-bit) Linux
Comment 20•6 years ago
|
||
A bug that implemented a new behavior can't be back, at a maximum you could argue the behavior broke, and then you should rather file a regression bug.
You need to log in
before you can comment on or make changes to this bug.
Description
•