2006.07.28 05:06 PM

Dynamic Script Elements and a FireFox Difference

I'm a fan of the DOM-Based On-Demand JavaScript pattern and rely on it pretty heavily in the web applications I develop. It's simple, works in every browser I've ever had my hands on, and as long as the request can be described within the limits of a querystring (sometimes with the aid of a cookie) it can be very powerful. In my experience it's the quickest, easiest, and most efficient way to communicate browser events and data to the server and get back data and/or presentation altering logic without a POST and page refresh.

I'm not going to describe the technique in detail, as there's plenty of information available on it (see here and here for more; I even included an example in an earlier post). But I did want to note that while testing my latest web application, I discovered something about FireFox and dynamic script elements that I hadn't noticed before, something that differs from Internet Explorer.

One of the downsides of this technique, as compared to full bore XHR, is that there's no way to monitor the status of requests made by the browser following the insertion of a new src-attributed script element into the DOM. In Internet Explorer, a bad src URL or non-responsive server results in, well, nothing, IE simply swallows it. In order to deal with this, it's necessary to write an additional setTimeout-based monitor and coordinate its handling with the JavaScript returned by the server. I've always assumed that this was true for FireFox as well and so was surprised to discover that FireFox actually throws a trappable error in these situations.

The way I discovered this was that the web application, like most I develop, uses a window object onerror event handler as a backstop against unintended user alerts in Internet Explorer and the swallowing of untrapped JavaScript errors in FireFox. One set of tests that I ran included stopping the web server to verify the behavior of the dynamic script elements when faced with no response. I expected that the non-responsive server request would trigger the setTimout-based monitor logic and report an appropriate error to the user, and in IE it did. But in FireFox it triggered the onerror event handler logic with the message: "Error loading script".

Who knew? Probably everyone. Now I know, too. But what I still don't know is why I never saw this in any of my earlier web apps. Perhaps this error was added to FireFox in version 1.5? If I get time I'll have to go back and check. Anyhow, having discovered this, I had to modify the onerror event handler to ignore this particular error so that both FireFox and IE would deal with the situation in the same way.


I will continue to visit enjoyed the reading thanks

| 2006.08.27 07:14 PM

I need more details about 'Error in loading Script' message on onerror event.

Jenitha | 2007.02.21 01:53 AM

I have used this coding.
function pageError(msg,url,l)
return true;
For same page it works fine in IE but it throws alert for

Please update me.

Jenitha | 2007.02.21 02:08 AM

Hi Jenitha,

I'd like to help, but I'm afraid I don't know any more about this particular browser error than I've written above. Are you using dynamic script elements, as described in the post? If so, and one of them is failing to load, and the script element is being created during page load, then I'm not surprised that FireFox is throwing the error and it's being reported via the code you've posted - that's consistent with the behavior I saw. I would not be surprised if in FireFox the same thing happened with static script elements having src attributes that couldn't be loaded.

ewbi.develops | 2007.02.21 08:29 AM

Thanks for your response.
Actually the page it fails to load is JavaScript file.In html
it's coded as follows


Jenitha | 2007.02.22 01:13 AM


HTML is stripped from the comments here, but I think I understand what's happening, which is that FireFox throws an error when the script cannot be loaded, but IE doesn't, as described in the post above (in your case the script element is static, but it's all the same). And, your page includes code that traps the error and displays it, which of course only happens in FireFox.

Assuming that is correct, what can I help you with?

ewbi.develops | 2007.02.22 07:10 AM

I want to fix this error.Can you please
suggest an idea to fix this error.
But there is possibility to suppress this error.If i would suppress this error means,i have to justify that.How to justify it?

Jenitha | 2007.02.23 01:04 AM


I'm afraid the only suggestion I can make to fix the error is to identify the src-attributed script element in the HTML that is failing to load and either 1) fix it so it loads, or 2) remove it from the HTML. I can't help at all with (1) and have no idea what the impact of (2) would be on the page, except to guess that if the script is failing to load every time then it isn't doing anything for the page anyway, which answers your second question regarding justifying suppressing the error: if an unloadable script is referenced by the HTML and you can't make it load and can't remove the script element, then there's no point in displaying an error message that just repeats these facts.

Good luck.

ewbi.develops | 2007.02.23 02:10 AM

I have resolved that previous issue by inserting setTimeout.I had an another issue now.Problem in loadind page in mozilla.

I have loaded one script file from that two files have to be lodaed .

I have loaded index.xuda file after that two more files
get loaded consecutively.In all other browsers it's working fine.
In case of Mozilla first file get loaded twice.
second file fet loaded once and stop loading.If i use Reload button in browser means it get loaded properly.
Can you please tell me why this happens.

Jeni | 2007.03.16 12:02 AM

Jeni - I would need to see the pages/scripts to even begin to know why this might be happening. Feel free to forward them to the address shown in the left column of this page and I'll look at them when I get a chance.

ewbi.develops | 2007.03.16 03:10 PM

I have a site with over 80 pages, all that employ JavaScript error trapping. My site serves well over 2000 pages a day and I get about ten "Error loading script" scripting errors each day from Firefox browsers. It is beginning to really annoy me and I am becoming convinced that it is a problem in Firefox.

I can discount the NOSCRIPT suggestion because the script loads in the head of my pages where there are no NOSCRIPT tags.

I can discount the 'external domain' suggestion because I have two sites that suffer this problem and in both cases the JS library files are located on the sites own server.

I have carefully checked every library file and web page using JavaScript Lint and I have discovered scripting errors and questionable scripting techniques. All these problems have been corrected but this has not provided any sort of cure to the "Error loading script" problem.

My pages do load several JavaScript library files that do not have this problem and the only difference is the size of the files. Most of the files are under 5KB but the problem file is 17KB.

Could the size of the library file be the problem?


webwisewizard | 2008.10.30 04:27 PM

I have found that, in every browser except Firefox, after attaching a dynamic script, you can remove the script element which will cancel downloading the script.

This problem is compounded by FireFox's rigidity with respect to retaining execution order of dynamically attached scripts; Essentially if you want to use this technique to retrieve data from the server every 5 seconds, ONE BAD REQUEST the data retrieval will stop functioning until FireFox sees fit to declare the script dead.

Has anyone figured out how to "configure" FireFox's script timeout? SEems to be 60 seconds by default.

var N= 5;
function loadScript(){
_script= document.createElement("SCRIPT")
_script.onload= _script.onerror= function(){ setTimeout(loadScript, N * 1000);
_script.src= "/rest/info.json"
setTimeout( (N - 1) * 1000, function(){
// At this point you would want to make another
// request for the same remote script; removing the script
// element like this does not seem to matter to FireFox.

Serverherder | 2009.10.07 11:57 AM

Interesting, thanks for sharing this - unfortunately, not much traffic here these days, but maybe someone will see this and respond. Good luck!

ewbi.develops | 2009.10.07 12:54 PM


TrackBack URL:  https://www.typepad.com/services/trackback/6a00d8341c7bd453ef00d834e14bf869e2

Listed below are links to weblogs that reference Dynamic Script Elements and a FireFox Difference: