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

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect, P3)

Description

[Prognathous]

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.

Comment 1

[Miguel Gaspar]

WFM in Firefox 1.0.
should be marked FIXED.

Comment 2

[David Naylor]

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

[Adam Guthrie]

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

Comment 4

[Adam Guthrie]

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

[Adrian]

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

[Peter Kasting]

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.

Comment 7

[Prognathous]

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

[Peter Kasting]

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.

Comment 9

[Peter Kasting]

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

[Peter Kasting]

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

[Peter Kasting]

Attachment: 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...

Comment 12

[Mike Connor [:mconnor]]

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

bryner's the best target for autocomplete reviews

Comment 13

[Brian Ryner (not reading)]

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.

Comment 14

[Benjamin Smedberg]

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

Comment 15

[Peter Kasting]

Nominating for Fx2 B1.  Our deletion behavior for URL bar autofill needs help.

Comment 16

[Peter Kasting]

Adding a target milestone to increase likelihood of search queries finding me

Comment 17

[Mike Connor [:mconnor]]

non-security bugs in features that are enabled from a hidden pref aren't blockers

Comment 18

[Peter Kasting]

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.

Comment 19

[Pam Greene]

Attachment: Patch as checked in: added { } around an if block

Comment 20

[Pam Greene]

fixed-1.8-branch, fixed-on-trunk

Comment 21

[David Naylor]

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

Comment 22

[Peter Kasting]

(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.

Comment 23

[Peter Kasting]

Also, dumping this off my plate, as I'm not going to have time to look into it again any time soon.  Sorry :(

Comment 25

[Roman R.]

Dudes, the bug is still present in Firefox 17. Please fix it!

Comment 28

[Daniel Jackson]

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

[Wesley Chalmers]

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.

Comment 32

[Worcester12345]

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

[Vladimir Panteleev]

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

[Worcester12345]

(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.

Comment 35

[Marco Bonardo [:mak]]

This bug is too old and no more useful, the issue is tracked in bug 835779 anyway, and likely fixed in the Quantum Bar.
Though comment 28 describes a different bug, that I'll file apart.