559878 - browser.urlbar.autoFill replaces typed characters in awesomebar with tab match URL characters

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[Matt Brubeck (:mbrubeck)]

Attachment: screenshot after typing "mo"

Steps to reproduce:
1. Type some text in the awesomebar that matches an open tab.

Results: Text that you typed is replaced with the URI of the open tab.If you continue typing, the first N characters of the URI replace the N characters you typed.  (In the attached screenshot, the match appeared after I type "mo" - if I type "motown" then "httown" appears in the awesomebar.)

I can't reproduce this with just any tab, but for affected URLs it happens consistently.  I think it might happen on pages with higher suggestion "scores" (frecency, etc.) but I'm not sure.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Do you have browser.urlbar.autoFill set to true?

Comment 2

[Matt Brubeck (:mbrubeck)]

(In reply to comment #1)
> Do you have browser.urlbar.autoFill set to true?

Ah, yes I do.  Updating the summary to show this.  The problem does not exist with browser.urlbar.autoFill = false.

Comment 3

[Matt Brubeck (:mbrubeck)]

Aha! This happens whenever the typed text begins with characters from "moz-action:".

Comment 4

[imradyurrad]

(In reply to comment #3)
> Aha! This happens whenever the typed text begins with characters from
> "moz-action:".

Why is moz-action even shown in the urlbar?

Comment 5

[Matt Brubeck (:mbrubeck)]

"moz-action:" does not actually appear anywhere onscreen (in the urlbar or in the autocomplete menu), but the URL is autofilled as if it started with "moz-..." instead of "http..."  So I type "mo" and end up with "ht" in the urlbar.

Comment 6

[imradyurrad]

Attachment: moz-action

Comment 7

[imradyurrad]

(In reply to comment #5)
> "moz-action:" does not actually appear anywhere onscreen (in the urlbar or in
> the autocomplete menu), but the URL is autofilled as if it started with
> "moz-..." instead of "http..."  So I type "mo" and end up with "ht" in the
> urlbar.

Arrow over to where it says "switch to tab" and it does.

Comment 8

[Matt Brubeck (:mbrubeck)]

(In reply to comment #7)
> (In reply to comment #5)
> > "moz-action:" does not actually appear anywhere onscreen (in the urlbar or in
> > the autocomplete menu)
> Arrow over to where it says "switch to tab" and it does.

I can't reproduce this in the latest trunk nightly. It sounds like a different bug.  (When I use the arrow keys to highlight a tab match, the urlbar says "Switch to tab: http://...")

Comment 9

[imradyurrad]

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #5)
> > > "moz-action:" does not actually appear anywhere onscreen (in the urlbar or in
> > > the autocomplete menu)
> > Arrow over to where it says "switch to tab" and it does.
> 
> I can't reproduce this in the latest trunk nightly. It sounds like a different
> bug.  (When I use the arrow keys to highlight a tab match, the urlbar says
> "Switch to tab: http://...")

Using the latest hourly.

Comment 10

[imradyurrad]

Disregard that. Location bar 2 addon caused it.

Comment 12

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Ok, this kinda makes sense. Not sure how to fix it, mind you. Although, having bug 566489 fixed would make this a non-issue.

Comment 13

[Dietrich Ayala (:dietrich)]

Blocking+ due to regression of long-standing well-known pref.

Comment 14

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Any reason this needs to block beta5, rather than final (or betaN)?

(There's no chance I can get to this before beta5)

Comment 17

[Jake]

Is this too easy or too hard? why takes so long?

Comment 18

[Johnathan Nightingale [:johnath]]

Can't block on non-standard pref

Comment 21

[Dietrich Ayala (:dietrich)]

Blair, if you're not working on this, can you summarize what would need to be done to fix it, so others can jump in?

Comment 22

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #21)
> summarize what would need to be done to fix it

Step 1: Wait until bug 566489 is fixed.
Step 2: Profit!

Bug 566489 will have the lovely side-effect of inadvertently fixing this bug.

Assigning to the owner of bug 566489, just so no one else accidentally picks it up.

Comment 23

[Phil Ringnalda (:philor)]

(In reply to comment #22)
> Assigning to the owner of bug 566489, just so no one else accidentally picks
> it up.

Well, except you made the person who attached a patch there clear back in September of last year the QA contact of this bug, not the assignee.

Comment 25

[Michael Ventnor]

Bug 566489 landed, so this bug should be fixed too.

Comment 26

[Vlad [QA]]

Verified fixed on Mozilla/5.0 (X11; Linux i686; rv:6.0a2) Gecko/20110526 Firefox/6.0a2

Comment 27

[Matt Brubeck (:mbrubeck)]

Reopened due to back out of bug 566489.

Comment 28

[Sav]

Didn't know which bug form to fill this out in, the URL trimming replaces the letter h with this.

Comment 30

[Dietrich Ayala (:dietrich)]

Bug 566489 looks to be abandoned again. For now can we change 'moz-action' to something which is unlikely to be typed by a human? Would that work around the problem? Is there a reason to have it be human-readable?

Comment 31

[Michael Ventnor]

(In reply to comment #30)
> Bug 566489 looks to be abandoned again. For now can we change 'moz-action'
> to something which is unlikely to be typed by a human? Would that work
> around the problem? Is there a reason to have it be human-readable?

It's not abandoned, it's just being rewritten.
The new approach will be synchronous and should still fix this bug.

Comment 32

[Bur]

If it helps, the bug seems only to happen when the letter 'h' is typed. With all else the autofill feture works fine for me.

Comment 33

[Dietrich Ayala (:dietrich)]

Bug 566489 is complicated, and is looking at a possible second backout.

The wallpaper approach suggested in comment #30 will mitigate this bug with no change to code. Blair, is this a reasonable way to fix this in the short term?

Comment 34

[Mimi Burned]

I can confirm that this is only happening when typing the letter 'h', it gets changed to 'w'

Comment 35

[Loic]

I guess Bug 678352 is a dupe of this bug.

Comment 36

[Ryan Curtis]

For me this bug happens when I type the letter 'h' in the bar, and it is changed to an 'f'.  The autofill shows "fedoraproject.org" as the match with the H in "Fedora Project Homepage" highlighted.  If I type quickly enough, a 'h' will stay an 'h', but if I hesitate at all it will be changed to an 'f'.

Comment 37

[ffbug]

It isn't just with 'h'. Even 'm' turns into a 'w'. Here's what's happening - As you start with the 1st character of the URL you are trying to get to, the auto-complete kicks in, just like in previous versions. 
The difference now is, even though the typed character is shown in bold, the entire URL after the 1st character is highlighted. When the 2nd character is typed, the 1st highlighted character is replaced with the typed character. Since 'www' is the URL prefix in most cases, 'w' is the 1st un-highlighted. So, typing 'ho' for www.hotmail.com changes into a 'wo' Notice the bold 'h' when typing and also notice the entire URL is highlighted, except for the 1st w in www. Same thing happens if I try typing a 'm' for www.msnbc.msn.com. The URL turns into 'ws'

Comment 38

[ffbug]

Attachment: Screenhot 1

After typing 'h', notice the 'h' in all shown URLs is bold, however, the entire URL is highlighted.

Comment 39

[ffbug]

Workaround: Changed the "browser.urlbar.delay" setting to 500. This slows down the autocomplete suggestions and allows for time to enter the 2nd character (eg:ho) which then displays the correct suggestions.

Comment 43

[Matt Brubeck (:mbrubeck)]

This was fixed again by the re-landing of bug 566489.