762913 - Location bar autocomplete trims URLs inappropriately and does not show the current best choice in pulldown

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[LummoxJR]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0
Build ID: 20120605113340

Steps to reproduce:

Last night I got the update for Firefox 14 in the beta channel. Leaving aside the favicon removal, which is annoying beyond belief if your tabs are auto-hidden, I discovered that the new awesomebar behavior is downright unworkable. There are two changes to behavior that are a regression, and together make the location bar extremely difficult to use where it was once easy.


Actual results:

First, when I type a URL in the location bar, I see only the host name--not the protocol or www prefix. This behavior would be perfectly sensible for people who leave on the default setting of trimming URLs, but I deliberately turned that setting off. This is a severe usability problem because I can't even tell if I'm going to the http or https version of a site, and that does in fact matter in my browsing.

In the past however, I also could simply press the down arrow key to go to the top one or two autocomplete results in my awesomebar. If that was still available, the usability problem presented by trimming the URL would be mitigated; however it is not. The awesomebar results now no longer show appropriate suggestions ranked by the frequency with which I visit, but seem to be chosen more or less at random. As a simple example, I type "fac" and instead of http://www.facebook.com at the top of my results, I have a large number of https://www.facebook.com URLs with extra parameters. (Additionally, if I type out the actual protocol the awesomebar results don't reflect that, but there is already a separate bug report for that issue.)


Expected results:

The location bar should retain the behavior it had in Firefox 13, in which full URLs were shown in autocomplete (at least if URL trimming is turned off), and the suggestions should be ordered by frequency as they were before.

Comment 1

[LummoxJR]

Apparently bug 720081 accounts for the first part, and supposedly is fixed in Firefox 15. But for the love of all that is holy, this needs to be backported to the 14 beta. It's a serious usability issue.

For the rest, I found that this setting was responsible for the awesomebar's sudden crappitude and I was able to change it:

services.sync.prefs.sync.browser.urlbar.autocomplete.enabled = true

Changing this to false removed the behavior that was showing me bizarre results in the dropdown. The bogus results I'm getting with it on should be considered a bug however; I can't imagine showing completely unsorted history items is beneficial to anybody. For now I have restored some of the lost functionality by disabling the setting, but this new default setting is clearly badly broken.

Comment 2

[LummoxJR]

My mistake; the sync setting actually does not fix usability, and I'm back to square one.

Comment 3

[Marco Bonardo [:mak]]

(In reply to LummoxJR from comment #0)
> First, when I type a URL in the location bar, I see only the host name--not
> the protocol or www prefix.

You mean in inline-autocomplete? Since you are typing we can't change text below you, would be quite crazy if you type fac, and we replace it immediately with www.fac or whatever else. Though you can type the protocol and also www. if you wish, nobody disallows you from forcing those. FWIW, inline by itself, if available in your history, will always prefer secure versions.
If you meant something else, please clarify.

> The awesomebar results now no longer show
> appropriate suggestions ranked by the frequency with which I visit, but seem
> to be chosen more or less at random.

Nothing changed in our code relative to those results, so something must have happened on your side, or due to some add-on, or even due to Sync.

(In reply to LummoxJR from comment #1)
> Apparently bug 720081 accounts for the first part, and supposedly is fixed
> in Firefox 15. But for the love of all that is holy, this needs to be
> backported to the 14 beta. It's a serious usability issue.

That fix IS in Firefox 14.  The addition of the protocol and www don't happen while you type (for the above reasons) but when you confirm the match.

> For the rest, I found that this setting was responsible for the awesomebar's
> sudden crappitude and I was able to change it:
> 
> services.sync.prefs.sync.browser.urlbar.autocomplete.enabled = true

You disabled autocomplete on some other device and that setting has been synced to your desktop?
I don't understand though, that preference is not used by the product, it's just saying sync will copy the pref value across devices.
But also what the original pref ("browser.urlbar.autocomplete.enabled")_does is completely disabling autocomplete, so you should not get ANY result.

Are you sure you don't have some add-ons modifying autocomplete?

Comment 4

[LummoxJR]

The sync thing was a red herring; I found out it had nothing to do with fixing the issue for me, but I had been trying everything I could think of.

I disabled the inline autofill because I find the current behavior simply unworkable--it seems to me the suggestion it's picking up should be the very first one showing in the awesomebar, which it is not. Ironically though, it does autofill with the suggestion that the awesomebar SHOULD be showing. This suggests the list of results displaying in the awesomebar had something go wrong, but the autofill is using the right data.

As of right now the awesomebar's results are still wrong no matter what I do. The results should be ordered by frequency, and they are not. They do seem to be impacted by visiting a site again; typing in a URL manually and going there seems to drag it to the top of the list.

Comment 5

[Marco Bonardo [:mak]]

(In reply to LummoxJR from comment #4)
> I disabled the inline autofill because I find the current behavior simply
> unworkable--it seems to me the suggestion it's picking up should be the very
> first one showing in the awesomebar, which it is not.

Right, that's expected, it's an additional suggestion, not the first one in the popup that remains available as usual.

> Ironically though, it
> does autofill with the suggestion that the awesomebar SHOULD be showing.
> This suggests the list of results displaying in the awesomebar had something
> go wrong, but the autofill is using the right data.

They are just using different data sources, connected though (autofill gets data from old autocomplete).

> As of right now the awesomebar's results are still wrong no matter what I
> do. The results should be ordered by frequency, and they are not. They do
> seem to be impacted by visiting a site again; typing in a URL manually and
> going there seems to drag it to the top of the list.

I'm not sure what happened in your case, but I can ensure you nothing changed there, personally I'm using that version from months, and didn't notice any difference :(

Comment 6

[LummoxJR]

(In reply to Marco Bonardo [:mak] from comment #5)
> (In reply to LummoxJR from comment #4)
> > As of right now the awesomebar's results are still wrong no matter what I
> > do. The results should be ordered by frequency, and they are not. They do
> > seem to be impacted by visiting a site again; typing in a URL manually and
> > going there seems to drag it to the top of the list.
> 
> I'm not sure what happened in your case, but I can ensure you nothing
> changed there, personally I'm using that version from months, and didn't
> notice any difference :(

I suspect that the update process fried my places.sqlite file in some way. The problem continued when I switched back to Firefox 13 due to an unrelated bug (high memory growth over time and high idle CPU usage). There was no sign of a places.sqlite.corrupt file, but oh well. Maybe next time I update I'll just back up my file to be safe.

Comment 7

[Marco Bonardo [:mak]]

(In reply to LummoxJR from comment #6)
> I suspect that the update process fried my places.sqlite file in some way.

Strange, in case we replace the database it makes a .corrupt. in your case looks like frecency values uf uris were "reset" or changed in the upgrade process.

Comment 8

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.