This was a behavioral quirk that Patrick Mann asked me to look into. When an iFrame’s location is changed via window[0].location.replace() and the page is then refreshed, IE correctly honours the current URL rather than the src attribute — which is actually the right thing to do. However, inserting any HTML element into the page before the iFrame breaks that behaviour, and the iFrame reverts to loading its original src URL instead.

<div id="div_before_iFrame"></div>
&lt;iframe src="oldpage.html"&gt;&lt;/iframe&gt;
<iframe name="iFrame" width="300" height="200" src="oldpage.html"></iframe>

<script>
document.write("Random Number: " + parseInt(Math.random()*10000) + " (so you know for sure if the main page was reloaded after pressing F5)<br />");
try
{
 document.write("I have <b>full access</b> to window[0].document: " + window[0].document);
}
catch (e)
{
 document.write("<font color=\"red\">I <b>can not</b> access the window[0].document, even if the SRC attribute of this iFrame is in my domain.</font>");
}
</script>

<input type="button" onclick="window[0].location.replace('http://www.google.com');" value="Change iFrame source" />
<input type="button" onclick="document.getElementById('div_before_iFrame').innerHTML = '<span>I am a span</span>';" value="insert Element in the page" />

The reproduction steps are: change the iFrame source using location.replace, then insert an element before the iFrame, then press F5. The insertion causes IE to invalidate whatever history state was tracking the dynamic URL, so it falls back to the original src attribute. This is a subtle session-history fidelity bug rather than a security issue, but it can cause unexpected page state after reload.

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