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.

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)

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

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!

Automatically closed due to 14 days of inactivity.

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!

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.

Pic is unrelated: http://item.rakuten.co.jp/icefield/1848041/

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.

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.