Chrome breaks the Web
tonsky.me
tonsky.me
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...
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=587466
I'm all for empowering browsers to override abusive behaviour from websites, but using bad defaults and breaking innocent websites as a result is not the solution.
The browser is the agent of the user.
The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX better than Google/you, they're stuck with crappier security/UX and the market should sort it out.
I've actually managed to convince a company to stop prohibiting copy-paste on logins by pointing them at the new NIST password guidelines. I don't expect this to work for every company, but if they intentionally don't change, it's okay to name and shame them for it. Whether it's a UX sin or security voodoo.
The difference is that disabling of "autocomplete" is a user interface issue, and can be addressed by the browser I use. The problem of ridiculous password restrictions is not usually something that can be controlled by the client.
I like the idea of convincing IT to change crazy password policies, but I don't have the mental energy to navigate these huge bureaucracies.
If the Chrome team could figure out a way to force all of those sites to change their password restrictions through a Chrome update, they probably would.
What? No. Clearly it should never have been in the spec, and a browser should be the extension of the users desires.
You can also copy text with right-click -> Inspect Element -> copy($0.innerText). Although you'd use $0.value for an input or textarea.
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.
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.
You must decide that it's necessary. As an engineer, you are the most qualified individual to determine if something is technically necessary. Just like you decided that proper indentation, unit tests, refactors, etc. are important, so must we decide that other elements are.
That's exactly the point and you're essentially nitpicking (with anecdata) the fact that he pinned the problem on developers instead of product managers. Regardless of who is making the decision in companies, the end result is pretty much the same.
It brings the site closer to recommended accessibility guidelines, making it easier for e.g. people who have vision loss to navigate. It also reduces our potential legal liability to such users for not meeting accessibility requirements.
so what's the problem?
>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.
Its interesting that you're calling for a browser to not implement standards.
In any case, an advertising company would be the last entity who I would trust to do anything "good" with regards to the web.
The "standards" are created by the browser makers. It is up to them to decide what the standards are by choosing what to implement.
For instance, Apple can decide to not allow 3rd party cookies, which "breaks the web" and "doesn't follow standards" but it is also the right thing to do.
You're half right: standards are created by W3C & IETF, which includes browser makers.
> It is up to them to decide what the standards are by choosing what to implement
Kind of like IE and ActiveX, right? Right?
............Right?
The changes some browsers have made to autoplay videos or alerts do not contradict what is in the manual.
WHICH IS OKAY, if we're talking about security/privacy, but performance ... not really. Let the market (and the users) decide. If a site takes forever to load, and scrolling is impossible because it takes ages to scroll, and burns a mark in your palm in that time, then maybe you'll reconsider visiting that site ever again.
WHICH IS OKAY, if we're talking about security/privacy, but performance ... not really.
It's not automatically OK to break functionality even for security/privacy reasons, IMHO. Browsers are used for many useful purposes that do not involve visiting sites run by large organisations with full-time development teams assigned to ongoing maintenance. Intranets. Embedded UIs in devices. Personal sites full of useful information but with no-one actively maintaining them.
The number of breaking changes browser developers have been willing to make in recent years does not bode well for the future of the Web, a platform which became what it is today precisely because it was a known target for developers and for a few years the industry standards actually meant something.
The Brave New Web is one dominated by ego-stroking contests between the major browser developers and huge, centralised sites with effectively unlimited resources run by just a handful of organisations. Notice that neither users nor original content creators appear in that previous description. The original author here is quite right to call the big players out for that. We saw Microsoft's infamous embrace-and-extend strategy and the way the Web was held back for years as a result. We should be just as wary when the likes of Google sing the same song.
Then chrome Devs say to use autocomplete=something-stupid to get the specification behaviour of 'off' WTF is that?!
Donate to Firefox.
Chrome is the new IE
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Fo...
I'm all for moving the web forward and addressing stuff like this is a critical part of that, but this is not moving the web forward, this is moving Chrome forward, and in so doing breaking thousands if not millions of sites, and placing the burden of their repair on their developers with no notice and no better solution, just a different hack than the hack they were using.
Chrome is breaking 'autofill=false' on webforms because its really bad to have autofill=false most of the time. For example, this was breaking password managers, forcing users to have a worse experience around something as security critical as entering a password. If the goal is to have the user never remember their passwords to avoid phishing, this is a really important thing.
I'm entirely, 100% in support of them ignoring 'autofill=false' because most of the time I see this as a security flaw on websites. This isn't anticompetitive - they aren't trying to break websites on Firefox, they aren't contacting websites to get them to do some Chrome specific thing. They're ignoring a really bad default that hurts users.
While Chrome has the goal to destroy everything else.
Example 1: Google Chrome spam on youtube, gmail, every website on the internet. I can't count the amount of times my parents called and asked why Google asked them to "upgrade their browser" (hint: It wasn't a new Firefox-build).
Example 2: Sending email SPAM to all Google-users where they are advised to install Chrome if they ever sign in to their Google-account on a new machine using anything except Chrome.
Example 3: Installing Chrome unasked as drive-by installers when you install anything lots of freeware, because Google paid third-party developers to host Chrome as a spyware-like installation in their installer.
Google is using spyware techniques to deploy their fucking browser. Google is literally working on killing all other browsers.
And for the good of the web, this should be reason enough to instantly and permanently uninstall Chrome.
Had Microsoft done a fraction of this for anything they did, you'd seen social media and the EU causing a shit-storm. How come Google gets a free pass?
Also: "For most modern browsers (including Firefox 38+, Google Chrome 34+, IE 11+) setting the autocomplete attribute will not prevent a browser's password manager from asking the user if they want to store login fields (username and password), if the user permits the storage the browser will autofill the login the next time the user visits the page. See The autocomplete attribute and login fields."
(From: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Fo...)
Netscape is irrelevant. The fact is Chrome is using it's market dominance to affect the implementation of standards and in doing so, is breaking numerous websites. That IE is famous for but because Chrome is made by Google, it gets a pass.
> Chrome is breaking 'autofill=false' on webforms because its really bad to have autofill=false most of the time.
That is not the Chrome web-teams decision to make. The point of standards is that the standards should be followed, regardless of your or anyone elses opinion. If you disagree with a standard, you work to change the standard, you don't just change your browser's implementation of the standard, break a ton of functionality all over the web, and then sit there saying "well that's how it should be."
> This isn't anticompetitive - they aren't trying to break websites on Firefox, they aren't contacting websites to get them to do some Chrome specific thing. They're ignoring a really bad default that hurts users.
I agree with this in principle, but then they should be working to see that the standard is changed, and do so in such a way that the other browsers can follow suit and allow the standard to be improved. I don't disagree with the stance Google is taking; I don't like that one company is allowed to make such a sweeping change, and all the people who would get all over Microsoft's or Apple's asses about it if it was done in IE/Edge or Safari, are just all cool with it because again, Google is the golden child.
Chrome is the most used web browser
Chrome is deciding how the web should work unilaterally.
These are the exact conditions that produced ActiveX and resulted in many websites with an IE6-only requirement. As much as developers dislike having to design around the various browser quirks, the situation will get much worse if any one browser becomes "important" enough that you can forget the others.
Also, do you agree, in general terms, that sometimes changes can be good whereas other times changes can be bad?
The only big ones that are independent are Safari (since Google forked Webkit to create Blink), Firefox, and IE/Edge.
And the impression i have is that Safari is lagging, Mozilla is directionless and struggling to keep Firefox relevant, and MS is, well, MS.
Ever since Opera folded and made their browser a Chromium clone, only Mozilla have been carrying the banner for standard correctness. And even they seem more and more bow to Google's decrees (whole virtually cloning the Chrome look and feel with each Firefox update).
Have we not been there yet? Can we agree that that is a place of endless pain for developers, project managers and users as well?
Are you serious? No one thinks this way? I've worked at several companies where the software I've written was EXPLICITLY written with others in mind. To claim "rarely, if ever" shows that you know very little about this industry. Or, you surround yourself with a bunch of selfish people who shouldn't be doing software development.
But the megacorp Google is acting all altruistic and not at all abusing it monopoly powers?
Give me a break.
It's simply not realistic the 1000th time it's offered as the obvious solution.
If its not they should probably just work how everyone else works.
No, it's better for users who read the auto-filled boxes to make sure they are sane (which is what I do). It's not good for users that don't understand what auto-fill is (i.e. they think the website is suggesting it to them).
Except that whether it's better or not is probably contingent on the particular web site and particular user.
The settings that come with the markup are best understood as a recommendation, a slight hint that autocomplete might not be appropriate here. The final say is always with the user, though.
Sadly, through over-usage on the part of website operators, this hint has become utterly useless.
I think the solution is to follow the hint, but give users an override button next to or inside form fields that have it set to off.
This isn't what the autocomplete attribute was for in the first place; password managers have a different workflow and saving a password is prompted to the user, so we removed it. Password managers are not autocomplete features, basically.
Disabling autocomplete=off on everything doesn't seem to be a good change. Would love to be proven wrong but I don't think there are any ways autocomplete=off can be abused besides the password manager thing, and it's not worked on password managers for years.
I hereby confess to being guilty of adding autocomplete="off" to a login form, because the client's corporate IT only cared about ticking all the boxes on a security conformance report. We have tried to fight this and some other rules (e.g. log the user out after 20mins), because this was quite a simple website, but the rules were strict like it was online banking at the very least.
Now OWASP has changed their mind, but the damage has been done.
> Since early 2014 most major browsers will override any use of autocomplete="off" with regards to password forms and as a result previous checks for this are not required and recommendations should not commonly be given for disabling this feature. [1]
https://www.owasp.org/index.php/Testing_for_Vulnerable_Remem...
Yeah, I'm aware it used to be in conformance stuff (and probably still is in many cases). Super annoying when that happens :)
This is a continual frustration of mine, when valuable diagnostic data is disabled for security reasons and then when stuff breaks I'm asked to go fix it blind. Sure you can have gigabytes of audit logs that are impossible to find anything in, but an error message that tells you that some system certificate expired is too much of a security vulnerability.
Autocomplete=off is abused, certainly. It's commonly used to interrupt password manager functionality, in much the same way that copy/paste disabling is used on "repeat new password" fields. (As an aside: disabling autocomplete is a good idea, but only on the password manager level, not the website level. It's defense for user privacy, so employing it on well-meaning websites is worthless.)
But it's not abused in the user-endangering manner that circular redirects and back button hijacking have been. (Specifically, to make scam sites hard to escape and easy to click into.) It's just an inconvenience to users, and honestly I'm not thrilled to see browsers override code for non-security reasons.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=587466...
Personally, I installed a Safari plugin to ignore autocomplete=off because it was so annoying. So Chrome is doing what I want my browser to do.
This is precisely why I refuse to use Chrome.
I use Firefox and would do so even if it were an inferior browser, plus at this point in time and for my usage patterns Firefox really is superior.
If you have a simple web app that has an administrator mode for editing accounts, you should be able to turn off autocomplete so your password doesn't automatically get filled in for users that you edit.
It's that simple.
https://bugs.chromium.org/p/chromium/issues/detail?id=490015
https://bugs.chromium.org/p/chromium/issues/detail?id=696126
Broken WebGL anti-aliasing because:
> for now since it _shouldn't_ affect any actual devices
Except well... it did.
Philosophically-speaking some Web Platform developers think that it's more secure for the browser to autofill credentials from a keychain so that users can use better passwords and not be burdened with remember N-pseudo-random character sequences. Sounds good. Probably is good.
Whether or not you agree with the above there are plenty of regulations in certain setting that require us to disallow client applications from auto-filling form fields. We have to battle with the Web Platform authors to fill this niche and work around everything they put in our way to stop us from doing our job. Awesome.
Personally I thought feature detection was a smell and was glad to see it going the way of the do-do in the early aughts. Not so glad to see it making a come back.
> there are plenty of regulations in certain setting that require us to disallow client applications from auto-filling form fields.
And which regulations would those be, specifically?
From an ISO/IEC/IEEE 29148 perspective the language might be "shall not remember passwords" which would imply a legally binding requirement for compliance purposes.
This doesn't preclude applications from using autocomplete on form entry from password managers; just that the browser is not allowed to remember the entered password.
However in practice I've seen most systems deploy their applications on a target platform that runs the browser in "kiosk" mode, which if I recall from the time, was an IE-only thing. In more modern times we're starting to see consumer-level tablets and devices enter the mix and I'm not even sure if those can be locked down into a multi-user/kiosk type mode. Regardless... the web is a difficult platform for this kind of stuff.
If I had a penny for every time I've heard this excuse for really terrible unsafe practices just to find out that the developer deliberately misinterprets it to make its job easier... it be rather rich now.
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.
Every update of chrome erases their password manager entries. So for every site their password has to be re-entered.
Why is that dangerous? Because that means that my cousins and nephews other regular folks cannot trust Chrome to keep their passwords, so they must either reuse passwords or write them down somewhere. Obviously, a third-party password manager is simply not an option for these folks- they rely on the browser. The browser can get it right or get it wrong. Chrome gets it wrong.
That has not been my experience.
https://superuser.com/questions/926902/google-chrome-loses-d...
At least for me they don't. I have 2 passwords stored in Chrome (not a site important enough to go into KeePass), and have been through multiple updates and yet to lose any passwords.
It's been doing it for a while apparently.
https://superuser.com/questions/926902/google-chrome-loses-d...
Autocomplete is a security problem that can be used to get more information from users than they think they are providing - just ask for one field like email but put the other fields to be auto completed as hidden, and the browser helpfully gives the site all the other fields the user didn't realise are being autocompleted..
And that is how IE used to operate. I think this is something we're going to have to deal with for a long time.
As a developer, I have never used it anyway, so don't care.
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?
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/w3c/touch-events/issues/74 , 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.
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.
> 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.
I'm not talking about old sites; I'm talking about current sites. The old sites were illustrative examples of the backwards compatibility in the web.
The point is that the web has always been a platform you can deploy code to without needing to tend to it later.
This post is an example of it breaking a current site.
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.
In few years time, it will lead to the same thing happening to Chrome JS ecosystem
Unless their navigation interface used a Java applet.
The first part I agree with. The second, I don't understand.
.NET and Java are way more universal than assembly language unless you really split hairs and pretend "any byte code generated by a machine that ends up as assembly = assembly."
For the most part, Google is putting its developers ahead of your developers. They could have e.g. jitted scroll handlers to bail out of passive, but did not, and instead broke all active scroll listeners.
> 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.
And once again minorities get to visit the mass grave through no fault of their own.
Could they? From my understanding passive listeners do not stop execution, so even if a specific handler wants to bail out at run time it will already be too late to do so.
> once again minorities get to visit the mass grave
You don't think you're being a touch hyperbolic here? You can still use a non-passive listener if you want to, you just have to opt into it. Defaults should serve the majority use cases, that's the whole point of having them.
Code rot is very real for websites, and I worry that in the quest to do things 'right' Chrome is undervaluing the incremental harm done by every change. I don't think this action broke the web, but I'm wary of the idea that breaking changes can be casually blamed on the people who didn't update fast enough.
Change is bad, inasmuch as it makes new work for maintainers and harms user experience where maintenance isn't prompt. It's often necessary, but there ought to be an open discussion about timeframes and impact before a change happens. In this case, the discussion largely happened after the fact.
There was. In fact, there's a whole GitHub project dedicated to discussing proposed interventions like these: https://github.com/WICG/interventions
All interventions also get posted on the blink-dev mailing list before they are implemented: https://groups.google.com/a/chromium.org/forum/#!forum/blink...
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?
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.
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.
same with apple - "now we'll ignore user-scalable=no and screw every responsive webapp out there"
instead of user punishing badly behaved application, vendor are indiscriminately breaking well behaved apps whether they're doing the right thing or not (ie. apps that use em and thus respect user accessibility settings)
this leaves both developers AND users with a sub-par browser experience - like all canvas games out there now get zoomed on double taps, an animation which is often enough to stress the device gpu so much that the browser crashes.
I'm all for improving the web, but there are ways that work and there's this force feeding crap to developer without tough and foresight, and we as a community need to call what's good and what's crap for what it is.
I mean honestly you should have seen the writing on the wall with user-scalable: it inhibited the user from doing something they wanted to do, it hurt accessibility, it made websites imperceptibly inconsistent, and there isn't a good way of asking the user if they would like to disable zoom.
Whats wrong with "This page wants disable zooming. Allow?"?
That would fix the canvas web game usecase.
You know what's good for the web? Standards. Standards that are thoughtful and consistent.
Here are the comments on the property:
> Authors should not suppress (with user-zoom: fixed) or limit (with max-zoom) the ability of users to resize a document, as this causes accessibility and usability issues.
> There may be specific use cases where preventing users from zooming may be appropriate, such as map applications – where custom zoom functionality is handled via scripting. However, in general this practice should be avoided.
> Most user agents now allow users to always zoom, regardless of any restrictions specified by web content – either by default, or as a setting/option (which may however not be immediately apparent to users).
Maybe because 90% of responsive webapps would be better implemented as standard html websites which would improve performance and help preserving battery.
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.
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.
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.
Yes, it breaks some websites, and for those users in that moment things might be worse, but it is making the web better for significantly more people, and even the users affected aren't really "impacted" by it in most cases (generally only seeing "sticky" headers warp around while scrolling outside of a few specific types of applications).
This only affected websites which were using blocking scrolling event listeners. Scrolljacking, some mapping websites where you were able to tap and pan around, and some sticky headers, and only on mobile devices using chrome.
And of those features impacted, most weren't even "broken", they were simply delayed until after the user lets their finger off the screen. A "sticky" header will still work with this change, it will just "snap" into place after scrolling. Scrolljacking content will act in a similar manner.
I'm completely against breaking the web wherever possible, but in this case I really believe it to be worth it. Smooth scrolling makes sites usable, janky jumpy websites on mobile are so infuriating, and on lower spec devices can be completely unusable. This makes them usable again, it wasn't just "breaking the web" it was "fixing the web" for many people.
In my mind I see this like I see popup blockers or even adblockers built into the browser. Yes, they break functionality, but they do so for the user, and if the website needs to get around this change, they can easily do so without the user having to do anything (unlike popup and adblockers in most cases).
It's a simple question of cost benefit analysis. Some users are harmed by slow scrolling, others will be harmed by the update. There's not some obvious reason to prefer one group to the other absent an assessment of how many users are impacted and how bad the impact is.
In this case, the impact of slow scrolling affects almost everyone, and it's pretty bad. For a long time, I basically wouldn't bother to use my web browser on the phone.
The impact of breaking some scrolling behavior affects the users of a small number of poorly maintained sites, and in most cases, not in a way that actually breaks anything.
To me, the "terrifically isolated bubble" approach is to focus only on the part of the user experience you care about rather than balancing the pros and cons to all users.
What are you basing this on?
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.
The article has nothing to do with scroll jacking other than the fact that all JavaScript events are listened to via "addEventListener".
Unfortunately, browsers have a long history of giving sites the power to do things I probably don't want, like opening new windows, moving windows to the back, opening alerts that are implemented as modal dialogs (which block all tabs, even unrelated ones), and disabling context menus.
I guess they are trying to provide a rich set of capabilities to allow web devs to make neat things, but from my perspective as an end user, they're all about could, not about should.
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.
Exactly, I stopped using https://news.google.com because of its strange scrolling behavior on my phone.
Who? Any examples?
http://mobile.abc.net.au/news/2017-10-16/north-korea-missile...
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.
:|
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.
> 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.
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.
Google.
Google is also the pusher of some of the WebAPIs that will give browsers more access to your system (e.g. WebUSB [1])
Do you think Google is breaking JS to make themselves using less JS?
Consider that, to the user, these are all seen as website problems. Breaking Javascript with consensus is great - breaking designs without blame is a slap in the face to web developers.
Why stop there? I say let's make "if" conditions randomly work on false values 1/1000th of the time. That will teach them.
I'm no believer in Google's faux-altruism, much less sympathetic to their cause (see: AMP). The rollout could've been less agressive, sure. But I don't think equating a step towards sane default behavior with wrench-in-the-gears chaos adds much to the discussion.
It would be a straw man argument as a reply to the article, but it's a reply to a comment that advocates breaking the JS to make developers use it less.
But you know whats gonna happen right? Someone will create a “jqif” library that will run same if 10 times (maybe throw in a transpiler) or whatever then we’ll have 10 times slower javascript that fails with 1/10^11 chance.
Js is here to stay unfortunately.
Though not by pushing it down people's throats in a backwards-incompatible way.
> to make people use less JS and simpler JS on their websites
Let us return to a moment to the WWW's ripe vintage of 1995, when Netscape Communications Corporation released a browser which had 3/4 of the browser market share within a year of release. Their product was advertised as a consistent universal interface to the web. They created custom features for their product, such as SSL, and JavaScript. But many of the features were released to outdo its main competitor, Microsoft, who could dedicate far more resources to development (they had so much cash they didn't even need to charge for the browser!).
Netscape Communicator attempted to be a groupware solution combining multiple products to provide a complete solution for office and enterprise needs. But the design was too monolithic and complicated, and development was eventually halted. Ever since then, many organizations have attempted to build complete groupware solutions, but have been weighed down by the difficulty of developing such a complex suite of applications.
And so came the future. As the web's technologies progressed, so did the capability of content delivered through a "standard" web browser. Even though browsers have traded back and forth over who supports what, most of the time the browser with the majority market share holds all the cards. As long as that browser works the same on multiple platforms, they don't need to worry about cross-browser compatibility, because that isn't their goal. Netscape's original goal was to kill Mosaic, and they did that in spades.
Today, Google provides a mostly-complete groupware solution, delivered on its favorite application platform: its own web browser. The costs of developing and shipping the software to end users are much lower than traditional native apps, and they increasingly control more and more of the pipeline, even to the actual computer (Chromebooks are designed to cement Google's ownership of computing resources, freeing them from the constraints of other vendors' platforms).
They not only don't want you to have "less JS and simpler JS on a website", they don't want you to run a website. They want you to provide an application which runs on their application platform. In service of that goal, they have developed dozens of web technologies designed to further their own application platform, just like the Netscape of old. If they have to break compatibility with other browsers to do it, that's fine with them.
The bizarre thing is breaking existing websites on their own browser. If you can't browse the web reliably you'll stop using their browser, and then their app platform and apps are in danger of becoming obsolete.
If you care about backward compatibility there exists a polyfill for this functionality.
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.
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.
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.
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.
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.
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://.
Why I'm not surprised?
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.
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".
Hopefully someday a "lean webpages" movement appears.
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.
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.
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?
It might be a controversial opinion, but I think that the balance should always lean closer to the user's side, not developer's.
Forcing autocomplete in this instance does a dis-service to both users and developers.
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.
"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.
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.
“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.
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.
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?
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.
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.
I'm curious, were these implemented using a 3rd party library or developed in-house?
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.
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.
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.
It doesn't have to be trivial to be worth doing.
Yes, very much so. Especially on mobile, where UA-sniffing is rife.
Here's a very much non-exhaustive sample:
https://bugzilla.mozilla.org/show_bug.cgi?id=1047854
https://bugzilla.mozilla.org/show_bug.cgi?id=975444
https://bugzilla.mozilla.org/show_bug.cgi?id=1322001
https://bugzilla.mozilla.org/show_bug.cgi?id=958575
https://bugzilla.mozilla.org/show_bug.cgi?id=1020740
https://bugzilla.mozilla.org/show_bug.cgi?id=1232656
https://bugzilla.mozilla.org/show_bug.cgi?id=1377499
https://bugzilla.mozilla.org/show_bug.cgi?id=1393109
(funny what percentage of those are google.com sites....)
Although, it's not very good in Chrome either :)
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.
Having browsers identify themselves by the features they support would have been nice, but also very complicated, and it's not where we are now.
Or the "Browse the web faster and more securely, try (Chrome|Edge)" crap?
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?
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.
> 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.
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.
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?
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.
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.
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?
Which browsers are those?
"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.
> they made all top-level event listeners passive by default.
> Now, this is a terrible thing to do. It’s very, very, very bad.
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.
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.
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...
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.
- Its more customizable - Its more open and standards-compliant - It doesn't eat up all RAM - Its fast enough
I happen to visit an old unuqdated site from time to time now all I can read is gibberish.
What were they thinking??
Of course, sometimes it still is nice to be able to turn off alerts and then keep using the page.
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.
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.
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?
What will we do when they decide to make a change that isn't?