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: | jlennox@gmail.com | 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.
Attachments (0)
Change History (10)
Changed September 29, 2012 01:24AM UTC by comment:1
resolution: | → notabug |
---|---|
status: | new → closed |
Changed September 29, 2012 02:44AM UTC by comment:2
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:
Changed September 29, 2012 02:44AM UTC by comment:3
status: | reopened → open |
---|---|
version: | 1.8.1 → 1.8.2 |
Changed September 29, 2012 02:53AM UTC by 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 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 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
Changed September 29, 2012 02:36PM UTC by 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, 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
Changed September 29, 2012 05:44PM UTC by 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 comment:8
owner: | → mikesherov |
---|---|
status: | open → assigned |
Changed December 29, 2012 04:25AM UTC by comment:10
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.