1847723 - URI Fixup always prepends 'http' even when original url used 'https'

Status: NEW

(Firefox :: Address Bar, defect, P2)

Description

[Marc Seibert (:mseibert)]

When a customer has '.trimHttps' enabled (a pref that is introduced in #1846261), then the fixup uri should also have "https://" as the scheme.

Comment 1

[Marco Bonardo [:mak]]

What do you mean in the title by "even when original url used 'https'", that the user has typed https and we replaced it with http?
That'd be definitely a bug, but I'd like to know more about that.

If instead you mean adding https instead of http, it's not that easy, doing so would indeed break navigation to local uris and service, like the router page for example. We'll instead rely on https-first (Bug 1704453).
Bug 1812192 will be the first step towards that.
It's possible in the future we may be able to set https initially, and let the https-first fallback, but until that fallback is in, we can't touch URIFixup.

Comment 2

[Marc Seibert (:mseibert)]

In Bug 1067293 I had to implement something like this

let trimHttps = lazy.UrlbarPrefs.get("trimHttps");
if (trimHttps && this._untrimmedValue.startsWith("https://")) {
  untrim = fixedURI.displaySpec.replace("http://", "https://");
} else {
  untrim = fixedURI.displaySpec != expectedURI.displaySpec;
}

in order to ensure that the correct protocol is restored when "untrimming". So, yes I mean the first thing. fixedURI.displaySpec is not returning the 'http://' scheme when a user entered an URL with https:// scheme.

Comment 3

[Marco Bonardo [:mak]]

I see, we should always respect what the user has typed, my only concern is when the user didn't type an explicit protocol. Thank you for the clarification.

Comment 4

[Marco Bonardo [:mak]]

The first thing we need here is bug 1812192.
Then we should investigate what we use for displaySpec here and why we can't just reattach the original protocol, or trim later in the view.