Skip to main content

Bug Tracker

Side navigation

#5521 closed bug (wontfix)

Opened November 17, 2009 10:24AM UTC

Closed September 30, 2010 08:53PM UTC

Last modified May 20, 2013 10:47AM UTC

$(document).ready() firing too early probably in WebKit, and messing up the page

Reported by: kipras Owned by:
Priority: major Milestone: 1.4
Component: core Version: 1.3.2
Keywords: document ready webkit Cc:
Blocked by: Blocking:
Description

I have attached a website design, where adding the jQuery script breaks the website on WebKit based browsers (i have tried Google Chrome 3.0.195.27 and Safari 4 Public Beta 528.16 on Windows XP).

The page is displayed correctly in all browsers (Firefox, IE 6+, Opera), except the WebKit based browsers. When you load the page in Chrome or Safari, about 50% of the time you will see the three buttons where it says "Rezervavimas online", "Užsakymas" and "Stiklių apartamentai" get displayed one below each other, even though they are supposed to float left (note, that the other 50% of the time, everything gets displayed fine).

These buttons are actually <a href=""> tags that each have a div inside them and display:block attached to them. Now i know that this is not the best solution, but it works in every browser, and jQuery shouldn't mess that up.

Mind, that i mean adding the jQuery script just to be loaded - the website gets messed up, without any additional coding, just by loading the jQuery script. Without loading the jQuery script, everything is displayed fine in WebKit browsers. Comment it out and you will see.

I also found a fix to this situation. Add these lines between lines 3054 and 3055 in jquery-1.3.2.js (right after the line

document.addEventListener( "DOMContentLoaded", function(){

if (jQuery.browser.safari && document.readyState != "complete") {

setTimeout( arguments.callee, 100 );

return;

}

With this check, everything works fine.

Attachments (2)
  • html.zip (254.5 KB) - added by kipras November 17, 2009 10:28AM UTC.

    Here are the sources to the website design which shows the problem (use a WebKit based browser to see what i'm talking about)

  • jquery-1.3.2.fixed.js (118.1 KB) - added by kipras November 17, 2009 10:31AM UTC.

    This is the fixed version of jQuery 1.3.2, replace the original jquery-1.3.2.min.js with this one to see the problem go away.

Change History (16)

Changed November 19, 2009 07:18AM UTC by caii comment:1

GOOD!

I download and test your "html.zip", and the result is that the problem really as what you described.

between lines 3200 and 3207 in jquery-1.3.2.js, In order to achieve "jQuery.support.boxModel" .

There executed the first "ready" function . then maybe too early and messing up the page as you find.

Changed November 26, 2009 10:15PM UTC by yves.wdxperience comment:2

Thanks,

Your fix works in my website.

Changed December 16, 2009 02:22AM UTC by dmethvin comment:3

This is basically the patch. We'll need a better way to detect webkit though because

jQuery.browser.safari
will return false in 1.4 in Chrome for example.

		// Mozilla, Opera and webkit nightlies currently support this event
		if ( document.addEventListener ) {
			// Use the handy event callback
			document.addEventListener( "DOMContentLoaded", function DOMContentLoaded() {
+				if (jQuery.browser.safari && document.readyState != "complete") {
+					setTimeout( arguments.callee, 100 );
+					return;
+				}
				document.removeEventListener( "DOMContentLoaded", DOMContentLoaded, false );
				jQuery.ready();
			}, false );

Changed January 04, 2010 01:46PM UTC by 36Flavours comment:4

Has there been any progress regarding this ticket?

I tried the nightly build but found that no solution (neither this or an alternative) had been included.

Changed January 18, 2010 10:49AM UTC by kipras comment:5

This bug is still present in jQuery 1.4 !

Changed February 03, 2010 01:30PM UTC by kipras comment:6

I've recently encountered a similar situation in IE6, where loading jQuery also does some undesired changes to the page layout (tried versions 1.3.X and 1.4.X, and that happens on both).

I've played around with it a bit and tracked down, that the cause of this is indeed the jQuery.support.boxModel test as pointed out by caii, that screwes up the page layout. I've commented it out, and everything is fine then.

Anyway, i'm curious as to why this has not been fixed? Come on people, you've managed to add so many big changes to jQuery 1.4, and you can't fix one small problem? :))

Changed February 13, 2010 10:37AM UTC by nathanhammond comment:7

WebKit-based browsers do not calculate in the size of any images without width and height attributes on events triggered by DOMContentLoaded.

A quick review of the HTML provided shows that there aren't dimensions on the img tags, and thus the behavior seen in WebKit-based browsers.

I would say that this is expected behavior and that this ticket can be closed.

Changed March 26, 2010 05:14PM UTC by rasamassen comment:8

WebKit-based browsers do not calculate in the size of any images without width and height attributes on events triggered by DOMContentLoaded.

But IE,FF,and O do. I would say this is unexpected behavior in WebKit vs. any other standard browser. Make a simple page with a div containing an image of unspecified height and test height()/outerHeight(). IE,FF,and O will return a height that accounts for the image. Webkit-based browsers will not. But JQuery should return the same value no matter what browser it is run in.

Changed September 30, 2010 08:53PM UTC by addyosmani comment:9

resolution: → wontfix
status: newclosed

I agree with @nathanhammond that this is an issue with WebKit itself and that adhering to the image attribute requirements WebKit has will solve the issue.

When it comes down to individual rendering engines, I think that we need to leave it up to the engines themselves to manage how they output attributes such as image dimensions and that it's not the responsibility of the jQuery core to provide fixes for this type of behavior.

Changed October 23, 2010 09:57AM UTC by anonymous comment:10

I've reproduced this in Chrome5 with 1.4.2 even when the element in question DID have specified dimensions. For anyone else who experiences this I managed to work around it by putting the ready function at the bottom of the body, after the element in question.

Changed October 08, 2011 03:07AM UTC by my name is piano comment:11

Bumping bug because browser buffoonery boggles brain.

Changed July 30, 2012 04:37PM UTC by mykolenas@yahoo.co.uk comment:12

bump because the bug is still present in 1.7.2 :(

Changed July 30, 2012 04:44PM UTC by dmethvin comment:13

This isn't an AOL message board, bugs don't need a "bump". They need verifiable test cases.

Changed July 31, 2012 10:51AM UTC by anonymous comment:14

Replying to [comment:13 dmethvin]:

This isn't an AOL message board, bugs don't need a "bump". They need verifiable test cases.

want a testcase?

here's one:

$(document).ready(function() {

alert("I bet you can't see me after a refresh if you are using Chrome");

});

Changed July 31, 2012 11:04AM UTC by jaubourg comment:15

Replying to [comment:14 anonymous]:

Replying to [comment:13 dmethvin]: > This isn't an AOL message board, bugs don't need a "bump". They need verifiable test cases. want a testcase? here's one: $(document).ready(function() { alert("I bet you can't see me after a refresh if you are using Chrome"); });

http://fiddle.jshell.net/S4avC/1/show/light/

Oh, look, I refresh and get the alert all right.

Please, provide a usable and verifiable test case. If you can't, ask for support on a forum of your choice and/or IRC. Thank you.

Changed May 20, 2013 10:47AM UTC by anonymous comment:16

Still present on jquery 1.9.1, well done, I am not using jquery since is not reliable at all !