Google has a vested interest in doing so, and change is their weapon; it keeps control of the web in their hands when no other organisation has enough brute force to keep up with their changes.
Why only remove it from iframe and not the entire browser if that is the concern?
Why was this concern not alleviated with better UI for the standard alert dialogs?
Alert dialogs and prompts are huge for accessibility - they're genuinely one of the best ways to get a screenreader's attention and have the user interact immediately with something. They are great for the web. They provide a standard interface and I think we should use them more often.
To me, this is Chromium team doing one of two things: (1) Trying to fix a security concern and instead of improving the UI so it's clear where the dialog is coming from, being lazy and just turning the feature off, or (2) Boiling the frog: remove dialogs from iframe, wait a while, then remove them from top-most with the rationale that "hey, they're already not supported in iframes" because they think dialogs are so Web 1.0
I don't like it either way. Just let me opt-in via `sandbox` like I do for other iframe features. Honestly, even that's rude to make website developers have to do, but at least we're not left high and dry.
I'll be irrationally angry if this all boils down to some UXD thinking that alert dialogs are "ugly" or something.
Definitely more often than whatever hacky edge case websites relies on this behavior.
These are not common-use-cases-for-average-websites-on-the-net, but for web _apps_ where third-party `iframe` is the quickest way to real isolation between divergent code, iframes are pretty common. And `alert`, `confirm`, and `prompt` are not common in such code either, but when they are used they're often used in code paths that expect blocking behavior and are therefore definitely not amenable to alterations.
And the fact of the matter is that as the developer of a web application _I can still get this blocking behavior_. "All you need to do is have the parent and the child cooperate by sharing a TypedArray between the origins and use `Atomics.wait`" [1]. If by having the parent and the child cooperate I can get the blocking behavior, why not allow me to do it simply with a `sandbox` attribute, rather than having me publish a `@backcompat/alert` NPM module that both sides can pull in to polyfill a functioning `window.alert`?
This is one of the most common phishing vectors.
Simply false. This change broke several of my companies apps, and it broke Salesforce, and God knows what else. And it's not just a layout problem; it's material behavior which changed.
take 1: Salesforce is already a broken heap of fertilizer
take 2: Hmm, didn't Google try and fail to acquire Salesforce?
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).
Since you're obviously from the future, can you give me tips on some stocks or sporting events to "invest"?
Not to count years literally.
If the problem is "this functionality steals focus", how about making it not steal focus rather than removing it entirely on short notice? Why don't the Chrome developers focus on fixing their browser?
Though they may need to move beyond the line of death to mitigate spoofing.