jQuery: Ticket #9789: If an animation 'complete' callback throws, it will keep getting invoked repeatedlyhttps://bugs.jquery.com/ticket/9789
<p>
See <a class="ext-link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=669107#c4"><span class="icon">​</span>https://bugzilla.mozilla.org/show_bug.cgi?id=669107#c4</a>
</p>
<p>
Basically, if a 'complete' callback throws, its corresponding animation will keep going, and any later animations won't be processed correctly at all.
</p>
en-usjQuery//jquery.com/images/logo.gifhttps://bugs.jquery.com/ticket/9789
Trac 1.2.3timmywilSat, 09 Jul 2011 16:04:05 GMTpriority, status, component changed; resolution sethttps://bugs.jquery.com/ticket/9789#comment:1
https://bugs.jquery.com/ticket/9789#comment:1
<ul>
<li><strong>priority</strong>
changed from <em>undecided</em> to <em>low</em>
</li>
<li><strong>resolution</strong>
set to <em>wontfix</em>
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>component</strong>
changed from <em>unfiled</em> to <em>effects</em>
</li>
</ul>
<p>
This cannot be changed unless we want to go back to the old queue order. However, if callbacks do not throw errors (which they shouldn't after debugging), everything works fine so I'm not sure having a disordered queue is worth the fix. Ideally, we could use a try {} finally {}, but this causes problems in IE if there's no catch (which we can't add for debugging reasons). And setTimeout(f, 0) would be unpredictable. If we want to maintain consistent behavior across browsers, it should probably stay as is.
</p>
Ticket