I've run into an issue with Firefox 3 firing its DomContentLoaded event before all of the inline javascript and required dojo libraries have been pulled into the context. Has anyone else here noticed a similar issue with the latest relase of Firefox 3? I can readily reproduce the problem using FF3 on WinXP (the mozilla folks have also been able to reproduce it with FF3 on Vista).
We've reported a bug to Mozilla here: https://bugzilla.mozilla.org/show_bug.cgi?id=444322
The problem that I've encountered is that the DomContentLoaded event is fired while dojo is in the process of pulling in the required libraries for a simple Clock widget. (Our example is written with dojo 0.4) After a bit more sleuthing, I've narrowed the problem down to the line:
http.send(null);
in the method dojo.hostenv.getText in dojo.js
For some reason, Firefox will trigger the DomContentLoaded event while its sending an XmlHttpRequest for subsequent dojo libraries. This problem occurs intermittently -- which makes is reproduction extremely frustrating. My coworker and I have a simple page that'll cause this issue with FF3 on WinXP:
http://www.vodafonegroup.eu:8080/jsp-examples/ff3/welcome.jsp
The page will reload itself every second until the issue pops up - so you may have to let FF3 run for a while.
When the premature event is triggered, my rudimentary debugging puts out a call stack similar to the following:
-------------------
BEGIN INLINE SCRIPT
-------------------
Before dojo.require(dojo.widget.Clock)
Begin dj_load_init(). (Triggered from EVENT: domcontentloaded)
dojo.hostenv.makeWidgets() Called
dojo.hostenv.makeWidgets() Ended
After dojo.require(dojo.widget.Clock)
Before dojo.addOnLoad(init)
init() Called
The expected call stack is:
-------------------
BEGIN INLINE SCRIPT
-------------------
Before dojo.require(dojo.widget.Clock)
After dojo.require(dojo.widget.Clock)
Before dojo.addOnLoad(init)
After dojo.addOnLoad(init)
-------------------
END INLINE SCRIPT
-------------------
Begin dj_load_init(). (Triggered from EVENT: domcontentloaded)
dojo.hostenv.makeWidgets() Called
dojo.hostenv.makeWidgets() Ended
init() Called
init() Finished
So, to sum it up -- has anyone here in the dojo community run into this intermittent event misfire? Is there something inherently wrong with calling XmlHttpRequest.send() before the page has loaded?
We've been running with our widgets problem free on IE6 / IE 7 / FF2 / Safari. This problem only seems to appear in FF3.
If anyone has any insight into this - any thoughts or ideas would be greatly appreciated. If not -- I figure it would at the very least be a good idea to let the dojo community know that there may be a potential issue with FF3 and the dojo framework.
Thanks
-Jason
If you're experiencing this with the Clock widget from 0.4...
...it's pretty likely that there's a synchronization issue that is specific to dojo.gfx (IIRC, that's what it was in 0.4; it's dojox.gfx now). The issue there is that it *needs* to do a browser sniff in order to load the correct set of files (i.e. SVG for most, VML for the bastard child), and usually that may or may not happen *after* the require for the Clock widget was loaded and evaluated.
You might want to try (or at least plan to try) an upgrade to the latest and greatest. The same issue is there but because of the way Dijit was rewritten, an awful lot of the loading pain that used to be there is gone.
We have not ported that particular widget (it was deemed unnecessary for Dijit) but frankly you could port it yourself pretty fast; there's nothing unusual about it, and aside from gfx moving to the DojoX project, the majority of that API remains very stable.
Thanks a bunch
Thanks a bunch for the reply. I initially thought that there was some synchronization issue with dojo -- but after some more meddling, I'm still convinced that there's some sort of threading bug in FF3.
This week I'm going to upgrade our widgets to the 1.1.1 framework. So, I'm pretty sure that this will become a non-issue. This entire Clock widget test case I created was purely to demonstrate the premature event firing -- we're not using the clock in our production code at all.
All of the widgets in our production code are Custom -- and they are all pretty simple. In fact, they're not using anything from the dojo.gfx library at all -- yet I can easily reproduce this FF3 issue with our custom stuff.
In any event, thanks a lot for your reply - its greatly appreciated. I'm going to fiddle around some more - and just go forward with a 1.1.1 upgrade. If that fixes our issue, or if I figure out anything else, I'll drop a note in here - just in case its of interest to anyone. My frustration is with FF3 these days - we've seen all sorts of intermittent issues with inline style tags being ignored, inline script tags being ignored, and this strange premature event firing. I've never seen anything like this with IE 5.5 / IE 6 / IE 7 / FF 1.0 / FF 2.0 / and even Safari.
Cheers
-Jason
Seeing the same behavior in FF3 with dojo 1.1
I have been seeing what sounds like the same behavior in FF3 even with dojo 1.1. Great to see that you have tracked this problem down! Since there weren't posts about it until now, I had been hunting around to see if there was a bad race condition in our custom dojo extensions/widgets.
The sporadic nature made it especially confusing. What I have observed is that if FF3 is loading a complex page (which includes dojo) for the first time, then it throws errors that claim that some basic dojo (built-in) functions or objects have not loaded. For example, a common error has been that "dojo._getText" is undefined. But, if the same page is reloaded, everything loads fine. So, I'm assuming that the caching the second time around is making the race condition conflict less likely.
In your test cases, were you seeing built-in dojo code that was coming up with errors, because dojo had not finished loading, or was it only custom code that was affected? (IOW, is it custom code that is failing because it's being called before dojo is done loading, or are there internal parts of the dojo lib that don't load successfully because they have dependencies on other parts of the lib that are supposed to load before them?) I can't tell from my test cases. The failures I've seen definitely involve custom code getting the go ahead to load before dojo has finished loading. But, it's not clear if internal parts of dojo are also failing for the same reason. If it's only a custom code issue then a workaround for the time being could be to set an interval to check if certain components of dojo are loaded before continuing.
Is there any update on this
Is there any update on this topic?
I experience similar behaviour. Using a local copy of dojo 1.1.1. Firefox 3. With the most minimal number of dojo.require() statements. Page is generated from JSP.
When I pear down the page to the bare minimum, I can almost always avoid error messages, but as soon as the page grows a little, I get:
Is there any update on this
Just wishing to say that preliminary attempts seem to suggest that a (very temporary and unsatisfactory) way out is to load anything to do with dojo just before the closing </body> tag...
One workaround may be to use
One workaround may be to use an xdomain build of Dojo: it uses asynchronous loading of scripts so it probably reduces the possibility of triggering the specific bug. I do not think I have seen the issue if I am using Dojo from a CDN, like Google's or AOL's (which are xdomain builds).
Same problems here with Firefox 3.0.3
Hello folks!
Same timing problems here. Curiously this only happens with Firefox under Windows, while the Linux version I often use seems to be safe.
It really looks like the timing is sometimes not correct, as it happens only sometimes (and it IS frustrating). I'm using Dojo 1.2.0 RC1. Now that the 1.2.0 final is out I might be able to solve by using CDN (the RC versions were not available on Google or AOL), but I think this has to be fixed (either in Dojo itself or in Firefox, I don't know).
----------
failed loading undefined./parser.js with error: TypeError: this._getText is not a function
failed loading undefined../dojox/grid/DataGrid.js with error: TypeError: this._getText is not a function
cryolist is undefined
(?)()()jK%2BIRy...1mQ%3D%3D (row 40)
toString()()dojo.js (row 16)
toString()()dojo.js (row 16)
toString()()dojo.js (row 16)
toString()(load )dojo.js (row 16)
[Break on this error] undefined
----------
Michele.
Confirmed FF 3.0 bug
So, this problem is not a dojo issue - its a pretty serious issue with FF 3.0. This has been reported to the mozilla folks, and there's been a lot of chatter recently on the issue. ( The bugzilla report is here: https://bugzilla.mozilla.org/show_bug.cgi?id=444322 ) I don't think they have a fix for the problem yet.
I was able to workaround the issue by doing a custom dojo build. I'd highly recommend using a custom build in your production code -- that way dojo won't have to issue XHRs to pull in the necessary libraries -- that's what causing the issue in FF 3. Not only does it solve the FF issue, but your page will load much much faster.
An extremely simple workaround
Here is an extremely simple workaround that worked for me. The nice thing about it is that it does not make you alter or move your existing code. Just insert the following before the closing </body> tag:
<script type='text/javascript'> </script>
NOTICE: there is a space between the "script" tags, as in order for this workaround to be effective, there must be something between the script tags - totally empty tags will not workaround the issue.
Hope it helps.
Workaround is not working all the time..
Hi All,
When it is loading page, some times it is not loading dojo .js files and throwing below error message in FireFox 3
failed loading undefined./parser.js with error: TypeError: this._getText is not a function
GET http://localhost:7001/ebats/dojoroot/dojo/_firebug/firebug.js
http://localhost:7001/ebats/dojoroot/dojo/_firebug/firebug.js
8ms dojo.js (line 16)
ParamsHeadersPostPutResponseCache
Response Headers
Request Headers
Firebug needs to POST to the server to get this information for url:
http://localhost:7001/ebats/dojoroot/dojo/_firebug/firebug.js
This second POST can interfere with some sites. If you want to send the POST again, open a new tab in Firefox, use URL 'about:config', set boolean value 'extensions.firebug.allowDoublePost' to true
This value is reset every time you restart Firefox This problem will disappear when https://bugzilla.mozilla.org/show_bug.cgi?id=430155 is shipped.
I'm using dojo 1.2.0 and FireFox 3.0.4. I never experianced this problem in FireFox 2
Regards,
Sharath
Potential Fix
After banging and banging to fix this, we just came up with a solution. Forget about caching in Firefox 3, if they are going to be jerks, then we will.
#Due to mozilla bug in FF3, we disable all caching in FF3.
#https://bugzilla.mozilla.org/show_bug.cgi?id=444322
BrowserMatchNoCase "Firefox/[3]" screwff
Header set Cache-Control "no-cache" env=screwff
Pop that in your .htaccess file, and the problem is gone. Until they fix this FF3 people get no caching.