'How Chrome Broke the Web' (tonsky.me)

Reader Tablizer writes (edited and condensed): The Chrome team "broke the web" to make Chrome perform better, according to Nikita Prokopov, a software engineer. So the story goes like this: there's a widely-used piece of DOM API called "addEventListener." Almost every web site or web app that does anything dynamic with JS probably depends on this method in some way. In 2016, Google came along and decided that this API was not extensible enough. But that's not the end of the story. Chrome team proposed the API change to add passive option because it allowed them to speed up scrolling on mobile websites. The gist of it: if you mark onscroll/ontouch event listener as passive, Mobile Google can scroll your page faster (let's not go into details, but that's how things are). Old websites continue to work (slow, as before), and new websites have an option to be made faster at the cost of an additional feature check and one more option. It's a win-win, right? Turned out, Google wasn't concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. That's why on February 1, 2017, they made all top-level event listeners passive by default. They call it "an intervention." Now, this is a terrible thing to do. It's very, very, very bad. Basically, Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable, at the benefit of winning some performance for websites that were not yet aware of this optional optimization. This was not backward compatible change by any means. All websites and web apps that did any sort of draggable UI (sliders, maps, reorderable lists, even slide-in panels) were affected and essentially broken by this change.

Comments

onScroll not passive?

[Luthair]

Maybe you should fuck off with your website that modifies scrolling.

Re:onScroll not passive?

[tepples]

The featured article claims that "All websites and web apps that did any sort of draggable UI (sliders, maps, reorderable lists, even slide-in panels)". In such web applications, if the user is performing a slide gesture, he doesn't necessarily want to make the whole document scroll just because the gesture has approached the edge of the document.

So let me get this straight: Are you claiming that such web applications "should fuck off"? Must they instead be rewritten as native executable applications that work only on one brand of operating system?

The Chrome team "broke the web"...

[Anonymous Coward]

if you use Chrome.

As I'm firmly in the 'fuck Google and all of their products' camp, I hadn't noticed.

Didn't they just break their own product?

[myowntrueself]

It doesn't sound like they broke the web; surely other browsers carried on working just fine? They broke their own product.

Re:Didn't they just break their own product?

[TuringTest]

Except that users will perceive it as "this old website doesn't work", not "Chrome doesn't work", since the problems only happens in some websites and not others.

Re:Didn't they just break their own product?

[Anonymous Coward]

It's like a smudge on the screen, except users would probably figure out that not all web sites started having smudges in a fixed position.

During your first week of working in this industry, you will quickly learn one thing: never, ever depend on users to figure out anything.

You can only count on users to find the most ingenious ways to break things. You can't count on them to figure out new things. In fact most of them really hate learning. They will go to such extraordinary lengths to avoid learning, that actually learning would have been far less effort.

If you've ever worked in an office setting, you will have seen tons of users who have used the same systems for years. Yet they know nothing more about how things work than when they started. They managed to avoid even accidentally picking up bits of new info along the way. Now that takes real work. If a later version changes the location of a menu item or icon, the company has to invest in "retraining".

That's what "users" are like.

Re:Never rely on defaults...

[Anonymous Coward]

This wasn't a default, it was a standard. Google was the one that decided to add a passive option in the first place, and when they defaulted it to true, they violated the standard. Sites that were broken by this change were doing everything right when they were written; their only mistake was not religiously re-checking their site against every new Chrome Canary build to make sure their standards-compliant site hadn't been broken.

Re:Never rely on defaults...

[Anonymous Coward]

Years ago, websites were designed so that they rendered properly with Internet Explorer. Microsoft didn't have to follow any standards because they had the most widely used browser and Fuck You if you don't use IE.

Now Chrome is the most widely used browser and Google has decided to become the new Microsoft.

Re:Never rely on defaults...

[Jerry]

Exactly.
Google is just adopting Microsoft's "Embrace, Extend, Extinguish" tactic against its opposition because it has the market share to do it.

That, and Google's attack on free speech, are the reasons why I canceled my Google account.

Re:So, you're saying...

[thegreatbob]

When too much changes too quickly, as is pretty clearly the case here, cromulence diminishes rather rapidly. Making up new words is fine, provided they have a definition based in what is already understood (perhaps even understandable?). However, if I (or whatever entity) begin to unilaterally redefine words and other parts of speech, problems start to arise, and mutual intelligibility is lost.

Mod him up - he's right by example... apk

[Anonymous Coward]

See subject: He's right - there was so much bitching about MS doing things around IE specific code (which forced sites to follow it BY FORCE) & now Google's doing it - hypocritical/pot-calling-a-kettle-black bs (do not as I do but as I say etc.) - This kind of change should go thru a standards board imo!

* Doesn't it OR rather, SHOULDN'T IT?

(I'd think so)

APK

P.S.=> This kind of action will 'break the web' ALL OVER AGAIN (& I recall web page makers bitching about "I write pages for IE one way, another way for FireFox, another way for Opera, another way for Chrome - it's too much work!" & they were right... apk

How bad is it really?

[140Mandak262Jamuna]

The summary says:

It's very, very, very bad

It explains:

Basically, Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable, at the benefit of winning some performance for websites that were not yet aware of this optional optimization

OK, half the user websites? 50% of the web right? The linked article says:

We looked at the percentage of cancelable touch events that were sent to a root target (window, document, or body) and determined that about 80% of these listeners are conceptually passive but were not registered as such. Given the scale of this problem we noticed a great opportunity to improve scrolling without any developer action by making these events automatically "passive".

Looks like the chrome team did some basic profiling, figured out 80% of the listeners are actually passive. Still they should not have touched the default and educated the website developers to register conceptually passive listeners as passive, right?

Google gives some motivation for this:

We believe the web should be fast by default without developers needing to understand arcane details of browser behavior.

There are some plots and more profiling data there.

They could have done an RFC and got the standards updated in the next batch for this. But still, as evil behaviors go, this is not "dos is not done till lotus wont run" level. Does not even come to working around bugs in IIS in IE to make all other browsers crap out level of evil.

Re:How bad is it really?

[LordKronos]

Yeah, I'm finding it a little difficult to get worked up about this. It's been this way for over half a year and I haven't noticed anything broken by it. And honestly I'm having a bit of difficulty imagining how a website could legitimately use this sort of eventListener and not be a prime example of sloppy coding. Yes it might've worked by the standard...I understand that. But really...listening for scroll events at the window, document, or body level? Can someone give me a good example of how this is used and couldn't be done better? Some of the "broken things" examples given in the linked article: Drag an drop list? Your list should be contained in some div or ul element and you should apply the listener at that wrapper level, not listen to ALL scroll events on the ENTIRE document. Sliders? Same. Maps? Same. Yes, it might have worked before by listening to all body events, but really that's just shit design.

So I feel like a better description would be more like "google broke 50% of the shitty websites, but not the well designed ones". But please, I welcome an example to show me where there are good reasons to do this.

Re:How bad is it really?

[LordKronos]

Or perhaps this should be the free square on why you read the post before replying to it. Read my post again. As I mentioned, this particular chrome change ONLY applies for event listeners that are bound to the window, document, or body. It's a pretty general rule that any type of listener should be scoped to only listen to the minimum required amount of events. When you bind to window, document, or body, you are pretty much saying GIVE ME EVERYTHING. So now you get called for every event...even those you couldn't possibly be the slightest bit interested in. Best programming practice is generally to scope your event listeners so that they only get called in cases where you might possibly be interested in handling them.

Lets look at a simple case....a webpage where the body contains 2 divs (divA and divB). In divA, you want to handle an event and perform some custom handling, possibly even cancel the the event with preventDefault. In divB, you never care about the event, so your event handler is always going to do nothing.

If you bind your event handler to divA, then whenever that event occurs in divB your event handler will never even be call. That's perfect...you aren't interested so lets not even waste time asking if you want to do anything. But if you bind your event handler to the body/document/window, your event handler is going to be needlessly called so that it can do ABSOLUTELY NOTHING (except waste CPU time) every time the event occurs in divB.

So that was my point...based on what I've read my gut instinct is to say that this would pretty much only affect web pages where the programmer was too sloppy/lazy to properly scope their event handler to the parts of the DOM where they're actually interested in doing something about that event.

But of course, I admit that I may certainly be overlooking cases where this isn't the case, and there's absolutely no way to implement it without throwing an event handler on the window/document/body. And that is why I humbly asked for examples where I was wrong and this is the only way to do it. I will note that you provided precisely zero example of such. Maps and reorderable lists can certainly have their event handlers properly scoped instead of just throwing them on the window/document/body

Re:Get with the picture!

[bhcompy]

Don't use Chrome. There, fixed.

Multiple browsers

[ilsaloving]

It's idiocy like this why I am compelled to have at least 3 different browsers on every machine I use. Because it seems like every time there's some kind of update, stuff get horribly broken and I need to switch to a different browser for an extended period of time. It's to the point where I've purchased an xmarks premium subscription, so that all my bookmarks gets synced and I don't have to jump through hoops when the inevitable switch happens.

It's so frustrating the way companies think that they are allowed to have defacto control of the entire internet.

Fuck you Google, and fuck you Microsoft before you.