27 ms·

Chrome breaks the Web

1187 points by bloomca 9y ago

draw_down 9y ago
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 9y ago
  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.
est 9y ago
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.
just2n 9y ago
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?
sbussard 9y ago
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.
old-gregg 9y ago
> 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.
Fede_V 9y ago
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.
pasbesoin 9y ago
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.
Waterluvian 9y ago
Funtion overloading in a weak typed coersive language like JS seems like a bad idea.
fiatjaf 9y ago
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.
datashovel 9y ago
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.
rpo1991 9y ago
Google is putting users before developers, which is dangerous because the users aren't the ones holding everything together.
nasso 9y ago
When did this breakage happen? I dont remember it at all.
marijn 9y ago
> 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
glennblack 9y ago
The tricky thing is somewhere in the travel of the autocomplete
amandashye 9y ago
A browser program I run on my computer is Chrome.
JeanMarcS 9y ago
Back in the old days of IE / Netscape web. When Microsoft thought the respect of w3c wasn't fitting their vision. Yepee :(
creative-coder 9y ago
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
minusSeven 9y ago
Only thing I have to say in all this is any changes made on the web should always be backward compatible.
ipedrazas 9y ago
> Google wasn’t concerned about your websites at all. It was more concerned about its own product performance Why I'm not surprised?
- stupidcar 9y ago
  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.
  - nsebban 9y ago
    Excellent point. Hopefully someday a "lean webpages" movement appears.
    - fenwick67 9y ago
      It's here and it's basically the brutalism of the web, see Craigslist or the Drudge Report, or just look at Hacker News. These are not "web 2.0" designed but they are easy to use and well organized.
      - what_ever 9y ago
        Except that Hacker News website is just dumb, lacks a ton of functionality and gets very basic design wrong. Have you looked at that upvote button? Is this a website for ants?
  - disconnected 9y ago
    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".
acdha 9y ago
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 9y ago
  I think the point of it was that they made every event listener passive by default, rather than making it an option.
  - acdha 9y ago
    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.
Sir_Cmpwn 9y ago
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.
- pvdebbe 9y ago
  Except that Firefox LTS and other minority browsers suffer. I already use a couple sites that disregard all old Firefox compatibilities and use JS that break things up
  - deno 9y ago
    How does this affect Firefox LTS? It doesn’t.
    - falcolas 9y ago
      Devs frequently assume "Chrome", because that's what they use. So, passing an unexpected argument to addEventListener will break LTS releases.
      - deno 9y ago
        This has nothing to do with making event listeners passive by default. If you don’t do feature detection then of course your website will not be backwards compatible. If you care about backward compatibility there exists a polyfill for this functionality.
        falcolas 9y ago
        In saying that "Devs assume Chrome", I'm asserting that they do not do feature detection. However, that does not absolve Chrome of breaking backwards compatibility, workaround or not. Tossing the responsibility of dealing with their breaking changes back on the developer (with little notice) is what caused this article in the first place.
KeitIG 9y ago
> 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#c164 https://bugs.chromium.org/p/chromium/issues/detail?id=468153... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=587466 https://bugs.chromium.org/p/chromium/issues/detail?id=587466
- hinkley 9y ago
  This is just arrogance. From a historical perspective, this is nowhere near the sort of behavior one saw from Microsoft in the 90’s, but that’s pretty faint praise - nobody wants anything like that to happen again. You shouldn’t have people contributing to competing products out of spite. I hope we never hit the point again where it is a cliche for FOSS people to bond over shared hatred of a company. I’d like to think we have been inoculated against that. I like to see people who will speak up like this early and often.
- drewmol 9y ago
  As I've seen others mention, there seems to be a divide between the most user friendly behavior for: (1) public webpage w wide ranging user base that will be consistently updated and developed+ monitored for the widest compatibility, latest security, and (2) the CRM, intranet app, hardware config portal, etc. that will not. Any web devs have recommendations on how they handle the two circumstances?
untog 9y ago
> 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?
- kllrnohj 9y ago
  The real problem here is the fact that active listeners are still a problem to begin with. It'd be absolutely insane if a native app did not get first crack at all input events. This is how they all work (iOS, Android, Windows - take your pick), and the mere existence of a touch/scroll listener is never a problem. But on the web simply having a scroll listener is such a massive performance issue that it's worth introducing not just a new API to get events after they've happened, but to then make that the default? Why not just fix the performance problem instead of hacking and slashing around it?
- pier25 9y ago
  The problem is that it wasn't only the scroll event but also the mousemove event. I maintain a library of interactive widgets for an education product with a lot of dragging and dropping and I was hit hard by this. I understand the reasons behind this, and I agree something thad to be done, but Google is making it difficult for devs to sympathise with the unilateral intervention. It's not the what, it's the how.
- Sylos 9y ago
  No, it's not to serve users. Users don't want broken webpages either. It's to make their own browser look faster at the expense of webpage authors. Because users will blame webpage authors for their webpage being broken. Would they know that they could have this same page unbroken with slightly worse performance, no one would choose the better performance. Sure, there's something to be said about webpage authors getting off their butts quicker, if their webpage is actually broken, rather than just not quite as fast as it could be, but the majority of webpages are not actively maintained. Chrome is simply breaking those. With only 8 months of a transitional period, there's no two sides to this argument. What they've done is unresponsible in every way.
moocowtruck 9y ago
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
trgv 9y ago
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 9y ago
  > 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.
Klathmon 9y ago
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 9y ago
  > "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 9y ago
    Except that millions of sites will not ever be fixed; they'll just be broken indefinitely.
lallysingh 9y ago
I don't get this feature detection problem. The browser identifies itself in the request. Why not serve the right version at the beginning?
- scott_karana 9y ago
  In addition to the UA spoofing others mention, there's also forward conpatibility. If your app holds a mini "caniuse.com" UA-feature mapping, you have to keep it up to date infinitely forward in time, or new browsers won't work (think Brave/etc) Better to detect features directly, and reward anyone who implements them, rather than just hardcode the present incumbents.
- falcolas 9y ago
  Because browsers can and do lie? Often to get around such "serving the right version" logic. Or the "Browse the web faster and more securely, try (Chrome|Edge)" crap?
- acobster 9y ago
  Are you referring to user agents? Serving different code based on user agent is considered bad practice, and would be a maintenance nightmare. Not to mention, serving different JavaScript would make it more difficult to reason about what is running client-side. Plus, user agents are neither canonical nor necessarily even reliable sources of information about the browser.
- breakingcups 9y ago
  Because it's bad behaviour to rely on browser user agents instead of feature detection. It's what led to IE-only sites and is currently leading to Chrome-only sites.
  - criddell 9y ago
    Are there Chrome-only sites? I'm sure they exist on LANs, but are there public sites that only work with Chrome?
dotdi 9y ago
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.
- csallen 9y ago
  > Yes, some people do it right Who? Any examples?
  - diafygi 9y ago
    I normally hate scroll jacking, but the Australian news article on the NK ballistic missile range was pretty cool, even on mobile. http://mobile.abc.net.au/news/2017-10-16/north-korea-missile-range-map/8880894 http://mobile.abc.net.au/news/2017-10-16/north-korea-missile...
    - deleted 9y ago
      [deleted]
    - deno 9y ago
      This page doesn’t do scroll-jacking. Its state appears to update asynchronously based on the scroll position. That is the correct way to do this sort of thing. Scrolling on this article is buttery smooth on my Apollo Lake (1.1GHz Celeron) netbook, on both Firefox and Chrome, even if the background animations aren’t. No jank whatsoever.
      - Groxx 9y ago
        meanwhile... once I scroll to the globe, Chrome locks up. :| Scrolling in FF is indeed super smooth, but that background janks all over the place. Not sure what I'd prefer, tbh, though agreed that the vast majority of scrolljacking is utter garbage.
EGreg 9y ago
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 9y ago
  > 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://.
jarym 9y ago
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 9y ago
  > 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 9y ago
    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 9y ago
      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 9y ago
        'Why not?' you ask? Let's look at HIPAA for starters: 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 https://www.quora.com/Do-current-HIPAA-rules-require-publicl... "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.
s17n 9y ago
> 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 9y ago
  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 9y ago
    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.
avodonosov 9y ago
When Microsoft dominated the browser market they introduced non standard extentions. Now google dominates and does that too.
matt_kantor 9y ago
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 9y ago
  "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.
halayli 9y ago
This is why Linus is very adamant to not break userspace applications.
flight21 9y ago
Whining for not much, just update your code. I think the move is best for users and web performance!
anodari 9y ago
Adwords was asking me to test the new version, I clicked to update and it warned that only works in Chrome.
hwu2whag 9y ago
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.
cosinetau 9y ago
> "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.
iainmerrick 9y ago
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.
nitwit005 9y ago
> 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/supports https://developer.mozilla.org/en-US/docs/Web/API/CSS/support...
mathias 9y ago
> 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 9y ago
  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 9y ago
    > In older browsers, useCapture is NOT an optional parameter Which browsers are those?
diiiimaaaa 9y ago
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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      Right. The whole problem disappears if you just define a new function name.
francasso 9y ago
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 9y ago
  Stop being so dramatic. Valuing users over developers is not malice, it's common sense.
  - francasso 9y ago
    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 9y ago
      > 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 9y ago
        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?
nilved 9y ago
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.
Cacti 9y ago
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 9y ago
  Is there a list somewhere of software which strives not to break the higher level things that depend on said software?
joering2 9y ago
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 9y ago
  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.
ajross 9y ago
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.
- rawnlq 9y ago
  There's a demo I wrote using jQuery UI Draggable that used to work with touch on mobile (using jquery ui touch punch) that no longer works. I actually had no idea what could've broke it until I saw this submission. It's still not going to be fixed though since I don't remember the code. I assume a lot of people are in a similar position.
- lukenyc 9y ago
  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.
Illniyar 9y ago
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.
styfle 9y ago
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 9y ago
  <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 9y ago
    > Drag/drop list reordering, pan/zoom image cropper I'm curious, were these implemented using a 3rd party library or developed in-house?
tehsauce 9y ago
I was a victim of this, thanks for pointing it out. Now I know what to fix at least!
bastijn 9y ago
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 9y ago
  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.

1187 points by bloomca 9y ago

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 9y ago
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.

est 9y ago

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.

just2n 9y ago

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?

sbussard 9y ago

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.

old-gregg 9y ago

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

Fede_V 9y ago

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.

pasbesoin 9y ago

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.

Waterluvian 9y ago

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

fiatjaf 9y ago

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.

datashovel 9y ago

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.

rpo1991 9y ago

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

nasso 9y ago

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

marijn 9y ago

> 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

glennblack 9y ago

The tricky thing is somewhere in the travel of the autocomplete

amandashye 9y ago

A browser program I run on my computer is Chrome.

JeanMarcS 9y ago

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

creative-coder 9y ago

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

minusSeven 9y ago

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

ipedrazas 9y ago

> Google wasn’t concerned about your websites at all. It was more concerned about its own product performance Why I'm not surprised?

stupidcar 9y ago
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.
- nsebban 9y ago
  Excellent point. Hopefully someday a "lean webpages" movement appears.
  - fenwick67 9y ago
    It's here and it's basically the brutalism of the web, see Craigslist or the Drudge Report, or just look at Hacker News. These are not "web 2.0" designed but they are easy to use and well organized.
    - what_ever 9y ago
      Except that Hacker News website is just dumb, lacks a ton of functionality and gets very basic design wrong. Have you looked at that upvote button? Is this a website for ants?
- disconnected 9y ago
  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".

acdha 9y ago

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 9y ago
I think the point of it was that they made every event listener passive by default, rather than making it an option.
- acdha 9y ago
  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.

Sir_Cmpwn 9y ago

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.

pvdebbe 9y ago
Except that Firefox LTS and other minority browsers suffer. I already use a couple sites that disregard all old Firefox compatibilities and use JS that break things up
- deno 9y ago
  How does this affect Firefox LTS? It doesn’t.
  - falcolas 9y ago
    Devs frequently assume "Chrome", because that's what they use. So, passing an unexpected argument to addEventListener will break LTS releases.
    - deno 9y ago
      This has nothing to do with making event listeners passive by default. If you don’t do feature detection then of course your website will not be backwards compatible. If you care about backward compatibility there exists a polyfill for this functionality.
      - falcolas 9y ago
        In saying that "Devs assume Chrome", I'm asserting that they do not do feature detection. However, that does not absolve Chrome of breaking backwards compatibility, workaround or not. Tossing the responsibility of dealing with their breaking changes back on the developer (with little notice) is what caused this article in the first place.

KeitIG 9y ago

> 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#c164 https://bugs.chromium.org/p/chromium/issues/detail?id=468153... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=587466 https://bugs.chromium.org/p/chromium/issues/detail?id=587466

hinkley 9y ago
This is just arrogance. From a historical perspective, this is nowhere near the sort of behavior one saw from Microsoft in the 90’s, but that’s pretty faint praise - nobody wants anything like that to happen again. You shouldn’t have people contributing to competing products out of spite. I hope we never hit the point again where it is a cliche for FOSS people to bond over shared hatred of a company. I’d like to think we have been inoculated against that. I like to see people who will speak up like this early and often.
drewmol 9y ago
As I've seen others mention, there seems to be a divide between the most user friendly behavior for: (1) public webpage w wide ranging user base that will be consistently updated and developed+ monitored for the widest compatibility, latest security, and (2) the CRM, intranet app, hardware config portal, etc. that will not. Any web devs have recommendations on how they handle the two circumstances?

untog 9y ago

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

kllrnohj 9y ago
The real problem here is the fact that active listeners are still a problem to begin with. It'd be absolutely insane if a native app did not get first crack at all input events. This is how they all work (iOS, Android, Windows - take your pick), and the mere existence of a touch/scroll listener is never a problem. But on the web simply having a scroll listener is such a massive performance issue that it's worth introducing not just a new API to get events after they've happened, but to then make that the default? Why not just fix the performance problem instead of hacking and slashing around it?
pier25 9y ago
The problem is that it wasn't only the scroll event but also the mousemove event. I maintain a library of interactive widgets for an education product with a lot of dragging and dropping and I was hit hard by this. I understand the reasons behind this, and I agree something thad to be done, but Google is making it difficult for devs to sympathise with the unilateral intervention. It's not the what, it's the how.
Sylos 9y ago
No, it's not to serve users. Users don't want broken webpages either. It's to make their own browser look faster at the expense of webpage authors. Because users will blame webpage authors for their webpage being broken. Would they know that they could have this same page unbroken with slightly worse performance, no one would choose the better performance. Sure, there's something to be said about webpage authors getting off their butts quicker, if their webpage is actually broken, rather than just not quite as fast as it could be, but the majority of webpages are not actively maintained. Chrome is simply breaking those. With only 8 months of a transitional period, there's no two sides to this argument. What they've done is unresponsible in every way.

moocowtruck 9y ago

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

trgv 9y ago

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 9y ago
> 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.

Klathmon 9y ago

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 9y ago
> "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 9y ago
  Except that millions of sites will not ever be fixed; they'll just be broken indefinitely.

lallysingh 9y ago

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

scott_karana 9y ago
In addition to the UA spoofing others mention, there's also forward conpatibility. If your app holds a mini "caniuse.com" UA-feature mapping, you have to keep it up to date infinitely forward in time, or new browsers won't work (think Brave/etc) Better to detect features directly, and reward anyone who implements them, rather than just hardcode the present incumbents.
falcolas 9y ago
Because browsers can and do lie? Often to get around such "serving the right version" logic. Or the "Browse the web faster and more securely, try (Chrome|Edge)" crap?
acobster 9y ago
Are you referring to user agents? Serving different code based on user agent is considered bad practice, and would be a maintenance nightmare. Not to mention, serving different JavaScript would make it more difficult to reason about what is running client-side. Plus, user agents are neither canonical nor necessarily even reliable sources of information about the browser.
breakingcups 9y ago
Because it's bad behaviour to rely on browser user agents instead of feature detection. It's what led to IE-only sites and is currently leading to Chrome-only sites.
- criddell 9y ago
  Are there Chrome-only sites? I'm sure they exist on LANs, but are there public sites that only work with Chrome?

dotdi 9y ago

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.

csallen 9y ago
> Yes, some people do it right Who? Any examples?
- diafygi 9y ago
  I normally hate scroll jacking, but the Australian news article on the NK ballistic missile range was pretty cool, even on mobile. http://mobile.abc.net.au/news/2017-10-16/north-korea-missile-range-map/8880894 http://mobile.abc.net.au/news/2017-10-16/north-korea-missile...
  - deleted 9y ago
    [deleted]
  - deno 9y ago
    This page doesn’t do scroll-jacking. Its state appears to update asynchronously based on the scroll position. That is the correct way to do this sort of thing. Scrolling on this article is buttery smooth on my Apollo Lake (1.1GHz Celeron) netbook, on both Firefox and Chrome, even if the background animations aren’t. No jank whatsoever.
    - Groxx 9y ago
      meanwhile... once I scroll to the globe, Chrome locks up. :| Scrolling in FF is indeed super smooth, but that background janks all over the place. Not sure what I'd prefer, tbh, though agreed that the vast majority of scrolljacking is utter garbage.

EGreg 9y ago

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 9y ago
> 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://.

jarym 9y ago

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 9y ago
> 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 9y ago
  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 9y ago
    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 9y ago
      'Why not?' you ask? Let's look at HIPAA for starters: 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 https://www.quora.com/Do-current-HIPAA-rules-require-publicl... "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.

s17n 9y ago

> 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 9y ago
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 9y ago
  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.

avodonosov 9y ago

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

matt_kantor 9y ago

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 9y ago
"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.

halayli 9y ago

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

flight21 9y ago

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

anodari 9y ago

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

hwu2whag 9y ago

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.

cosinetau 9y ago

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

iainmerrick 9y ago

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.

nitwit005 9y ago

> 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/supports https://developer.mozilla.org/en-US/docs/Web/API/CSS/support...

mathias 9y ago

> 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 9y ago
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 9y ago
  > In older browsers, useCapture is NOT an optional parameter Which browsers are those?

diiiimaaaa 9y ago

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 9y ago

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 9y ago
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 9y ago
  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 9y ago
    Right. The whole problem disappears if you just define a new function name.

francasso 9y ago

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 9y ago
Stop being so dramatic. Valuing users over developers is not malice, it's common sense.
- francasso 9y ago
  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 9y ago
    > 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 9y ago
      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?

nilved 9y ago

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.

Cacti 9y ago

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 9y ago
Is there a list somewhere of software which strives not to break the higher level things that depend on said software?

joering2 9y ago

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 9y ago
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.

ajross 9y ago

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.

rawnlq 9y ago
There's a demo I wrote using jQuery UI Draggable that used to work with touch on mobile (using jquery ui touch punch) that no longer works. I actually had no idea what could've broke it until I saw this submission. It's still not going to be fixed though since I don't remember the code. I assume a lot of people are in a similar position.
lukenyc 9y ago
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.

Illniyar 9y ago

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.

styfle 9y ago

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 9y ago
<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 9y ago
  > Drag/drop list reordering, pan/zoom image cropper I'm curious, were these implemented using a 3rd party library or developed in-house?

tehsauce 9y ago

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

bastijn 9y ago

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 9y ago
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.