Closed Bug 246237 Opened 15 years ago Closed 2 months ago
Ctrl+Backspace in the address bar is incorrectly handled when browser
.urlbar .autofill is true
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.
WFM in Firefox 1.0. should be marked FIXED.
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.
*** Bug 303175 has been marked as a duplicate of this bug. ***
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.
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
Using 22.214.171.124, 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.
The bug is still there. Tested with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060308 Firefox/188.8.131.52 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.
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
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.
Patch for this coming tomorrow morning (it works, I just need some time to disentangle it from other changes in my local tree).
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.
I can't get to this until after XTech, so two weeks.
Attachment #220674 - Flags: review?(mconnor) → review+
Nominating for Fx2 B1. Our deletion behavior for URL bar autofill needs help.
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-
Attachment #220674 - Flags: superreview?(benjamin) → superreview+
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)
Attachment #220674 - Flags: approval-branch-1.8.1?(benjamin) → approval-branch-1.8.1+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Is this really fixed on 1.8 branch? I still see this bug using Firefox 2...
(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
Resolution: FIXED → ---
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
Flags: blocking-firefox3? → blocking-firefox3-
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.
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.
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+".
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.
(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.
Status: NEW → RESOLVED
Closed: 13 years ago → 2 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.