Bug Tracker

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#7130 closed bug (invalid)

getScript in Firefox fires success before script is loaded

Reported by: johncongdon Owned by:
Priority: undecided Milestone: 1.4.3
Component: unfiled Version: 1.4.2
Keywords: Cc:
Blocked by: Blocking:


I am using getScript to load some jQuery plugins and trying to initialize as soon as the script is loaded.

I have found that if I use set timeout to wait a few seconds, the script will be ready. However I am just creating a race condition. If the script doesn't become ready, then I will still have issues.

Change History (4)

comment:1 Changed 12 years ago by addyosmani

Resolution: invalid
Status: newclosed

Could you please re-submit your ticket with a sample of the code being used (and a reference to the plugins that you are trying to load) using getScript?.

There are a number of factors that could be affecting why this isn't working and it would help us greatly if we could avoid speculating what the cause of the problem is before we've seen what your code is doing.

We'll be happy to investigate once this has been done. Thanks!.

comment:2 Changed 12 years ago by Hannes

I am seeing this too. It is very hard to reproduce as it seems to be a proper race condition. One out of 10 to 20 times the callback fires before the loaded script has finished executing. Contributing factors in my case might be the use of iframes and that the embedding page as well as the embedded page do XHRs and dynamic script injections simultaneously. The workaround for me is to force "remote" script loading which causes jQuery to inject the script as <script src="$url"></script> rather than <script>$xhr_response</script>. In that mode, the callback is invoked as an onload event handler attached to the injected script tag which seems to work more reliably.

Firefox 3.6.12, Mac OS X 10.6.4 (10F569), jQuery 1.4.3

You can force "remote" loading either by specifying an absolute url whose protocol (or host) is differs from location.protocol (or location.host). I can't do this in my specific case, so I had to patch jQuery

Index: jquery-1.4.3.js
--- jquery-1.4.3.js	(revision 5503)
+++ jquery-1.4.3.js	(working copy)
@@ -5584,7 +5584,7 @@
 		// Matches an absolute URL, and saves the domain
 		var parts = rurl.exec( s.url ),
-			remote = parts && (parts[1] && parts[1] !== location.protocol || parts[2] !== location.host);
+			remote = s.forceRemote || parts && (parts[1] && parts[1] !== location.protocol || parts[2] !== location.host);
 		// If we're requesting a remote document
 		// and trying to load JSON or Script with a GET

and use the following function instead of $.getScript

var loadScript = function( url, callback ) {
	return jQuery.ajax( {
		type: "GET",
		url: url,
		data: null,
		success: callback,
		dataType: 'script',
		forceRemote: true // this is the key
	} );

comment:3 Changed 12 years ago by [email protected]

Looks like I'm one of the few that has encountered this bug as well. I was able to reproduce it all the time because we run Selenium automated tests, on some of the pages the above situation occurred. The solution above worked for me, here is the updated version.

For jQuery 1.5+ :

var getJSScript = function( url, callback ) {

return jQuery.ajax( {

type: "GET", url: url, data: null, success: callback, dataType: 'script', cache: true, crossDomain: true this is the key

} );


comment:4 Changed 12 years ago by Domratja

I hade this exact problem in FF 3.6.17 and it was solved by removing a broken script resource, I was linking to a JS-document that wasn't there and that returned a 404. Somehow that might have messed up the execution order?

Note: See TracTickets for help on using tickets.