Bug Tracker

Opened 7 years ago

Closed 7 years ago

#12630 closed bug (duplicate)

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

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

Description

The following example shows the diviation:

window.m = $("<div />").appendTo("body");
m.css("overflow"); // prints "visible"
m.slideUp();
m.css("overflow"); // prints "hidden"
m.slideDown();
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.

Change History (10)

comment:1 Changed 7 years ago by dmethvin

Resolution: notabug
Status: newclosed

http://jsfiddle.net/T96PF/

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

comment:2 Changed 7 years ago by mikesherov

Component: unfiledeffects
Priority: undecidedlow
Resolution: notabug
Status: closedreopened

Despite the misunderstanding about asynchronous execution, I believe this is actually confirmed in chrome: http://gyazo.com/46a3f92e3cb9dbf1ebba402f538e3bf7

comment:3 Changed 7 years ago by mikesherov

Status: reopenedopen
Version: 1.8.11.8.2

comment:4 Changed 7 years ago by dmethvin

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

http://imgur.com/79bQg

comment:5 Changed 7 years ago by Joseph Lennox <jlennox@…>

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 jQuery.com 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

comment:6 Changed 7 years ago by Joseph Lennox <jlennox@…>

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, jQuery.support.shrinkWrapBlocks = 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: http://jsfiddle.net/wZdJF/

All of this is on Chrome 22.0.1229.79 m

comment:7 Changed 7 years ago by dmethvin

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.

comment:8 Changed 7 years ago by mikesherov

Owner: set to mikesherov
Status: openassigned

comment:9 Changed 7 years ago by mikesherov

#12854 is a duplicate of this ticket.

comment:10 Changed 7 years ago by mikesherov

Resolution: duplicate
Status: assignedclosed

Duplicate of #11635.

Note: See TracTickets for help on using tickets.