Closed Bug 1700906 Opened 3 years ago Closed 3 years ago

https URLs are not trimmed in the urlbar

Categories

(Firefox :: Address Bar, enhancement, P5)

Firefox 89
enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1067293

People

(Reporter: aminomancer, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

  • Set browser.urlbar.trimURLs to true
  • Check the urlbar's value on this page, it's untrimmed

Actual results:

  • BrowserUIUtils.trimURL only trims http:// off the url string:
get trimURLProtocol() {
    return "http://";
},
trimURL(aURL) {
    let url = this.removeSingleTrailingSlashFromURL(aURL);
    // Remove "http://" prefix.
    return url.startsWith(this.trimURLProtocol)
        ? url.substring(this.trimURLProtocol.length)
        : url;
},

Expected results:

It seems pretty silly for one web protocol to be trimmed and not the other. I can understand not trimming a protocol like ftp or loopbacks, but if someone has this preference enabled then it seems very unlikely that they would want "http" URLs to be trimmed but not "https" URLs. After all, the vast majority of sites users will actually be navigating nowadays support https, and Firefox now ships an https-only mode that finally works very well.

I don't use this preference personally, it only came to my attention from this thread, but if I started using it, I think I'd find it a bit annoying since I almost never see "http" URLs in the wild. A friend thought the preference was simply broken altogether since they never noticed it actually trimming the protocol.

I'm sure this isn't just an oversight and there's likely a good reason, but if nobody can figure out a workaround, then the pref should be disabled by default. This inconsistent behavior makes no sense. It's the reverse of what would make sense, actually. Consistency would obviously be better, but if one of them is going to be untrimmed it should be the unsafe protocol. That way the danger of the current connection is not hidden from the user without their knowledge.

This kind of indicator is more useful when it's showing active danger, rather than showing active safety. As it stands now, depending on the user's other browsing preferences, they may only be able to tell they're on an unencrypted connection by the absence of an explicit protocol in the urlbar. And the absence of an indicator is always going to be worse than an actual indicator.

Of course the identity icon can fill that role so my main complaint is just the inconsistency of it, but if one of them needs to be untrimmed for whatever reason, it should really be the http protocol. And trimming should ideally be disabled by default if it can't be made to behave consistently.

One other thing, the user in that thread asked how to trim URLs in the urlbar but leave URLs in the status bar untrimmed. I worked that out but it made me realize that request makes a lot of sense. The status bar is a transient element and it can afford to take up more space than the urlbar. Users should only see the "overLink" status when they're contemplating clicking a link. This is exactly when they are most likely to need to know the protocol of the link.

It makes a lot of sense for the default behavior to be trimming in the urlbar, and no trimming in the status bar. But instead the status bar uses the urlbar's pref. I get the sense that most users would like to know the protocol of a hyperlink they're considering clicking on. And surely many of them (like me) want the protocol to be displayed in the urlbar all the time too. But for a number of users, simplicity is ideal, at least in the more permanent, prominent UI fixtures. They may want to see the protocol in the status bar, but not necessarily in the urlbar. So having two prefs would be a big improvement

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Component: Networking: HTTP → Address Bar
Product: Core → Firefox

Thanks for the report. It looks like this behavior was added back in bug 665580, where we started hiding http:// but not https:// in the urlbar. The copy-paste behavior just follows what's shown in the input. IIRC aside from Chrome doing it, the rationale was that it would clearly let users know when they were on https pages. With all the work that has gone into Firefox's urlbar and site identity features since then, it would certainly make sense to revisit this UX. Unfortunately AFAIK it's not a priority right now, but it's a valid request.

Severity: -- → N/A
Status: UNCONFIRMED → NEW
Type: defect → enhancement
Ever confirmed: true
Priority: -- → P5
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.