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

Chrome breaks the Web

tonsky.me

Post reply on HN
Print view View original

161–170 of 473 posts

Re: Chrome breaks the Web

#161

Post by Manishearth »

andybak wrote: post #33
KeitIG wrote: post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

Isn't this a reaction to moronic use of autocomplete=off in a user-hostile way by various websites? In a similar vein to how abuses of disabling the back button, popups etc have led to defensive measures by browser vendors.

I'm one of the folks who pushed for autocomplete=off to be disabled for password fields because of abuse. Basically, browsers obeyed autocomplete=off to shut off password managers; and sites used this to shut off password managers for "idk lol security" reasons.

This isn't what the autocomplete attribute was for in the first place; password managers have a different workflow and saving a password is prompted to the user, so we removed it. Password managers are not autocomplete features, basically.

Disabling autocomplete=off on everything doesn't seem to be a good change. Would love to be proven wrong but I don't think there are any ways autocomplete=off can be abused besides the password manager thing, and it's not worked on password managers for years.

Re: Chrome breaks the Web

#162

Post by sterlingfs »

saas_co_de wrote: post #84
KeitIG wrote: post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

> does assumption on how things "should" be (in a highly subjective way) They claim they are making these decisions based on user data which I have no reason to doubt. > and breaks the web. Breaks crap websites that are broken already from performance and usability perspective. I personally think this is exactly what is needed to make the web better as a whole. Individual developers working for individual companies a…

I think many will see this as a type of tyranny, and therefore will be worried about the future implications of yielding authority to a single monolith.

Re: Chrome breaks the Web

#163

Post by virgilp »

mcv wrote: post #70
biotech wrote: post #58

Earlier quoted context omitted.

> How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions The difference is that disabling of "autocomplete" is a user interface issue, and can be addressed by the browser I use. The problem of ridiculous password restrictions is not usually something that can be controlled by the client. I like the idea of convincing IT to change crazy password policies, but…

I'm all for allowing the user to control whether autocomplete is or isn't respected. But the browser breaking web standards to force certain choices on the user is about the worst possible way to go about this.

Aren't cookies a web standard? I can assure you that Safari's policies w.r.t. cookies "break" a lot of website functionality, and quite intentionally so. You may not like that functionality, but the website marketers like it and have spent lots of time implementing it.

So - what's ok to break, and what isn't? In the end, it's a judgement call on the browser developer. I like what another person said here - the browser is an "user agent", as long as the actions are clearly motivated by user interest, I think they're ok even if/when they break some standards.

Re: Chrome breaks the Web

#164

Post by bluGill »

linza wrote: post #112
bluGill wrote: post #89

Earlier quoted context omitted.

You don't necessarily have to convince IT. If you instead convince their legal department that by not following the NIST standards for passwords they are opening their company to a lawsuit, that could get results a lot faster. When IT is convinced they have to decide when to put it into the budget. If they think their policy is not okay, just not perfect the fix will probably be buried in the bottom of the budget pil…

Not all websites are operated by US companies. Would that still work for, say UBS (a big bank) in Switzerland?

Maybe, does UBS have a branch in the US that you can sue? Alternatively, does the country you are in treat foreign standards as admissible in their court in some form? Does the country have their own version of NIST that is willing to "leverage" the work of another country into their own standards, thus making the NIST standard a national standard for their country? Does the country have their own version of NIST that has already issued a standard? Any of the above are angles to consider before you reject legal approaches to the problem just because the country doens't apply.

Your question is one of the reasons I didn't say the legal route was a better way. It is an option that may get better results in some cases. Even in the US it may not always get the best result.

Re: Chrome breaks the Web

#165

Post by ksk »

Klathmon wrote: post #153
ksk wrote: post #135

Earlier quoted context omitted.

But how does this apply to the majority of users as you suggest? As a user, I'd like the website to keep working. I don't agree with simply breaking working websites via a top-down dictatorial approach.

Because in my personal case a majority of users would take smoother scrolling over a small UI bug that doesn't impact the usability of the application which is fixable in a few hours at most. Because any websites that need this "blocking events" functionality can opt-in to it quite easily. Because as I explained in my first comment, the breakages didn't affect that many websites, and the sites it did affect were most…

Sorry, I am not convinced with your arguments. Anyway, have a nice day.

Re: Chrome breaks the Web

#166

Post by tomjen3 »

KeitIG wrote: post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

I am going to have to disagree there - I think putting autocomplete control in the standard was an error, just as a webdev shouldn't be able to not accept copy and paste. That is inherently a user choice.

Re: Chrome breaks the Web

#167

Post by ko27 »

francasso wrote: post #152

Jesus Christ, to think there are people in this thread defending what the assholes in the Chrome team did is unbelievable. You make breaking changes opt-in, that is API design 101. Linus should take over Chrome development.

Stop being so dramatic. Valuing users over developers is not malice, it's common sense.

Re: Chrome breaks the Web

#168

Post by TFortunato »

staticassertion wrote: post #113
FussyZeus wrote: post #99

Earlier quoted context omitted.

So aside of the fact that you agree with their decisions, how is this at all different from how Internet Explorer's dev team made arbitrary decisions on how things would work in their browser, and in so doing because of their market dominance, influenced how the web grew, looked and functioned for decades to come? And how much technical debt had to be tacked onto every project to address that need (and is to this day…

It's not really comparable to IE. MS had a pretty explicit goal of destroying Netscape - to the extent that they were making deals with other companies to break compat with Netscape. Chrome is breaking 'autofill=false' on webforms because its really bad to have autofill=false most of the time . For example, this was breaking password managers, forcing users to have a worse experience around something as security crit…

Was it breaking password managers? Because from what I understand, that isn't the case, and the bug linked earlier is specifically titled "autocomplete=off is ignored on non-login INPUT elements"

Also: "For most modern browsers (including Firefox 38+, Google Chrome 34+, IE 11+) setting the autocomplete attribute will not prevent a browser's password manager from asking the user if they want to store login fields (username and password), if the user permits the storage the browser will autofill the login the next time the user visits the page. See The autocomplete attribute and login fields."

(From: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Fo...)

Re: Chrome breaks the Web

#169

Post by reificator »

lallysingh wrote: post #77
reificator wrote: post #28

Earlier quoted context omitted.

1. Because every browser pretends to be each other and so the UA is worthless: https://webaim.org/blog/user-agent-string-history/ 2. Because you're not going to update your detection every time a new version comes out, meaning that new browsers that support the features you need are still going to get served the wrong version of your site. 3. Because there are more browsers than you can count. 4. Because for non-synt…

For 1, 2, and 3: I figure you just need to parse the UA string to get the actual browser and version number, then have a variant for before and after a given threshold number. You're only doing this for the number of variants of code you want to run/maintain, so this isn't some sort of combinatorial explosion. It's just another method of dispatch instead of runtime checks inside JS. At worst you put the runtime check…

Browser sniffing falls in the same category as time, crypto, and string encoding for me. If you think it's easy, you haven't spent enough time thinking about it.

Re: Chrome breaks the Web

#170

Post by tomjen3 »

pluma wrote: post #50
Spivak wrote: post #35

Earlier quoted context omitted.

The problem is that some sites decided to use autocomplete=off to impose their feeling about password managers on users and make them more difficult to use. It's the same reason I have to turn off clipboard events because some sites think it's okay to block copy/paste.

How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)? The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX b…

>The right thing to do is to bring the issue up with whoever is running the website

What? No. Clearly it should never have been in the spec, and a browser should be the extension of the users desires.

Post reply on HN