Side navigation
#9217 closed bug (fixed)
Opened May 10, 2011 08:19PM UTC
Closed July 23, 2012 02:18AM UTC
javascript error in IE8 when animating element is removed before animation finishes
| Reported by: | JorisDebonnet | Owned by: | gnarf |
|---|---|---|---|
| Priority: | low | Milestone: | 1.8 |
| Component: | effects | Version: | 1.6 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
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;
(note: I always need to run it twice before it crashes)
Attachments (0)
Change History (11)
Changed May 10, 2011 08:53PM UTC by comment:1
| component: | unfiled → effects |
|---|---|
| priority: | undecided → low |
| status: | new → open |
| version: | git → 1.6 |
Changed May 10, 2011 09:15PM UTC by comment:2
| _comment0: | 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. → 1305062244094498 |
|---|
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.
Changed October 11, 2011 07:23PM UTC by comment:3
| milestone: | 1.next → 1.7 |
|---|---|
| owner: | → gnarf |
| status: | open → assigned |
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();
Changed October 11, 2011 07:58PM UTC by comment:4
Changed October 24, 2011 04:14PM UTC by comment:5
| owner: | gnarf → timmywil |
|---|
Changed November 11, 2011 01:54PM UTC by comment:6
| milestone: | 1.7 → 1.next |
|---|
Changed April 05, 2012 03:13AM UTC by comment:7
| owner: | timmywil → gnarf |
|---|
Changed June 16, 2012 02:43PM UTC by comment:8
| milestone: | 1.next → 1.8 |
|---|
Gnarf, you mentioned you were going to roll this up into the animation rewrite. The fiddle is still failing on edge.
Changed June 19, 2012 12:34PM UTC by comment:9
| summary: | jQuery crashes in IE8 when scrollTop-animated element is removed → javascript error in IE8 when animating element is removed before animation finishes |
|---|
Changed July 03, 2012 05:35PM UTC by comment:10
I'll jump on this one soon.
Changed July 23, 2012 02:18AM UTC by comment:11
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fix #9217. oldIE error when changing detached elements, close gh-861
Changeset: 74cc5b0984335532ab272b8286566000c4bf3daf
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.