3 ms·
> 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,
by bryik 5y ago
> 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, and we should consider carefully whether we want to regress, even in an opt-in manner.
https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/Ut5AZXwuBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
- ricardobeat 5y agoI wonder what is user-hostile about it. Users have no concept of the event loop. Can’t remember being harmed by an alert() since forever. Last time was probably six or seven years ago when pop-under ads where still a thing.
- travisd 5y agoAlert (essentially) blocks the main UI thread. This means that if you have a while(true){alert} kind of thing, it can be impossible to exit the page since you first have to exit the dialogue before you can take any other action (but of course the dialogue is immediately retriggered). This is better nowadays, but can still cause issues.
- another-dave 5y agoI'd love to see figures on how many people this hits in the wild, especially since you have the "prevent this site creating more dialogs" option.
- ricardobeat 5y agoThis was solved many years ago by having dialogs scoped to the active tab. You can just close the tab.