This is a regression with the new alert dialog behavior in Safari 9.1. If this should be reclassified to a different component or refiled in Radar, please let me know. Safari 9.1 introduced a new auto-dismissal feature with alert dialogs, where alerts are dismissed when switched away from. Unfortunately, it doesn't block alerts happening in background tabs, which leads to issues. Repro: 1. Go to http://www.w3schools.com/jsref/met_win_alert.asp 2. Click the "Try it yourself >>" button. This will result in a new tab. 3. In the new tab, paste in to the left side this code, and click "See Result >>" ---8<--- <html><body> <button onclick="myFunction()">Go</button> <script> function myFunction() { setTimeout(lalala, 5000); } function lalala() { alert("hi"); } </script> </body></html> ---8<--- 4. Click the "Go" button in the right pane. 5. Within the next five seconds, switch back to the original tab. 6. After five seconds, attempt to interact with the original tab. You'll find that because the background tab has shown an alert, it has locked up the foreground tab and all other tabs that share a renderer. In addition, it's worse, because there is no UI affordance to let the user know *why* their tab locked up. They have to poke around at all the tabs to see which one was showing an alert.
<rdar://problem/25397627>
Here's a simpler repro that demonstrates the problem more clearly: http://output.jsbin.com/mijefe This seems likely to hit users in practice. Eg. I click on links in my gmail that open new tabs, then one of them happens to spawn an alert box while it's in the background - boom of those tabs become unresponsive without any indication of which tab has the dialog box :-(
To help us prioritize, has anyone observed this in the wild on a real site?