Google Chrome to remove alert() inside cross-origin iframes in a future version

twitter.com

14 points·thiscatis··4 comments

not just alert but also prompt(), confirm(), etc. And from what I can tell there's not even an option to turn them back on, like some other sandbox rules that are available from iframes (not 100% certain about this but that was my takeaway skimming the relevant bug report on monorail)

This is Google trying to eliminate part of a web standard because their WebKit implementation is bad and those things block the event loop and cause all kinds of headaches.

I would prefer an os-native alert() over some monstrosity of a jQuery UI message box any day...

> This is Google trying to eliminate part of a web standard because their WebKit implementation is bad and those things block the event loop and cause all kinds of headaches.

Funny, Didn't realize Firefox ran on webkit/blink as well, just tested an alert(..) box in there and what do you know, the setInterval(..) that ran also locked up until the alert was dealt with... [1]

Hate on google chrome dev team for this, it was shittly managed, but don't make baseless claims as to the why.

As to the issue at hand, For a group of devs (Google) that LOVE to mess around with changing UI on every product they can every year to justify a payrise or pad their CVs.... NONE OF THEM THOUGHT TO REDESIGN THESE POPUPS INSTEAD??

[1] : https://jsfiddle.net/garqhjzo/1/

The javascript spec requires a setinterval to block... Thats as intended.

What isn't intended is that all kinds of management messages that involve the renderer will block, like for example closing the tab, printing the page, spellchecking, adding to bookmarks, etc...

A few of those things Chrome works around with a nested event loop that only handles certain types of events, but it's very fragile and a big maintenance burden, so they want to get rid of it.

Reply on news.ycombinator.com