1614957 - strip www. prefix in address bar results

Status: VERIFIED FIXED

(Firefox :: Address Bar, enhancement, P1)

Description

[Mike Connor [:mconnor]]

Other browsers have already taken this step, we should follow suit to enhance readability.

Comment 1

[Dão Gottwald [:dao]]

Attachment: Bug 1614957 - strip www. prefix in address bar results. r=adw

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7a7d4fdddf8d
strip www. prefix in address bar results. r=adw

Comment 3

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/7a7d4fdddf8d

Comment 4

[Marco Bonardo [:mak]]

Dao, should we uplift this to Beta?

Comment 5

[Dão Gottwald [:dao]]

mconnor said no in the meeting where we discussed this change, he didn't want to cram more changes into 74. I don't have a strong opinion either way.

Comment 6

[Serge]

Hi here,
For some reason the mentioned change (hide www and http from the megabar dropdown results) works for me only if browser.urlbar.trimURLs is set to true.

Nightly 75.0a1 (2020-02-25)
browser.urlbar.trimURLs itself has the following logic:

• true - hide http:// from URL bar (https:// is visible)
• false - both http:// and https:// are visible in the URL bar.

Current behavior seem a bit strange: http:// is hidden from the URL bar (but https is present there) and both are removed from the megabar dropdown results

Separating megabar dropdown results into a separate pref instear of relying on browser.urlbar.trimURLs sound more logical.
Any thoughts on this?

Comment 7

[Dão Gottwald [:dao]]

(In reply to Serge from comment #6)

Current behavior seem a bit strange: http:// is hidden from the URL bar (but https is present there) and both are removed from the megabar dropdown results

Only either "http://" or "https://" should be removed from the results list (depending on the browser.urlbar.update1.view.stripHttps pref), not both. Also note that "www." only gets removed with said stripHttps pref set to true. This is a temporary inconsistency as we're going to remove that pref after shipping it enabled by default.

Separating megabar dropdown results into a separate pref instear of relying on browser.urlbar.trimURLs sound more logical.
Any thoughts on this?

There are legitimate reasons why power users might want to not have parts of URLs hidden, so I think it's important to offer a hidden pref to disable that behavior altogether. Enabling it on one part of the UI but not in the other seems like an esoteric use case that I don't think we need to support.

Comment 8

[Serge]

Only either "http://" or "https://" should be removed from the results list (depending on the browser.urlbar.update1.view.stripHttps pref), not both. Also note that "www." only gets removed with said stripHttps pref set to true. This is a temporary inconsistency as we're going to remove that pref after shipping it enabled by default.

Hmmm, I have the following behavior:
Case 1:
browser.urlbar.update1.view.stripHttps >> true
browser.urlbar.trimURLs >> false
Result:
megabar dropdown results: http://, https://, www are present.
URL-bar: http://, https://, www are present.
Case 2:
browser.urlbar.update1.view.stripHttps >> true
browser.urlbar.trimURLs >> true
Result:
megabar dropdown results: http://, https://, www are stripped.
URL-bar: http:// - stripped, https://, www - present.

My main concern is that I need to flip browser.urlbar.trimURLs >> true to make megabar dropdown results (browser.urlbar.update1.view.stripHttps) changes to work.
Is this an expected behavior?

There are legitimate reasons why power users might want to not have parts of URLs hidden, so I think it's important to offer a hidden pref to disable that behavior altogether. Enabling it on one part of the UI but not in the other seems like an esoteric use case that I don't think we need to support.

As for time being I flip browser.urlbar.trimURLs >> false to make URL bar behavior consistent (to show both http:// and https://)

Comment 9

[Dão Gottwald [:dao]]

(In reply to Serge from comment #8)

My main concern is that I need to flip browser.urlbar.trimURLs >> true to make megabar dropdown results (browser.urlbar.update1.view.stripHttps) changes to work.
Is this an expected behavior?

Yep. browser.urlbar.trimURLs is the only pref we'll support long-term, browser.urlbar.update1.view.stripHttps is going to go away.

Comment 10

[Serge]

Hmm, if I understand correctly browser.urlbar.trimURLs in the long term will control overall URL stripping behavior for both URL bar and dropdown results.
If this is the case then there is still some inconsistency.
If pref is set to true users will never see http://, https://, www in the dropdown results, but they will encounter https:// in URL bar.
Consistency-vice in such scenario http://, https://, www should be stripped in both areas the same way...
Or... URL bar and dropdown results stripping should function separately...

Not like I am against the https://, http:// in the URL bar (I am quite the opposite, and like/believe it to be shown there)

What I am uncertain whether it will be possible to have both http:// and https:// in the URL bar (browser.urlbar.trimURLs >> false) and have them stripped from the dropdown results at the same time?

Comment 11

[Dão Gottwald [:dao]]

(In reply to Serge from comment #10)

Hmm, if I understand correctly browser.urlbar.trimURLs in the long term will control overall URL stripping behavior for both URL bar and dropdown results.
If this is the case then there is still some inconsistency.
If pref is set to true users will never see http://, https://, www in the dropdown results, but they will encounter https:// in URL bar.

No. In the address bar we strip "http://", in the results we strip "https://" and "https://www." but NOT "http://" as I mentioned before; see bug 1589923.

Consistency-vice in such scenario http://, https://, www should be stripped in both areas the same way...

We don't strip "https://" in the address bar because if we did, hitting Enter would attempt to use an unencrypted connection. We don't strip "http://" in the results so that the user can see beforehand whether a result is going to use a secure connection.

Comment 12

[Madis]

Nearly 300 common users and developers are against this change in Chrome, why bring it to Firefox? https://bugs.chromium.org/p/chromium/issues/detail.id=883038

Also, why make it inconsistent with the common URL display (e.g. hiding https and showing http while the address bar does the opposite)?

Comment 13

[Serge]

To be honest, I totally agree with previous comment.
I see little logic in the change.
Both entities should share the same display logic. If this is not possible/achievable during some valid reasons then they should have separate prefs, so users can chose what they want with each one of them

Comment 14

[Marco Bonardo [:mak]]

The right link is https://bugs.chromium.org/p/chromium/issues/detail?id=883038 and apparently it's very different, as far as I understand it, Chrome was hiding www. and m. also from the input field. that was shipped in Chome 69, and then m. elision has been reverted in Chrome 70. So www. elision stays.
We are only stripping www in urlbar results, not from the input field.

Comment 15

[Darkspirit]

Chrome hides both protocols which is confusing IMHO. Hiding one is totally fine.
If you press the down arrow key, the address bar correctly shows https://. It's a transition taking into account that most page loads are https.
I guess bug 1067293 behind a default-to-https pref could address some complaints.

Comment 16

[Marco Bonardo [:mak]]

Yes, long term we should show http and strip https. The Web is going that direction.
But currently there's no plan to hide www. from the url shown when browsing, if that should ever happen it will require a deep understanding of the problem and a lot of study.

Comment 17

[Madis]

In that case it shouldn't be hidden from autocomplete either, how does that not require "deep understanding of the problem and a lot of study"?

Comment 18

[Marco Bonardo [:mak]]

What we made is merely a visual help, a cleaner panel helps users to find what they are looking for, and makes the origin more prominent, that has clear advantages. What I meant is that changing the url of the page you are on has deeper implications, because in most cases you are not picking a url from a list, maybe you are clicking a link, or a page is redirecting you... You can end up on a page in a lot of ways, hiding parts of the url of the current page has serious implications that must be evaluated.

Comment 19

[Mozira]

URI with www and without www contains different domains. It means version with www and without www is able to serve other content. The "www." should not be shown. Https and http can be peresented as padlock and crossed padlock. If "ftp://" the protocol still should be visible.

Comment 20

[Mozira]

• The "www." should not be hidden.

Comment 21

[Darkspirit]

If a website violates best practices it might confuse their users a bit (or harm their search engine reputation), but the address bar anyway still shows www. Just press the down arrow key and you see that www is present. Every other protocol than the default protocol is visible.

Comment 22

[Madis]

If you still want to go with this, how about some heuristics?
Say, if the user did type a www. to enter a site, save it and display it in autocomplete (because that's what user expects). If the user did not type it, elide it (regardless of actual redirects).

Comment 23

[Marco Bonardo [:mak]]

We keep tracking feedback and if this should cause obvious disruption among users we'll intervene.
Complicating things with heuristics that can arguably fail, or confuse the user even more, doesn't sound promising. More specifically your heuristic is biased, because users have been trained for years to think the Web is www.something.

Comment 24

[u614622]

It is very bad direction. Don't follow google in this matter. This will cause lots of safety trouble for people. Instead push this as an option in settings to show or not to. If someone would like to see it can be switched on.

Comment 25

[Rin Cat]

Why we just can't see what true URL is? Hide 'www.' will increase readability is a ridiculous theory. Save 4 characters from a long URL is pointless. People already get used to it over 30 years, and they know 'www' means some website's main site. And technically www and naked domain are two different sites, you can not assuming they are the same.

Comment 26

[Darkspirit]

(In reply to Rin Cat from comment #25)

Why we just can't see what true URL is?

You could set browser.urlbar.trimURLs to false.

And technically www and naked domain are two different sites, you can not assuming they are the same.

For users they are the same. If you are responsible for such a rare confusing setup, please fix it - please.

Comment 27

[Rin Cat]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #26)

(In reply to Rin Cat from comment #25)

Why we just can't see what true URL is?

You could set browser.urlbar.trimURLs to false.

And do it every time when use public/library/someone else computers.

And technically www and naked domain are two different sites, you can not assuming they are the same.

For users they are the same. If you are responsible for such a rare confusing setup, please fix it - please.

I don't have such rare setup, but www and naked domain cookies could not be the same. As naked domain cookies could be pass to other subdomains.

Comment 28

[Darkspirit]

(In reply to Rin Cat from comment #27)

As naked domain cookies could be pass to other subdomains.

Offtopic, but will help to understand this aspect:
It's still a free choice to host on www or apex domain. Apex domain cookies can be isolated by __Host- prefix:

Sent only to the host which set the cookie. That is, a cookie named "__Host-cookie1" set from "https://example.com" MUST NOT contain a "Domain" attribute (and will therefore be sent only to "example.com", and not to "subdomain.example.com").

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Cookie_prefixes
https://caniuse.com/#feat=mdn-http_headers_set-cookie_cookie_prefixes
The perfect cookie:
Set-Cookie: __Host-key=value; Path=/; Secure; HttpOnly; SameSite=Lax

Comment 29

[Avlasenko Vitaliy]

What a stupid decision to do this... Didn't find a people in the Net that would like this. "Chrome does it, so we should do also" is not a reason. What people should do if "www.example.com" and "example.com" point to two different websites?

Comment 30

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I can confirm the intended behavior is respected. I verified using Fx 75.0, on Windows 10 x64, macOS 10.13 and Ubuntu 18.04.