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

RESOLVED FIXED

Status

()

Firefox
Location Bar
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: mbrubeck, Assigned: Michael Ventnor)

Tracking

(Depends on: 1 bug, {regression})

Trunk
x86
Linux
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [switch-to-tab][needs 566489])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
Created attachment 439575 [details]
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.
Do you have browser.urlbar.autoFill set to true?
(Reporter)

Comment 2

7 years ago
(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.
Summary: "Switch to tab" autocomplete replaces typed characters in awesomebar with tab URL characters → browser.urlbar.autoFill replaces typed characters in awesomebar with tab match URL characters
(Reporter)

Comment 3

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

Comment 4

7 years ago
(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?
(Reporter)

Comment 5

7 years ago
"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

7 years ago
Created attachment 456316 [details]
moz-action

Comment 7

7 years ago
(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.
(Reporter)

Comment 8

7 years ago
(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

7 years ago
(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

7 years ago
Disregard that. Location bar 2 addon caused it.
Duplicate of this bug: 581703
Ok, this kinda makes sense. Not sure how to fix it, mind you. Although, having bug 566489 fixed would make this a non-issue.
(Reporter)

Updated

7 years ago
blocking2.0: --- → ?
Blocking+ due to regression of long-standing well-known pref.
Assignee: nobody → bmcbride
blocking2.0: ? → beta5+
Keywords: regression
Any reason this needs to block beta5, rather than final (or betaN)?

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

Updated

7 years ago
blocking2.0: beta5+ → betaN+

Updated

7 years ago
Attachment #456316 - Attachment is obsolete: true

Updated

7 years ago
Duplicate of this bug: 599678
Depends on: 566489
Duplicate of this bug: 610348

Comment 17

7 years ago
Is this too easy or too hard? why takes so long?
Can't block on non-standard pref
blocking2.0: betaN+ → -
Whiteboard: [switch-to-tab]
Duplicate of this bug: 633682

Updated

6 years ago
Duplicate of this bug: 644091
Assignee: bmcbride → nobody
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?
(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.
Status: NEW → ASSIGNED
QA Contact: location.bar → ventnor.bugzilla
Whiteboard: [switch-to-tab] → [switch-to-tab][needs 566489]
(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.
QA Contact: ventnor.bugzilla → location.bar
Assignee: nobody → ventnor.bugzilla

Updated

6 years ago
Duplicate of this bug: 658447
(Assignee)

Comment 25

6 years ago
Bug 566489 landed, so this bug should be fixed too.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 659437

Comment 26

6 years ago
Verified fixed on Mozilla/5.0 (X11; Linux i686; rv:6.0a2) Gecko/20110526 Firefox/6.0a2
Status: RESOLVED → VERIFIED
(Reporter)

Comment 27

6 years ago
Reopened due to back out of bug 566489.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 28

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

Updated

6 years ago
Duplicate of this bug: 667450
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?
Version: Trunk → 6 Branch
Version: 6 Branch → Trunk
(Assignee)

Comment 31

6 years ago
(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

6 years ago
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.
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

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

Comment 35

6 years ago
I guess Bug 678352 is a dupe of this bug.

Comment 36

6 years ago
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

6 years ago
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

6 years ago
Created attachment 582468 [details]
Screenhot 1

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

Comment 39

6 years ago
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.

Updated

6 years ago
Duplicate of this bug: 688942

Updated

6 years ago
Duplicate of this bug: 680766

Updated

6 years ago
Duplicate of this bug: 653845
(Reporter)

Comment 43

6 years ago
This was fixed again by the re-landing of bug 566489.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.