Opened 10 years ago
Closed 10 years ago
#12630 closed bug (duplicate)
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: |
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 10 years ago by
Resolution: | → notabug |
---|---|
Status: | new → closed |
comment:2 Changed 10 years ago by
Component: | unfiled → effects |
---|---|
Priority: | undecided → low |
Resolution: | notabug |
Status: | closed → reopened |
Despite the misunderstanding about asynchronous execution, I believe this is actually confirmed in chrome: http://gyazo.com/46a3f92e3cb9dbf1ebba402f538e3bf7
comment:3 Changed 10 years ago by
Status: | reopened → open |
---|---|
Version: | 1.8.1 → 1.8.2 |
comment:5 Changed 10 years ago by
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 10 years ago by
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 10 years ago by
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 10 years ago by
Owner: | set to mikesherov |
---|---|
Status: | open → assigned |
comment:10 Changed 10 years ago by
Resolution: | → duplicate |
---|---|
Status: | assigned → closed |
Duplicate of #11635.
http://jsfiddle.net/T96PF/
If the example isn't clear, please ask for help on the forum and not the bug tracker.