javascript error in IE8 when animating element is removed before animation finishes

[JorisDebonnet]

I had some IE8 users report that my application was sometimes 'crashing', and it took me many, many hours to pinpoint the problem (because all IE8 said was: 'unspecified error' somewhere in jQuery). I should just have used a non-minimized version of jQuery to save me those hours, but anyway.

Apparently, if an element's scrollTop is being animated, and that element is removed during the animation, then jQuery will crash in IE8. In the git at the time of writing, it's on line 8499 in a piece that extends jQuery.fx's step, and says:

fx.elem[ fx.prop ] = fx.now;

​http://jsfiddle.net/NGBaX/2/ (note: I always need to run it twice before it crashes)

[Timmy Willison]

I'm unable to reproduce the crash, but I do notice a javascript error. Regardless, you should probably stop the animation before the removing the element.

[JorisDebonnet]

Well, yes, the javascript error is what I mean. Since it also affects future animations, at least in my application, I called it a 'crash'. In my application's case, even logging out would not work anymore ... since that does an animation (which only redirects the page upon finishing it).

It does sound sensible of course to stop the animation before removing the element, but it was not obvious to think about it in my case. It's a stylized dropdown in a form that is slid up when an input element is blurred. Makes sense to me, but 'sadly' this element is of course also blurred when the form is submitted via ajax, which (when response is received) overwrites part of the page. And, well, the ajax call seems to return faster than the animation, so it does that. :)

(I temporarily solved my app by simply removing scrollTop from the animation)

So anyway, all this just to say that I do believe it's something a developer should be able to rely on, in complicated systems :)
The point is perhaps that scrollTop is not very often animated, leaving the problem unreported until now.

[gnarf]

Originally commented on this pull: ​https://github.com/jquery/jquery/pull/542#issuecomment-2369920

---

I really really dislike this "catch and release" pattern here... There HAS to be a better way to fix this bug.

Timmy's suggestion in the bug ticket has some merit, to fix the crash/bug you just need to .stop() the animation before removing the element - which makes sense anyway...

Why are we still animating an element that has been removed? Should these timers be stopped? etc..

---

If we are going to fix this bug, we should probably be REMOVING the timers from jQuery.timers in cleanData. If not, we need to tell users to .stop() before .remove(), but that has problems. It's probably easier for us to remove timers than it is for the user to .find("*").stop().end().remove();

[gnarf]

​https://github.com/jquery/jquery/pull/543

[mikesherov]

Gnarf, you mentioned you were going to roll this up into the animation rewrite. The fiddle is still failing on edge.

[gnarf]

I'll jump on this one soon.

[Corey Frang]

Fix #9217. oldIE error when changing detached elements, close gh-861

Changeset: 74cc5b0984335532ab272b8286566000c4bf3daf