Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome hides www and https:// in the address bar again

bleepingcomputer.com

Post reply on HN
Print view View original

171–180 of 194 posts

Re: Chrome hides www and https:// in the address bar again

#171

Post by eridius »

Veedrac wrote: post #163
eridius wrote: post #136

I don't understand why you have to click twice to show this info. That's just bizarre.

Simple UX: don't move things around more than necessary. I honestly don't understand why people think this second click is unreasonable; the power-user shortcut (ctrl-l) already expands immediately anyway.

It's unreasonable because it violates user expectations. One click already makes the field editable and selects the text, having a second click change the text has no precedent whatsoever. It's also confusing because this means that clicking to position the insertion point suddenly moves the text out from under where you clicked (thankfully it does still place the insertion point at the right location, but that location is no longer where you're looking and pointing).

There's also just no reason for this. It's unnecessary overhead to showing the full URL and there's no benefit.

Re: Chrome hides www and https:// in the address bar again

#172

Post by NikkiA »

e12e wrote: post #104
jorvi wrote: post #81

Earlier quoted context omitted.

Its hostile for power users but it prevents grandpa from renaming 'IMG_144.jpg' to 'Idaho_grandkids', hammering enter on the 'are you sure you want this' nag screen and then wondering what broke his picture.

Does Mac still have resource forks? Either way, I'm sure it still has decent magic number decoding. Who (except family members in windows?) would care about the missing extensions? The only real reason i care is for vim file detection (in Linux). How sad is that? :'(

Even NTFS supports resource forks, noone uses it for anything though.

Re: Chrome hides www and https:// in the address bar again

#173

Post by Jaruzel »

sjs382 wrote: post #48
zzo38computer wrote: post #43

Earlier quoted context omitted.

And, there is a setting to tell it to not do that, but even then, for some files it is hidden anyways. But, it is possible to use regedit to change it so that the extensions are not hidden even for those cases.

Editing Chrome flags is similar to editing the Windows registry. Here are the relevant settings: chrome://flags/#omnibox-ui-hide-steady-state-url-scheme chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref

Until they take those away. The Chrome devs have an annoying habit of removing flag options once they consider the 'feature' to be out of beta.

Re: Chrome hides www and https:// in the address bar again

#174

Post by Veedrac »

eridius wrote: post #171
Veedrac wrote: post #163

Earlier quoted context omitted.

Simple UX: don't move things around more than necessary. I honestly don't understand why people think this second click is unreasonable; the power-user shortcut (ctrl-l) already expands immediately anyway.

It's unreasonable because it violates user expectations. One click already makes the field editable and selects the text, having a second click change the text has no precedent whatsoever. It's also confusing because this means that clicking to position the insertion point suddenly moves the text out from under where you clicked (thankfully it does still place the insertion point at the right location, but that locat…

The point is that the most common thing people do when clicking the URL is typing something else in the search bar, and the second most is copying the URL. In both cases, having the URL change is a problem, because this includes people who don't know what the http:// means or what a subdomain is, and don't immediately understand when a URL is the same as another. Your extra click saves my mother, and millions like her, much more confusion than the click costs you.

You probably mostly know technically fluent people, and think ‘my mother’ is a euphemism, but it's not. If we can get to a world where she can see an unfakeable padlock and read ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.’ in the URL bar, and which parts of the string of letters to skip, we've made her life less hostile.

The corresponding problem you're complaining about is incredibly trivial in comparison. If you're actually editing the URL, you see the whole URL. If you need to know these implementation details, they're vastly easier to find than, say, HTTP headers.

Re: Chrome hides www and https:// in the address bar again

#175

Post by cm2187 »

NikkiA wrote: post #169
cm2187 wrote: post #141

Earlier quoted context omitted.

Or more generally the header should contain the metadata of the file: date modified, filetype, comments, icon, etc, rather than spreading that between the filesystem (with different filesystems having inconsistent dates), the OS, etc.

I disagree, locality data such as ownership, modified date, comments, permissions even, should not be part of the file, it breaks things like repeatable builds, version control and anything where the contents of the file are considered static. shadow files (._*) and directory clutter (.DS_Store/desktop.ini) are one solution, but they're ugly and frustrating, having separate areas in the filestore (like a resource for…

I don't think it breaks anything. If the world had gone this way, all the functions you use to read a file would read the data from the first byte after the header.

Re: Chrome hides www and https:// in the address bar again

#176

Post by NikkiA »

cm2187 wrote: post #175
NikkiA wrote: post #169

Earlier quoted context omitted.

I disagree, locality data such as ownership, modified date, comments, permissions even, should not be part of the file, it breaks things like repeatable builds, version control and anything where the contents of the file are considered static. shadow files (._*) and directory clutter (.DS_Store/desktop.ini) are one solution, but they're ugly and frustrating, having separate areas in the filestore (like a resource for…

I don't think it breaks anything. If the world had gone this way, all the functions you use to read a file would read the data from the first byte after the header.

In that situation the metadata is no longer part of the 'file' then, and would be lost by a 3rd party copy function unless extra API functions are used to copy the metadata.

At this point, it might as well be a "resource fork" or whatever you want to call your secondary file contents at the fs layer shrug

Re: Chrome hides www and https:// in the address bar again

#178

Post by eridius »

Veedrac wrote: post #174
eridius wrote: post #171

Earlier quoted context omitted.

It's unreasonable because it violates user expectations. One click already makes the field editable and selects the text, having a second click change the text has no precedent whatsoever. It's also confusing because this means that clicking to position the insertion point suddenly moves the text out from under where you clicked (thankfully it does still place the insertion point at the right location, but that locat…

The point is that the most common thing people do when clicking the URL is typing something else in the search bar, and the second most is copying the URL. In both cases, having the URL change is a problem, because this includes people who don't know what the http:// means or what a subdomain is, and don't immediately understand when a URL is the same as another. Your extra click saves my mother, and millions like he…

If you type something in the bar it doesn't matter what it shows.

If you copy the URL, the fact that what you copy is literally different than what you're looking at is confusing. You copied "example.com", so why does the clipboard now contain "http://www.example.com/"?

> If we can get to a world where she can see an unfakeable padlock and read ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.’ in the URL bar, and which parts of the string of letters to skip, we've made her life less hostile.

Whether the URL bar shows "https" or a padlock has nothing at all to do with the unnecessary confusion inherent in Chrome requiring a second click on the URL bar to reveal the full URL.

Nothing in your comment even begins to explain the benefit in presenting a fully-editable text field that allegedly shows the URL, except it's still hiding information that is only revealed once you try and perform another text editing action. If someone looks at the URL bar and sees "example.com", and they click on it and it immediately turns into "https://www.example.com", that doesn't harm them in any way. In fact, that's exactly how mobile browsers such as iOS Safari have worked for years and nobody's complained. Chrome is deliberately doing something different than all precedent and there's no obvious reason for this beyond their desire to be unique.

Re: Chrome hides www and https:// in the address bar again

#179

Post by floriferous »

cpeterso wrote: post #102
RobertRoberts wrote: post #84

This is a giant AMP scam. The next change will be that it will trick users into thinking they are on are on a real site like example.com but will instead be on Google.com/example.com. But chrome will remove google.com just like http/s.

Chrome on Android already hides the "google.com/amp" URL prefix for AMP URLs: https://blog.amp.dev/2018/01/09/improving-urls-for-amp-pages...

How scammy is this?!

Re: Chrome hides www and https:// in the address bar again

#180

Post by anthony_doan »

munk-a wrote: post #132
cpeterso wrote: post #97

Earlier quoted context omitted.

Firefox hides the http:// scheme in the address bar, but will include it if you copy the URL. You can test with http://example.com/ and https://example.com/ .

Nice! Though it'd be good if they swapped the scenario where they hide the protocol to be `https` and make `http` the one that sticks out awkwardly.

I mean they have the lock icon for https.

If you want it to stick out awkwardly I feel like they just need a opened lock in red icon.

Post reply on HN