Two examples of bad user experience caused by HTTP prefix being hidden in Chrome | Hacker News Reader

Two examples of bad user experience caused by HTTP prefix being hidden in Chrome

code.google.com

64 pointsaugustl47 comments

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."

Let's hope my issue helps. I wrote it as to-the-point as I could, with no bitching and hopefully well reasoned arguments.

They're obviously tired of people claiming suckage without explaining why they think it sucks, and probably tired of even hearing about the issue in general. They've merged LOTS of dupes into http://code.google.com/p/chromium/issues/detail?id=41467

It's as bad as the sites that use Javascript to inject read more @ bar.com...

No it isn't don't be ridiculous

uh, yes it is. It causes the same level of annoyance and has the same solution.

Load up Chrome and go to http://hackerne.ws, copy "hackerne.ws" from the address bar (all that displays) and you clipboard contains "http://hackerne.ws, to only get "hackerne.ws" in your clipboard you must paste somewhere else and remove the http://

Load up dailymail.co.uk and select an article, highlight a portion and copy it. Now your clipboard contains your selection + "Read more at...", now you must paste it somewhere else and remove "Read more at..." if you want your selection.

Both cases can be argued it's "for the user": The Chrome example, "oh well obviously the user wants to have http:// there!" and in the dailymail example "Well obviously if they're sharing that part of the article a link to the full article would be good!". Both examples cause the same problem and have the solution, therefore they are comparable.

I think he was being ironic (look at how it was quoted: @bar.com and not @http://bar.com)

> Load up dailymail.co.uk

There was your first mistake

sfgate.com does it also. No political affiliation is safe!

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

It doesn't.

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

But in retrospect I see why that was confusing.

So what happens if you select only part of the URL? What if you just want to select foo.com?

What I have to do is to leave copying the first letter if I only want to copy the domain name. For example, example.com, I'll just highlight xample.com. It sucks, but it's a sliver quicker than having to delete http://

I'm glad that at least 24 people agree with you; I thought I was the only person who had an issue with the way Chrome treats URLs in the Omni bar. I wish there was an option that lets you choose.

I may write a Google Chrome extension for this (but how many people would really want an extension just for this problem?)

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/

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

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.

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.

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!

Websites should transparently redirect to https if they need to

From a UX point of view, definitely. But from a security point of view, this isn't good.

Really? Why? Users should rely on the browser indicating a secure site via a padlock or some other indicator. I would imagine most real users would not know the difference between http and https to asking them to base their security decision on that is misguided.

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.

I've found the simplicity of Chrome to be great. Mainly I'm bugged by how it just doesn't quite get flash right on OSX. Still, I've tried the latest FF and Opera releases, and I can't get over the extra toolbar real estate. Chrome just plain looks nicer, which, in combination with its other great features, solidifies its spot as my browser of choice. I just wish they'd fix the bugs.

Agreed. Have you tried the latest nightlies of Firefox 4? They're much closer to what I imagined browsing would be like today, ten years ago, than Chrome is (Firefox has new features like Panorama, and is as hackable as ever. Chrome has... the http prefix hidden? Seriously?). Ever since I started using Panorama, my productivity has shot through the roof.

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.

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...

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.

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.

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

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.

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

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...

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

Sorry, but at least http://localhost/ disagrees. Also, remember about hosts file and NetBIOS names.

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

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.

Add a question mark or use Ctrl+K for a search. Both the below work.

    Ctrl+K pdf/a Enter
    Ctrl+L ?pdf/a Enter

I'm sure I'll remember that the next time I need to search on a phrase containing a slash.

Yep, this has happened to me. Sometimes I miss my separate search bar.

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.

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.

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

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?

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.

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

These are poor counter-examples.

If you're referring to my examples, I'd love to hear some arguments :)

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!

concur, hiding the http is annoying to me

Reply on news.ycombinator.com