According the documentation in your link
"""""""""""
We cannot show simple dialogs for a Window window when the following algorithm returns true:
1. If the active sandboxing flag set of window's associated Document has the sandboxed modals flag set, then return true.
2. If window's relevant settings object's origin and window's relevant settings object's top-level origin are not same origin-domain, then return true.
3. If window's relevant agent's event loop's termination nesting level is nonzero, then optionally return true.
4. Optionally, return true. (For example, the user agent might give the user the option to ignore all modal dialogs, and would thus abort at this step whenever the method was invoked.)
5. Return false.
"""""""""""
Additionally, the MDN documentation describes the chrome change as
"""""""""""
Starting with Chrome 46, this method [alert] is blocked inside an <iframe> unless its sandbox attribute has the value allow-modals.
"""""""""""
First of all, I am wondering, is the MDN described Chrome change actually an implementation of the "WhatWG" described algorithm line #2?
Secondly, the MDN description states "... unless its sandbox attribute has the value allow-modals" which, I believe, means that the page hosting the iframe can optionally permit the iframe content to throw up an alert box. So a web page designed can choose to allow it iframe contents to throw up alert boxes. The article fails to mention this.
Given that an alert box loop can be used to disable user operation (maybe as a delay tactic while other nasty stuff is going on) I would say there is good reason to tightly control its use.
Biting the hand that feeds IT
