title: Stuck setTimeout()s (Chrome)
body: <p>I have a situation where multiple <code>setTimeout()</code> calls (typical length: 100ms to 1 sec) are active and should have gone off, but they do not fire. A Chrome (Mac) debugger profile shows &quot;idle&quot; during this (potentially infinite) period.  The profile shows that nothing is going on.  No loops.  No code running. No garbage collection. No activity whatsoever.  The viewport is active and has focus.  After I wait (potentially an infinite time), when I &quot;do something else&quot;, like <code>mouseover</code> some unrelated element -- as simple as a :hover -- the logjam breaks and the queued <code>setTimeout()</code>s all fire.</p>
  <p>When I set breakpoints in the <code>setTimeout()</code> handler functions after this &quot;freeze&quot; occurs, they get hit in sequence when the logjam breaks, just as you would expect.</p>
  <p>Unfortunately the replication path is difficult. So far, creating simpler test cases just makes replication even more difficult or, ultimately, impossible.</p>
  <p>Most of the chatter around <code>setTimeout()</code> &quot;issues&quot; is from people who don't understand the single-thread nature of jscript, etc., so it is not helpful. Let me repeat: the timers are queued and should have fired.  The browser is idle, as proved by the profiler.  The timers DO fire ultimately, but only after mouse activity occurs. This behavior seems very wrong to me.  If the browser is idle, and there are events in the queue, they should fire.</p>
  <p>Has anyone seen behavior like this?  Have I stumbled across a way to lock up the event dispatcher?  Maybe I'm missing something.</p>
  <p>Update: Cannot replicate on Windows 7.</p>
  <p>Update 2: Restarted Chrome on Mac, can no longer replicate.  So, worst possible outcome: no answer as to why it happened, why it kept happening, why it didn't happen reliably, why it went away, and why it won't happen any more.</p>