Live data from Hacker News

Chrome breaks the Web

tonsky.me

301–310 of 473 posts

Re: Chrome breaks the Web

#301
post #67

Earlier quoted context omitted.

So the question becomes what's less bad: for website developers to break their own site, or for Chrome to break other people's site. I'm all for empowering browsers to override abusive behaviour from websites, but using bad defaults and breaking innocent websites as a result is not the solution.

Chrome is a program that I run on my computer. It protects my interests, not the interests of random crappy website developers doing horrible things like hijacking clipboard events. I'm all for the defaults being whatever is best for me. The browser is the agent of the user.

>Chrome is a program that I run on my computer. It protects my interests, not the interests of random crappy website developers doing horrible things like hijacking clipboard events. I'm all for the defaults being whatever is best for me.

>The browser is the agent of the user.

Here I support you, but do you remember that Googlers pressed assertively for hijackable right click, no opt-out history spoofing, and many many many other supremely user hostile features in W3C standards.

Out of all broken web novelties, they prefer to unilaterally break ones coming from outside:

Declarative right click menu from Mozilla was killed by Chrome.

Declarative SMIL animations, same story

They added support for HTTP pipelining and killed it just to force people to migrate to their protocol

They had working drag and drop on mobile, yet they killed it because "iphone's dnd is broken, so we made ours broke too"

They banned few people from bugzilla from insisting on turning off vibrator API from mobile Chrome, yet the moment people started using it for bot detection, they killed it in iframes (denying its use as a hard proof of clickfraud for ad companies)

I always told clients that if you have to choose in between having feature A broken on iphone or having it broken every other browser, to chose to break iPhone. Now, I don't know what is right to say there, probably something like "you need to settle on a variant where stuff is broken in a consistent manner across all browser"

Re: Chrome breaks the Web

#302
post #277

Earlier quoted context omitted.

> The church down your street was extremely unlikely to even be impacted by this change Why do you say that? Let's say, for example, that they use Discourse [1] to provide a web forum for churchgoers on their website. Oops! Mobile scrolling is completely broken for them [2] until they manage to update Discourse to the latest version. Is this the flu shot you were talking about? [1] https://www.discourse.org/ [2] http…

No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken. And while they would need to update, if they were using the hosted discourse plan it would have been fixed for them, and if they were using the self-hosted plan, they are running that on a linux server which needs updates and maintenance periodically anyway or a broken timeline will be the least of their problems. Luckil…

> No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken.

So, mobile scrolling is broken, but not all the time. Is that really the distinction you want to make right now? For the individual who said "[c]omplaints from my users are starting to come in", is that an adequate response?

> Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI.

Please do tell that to the parishioner whose son set up the website a year ago before he left to go to college. We all agree that software upgrades are important for security, but that doesn't justify imposing an additional artificial upgrade burden due to a backwards-incompatible breakage to the web.

Re: Chrome breaks the Web

#303

Earlier quoted context omitted.

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

Woah woah woah. Let me recount/nutshell the crux of conversations I've had with my product manager(s) about things like this. Me: Hey, I'd like to add a work-item to our current sprint that reworks semantic attributes into our site. Them: What would that do? Me: It improves the underlying architecture making the markup more usable and extensible. Them: How does that benefit the users? Me: Over time it will reduce the…

> It's a struggle to improve what doesn't directly add to the bottom line.

That's exactly the point and you're essentially nitpicking (with anecdata) the fact that he pinned the problem on developers instead of product managers. Regardless of who is making the decision in companies, the end result is pretty much the same.

Re: Chrome breaks the Web

#304
post #300

Earlier quoted context omitted.

Chrome is a program that I run on my computer. It protects my interests, not the interests of random crappy website developers doing horrible things like hijacking clipboard events. I'm all for the defaults being whatever is best for me. The browser is the agent of the user.

How is breaking websites good for the user?

Adblock is "breaking websites". If a website is doing something crappy, I'd prefer to not have that crappy thing happen than experience the developer's true intent.

Re: Chrome breaks the Web

#305
post #33

Earlier quoted context omitted.

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 u…

> "idk lol security" reasons.

I hereby confess to being guilty of adding autocomplete="off" to a login form, because the client's corporate IT only cared about ticking all the boxes on a security conformance report. We have tried to fight this and some other rules (e.g. log the user out after 20mins), because this was quite a simple website, but the rules were strict like it was online banking at the very least.

Now OWASP has changed their mind, but the damage has been done.

> Since early 2014 most major browsers will override any use of autocomplete="off" with regards to password forms and as a result previous checks for this are not required and recommendations should not commonly be given for disabling this feature. [1]

https://www.owasp.org/index.php/Testing_for_Vulnerable_Remem...

Re: Chrome breaks the Web

#306
post #61
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.

Password managers use browsers plugins, and as such can modify pages before they render as much as they like.

I usually use Chrome and Firefox's built-in password managers.

Re: Chrome breaks the Web

#307
post #302

Earlier quoted context omitted.

No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken. And while they would need to update, if they were using the hosted discourse plan it would have been fixed for them, and if they were using the self-hosted plan, they are running that on a linux server which needs updates and maintenance periodically anyway or a broken timeline will be the least of their problems. Luckil…

> No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken. So, mobile scrolling is broken, but not all the time. Is that really the distinction you want to make right now? For the individual who said "[c]omplaints from my users are starting to come in", is that an adequate response? > Luckily Discourse will email you when there is an update with a link to the admin page that l…

The timeline feature is the sidebar that shows you where in time since the first post you are looking at. When you drag along it, it can move you to that date and time. It's a cool features but not integral to the application.

Scrolling still worked... 100% of the time on 100% of devices.

And as for the upgrade, if the parishioner can't click [0] in the web UI (a link to which was emailed to them), then I'm not sure how they are using discourse at all. And IMO they have no business hosting anything themselves as it will most likely turn into a DDoS bot within a year.

But again, there is no need to do this as the forum software worked completely fine for it's core functionality and only scrolling via the timeline was broken.

[0] https://meta-s3-cdn.freetls.fastly.net/original/3X/4/b/4b2ff...

Re: Chrome breaks the Web

#308

  > they made all top-level event listeners passive by default.
  > Now, this is a terrible thing to do. It’s very, very, very bad.
I disagree. This is similar to popup-blocking, yeah the "API" is there, so lets allow every site to just open windows because they want to?

Executing code during scrolling is a hostile action performed by web developers against users. These listeners shouldn't exist in the first place. Chrome developers sided with users, thank you Chrome developers.

Re: Chrome breaks the Web

#309
I have a few contradictory thoughts on this.

On one hand, I really feel Chrome is more on my side than the average webmaster. I don't want bloated websites, I don't want autoplay videos, I don't want copy/paste blocked, I don't waste text copying hijacked so that a phrase has a referral link to the article, etc. If Chrome breaks a website functionality to over-write these things, good.

The downside is that Chrome is a very big player and by working outside of the system then the rest of the web loses on the spillover benefits.

This is hard, committees are slow, bureaucratic and massively resistant to change - and saying fuck it, I'll fix it properly for myself is a lot easier, and I have little patience for it myself. However, in the long ran this is probably better.

Re: Chrome breaks the Web

#310
post #195

Earlier quoted context omitted.

The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. Websites have always been a "write and forget" deal; there never was supposed to be any feedback loop of developers fixing breaking changes. This is why old websites from 1998 still work in your browser. This is why there are piles and piles of cruft within browsers and web standards for making sure old be…

> This is why old websites from 1998 still work in your browser. They won't if they use a tag, for example. The problem is that if we freeze the entire web and demand 100% backwards compatibility, we also can't ever move forwards. This scroll event change is a positive in 99% of cases - should a web site built in 1998 really hold that back? There's no absolute in "putting users first" there - you're either putting th…

I don't get why those guy stand against explicit versioning in JS for the sake of forward compatibility, yet it only leads to no IE6 era JS heavy website running in modern Chrome.

In few years time, it will lead to the same thing happening to Chrome JS ecosystem

Post reply on HN