Skip to main content

Bug Tracker

Side navigation

#7261 closed bug (patchwelcome)

Opened October 20, 2010 08:55PM UTC

Closed December 23, 2010 03:54AM UTC

Last modified March 14, 2012 01:43AM UTC

Body Table

Reported by: wray@wraybowling.com Owned by: wray@wraybowling.com
Priority: undecided Milestone: 1.5
Component: support Version: 1.4.3
Keywords: Cc:
Blocked by: Blocking:
Description

Lately, I have been using an experimental layout method in which I turn the entire <body> tag in to a table.

html{height:100%}
body{display:table; width:100%; height:100%;}

After those main parameters are set, I use a div that acts as a row via display:table-row, and then another div with display:table-cell. The model, essentially works just like a Web 1.0 tables layout and I've had a lot of fun using it with great success. (one of the lovely things about it is I don't need to know the height of the footer to make it sticky and nonblocking)

However, when jQuery is included, even the newest version, Webkit breaks. The body still reaches to 100% height of the viewport, but it appears as if the bottom of the page is about a sixth up from where it should be.

Observe this example page I've put together. Right away, in Chrome or Safari, you will see the white at the bottom of the page. However, comment out jQuery, and the page renders properly:

<!doctype html> 
<html> 
<head> 
<meta charset="utf-8"> 
<style> 
*{ margin:0 }
html{height:100%; overflow-y:scroll;}
body{ display:table; width:100%; height:100%;}
.wrapper{ width:700px; margin:0 auto;}
.table{display:table;}
.row{ display:table-row; }
.column{ display:table-cell; }
.sticky{ height:1px; }
</style> 
<!--<script src="http://code.jquery.com/jquery-1.4.2.min.js" type="text/javascript"></script>-->
<script src="http://code.jquery.com/jquery-1.4.3.min.js" type="text/javascript"></script> 
<script src="../js/filler_text.js" type="text/javascript"></script> 
</head> 
<body> 
<div class="sticky row"><p>All these are evidently sections, as it were,</p></div> 
 
<div class="row"> 
	<div class="wrapper table"> 
		<div class="row"> 
			<div class="column" style="width:200px;"><p>Three-Dimensional representations of his Four-Dimensioned being, which is a fixed and unalterable thing.'</p></div> 
			<div class="column"><p>'Scientific people,' proceeded the Time Traveller, after the pause required for the proper assimilation of this, 'know very well that Time is only a kind of Space. Here is a popular scientific diagram, a weather record.</p></div> 
		</div> 
	</div>	
</div> 
 
<div class="sticky row"> 
	<div class="wrapper"><p>first</p><p>sticky</p><p>footer</p></div> 
</div> 
<div class="sticky row"><p>bottom sticky footer</p></div>
<script>
	function ranHex(){return '#'+Math.floor(Math.random()*16777215).toString(16);}
	var divs = document.getElementsByTagName('div');
	for(var i=0; i<divs.length; i++){
		divs[i].style.background = ranHex();
	}
</script>
</body> 
</html>
Attachments (0)
Change History (11)

Changed October 20, 2010 09:31PM UTC by addyosmani comment:1

owner: → wray@wraybowling.com
status: newpending

You don't appear to be using jQuery on your page (other than including it) - could we see the contents of the filter_text.js file?. Merely including jQuery on your page should almost never cause this behavior unless there's something in your code that is causing an issue with it.

Changed October 21, 2010 01:47AM UTC by jitter comment:2

I can confirm this bug. And it is triggered by just including jQuery on the page (no other javascript executed neither normal nor jQuery based). It also seems to only happen in Webkit based browsers (Chrome, Safari).

The cause is this W3C box model test in support.js (I guess this actually is a Webkit bug to be reported)

I also tested Opera 10.62, FF 3.6.10 and FF 4.04b where it works just fine (can't test IE 6/7/8/9 at the moment).

I made a stripped down test-case (which I can't attach as there seems to be no option to attach a file) thus I provide this jsfiddle version of the testcase which resamples it.

Expected result:

Two colored rectangles each claiming 50% of the browser window. One red in the upper half and one yellow in the lower half

Opera with jQuery (thumbnails are clickable)

[[Image(http://b.imagehost.org/t/0398/chrome_7261_without_jquery.jpg, link=http://d.imagehost.org/0067/opera_7261.jpg)]]

Part[1 / 2] (as TRAC thinks my comment is spam - too many outbound links)

Changed October 21, 2010 01:48AM UTC by jitter comment:3

_comment0: Part [2 / 2] \ \ Chrome with jQuery and Chrome without jQuery \ [[Image(http://d.imagehost.org/t/0381/chrome_7261_with_jquery.jpg, link=http://d.imagehost.org/0381/chrome_7261_with_jquery.jpg)]] \ [[Image(http://b.imagehost.org/t/0398/chrome_7261_without_jquery.jpg, link=http://b.imagehost.org/0398/chrome_7261_without_jquery.jpg)]] \ \ If you remove the above highlighted test from `support.js` it works fine. \ \ If you just comment every line out in this support-test which accesses either `div.offsetHeight` or `div.offsetWidth` it also works fine. \ \ Conclusion: \ \ The support test adds a normal div (`display:block`) at the end of a `body` with `display:table`, does some tests and manipulations and then removes the div. \ \ Accessing the `offsetHeight / offsetWidth` attribute of this div triggers the faulty behavior in Webkit. \ \ The problem seems to be that Webkit after removing the div doesn't reclaim the space it has taken up and thus doesn't "resize" the other elements to fill the space. \ \ The same behavior can be achieved in Opera and FF by removing this [http://github.com/jquery/jquery/blob/97dfa0d5a85a32fe56aba837bbf2bc889b092d2b/src/support.js#L170 line] from `support.js`. \ \ So Webkit behaves as if the div wasn't removed altogether \ \ P.S.: Sorry for this massive post. But some lines where needed to explain this strange bug. Hope it helps some1287625761000133

Part [2 / 2]

Chrome with jQuery and Chrome without jQuery

[[Image(http://d.imagehost.org/t/0381/chrome_7261_with_jquery.jpg, link=http://d.imagehost.org/0381/chrome_7261_with_jquery.jpg)]]

[[Image(http://b.imagehost.org/t/0398/chrome_7261_without_jquery.jpg, link=http://b.imagehost.org/0398/chrome_7261_without_jquery.jpg)]]

If you remove the above highlighted test from support.js it works fine.

If you just comment every line out in this support-test which accesses either div.offsetHeight or div.offsetWidth it also works fine.

Conclusion:

The support test adds a normal div (display:block) at the end of a body with display:table, does some tests and manipulations and then removes the div.

Accessing the offsetHeight / offsetWidth attribute of this div triggers the faulty behavior in Webkit.

The problem seems to be that Webkit after removing the div doesn't reclaim the space it has taken up and thus doesn't "resize" the other elements to fill the space.

The same behavior can be achieved in Opera and FF by removing this line from support.js.

So Webkit behaves as if the div wasn't removed altogether

P.S.: Sorry for this massive post. But some lines where needed to explain this strange bug. Hope it helps some

Changed October 21, 2010 01:42PM UTC by anonymous comment:4

http://jsfiddle.net/zZLds/

Here's my original example on jsfiddle. It occurs in JQuery 1.3.2 and up.

By the way, the filler_text.js was originally just there to fill in, you guessed it, text which i left out because it's the whole first chapter of the Time Machine. :P

Thanks for checking this out!

Changed November 11, 2010 11:09PM UTC by trac-o-bot comment:5

status: pendingclosed

Automatically closed due to 14 days of inactivity.

Changed November 15, 2010 05:13PM UTC by jquery@kenman.net comment:6

Replying to [comment:5 trac-o-bot]:

Automatically closed due to 14 days of inactivity.

So well-documented, reproducible bugs are automatically closed when there's been no activity for 2 weeks?

That's kind of messed up.

The user did everything that they could to help further the diagnosis and rectification of this bug; what more could they have done, aside from actually fixing it? The ball was obviously in *your* (jQuery's) court!

Changed November 16, 2010 03:50AM UTC by snover comment:7

status: closedreopened

The original report was marked as requiring additional clarification, and the original reporter’s account was not used to respond to the test case (the same person may have responded but as “anonymous”, which our system can’t identify), so this state was never cleared. This sort of mechanism is necessary in order to prevent the bug tracker from filling up with abandoned tickets.

In the future, if you want to request that a closed ticket be re-evaluated, please try to do so without being so confrontational. We are all volunteers, and we are trying very hard to make sure that limited resources are being used as efficiently as possible. If you feel that our current policies or practices are not as good as they could be, we would be happy to accept your time and effort to improve them.

Changed November 16, 2010 04:06AM UTC by paul.irish comment:8

Changed November 20, 2010 02:24AM UTC by dmethvin comment:9

component: unfiledsupport
keywords: → needsreview

Wow, this is a pretty crazy corner case. As jitter observed, jQuery expects to be able to append content to the body in support.js where we do feature detection, and also effects.js where we append an element to the body to determine its default display state. If the whole body is a table this will create an invalid document.

I'll leave this open, assign it to the "support" category, and mark it needsreview for now, but it's very likely to be closed wontfix or patchwelcome.

Changed December 23, 2010 03:54AM UTC by dmethvin comment:10

_comment0: I'm going to close this ticket patchwelcome. It may be possible to work around the issue, but the effort required to do that and ensure no regressions for the other 99.9% of the time is beyond the benefit for the jQuery team to dedicate time to it. \ \ To solve this particular error it *might* be as simple as checking that document.body.style.display=='' or 'block' in support.js and skipping the feature tests. But that also impacts the cases we are trying to feature detect and jQuery's behavior on some operations. It would all need thorough testing. \ \ There is lots of other jQuery code in the wild, including plugins, that expect to be able to append elements to the body (e.g, dialogs and tooltips). I think that would be the downfall of any plan to turn the body into a table.1293076499177756
resolution: → patchwelcome
status: reopenedclosed

I'm going to close this ticket patchwelcome. It may be possible to work around the issue, but the effort required to do that and ensure no regressions for the other 99.9% of the time is beyond the benefit for the jQuery team to dedicate time to it.

To solve this particular error it *might* be as simple as checking that document.body.style.display=='' or 'block' in support.js and skipping the feature tests. But that also impacts the cases we are trying to feature detect and jQuery's behavior on some operations. It would all need thorough testing.

There is lots of other jQuery code in the wild, including plugins, that expect to be able to append elements to the body (e.g, dialogs and tooltips). I think that would be the downfall of any plan to turn the body into a table.

Changed December 23, 2010 03:55AM UTC by dmethvin comment:11

keywords: needsreview