448853 - Strip http:// from URLs shown in location bar autocomplete

Status: RESOLVED DUPLICATE of bug 665580

(Firefox :: Address Bar, defect)

Description

[Ed Lee :Mardak]

For just http:// urls (not https or ftp, etc) we can remove the protocol.

Additionally, just-domain urls can have their trailing slash dropped.

Comment 1

[Ed Lee :Mardak]

Attachment: screenshot of v1

Example of http:// domain only uris, http:// uris, https://

Comment 2

[Ed Lee :Mardak]

Attachment: v1

Comment 3

[Ryan S. Scheel [:havvy]]

Make sure there is a preference to show the HTTP protocol.  In fact, a preference for hiding any protocol name would be nice.

browser.urlbar.protocol-hide.PROTOCOL being boolean.  By default, only show one protocol:  http

There is already one about config entry that works this way:

network.protocol-handler.external.PROTOCOL

I personally have made the following two (chatzilla...) and are examples of how it works;

network.protocol-handler.external.irc
network.protocol-handler.external.ircs

With a pref like 
browser.urlbar.protocol-hide.PROTOCOL, an advanced user can go in there and turn off protocols he doesn't want to see.

Also, allow one value either "all" or "*" or "on" to turn off showing them for all protocols.

Comment 4

[Benjamin Smedberg]

OMGChange! Really though, I think this makes it harder to scan the URLs because the domains aren't horizontally aligned.

Comment 5

[(not currently active) Ted Mielczarek]

what's the motivation here?

Comment 6

[Mike Connor [:mconnor]]

Let's not do this piecemeal, either we should strip all schemes or we shouldn't bother.

The primary motivation is that scheme is largely meaningless to end users, and makes effective scanning of URLs harder to do without learning.  We don't have time to iterate and explore on this for 3.1, but we want to do this right in the future, with the end goal being that users can actually start to grok the components of the URLs...

Comment 7

[Ed Lee :Mardak]

(In reply to comment #5)
> what's the motivation here?
I'll let Alex answer that :) He suggested it to me at the summit, so I wrote a patch.

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

>what's the motivation here?

The fact that information is being transmitted using the Hypertext Transfer Protocol is irrelevant.  Putting http:// before every URL is about as silly as having a status bar that states that you are using TCP/IP, your hardware is designed for base 2 operations, and that this device is Turing complete.

I think we should adopt the same policy for the scheme that we are using for ports in the authority: only show it if it is different from the default.  Just as we don't include :80 on every URL, we shouldn't constantly display http:// (but we would continue to show https, ftp, etc.).

Surfacing arcane implementation details to the user is one of the most common ways interfaces suck, and displaying http in particular has become a textbook example of violating that usability heuristic.  (literally, I've actually been in user interface design courses where this has been the specific example used). 

Comment 9

[Shawn Wilsher :sdwilsh]

Why still show https then?  It's fairly common too (although not as common as http).  We also have two other indicators (one if you hide the statusbar) that a connection is *fully* over https which is arguably more important than if the toplevel page is.

Food for thought (I don't really care either way)

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

cc'ing johnath to see how he feels about removing https in favor of other indicators.  I think removing https would be more of a straightforward decision if we had set browser.identity.ssl_domain_display to 1.

Comment 11

[Jesse Ruderman]

This bug is only about autocomplete, right?

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug is, but mconnor's comment #6 makes it sound like we should make a decision for all instances of URLs in the app in a future release:

>Let's not do this piecemeal, either we should strip all schemes or we shouldn't
>bother.

Comment 13

[Justin Dolske [:Dolske]]

Perhaps mconnor can clarify -- are you really talking about all the URLs in the app? My assumption was that comment was only about the location bar autocomplete.

App-wide change sounds like the perfect vs the good, to me. Consistency is nice, but it's also fair for different levels of detail to be shown in different contexts. Certainly we've already crossed this line -- the download manager only shows domain (TLD) and filename.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 332036 [details] [diff] [review]
v1

Fine from a code-works POV, but I'm not sure we want to do this at all given the comments here, so no use keeping this in my queue (which I'm trying to clear out).

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

If we end up making significant changes to the location bar, we'll want to do it as part of a larger redesign that impacts a lot of things (identity, notification site preferences, etc.)  Let's go over all of that with iterations on mockups in dev.apps.firefox and then potentially return to this bug later as part of a potential group of changes.

Comment 17

[KLB]

Has anyone given any thought to the fact that with "http://" stripped off the url when an inexperienced user copies an address and then pastes it somewhere, like say on a forum post, the link will be broken because the protocol will be missing?  This is going to cause broken links all over the place on forums, blogs, websites, emails, etc. Are other browsers doing this or just Firefox? Do we really want to be different in this case?

Comment 19

[damian]

KLB, exactly why I had to search this issue, it has appeared only since the latest forced upgrade of FF...  

which also broke many addons of mine.

firefox has become the beast it always tried to avoid being... an awkward and obnoxious piece of software, like thunderbird.