5 ms·

This is peak Chrome; what seems to be a reasonably good idea that's hampered because it was pushed out thoughtlessly without putting any serious effort into not

This is peak Chrome; what seems to be a reasonably good idea that's hampered because it was pushed out thoughtlessly without putting any serious effort into notifying the people affected or making sure that nothing else breaks, or making sure that it thoroughly solves the problem. The product owners at Chrome are smart, but they're careless and constantly break the web because they don't seem to have enough of a sense of gravitas or caution about what they're doing. From what I can tell, this isn't a terrible change -- at least at first glance, it seems to me like we should probably remove prompts/alerts eventually. Just... competently remove them, without breaking people's sites and then shaming them for not keeping up with Chrome's official blog. I also love the juxtaposition here between how careless Chrome is about things like web audio/URLs/extensions, and how careful they've been recently about privacy and anti-tracking proposals. Heaven forbid that we block 3rd-party cookies by default without first rolling out 3 different proposals[0][1][2] and having an extensive very public debate about how to replace them. Breaking web audio for nearly every interactive site on the web (including timers on Google's own search page) is one thing, but breaking ads? That would be irresponsible. [0]: https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/ https://developer.chrome.com/docs/privacy-sandbox/first-part... [1]: https://developer.chrome.com/docs/privacy-sandbox/floc/ https://developer.chrome.com/docs/privacy-sandbox/floc/ [2]: https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/ https://developer.chrome.com/docs/privacy-sandbox/attributio...

throw_m239339 5y ago
> . The product owners at Chrome are smart, but they're careless and constantly break the web because they don't seem to have enough of a sense of gravitas or caution about what they're doing. Now imagine when Chrome has no competition whatsoever anymore, which will eventually happen. Google will control the web, at the very least on PC and Android, which is like 90% of the audience or something. They will take terrible, unilateral decisions because of their monopoly and "standards" will be as good as dead.
- deleted 5y ago
  [deleted]
ehsankia 5y ago
Hmm, the linked bug is from March 2020, and this thing will be Removed in December 2021. That's nearly 2 years, no?
- danShumway 5y ago
  Yes, and yet people were still caught off guard. Which is in some ways even worse to me, because what were they doing for those 2 years? When someone maintains the largest browser in the world, and almost every public website in the entire world relies on maintaining compatibility with that browser, then the standards for reaching out about breaking changes are a lot higher. The amount of time is only one aspect of this, the other is making sure that people actually understand the change is happening. That is of course, a wildly difficult problem. But while I'm sympathetic to the sheer difficulty of getting people's attention at that scale, I also feel that nobody is forcing the Chrome team to own the entire web. If they're going to be in that position, then they need to act like they're in that position. At the very least, what internal studies were done over those 2 years to check and see which sites would be broken? How did they miss services like Repl.it during those studies? My frustration with the Chrome dev team is that they handle feature changes and testing as if they're managing some kind of niche Open Source project, when in reality they are maintaining one of the most important pieces of software in the world. They're not Arch, they're not in a position where they can reasonably dismiss people who get caught by breaking changes because they aren't following the release notes. At the scale of Chrome it becomes their job to make sure website maintainers know about future changes and that nothing breaks.
  - ehsankia 5y ago
    > Which is in some ways even worse to me, because what were they doing for those 2 years? What everyone always does, which is put it off until the last minute. Also, unless there's actual breaking change, people often don't notice, hence putting it behind a Chrome Origin Trial for the last 6 months forcing people to actually address it.
madeofpalk 5y ago
So over a year ago they did publish their "Intent to remove" for this https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/JtkdpDd1BAAJ?pli=1 https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi... Honestly, what is the right way to "notify the people affected" for changes like this, apart from publishing them to their mailing list. There is no centralised place for these sorts of things, apart from each developer's mailing lists, or the standards mailing lists. I'm a web developer and I've never paid attention to the blink-dev mailing list, but perhaps I should more?
- gpm 5y ago
  1. Blog posts on a real big corporate blog, not on some mailing list no one reads. 2. A few months later: Warnings in the dev tools. 3. A few months after 2, at least a year after 1: Warnings on websites using the feature, for this feature it would probably have made sense to make a yellow or red ex through the padlock. 4. A year after 3, at least 2 years after 1, maybe actually consider actually removing it. It's folly to think that all important websites are actually maintained, it's certainly not the case that they can all roll out updates within months (think internal websites from vendored software that is rarely updated), and there's no reason to rush. I'd consider what I outlined here to be a very aggressive rollout schedule. Better than removing it entirely, would be to permanently put in a version of the feature that is still functional but avoids the issues with it. E.g. change the alert dialog to something hideous that clearly explains "this might not be from where it claims it is", but don't entirely break backwards compatibility.
  - gpm 5y ago
    The more general version of this is 1. Tell people who read the news (blog) 2. Tell people who make the thing you're breaking (devtools) 3. Tell users, but without breaking it since it's not something they can solve (padlock) 4. Maybe finally break it
  - Orphis 5y ago
    I've removed some feature from the web in Chrome after a long deprecation phase with warnings in devtools, proper announcements in ALL the relevant mailing lists and release notes. Still, many major websites broke as they failed to implement the very simple required changes in their products. Did they break in Chrome? No, we landed the change at a later date than announced. But Firefox did the same removal and it landed to stable a few weeks before Chrome. They also advertised for the removal extensively and were hit by all the "Major site X and Y are broken" bugs unfortunately. A couple days later, everything was fixed though, when Chrome's side of thing reached stable, no sites were really impacted. The replacement API had been available for many years before, people used the old non-standard and deprecated way still. So no, websites owner will not be proactive and fix their products no matter what you do unless they break. We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.

throw_m239339 5y ago

> . The product owners at Chrome are smart, but they're careless and constantly break the web because they don't seem to have enough of a sense of gravitas or caution about what they're doing. Now imagine when Chrome has no competition whatsoever anymore, which will eventually happen. Google will control the web, at the very least on PC and Android, which is like 90% of the audience or something. They will take terrible, unilateral decisions because of their monopoly and "standards" will be as good as dead.

deleted 5y ago
[deleted]

ehsankia 5y ago

Hmm, the linked bug is from March 2020, and this thing will be Removed in December 2021. That's nearly 2 years, no?

danShumway 5y ago
Yes, and yet people were still caught off guard. Which is in some ways even worse to me, because what were they doing for those 2 years? When someone maintains the largest browser in the world, and almost every public website in the entire world relies on maintaining compatibility with that browser, then the standards for reaching out about breaking changes are a lot higher. The amount of time is only one aspect of this, the other is making sure that people actually understand the change is happening. That is of course, a wildly difficult problem. But while I'm sympathetic to the sheer difficulty of getting people's attention at that scale, I also feel that nobody is forcing the Chrome team to own the entire web. If they're going to be in that position, then they need to act like they're in that position. At the very least, what internal studies were done over those 2 years to check and see which sites would be broken? How did they miss services like Repl.it during those studies? My frustration with the Chrome dev team is that they handle feature changes and testing as if they're managing some kind of niche Open Source project, when in reality they are maintaining one of the most important pieces of software in the world. They're not Arch, they're not in a position where they can reasonably dismiss people who get caught by breaking changes because they aren't following the release notes. At the scale of Chrome it becomes their job to make sure website maintainers know about future changes and that nothing breaks.
- ehsankia 5y ago
  > Which is in some ways even worse to me, because what were they doing for those 2 years? What everyone always does, which is put it off until the last minute. Also, unless there's actual breaking change, people often don't notice, hence putting it behind a Chrome Origin Trial for the last 6 months forcing people to actually address it.

madeofpalk 5y ago

So over a year ago they did publish their "Intent to remove" for this https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/JtkdpDd1BAAJ?pli=1 https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi... Honestly, what is the right way to "notify the people affected" for changes like this, apart from publishing them to their mailing list. There is no centralised place for these sorts of things, apart from each developer's mailing lists, or the standards mailing lists. I'm a web developer and I've never paid attention to the blink-dev mailing list, but perhaps I should more?

gpm 5y ago
1. Blog posts on a real big corporate blog, not on some mailing list no one reads. 2. A few months later: Warnings in the dev tools. 3. A few months after 2, at least a year after 1: Warnings on websites using the feature, for this feature it would probably have made sense to make a yellow or red ex through the padlock. 4. A year after 3, at least 2 years after 1, maybe actually consider actually removing it. It's folly to think that all important websites are actually maintained, it's certainly not the case that they can all roll out updates within months (think internal websites from vendored software that is rarely updated), and there's no reason to rush. I'd consider what I outlined here to be a very aggressive rollout schedule. Better than removing it entirely, would be to permanently put in a version of the feature that is still functional but avoids the issues with it. E.g. change the alert dialog to something hideous that clearly explains "this might not be from where it claims it is", but don't entirely break backwards compatibility.
- gpm 5y ago
  The more general version of this is 1. Tell people who read the news (blog) 2. Tell people who make the thing you're breaking (devtools) 3. Tell users, but without breaking it since it's not something they can solve (padlock) 4. Maybe finally break it
- Orphis 5y ago
  I've removed some feature from the web in Chrome after a long deprecation phase with warnings in devtools, proper announcements in ALL the relevant mailing lists and release notes. Still, many major websites broke as they failed to implement the very simple required changes in their products. Did they break in Chrome? No, we landed the change at a later date than announced. But Firefox did the same removal and it landed to stable a few weeks before Chrome. They also advertised for the removal extensively and were hit by all the "Major site X and Y are broken" bugs unfortunately. A couple days later, everything was fixed though, when Chrome's side of thing reached stable, no sites were really impacted. The replacement API had been available for many years before, people used the old non-standard and deprecated way still. So no, websites owner will not be proactive and fix their products no matter what you do unless they break. We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.