

Two examples of bad user experience caused by HTTP prefix being hidden in Chrome - augustl
http://code.google.com/p/chromium/issues/detail?id=60528

======
citricsquid
I repeatedly posted about this being terrible on reddit, I was repeatedly told
to stop bitching.

It's a pain, surely this is something that you don't do, the user highlights
"foo.com" and is instead given "<http://foo.com>. It's as bad as the sites
that use Javascript to inject "read more @ <http://bar.com..>.

It wouldn't be so bad if it was optional, but don't expect that of Chrome, oh
no.

It also leads to an inconsistent experience, I'll quote myself: "If the URL
you're using is <http://website.com> and you copy website.com, you get
<http://website.com>, but if the URL you're using is <https://website.com> and
you copy website.com, you get website.com. It not only messes with copying by
changing what you copied into what it thinks you want, it's inconsistent with
that guessing."

~~~
elblanco
selecting text in the addressbar should cause it to switch modes to reveal the
full URL for the user to select.

~~~
BerislavLopac
It doesn't.

~~~
elblanco
I was saying "should" as in "it'd be nice if it did".

But in retrospect I see why that was confusing.

------
sirn
I don't understand why Chrome don't implement something similar to
LocationBar2[1]. It expands to include the protocol when URL bar is focused,
and hides the protocol on unfocus. It also tries to make sure text width never
changes when protocol is hidden by center-aligned the domain part, e.g.

    
    
        URL: http://news.ycombinator.com/item?id=1829087
    

When protocol is hidden, will be displayed as:

    
    
        URL:     news.ycombinator.com   /item?id=1829087
    

[1]: <https://addons.mozilla.org/en-US/firefox/addon/4014/>

~~~
citricsquid
The fact that they don't lends weight to the spdy _conspiracy_ theory (can it
be called that that?)

~~~
al_james
I think its more likely that they realise most people don't understand what
the http/https bit is all about, so its much simpler if you ignore it
altogether.

I honestly think http/https should beside the point. Websites should
transparently redirect to https if they need to (so the padlock appears), but
there is no need to signal this to the user with some cryptic techno-gabble.

~~~
drivingmenuts
Shoulda, coulda, woulda ...

The web largely of sites that could do things better, but don't. We have to
work around that, because you and everyone else here knows in the deepest pits
of our little black hearts that these sites won't be fixed.

~~~
al_james
I should imagine google, having access to a 'quite' large web index, would
know if hiding the http/https would break the Internet for the majority of web
users. I am guessing this actually only happens in a very few edge cases, and
those edge cases should fix their sites, not hold back development for
everybody else!

------
paol
I find Chrome full of little annoyances like this. I tried to move to it
because of the huge speed advantage over firefox but gave up pretty quickly.

I understand - and generally approve - the drive towards simplicity, but
things should be made as simple as possible, and no simpler. (With apologies
to Einstein.) Chrome crosses that line in several ways which ends up causing
more confusion than it solves.

~~~
sigzero
Chrome on the Mac is still lacking. In Safari if I right click and copy an
image I can paste that directly in Mail. Using Chrome I get a broken image
icon.

------
stfp
I find it kind of silly to be hiding protocols in URLs, while, at the same
time, sites are adding the ugly-ass #! shebang ajax crawlability thing[1],
right in the middle of URLS - a scheme brought to you by ... google :p

[1] see [http://code.google.com/web/ajaxcrawling/docs/getting-
started...](http://code.google.com/web/ajaxcrawling/docs/getting-started.html)

------
yock
I want to know why your server is listening on port 80 only to kick out 404
pages. If you require SSL for all traffic, then you really only have two
logical choices, either only listen on 443 or redirect from 80 to 443.

Now, if you only use https for authentication, not redirecting to the SSL-
enabled url is a far, far greater transgression against UX than hiding the
protocol in the address bar.

Simply put, this seems like a nitpick rarely exposed outside of corner cases
and other UX mistakes.

~~~
jancona
Saying that the solution is for server admins to do something misses the
point. Even if you're right, as a user I have no way to get a random server's
config changed. Therefore I want the option to configure my client so that I
don't run into the issue.

~~~
abraham
If your client does not do what you want use a different client. Or you can
run Chromium and add whatever features you want.

------
rwolf
It's amazing how many people jumped into the comments section to say "I agree"
or "I disagree." Whenever the Chrome devs get up this morning and check their
tracker, I imagine they will be very annoyed.

~~~
mkr-hn
I clicked the little star to register support, and now I'm getting every "I
agree" post in my inbox. Very annoying.

------
bambax
Not directly related (but not totally unrelated), try to search for "PDF/A" in
the "ominous bar" => error.

What you're looking for:

<http://en.wikipedia.org/wiki/PDF/A>

What you get:

 _This webpage is not available. The webpage at<http://pdf/a> might be
temporarily down or it may have moved permanently to a new web address._

The reason for this, is probably that anything with a slash in it has to be
interpreted as a url, since there is no protocol left to make the difference
between a web address and a search...

~~~
redthrowaway
That seems like a pretty easy fix. Just ensure that you have a .something
somewhere in the address, before the first slash.

~~~
bambax
Maybe my post wasn't completely clear: I want to _search_ for PDF/A, and
actually the expected result is the Google result page for this search, ie:

<http://www.google.fr/search?q=pdf/a>

What I get instead is an error because Chrome tries to access the non-existent
web page <http://PDF/a>

~~~
redthrowaway
Sorry, no, it was my post that wasn't clear. That should be easy behaviour for
Google to code for. The current implementation seems buggy; at least the fix
wouldn't be difficult.

------
shrikant
Why this sudden outrage? This has been the case ever since Google Chrome took
the step of obscuring the HTTP protocol scheme way back in April 2010, and
been mentioned way back then as well.

See: <http://code.google.com/p/chromium/issues/detail?id=41467#c19> for a
developer's comment where he explains the 'feature'.

This seems to be a case of reporting an existing 'feature' (however much you
may dislike it) as a bug.

~~~
augustl
Because from what I've seen, the Chrome devs appreciate concrete use cases.
I've seen little of those, and many "plz fix it suxx!!!" posts, so I thought
I'd contribute some, well, concrete use cases.

------
plaes
Hehe.. check out the subtle tabs on the images posted in comment #36.

------
al_james
If you have a website that respondes to HTTPS traffic and not HTTP traffic,
and you are targeting everyday Internet users, you don't deserve traffic!

Most people dont understand the difference between the cryptic labels HTTP and
HTTPS. Why should they? Why force users to become experts in Internet
protocols to use the Internet?

~~~
augustl
I'm not targeting everyday internet users. As I mention in the ticket, it's
our internal servers.

Hiding the label makes sense, but the way it's solved in Google Chrome has
some trade-offs that some (which according to the number of tickets on the
issue is more than just a few) people may not be willing to live with.

<https://addons.mozilla.org/en-US/firefox/addon/4014/> \- sirn mentioned this
Firefox addon in a comment, looks like a good solution.

I'd also say the iOS-like animation I propose in the ticket makes more sense.

------
nlawalker
I still haven't seen a good reason for hiding it in the first place.

------
bruceboughton
These are poor counter-examples.

~~~
al_james
I honestly think the first example is a feature not a problem (its a good
thing!) and the second is an edge case that will never happen to the vast
majority of web users.

Whereas hiding the http/https prefix simplifies the web browsing experience
for the vast majority of web users. Worth keeping!

------
konad
concur, hiding the http is annoying to me

