Setting screen.updateInterval to a very large value prevents IE from repainting the window after navigation. The user can change URLs, but the browser won’t visually update unless they scroll, resize, or switch focus to another window and back. The property isn’t reset on navigation, leaving the browser effectively broken for rendering.
<!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>PseudoDOS_screen_updateInterval</title></head>
<body>
<font size="2" face="Tahoma">
<center>
<h2>pseudoDOS_screen_updateInterval</h2>
This is a very silly bug, but it will render the Browser unusable. The property <b>updateInterval</b> from the <b>screen</b> object
is not being "reseted" when you change the URL. That ends up in a browser that does not refresh, unless you fire an event that repaints
the window (scroll, resize, unfocus/focus, etc).
Let's <a href="http://www.google.com">go to Google</a> and see...<br><br>
You can keep changing the URLS (addressBar) and still, the browser will not refresh unless you scroll, resize, or focus a
different window and come back to this one.
</center>
<hr />
screen.updateInterval=100000;
<hr />
</font>
<script language="JavaScript">
screen.updateInterval=100000;
</script>
</body>
</html>screen.updateInterval controls how often the screen object updates its properties, but its side effect of throttling repaints was apparently not scoped to the current document. Setting it to 100,000 milliseconds means IE waits nearly two minutes between repaints — long enough to look completely broken. Any repaint-forcing event like scrolling still works because those bypass the interval check.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.