Implement window.{alert, prompt, confirm} removal from cross-origin iframes (opens in new tab)

Alert is pure garbage and should not have made it past the 90s. Also, basic auth popups need to go too. Not sure why browsers would ever make those focus stealing in the first place. There should not be one single way for a web application to steal focus. The current workaround is to download a buggy ad blocker (last time I used chrome, just like firefox it has no way to turn popups off).

Edit: I just remembered alert no longer steals focus on modern browsers (IIRC). But basic auth still does (at least on my 50 year old fork of firefox).

They could oppose, but then Google would just spread propaganda about how their browsers are "less secure" or whatever. There's really no choice for other browsers at this point.

From the point of view of neutrality, the whole "origin trial" thing is seriously messed up. You are effectively having to ask for permission from one megacorp to treat your site differently from others in its browser.

And regardless of whether you think `window.alert` is a giant pile of tech debt: "we don't break userspace" is a mantra that web browser teams would benefit to heed.

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.

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.

> "We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome. Since PRs to the HTML spec require one more vendor to support (and none to oppose), we’ll reach out to other vendors before sending the PR."

The first comment response reads.....

> "Although the spirit is right, this isn't quite the correct approach procedurally. It's best to submit a specification pull request before any Intents are approved, to better help promote cross-vendor discussion, and allow the API owners to assess interop risk by looking at the spec (and accompanying web platform tests). The specification pull request doesn't have to be approved, but it should exist, so that there is a public record of what we are implementing at the level of detail of a full specification."

The next comment agrees.....

> "I'd like to second that. A part of the reason we have our launch process is to evaluate interop risk, which requires engaging with other vendors to see if they'd follow our path. A spec PR would enable them (as well as the API owners) to evaluate what this change actually means and allow them to express their opinions on it. FWIW, I'd be surprised if they weren't supportive of this, assuming we prove that this change is web compatible."

So here we see on full display Google acknowledge that they have enough market share to ignore other vendors, awknoledge that it is not in the web's best interest to do so, and yet somehow that part of the discussion was allowed to completely die out.

So yeah, switch to Mozilla. The conversation they had on the topic was much more aligned with what I want to see from my supply chain than the conversation I saw over at Google.

[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...

“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

When did my web site become a Google property?

My website has nothing to do with Google. Why should I have to agree to a contract with Google just so people can use my site?

Would you be fine with Facebook also forcing agreement with a contract just to view a completely third party website in a web browser?

Isn’t this expected? The other people can say whatever, but the final decisions will be made by people committing the code into major browsers. If they say “no, we won’t implement this”, what can others do?

From a quick look at the DOM, I'd bet dollars to donuts it's the weird combination of custom WebComponents and the #shadow-root stuff and other various markup excess that they just didn't bother to test with Firefox. Whether it's a bug with Firefox itself and how these elements are handled, I guess would need some investigation. But if it were my web app, I'd probably just fix it instead of blaming the browser.

Screen capture: https://imgur.com/RmoSZRB

However, the loss of system dialogs in favor for custom UI-kits implemented in the DOM is a major attack on accessibility.

Edit, regarding backward compatibility: A sustainable web-stack is really of major concern. For some decades now, most of human creativity and content production has been published on the Web, much of this exclusively so. Backward compatibility is important, if we don't want to leave a singular black hole as our legacy and as the heritage of future generations. For us as a society, as a culture, this is of much more importance than adding yet another fancy capability to the standard. – As it turns out, the singularity is not artificial superintelligence (ASI), but the evergreen browser and rolling web standards (EGB-RWS).

Remember: it's not about whether it's useful, it's about whether there isn't a better way to do it, because it's useful. In this case: yeah, absolute. There are way better ways.