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

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

Dao, should we uplift this to Beta?

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.

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?

(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.

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://)

(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.

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?

(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.

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.

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.

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.

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"?

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.

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).

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.

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.