1848715 - Editing and copying URL loses "https://" URL scheme when browser.urlbar.trimHttps = true

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Chris Peterson [:cpeterson]]

Steps to reproduce

1. Set browser.urlbar.trimHttps = true.
2. Open https://www.example.com/
3. Click focus to the address bar. You will be editing the string www.example.com instead of https://www.example.com/. Expanding the edited string to the full URL, https://www.example.com/, like Chrome would fix this bug.
4. Edit the URL, such as changing .com to .net.
5. Ctrl+A and Ctrl+ C to select all and copy the URL text.
6. Pass the copied URL in another tab or app.

Expected results

https://www.example.net/ like in Chrome.

Actual results

www.example.net

This behavior happens with http:// URLs when browser.urlbar.trimHttps = false, but when this behavior affects https:// URLs, it can happen on many more websites.

Comment 1

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

:mseibert, since you are the author of the regressor, bug 1067293, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Dão Gottwald [:dao]]

We're aware of this shortcoming but it's not currently considered a blocker. The HTTPS-first feature that's currently being worked on by the Security team would somewhat mitigate this.

Adopting Chrome's behavior would be an option, but the URL jumping around when editing it isn't great. :/

Comment 4

[Marc Seibert (:mseibert)]

Attachment: Bug 1848715 - Untrim on intearction with urlbar.r=mak

Comment 5

[Sven Marnach :sven]

I ran into this issue today when manually editing REST API URLs. The server did not listen on port 80 at all, so everytime I edited the URL the request simply stopped reaching the server, and even if I just remove a slash from the end of the URL, I had to manually add https:// back at the beginning.

I'd personally consider this more severe than it sounds in the comments here. Firefox completely unexpectedly sent my URL over an unencrypted connection, when I had a reasonable expectation that it would not do that. This might even leak private data.

Comment 6

[Marco Bonardo [:mak]]

It is sever yes, but this change is only enabled in Nightly exactly to identify and address these issues.

You can enable dom.security.https_first_schemeless if you wish the urlbar to try https first. That will be the default once we have addressed remaining issues.

Comment 7

[Marc Seibert (:mseibert)]

Attachment: Bug 1848715 - Always untrim on focus.r=mak

Comment 9

[Marc Seibert (:mseibert)]

Attachment: WIP: Bug 1848715 - Always untrim on focus with doubleclick correction.r=mak

Comment 13

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

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 14

[Marco Bonardo [:mak]]

I'll take this over soon.

Comment 15

[Marco Bonardo [:mak]]

Attachment: Bug 1848715 - Untrim address bar value on user interaction. r=dao

Untrim the address bar value when the user starts manipulating it.
This doesn't untrim on focus because that breaks double-click to select word,
and we'd need a way to simulate word boundaries selection. It's possible we'll
evaluate that in the future, once we have such method.
The behavior is currently behind the feature-gate preference:
browser.urlbar.untrimOnUserInteraction.featureGate

Original patch by Marc Seibert.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/96d4e09e1242
Untrim address bar value on user interaction. r=dao,tabbrowser-reviewers

Comment 17

[Aron Cseh]

https://hg.mozilla.org/mozilla-central/rev/96d4e09e1242

Comment 18

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Issue is reproducible on a 2023-08-14 Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 127.0a1 on Windows 10, Ubuntu 22, macOS 12.