The Chrome team are a bunch of entitled jerks. They keep doing these things completely tone deaf and disconnected from the rest of the world. Unfortunately this seems to be fairly common with large software vendors in general, as soon as they have a captive audience they immediately turn hostile.
We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal
It ought to be a lot easier than this detective-work to discover this plan. Like, we should probably all know about it, and stop using these user-agent modals now working to replace all use of them?
(rails-ujs, for instance, still uses window.confirm for opt-in "are you sure" on form submissions. not sure what a good replacement is honestly. This is something I would hope to see people discussing and figuring out...)
oh wow. that's gonna break a LOT of things. I hope they agreed the value of that removal has to be very high for that level of breakage, and decided it was... if decision-makers just don't care about breakage anymore, that would be disturbing.
> being able to trigger alert from an iFrame that is being singlehandedly removed by the Chrome team.
Fixed that for you. It’s not being reconsidered; The Chrome team makes decisions for the web whether you agree with them or not. They might pull the “proposal” only to just do it again later. [1]
Disclaimer: I'm the one who made the change in [1] so I'm biased but...
IMHO the argument on the blog mischaracterizes the situation - Chrome didn't break these properties but changed how they're interpreted under pinch-zoom. This was done precisely to keep backwards compatibility (on desktop browsers): at the time, the vast majority of pages assumed pinch-zoom can't happen on desktop (something that was becoming more common). The status quo meant zooming in on a desktop page would cause it to "swim" as various "fixed" elements shifted around, JS drop-down menus appeared in the wrong place, etc. This happened virtually everywhere one looked: facebook, twitter, apple.com, etc.
The blog basically argues for "make pages fix themselves" which, even if major sites do, is unrealistic in the long tail.
> They might pull the “proposal” only to just do it again later
It's not nefarious, this often happens in response to feedback and real world experience to try and minimize disruption. In this case, developers convincingly argued that there should be an API to better react to pinch-zoom before making the change.
