Skip to main content

Bug Tracker

Side navigation

#12630 closed bug (duplicate)

Opened September 28, 2012 11:38PM UTC

Closed December 29, 2012 04:25AM UTC

slideUp sets overflow: hidden and slideDown does not restore the original element's overflow.

Reported by: Owned by: mikesherov
Priority: low Milestone: None
Component: effects Version: 1.8.2
Keywords: Cc:
Blocked by: Blocking:

The following example shows the diviation:

window.m = $("<div />").appendTo("body");
m.css("overflow"); // prints "visible"
m.css("overflow"); // prints "hidden"
m.css("overflow"); // prints "hidden"

The overflow css property is being set to assist in the visual aspects of the effect. Once slideDown is finished the item should be back to it's original state, including overflow. The above example should result in "visible" for the final .css call.

Attachments (0)
Change History (10)

Changed September 29, 2012 01:24AM UTC by dmethvin comment:1

resolution: → notabug
status: newclosed

If the example isn't clear, please ask for help on the forum and not the bug tracker.

Changed September 29, 2012 02:44AM UTC by mikesherov comment:2

component: unfiledeffects
priority: undecidedlow
resolution: notabug
status: closedreopened

Despite the misunderstanding about asynchronous execution, I believe this is actually confirmed in chrome:

Changed September 29, 2012 02:44AM UTC by mikesherov comment:3

status: reopenedopen

Changed September 29, 2012 02:53AM UTC by dmethvin comment:4

Strange, I'm not seeing a problem here with Chrome 22.0.1229.79 m

Changed September 29, 2012 03:04AM UTC by Joseph Lennox <> comment:5

My original test was typed one line at a time into the console, it should of taken async into considerations via callback for clarity of the bug case, but async wasn't an issue in my production.

Using the jsfiddle test from dmethvin the issue is not replicating in the same copy of Chrome as my test. Copying and pasting his into my websites console does replicate the issue (can not provide link in public, sorry). Running it on also does not replicate the issue.

This caused me to assume it's some other code causing the issue. I tested not loading jQuery UI and upgraded to jQuery 1.8.2 (from 1.8.1), neither fixed the issue.

However, if mikesherov is running into this issue then there might be something that's less specific than my setup happening here.

I intend to debug into jQuery and resolve the issue come next week.

Chrome Version 22.0.1229.79 m

Changed September 29, 2012 02:36PM UTC by Joseph Lennox <> comment:6

After some investigation, the following line is resulting in "true" because div.offsetWidth is set to 2.

support.shrinkWrapBlocks = ( div.offsetWidth !== 3 );

If I manually set this value to false in the console, = false;

The test passes as visible/hidden/visible.

Removing the following CSS causes that div.offsetWidth to compute "properly" to 3 and for the visible/hidden/visible result to show as expected.

body p, body div, body span, body input, body button, body textarea, body a {
box-sizing: border-box;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
-khtml-box-sizing: border-box;
-o-box-sizing: border-box;

This can be demonstrated live here:

All of this is on Chrome 22.0.1229.79 m

Changed September 29, 2012 05:44PM UTC by dmethvin comment:7

Thanks for tracking this down! So was that CSS in your original page? The shrinkWrapBlocks feature detect is meant for IE6 which doesn't support border-box, so we can move it inside some other related guard condition if it helps.

Looks like there was a tangential mention of this in #10335.

jQuery 2.0 can't come soon enough.

Changed December 29, 2012 03:43AM UTC by mikesherov comment:8

owner: → mikesherov
status: openassigned

Changed December 29, 2012 03:48AM UTC by mikesherov comment:9

#12854 is a duplicate of this ticket.

Changed December 29, 2012 04:25AM UTC by mikesherov comment:10

resolution: → duplicate
status: assignedclosed

Duplicate of #11635.