missing http in the bar is a "feature".
But when you copy paste a link and no http:// appears its a bug!

Copy-and-pasting the URL should include the scheme in the pasted result.  If it 
doesn't, please file that as a bug.  The core change here, to remove the scheme, is not 
going to be reverted.

Issue 41468 has been merged into this issue.

Issue 41478 has been merged into this issue.

+1 on people not liking this change.

Issue 41350 has been merged into this issue.

Issue 41303 has been merged into this issue.

Issue 41317 has been merged into this issue.

Issue 41318 has been merged into this issue.

Issue 41146 has been merged into this issue.

Issue 41139 has been merged into this issue.

Issue 41483 has been merged into this issue.

This is a bad change and should be reverted.  This is Google using market share to
force a change that doesn't comply with relevant standards.  

As another poster pointed out on another bug "Many blogs, message boards, email
viewing software, instant messaging software, etc. depend on matching against http://
to auto-link URLs. Removing http:// will train end-users to omit it, which will have
a negative impact on usability all over the web."

Also, Peter Kasting needs be removed from the decision making process, as he seems to
have no interest in resolving this.  A large amount of relevant user feedback has
been disregarded today by Peter, and I'm hoping that someone else will realize that
users are not being well-served, and let someone in the company know about it.   

mhaisley is right.

A few examples from Google products; the Google Talk desktop client does not auto-link url fragments without 
http:// on the front. Also, take a look at the Google Wave bug reports where it doesn't handle URLs without 
http:// here: www.google.com/support/forum/p/wave/thread?tid=73e25fdd3be08c28&hl=en (yes, I omitted http:// 
to show that it doesn't work here, either.)

We probably all agree that "http://" is an unfortunately nasty part of URLs, right up there with "www", 
".com" and all the other pesky line noise. Even Tim Berners-Lee apologized for the "//". However, I don't 
think the address bar is the right place to address this issue.

Please revert this change.

Maybe someone could make an extension to revert the change.

Issue 41534 has been merged into this issue.

As noted elsewhere, we include "http://" when copying the URL to the clipboard, so it 
will still appear when pasted elsewhere.  There are a couple of bugs open to improve 
aspects of this, such as making sure it appears in the rich-text copied object as well 
as the plain text (bug 41173, bug 41489, bug 41490), and making sure it appears for 
partial-URL copies like ones that just copy out the hostname (bug 41493).

As for training users to omit "http://", you're about 15 years too late -- users who are 
typing URLs by hand rather than pasting them almost invariably omit the scheme.  The web 
can and does work fine today with this.

If you have examples of feedback I (or any other team members) have disregarded, feel 
free to share it.  All the comments on all linked bugs have indeed been read.  However, 
Chromium UI design is not a democracy and is not based on users' votes, so "I don't like 
this" carries very little weight.  Concrete use cases that are actually broken are much 
more valuable -- and have already caused us to file the bugs noted above.  The fact that 
we haven't elected to revert this change doesn't mean your feedback has been 
"disregarded", it means we're not convinced a revert is justified-- especially when it 
has been in the product for a couple of days.

I has been in the *dev* release of the product for a couple of days, and there have already been very many 
tickets about this, which you can see merged in to this one.

Sometimes users copy and paste or type fragments. Supporting this (which browsers do) and encouraging this are 
two different things. Since Chrome goes to "http://www.google.com/" when you type "google", why not omit the 
"www." and ".com/" as well, and show them if they differ (similar to how you show "https://"). Obviously, this 
would lead to quite a bit of confusion.

The Chromium UI design is not a democracy, but browser market share is. We're telling you we do not like this, 
do not want to use a browser which does this, and would not recommend that our friends and colleagues use a 
browser which does this. The user base is rarely so opinionated, so maybe you should re-think this feature.

Here's my attempt to synthesize why people are reacting negatively, presented (IMO) in order of how 
convincing the arguments are:

1. If it ain't broke, don't fix it. What problem does selectively ditching the protocol solve? And 
is this the best solution?

2. Apple has already implemented this feature in mobile Safari, and implemented it thus: 
http://daringfireball.net/2008/11/treating_url_protocol_schemes_as_cruft - Apple puts a TON of 
thought into their UI (certainly more than 2-3 days) and probably came around to this space-saving 
design for very good reasons. Why try to design your own UI conventions when you can just copy 
someone else's work?

3. If you hide the protocol for insecure pages, but display the protocol on secure pages, this 
actually makes secured pages seem "scarier". The lack of consistency between how SSL and non-SSL 
pages are displayed could actually be a disservice to secure sites.

4. Preemptive counter-argument to "users are too stupid": if you think users are confused by 
'http://', then you should ALSO hide the query string, which is certainly more confusing to the 
average user. Millions (billions?) of people know http://, even if they don't know what it means, 
and it's certainly one of the least scary parts of a modern, complex URL.

5. By hiding 'http://', you're creating additional headaches for yourself as developers. Already you 
have 4 solid implementation bugs (X-Copy in Linux, the lack of http:// in rich text, inability to 
copy the first part of a URL, problems with dragging URLs). There will likely be more bugs that 
fallout from this change. 


--
Aside: Of course Chromium is not a democracy. Nobody expects it to be. But there is an expectation  
that if someone takes the time to file a bug report, and the bug report is well-formed and polite, 
then the ticket will be responded to. There is also an expectation that discourse be civil, and 
YELLING kept to a minimum. 

Chrome doesn't go to http://www.google.com when you type google, unless you have 
previously typed that address and are being inline autocompleted to it.

Omitting pieces of a URL that add no clarity and cannot change the destination of the 
URL is quite different than adding pieces that can -- "google" is a hostname of an 
intranet machine.

You are correct that market share is effectively a democracy.  As is true for all 
changes we make, you should use whatever browser best matches your needs and desires.  
Having been a part of the Chrome project for its entire existence, I don't happen to 
agree with your point of view that this is a change which will drive away users in 
droves, but I could be wrong.  However, right now, the view that this is a good 
change is one that I'm expressing on behalf of the entire Chrome UI design team and 
management chain, so reversing that decision is only likely if we've all missed some 
crucial cases.

I'm fine with the product change, but this doesn't work with X11 clipboard. I don't 
really know the X11 API for interacting with the clipboard, but is there a way you can 
make the protocol get into the buffer?

For instance, if I triple-click the address bar, and then middle click elsewhere, I'd 
expect to get a full URL including the scheme.

@23: That's bug 41173, which has been fixed on trunk and should be in the next Dev 
release.

This change seems more than a bit odd to me as well. It could be that it's my 16+ years of habit speaking here, 
but somehow training people to drop the http:// feels wrong.

More than that, though, it feels wrong that this change appeared in the product without being discussed on any 
of the mailing lists or without a design spec being circulated (at least not one that I saw). I personally don't 
believe that UIs are best progressed by democratic vote, but perhaps those that were involved in this decision 
should share their ideas with the rest of us, especially if this is all part of a grander design plan. Apologies if that 
did happen and I didn't see it.

I should have added that I feel similarly about the "globe" icon that now appears to the left of the URL (having 
moved the bookmark icon to the right). I find myself rather often clicking on the globe out of habit to bookmark 
things, and getting a (more or less useless) dialog appearing that I then have to close.

Please don't break conformance to RFC 3986 in correctly presenting URI syntax. The fact 
that it only affects the HTTP URI is irrelevant regarding arguments in favor of the 
change.

In addition, this breaks the standard clipboard functionality, which just doesn't 
seem right.   Users expect that when they highlight X, and press copy, they get X, 
instead chrome is going to present Y.   There are use cases where this may cause 
unexpected results.  For example when a user copies www.google.com and pastes it into 
say ping.  

Obviously most users will understand what happened, and be able to correct it, but 
not always.  For google.com this isn't a strong use case, however it gets a lot 
stronger for an internationalized domain name, such as пустыня.com or ƹӂʒ.tk which 
would be near-impossible for an average user to type. 

+1 to such change doesn't actually solve anything but only creates unnecessary problems & complexities.

@29: I appreciate that you're trying to provide actual use cases.  However, I don't think I fully understand 
the arguments you're making.

First, you say, "In addition, this breaks the standard clipboard functionality, which just doesn't seem 
right."  But there is no such thing as "standard clipboard functionality".  On all OSes, the clipboard can 
hold a large variety of different object types simultaneously, and programs place whatever they think is 
most reasonable on the clipboard.  If you copy a hyperlink, for example, the Windows clipboard probably 
contains a URL object (which you didn't actually see while copying), and both plain and rich text, either of 
which might contain the URL itself, or the link text.  If it's the URL, you further have the decision of 
what encoding to use, whether to use punycode or Unicode for IDNs, etc.  Even before this change, Chrome has 
long had a set of heuristics for deciding how to populate the clipboard in various cases.  (See more detail 
on this at http://neugierig.org/software/chromium/notes/2010/04/url-copying.html .)  So, in reality, there's 
no obvious "right way" that we used to be doing and now aren't.

Second, as to the particulars of the cases you present.  You cite a user copying www.google.com and pasting 
it into ping.  It's not clear to me whether you're complaining that the user expects no scheme and gets one, 
or expects one and doesn't get some, but for me the fact that ping works either way suggests this isn't a 
strong case, because it can't be broken by this change.  You also mention typing IDNs, but again, I'm not 
sure what exactly is breaking; if пустыня.com has or does not have a scheme in front, and the user wanted 
the opposite, what needs typing or deleting is "http://", not the characters of the hostname.

I also find it telling that you say that "most users will understand what happened" when in fact the 
opposite is true.  Easily 95%+ of our users wouldn't even _notice_ the difference between a URL with a 
scheme and one without, let alone have any idea what the difference meant.  Our goal is to make everything 
work right in every case, which in this case means adding some clever heuristics to copy and pasting.  This 
probably strikes you as dangerous and risky, but I suspect you don't think twice about using the Omnibox in 
general, which has an enormous set of very complex heuristics to decide how to handle everything you type 
"correctly" without you noticing, or our tabstrip, which similarly has a lot of very complex algorithmic 
work under the hood.  We're not afraid of tackling difficult UI and trying to make it seamless; it's what 
we've been doing for the whole of Chrome's history.

It's legitimate to worry about this change, or to simply dislike it on using it.  But the feedback that's 
really useful to us comes in other forms:

* Concretely, I actually tried to do X and it is currently broken in this way.  (Again, see the bugs noted 
in comment 19 for examples of this.)  This is extremely valuable.  In theory, if we encountered lots of 
these cases, we would probably consider reverting this change.  Note that "I bet X won't work well anymore" 
is not the same thing as actually testing it (we've had many bugs filed where people assumed we'd never copy 
out a scheme anymore without ever bothering to try it).

* I have used this daily for several weeks now and I have the following detailed impressions.  This, of 
course, isn't currently possible as the change only shipped a few days ago.

* My non-computer-literate friend, who uses Chrome every day, encountered this without anyone pointing it 
out in any way, and he reacted this way.  It's easy for us on the team to design things we think experts can 
get used to, because we're all experts ourselves.  Getting non-expert reactions is always more interesting, 
but it's nearly impossible to do in an unbiased way.

HTH.

I note that SSL URLs (https://) are displayed in full but not those starting "http://" - this 
seems inconsistent and confusing.

It's true that the full URL appears in the clipboard, but copy/paste is broken for those of us 
who copy by selecting the URL bar and paste with mouse-middle-click.  It's a poor 
decision and I agree with those who want to see it reverted.

Again, you're breaking conformance with IETF RFC 3986 for the display of URIs. While 
you're not breaking conformance with the actual query, you ARE incorrectly displaying 
the request syntax outlined specifically in IETF RFC 2616. It doesn't say "Globe 
icon", it says "http:" "//" specifically. 

I like my address bar to accurately refer to the URI I'm looking at. Copy and paste 
isn't the issue here. It's deliberate tampering of display of a URI visual function 
for aesthetics. And again, it's arguably non-HTTP 1.1 conformant (RFC 2616). Change 
it back.

Sorry, but when copy selected url in address bar with hotkey i.e. Ctrl-Ins there is no 
http:// in clipboard! 
When i need to copy a part of url i.e. left part of it there is no http:// in 
clipboard!

It is extremely problematic.

Another bug with this change: http://code.google.com/p/chromium/issues/detail?id=41585

I also consider this to be a very negative feature. I don't like the appearance of a 
URL without its schema. On a more practical note, I frequently copy only part of 
URLs, omitting the trailing part. For instance, right now, the address bar says:

  [Useless Icon] code.google.com/p/chromium/issues/detail?id=41467#makechanges

If I copy the whole thing, I get "http://" at the start, but if I wanted to show a 
friend this issue, I would copy everything up to the beginning of the fragment, 
omitting it because it obviously should not be there when directing someone to the 
page as a whole. When I copy this subset of the URI, "http://" is not prefaced.

If you must include this deleterious change and refuse to add an option "under the 
hood" with which to turn it off, please at least alter it to show the entire URL when 
the address bar has focus, so that it is my decision whether "http://" is included 
and not some heuristic within the browser code.

I'm having trouble imagining what _any_ user gains from this. On a platform with 
limited screen space (mobile) it makes sense, as pointed out by portman.wills, but I'm 
using a PC.

So I'd love to know what rationale went into this change.

Also, personally, I don't like it; the url looks naked.

I've been using the dev build on Mac with this feature for a few days, and I hate that copying a URL from the 
address bar and pasting it into an Entourage 2008 for Mac email now pastes a string with this format:

no-protocol <with-protocol>

ex. code.google.com/p/chromium/issues/detail?id=41467 
<http://code.google.com/p/chromium/issues/detail?id=41467> 

I'm sure its partially the fault of the destination app for not selecting the 'right' clipboard object, but I'm also 
sure its not the only Mac app that will do this.

The sensei at my dojo is not highly-computer literate, but he knows enough to get by. 
He knows that the URL needs to start with "http://", and if it isn't there he always 
carefully types it. When going to a new page, he carefully selects, with the mouse, 
the part of the URL after "http://" and deletes it before entering the new URL. With 
this change, he will be continuously typing in "http://" by hand and cursing "the 
computer" for removing it.

He is far from unusual. I'm certain this scenario will play out with many of the 
people who use Chrome casually.

If screen space is severely restricted, removing anything unnecessary can definitely 
be an improvement, but my monitor is nearly 2,000 pixels wide. Any URL for which 
removing "http://" is going to make a difference is so long I'm not going to be 
reading the whole thing anyway. In a similar note, the new location for the star 
button for bookmarking the current URL is so far removed from the URL as to no longer 
be visually cued to it. As I type this, there are some 1,250 pixels of white space 
separating the end of the URL and the star button.

This is a shockingly poor decision which shows a complete disregard for how people 
share URIs.

The protocol specification is vital to correctly specifying a URI; without it, the 
URI loses its meaning. If Chrome only supported a *single protocol* I could 
*possibly* understand this decision, but that's not the case. If the protocol 
specification was represented by an icon when the bar was not active and by text when 
it was in focus, I could maybe, kind of condone that, but that's also not the case.

This is just plain bad design.

@portman.wills

2. Apple has already implemented this feature in mobile Safari

Yes, Safari does hide http:// until you actually click the URL bar, then http:// is
shown. This is presumably done to save space because of the small device size. But
they got it right by showing the full URL when you tap the URL bar. I don't see any
reason to hide the http:// from the user on a desktop browser. None of the other
browsers do this.

	IMG_0002.PNG 68.1 KB View Download

	IMG_0001.PNG 33.9 KB View Download

Point 2 in comment 21 caught my eye, which to me only seems to have happened because
of the way Copy/Paste interactions are performed on their mobile devices.  But then
I'm wholly unaware for the motivation for the change in the first place.

@42: I'm pretty sure we're saying the same thing. Just to avoid any confusion, let me 
summarize.

First preference: Don't hide the http://, ever.

Fallback preference: If you're going to hide the http://, then the http:// should be 
displayed when the user clicks into the omnibox.

@44:

Agreed. I don't think even an "under the hood" menu option helps much here either, 
since many users would never find it. All users should be able to see the actual URI, 
not just those who are aware of how to re-enable its visibility.

The protocol specification is not optional. It's a part of the URI. A URL bar that 
doesn't show the actual URI is not very good at what it does.

Issue 41618 has been merged into this issue.

@32: As stated multiple times, that's bug 41173, which is fixed.
@34: That's bug 41369.
@36: That's bug 41609.
@38: I believe bug 41490 will fix that.

I think the real issue is that this change was not mentioned in release notes - and no 
justification for it was made. While the latter part is not that important - mentioning 
it in release notes would have saved a lot of duplicate bug reports about an intended 
change.

I keep seeing replies to other technical issues regarding this, yet I've stated twice 
in specific terms how the change possibly breaks conformance to IETF standards. One 
of those standards being the HTTP 1.1 protocol itself.

Alternatively, as others have stated, instead of using heuristics to try to fix the 
issue of copying the non-conformant URI (and never truly fixing the issue), why not 
just have the URI be displayed correctly when the Omnibox is focused or even on 
mouseover? I still don't appreciate the URI displayed in the Omnibox having been 
modified to be visually inconsistent with the correct URI. It is counter-productive 
to not show the URI Scheme. I am not looking for a globe icon, I am looking for text 
as outlined in IETF RFC 3986. As someone else stated; the scheme component of a URI 
is NOT optional.

@kjonesinmo : the RFCs for defining the syntax of URIs say nothing about when or how user agents are required 
to display URIs, and it would be inappropriate for them to do so. Various protocol specs will tell you when you 
use a URI, if it is required to be in a particular syntax or not. You can be sure that we use the full URI when it is 
needed in a protocol (or, at least, it would be a pretty severe bug if we didn't).

@49: I think you are too optimistic. :-) I doubt many of the users who posted a bug 
report actually checked release notes. The fact that nothing was there was not an 
influence in their decision to post a bug report.

Issue 41660 has been merged into this issue.

@51. I understand, but not displaying the actual URI of what is being viewed is 
hypocritical for something that is designed to correctly follow standards. 
Functionality (I consider visual aspects like correct URI display to be functionality) 
is being sacrificed for aesthetics as far as I am concerned; and seemingly useless 
aesthetics at that.

Can anyone answer question asked @37?

@55: 7 more characters of the URL being displayed? :)

@54: As I have stated earlier, I'm not a fan of this change either, and I am perhaps inclined to agree with you that 
it's a tradeoff of functionality (and perhaps security) for aesthetics. My only point was that this change does not 
make the browser non-compliant with any standard I am aware of.

@56: Do you even get 7 more characters? The "globe" icon seems to take up just as much 
space as the protocol specification, so I don't think there's any functional benefit 
to losing it.

As far as I can tell, the rationale must be "Globes look pretty, http:// looks ugly," 
in which case they may as well develop icons to replace the other "ugly" parts of the 
URI. Perhaps a smiley face instead of a /, or a puzzled looking guy instead of a ?

@57: It's important to separate the introduction of the globe from the removal of the 
"http://", so yes, you do get 7 more characters. However, as I pointed out previously, 
with typical screen resolutions today, if a URL is so long that you *need* those 7 
characters, it's so long that you're not going to read it anyway.

Another problem with copying of the URL: if I open a new tab, start typing, select an url from history, select all, 
copy - this resut in a schemeless URL in the clipboard.

To whoever introduced this change: can we please get the old behavior back? I'm not violently opposed to lack 
of scheme, but looks like this feature is simply not finished, given the number of corner cases. I'd be far more 
happier with something more complete. And I'd still like to listen to rationale behind this change (I don't see 
any).

Thanks,

KT.

Can we at least have an option to hide/unhide the protocol? 

Perhaps someone could write an extension that undoes the hiding of protocol in the 
omnibox, so that those that want it hidden can, etc.

@59: Bug 41609.

Perhaps it bears repeating that generally, features going into the Dev channel take 
many releases to actually finish.  It's not surprising that something that's been in 
the trunk for a few days does not have all the resulting effects nailed down.  If this 
isn't the kind of thing you can handle, the Beta or Stable channels may be a better 
choice.

@61: fair enough. It's unfortunate, as the Mac dev version is really the only sane choice, but that doesn't matter 
that much in context of this bug.

How about that motivation behind this change?

re comment #19:

I assume that a lot of the frustration (at least as far as I'm concerned) comes from the fact, that this change "came out 
of the blue". There was *NO* discussion prior to implement this bug on a medium designed for this (ie. forum/mailing list). 
Why is there a chromium-discuss list, if discussion doesn't take place there? I also find it very much appaling when you 
say that users vote don't count. That's so very wrong. If it's not votes that count, what else does count? Votes are the 
best way for a user to express interest in an issue. Of course it's no democracy, but shouldn't the browser made in such a 
way, that users like it?

Reg. the feedback you want to hear:

* I have used this daily for several weeks now and I have the following detailed impressions.  This, of 
course, isn't currently possible as the change only shipped a few days ago.

-> I used it daily since it came out and absolutely hate it. It makes harder to deal with the address, it makes it harder 
to directly see on which kind of server you are, it's different to any other normal (ie. barring things like Mobile Safari) 
browser and looks plain ugly. It also breaks the URI syntax. I also "worry" about the useless complexity which now must be 
there. That all feels so extremely wrong. Why fix something, which was in no way whatsoever broken? And if you think that 
"users" (which users?) are scared by what they see in the address box - be bold, and remove it alltogether! I *DO* think 
that this would be good! For normal surfing, it's just not needed. So do away with it and add buttons/keycombos which bring 
up a dialog box for entering the URL and/or search term (kinda like the ctrl+l dialog of Internet Explorer).

For making it better - I'd think using a "color scheme" (see attached image) would work MUCH better. The protocol would be 
displayed all the time (it could even be dimmer then in the image) and user gets focussed on the server name (because it's 
in dark black). Going such a route, no corner cases would exist, because the address would still be shown completely. But 
in a more structured and thus better way.

	bildschirmfoto20100415ux.png 11.4 KB View Download

@31:

"Our goal is to make everything work right in every case, which in this case means 
adding some clever heuristics to copy and pasting.  This probably strikes you as 
dangerous and risky, but I suspect you don't think twice about using the Omnibox in 
general, which has an enormous set of very complex heuristics to decide how to handle 
everything you type "correctly" without you noticing"

That's soo wrong....

Firefox 3.5 also has some sort of "Omnibox" built into it (of course not nearly as 
good as the Omnibox in Chrome). You can type a query into the addressbar, and it 
takes you to Google (or whatever - btw: firefox allows you to easily specify which 
Google to use; something which is completely broken-by-design in Chrome as well...). 
Anyway... Firefox also has a "search box". When I see my "non-computer-expert" wife 
use Firefox, she either goes to type in http://www.google.de/ (INCLUDING the 
http://!) or, at best, uses the search box. And I have told her, that she can type in 
queries directly in the address box. When she's using ("my") Chrome browser, she 
always goes to http://www.google.de/ first (I told here that she can type stuff in 
the "Omnibox").

What does that prove? It proves, that a (however sized) number of users don't even 
use your "good" heuristics. No need to add more to it!

And as far as displaying the http:// goes - normal users certainly don't know what 
http:// means. I agree. But why hide it? It's not like that scares people, or is it 
(do you have prove for saying that it scares people?). OTOH, the people that DO CARE 
about what's shown in the address box seem to be very much opposed to the change at 
hand.

So we've got the "normal" users, who couldn't care less if http:// is displayed or 
not and those, who do care. If http:// is displayed, the 2nd group of people is 
pleased, but the 1st group isn't affected negatively. But if http:// is removed, the 
2nd group is very much pissed off (as can be seen by all the bug reports) and the 1st 
group still doesn't care. This shows, that NOBODY is served well if http:// is 
removed, but some people are served well, if http:// is shown.

Conclusion: If it's really true that "Our goal is to make everything work right in 
every case" is the case, then http:// ought to be shown.

@48 in reply to @32:  bug 41173  is not fixed.  Paste by selecting "Paste" from a menu 
pastes the http:// but paste using middle-mouse-click does not.

I don't feel that directing users to multiple bug reports or suggesting that they 
don't use dev is addressing this issue.  Maybe this is the wrong forum, but people are 
just reacting to a real problem in usability.

I still have no experience with this "feature"(using the beta, and now not even thinking of going to 
dev) but it looks kind of stupid to me, it's like:
-"Here is a picture of a car"
-"Where are the wheels?"
-"Oh don't worry, we'v just hidden them"
-"Well, is it a car if it doesn't have wheels?"
-"It has wheels, there just hidden on the picture!"
-"Well, than it isn't a picture of a car!"

now replace car with url and wheels with scheme, and you know what i mean.
An url without protocol is as useless as a car without wheels.
and the url should be displayed "as is" without any modifications (except for color styling it for readability, as pointed to in 65.)

i think it's time for people like pkasting to be a little bit flexible an that we come to a 
compromise (if needed in Belgian style :) )

and btw. if you already know that "Easily 95%+ of our users wouldn't even _notice_ the difference 
between a URL with a scheme and one without"(31) you also might notice that those 5% others are the 
ones here saying that they do notice and that they want the scheme back!!

But that's exactly where Google's great failures and problems lie.  Google has no 
desire to spend any time or effort or resources handling the 5% cases; Google simply 
chooses to ignore and not care about those cases.

They are just (wrongly) satisfied with dealing with the 95% case.

krtulmay,

well, to please the 5% cases, in this case, "Google" (or the chromium folks) didn't 
need to do anything at all. Actually, they shouldn't have spend the time and effort, 
because "95% don't notice the change in the first place".

@68 Wheels on a car? Seriously? How do you think that analogy is even equivalent. 
Wheels on the car propel the car. Removing wheels, clearly causes the car to no longer 
propel itself down the road. Removing 'http://' from a display removes redundant 
information, while the browser continues to function.

If you want to use a car picture analogy, you need a statement saying "this car uses 
unleaded gasoline". Tell me, is that information necessary? The user already assumes 
that the car is propelled by unleaded gasoline. If the car is propelled by natural gas 
or biofuel, then it should be communicated to the user, but if not, the user should 
correctly assume the car uses unleaded gasoline. So why communicate that in the 
picture? THAT is a more accurate analogy.

A lot of GUI choices on Chrome are good. But here it is just not clear what the reason for the change is. There is a 
lot of real estate on a desktop. On a small device, this would be understandable. There are big differences 
between irc:// http:// ftp:// ftps:// and so on. It is not a bad thing that people be exposed to them. URLs is a 
core internet technology. No need to dumb the user down. Allow him/her to grow into the web.

I don't like this change either. A problem could be when a user copies the address bar 
and suddenly a http:// is added. This will seem suspicious to quite a few users, so 
they might remove it when pasting it! This will then break many parsers.

I also don't like the inconsistency between http:// and https:// - either display both 
as icons or both as text.

PS. I hope Googlers are prepared for more resistance when this hits beta and stable :)

@65:

I think you're onto something; is it really conceivable that people are scared of the scheme, but they're not scared of query 
strings and other URI ugliness? As far as an average user is concerned, they'll never need to process anything beyond the domain 
name (and POSSIBLY one node's depth) mentally. Anything beyond that will almost never be parsed as useful information, and the full 
URI will only ever live as a complete string that's shifted around electronically (via copy/paste and/or a sent/received document). 
In fact, I imagine the protocol is more likely to be relevant to an average user than anything after the domain name would be.

The current solution is a half measure that doesn't actually solve anybody's problems. If you want to represent a "human readable 
web address descriptor," I think that the proper solution isn't to obfuscate the URI and replace parts of it with icons, but to 
remove the display of the URI completely. Show the domain name and document title (representing the protocol iconically), but still 
provide an easy way to copy AND view the complete URI (protocol specification included).

I'd still rather just have the whole URI displayed, but if you MUST hide it, I'd rather that you REALLY hide it but also make it 
REALLY easy to see completely. This would unambiguously show that you're presenting the user with a human-readable "web address 
descriptor" rather than an actual URI. The current solution conflates the two notions by presenting a partially obfuscated URI, 
which looks *mostly* like a valid URI, but isn't quite.

On Thursday 15 April 2010 00:19:13 you wrote:
> 
> Comment #19 on issue 41467 by pkasting@chromium.org: URL bar no longer  
> shows http://
> http://code.google.com/p/chromium/issues/detail?id=41467
> 
> If you have examples of feedback I (or any other team members) have  
> disregarded, feel free to share it. 

open this ticket (code.google.com/p/chromium/issues/detail?id=41467):
press ctrl+L
then ctrl+c
go to pidgin
press ctrl+v into a XMPP contact, and press Enter
result: brainbird.net/notice/2373271

PS: funny how I lost http on that too :) so kmail doesnt have it either

-- 
Fernando Pereira

Ok, here's my two cents on this. it's UGLY as hell! I "live" on the for a few years 
already and ALL the browsers I ever used show "http://". Why hide it now? Does it take 
space on a 1600x1200 screen (probably avg resolution nowadays)?! It takes about 30 
pixels of that 1600! I really can't understand the benefit of this... And you guys 
should think about something: If there is so many people complaining, who's wrong?! 
Thousands of us, or 5/6/7 of the Chrome UI Team? 
http:// doesn't hurt the UI, it never did, it never will... 

Those running their own builds off of the dev line can turn this feature off for 
themselves, of course. The simplest way I found to do it is to go to src/net/base and 
edit net_util.cc. Search for the line defining a local "const wchar_t* const kHTTP" 
and change the constant's value from "http://" to something that won't ever match.

I'd be interested to know, incidentally, why the following line constructs an entire 
wstring object just to get the length of the kHTTP string, which is a constant that 
will always be exactly 7 characters. Even if you want to allow for future changes to 
the name of the HTTP protocol, is there no wcslen, or equivalent platform-agnostic 
wrapper?

Yes I hate this too. It just feels like a bug and the browser is missing something 
important to the net. We should at least have a preference or I may as well go back to 
Firefox.

Uh WONTFIX? This is a huge problem. +1 to fix this. This is a huge usability problem 
and it breaks many things. Your stupid workarounds are just that - stupid. Fix it.

This is 100% broken on Unix (as noted by many other commenters, X11 copy-and-paste doesn't work).  This is 
100% broken on Mac OS X (as noted by @38).  I haven't tested it on a Windows box, but I assume it's probably 
broken there also.  This is a quite unnecessary change and has caused many flames.  I am a software engineer 
with a primary focus on usability and I will say that with over 80 comments in 2 days on a *development 
branch* release, and even other developers frustrated at the change (see @56) I must say that this obviously 
wasn't thought through.  And where is the rationale?  pkasting became defensive when people questioned this 
change, but never provided one; is it just a 'pet peeve' of his that "http://" is at the beginning of URIs?

Lastly, I agree with some of the other commenters; if you're going to take http:// out of the URI, just make the 
entire OmniBox appear more like the Android browser's location bar.  "www.google.com: Google" seems more 
appropriate.  You could even remove the name from the tab bar and leave it as just the favicon (with page title 
displayed as a tooltip), since that information would be duplicated in the OmniBox.  Seriously, if you're going 
to make a huge functionality change, think it all the way through.  Make multiple designs.  And be able to 
provide clear cases where this benefits the user and why this decision is better than the alternatives.

omg, this will be pain. i already suffer enough when people paste me URLs without 
http:// and it doesn't get auto-linked. now you're training people to do it even 
more!

you're encouraging BAD behaviour. so what if your browser is smart enough to do the 
copy/pasting?

and now your codebase is more complicated, and has a dozen corner cases to deal with. 
gotta love your "fix" for web pages on a domain like ftp.blah.org. as soon as you're 
adding special cases for such BASIC interaction, you SHOULD know you're doing 
something wrong.

talk about over-engineering!

Although @82 is rather emotional, it's quite correct in the assesment of the situation :) I believe the decision will 
make *some* sense once we hear the rationale and/or motivation behind this change - but so far, this hasn't 
happened.

@71 read the analogy right, it handles about a "picture of a car" which represents
the "displaying of the url" and the protocol is as important as wheels of a car,
because tel me, how would you surf the web without http? 

@84 I did read the analogy correctly. Reread my reply. Displaying something to the user 
they are already familiar with is silly. Thus, displaying that the car uses unleaded 
gasoline is silly.

@81 Can you be more explicit on exactly what is broken? I have Debian GNU/Linux on my 
laptop, and copy/paste works just fine in every application I've tested with. The 
latest version of Chromium is presenting a web object to the clipboard, and each 
application I've pasted the URL in, appropriately identifies the object, and 
linkifies the paste. My wife has an iMac and an iBook, and the latest version of 
Chromium works as expected with copy/paste as well. Lastly, my work machine is a 
Windows XP laptop, and again, everything works as expected with the latest Chromium 
revision.

One person on the chromium-discuss mailing list, that Emesene doesn't handle the web 
object correctly, and doesn't linkify the paste without "http://" in the front. I 
haven't verified this, but this is exactly the sort of reports the developers want to 
hear about. If you're a software engineer, surely you're familiar what a good bug 
report is. That's what we want to hear. Not sweeping, broad statements and 
assumptions. So, how about it? Have any specific bug reports we can test where 
pasting a URI without "http://" is broken?

Further, as explained many times, the rationale for pulling "http://" from the 
display, is because it's redundant information. It's already understood that the 
browser uses the HTTP protocol by default. Displaying it to the user is just silly. 
If a protocol other than HTTP is being used by the browser, such as HTTPS or FTP, 
then the user should be notified.

@86 When I highlight and copy all but the end characters of the URI (say, leave off 
fragment), the paste does not include "http://".

@86, the rationale is rather unconvincing to me, but that's subjective thing. What are the chances of changing the 
behavior to "show whole URL after focusing Omnibox"? This would cut the list of corner cases "program Y running 
under Xwindow version Z fails to properly retrieve whole URL".

@86 It's visually jarring, and the rationale makes no sense. You're *expending* effort 
to "fix" something that's not broken. Ever heard of the KISS principle? No-one benefits 
from this change. Surely you have better things to do than waste time on this.

Also, www.google.com/ looks plain silly and unbalanced compared to 
http://www.google.com/. If you're so into "prettifying" the URL for inane reasons (it's 
redundant!), then get rid of that lingering / at the end.

@88,

of course the rationale isn't convincing. Problem is: They don't have to convince you and me. Eat or die! I'm 
actually somewhat sure, that they by now understood that it was a bad decision to take. For "social reasons", 
they can't back it out, though. At least that's my impression.

Regarding "add http on focus" - have a look at http://www.flickr.com/photos/alexs77/4527511799 (darn - 
http:// was originally missing after copying from Omnibox. Sucks.). Please pay attention to the 2nd round of 
me clicking into the Omnibox. There, I'm clicking "in the middle" and then drag to the left. If "http://" would 
be added when Omnibox gets the focus, then from where would I start selecting? A few chars to the left? Why? 
And what if you drag to the right/end-of-line?

No - adding http:// ON FOCUS is bad.  

Adding http:// ON HOVER would be a solution to this. But it would look terribly ugly (text jumping all the 
time). It would also make selecting text harder.

And then there are "pointerless" devices (tablets/touchscreens), where there's just no "hovering".

-> Solve the root cause! Don't remove http://!

@87 Same here. But, the copy from Chromium put a web object in the clipboard, and the applications that I paste that web object 
into, even though "http://" is missing, correctly identifies the object, and linkifies the paste. So, even though the "http://"  
text is missing from the paste, it's still linkified, and everything works as expected.

@89 No on said anything is broken when the change occurred. This isn't "fixing" anything. Just like moving the tabs to the top 
or moving the menu bar to a couple of buttons, or merging the search and address bars. None of those were fixing anything 
broken. They were just changes that enhance the overall experience with the browser. This is one of those changes. However, I 
do agree with you about the trailing slash. That is a bit unbalanced, and just actually be filed as a separate bug. 
"www.google.com" is more visually appealing than "www.google.com/".

@90 You're behaving quite emotionally. I would suggest taking a deep breath, taking a step back, and looking at the change 
logically. How will this change affect the way you use the browser? Will you type URLs in the Omnibar any differently? Will 
pages be presented differently? When copying and pasting, are there specific applications that aren't linkifying the web object 
from the clipboard? What we need is logical discussion, not emotional ranting.

@91 I don't know what you mean by "web object". I'm on Windows, and nothing seems to 
linkify the URI without the http://, including Google products.

@91,

I might sound emotional, because you guys behave so thickheaded. That's annoying. It's also rather annoying, 
that you pretend to want to get a logical discussion but simply dismiss or don't accept logical reasons 
presented against the change. To underline: This behaviour of yours and also of pkasting is what's pissing me 
off. This BTW also includes marking such a bug "WontFix" so quickly. "Won't Fix" is quite an aggressive 
statement, in the lights of all the problems and arguments presented against it. Of course you won't see that; 
you don't have to say this now.

@92 The clipboard is a complex tool. It doesn't just store plain text any longer. It 
can store spreadsheet data, even keeping formulas in tact, it can store rendered 
HTML, it can store binary images and other binary data. It can be stack-based, 
meaning a copy of one object won't overwrite a previous copy of another object. The 
clipboard can be implemented system-wide, or application specific. In the case of 
Chromium, when copying the URL from Omnibar, the cliboard has a web object, meaning 
that when you paste the object into another application, the application should 
recognize it's a web object, and immediately linkify the paste.

So, can you give specific cases of applications that aren't linkifying the paste? 
From here, I've tested in the Gmail and Google Docs interfaces, and in both cases, 
it's a link. It works in Microsoft Word and OpenOffice.org Writer. It works in 
Thunderbird and Outlook. It works in Pidgin. Any application that I have installed on 
my Debian GNU/Linux machine, my wifes Macs, or my work Windows laptop, in every case, 
the web object is treated correctly, and the link is created. So, can you give 
specific examples of something that is not creating the link?

@94,

of course you won't accept this, but I copied an URL from the Omnibox into this very text entry box on 
code.google.com here, and no http:// was added to the beginning of the URL.

So, if you want to know about an application where http:// adding doesn't work - try Google Chrome. 

@93 For the record, I'm not a Chromium developer. However, can you explain this 
behavior? We've told you why the change took place. It's redundant geek speak, that 
doesn't need to be communicated to the average user. Rather, a globe icon 
communicates what is happening better than text. In the terms of copy and paste, 
we've asked for specific applications that are not linkifying the paste, and no one 
has stepped up to provide such an application. We've asked what bugs this causes, and 
all we've gotten is "I don't like it" or "it's pissing me off". I think we've been 
quite patient and level headed trying to assess what the big issue is, and the only 
thing people seem to keep bringing up is they don't like it. In other words, it's 
entirely subjective. So, if you can remain level headed, and provide specific bugs 
reports or broken behavior due to the change, then we can look at those cases. Until 
those are brought up, whining and moaning about it isn't going to do much, if 
anything.

@95 It's not about whether "http://" is displayed in the paste. Of course it isn't. The 
point is, does Chrome not know how to interpret "www.google.com/"? Does it break, 
because "http://" isn't at the front? It's not about what is being shown, but how the 
application behaves with the data.

In all honesty, removing the 'http://' seems to be a solution in search of a problem, 
particularly given that Chromium tries to be 'clever' about how URL fragments are 
copied into the clipboard.

Nor is 'http://' redundant information--if Chromium did not support HTTPS or FTP, I 
would agree, but it does support those protocols. Thusly, it needs to show the protocol 
all the time or you're violating the principle of least surprise.

@96 Have you completely missed all the specific use cases posted to this bug report? I 
myself posted a couple.

@96 I posted a concrete example in @38

I too am not fond of this change.

Many sites do use SSL and one might speculate that as computing power and security 
awareness grows, this number will too. The inconsistency between this and regular 
http:// being hidden feels strange. As #98 said, this does break the principle of 
least surprise.

It seems that you're adding code for what is either very little gain or a loss 
(depending on your viewpoint). This doesn't seem like the right choice - although I'm 
sure the clipboard problems will get sorted, it's obviously not an entirely simple 
thing to get right (as evidenced by the current bugs) and gives another place for 
bugs to hide.

@94 It doesn't work in any case I've tried: 
Twitter (using Google Chrome)
Facebook (using Google Chrome)
code.google.com (using Google Chrome. see?: code.google.com/p/chromium/issues/detail?id=41467 )
Google Talk (destkop client)
GMail (it linkifies in the email, and not because it's a 'web object' but because GMail linkifies URI 
fragments, but since it doesn't include http:// it doesn't linkify for the person I send mail to)
mIRC
notepad
wordpad

Are you sure any of those applications you tested actually wouldn't linkify "www.google.com" if you 
typed it?

@97,

if http:// isn't displayed in the paste, then it's plainly broken. While it might be true, that nowadays lots of 
tools or websites automatically parse "strings" like www.google.com and make that a link, that's not so true 
for strings like code.google.com. So, yes, the "application" breaks, and doesn't make code.google.com a link, 
because the protocol http:// is missing in front of it.

@96,

yes, you've told why the change took place. It wasn't convincing in the least, because your basic assumption 
"http:// is ugly/scares people" is an assumptin, that I don't share. Also not when I think about normal users. 
On the contrary, NOW the addressbox is ugly, because the http:// is missing. Again: http:// is no means 
whatsoever "redundant". It's important information! Some "strange" icon doesn't communicate this information 
better then http:// does. The opposite is true - the icon is worse.

It's also untrue, that all you've gotte is "I don't like it" or "it's pissing me off". You know that this is untrue, but 
that makes me wonder, why you write this in the first place? It's also not like I haven't brought up specific 
issues. Again: You know that you're not writing the truth. Why do you do that?

@100 it seems Enterage 2008 is indeed identifying the web object, and linkifying, it's 
just pasting the URI twice, am I correct?

@102 Twitter, Facebook, code.google.com, Google Talk, mIRC, notepad and wordpad all use 
plain text editors (minus wordpad, which is an RTF editor). These editors don't carry 
meta-information for web objects, so even if you type "http://google.com" in them, it 
still won't linkify. That should be expected.

Also, I just tested with Thunderbird and it does not linkify for me there either.

@104 Not true. Twitter, Facebook, code.google.com (using Google Chrome), Google Talk, 
mIRC and Wordpad all would linkify if I pasted an http:// url. Try it. Notepad would 
not, but it would paste with "http://" from a normal browser, which I would expect to 
be in the clipboard for non-"web object" applications to fetch.

Issue 41869 has been merged into this issue.

Issue 41819 has been merged into this issue.

When I copy the URL for this page into apple mail (latest version) I get

  code.google.com/p/chromium/issues/detail?id=41467

Ie, the protocol part of the URL is missing.

   When I do that with any other browser I get the full URL. For the past week I have to add the http:// to every
URL I mail people, and that is close to 70 a week, if not more.

@96 said "It's redundant geek speak, that doesn't need to be communicated to the
average user. Rather, a globe icon communicates what is happening better than text."

I really hope you understand that this is a fundamental change that affects the
entire web and how people look at web addresses. This is reverting Tim Berner's Lee
decision to add http:// to web addresses.

If all the browsers would implement this and 'http://' gets wiped out of the global
consciousness, it would be a fundamental change to how billions of internet users
identify and recognize web addresses. 

You have to have more reasons than "it feels redundant, we're saving some space, a
globe is so much prettier" when you are changing something so fundamental.

Let's assume after a while all browsers implement this and all applications out there
handle this correctly by linkifying everything. People get used to passing around
www.foo.com without http. Everybody forgets what http even means, it's just redundant
geek speek.

I see a few problems with this

 - it's really hard to tell that you are ONLY hiding http:// and not other protocols.
That globe means nothing to me. How do you explain to the user what protocol you are
hiding? 

 - how do you do that consistently across browsers? Will everybody implement their
own little globe to signify 'http://'? Will there be something standardized?

 - will you in the long term remove https:// because it's redundant too? If that is
the plan, then once this also gets wiped out of global memory, how do you explain to
the users the difference between secure and insecure connections? The one with the
globe and the one with the lock? :-)

What I think everybody here is saying is that for such a fundamental change, you
should have a better thought out answer other than "well, I'm a developer and I
personally think this was redundant, so I removed it". It's a change that affects far
far more than some space on the address bar.

@111 It's like the dot after every TLD (www.google.com.) - it's used with every DNS 
request but it's not shown in the URL, because it's been put automatically if it's not 
there. And it would confuse every browser user.

This breaks middle-click paste functionality on linux machines:

To reproduce:
1) double click in the location bar to select the URL
2) middle click in another window to paste the URL.  Note that http:// is still missing.

This is frustrating enough to me that I'm considering a move back to Firefox or Opera.  Please 
revert this short-sighted change.

Throwing around threats that you're moving to another browser is counter productive. 
Right now, it's a regression that "http://" isn't showing in pastes, and it's being 
worked on. You're more than welcome to help if the patches aren't being submitted fast 
enough.

The option to hide the protocol should be an opt-in option, meaning that by default 
it shows the protocol and you can change it to not show.  Having the option to 
customize the browser to each person's wishes is an added bonus.

If chromium keeps with the current growth rate and keeps this feature, I fear that 
other vendors and users will adopt the idea that "http://" is optional (and later 
maybe "https://").  If the defining web protocol is deemed optional it will cause a 
slew of headaches for validation and standardization, potentiality URI's would have 
to be checked against validation schemes for multiple protocols before they could be 
used.  Imaging having to check against schemes for (http[s], irc, smtp,...) before 
you could even safely use the string.

This is the patch in question.

http://src.chromium.org/viewvc/chrome?view=rev&revision=44140

Issue 41885 has been merged into this issue.

Another nice example for real world unpleasantness this causes:
- Enter ftp.gnu.org/gnu into omnibox.
- That'll take you to ftp://ftp.gnu.org/gnu
- If you want to go to the http version, you have to type in http://ftp.gnu.org/gnu
- Which will show up as ftp.gnu.org/gnu

Lovely.

@118,

it's even worse: When you're on http://ftp.gnu.org/gnu, only ftp.gnu.org/gnu is shown. Now go to the Omnibox 
and hit <enter> (because you changed something in the URL or maybe not).

Result -> you're on the FTP server!

--> Issue #41585 => http://crbug.com/41585

Just logged another bug on a related issue: http://code.google.com/p/chromium/issues/detail?id=41910 and I blogged about the overall matter at at 
http://dropsafe.crypticide.com/article/3962 

I regret that this issue seems to be turning into the Chrome people entrenching themselves in the face of folk telling them "we don't like this change" - hidden 
amongst which are a selection of powerful technical and philosophical issues which don't get addressed other than being "less important than the UI goal"

To change tack I would highlight that by expunging the protocol from the URL field the Chrome team are going to have to do a *lot* of out of band effort and 
bookkeeping to maintain that information elsewhere, for the purposes of cut, paste, and the internal operations of Chrome.  I suspect that issue #41910 is 
likely caused by a failure to manage this information properly.

To me this smacks of making a rod for Chrome's own back, which is a pity.

After a few days with this change, I feel compelled to express my disappointment.

I hope that despite the fact that UI design is not a democracy, chromium/google will 
take advantage of these early reactions to the change from their users and packpedal 
on this one a bit.

If the change isn't reverted, I think this amount of reaction warrants an 
explanation, a blog post or something, describing the reasons and logic for the 
change. Because for now, to me (and others obviously), it looks incoherent.

You could sidestep the problem for now by adding a config option, even a command line 
one, letting people revert to a "complete url display" mode.

People have also suggested showing the complete URL on focus, which I think is a very 
good idea, as it solves the "show one thing, copy/paste another" least-surprise-
principle-breaking thing.

I understand that you guys have your reasons for this change, and the need for 
innovation in the browser. Styling the url (graying out http...) was a nice touch, 
and you can probably invent 100 new styles or displays that in the long run will be
more appropriate (showing the page title, whatever). 

But this is not just any random part of the UI, it's a pretty important one (sacred 
for some ?), and so you'd do well to approach it step by step and provide fallbacks.
 
Thanks !

@90 a.skwar, one option would be to ensure that the URL is placed into the address 
bar in such a way that were the odd little globe icon not present, the text "http://" 
would fit in perfectly -- essentially starting the edit box right at the left edge of 
the white area, rather than at the right edge of the globe. On focus, it could switch 
(even crossfade :-) from the globe to a grayed-out "http://". Many users wouldn't 
even notice, because the rest of the text wouldn't move, and this would solve your 
text jumping problem. A single click would do the same thing, but also select the 
"http://" part of the line -- copy/paste problems solved. For other protocols that 
are always shown, the icon would simply be left there. Minor inconsistency, but no 
more inconsistent than hiding "http://" in the first place.

lol what a weird and annoying bug, my dad who's quite computer illiterate thought he 
had been hacked and refused to use the internet to log into anything (email, banking, 
etc.)

Have to go back and install firefox for him now.

Hi everyone.

I think the most severe problem which *can't* be fixed is outlined in @29 but it
looks like it wasn't understood.
If http:// is hidden and heuristics are used to add it to clipboard while copying
how is the browser going to find out what exactly you want to copy?

I mean: the address bar now reads
code.google.com/p/chromium/issues/detail?id=41467#makechanges
if I select "code.google.com" it's going to put "http://code.google.com/" into
clipboard but what if I want only the hostname (e.g. for ping)?
Here I'm forced to paste it then edit it to remove http://.
And what if I'm pasting it into some sort of weird terminal which doesn't support
line editing?
Will I have to open notepad, paste it there, select the part which I *wanted* to
copy...?

I already changed to OLDER version of Chrome, to have my URLs back to normal.
I like how it looks, I like that you want to minimize clutter, but why can't you 
display http:// when user clicks on omnibox? 

@126 The short answer is that you can begin selecting in the text of the address right 
off the initial mouse click, before it actually has focus. If the text abruptly changed 
to include "http://", it would move, and your selection would start from the wrong 
place. However, in comment 123 I proposed a solution to that issue.

it has to be evident, the http://, other scenarios https://, ftp://, it could be 
hidden once the entry has been typed, on other like https:// it stays like now open 
& evident and color change for security.
The address bar should be adjustable, currently too wide. (my screen is 1900 x 1050 
pixels).
So the change, I think should be modified, loads of great ideas above, most of us, 
do not agree with the change. 
Thanks for reading.

How to escalate this issue to the right person (senior management of Google?) which 
can make a quick decision? Rather than wasting our time in debating here.

Btw, any Google Marketing/PR here? This issue do hurt your company's image. 

It's this kind of thinking that compels me to stay with Firefox. At least Firefox's
design is based on popular vote.

This is beginning to remind me of the vast amount of negative feedback over the 
mandatory left tabs on the iGoogle personal home pages. Users overwhelmingly did not 
like it, but Google apparently had a compelling reason to ignore the users' 
preferences.

The comments that I've seen so far about the removal of the "http://" are also 
overwhelmingly negative, but Google apparently has a compelling reason to ignore 
users' preferences about this, also. In both cases, the compelling reason is not being 
communicated - at least not in a way that makes sense to the users.

This ticket is closed. It was stated early on that the core change of scheme removal 
will not be reverted, and I've seen nothing in the comments since then that makes me 
think that this decision will be reversed.

Having said that, @122 makes a lot of sense to me. Personally, I like the idea of the 
schema appearing on Omnibar focus/hover. But whatever is decided, I'm adding my voice 
to those calling for a detailed explanation of the rationale behind the decision to 
get rid of the schema.

Actually, this is a great leap forward in human engineering: having the computer
intuit what I actually meant and discarding the irrelevancy I, as an untutored
mortal, have committed.

This feature should actually become pandemic across the entire UI.  Let's start by
dropping the need for those pesky vowels: A E I O U.  That's only five characters
that need special casing; we already have that powerful handling of "http://" to
prove the technology.  Imagine: we could just key in "ggl" and wind up at
http://www.google.com/search!  Boy, what a savings!  My carpal tunnel loves this!!

The Z-Shell already corrects most of my command line typing mistakes; if only I
didn't need to type it at all.  We can do this in Chrome, can't we?

All we need is to carefully mimic the time-tested semantic transformation rules
established during the days of the Egyptian pharaohs.  We can write our web browsers
using the same spelling correction employed on the pyramids where vowels were dropped
to reduce space, reduce carving bandwidth, and nobody could read it anyway.

"MMX + 1" anyone?

Is there an online explanation of the rationale behind the decision?

@19 - pkasting@chromium.org 

A direct quote from you:

"Chromium UI design is not a democracy and is not based on users' votes, so "I don't 
like this" carries very little weight."


That is starting to sound a lot like Microsoft IE talk.
I'd like to refer you to Google's own philosophy, bullet point number 1:

1. Focus on the user and all else will follow.

www.google.com/corporate/tenthings.html

(notice the way the above url is pasted - missing the http:// thanks to this 
particular change removing the ability to select text in linux using the mouse and 
paste using shift-insert)

The idea of "copy one thing, paste another" is a very, very bad idea.  I really don't 
want to have to fight with Chrome in order to copy only part of the URL -- the part 
WITHOUT the http://.  @122 seems like a good compromise.

http://www.osnews.com/story/23171/Google_Removes_http_from_Chrome

I think following the @42 Mobile Safari approach is best. If the decision to revert
is not in the power of the developers and testers and has solely been passed down by
the UI team, then at least compromise and save face, by enacting click to view protocol.

I might point out, that if my UI team enforced a change like this on my development
team without consultation or even a seemingly valid reason, there would have been a
nerf war on an unimaginable scale taking place in the office right now.

So, no revert, fine, but at least look at @42 and perhaps buy your development team
some pizza to save face. 

Another use case. Amazon likes to add a lot of internal parameters to URLs, which can usually all be cut. 
Except that copying the beginning of the URL doesn't copy http:// now.

http://www.amazon.co.uk/gp/bestsellers/videogames/676365011/ref=amb_link_84068913_5?
pf_rd_m=A3P5ROKL5A1OLE&pf_rd_s=left-
1&pf_rd_r=1YPFPYN1XZ59Y4221GJK&pf_rd_t=101&pf_rd_p=477240573&pf_rd_i=13821481

www.amazon.co.uk/gp/bestsellers/videogames/676365011/

This just adds unnecessary complexity and code to guess what the user might've actually intended when copying 
the URL or part of it. Color coding however was and still is a good idea. If you absolutely want to make 
http:// less prominent why not just make it a very light grey.

Yet another straw on the camel's back.
http://blog.ssokolow.com/archives/2010/04/18/google-chrome-a-testament-to-hubris/

As much as I like most of the UI design principles that go into Chrome, I've got high 
hopes for Firefox 4 and its promise of a Chrome-like UI layout, a GUI that's actually 
responsive enough to use on Linux with more than one tab, and an extension system 
that, as fragile as monkey-patching is, does allow me to exercise my right to choice 
as a user.

I get the feeling the people making the choices could benefit from watching this TED 
Talk: http://www.ted.com/talks/malcolm_gladwell_on_spaghetti_sauce.html

To me, it's like the history of Firefox's success, told with food, and I think it's 
the number one reason why there's such an uproar whenever the UI team push what they 
wholeheartedly believe to be a definite improvement.

To be honest I like the idea but it doesn't make sense then why you left the / on the 
end of the url.

If this is to make it easier to the user (because computing is to make things easier) 
then why dont do it correctly?

http:// is gone, but www.google.com/ ???

It should be then www.google.com

Both options should only be a visual trick, hided because allot of softwares and authentications systems rely on the http protocol and a url without a / on the end 
would lead to an internal webserver redirection which leads to servers correcting 
this all the time on websites that forget the / on the end.

I agree Internet has to be easier but then it should be done wright.
https:// also still shows up. Why? If you decide to hide http:// you can also as well 
hide https:// you already have a lock icon for that that shows the user a secure connection. Grandma and pop dont care about either of them, they dont even care about 
www

This are my suggestions and I would also add two more.
When you hover the mouse over the address bar it show display the protocol

For people that dont like this they should have an option to turn the hide feature 
off in the browsers settings.

Im not sure why people complain because on the end its Google browser so they can do 
what they want.

@140:
I totally hate this "features" for reasons already stated here.

I would, however, agree with your last point if it was true. People complain because
they CANNOT do what they want. If options (even well hidden ones) or extension could
be easily provide, this kind of issue would not arise.

And I still wait for a reasonable explanation of this features (and the ones that
created similar reactions) other than "That the right thing to do [i.e. what we thing
it is even if we don't have justification and you tell us it could be otherwise],
love us or leave us"...

Removing the protocol scheme from the URL location bar is like removing the Google 
Search button on the Google homepage. It doesn't help anyone and it will confuse people 
even more. I'm all for simplicity and cleanliness, but this is the wrong way to do it.

Not only does this break the old habit of "double click on the adressbar and then 
middleclick in the irssi window" but it also hides information. it would make sense on 
a smartphone, but not on a browser. PLEASE PLEASE revert this change.

my viewpoints:
-BLIND peoples those who use text readers
-teaching
-What you see is what you get
-tradition
-I want to check the URL and the protocol from ONE box
-I sometimes edit the URL bar, this is annoying for me (change between 
http,https,ftp)
-new behaviour is not obvious (obvious for me is: all protocol showed or neither 
showed)

"PLEASE PLEASE revert this change" or
"For people that dont like this they should have an option to turn the hide feature 
off in the browsers settings."

i believe that hiding http:// or even https://, ftp:// and any other relevant internet protocols is a huge mistake 
and could end up causing security flaws with people copying and pasting www.somesite.com and putting http:// 
when the site uses https://

Chrome UI design team?????

What? Im sorry but this is copied from Apple and the design team in Chrome is so 
creative and they work so hard that they copied the feature exactly:

www.google.com/

Otherwise why is there a / in the end?

Im not sure who is in the UI team but they sure did a lousy jobs with tabs and status 
bars. Visual should be simple but still be useful. Otherwise just use a text only 
browser.

Like someone else said, must people know http:// even when they dont know what it 
means but I can bet most people dont know for what the trailing is on the end.

I completely agree with this feature but only if its done correctly, not just because 
Apple does it then Chrome has to do it as well.

Nobody types http:// anymore.

Nobody advertises their websites with http:// anymore

Even my business cards only have www.domain.com on it with no http://

But if this is to be done as a visual aid then the / on the end should be gone as 
well. And it should be done for https:// as well.

Still this must be an option, not a forced option. If someone does type or want to 
see http:// they should.

Now if the UI wants to render the url then do it correctly not in just partially.

And if you want to take this a step further in some years domains with .com will not 
even show the .com anymore but just the name:

Google

What about other domains maybe .org?

Google ORG

Google GOV

How many of you will remember this as this is how its going to be in 5 to 10 years. I 
said the same for things that are now happening 10 years ago.

I completely understand people are afraid to changes but we geeks cannot force the 
rest of the world to think like us, if it was for us we would even see the IP address  
with the url or even use numbers instead of domain names. 

Internet is getting easier and it should be for users as well. Now people do have a 
very good point here and I think this should be a gradual change not a forced one. Im 
sure Geeks will stop using Chrome for this as they are exactly the ones that love to 
see everything, so this has to be a thing of personal choice which can be turned 
off/on from the settings. Otherwise DONT implement it because the world is not ready 
for it.

It would be great someone from Chrome team will update the latest developments on this 
bug. It looks like team ignored this user feedback

I have 2 use-cases that this change breaks:

Use Case 1: Easily Switching Between URL Schemes.

I use Google Docs which supports both http and https schemes interchangeably. 
Sometimes I will load up my doc list, edit the URL to append a 's' to the URL scheme
to get it secured. Other times if I have issues using the https version (e.g. on a
bad connection, or when accessing from behind a firewall), I will edit the URL to
remove the 's' from the URL scheme.

Another example: some file-repository type websites support both ftp:// and http://
views of their repository.

Changing the URL scheme from http:// is no longer possible with this change, and
breaks this use-case.


Use Case 2: Copying Partial URLs

The ability copy partial URLs (sometimes including the http, sometimes not) is
convenient, and I personally do it frequently. This change breaks that use-case, with
Chrome deciding for you exactly what text is added to the clipboard.

E.g. for the url http://path.to/some/resource, a user may reasonably wish to copy:
- "http://path.to/", and
- "path.to/"
Which is no longer possible.

NB. Mobile Safari does *not* break this use case, as full URL is shown when editing.

It has just been the weekend - so give them some time :) 

Please revert this change or at the very least provide an option to return to the
correct functionality.

Had this "BUG" a few days now and it just makes the URL not look right, It doesn't make 
it look better it just looks wrong. This Absolutely needs to be fixed if it doesn't 
guess ill have to dive into the source-code and fix the "BUG" myself ;) 

I completely understand the need to accommodate illiterate users, but this is quite a poor choice for the literate ones.
I would prefer *a lot* the use of colors the same way you are using now for the rest of the url, a light gray should do it, but i don't see the point in 
removing the whole thing, beside keeping illiterate the illiterate.
I mean, if you want to browse the web you need to get used to the way it works: you call it redundant geek speak but in fact there is no other 
information on-screen letting you know what protocol is being used; you could make it lighter gray so that illiterates will be more prone to ignoring it 
but that's it, else they'll learn something new.

What next? Are you going to remove that clunky "www" too!? Is this still redundant geek speak or not?

"Rather, a globe icon communicates what is happening better than text. "

*Maybe* for a child too young to read books without pictures in them, or for an
illiterate person who asks for a picture menu when they order at Burger King.  

Except, that you're expecting people who barely understand computers, and may very
well think the globe is a new version of IE's spinning-Earth loading icon, to guess
that the globe icon means "'http://' belongs in front of the address you see", or
that globe = "insecure connection" instead of globe = "happy earth day everyone".

"However, right now, the view that this is a good change is one that I'm expressing
on behalf of the entire Chrome UI design team and management chain"

Thanks, that really means a lot, especially to people who have ever worked under a
"management chain".

"But there is no such thing as "standard clipboard functionality"...So, in reality,
there's no obvious "right way" that we used to be doing and now aren't."

That's the saddest excuse I've heard in a very long time.  When anyone copies or
pastes anything that looks like text on and computer, they expect that exact same
text to be copied or pasted, regardless of the clipboard implementation details. 
Imagine you're pasting paragraphs into a legal document and the default view of the
document displays the middle 90% of each paragraph as a pencil icon, for the users'
convenience...

What a pity; this move, together with the globe icon, makes me go running to Firefox 
again.

At least it is predictable. Slow, but completely predictable.

I use Chromium every day on Linux machines, and liked it a lot in spite of some 
missing features (e.g. like RSS bookmarks). I liked the speed but particularly the 
UI.

Not anymore.

Given the overwhelmingly negative tone of the feedback in this item thus far, I felt
the need to offer some support. 

I like the change. I think it could use some polish, perhaps showing the http:// when
the input bar is focused, so that the cut-and-paste behavior is less magical, but
overall I think it removes just a little bit of noise from our lives.

While I can see the logic in the change (not that i agree with it, mind you) hopefully 
we'll see an extension to bring back the old behavior.

This bug has been closed with 'Won't Fix' after only four days.  I'd like to see this 
discussion continue.  This is big change to the UI and more people should be allowed to 
provide input.  I'm not in favor of this change at all.  We need to see the entire 
address.

Yet another reason for me to not use Chrome. It doesn't play nice with others, it
refuses to obey usability standards, and it confuses users. Oh, and it crashes every
5 minutes. Let's not forget that.

Can Google fail with this product any more than they already have?

I'm going back to Firefox if this hits Chrome as a feature.

http://www.osnews.com/story/23171/Google_Removes_http_from_Chrome
http://blogs.zdnet.com/igeneration/?p=4677
http://blog.arpitnext.com/2010/04/chrome-to-ditch-http-from-addressbar.html
http://www.conceivablytech.com/684/products/simplifying-web-browsing-google-chrome-drops-url-prefix/
http://www.readwriteweb.com/archives/chrome_hucks_http.php
http://www.thinq.co.uk/news/2010/4/19/google-drops-the-http-from-chrome/
http://erictric.com/2010/04/19/google-chrome-gets-rid-of-http-from-address-bar/
http://www.freenews.fr/spip.php?article8145
http://www.generation-nt.com/google-chrome-http-actualite-1000011.html
http://www.clubic.com/navigateur-internet/google-chrome/actualite-335982-google-debarrasser-chrome-http.html
http://www.diarioti.com/gate/n.php?id=26301

Can't believe nobody has mentioned the obvious rationale for this change: SPDY://

They'll never get over inertia unless they disintegrate the HTTP juggernaut first.
Anyway this ain't gonna change, folks, so quit whining.

Issue 41992 has been merged into this issue.

Issue 42076 has been merged into this issue.

Issue 42103 has been merged into this issue.

Issue 42855 has been merged into this issue.

Issue 54515 has been merged into this issue.

Issue 54598 has been merged into this issue.

Issue 54878 has been merged into this issue.

Issue 54964 has been merged into this issue.

Issue 55000 has been merged into this issue.

Issue 55288 has been merged into this issue.

Issue 55290 has been merged into this issue.

Issue 55585 has been merged into this issue.

Issue 52321 has been merged into this issue.

Issue 55863 has been merged into this issue.

Issue 55890 has been merged into this issue.

Issue 56161 has been merged into this issue.

Issue 56662 has been merged into this issue.

Issue 58626 has been merged into this issue.

Issue 56015 has been merged into this issue.

Issue 60528 has been merged into this issue.

Issue 60584 has been merged into this issue.

Issue 61353 has been merged into this issue.

Issue 61921 has been merged into this issue.

Issue 65620 has been merged into this issue.

Issue 66603 has been merged into this issue.

Issue 72411 has been merged into this issue.

Issue 117818 has been merged into this issue.

Issue 137551 has been merged into this issue.

I've read many rationales as to why you're determined to have this 'feature' and have yet to hear one that makes sense or I believe. However, you're determined to exercise Google, dictator-like control over Chrome. Fine. You won't even give us a setting for this. Can't power users at least have a flag in chrome://flags/? It's so frustrating copying one thing and pasting another.

My work involves knowing and using every part of the URL. Our platform behaves differently and offers different features depending on whether you start with "http://" or "https://" for the exact same URL. It was developed that way because that's how URLs work. When I also give links to clients, it matters whether it's http or https. I shouldn't have to edit it after it's left my browser.

I also have to connect to a Microsoft exchange server from time to time which literally breaks if accessed via http. Since Google automatically parses it as http and then doesn't show it, I have to type in every single symbol of the entire URL to get it to connect. That is not a feature. That is a bug.

The protocol is neither optional, nor cosmetic. Nothing in the URL is superfluous, even if you don't like how it looks and nothing can be left out. It's not your decision whether or not to strip parts of the URL. You do not make web standards and you do not get to overrule them even in your address bar.

IE is a plague and yet when I develop, I develop for it as well, because it has to work for everyone using the page. Give us the option to get our whole, uncut URL back, it's not your decision to make.

this is very disappointing.  I want to see the scheme as part of the URL.  You don't hide "chrome://", so why pick and choose to hide "http://".
Also, not having it there breaks several services that I use from OmniGroup.

The only thing left to comment is that this issue is unbelievably ridiculous (commenting for the purpose of keeping this bug alive).

removing scheme from copied URL is wrong way! Look here http://en.wikipedia.org/wiki/URL and don't speak for all people "Nobody types http:// anymore."

My issue:  I use chrome at work.  I work at a web hosting provider.  I often have to ping/dig/whois a domain name.  I can no longer copy and paste it from Chrome to such lookups because the http:// auto-copies, and I have to go and remove it from each lookup I do...

Instead, I went back to Firefox, which did the same change a while back.  Their's you can undo though, 

About:cofig -> browser.urlbar.trimURLs = false

Why can't Chrome make it so you can undo this too???

@196 Not only that but Waterfox runs just as smooth as Chrome does (at expense of memory) so here I am looking at switching back to Waterfox because they respect the users enough to give us the option to disable 'Noob Mode'. 

Chrome is starting to make the same 'We made it stupider because there are stupider people' arguments as Windows, and FF is looking more like Linux with options/controls to keep your user experience positive.

Firefox has in about:cofig setting browser.urlbar.trimURLs

Why can't Chrome make it so you can undo this too?
----

I do not argue with UI design of Chromium, because it is NOT my call as I'm just user. But as user I argue to have user setting to set UI of Chromium to my needs (or liking, for that matter).

I'll probably continue to use Chromium weather it be solved or not, but I'll never use browser without this setting as my primary browser. Or rephrased in other words, it's your (design) right to mold Chromium to have smart & secure UI. But denying it's users to have preferences is not just ignoring your user base, it's actually considering Chromium users too stupid to give us choice. That's not only annoying UI decision, it is also a management decision, and a bad one.

Having in mind number of complaints here, work needed to implement this (should be trivial) and positive feedback from your user base if you do it, maybe changing status of this bug from WontFix to LowImportance or even Medium :) would not be such bad idea.

My 2 cents etc...

The feature is a valid and useful feature for most users.  

However, many devs now use Chrome for HTML5 development.  For them, it's critical to know if it's https or http.  Developers also want to be able to alter the URL after the initial hit.  This is usually to add URL Parameters (tokens etc).

Unfortunately, updating the URL is a big issue, as Chrome "forgets" you ever typed in https.  What's worse, because Google can't resolve the url (because it might not be publicly accessible), it redirects you to google search.  This is very frustrating.

I think there should be an optional feature for developers which will stop google messing with your address.  I've spent hours fighting this "feature".  Of course it's not a problem for your average user, but highly irritating for devs.

Sorry, just to add to this, I've also had Google Chrome "steal" temp tokens as it visits the URL before i hit enter.  I'd like to turn this feature off too.  I keep getting session expired, because it steals the one-time token for itself.

The broken copy-paste behavior is the part of this bug I run into most frequently. Often when I copy a partial URL out of the omnibar, I *don't* want the protocol. But with Chrome, I get it whether I want it or not.

I stopped using Chrome/Chromium a long while ago, PRECISELY because of this "feature".

How much does it cost for Google to keep this stupid position, against all odds? How much energy, engineers time and money is spent to defend this?

Why not give us a damn hidden switch to turn off this "feature"? This would appease all, I guess. And I would happily go back to Chrome/Chromium.

Jesus...

Yep. Definitely Google being stupid again.

You would think that any reasonable company that was still dealing with user complaints a year after implementing a stupid idea would have the brains to change their decision, or at least allow a user option so we could have the behavior we need.  Given the issues with the Flash player not working in Chrome, I guess its time to say adios to what could have been a great product and go back to Fire Fox.

Comment 205 above: "I guess its time to say adios to what could have been a great product and go back to Fire Fox."

I never left Firefox, but changed Opera with Chrome/Chromium as second browser. When level of irritation becomes too high, I'll look for better choice for second browser.

Anybody at Google caring enough to take a hint from it's users in time?

Same problem. Some time I want to add "s" to "http". Chrome never be my primal browser.

I'm a developer who said adios to Chrome about a year ago, after having had been a fan for a while. I came back to see if things have improved. They haven't. This particular issue is a pain, a small pain, but enough to make me once again uninstall it and feel both disappointed and annoyed at Google... once again! I think this may well be the last time I'm going to bother. I'm even going to stop testing web-sites in it and on all my sites I am going to suggest that the user upgrade to a more 'user-compliant' browser, like FF or (dare I say it) IE9+ or even the much overlooked and quite lovely Opera. Goodbye Google Chrome, you had a nice childhood, but you're a know-it-all adult who doesn't care about anybody else's opinion. You and your remaining users are going to end up very lonely!

p.s. what about gopher:// and archie:// etc. Have you decided that people don't need to know about those bits of the internet?? Making way too many bad choices for me Google!!

p.s. what about gopher:// and archie:// etc. Have you decided that people don't need to know about those bits of the internet?? Making way too many bad choices for me Google!!

Adding an option would resolve this.
Not doing it is just stupid.

If this will never change, please add show 'http://' as an option for more tech savvy users like Firefox allows for.  This would allow users like me to choose if I want to include the 'http://' in my copy and paste.

As a web dev I use FTP frequently for many different websites.   9 times out of 10 the host is the same as the URL.  Having to remove the http:// from my copy and paste of the url each time is unnecessary nuisance.

I don't know why the developers thought this was a good idea. The standard URL structure is prefixed with a protocol regardless of the website you visit. Why fix something that isn't broken? Isn't this the reason why IE6 became so notorious? 

This reeks of Google's influence on the developer team to do things their way, and I don't like it. I don't know much C/C++, but I'm sure it's just a matter of changing a few formatted strings to include "protocol://" by default.. C'mon people. This is a no-brainer.

Since Apr 14, 2010 a lot of people have requested an option this "feature" to be turned off. Firefox has a great clean solution for this - both sides are happy:
1. by default http:// is hidden and normal users will use it that way.
2. The users that do not like it this way can turn off this feature from about:config page, option "browser.urlbar.trimURLs"
Note that this do not add any complexity to the options menu. It's invisible for the normal user.
It would be great to add it on chrome://flags/ page

Yeah, having a flag for this would be great. I'd like to see the protocol all the time, too.

Is it really so hard to make an OPTION for it ??

Thats exactly what options are for. Some people want it that way, some the other way.
If only one opinion counts, you could simply remove all options.

I'm yet another user who dislikes this change and requests an option to revert it. I'm seriously considering going back to Firefox as my primary browser.

Another plea from the community to provide a flag to disable protocol clipping. I have no problem with this feature being shipped by default. However, the fact that there is an immense outcry from the community to provide an option to the user to disable this feature and is being ignored by Google development team sends a bad message and leaves a faul taste.

Please, provide us with an option to disable protocol clipping.

Provide options to show URL scheme/protocol and port, or the complete actual URL.

Please provide an option for this, or at least allow an extension to do so.

+1 Please provide an option for this, or at least allow an extension to do so.

Please provide an option for this.

Just one of the reasons do not use chrome.
Google thinks they can dictate what we like and what not, what we need and what not
To proof this : look at all the comments and still the status is WontFix

Google ??

force me to use firefox.
Google think they are right,but they do evil.
just like what other people said:
"Firefox greets me with a page explaining my rights as a user of open source software. Chrome greets me with… sigh… Chrome greets me with a fucking advertisement for a Chromebook."

I had problems with this issue. My site had broken ssl. The broke was hidden with this feature and i am wasting my time to read that if that is http you see nothing, but if you have https, it will be shown. So it is insecure. I need option to see complete url in any case.

Hi pkasting@chromium.org, could you explain what the team's rationale was for this feature? I've tried searching with Google and I've been unable to locate any sort of blog post or news reports containing word on the issue. I read all of your comments and they all focus mostly on addressing other people's reasoning without really exposing your own for criticism.

I will try to list what I understand about the issue.
Pros:
- Displayed URL takes up less screen space. (not really a pro on any modern desktop, not to mention it could autohide based on space)
- Displayed URL contains less distractions without containing less information.
- Makes an effort to combat the common belief that a prefix is necessary, which you might consider obsolete or undesirable.
- Provides more contrast to https urls, which don't hide the scheme. (This has no actual merit because you already have a large intuitive graphic next to the url for indicating this.)
Cons:
- This is undeniably a "gotcha", an intentional feature that is counter-intuitive and invites mistakes.
- Makes it harder to edit urls in the address bar. (changing the scheme to https, adding a slash before typing or pasting a directory name)
- Makes it impossible to copy the entire domain without copying http:// as well. (Please don't try to claim that there is no good use for this. This is a matter of generic interaction with other software which Chrome developers CANNOT predict.)
- Inconsistent, because https schemes are still shown.
- Becoming less relevant as usage of https on the web increases.
Potential improvements:
- Show the hidden components whenever the address bar has focus.
- Show the hidden components whenever the insertion cursor is on that edge and the user presses an arrow key to move out of bounds.
- Don't copy the hidden components if the user carefully selected the edge characters without moving the mouse out of bounds. (I have done this in vain out of frustration many times)
- Add a command line parameter, advanced option, or addon API to reveal the hidden components all the time or to apply the above fixes.

I have personally been using Chrome as my main browser for the entire lifetime of this feature and it has failed to grow on me in any way. I still experience the negative consequences of it regularly and have no use for any of the benefits of it. I was pleasantly surprised that you added a command line to opt out of the gigantic context menus that were recently added (and even fixed bugs with that setting). I searched up this issue again expecting for some sort of option to be available after all this time and this is rather disheartening.

Your team has clearly decided that the pros outweigh the cons but I don't understand why you're against any form of compromise with those that disagree. A lot of the people that don't fall into your "95%+" demographic are probably developers. Any developer that came here and read that statement probably does and should feel like a second-class citizen.

I need the http in all urls. Please provide that option somehow. In the meaintime I'm sticking with Firefox and others which make it possible.

I find it hilarious and annoying at Google saying, "We don't give a shit what you think, you're wrong and we're right and it's our browser, not yours anyway."

Opera for me it is.  Just because of this.

I used Firefox for many years to develop my web applications, and just recently switched to Chrome to see if the experience was better.

It's not. Because of this. Seriously. Show-stopper. GOOGLE SHOULD FIX THIS OR PROVIDE AN OPTION IN SETTINGS SO THOSE OF US WHO NEED IT CAN USE IT.

Back to Firefox...

We support a DOD facility and need the http:// or https:// protocol to display when adding sites to the GPO under 'URLs to open on startup' because we have an internal Intranet site.  This does not alloow us to force our users to start on our Intranet (security requirement).

I couldn't care any less about whether http:// is visible or not.
The 'fix' that adds the http:// when copying troubles me.

I get an unwanted http:// at least every day which serves me as a reminder that when I copy domains from the urlbar I should leave out the first character to cancel the effect and do an additional keypress before pasting.

Unfortunately Opera has this same issue these days. If Firefox wheren't so slow I would've thrown away my chrome.

Any of the improvements mentioned in reply #227 would be great.

Wow, After reading this I feel extremely naive...thinking a corporate entity gave a shit about its users.

Another +1 Me Too! to fall on deaf ears...

found this because AngularJS (another Google product) has an issue with this missing.

var SERVER_MATCH = /^([^:]+):\/\/(\w+:{0,1}\w*@)?(\{?[\w\.-]*\}?)(:([0-9]+))?(\/[^\?#]*)?(\?([^#]*))?(#(.*))?$/;

SERVER_MATCH.exec('localhost:9080/app') === null 

SERVER_MATCH.exec('http://localhost:9080/app') === array of matches

Typical Google: "We know what's good for you better than you do. And we know what you should want, because we are the wise and mighty Google." As other have posted, Mozilla Firefox made the same change a while back, but made it easy to change Firefox's behavior so that http, https, etc. can be seen in the address bar. I wonder if Google's technopimps remember AltaVista, AOL, Netscape, ad nauseam? You ARE replaceable.

Issue 295343 has been merged into this issue.

Google like to dictate the user experience (and not only that). So do yourself a favor and use firefox with option in about:config -> browser.urlbar.trimURLs: false;

Lacking the http:// in the URL display significantly reduces the browser usability for me. Like some others I constantly switch from http:// to https:// and back and being able to visually see that I'm on http:// is something I would like. And having it so have so that changing back and forth is as simple as possible. 

Issue 299401 has been merged into this issue.

With this change I now cannot see if I am on https or not! Not great when entering credit card details!! arghhh!!!

Fuck oiff and give me http:// back or at least the option to turn it on

Issue 310613 has been merged into this issue.

user experience is awful!

CAN NOT tell user to make sure he is on https

CAN NOT be sure of what I am copying into clipboard.

CAN NOT copy only the hostname. http/s will be added to the copied string.

This is KILLING me.  I can no longer copy/paste URLs in a way that they are treated as URLs.  On a personal level this kills my ability to share links on Facebook.  Whatever, that's just BS.  On a professional level this kills my ability to include hyperlinks with ease - I now need to jump through a bunch of f**king hoops to include Jira ticket links in my emails.    AAAAAAAAAAAAAAAAARGH bring the protocol back!  At least give us an option that will allow us to copy URLs with protocols!

Please, add option show http:// 

Status: 	WontFix is bull!  This should be an option to enable or disable hiding http

You know what's the worst part about it? Even if you specifically and manually select the whole URL (even the slow, laborious way), it will STILL insert the scheme at the front (and a trailing slash if the URL is a directory). In other words, it FORCES you to manually remove the scheme and slash no matter what; there is no way to copy the whole URL without getting the extra junk.

This is obviously very frustrating for countless scenarios and is reflected in the (literally) hundreds of duplicate bugs filed and thousands of angry comments.

Unfortunately the Google devs are tyrannical, fascists, egotists and don't allow anything that they did not think of themselves. The UI/UX team is clearly run by a bunch of people who have absolutely NO UI/UX skills or knowledge, and (as usual) Peter Kasting has already offensively put his foot down about not succumbing to user demand and listening to what user want, and instead telling user what they will get, like it or not.

Anyway, that this thread has not already been locked is an oversight (every single other discussion about this has been closed), and I'm sure that they will close it soon enough.

Also, the "WontFix" label is really offensive; it says "we're not going to bother with this bug report because it's not worth our time and you users are all idiot". I don't know what they don't change it to "Closed" or something less insulting.

Just thought I would ask when this bug will be fixed? It has been over three years and it is still just as annoying as when it was first brought up.

The only other time I have found that copying text results in something else being placed on the clipboard is those stupid sites that replace the second half of what you copied with "you can read more about this on blahblahblah.com", and we all know how bloody irritating that is.

This is yet another case of Chromium's "the user is wrong" attitude that makes me want to switch back to Firefox. Get it sorted out or expose an API so that an extension can fix this.

Please please bring the protocol BACK!!!!!!
I work in middleware, this drives me nuts!

And then if you only copy the DNS entry, tara, http gets carried along as well, hate it hate it hate it!!

Please

Why is this marked WontFix? It's really hard to tell if a URL is http or https.

I would really like to have an option to choose a protocool visibility...

it's really really bad user experience for developer who wants to copy the link and paste to the command line, trying with ping/host etc commands. I need to get rid of the scheme first every time.
And I don't think it would benefit for common users, what's the difference showing/hide the protocol scheme. I can't understand.

If there is no option to show http:// prefix, I will absolutely not use this browser. It is disabled by default in Firefox but they give users the ability to display it.  The choice needs to be up to the user, not the developer.  If google chooses to disable the feature without recourse to the user, the user has the recourse to use another browser.  Sorry to put it in these terms but the Google team is being myopic on this.

Please add option to show/hide protocol.

Please add option to not trim url.
http:// clearly separates an url from a search-string, and since chrome combines these two usecases in one field, removing http:// effectively makes chrome interpret urls as search-strings, which in turn makes chrome show a useless search-result rather than the desired web-page.

I, too, would like the protocol to be displayed.  There are more than http: and https:.  There are, for example, rmtp: and ftp:, both of which need to be there when I copy a url.

I really can't understand the rationalle of hiding this from the user, any more than I understand why some browsers now hide the page part of the url either.  Show us the whole address, please, and let us cut-n-paste it properly!

I find this intensely irritating.

I really dislike this feature.  Often I want to switch between http and https, or switch between the same http url on two different servers.  Can we have a configurable option for this?  It's very annoying.

If you leave the feature in place, lack of a protocol should be treated as an implied http://.  For example if I visit http://server1/mypage, it becomes server1/mypage.  When I want to change it from server1/mypage to server2/mypage, I need to re-add the http:// as well as changing server name.

I'm stopping use of Chrome due to the "http://" scheme masking.   Intranet URLs get gobbled up too frequently by Chrome's interpretation of the URL as a search term.    

In the case of "http://srvr1.intranet.mycompany.com/application", "srvr1/application" seems like a one-time case to solve (after the first time, it will be populated at the top of your history in the omnibox drop down).  Unfortunately, in the modern world of IaaS (with dynamically provisioned domain names), using Chrome will quickly become nightmarish.

See:
"srvrUAT1" .. "srvrUAT205" * [UAT|INT|QA|STG|..]

Perhaps an option to preempt the search with a quick intranet DNS host match pass/fail would suffice?

I think this is about to make me move to firefox. Add an option to allow us to choose.

I don't mind the non visibility of the scheme, but I hate that I cannot chose to see it if I prefer, and when copy/paste prepends the scheme and appends a trailing / at the end. I know for the vast majority of users this may not be an issue, but as a developer, is very annoying. 
It should be an option to display the entire URL with SCHEME included and if that is enabled, when you are copying the address, you should get JUST what you are copying.

The copying of HTTP:// regardless of weather you select it or not is poor (and unexpected) behaviour and should be reverted or at least an option created to disable it.

"Me too". Very annoying that http is included when you want to copy just the domain and use in e.g., ping/ssh/traceroute or, as in my most common case, I subaddress using the domain name (myaddress+code.google.com@tld.com).

This is just an annoying top-down-decsision - I *like* seeing what protocol my browser is currently using. Please bring back an option to have this switched back on.

It's even worse in current beta, the only thing the url bar shows is the domain. If you click the address bar, it presents an empty box. took me a while to figure out that you have to click on the domain to get the url. Also worth noting that keyboard nav only presents an empty box, this has now become an accessibility issue.

Using Version 35.0.1916.86 beta-m
URL is now gone for me. I have to click the domain to see it.
How can i toggle this back on?
Surely someone didn't decide to hide it and not allow users to toggle it back on.

Figured out the option to at least get the url back. Still no http:// but better than nothing. go to chrome://flags and make sure "Enable origin chip in Omnibox" is disabled.

#267 not possible on Linux and now (35.x) copying URL doesn't even copy/add protocol, so I end up with broken URL in clipboard. Have to add protocol manually.

Ugly bug :(

But there are people that doesn't use CTRL-C/V at all - and I'm one of them, I have more convenient methods. Now URLs are copied without http:// and this is irritating.

Agreed, please do not hide the protocol (or at least provide some means of disabling this "feature").

"Enable origin chip" flag is not available on linux and this feature completely breaks copy&pasting URLs. Horrible.

<a href="https://i-m.ch/"> Web hosting </a> Web Hosting offers you a domain name, unlimited web hosting space, ecommerce web hosting, design  tools to create a web site easily at a reasonable

Hello. I don't usually use Chromium or Google Chrome, primarily because of the removal of the "http://" scheme from the URI in the "omnibox". I happened upon this discussion because I was using Chromium for testing (since it is not my preferred web browser). It's been four years since the URI scheme was dropped, and it still looks ugly as sin. I agree that it encourages bad user behavior, which no one needs more of. It would be nice to have an option to revert the change (e.g. "browser.urlbar.trimURLs" in Firefox). I read through the first half of the discussion here, which is most disappointing. If you make UI, you must consider the user. If the user tells you it's bad, then why vehemently refuse to even offer an option to revert it? That's a bad way to interface with users. And, really, it's such a simple request, isn't it? And others have even asked nicely by typing "please". I'll ask in kind: Chromium developers, please revert the hidden URI scheme (http://) or provide an option to show it. Thanks! =)

In some occasions I need to switch between http and https, and it is really painful to have to type the whole https:// all the time when I could just type an 's' if http:// where shown all the time.

Please, put an option on the configuration menu to let the user decide whether the http:// will be shown or not!

C'mon, we're not asking you to launch a Rocket to Mars, it just a flag on the menu.

This is an urgent issue, most annoying to developers. Please fix asap. Add an option or something. Don't make it compulsory....

I know what I want and I don't want to copy what I don't see, it messes with my head!
I'm really disappointed I'm not able to find a flag to switch this option off.
I'll make my own fork of Chromium, with a flag to turn that off, and with blackjack and hookers!

They obviously have a hard time listening to users, and keep merging other issues into this WONTFIX one. Try creating a new feature request to add an option, and see if it gets their attention.

Guys this "feature" of trimming the URL sucks .... I am getting seriously seriously fed up of cutting and pasting urls into terminal to ping them and finding an http:// stuck in when I didn't copy it from the address bar.

If no-one provides a feature to allow us to disable this annoying behaviour then I think it might be about time someone forked Chrome and starts paying attention to the requests.

I can't believe 4 years have gone by and this f***g feature still hasn't been fixed properly :(

This is a serious problem. I need to know the full URL to verify security. This is not optional. This is not a feature. This is a security problem.

I really don't want to have to use another browser. This modification of URL's and the associated problem of trying to search instead of going to a URL is a deal killer on me using Chrome, but I HATE the alternatives.

Wontfix? Oke then NOCHROME on my devices!

+1 to give an option to turn this 'feature' on/off. It is really starting to annoy me having to go back and delete the "http://" from stuff I am copying out of the address bar.

"Show protocol in address" in prefs would solve for all. Day to day, doing traceroute, ping, whois is really frustrating with this "feature" of Chrome, sneaking http:// into my clipboard.

+1 this http:// issue is getting annoying.

I have the same issue as most folks here, a domain is not an URI and I've been dealing with this for years manually removing http after pasting, not cool

Issue 440780 has been merged into this issue.