1904837 - http:// scheme is displayed in address bar when request upgraded by HTTPS-First is loading

Status: NEW

(Firefox :: Address Bar, task, P3)

Description

[Malte Jürgens [:maltejur]]

Attachment: Screenshot_20240626_145459.png

To see what I mean, open httpstat.us/200?sleep=2000 in a configuration where dom.security.https_first_schemeless is enabled (this is the case in Nightly). You should see:

• http://httpstat.us/200?sleep=2000 loading for 2s
• When the site is completely loaded, the address bar should display httpstat.us/200?sleep=2000 instead (so a secure URL with https trimming enabled)

But in this case, we only do a external request to https://httpstat.us/200?sleep=2000, and not http://httpstat.us/200?sleep=2000. So I think we should probably not display the http:// scheme while the site is loading, and instead just omit the scheme (similar to what we did in Bug 1876513).

Comment 1

[Marco Bonardo [:mak]]

fwiw, Bug 1876513 was about the results panel, while this seems about what is shown in the input field.
I suspect changing the input field may have more complex implications, we must try.

Comment 2

[Frederik Braun [:freddy]]

Hi Drew, is this going to be part of your big address bar project? It seems neither this bug nor the associated JIRA issue has had any significant activity in the past.

It's unlikely that we are going to be able to tackle this from the HTTPS Adoption folks.

Comment 3

[Marco Bonardo [:mak]]

We didn't consider this a blocker for the Scotch Bonnet redesign so far, because it's a temporary condition, and we've already shown no protocol in the panel, user expectations should be low. There's quite a few higher priority issues to address first for MVP.
Please let us know if you think this is a show-stopper kind of bug that can't wait.

Thinking about this, URIFixup defaults to http, to provide better support for intranet addresses, and schemeless attribute is passed down along with the request for upgrade. We should debug what is setting the http url here, if it is set by onLocationChange or some other pre-emptive code.

Anyway, I suspect it would end up being a visual hack for this specific schemeless-http case, that is likely to make the code more cumbersome.
Imo it would be much easier to address this issue by stripping both http AND https in the input field, that is something we want to do in the future (after Scotch Bonner), but we don't have a specific date.

Comment 4

[Frederik Braun [:freddy]]

(In reply to Marco Bonardo [:mak] from comment #3)

Anyway, I suspect it would end up being a visual hack for this specific schemeless-http case, that is likely to make the code more cumbersome.
Imo it would be much easier to address this issue by stripping both http AND https in the input field, that is something we want to do in the future (after Scotch Bonner), but we don't have a specific date.

No objections here, just stating the obvious. What you call a specific case is the default in Firefox since 129 (August 2024).

Comment 5

[Frederik Braun [:freddy]]

Maybe we want to duplicate this against bug 1850491 or something below that meta bug?

Comment 6

[Marco Bonardo [:mak]]

I'm not sure I understand. We still want to fix this, and there's no other bug about this issue where we temporarily show http in the input field.

At a maximum we could make this depend on a bug to strip both http AND https. I suggesting splitting that out of Bug 1736955. For now I'll add that as a dependency.