Better indicate when autofill will visit the https entry.

RESOLVED DUPLICATE of bug 1322747

Status

()

Firefox
Address Bar
P3
normal
RESOLVED DUPLICATE of bug 1322747
a year ago
9 months ago

People

(Reporter: Nicos Gollan, Unassigned)

Tracking

48 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxsearch])

Attachments

(2 attachments)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160803004522

Steps to reproduce:

Visit a site A, say, http://www.site-a.local/blah and a sibe B, e.g., http://site-b.local/bar ; note that A has a subdomain in its domain-name (www). Also visit subresources on both sites.


Actual results:

When entering "site-a" in the location bar for subsequent visits, "www.site-a.local" places, the desired result, will be in second place. However, when entering "site-b", then the place for B will be mangled into the "Visit" result on top of the list.

This means that for one set of sites (with subdomains), navigation is (1) enter search string, (2) arrow down, (3) enter; but for sites without subdomains, step (2) consistently leads to arbitrary subresources due to the mangling of places.

The browser *also* makes a strong and *incorrect* assumption that everything is reachable on the plain domain name without any hostnames for the Visit result.


Expected results:

The browser MUST exhibit homogeneous behaviour so either the top hit or the second hit is *always* the same presumed user intention. It MUST NOT squash results into the "Visit" thing for one set of sites and the most visited resource for others.

The browser MUST NOT assume that hostnames do not exist or are unneccessary.
Component: Untriaged → Location Bar
(In reply to Nicos Gollan from comment #0)
> When entering "site-a" in the location bar for subsequent visits,
> "www.site-a.local" places, the desired result, will be in second place.
> However, when entering "site-b", then the place for B will be mangled into
> the "Visit" result on top of the list.

I expect the top preselected suggestion to be "site-a.local" and "site-b.local" respectively, where the former will go to "www.site-a.local" while the latter will go to "site-b.local". What is shown doesn't matter, cause it's just a mere placeholder that copes with what's in the input field.
Is not this what happens?

Since the "action row" (that's how we call the "visit" row) is pre-selected, reaching the url with the complete path is still a single arrow down, as it was before 48, when nothing was preselected. Nothing changed here.

> The browser *also* makes a strong and *incorrect* assumption that everything
> is reachable on the plain domain name without any hostnames for the Visit
> result.

This is untrue, we show the domain without a subdomain, but we use the subdomain when visiting.

Could be I misunderstood some parts of this report, if so please try to make it more clear, by indicating for each host, what you see and what you expect to see.

Thanks.
(Reporter)

Comment 2

a year ago
Created attachment 8787530 [details]
Navigation actions without "subdomain"
(Reporter)

Comment 3

a year ago
Created attachment 8787531 [details]
Navigation actions with "subdomain"
(Reporter)

Comment 4

a year ago
Attached two screenshots, one showing the navigation suggestions for a site that got into Places without a host below its domain (petapixel.com) and another that uses a "www" host (fstoppers.com). Navigating to the front pages takes two annoyingly different actions: for petapixel, enter "peta" and press enter, for fstoppers enter "fstop", arrow down (muscle memory from EVERY Firefox version that had Places), press enter. For petapixel, the front page doesn't even show in the suggestions.

Maybe it's related to fstoppers using HTTPS, but either way those actions need to be the same.
(Reporter)

Comment 5

a year ago
And on second notice, in those cases the subdomain doesn't even matter, sorry for that red herring. So it's something else that mixes things up.
(Reporter)

Comment 6

a year ago
In other cases, the location bar will gleefully produce an initial autocompletion for `example.com` and then have `http://www.example.com/` and `https://www.example.com/` in the second and third position, which is not conducive to the "HTTPS all the things" theme otherwise pushed by Mozilla, and a potential (albeit small) privacy leak.
(Reporter)

Updated

a year ago
Summary: Location Bar completion broken with(out) subdomains → Location Bar autocompletion unintuitive and infuriating
(In reply to Nicos Gollan from comment #6)
> In other cases, the location bar will gleefully produce an initial
> autocompletion for `example.com` and then have `http://www.example.com/` and
> `https://www.example.com/` in the second and third position, which is not
> conducive to the "HTTPS all the things" theme otherwise pushed by Mozilla,
> and a potential (albeit small) privacy leak.

As i said already, the initial "example.com" autocomplete, already includes https if the secure version has been typed even just once. The visual is not great, we may evaluate to add a secure indicator or such.

Updated

a year ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [fxsearch]
Summary: Location Bar autocompletion unintuitive and infuriating → Better indicate when autofill will visit the https entry.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1322747
You need to log in before you can comment on or make changes to this bug.