Closed Bug 1853643 Opened 9 months ago Closed 7 months ago

"IP:Port" URL still interpreted as HTTP even with trimHttps, leading to inconsistency

Categories

(Firefox :: Address Bar, defect, P3)

Desktop
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 1848715
Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 --- unaffected
firefox117 --- unaffected
firefox118 --- disabled
firefox119 --- disabled
firefox120 --- disabled
firefox121 --- disabled
firefox122 --- disabled

People

(Reporter: heftig, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [sng][search-papercut])

Say I'm connected to https://192.168.0.1:1234.

With trimHttps enabled, the address bar only displays 192.168.0.1:1234 but copying the entire location actually copies https://192.168.0.1:1234. This is fine.

However, when I then edit the location to say 192.168.0.1:12345 and press enter, it interprets this as http://192.168.0.1:12345 instead of the https://192.168.0.1:12345 I expected.

https_first and https_only modes do not help. I suppose IP:Port addresses are excluded here.

Whoops, accidentally fat-fingered Return while editing the subject. Editing the rest...

No longer depends on: 1848715
OS: Unspecified → All
No longer regressed by: 1067293
Hardware: Unspecified → Desktop
Version: unspecified → Trunk

Chrome restores the https:// when starting to edit, so it's not a problem there.

See Also: → 1848715

I filed a similar issue Bug 1847723. The problem is that Services.uriFixup.getFixupURIInfo always prepends http:// if there is no protocol explicitly given.

See Also: → 1847723

https_only_mode does help after enabling dom.security.https_only_mode.upgrade_local, but https_first is apparently never applied to addresses with a port.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [sng] → [sng][search-papercut]

What happens here is that by modifying the url it becomes something completely different, there's no given that 192.168.0.1:12345 uses the same protocol as 192.168.0.1:1234. Any assumption about a protocol here has a 50% chance of being wrong.
That's why I don't think this is a P2, we are doing our best with the information at hand, we can't know what the url is, we take the most likely (very few local servers are using https today, yet).

The work being done in bug 1812192 should help here, what we can do is to detect that the address bar added a protocol, and then allow a downgrade to http (or upgrade to https).

I'm tempted to just call this a dupe of bug 1812192, but let's keep it as a dep for now.

Depends on: 1812192
Priority: P2 → P3

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Now that trimHttps has been enabled by default, this is now affecting Nightly by default.

Regressed by: 1853418

Based on comment 5 can this be closed out?

Flags: needinfo?(mak)

Set release status flags based on info from the regressing bug 1853418

I think editing the url makes it a wontfix, though a better solution for the users will be Bug 1848715, where on focus we will untrim the url, then when editing or copying the protocol will be there. So duping there.

Status: NEW → RESOLVED
Closed: 7 months ago
Duplicate of bug: 1848715
Flags: needinfo?(mak)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.