Implement window.{alert, prompt, confirm} removal from cross-origin iframes

What about folks who've registered for either origin trials or Google Search Console? Or Google Analytics?

That said, I'd love it if telemetry APIs were baked into the web, perhaps OpenTelemetry API support? Then website owners could set up their own error reporting OTLP endpoints or services to receive sampled deprecation alerts in a standard way, rather than assuming everybody can read the developer console in an end-user's browser (especially when it's hidden most of the time...)

Bonus points if we can ignore errors caused by extensions, or have extra feedback as to which extensions might be causing problems. Double bonus points if there's a UI so end users can choose whether to share this data or not, or to cache and sync the data so it only gets shared when on wifi or idle, in an extremely compressed way, and to provide a settings screen where you can browse what telemetry or errors are shared from/to websites in your history.

Okay, let's try another angle. Does the Chrome team have any stats at all about how many developers were informed about this change and were able to adapt to it before it went live?

You're right, some people are going to slip through the cracks, that's inevitable. How many people? How does the Chrome team determine if they're doing a good enough job with communication, what metrics for developer uptake are even being measured here? Is the Chrome team watching any public spaces like Twitter or Reddit to see whether or not changes are actually being seen and disseminated in developer communities?

You're phrasing this as if it's just a subset of developers who didn't realize what was going on. I would surprised if that's the case, I suspect the vast majority of developers did not realize what was going on.

> I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.

Also can't stress this enough, still more users than read the mailing lists. They will still get more traction than Chrome's existing announcements. You don't have to stop posting to the mailing lists, just put a little bit of effort into going into communities where developers actually spend time.

We know that developers don't read the mailing lists. So let's try to find out what they do read.

> Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself.

Definitely, but this is a really tone-deaf response to people telling the Chrome team that they have a problem with communication.

This is also one of my evergreen complaints about how breaking changes work in Chrome -- it always ends up being phrased as either the developers fault or an unsolveable problem. The best we can get is "all sides can maybe do better at broadcasting information". Yes, we have to treat Chrome like it might break our stuff randomly. We have to constantly be engaged in the web standards process, even when it's exhausting, even when it means we're drinking a firehose of information. Yes, we need to set up automated testing for all of our projects, we can't put sites up online and expect them to keep working.

We do our best to mitigate the problems that the Chrome team is causing by refusing to proactively reach out, by refusing to do anything beyond just posting their changes and giving people time to read them. And we don't get any indication that the process is ever going to improve.

Please meet us halfway.

Or at least the Chrome team could take your own advice and ask itself what it can do to make messaging more effective, rather than "only asking what developers should do for them" to make breaking changes go more smoothly.

So the "you'd catch all these changes if you were testing" excuse honestly kind of rubs me the wrong way, because as far as I can tell Google itself has trouble meeting that standard for even its biggest products.

You believe that Apple and Mozilla are rubber-stamping anything Google asks for because they’re afraid of a Google marketing campaign.

Have I accurately represented your beliefs?

People are just human, they will fail to understand changes sometimes and their impact. Or maybe, they're just not going to be listening at all. Or they saw it, and then a coworker interrupted them and they forgot. If you tell people that the Earth temperature is going to raise 1 degree, most will just glance over it and not understand the ramifications.

In the end, I don't know that much about this specific change, it's not my domain of expertise, but I know you can't expect random people to receive random messages from random sources. First it doesn't scale, and second it would be preferential treatment which doesn't seem to me in line with the healthy platform the web should be.

> What view of the web does the Chrome team have if they think the majority of site operators have this kind of testing setup running?

No, it's a personal opinion.

And yes, I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular. If you're only reacting to breakage instead of being proactive, you'll never be able to have a service continuously running and should lower your expectations. The platform is evolving and changing. Most of the time, the impact will be negligible, but sometimes it's not, and you should be prepared. Or you should just freeze all software updates in your company context until you can vet that every critical component works fine.

> It should not have been a surprise to some of the biggest REPL sites on the web that their products were about to break

REPL websites are still largely working though, my samples are still working the same, I just don't use the affected APIs which I've avoided for a long time already. If they care deeply about some specific scenario, they should probably be tested. And every failure to catch an error is an opportunity to learn, for all sides involved.