1872742 - Omnibox downgrading https to http when browser.urlbar.trimHttps is set to true

Status: RESOLVED DUPLICATE of bug 1848715

(Firefox :: Address Bar, defect)

Description

[Fumnanya]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0

Steps to reproduce:

Occurs on Firefox Nightly version 123.0a1 (2023-12-31) on Fedora.

With browser.urlbar.trimHttps turned on (by default) URLs in the address bar have the "https://" portion removed (the browser.urlbar.trimURLs setting seems to do this for "http://" as well).

I tried to access https://localhost:5000, which worked.
This shows up as "localhost:5000".
Then tried to add a "/home" to the end of the URL in the address bar.

Actual results:

Instead of navigating to "https://localhost:5000/home", this goes to "http://localhost:5000/home".

This also occurs with non-local URLs, I tested with google.com and mozilla.org.
I also have HTTPS-only mode turned on, which didn't affect this whether it was on or not.

Expected results:

The browser should keep the prefix of whatever the current page currently is, as opposed to always using "http://" when it is hidden with browser.urlbar.trimHttps=true

When browser.urlbar.trimHttps is turned off, adding extra bits to the URL doesn't change the initial prefix, which is intended behaviour.

Curiously, I asked my friends on macOS to check the default value of browser.urlbar.trimHttps, and it's false. I happen to use the proletarius101/firefox-nightly COPR repo to get firefox-nightly through dnf, so maybe that affects the "default" settings)
Someone else I know on Windows also says its false by default.

Comment 1

[Fumnanya]

Attachment: when trimHTTPS=false, extra content is appended correctly

Comment 2

[Fumnanya]

Attachment: when trimHTTPS=true, extra content is appended with the assumption that it is a HTTP site - even though the site is already open as HTTPS

Comment 3

[Fumnanya]

Attachment: previously visited URLs autocomplete with the correct prefix

Comment 4

[Fumnanya]

Attachment: an example error page for when it isn't redirected to HTTPS

Most sites would redirect you back to HTTPS even if you mistakenly enter a HTTP one because of this - but this ASP.NET application didn't, and it displayed this error.

This doesn't really concern the actual bug, it's just surprising - I assume HTTPS-Only mode doesn't kick in on localhost addressed so maybe that's why.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 6

[Fumnanya]

support article talking about it, dated 2013
https://support.mozilla.org/en-US/questions/949113

Comment 7

[Daniel Bodea [:danibodea]]

I reproduced it on WIndows 10 and Ubuntu 22.

Firstly, I have to say that browser.urlbar.trimHttps is only true by default in Nightly v123.0a1. Unknown if it's channel dependent or branch dependent. Furthermore, this pref does not exist in ESR v115. This is (most likely) an issue since the implementation of this pref.

Steps used:

1. Create a new profile!
2. Make sure browser.urlbar.trimHttps is true
3. Load mozilla.org
   Observe: it loads the "secure" page (HTTPS even if it's not visible in address bar)
4. add "/home" after the link (making it www.mozilla/org/.../home) and observe the address bar suggestion.
   Expected: Link suggested is secured (https://...)
   Actual: Link suggested is NOT seccured (http://...)

It looks like the browser is firstly looking for an insecure page if the https is not present in the urlbar, while using these steps.
I've set the "Search" component because it seems like the place to be. if incorrect, please revert it.

Thank you for your report!

Comment 8

[Mark Banner (:standard8)]

We think this is a duplicate of bug 1848715