For just http:// urls (not https or ftp, etc) we can remove the protocol. Additionally, just-domain urls can have their trailing slash dropped.
Created attachment 332035 [details] screenshot of v1 Example of http:// domain only uris, http:// uris, https://
Created attachment 332036 [details] [diff] [review] v1
Assignee: nobody → edilee
Status: NEW → ASSIGNED
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.
OMGChange! Really though, I think this makes it harder to scan the URLs because the domains aren't horizontally aligned.
what's the motivation here?
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...
(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.
Summary: Strip http:// from rich location bar urls → Strip http:// from URLs shown in location bar autocomplete
>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).
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)
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.
This bug is only about autocomplete, right?
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.
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.
Assignee: edilee → nobody
Component: Autocomplete → Location Bar and Autocomplete
Product: Toolkit → Firefox
QA Contact: autocomplete → location.bar
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).
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.
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?
Assignee: edilee → nobody
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 665580
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.
You need to log in before you can comment on or make changes to this bug.