#10335 closed bug (wontfix)

Opened September 23, 2011 06:32PM UTC

Closed June 06, 2012 01:26PM UTC

Last modified December 29, 2012 06:07AM UTC

In IE quirksmode, the "show" method, with a duration parameter, does not restore the element's original overflow values

Reported by:	whiskyConan	Owned by:	whiskyConan
Priority:	low	Milestone:	None
Component:	effects	Version:	1.6.4
Keywords:		Cc:
Blocked by:		Blocking:

Description

In Internet Explorer:

<html>

<head>

<style>

.Container

{

width: 20em;

height: 10em;

border: 1px solid #f00;

position: relative;

}

.InnerItem

{

width: 20em;

height: 4em;

border: 1px solid #0f0;

position: absolute;

left: 100%;

top: 0;

}

</style>

$(function ()

{

$(".Container:eq(1)")

.hide()

.show(200);

});

</script>

</head>

<body>

Outer Container

<div class="InnerItem">Inner Item</div>

</div>

Outer Container

<div class="InnerItem">Inner Item</div>

</div>

</body>

</html>

Locations in jquery-1.6.4.js:

Lines 8265-8267:

// when the animation starts, the overflow is set to hidden

if ( opt.overflow != null ) {

this.style.overflow = "hidden";

}

Lines 8523-8528:

if ( options.overflow != null && !jQuery.support.shrinkWrapBlocks) {

jQuery.each( [ "", "X", "Y" ], function (index, value) {

elem.style[ "overflow" + value ] = options.overflow[index];

});

}

(jQuery.support.shrinkWrapBlocks is true in IE quirksmode, so the overflow is never reset back to its original value, causing children to be hidden, like in the example)

Attachments (0)

Change History (11)

Changed October 07, 2011 01:45AM UTC by dmethvin comment:1

owner:	→ whiskyConan
status:	new → pending

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

Additionally, be sure to test against the jQuery Edge version to ensure the issue still exists. To get you started, use this boilerplate: http://jsfiddle.net/FrKyN/ Open the link and click to "Fork" (in the top menu) to get started.

Changed October 12, 2011 04:13AM UTC by whiskyConan comment:2

status:	pending → new

The test has been entered into jsfiddle:

http://jsfiddle.net/FrKyN/110/

However, jsfiddle injects a valid doctype declaration into the results iframe, and the bug cannot be reproduced via jsfiddle (except if using IE6).

Easiest way to see the bug is to copy everything between the <html></html> tags provided in the bug into a standalone file and run it in Internet Explorer.

I have verified that this bug still exists in the jQuery Edge version.

Changed October 13, 2011 04:17AM UTC by dmethvin comment:3

component:	unfiled → effects
priority:	undecided → low

Changed October 19, 2011 06:10PM UTC by timmywil comment:4

status:	new → open

Changed March 01, 2012 07:00AM UTC by jwoyame@gmail.com comment:5

I found that this also occurs in other browsers when you set the box-sizing of your div elements to "border-box":

html, body, table, div {
	-webkit-box-sizing: border-box;
	-moz-box-sizing: border-box;
	box-sizing: border-box;
}

Doing so triggers the "shrinkWrapBlocks" flag to be set in the jQuery code:

// Check if elements with layout shrink-wrap their children
// (IE 6 does this)
div.style.display = "";
div.innerHTML = "<div style='width:4px;'></div>";
support.shrinkWrapBlocks = ( div.offsetWidth !== 2 );

When an animation completes (in the step() function), jQuery will not reset the overflow style because this flag is set:

// Reset the overflow
if ( options.overflow != null && !jQuery.support.shrinkWrapBlocks ) {

	jQuery.each( [ "", "X", "Y" ], function( index, value ) {
		elem.style[ "overflow" + value ] = options.overflow[ index ];
	});
}

However in the animate() function, it changes the overflow:

if ( isElement && ( name === "height" || name === "width" ) ) {
	// Make sure that nothing sneaks out
	// Record all 3 overflow attributes because IE does not
	// change the overflow attribute when overflowX and
	// overflowY are set to the same value
	opt.overflow = [ this.style.overflow, this.style.overflowX, this.style.overflowY ];

...
}

if ( opt.overflow != null ) {
	this.style.overflow = "hidden";
}

So the overflow style is getting changed but not fixed after the animation completes. The solution should be one of the following:

A. Do not change the overflow flag if shrinkWrapBlocks is set.

B. Reset the overflow flags to their original value in all cases.

I tested this issue in Chrome 17.0.963.56.

Changed June 06, 2012 01:02PM UTC by kleinhans@boerse-go.de comment:6

This bug is still there in 1.7.2 with webpages that change box-sizing to "border-box" as described in the comment above.

I just noticed it with Chrome 20.0.1132.21

I could imagine this bug becoming more troublesome in the future when more sites start using the box-sizing property. Do you need a new testcase or any additional information?

Changed June 06, 2012 01:26PM UTC by mikesherov comment:7

resolution:	→ wontfix
status:	open → closed

We do not support quirks mode: http://docs.jquery.com/Won't_Fix

Also, there are a few fixes for box-sizing that will be coming in 1.8. Please test again jQuery edge using jsfiddle.net if you suspect there might be a bug. If you find one, submit it as a bug. As of right now, there is no bug except your imagination.

Changed December 29, 2012 02:40AM UTC by pha3zme@gmail.com comment:8

I read the won't fix page on this issue. There's no where to comment on that page so I'm commenting here. This is a *serious* problem. Most designers and developers who know what's going on are trying to get away from from the WC3 box model. Its flat-out junk. Border-box is the future and just writing this off as a 'won't fix' bug simply because it doesn't conform to WC3 is ridiculous.

Especially considering the fact that the WC3 has an absolute ly pitiful history of applying terrible standards that fail (they do this because secret they're trying to control the internet but that's another story). Fact is that browser vendors and developers have always lead the way and the WC3 ends up changing their model to conform to the masses. Thank God the masses *tend* to know whats best when it comes to development tools. Its one of the few cases where that holds true.

The fix to this problem in Chrome is simple. All you have to do is set overflow: visible after the animation completes. I easily fixed it for Superfish, but I'm also going to have to patch HelloBar and anything else that breaks.

The jQuery team needs to re-evaluate their decision to base things on WC3 standards and stop writing off better models as just "quirks modes". This issue should be able to be resolved without completely overhauling jQuery animation. I'd be impressed if someone could show a reason why a simple patch wouldn't do the trick.

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

pha3zme@gmail.com, thanks for contributing. I personally did a lot work to ensure a border-box future for jQuery 1.8 :-).

Border-box and quirks mode are very different things. Quirks mode is not supported, border-box is. There are several open assigned bugs I'm working on to address the overflow problem when NOT in quirks mode.

Please don't confuse the two, and have a nice night.

Changed December 29, 2012 03:49AM UTC by mikesherov comment:10

And just for the record, #12630 was already an open bug for precisely this issue. The fix IS trivial.

Changed December 29, 2012 06:07AM UTC by anonymous comment:11

Thanks mikesherov. I guess I didn't understand what was being said previously. I already don't consider border-box to be part of quirks mode. And that's why I was shocked by what I was seeing. I thought that the discussion was stating that border-box is only a quirks-mode feature. I'm glad that's not what was being said.

Side navigation