Bug Tracker

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#10335 closed bug (wontfix)

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:

<!-- missing doctype to force IE into quriksmode -->

<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>

<script src="jquery-1.6.4.js"></script> <script>

$(function () {

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

.hide() .show(200);

});

</script>

</head> <body>

<div class="Container">

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

</div>

<div class="Container">

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)

Change History (11)

comment:1 Changed 8 years ago by dmethvin

Owner: set to whiskyConan
Status: newpending

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.

comment:2 Changed 8 years ago by whiskyConan

Status: pendingnew

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.

comment:3 Changed 8 years ago by dmethvin

Component: unfiledeffects
Priority: undecidedlow

comment:4 Changed 8 years ago by timmywil

Status: newopen

comment:5 Changed 8 years ago by jwoyame@…

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:

  1. Do not change the overflow flag if shrinkWrapBlocks is set.
  2. Reset the overflow flags to their original value in all cases.

I tested this issue in Chrome 17.0.963.56.

comment:6 Changed 7 years ago by kleinhans@…

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?

comment:7 Changed 7 years ago by mikesherov

Resolution: wontfix
Status: openclosed

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.

comment:8 Changed 7 years ago by pha3zme@…

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.

comment:9 Changed 7 years ago by mikesherov

pha3zme@…, 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.

comment:10 Changed 7 years ago by mikesherov

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

comment:11 Changed 7 years ago by anonymous

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.

Note: See TracTickets for help on using tickets.