Image of the glider from the Game of Life by John Conway
Skip to content

Chromium Removing http://

A recent build of Chromium removes "http://" from the Omnibar in the browser, and replaces it with a globe icon. As a result, typing "" will result in "" being displayed, rather than the full URI. There's been a lot of heat and discussion about this, and near and far as I can tell, people just plain don't like it. At least the vocal minority doesn't. From what I've pieced together, here are the reasons the developers have removed "http://" from the display:

  1. The browser uses HTTP as its default protocol. Any other protocol, such as HTTPS, FTP, etc is not default.
  2. It's already understood that HTTP is the default protocol of the browser by users.
  3. Displaying "http://' is redundant information, as the user is already aware of #2.
  4. If the user is not familiar with #2, then why does it need to be presented at all? Why clutter the interface or display "geek code" to the average user?
  5. Removing "http://" from the OmniBar removes the redundancy, while keeping the browser behavior and user interface entirely in tact.
  6. The browser will display other protocols that isn't default to the browser, such as "https://" and "ftp://".

Fact of the matter is, the Chromium developers aren't going to revert the change. I've read all the comments I can find on this matter, and here's an overall summary:

It's UGLY!
After seeing "http://" in every browser on the market since browsers have been used, as soon as it's removed, it seems there's a big gaping hole in the address bar. For some reason, it keeps their eyes floating back to the address bar, wondering what had happened and why it was changed, when it wasn't hurting anything to begin with. In other words, displaying "http://" is sexy, and removing it is not. Either that, or they feel that there's a big void in their life with it missing.

It breaks other applications with copy and paste
By removing "http://" from the Omnibar, when copying a URL to the clipboard, and pasting it into other applications, these applications may or may not be able to recognize the URI, and as a result, not make it "clickable". However, there have been no use cases submitted of such breakage. No one has come forth saying "Application X won't linkify a URL pasted without http:// in front". Plenty of speculation about it, however. Plenty. But, what appears to be the problem, isn't Chromium, but either your operating system, or the application you're pasting your URL to. You see, Chromium will present a web object to the operating systems clipboard. If the operating system is worth its weight in gold, it will preserve the web object, and present the object to the pasting application.

So, at this point, it's up to the application how it wants to handle it. Every email and IM client that I can test, including office document creators, treat the web object as it should, and linkifies the paste, even though "http://" isn't part of the paste. If an application exists that doesn't linkify the paste, it should be brought to that developer's attention. After all, it's the problem of their application, not Chromium. Think about it. Do you type "" when chatting with your buddy, or just "". So, not only should the client recognize clipboard web objects, but it should also recognize partial URI schemes.

It doesn't adhere to specification
This is semi-valid. At least people are concerned about Chromium adhering to spec. The specification is the URI scheme includes a scheme name, such as "http", "ftp", "smb", etc, as well as an authority, path, query and fragment. So, by not displaying the scheme name in the Omnibar, Chromium is not adhering to specification. The problem with this argument, however, is that the specification is really only dealing with applications referencing a URI, through another program, source code, etc. What is displayed visually to the user shouldn't matter if it's "breaking spec" or not. I tell you right now, your mom isn't going to care if her URI is valid specification.

Frankly put, I've been all over the mailing list and on the bug report trying to explain to people soundly and logically why the move was made, and why the Chromium developers aren't going to revert the change. As I outlined above, no one, other that developers and Internet geeks, are going to notice, if they haven't caught wind already. If the change is indeed breaking applications, then the developers need to know what is breaking and how. What they don't want is a bunch of whining, moaning and threats that you're going back to Firefox. That doesn't help. If copying and pasting is broken in other applications, let them know what application is broken, and how it broke. You know, bug reports. Actual, solid, bug reports.

Currently, there is a regression. When removing "http://" from the Omnibox, copying the URL didn't include "http://" in the clipboard web object. So, a paste wouldn't show it either. So, they added "http://" to the clipboard on copy. However, something else broke this behavior, and as it sits, a copy and paste will not give "http://" in the pasted result. However, this has been marked as release critical, so the next stable push likely won't go out until this is fixed.

Personally, I welcome the change. Knowing the default protocol of your software may or may not be important, but I don't think the software really needs to communicate that to you. Think of your email client. It communicates over SMTP, IMAP and POP3, sometimes simultaneously. Yet, you don't think twice about it, and it certainly doesn't tell you "Okay, now I'm using the SMTP protocol to send your message.". IRC clients don't tell you they're using "irc://". Chat clients don't tell you their protocol, whatever it may be. FTP clients, SSH clients, Samba clients. On, and on, and on. The browser is the only exception to this rule. Why? Why does the browser need to tell you that it's using HTTP when it's already generally understood? Isn't the important thing interacting with the sites you want to visit? Not the protocol? Frankly, I say good riddance!

Now, if only we can get system administrators to register "domain.tld" as well as "www.domail.tld". I would like to go to without forcing me to type the www.

{ 22 } Comments

  1. ScottK | April 18, 2010 at 9:14 pm | Permalink

    Coincidentally, I just tried chromium for the first time today and liked it. It wasn't a version that had this "improvement". I really dislike this arrogant tossing away of years of common user interface for trivial reasons. I guess it's a good thing I'm not used to chromium yet.

  2. Kurt Kraut | April 18, 2010 at 10:00 pm | Permalink

    "It breaks other applications with copy and paste"

    Well, I did the following test:

    1) Copied (without the http:// at the begining)
    2) Pasted it into a Pidgin conversation

    And voilá! It wasn't rendered/recognized as a link. I think it will be pretty hard for applications like e-mail clients and IM clients to be able recognize an URL without the http:// or www at the begining even with new source code implementations.

  3. Brandon Jones | April 18, 2010 at 10:28 pm | Permalink

    I find it funny how someone is able to oh i don't know accept something that is different and actually mention reasons why the change was made. This is generally how it is supposed to go. I wonder why something like this was not done when ubuntu lucid's default window button position was changed. Hmm...

  4. simc | April 18, 2010 at 10:43 pm | Permalink

    This is just stupid, and too much hassle, bringing new bugs and inconsistency (i see and select/copy one thing, and paste another) with _no_ real benefits at all.

  5. Michael | April 19, 2010 at 12:00 am | Permalink

    If anyone wants to complain about the removal of this then they should also request that the port number is displayed and index.html.

    We would see instead of

  6. Neriman | April 19, 2010 at 12:21 am | Permalink

    Very clever, very smart decision. It should be done ten years ago!

  7. David | April 19, 2010 at 12:33 am | Permalink

    I think people’s eyes naturally gravitate towards the protocol-less location bar due to the location bar’s modality. It has too modes: an editing mode for choosing the next URL to go to, and a status mode for displaying the current mode. These two modes are generally not well-differentiated by browsers, so we rely on certain clues to tell us what that mode is. One of those clues is the display of the protocol, which is more likely to be displayed by the browser than input by the user. Thus, due to this learned behaviour, when people now see the current URL, they get confused, though they may not immediately realize why. It just looks like someone has input something in the location bar, and you feel like you need to reset it, even if you know that you don’t.

  8. Simon | April 19, 2010 at 12:51 am | Permalink

    I welcome this change as well. Many times I see inexperienced people typing web address before http:// or deleting one slash and then become confused when their web page doesn't open. It was silly to display this in the first place I think.

  9. Mez | April 19, 2010 at 1:15 am | Permalink

    Now try copying the URL to use with something like wget, or to use in HTML for another page... Accidentally forget that you need to manually add it in.

    Oh, damn, it broke my download/website.

  10. antistress | April 19, 2010 at 2:01 am | Permalink

    This articles has convinced me

  11. Kenneth Christiansen | April 19, 2010 at 3:53 am | Permalink

    You can internally store the http:// so that copying will actually copy http:// as well, thus solving the problems with copy and paste. A similar technique has been used by IMs, who might replace ":-)" with an image, but still make the copy contain the ":-)".

  12. Huygens | April 19, 2010 at 4:54 am | Permalink

    @Mez and others here:
    If you are geek enough to use wget or develop web sites, then you are clever enough to add the http://

    I also welcome the change. The http/https/ftp/etc. are internal specification that are not necessary for the humans. Those are necessary for interface between application layers and different applications.
    Therefore, this change will break a few apps, but those few apps were probably in need of a better UI in the first place.

  13. Aaron | April 19, 2010 at 5:30 am | Permalink

    @Mez As mentioned, that's a regression. A future build will add the "http://" to the clipboard web object for pasting. This wget, shouldn't break. As it sits, I have Google Chrome 5.0.375.9 dev, and this behavior works.

  14. Daviey | April 19, 2010 at 5:52 am | Permalink

    Copy (both types) and paste worked exactly as it should, perpending http://.. So there is no issue. :/

  15. Marco Trevisan | April 19, 2010 at 8:54 am | Permalink

    I can confirm... Copying prepends the http://, I like this.

  16. mathew | April 29, 2010 at 5:20 pm | Permalink

    Exactly the same arguments apply to https://

    I opened a bug, but it got closed as WONTFIX.

    The average user doesn't care about the path either, let alone the query string or fragment identifier. The omnibar should just show "", "" etc. Then you can either make the entire URL show up when the cursor enters the omnibar, or have a preference somewhere to make it show the whole URL always, and everyone will be happy.

    (Also, your OpenID authentication failed with "No matching endpoint", whatever that means.)

  17. Aaron | April 29, 2010 at 9:12 pm | Permalink

    No, it's not the same as https://. HTTPS is not the default protocol of the browser. HTTP is.

  18. tokland | May 29, 2010 at 7:18 am | Permalink

    @Daviey and others. As you probably know, GNU/Linux has more than one selection. The normal clipboard works fine, but the primary selection (the one you just select text with your mouse) is not processed by the application, so after this change you get a wrong link.

    Objectively this "feature" breaks a very usual copy/pasting method for GNU/Linux users. If Chromium developers care or care not, it's another matter. According to the opened issues report, they don't.

  19. Andy Waddington | June 21, 2010 at 6:44 am | Permalink

    It should be a user-choosable option, like choosing to use the window manager's title bar, or having middle-click open a new window not a new tab.

    Copy-and-paste by highlight then middle-click is important. We do it without actually looking to see what is inserted, because we expect it to work - it always has.

    And the suggestion that the "www." is equally redundant is laughable. http://www.mydomain... is a fast webserver hosted by my ISP, whilst mydomain is my own server on the end of my ADSL line (with 2 Tb of storage, but a slow pipe to the net). They are different machines at different addresses - that's not uncommon.

  20. Andy Waddington | June 21, 2010 at 6:46 am | Permalink

    and oh look, this site does the opposite - because I typed an address starting with www, it has inserted an http:// and made it a link (to a completely false domain name, as I saw no need to use the real one). Why can't software respect the idea that people type what they want and if it's wrong they can correct it themselves ?

  21. Aaron | June 21, 2010 at 8:27 am | Permalink

    Yeah, that's WordPress for you. 🙂

  22. Gerald Scheuerman | September 22, 2010 at 10:03 am | Permalink

    I don't agree that showing the protocol is 'ugly'. I think the solution is to have a switch to allow developers who have to use browsers as tools of their trade versus 'neophytes' that don't know the difference between a search engine and a browser.

Post a Comment

Your email is never published nor shared.