Bug Tracker

Opened 10 years ago

Closed 9 years ago

Last modified 7 years ago

#5521 closed bug (wontfix)

$(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 10 years ago.
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 10 years ago.
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.

Download all attachments as: .zip

Change History (18)

Changed 10 years ago by kipras

Attachment: html.zip added

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

Changed 10 years ago by kipras

Attachment: jquery-1.3.2.fixed.js added

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.

comment:1 Changed 10 years ago by caii

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.

comment:2 Changed 10 years ago by yves.wdxperience

Thanks, Your fix works in my website.

comment:3 Changed 10 years ago by dmethvin

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

comment:4 Changed 10 years ago by 36Flavours

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.

comment:5 Changed 10 years ago by kipras

This bug is still present in jQuery 1.4 !

comment:6 Changed 10 years ago by kipras

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? :))

comment:7 Changed 10 years ago by nathanhammond

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.

comment:8 Changed 10 years ago by rasamassen

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.

comment:9 Changed 9 years ago by addyosmani

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.

comment:10 Changed 9 years ago by anonymous

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.

comment:11 Changed 8 years ago by my name is piano

Bumping bug because browser buffoonery boggles brain.

comment:12 Changed 7 years ago by mykolenas@…

bump because the bug is still present in 1.7.2 :(

comment:13 Changed 7 years ago by dmethvin

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

comment:14 in reply to:  13 ; Changed 7 years ago by anonymous

Replying to 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");

});

comment:15 in reply to:  14 Changed 7 years ago by jaubourg

Replying to anonymous:

Replying to 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.

comment:16 Changed 7 years ago by anonymous

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

Note: See TracTickets for help on using tickets.