If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Ctrl+Backspace in the address bar is incorrectly handled when browser.urlbar.autofill is true

NEW
Unassigned

Status

()

Firefox
Address Bar
P3
normal
14 years ago
a year ago

People

(Reporter: Prognathous, Unassigned)

Tracking

(Depends on: 1 bug)

unspecified
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +
blocking-firefox2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxsearch])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

14 years ago
Steps to reproduce.

1. Make sure browser.urlbar.autofill is true.
2. Type a few characters in the address bar
3. Press the down arrow a few times to select an address of a page (not a top
level domain)
4. Press Ctrl+Backspace to trim a word off the end of this address

Actual result:
The last word is selected

Expected result:
The last word should be deleted

It gets even more confusing if one continues with this:

5. Press Ctrl+Backspace again to trim another word

Actual result:
The caret is placed between the last word and the one before it

Expected result:
Another word should be deleted

Both problems do not appear in Seamonkey.

Prog.
(Reporter)

Updated

13 years ago
Blocks: 282239

Updated

13 years ago
No longer blocks: 282239
Blocks: 282239

Comment 1

13 years ago
WFM in Firefox 1.0.
should be marked FIXED.

Comment 2

13 years ago
No, it's still there in 1.0.

What I need to do to reproduce:

(Set browser.urlbar.autoFill to true.)
1. press Ctrl-L
2. type "www."
3. press end, to go to the end of the suggested url
4. press Ctrl-Backspace

Instead of the last "portion" of the URL being deleting, it is selected.
Contrary to the bug description, I get this behaviour for top-level domains too.

Comment 3

12 years ago
*** Bug 303175 has been marked as a duplicate of this bug. ***

Comment 4

12 years ago
I don't think it's selecting the content when you backspace, but rather deleting
it but then immediatly filling it again according to the autofill behavior.

The same thing happens when you use backspace, too. Note that this only happens
when the autocomplete dropdown is present as well.

Comment 5

12 years ago
I have a similar bug (the same one?):

1) Set browser.urlbar.autoFill=true in about:config.
2) Open a new window.
3) Type the beginning of a url that autofills to a url with subdirectories.
   For example: "www.goo" autofills to "www.google.es/url?sa=Dsf...&ei=Y9kO".
4) Press one time the Left arrow key (the autofill part is de-selected).
5) Press and keep pressed the Rigth arrow key, until the cursor is at the
   right of "www.google.com" (and at the left of whole the subdirectories 
   info).
6) Press and keep pressed the Shift key, and then press the End key (the
   subdirectories info is selected).
7) Press one time the Delete key. Result: the selected info is deleted, but
   inmediately appears again (bug).
8) You have to press the Delete key _again_ to delete definitely the info.

The bug is in step 7 (the deleted info shouldn't appear again).

I'm using firefox 1.0.7 in FedoraCore 4. The rpm packet is

  firefox-1.0.6-1.1.fc4

Comment 6

12 years ago
Using 1.5.0.1, this seems to be WFM.

Using the original steps to reproduce, when I hit ctrl-backspace the entire URL is deleted (even for non-top-level URLs).  I'm not sure if this is correct behavior, but it's certainly not the behavior described.

Using the steps in comment 5, evertyhing appears to work normally.
(Reporter)

Comment 7

12 years ago
The bug is still there. Tested with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

Just follow the original steps-to-reproduce to the letter and you'll see it.

As for comment #5, I'm quite sure it's the same bug.

Prog.

Comment 8

12 years ago
Ah ha, I was testing on my GNOME box, where ctrl-backspace seems to behave differently.  Verified this reproduces on Windows XP.  The fix should be to not trip the autoFill routine again after a ctrl-backspace; perhaps there are other keypresses to also not do this after (like delete).  I don't know what code is already in place.  Since I doubt Ben will get to this, I'll take this one, but may not look at it for a bit.
Assignee: bugs → pkasting

Comment 9

12 years ago
This also seems to trip when I just press backspace; if I select a URL from the autocomplete box, hit the right arrow to put my cursor at the end, and then hit backspace, we autofill the character that was just deleted, and I have to hit backspace again to get rid of it.  At this point the browser _is_ smart enough to not continue to show the same bug with repeated backspaces, but I think even the first is wrong.  I wonder if maybe autoFill just should not trip if your keypress did not add characters to the string.

Comment 10

12 years ago
Patch for this coming tomorrow morning (it works, I just need some time to disentangle it from other changes in my local tree).

Comment 11

12 years ago
Created attachment 220674 [details] [diff] [review]
Fix various navigation key + autoFill issues

This fixes various issues with keyboard navigation and urlbar autofill:
* The fix for bug 323549 was incomplete; we should also take the autocomplete match as-is (instead of completing to it) when we right-arrow on a match, as well as when we hit enter.  This prevents some very odd-looking behavior when you type in "bugzilla", arrow-down to "http://bugzilla.mozilla.org/", hit right, and see "bugzilla.mozilla.org/" without a scheme.  (In 1.5, we never showed the scheme even while arrowing through the autocomplete list, so this didn't cause a bad visual.)
* When hitting right-arrow, left-arrow, or escape when the autocomplete popup is open (whether or not something is highlighted), we now properly ensure mSearchString is the same as the contents of mInput, so subsequent backspaces properly appear to be text deletions.

bsmedberg, I've asked you to review since I've already requested multiple other reviews from bryner...
Attachment #220674 - Flags: review?(benjamin)
Comment on attachment 220674 [details] [diff] [review]
Fix various navigation key + autoFill issues

bryner's the best target for autocomplete reviews
Attachment #220674 - Flags: review?(benjamin) → review?(bryner)
Comment on attachment 220674 [details] [diff] [review]
Fix various navigation key + autoFill issues

Actually I'm pretty swamped right now and I asked Peter to get a different reviewer if possible.  mconnor, bsmedberg, can one of you take this?  Thanks.
Attachment #220674 - Flags: superreview?(benjamin)
Attachment #220674 - Flags: review?(mconnor)
Attachment #220674 - Flags: review?(bryner)

Comment 14

12 years ago
I can't get to this until after XTech, so two weeks.

Updated

11 years ago
Attachment #220674 - Flags: review?(mconnor) → review+

Comment 15

11 years ago
Nominating for Fx2 B1.  Our deletion behavior for URL bar autofill needs help.
Flags: blocking-firefox2?

Comment 16

11 years ago
Adding a target milestone to increase likelihood of search queries finding me
Target Milestone: --- → Firefox 2 beta1
non-security bugs in features that are enabled from a hidden pref aren't blockers
Flags: blocking-firefox2? → blocking-firefox2-

Updated

11 years ago
Attachment #220674 - Flags: superreview?(benjamin) → superreview+

Comment 18

11 years ago
Comment on attachment 220674 [details] [diff] [review]
Fix various navigation key + autoFill issues

Requesting branch approval, presumably after this bakes on the trunk for a bit.
Attachment #220674 - Flags: approval-branch-1.8.1?(benjamin)

Updated

11 years ago
Attachment #220674 - Flags: approval-branch-1.8.1?(benjamin) → approval-branch-1.8.1+

Comment 19

11 years ago
Created attachment 225775 [details] [diff] [review]
Patch as checked in: added { } around an if block
Attachment #220674 - Attachment is obsolete: true

Comment 20

11 years ago
fixed-1.8-branch, fixed-on-trunk
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED

Updated

11 years ago
Depends on: 350079

Comment 21

11 years ago
Is this really fixed on 1.8 branch? I still see this bug using Firefox 2...

Comment 22

11 years ago
(In reply to comment #21)
> Is this really fixed on 1.8 branch? I still see this bug using Firefox 2...

I swear my patch really fixed it at the time, but I verify this reproduces again on trunk.  Reopening.
Status: RESOLVED → REOPENED
Keywords: fixed1.8.1
Resolution: FIXED → ---

Comment 23

11 years ago
Also, dumping this off my plate, as I'm not going to have time to look into it again any time soon.  Sorry :(
Assignee: pkasting → nobody
Status: REOPENED → NEW
QA Contact: davidpjames → location.bar

Updated

11 years ago
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]

Updated

6 years ago
Duplicate of this bug: 720284
Comment hidden (me-too)

Updated

5 years ago
Duplicate of this bug: 775144

Updated

5 years ago
Duplicate of this bug: 777994

Comment 28

5 years ago
I can't tell whether this is the same bug or should be filed as a new one, but:  ctrl+backspace after entering first portion of an address in address bar does not remove any in-line auto-completion suggestion.  As an example:

* Start entering the name of a site you use often (e.g. "goog"), you should see an in-line autocompletion appear (e.g. "goog[le.com/]")

* Press Ctrl+Backspace to remove the last word typed -- in this example, the "goog" will (as expected) disappear.

* However, the auto-completion suggestion (e.g. "le.com/") will remain.

* The user would expect this to disappear.


Note that this may be different to the bug as described above which discusses the other odd auto-fill behaviour seen when pressing Ctrl+backspace at the end of a URL.

Comment 29

5 years ago
I've read the relevant part of the code numerous times. I'm convinced it's the part of nsAutoCompleteController::HandleText that chooses whether mBackspaced (or whatever the variable is called) is set to true or false. 

In that "if" statement, it's checking the length of the new text against *the text the user has typed into the URL bar*, not the text filled in when they select one of the suggestions. 

I am completely new to FF development, and am not familiar enough to fix the issue myself, but all you need to to is check against *what is actually displayed in the URL bar*, and there's got to be a way to get that, right?

Maybe I'm not aware of how difficult the fix actually is, but I really think someone familiar with that part of the code could fix this in no time.
Target Milestone: Firefox 2 beta1 → ---

Updated

3 years ago
Duplicate of this bug: 1057520

Updated

2 years ago
Duplicate of this bug: 961549

Comment 32

2 years ago
Can we get an update to:
Version: 	unspecified
Platform: 	x86 Windows XP 

?
It might help to narrow things down. Also need to change the flag from "Wanted Firefox 3+".

Comment 33

2 years ago
Well, it still/also happens on Linux with 47.0a2 (2016-03-17), so I think this applies to all recent versions on desktop platforms.

Comment 34

a year ago
(In reply to Vladimir from comment #33)
> Well, it still/also happens on Linux with 47.0a2 (2016-03-17), so I think
> this applies to all recent versions on desktop platforms.

I cannot change that parameter/flag. Perhaps someone else can.
Priority: -- → P3
Whiteboard: [fxsearch]
You need to log in before you can comment on or make changes to this bug.