Response title
This is preview!
Move this topic
ScriptCommunicator for $.ajax script/jsonp loading
Maybe later
- Maybe later
- Under review
- In-progress
- Implemented
- Will not implement
in Developing jQuery Core
•
9 years ago
Amix from Plurk has developed a cross-browser solution to detecting ajax script load failures.
See the code here:
This would be a useful addition to the jQuery core.
Can this be added?
2
Replies(4)
Seems a little bit dicey - it requires modification of the script in order to get any useful information (which doesn't happen all that often - and when it does, it's likely already on your own domain so you're using XHR anyway). At this point I'm not really sold.
I think that modification of the script wouldn't be needed if you moved the variable-setting into your callback function, instead of hacking it into the response. Should still execute before the second script.
>> it's likely already on your own domain so you're using XHR anyway
In this case the idea is to have a long-polling comet request, so it's generally recommended to load from another subdomain to avoid tying up browser threads (allocated per domain).
On a site with active data, it's really useful to be able to know whether the current request has failed (in which case you should re-request), or whether it's just hanging, waiting for a response (in which case you want to wait it out).
Leave a comment on jeresig's reply
Well, the technique could be applicable in the context of jsonp requests. The current implementation is so-so but the idea is there. However, I tried to work with the idea in the context of generic script loading (using onreadystatechange/onload/onerror as callbacks) and I may find a way to use the technique (though I bump on some issues right now).
OK, so I tested this a bit this week-end and here is my horrible code: http://pastie.org/814670
Detects loading failure of injected script tags for IE, FF, Webkit and Opera.
- Webkit & FF rely on the onerror handler
- Opera on an inline script right after the injected tag (like ScriptCommunicator)
- IE uses a trick I found that allows to load a script as an event handler for a DOM element, so I load the script as the onclick event of the script tag itself then controls if the onclick method exists and .call( window ) it if it does.
There are probably some quirks here and there: apart from the fact the code is not that well-written and still contains some console.log, it would need better feature detection and the behaviour of scripts called as an onclick method under IE should be checked more thoroughly.
But the biggest problem is inconsistency when it comes to scripts that *are* loaded but can't be parsed. Thing is the trick for IE & Opera makes it so such faulty scripts will fire errors but NOT under FF & Webkit.
"Nevermind", I told myself, let's listen to the error event on the window element and bring some consistency there. I made it work for FF, but Webkit guys apparently don't feel us worthy of being notified when there's an error in such a case: https://bugs.webkit.org/show_bug.cgi?id=8519. This bug has been opened for *4* years and the comments from some of the webkit devs just proved to me, once again, that devs never eat their own dog food. Particularly enjoyed the guy suggesting to properly use try/catch bocks or the other one thinking we need yet-another-browser-specific solution.
Anyway, that's about as far as I'll go for now. What we have is an error notification if a script couldn't be loaded BUT at the cost of an inconsistency: an error will be notified when the script has been loaded but cannot be parsed under Opera and IE (and FF with a window "error" listener).
I leave it to John to decide if the inconsistencies are acceptable in that case.
Leave a comment on aubourg.julian's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to kennethkufluk's idea
Statistics
- 4 Replies
- 8532 Views
- 1 Followers