Side navigation
#4608 closed bug (invalid)
Opened April 29, 2009 07:24PM UTC
Closed November 17, 2010 04:00AM UTC
Last modified March 15, 2012 02:21PM UTC
Overflow left "visible" vs return to "auto" after animate on Safari on some MacBooks
Reported by: | gftn | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 1.4 |
Component: | core | Version: | 1.3.2 |
Keywords: | animate overflow Safari MacBook | Cc: | |
Blocked by: | Blocking: |
Description
On some (but not all) Macs running one of our apps under Safari (and not on other browsers or on Windows), after running an animate to change the height of a <div> that is a scrolling list (i.e., with overflow=auto) with a statement like:
$("#xxx").animate ({height:newHgt},XXXmsecs);
the list (quite repeatably) loses its scroll bar and spills on down the page. If you query the status of the overflow attribute after the event with:
$("#xxx").css("overflow")
the result is "visible". On other browsers/platforms, it's "auto" as expected.
Note that there are two other animates running along with this one (we're basically opening up a space for an image, making one <div> completely disappear and shortening the <div> containing list in question.)
If we explicitly reset the overflow to auto with:
$("#xxx").css("overflow","auto");
in the post-animate callback function (running off one of the other animates), it fixes the problem.
Attachments (0)
Change History (3)
Changed May 04, 2009 03:08AM UTC by comment:1
Changed June 04, 2009 02:23PM UTC by comment:2
Replying to [comment:1 dmethvin]:
Since the problem is repeatable...
We have determined that the problem is only with older versions of Safari: 3.2.2, 3.2.3 (maybe others but not in the 4.0 beta) on either Windows or Mac OS X. Your suggestion about race conditions was helpful and led to other fixes in the code. Will attempt to follow up with a small test case.
Changed November 17, 2010 04:00AM UTC by comment:3
resolution: | → invalid |
---|---|
status: | new → closed |
No test case and only for older Safari, so I'm closing this.
Since the problem is repeatable, please provide a simple test case. It sounds like the animates may be creating a race condition that only happens to occur in Safari, but the test case would help prove that.