
Chrome breaks the Web - bloomca
http://tonsky.me/blog/chrome-intervention/
======
KeitIG
> 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 `<form>` tags [1], because:

> The tricky part here is that somewhere along the journey of the web
> autocomplete=off become a default for many form fields, without any real
> thought being given as to whether or not that was good for users. This
> doesn't mean there aren't very valid cases where you don't want the browser
> autofilling data (e.g. on CRM systems), but by and large, we see those as
> the minority cases. And as a result, we started ignoring autocomplete=off
> for Chrome Autofill data.

Problem: Chrome now auto-fills wrong parts of forms with username/passwords
and this breaks forms that get unexpected data when submitted. And now, they
opened an issue on their tracker [2] to track "Valid use cases for
autocomplete=off".

This is insane to think that the developer is wrong to use some attributes
values, and to assume how a page should behave, ignoring devs intentions and
Web standards.

[1]
[https://bugs.chromium.org/p/chromium/issues/detail?id=468153...](https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164)

[2]
[https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

~~~
saas_co_de
> 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 are rarely if ever
thinking about the good of their users, except in a very narrow profit
motivated sense, and never thinking about the good of the ecosystem as a
whole.

Google is also "breaking the web" by not auto playing videos, not allowing
alerts in one tab to block the entire browser, etc. Those all seem like good
things to me.

~~~
notjoemama
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 TTM for features and allows us to adopt a
common standard others use on the web.

Them: So there's no UI and it won't affect their workflow?

Me: Well, no.

Them: Then why would you suggest it? We don't have the budget to add
meaningless development tasks.

I might be biased towards thinking there are _plenty_ of developers and
engineers out there thinking about this stuff but we don't always get the
final say in what is done. Also, a lot of enterprise applications were and
continue to be around before many of these standards. It's a struggle to
improve what doesn't directly add to the bottom line.

~~~
ric2b
Try to make those requests via e-mail, so you have something to show when it
breaks or becomes hard to maintain.

~~~
twothamendment
I've learned when I have to start getting things in writing that it is time to
find a better job. I can't stand playing games at work.

------
untog
> Turned out, Google wasn’t concerned about your websites at all. It was more
> concerned about its own product performance, Google Chrome Mobile.

As a web developer, I see this attitude a lot and it annoys me immensely.
Another way of phrasing it: Google is putting users first, ahead of
developers. This is as it should be. "your" website exists to serve users, if
you're doing a bad job at it then maybe it's an opportunity for self
reflection.

Janky scrolling behaviour on mobile has been a problem for a long time. Apple
also implemented non-standard behaviour for years to avoid it. You should
almost never be listening to scroll events in a non-passive way. The vast
majority of times scroll listening is used, a passive listener is the correct
implementation and just wasn't available when the code was written.

This is proven by the article itself: the change was made in February of this
year. Do you remember the internet breaking that day, and all of us rushing to
update our event listeners? No, me neither. Did Chrome really break when the
web when absolutely nothing broke?

~~~
Manishearth
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 behavior that folks may rely on continues to
work.

The commitment to stability on the web is astounding; I don't see anyone
changing that any time soon. Google should not be breaking things just for its
users; because its users are affected when they break things too.

That's the problem with Javascript. When Javascript breaks, it's not the
developers who get the error, it's users, who have no idea what it means and
no way to fix it. This is not the case with e.g. compiled languages; there's
no _extremely strict_ guarantee your code will still compile on a new release.

That said, Google did push this through the right channels
([https://github.com/WICG/interventions/issues/35](https://github.com/WICG/interventions/issues/35)
, [https://github.com/w3c/touch-
events/issues/74](https://github.com/w3c/touch-events/issues/74) ,
[https://github.com/WICG/interventions/issues/18](https://github.com/WICG/interventions/issues/18)
) and it seemed like browser vendors were in agreement that this wouldn't be a
problem. This is something that does happen; browser vendors "unship" or break
functionality after discussing it sometimes.

So while I'm not convinced Chrome stepped out of line here, breaking sites
_absolutely is not putting users first_.

~~~
untog
> This is why old websites from 1998 still work in your browser.

They won't if they use a <blink> 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 the minority user looking
at an old site first, or you're putting the majority looking at newer sites
first.

Maybe it wouldn't be the worst thing in the world to introduce an "archival"
mode in a browser. Nothing published on the web is ever truly broken because
it's very well documented what it _should_ do. So we can turn those features
back on when viewing an older site that requires them - blinking text and all
- while still moving forward on the platform people use every day.

~~~
katastic
> we also can't ever move forwards.

There is a thing called Forward Compatibility. Not everything old has to die
to move forward.

On our OpenGL 4.x videocards still run OpenGL 1.x. And no, fixed function
pipeline of 1.x isn't anything like the modern shader pipeline. (Sidenote:
many cards that were designed in the 3.x era and nVidia backported 4.x support
into their older cards which is amazing to me.)

>Maybe it wouldn't be the worst thing in the world to introduce an "archival"
mode in a browser.

Internet Explorer already did that.

~~~
untog
> Not everything old has to die to move forward.

But we're talking about a very specific example, where the best option for the
vast majority of users was to change default behaviour. There is no "passive
event listener still implements active event listener API" equivalent here.
You have to make a choice.

------
Klathmon
To be honest as a user, I'm glad they made this change, even though as a
developer it might be a pain in the ass for a day or 2.

Scrolling on the mobile web sucked for a long time. Yes, updating the default
broke many things, but the scope of that breakage was fairly limited in the
grand scheme of things (like the author said, sliders, maps, touch-and-
draggable things like lists are the biggest impacted, stuff like "sticky
headers" and other junk would be impacted, but not "broken beyond usage").

We've seen time and time again that simply giving a developer the ability to
fix things doesn't help, and letting the mobile web suck for several years
while a few percent of the web slowly learned how to fix this would end up
impacting far more people than the "breakage" ever would.

It's not ideal, and I wish that google provided a very quick and easy way to
"opt out" of the breakage (like some one-line "polyfill" that reverted the
change that site owners could use as a stop-gap until they could properly
update their apps to work correctly), but I see their point and as a user I
agree with it, even though as a developer this is the kind of stuff that ruins
your day.

I personally have not hit a single website that was impacted by this that I
could notice myself. That's not to say that I haven't been impacted by the
breakage, or used sites that had something break because of it (that I didn't
notice). But even knowing that this change was made when it was made, I didn't
see any sites that were "unusable" or "broken" because of it.

~~~
chii
> "polyfill" that reverted the change that site owners could use as a stop-gap
> until they could properly update their apps to work correctly

then the site owners would just use the polyfill indefinitely, since it now
works again. THe more expensive option of rewriting to conform is not going to
give return on investment.

This is why breaking a bad thing is needed - the suffering has to happen. It's
like getting the flu - to get better one must get sick first if you've been
infected.

~~~
emodendroket
Except that millions of sites will not ever be fixed; they'll just be broken
indefinitely.

~~~
ravenstine
Possibly, but if they are that useful to users, those sites either need to be
maintained or forked. Your argument could have just as easily been used to
argue for Adobe Flash support(OK it's still sort of around, but it's nearly
irrelevant at this point).

~~~
Dolores12
> sites either need to be maintained or forked

Maintained by who, forked by who? You can't just fork someone's work, there is
copyright. Also any saved copy of website(think web archive) will stop
working.

~~~
emodendroket
Assuming you can even get at it; most useful tools have a significant server
component that's inaccessible.

------
dotdi
Dear developer,

I hate you[1] when you interfere with scrolling. Yes, some people do it right
and so on. You are not one of them. Please. Stop.

Yours,

A user that will close your website when scrolling is messed with.

\---

[1] not OP, but the average developer, which, under time pressure and without
many resources, cannot test all desktop/phone and browser combinations.
Assuming they even care.

~~~
gldalmaso
Not all users have a choice to leave a website.

If a Chrome update breaks the governmental website that relied on some "never
used" feature and the user can no longer, say, apply to unemployment
insurance, real people would be getting affected in very real ways.

We wanted technology to part of peoples lives, now it is, we have to own up to
the responsibility.

~~~
anchpop
Couldn't they use Firefox?

~~~
yladiz
So many websites have "Use with Chrome" that if a user sees the website not
working in Chrome, it's likely that the user will assume the website is
broken, not the browser.

------
matt_kantor
First of all I 100% wholeheartedly agree with the message of this post.
However I have a minor quibble:

> Chrome broke half of user websites, the ones that were relying on
> touch/scroll events being cancellable

Either I badly misunderstood or the author is asserting that 50% of _all
websites_ rely on touch/scroll events being cancellable. That's inflated by at
least 100x. Exaggeration is doing no favors here; the rest of the article is
pretty rational despite it being clear that the author is pissed off, but this
one sentence undermines it.

\---

Unrelatedly:

> We really don't have more than anecdote (and our metrics) on the "support"
> side, and _no precise way to quantify the breakage_. I'd love to have a more
> quantifiable way to make these sorts of trade offs.

(Emphasis mine.)

Wow. So they're breaking backwards compatibility in a standardized web API
with no plan for how to measure the fallout? That's not very nice.

~~~
DannyBee
"Either I badly misunderstood or the author is asserting that 50% of all
websites rely on touch/scroll events being cancellable. That's inflated by at
least 100x. Exaggeration is doing no favors here; the rest of the article is
pretty rational despite it being clear that the author is pissed off, but this
one sentence undermines it. " The funniest part of this sentence is that it
cites no source. Meanwhile, Google claims very clearly that they analyzed
websites and determined pretty much nothing would break.

Given the internet did not break that day, i'm going to go with "They were
probably right".

Especially since, unlike this website, they have the crawl data to know.

------
Sir_Cmpwn
I side with Google on this one. IMO we should be breaking JavaScript _more_
often, especially in the name of performance, to make people use less JS and
simpler JS on their websites.

~~~
eknkc
Great idea.

Why stop there? I say let's make "if" conditions randomly work on false values
1/1000th of the time. That will teach them.

~~~
Sir_Cmpwn
You're being sarcastic, but this is a great idea. Let's do it.

~~~
todd3834
You have an interesting point of view. Why do you feel this way?

~~~
Sir_Cmpwn
I think JavaScript is largely a pox on the web. I _hate_ almost every website
I come across today. I just try to ignore all of the bullshit for as long as
it takes to consume the actual content, and 95% of the bullshit is possible
thanks to JavaScript.

~~~
kowdermeister
Do you think if JS weren't available advertisers and marketers wouldn't try
everything to shake some $ off your pocket? You would be pissed the same way.

Also if it weren't JS, would it make a difference if the bullshit is created
by lisp, java or erlang?

~~~
Sir_Cmpwn
It it were lisp, java, or erlang I'd still be pissed. The web should not have
a client-side scripting language.

~~~
kowdermeister
That's just laughable. Somebody at some point would have created an
alternative browser with client side scripting. Otherwise you end up with
static text and video. Wonderful. And plugins! Because you don't allow scripts
:)

~~~
Sir_Cmpwn
I don't think that it was a mistake at the time. I think that in retrospect it
has been abused, and many of the things that justified it are now possible
without it. It should be deprecated and removed.

Yes, I know this is a fool's errand. I don't actually expect this to happen.

------
ajross
OK, this sounds bad. But... Devil's advocacy here: are there any real-world
examples of actual sites whose event behavior was actually broken by this
change in Chrome 56? It happened a few months back, and I don't remember
anyone complaining.

I mean... it broke the author's app. Probably a few others somewhere. But it
seems not to have broken anything significant.

I guess I fail to see the concern here. It's an edge case of an existing API
that apparently "no one used". Google found a way to get a benefit from
exploiting a "change" in this "unused" API, presumably tested to make sure it
was unused, and then went ahead and pushed the change over an 8 month period.

Is that really so awful? As someone who lived through the early '00's and IE,
this seems pretty benign to my eyes.

~~~
lukenyc
It broke our web apps. Specifically, drag and drop list reordering
functionality and image cropping. I was pissed when it happened. It wasn't a
change that a typical content site would be broken by, but a lot of web apps
were: drag/drop reordering isn't a very unusual feature these days.

------
s17n
> As a user, I certainly do not care about “being part of moving the web
> forward aggressively”. Why should I? I like my stuff working, not broken.

Actually, I do want to be part of websites being faster, and I don't care
about the functionality that is being broken. Performance isn't a secondary
concern - if it's bad, the site is unusable from my point of view.

Your shitty scrolljacking site breaks the web, Chrome is trying to fix it.

~~~
mrighele
But his shitty scrolljacking doesn't break the web, at most his own website.
Google probably broke a lot of website _except_ its own.

~~~
s17n
This is a change to how Chrome deals with sites that use onScroll. In their
current state, most of these are broken as far as I'm concerned. Chrome's
changes will partially fix a lot of these sites, at the cost of breaking some
that aren't currently broken. That is a win for the user.

My only problem with this change is that developers can still override the
default and cancel scroll events. The handful of legitimate use cases this
enables aren't worth the cost of letting shitty designers abuse it.

------
EGreg
A lot of fair points in here.

I think what it comes down to is backward compatibility for the web. There are
SO MANY websites relying on old behavior that introducing new behavior is
going to break some sites that don't KNOW about your shiny new shit.

IE used to have this kind of thing too, anyone here remember "Quirks Mode" and
so on?

What web browsers sorely need is a backward compatibility standard that they
can STICK TO. Such as feature detection as a first-class API to be tried
first. Perhaps this way any new features can be detected across browsers.
Like, they would actually have to coordinate to name EACH new change the same
in EACH new browser.

But this is what you get when you have multiple browser makers. Some just
won't coordinate with the others and you need another layer - a library - to
abstract away the differences.

Which is why it would be super-useful for browsers to add content-addressable
protocols (read: not just http) to fetch files from any website in a DHT. So
these libraries can be loaded ONCE and become cheap to use!

Does anyone know any mainstream browserd planning to implement, I dunno, IPFS?
The only one I've heard of doing this is Blockstack and dude, how much
adoption does that have exactly?

Last question -- can there be a browser extension that can intercept http
requests by their Subresource Integrity checks, and load them on demand as if
they were content addressed? Maybe use service workers in Chrome? Is that
possible? I would be willing to partner with someone here to write such a
thing.

~~~
lgierth
> Does anyone know any mainstream browserd planning to implement, I dunno,
> IPFS?

It's actually not too far off - IPFS is already capable of running a full js-
ipfs node in a WebExtension's background page and expose its API to content
pages. What's missing is minor things like streaming to/from the background
page, and WebRTC in the background page.

For proper ipfs:// protocol support in the address bar and in links, a better
protocol handlers API in WebExtensions is required though, which will take
some more time. Basically right now with the ipfs-companion extension, ipfs://
URLs get rewritten to [http://](http://).

------
ipedrazas
> Google wasn’t concerned about your websites at all. It was more concerned
> about its own product performance

Why I'm not surprised?

~~~
stupidcar
No, Google were concerned about your websites. Your mobile websites which are
so heavily overloaded with JS that basic interactions like scrolling don’t
work.

Complaining that Google “broke the web”, when mobile developers have been
making it slowly unusable—and unused—for years is pretty hypocritical. All the
feature detection and backwards compatible changes in the world won’t help
developers when their entire userbase has fled to walled gardens like
Facebook. But I guess some people will resent anything that forces them to
accept short term pain, even if it’s essential to their long term survival.

~~~
disconnected
So this is a good thing because the gatekeeper is Google instead of Facebook?

How's about adhering to standards? We gave Microsoft a hell of a time for not
adhering to standards, but Google gets a free pass now? Because "performance"?
(read: some negligible gains on some synthetic benchmarks)

Then let's stop pretending: let's scrap the W3C and go back to the good old
days of "Best viewed on Netscape Navigator at 800x600".

~~~
ko27
Let's also complain about Mozilla because they are removing Flash support and
thus breaking backwards compatibility. It's obvious that they are all 'evil'.

~~~
jimktrains2
Was flash a standard? Also, flash still works, it's a click away with a button
in the location bar for sites that try to use it.

------
trgv
Can't they just add another argument for the options map without breaking
backwards compatibility?

That's ugly as hell too, but in a way that preserves backwards compatibility.

My feeling is that so many compromises have been made to maintain
compatibility in JS/DOM-land that it seems capricious to make this kind of
decision now.

~~~
masklinn
> Can't they just add another argument for the options map without breaking
> backwards compatibility?

The options map is a recent addition in the first place, and they want passive
listeners by default. They originally made passive opt-in, then decided that
they wanted it set.

------
jarym
It really feels like the Chrome developers have forgotten that they're
providing a platform and not an in-house Google service.

It happens very often - developers with experience building apps don't always
manage to build tools for other developers very well. They focus too much on
the end-user and disregard their platform developers too much.

The balance needs to be somewhere but I doubt they have it in the right place
currently. For example, how do Google's own apps disable autocomplete if
autocomplete is ignored?

~~~
ko27
> The balance needs to be somewhere

It might be a controversial opinion, but I think that the balance should
always lean closer to the user's side, not developer's.

~~~
jarym
I agree with you on 'lean'. But say I'm building a web-app that accesses
medical records and I don't want sensitive fields being auto-completed by a
browser.

Forcing autocomplete in this instance does a dis-service to both users and
developers.

~~~
jhasse
Why not? The user knows that the browser remembers field inputs, he wouldnt
expect it to be different for your website. So if he really wanted the browser
not to remember anything he typed in, he would use private mode or clear his
recent history afterwards.

Because then there's the teacher who has to put in medical data for a whole
class where everyone got the flu. The teacher is happy the browser does it job
like always and that you couldn't dictate what is best for him.

~~~
jarym
'Why not?' you ask? Let's look at HIPAA for starters:
[https://www.quora.com/Do-current-HIPAA-rules-require-
publicl...](https://www.quora.com/Do-current-HIPAA-rules-require-publicly-
viewable-machines-to-not-have-tabular-lists-pull-down-menus-of-patients-or-
autocomplete-except-for-fully-unique-matches)

"In summary, HIPAA does not specifically limit the use of drop down menus or
auto-complete, but if patient information was exposed to the public through
these features your business would have failed to control access to the
protected health information."

So now there's a risk that if a user of a medical information system uses a
shared computer (say one at home but that friends and family occasionally use)
you can't be sure to have protected control. It's all very well saying 'users
should use private browsing mode' \- you try enforcing that consistently when
you have hundreds of users.

Ultimately, you end up having to restrict access which is why I felt it does a
dis-service to users.

~~~
jhasse
You shouldn't enforce anything, since you can't really anyway: The shared
computer might record the screen or have a key-logger installed.

~~~
jarym
Well then let's just throw away any kind of data entry then since any computer
might have a key logger installed.... _sigh_

~~~
jhasse
> any computer might have a key logger installed

You know very well that for your own computer it's very unlikely that it has a
key logger. But not for public computers, so it's a good thing that users are
aware of that.

------
cosinetau
> "Browser vendors have their own agenda. It mostly includes making their
> browsers look fast, sometimes at the cost of your websites become broken."

I feel like you'd know the tree by it's fruit. I have a little more faith that
vendors like Mozilla wouldn't pull a punch like this; might have been more
receptive to community feedback, not that anyone here needs a continued
lecture about Google.

------
acdha
There’s a good point here but the clickbait trappings are holding it back,
especially since passive listeners aren’t some obscure edge case which only
Google needs.

~~~
juliangoldsmith
I think the point of it was that they made every event listener passive by
default, rather than making it an option.

~~~
acdha
My point was simply that while there's a good technical discussion to be had
here, the doom and gloom styling hurts it. There is a reasonable point about
backwards compatibility, the conflicts between Google owning Chrome and also
making web properties which compete with other companies, etc. but there's a
lot of hyperbole like this:

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

None of those claims are supported. If Mobile Chrome broke half of the sites
on the web, we'd have heard a lot more outrage over the last six months, and
the very strong language fails to consider all of the broken code which was
making the web experience worse for almost everyone.

Again, I'm not saying that that the technical discussion isn't useful but that
“breaks the web” seems unnecessarily hyperbolic. The fact that the React team
is struggling with a simple JS/CSS change seems to say a lot more about the
support cost of building huge JS frameworks which duplicate core browser
functionality than whether the Chrome team should make decisions to help
mobile performance.

------
diiiimaaaa
I've seen similar posts when Apple announced that there won't be Flash on
mobile Safari. And I agree with Chrome team decision to force passive on
document level listeners.

Also, note that not many people complained about "blocking video/audio
autoplay on mobile browsers", because it's good for users.

BUT:

\- Passive event listener detection is horrible and it baffles me that they
start thinking about proper way only now.

\- The announcement of this breaking change was quite silent. Chrome has so
many influencers on social media, but almost no one shared/explained this
change properly.

------
quotemstr
Without commenting on the "intervention" itself: why change the signature of
addEventListener? It would have been trivial to add a new addEventListenerEx
API with a redefined final parameter, and this alternative approach would have
made feature detection trivial.

~~~
mediumdeviation
It seems Firefox supports a non-standard fourth parameter, so that won't work
either.

addEventListener is possibly the worst organically grown API I've seen in a
long time. If anything, its sordid history should be a lesson to the Chrome
dev team that fucking around with proprietary extensions (which this most
definitely is) just leads to future technical debt and pain for everyone. Why
do they never learn?

~~~
djur
That isn't an issue if you use a new method name -- I believe
"addEventListenerEx" was meant to be read literally. (Appending "Ex" to a
function name for an expanded parameter list is a Win32 convention.)

~~~
quotemstr
Right. The whole problem disappears if you just define a new function name.

------
iainmerrick
I understand the push from browser vendors to (as they see it) encourage web
developers to keep their sites up to date, but it's crazy how little Google
and others seem to care about backwards compatibility.

So many websites from 10 or 20 years ago are unusable now -- if they're even
still available. That seems to me a bit of a tragedy. It's sad to just write
off that entire slice of human history.

Funnily enough, it's the sites that were quick to adopt the hot new HTML and
CSS features from 10 years ago, but then were unable to keep updating
indefinitely, that were the worst hit. Really old sites using basic HTML and
CSS mostly work OK.

------
styfle
Did anyone's website or web app break because of this change in Chrome 56?

I ask because the article lists a couple things that could break such as drag
'n drop but I have not noticed anything breaking in my experience.

~~~
lukenyc
<Raises hand> Took about a developer day to fix everything. Drag/drop list
reordering, pan/zoom image cropper were the primary things busted. IMO, the
change was an unacceptably aggressive move by the Chrome team made with good
intentions.

~~~
styfle
> Drag/drop list reordering, pan/zoom image cropper

I'm curious, were these implemented using a 3rd party library or developed in-
house?

------
datashovel
A great example of why I think the entire core ecosystem of the web is
backwards.

I've had a number of comments here on HN related to this. Imagine this same
scenario, except instead of the User being in charge of deciding which engine
is used to render a website / webapp, the Developer is making that choice.
What would a developer need to do if they were in control of which "engine"
rendered their website on the user's computer?

Instead of being at the mercy of Google / Chrome, the developer of said site
could simply change their HTTP Header "X-BrowserEngine" or something like
this, and the client's computer would know how to (a) download the new engine
if it's not on the computer already (b) sandbox the new engine (c) run the
site / app in said engine.

I've called this idea the "Meta Browser" in the past. It's a concept for an
app that sandboxes and runs sites on different browser engines seamlessly. The
user experience is more or less as though they're continuing to use a single
app to browse the web, but behind the scenes could be any number of custom
engines rendering the content.

------
lallysingh
I don't get this feature detection problem. The browser identifies itself in
the request. Why not serve the right version at the beginning?

~~~
reificator
1\. Because every browser pretends to be each other and so the UA is
worthless: [https://webaim.org/blog/user-agent-string-
history/](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-syntax related features, feature detection on the client
is usually pretty simple.

5\. Because the UA is trivial to spoof.

~~~
lallysingh
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 in the "I don't know what you are" variant and
let them run slower.

For 5: If the browser's lying, you're morally off the hook. The user's
configured their browser to lie, and gets what they deserve.

For point 4, fair enough. Go for that when you can.

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

~~~
lallysingh
A few seconds of googling found quite a few prebuilt results. First one:
[https://github.com/faisalman/ua-parser-js](https://github.com/faisalman/ua-
parser-js)

It doesn't have to be trivial to be worth doing.

~~~
reificator
Direct from the README of the linked library:

> However, it's not recommended to use this library as browser detection since
> the result may not accurate than using feature detection.

------
just2n
This doesn't surprise me. Having spent years working on a very complex web app
that's built to run primarily on Chrome (-2 versions), our API/DOM usage
coverage was so great that we would often joke that our unit and integration
tests were effectively a 90%+ coverage of all of Chrome's functionality, so
any bugs or changes they made, we knew about immediately.

I think nearly every version introduced some change that broke behavior and
had to be worked around, usually fairly minor and arguably reasonable.
Sometimes that's not the case, something would be completely broken and we'd
file bugs against Chrome to get them fixed, and our codebase is now riddled
with comments about workarounds citing Chrome bugs, some years old.

There was even a recent change to contenteditable that was a breaking change
and is not spec compliant, which totally breaks HTML-based rich-text editing
systems built on it that don't want to just have a ton of style tags and/or
empty tags everywhere in their markup. This API is probably one of the worst
I've ever seen (it needs to be extensible and modifiable, you can configure it
somewhat but you're left actually taking the output and massaging it yourself
if you want anything resembling a good product based on it), so I'd be in full
support of a rewrite of the spec and a new version of contenteditable, but as
terrible as this one is, it should remain spec compliant.

At one point I held Chrome in reverence for pushing the boundary and improving
the QoL of web application developers, but shifting to maintaining anything of
decent complexity has made me regret the decision based on how much extra work
Google makes for us. They really need to cut out the breaking changes and do
better regression testing. If our app detects errors in beta/canary and we
report them and they STILL make it to live, I just don't even know what to
say. I'm not even sure I agree that just because 0.1% of websites rely on
certain behavior that it should be "breakable." With all this talk about
progressive web apps, where are the progressive web browsers?

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

------
fiatjaf
The highlighted comments from the Google agent are very jerkish, but to be
honest,

    
    
        > But in Chrome we’re fundamentally unwilling to allow the mobile web to continue to die from performance bankruptcy. Other browsers are less aggressive, and people who prefer to be more conservative (preferring maximal compatibility over being part of moving the web forward aggressively) should prefer to use a more conservative browser.
    

is very true.

The mobile web is dying. Native apps are obscuring it while it is made
irrelevant by very poor website performance.

Now I don't know how to solve it.

------
marijn
> The gist of it: if you mark onscroll/ontouch event listener as passive,
> Mobile Google can scroll your page faster

onscroll has never been cancelable, and is fired after the actual scrolling
takes place. So I don't see how it being passive by default changes anything.
Is this an oversight in the article (and a bunch of comments here), or am I
missing something?

[https://developer.mozilla.org/en-
US/docs/Web/Events/scroll](https://developer.mozilla.org/en-
US/docs/Web/Events/scroll)

------
bastijn
Reading the comments here make me feel Chrome is like Uber. They may be right
in that the standards are outdated and force change. Yet, it breaks all rules
and regulations which they shrug off saying the rules have to change.

Again, this is not a comment to choose sides. Just an observation. As with
Uber I can’t say if I’m in favor or against. By law, they are wrong. In time,
it may turn out they have led change. Funny thing how you can get applauded as
patriots for breaking the rules early as long as you were right in the end but
critiqued otherwise.

~~~
Sylos
Reading the comments here makes me feel like Google's PR team made its round.

The performance benefit in this has to be miniscule, the number of
unmaintained webpages which are irrevocably broken by this has to be huge and
the time period from introducing this feature to breaking webpages, which have
not yet correctly implemented it, was simply far too short.

Even if you agree with having to enforce this somehow, this rushed execution
of that was by all means irresponsible.

Despite that, it seems like 8 out of 10 highly upvoted comments here make no
mention of this maybe not having been ideally executed or it maybe not
necesseralily being advantageous to users either.

------
mathias
> Which means you can’t practically use the new form without feature
> detection.

That does not follow.

`{ capture: true }` works in both, since it’s an object, and thus truthy.

There’s no need for feature detection in the case you describe.

Sadly, that’s the whole premise of this article.

It’s only a problem if you want `capture: false` combined with other options —
since you’d need to pass in an object, that would be truthy in the old
implementations expecting a boolean instead. But then again, the additional
options wouldn’t be supported in those old implementations either.

I’m confused — what’s the actual use case that’s breaking here?

~~~
mediumdeviation
In older browsers, useCapture is NOT an optional parameter, and in most cases
you do NOT want to use event capture instead of event bubbling. There's no
trivial way to support addEventListener(event, handler, { passive: true }) on
both new and old browsers without that really ugly feature detection code in
the article.

~~~
mathias
> In older browsers, useCapture is NOT an optional parameter

Which browsers are those?

------
pasbesoin
Many tech people learned this in the context of Microsoft in the '90's, but it
should be kept in mind universally:

"Embrace. Extend. Extinguish."

Maybe stop placing primacy on the "good/evil" aspects of this. Seems in part
to work at a more fundamental level of human and organizational behavior.

P.S. I guess this could also apply to the people who hang ever-more JS off of
their HTML skeleton, until our phones have to "boil an ocean" to load a page.

I guess that fits in with the "universal" aspect I described.

------
old-gregg

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

------
Illniyar
They broke userland.

They introduced a backwards incompatible change that causes a lot of sites to
lose some functionality, behave differently or outright break.

Now you could say that the user (the developer here) used the feature wrong
(I.e. they caused scroll jank), but that's a bit disrespectful - sure there
are a lot of developers who had no idea what it'll do to performance, but
others that weighed the options and decided that even with the jank the user
experience for the majority of users is acceptable.

------
sbussard
This sort of thinking is not "moving the web forward." It's the same thinking
that created the IE6 problem — favoring browser-specific features over web
standards.

------
nitwit005
> Think about it: a feature detection API that itself needs to be detected

There's already at least one such feature in the form of CSS.supports:
[https://developer.mozilla.org/en-
US/docs/Web/API/CSS/support...](https://developer.mozilla.org/en-
US/docs/Web/API/CSS/supports)

------
anodari
Adwords was asking me to test the new version, I clicked to update and it
warned that only works in Chrome.

------
tehsauce
I was a victim of this, thanks for pointing it out. Now I know what to fix at
least!

------
Cacti
Let's be clear here, this isn't a change in favor of users. This is a change
in favor of Google, to speed up their browser, and in favor of their
advertisers, for better overlay control.

~~~
jancsika
Is there a list somewhere of software which strives not to break the higher
level things that depend on said software?

------
hwu2whag
Google is toxic for the future of the internet, but its services are
convenient so from time to time a few of us will complain when they
inconvenience us, like in this case, but will continue using Google products
and completely forget about our grievance with this company.

Case and point, I don't hear anyone complaining about amp anymore, or the fact
that when you search for inventor in some US states you are presented with a
bunch of irrelevant black people rather than actual inventors like Edison,
Tesla, etc. Sadly, like with those cases this story too will blow over and
nobody will care about it in less then a week.

------
creative-coder
Thats' why contribute and stick to Firefox.

\- Its more customizable \- Its more open and standards-compliant \- It
doesn't eat up all RAM \- Its fast enough

------
est
The main problem I have with the chromium team is that they removed Encoding
menu.

I happen to visit an old unuqdated site from time to time now all I can read
is gibberish.

------
JeanMarcS
Back in the old days of IE / Netscape web. When Microsoft thought the respect
of w3c wasn't fitting their vision. Yepee :(

------
avodonosov
When Microsoft dominated the browser market they introduced non standard
extentions. Now google dominates and does that too.

------
minusSeven
Only thing I have to say in all this is any changes made on the web should
always be backward compatible.

------
moocowtruck
where you been? web been broken for awhile now..it's all just duct tape and
spit. We're also repeating the sins of the IE days all over again with
chrome.. At this point i'm using alternative browsers and only fire up stuff
like chrome if i have to

------
Waterluvian
Funtion overloading in a weak typed coersive language like JS seems like a bad
idea.

------
halayli
This is why Linus is very adamant to not break userspace applications.

------
glennblack
The tricky thing is somewhere in the travel of the autocomplete

------
joering2
Why the heck would they take out the checkbox on javascript alert box to "not
repeat anymore". Since they did, the only option to leave annoying website
that pops javascript alerts in never-ending loop is Ctr+Alt+Del.

What were they thinking??

~~~
TheCoelacanth
Didn't they make it so that you can switch tabs and close tabs even when one
of the tabs has an alert open?

Of course, sometimes it still is nice to be able to turn off alerts and then
keep using the page.

------
nasso
When did this breakage happen? I dont remember it at all.

------
flight21
Whining for not much, just update your code. I think the move is best for
users and web performance!

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

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

~~~
francasso
You can make it opt-in without breaking other people stuff. If a website
doesn't opt in their users will migrate to another one that offers the same
content with a better user experience. It just won't happen tomorrow (<\-
common sense, of the real kind).

What really bothers me is that people like you can't figure out that there is
a trend behind this and it's not good one.

~~~
ko27
> If a website doesn't opt in their users will migrate to another one that
> offers the same content with a better user experience

Can't you see how this logic also applies in Chrome's case: everybody would
switch to another browser that does passive listeners by default because it's
a better user experience.

What's bothering me is that people like you think they are entitled to not
maintain your active web apps on browsers that you didn't even help to
develop. It's not about you, it's about the users.

~~~
francasso
There is a rule against breaking APIs, there is no rule against making a
website that is better than another one.

So by your logic it's ok for you to kill and rob a rich person and
redistribute all the money because, hey, at the end of the day it's a better
user experience for everyone else and if you don't do it someone else might.

EDIT: By the way, browsers are in the business of providing a platform.
Platforms should be stable. If they plan on not doing that they should say so.
Guess how many developers will stop supporting chrome the day after that?

~~~
ko27
> There is a rule against breaking APIs

What rule? Is it that the 11th commandment? How about my rule: Users are more
important than API backwards compatibility (because, in the end, we are
serving users, not developers.).

It's simple really: killing a person to enhance user experience is morally
wrong. Forcing, in very rare cases (by my own experience), some developers to
make a 1 line change so that in effect almost all pages will have jitter-free
scrolling is a worthy exchange.

> By the way, browsers are in the business of providing a platform

YES!!! That's the main point of it. They serve (and thus get payed by) users
first, developers second.

> Platforms should be stable. If they plan on not doing that they should say
> so. Guess how many developers will stop supporting chrome the day after
> that.

They did more than say, the just did it. So let me guess have many web
developers will stop developing for Chrome now? uhmmm ..., zero?

~~~
francasso
If they plan on making breaking APIs changes whenever they feel like their
data suggest it's ok, they should clearly say so. But like openly, on the
front of the chrome web page: "We care about you, the user, and will break the
platform for the developers whenever we think it's necessary to improve your
experience".

> It's simple really: killing a person to enhance user experience is morally
> wrong

Well for me it's morally wrong to break APIs, if you don't agree I hope to
never touch anything you ever make.

This is not about caring about the users, it's about doing it without pissing
on the developers heads.

By the way, I was not even affected by this, but I know that if we let this
slide it will just get worse and worse. As if the web was a nice platform to
develop on to start with...

------
nilved
Google can break the Web because they own the Web. It's their platform. Maybe
handing it to them wasn't such a good idea.

------
draw_down
I agree with everyone else that this change is for the better.

What will we do when they decide to make a change that isn't?

~~~
Sylos
Make up even more ridiculous excuses for why this is clearly for the better of
all of us and could not have been handled better.

------
rpo1991
Google is putting users before developers, which is dangerous because the
users aren't the ones holding everything together.

