Hello,
I've recently bumped into a dojo.addOnLoad bug with IE6: It can execute the passed function even if document's readystate is currently "loading".
Here's a way to patch dojo.addOnLoad:
//dojo.addOnLoad patch if IE
if(dojo.isIE){
//Saving a copy of the original function.
var origAddOnLoad=dojo.addOnLoad;
//Wrapping it.
dojo.addOnLoad=function(){
var args=arguments;
if(document.readyState=="complete"){
//Document is loaded. Removing the wrapper.
dojo.addOnLoad=origAddOnLoad;
dojo.addOnLoad.apply(dojo,args);
}else{
//Document not loaded yet. Deferring execution.
setTimeout(function(){dojo.addOnLoad.apply(dojo,args);},10);
}
};
}
This code should be put in your own dojo module. So dojo might be in memory right before this patch is executed.
Pascal.
If you can file a test case
If you can file a test case at http://trac.dojotoolkit.org, that would be appreciated. We would like to fix the issue in the toolkit if we have a test case to confirm the fix. You can use the login/password of guest/guest to create a ticket and upload the test case.
Done
http://trac.dojotoolkit.org/ticket/6741
works
hey. thanks for the fix. this comes up in Safari for Win also.
same problem another solution
Today I saw this new one of the crazy IE "Operation aborted" alerts in our dojo-app (see also http://trac.dojotoolkit.org/search?q=operation+aborted ).
But Pascals solution does not work for our dojo build at all, if there is no dojo in IEs cache (e.g. first time user loading the page) the alert still appears. So I modified the loader.js in dojo/_base/ as follows:
added following lines to dojo._modulesLoaded:
if (document.readyState != "complete"){
setTimeout(dojo._modulesLoaded,100);
return;
}
}
then dojo._modulesLoaded should look like this:
if(d._postLoad){ return; }
if(d._inFlightCount > 0){
console.warn("files still in flight!");
return;
}
if (dojo.isIE){
if (document.readyState != "complete"){
setTimeout(dojo._modulesLoaded,100);
return;
}
}
d._callLoaded();
}
Tested with IE6/7, Firefox2/3, Safari
Operation f... aborted and us
Thx megmed !
However I had the same issue days prior to final release (as always) but then found myself pretty good at solving it by following the recommendations from MSDN article 927917.
Hopefully this second fix will make it in dojo 1.2. If JBurke reads this, could he add a note with the code above in the trak ticket ?
Thx again,
Pascal.
works
Can confirm this works.
I had problems using a modalbox in IE6. In my web application i got several tabs that reloads the entire page when you change tab, when I added the dojo.require("dijit.Dialog"); to one tab i had no problems. But when i added it to 2 or more tabs i got problems in IE6 when I tabbed between the two.
In order to fix this I had to use the first solution and change my code to use dojo.addOnLoad instead of parseOnLoad:true
as shown in this link:
http://dojotoolkit.org/forum/support/general-support/operation-aborted-i...
I see the ticket are now closed, hope this might help to remake the problem and fix it in the 1.2 version.
Somewhat confused about this
I'm following this thread with interest because my first encounter with the DOJO SDK environment has been the IE6 Operation Aborted errors when trying to view various dijit objects in the DOJO online Book:
- http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/form-validation-s...
- http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/form-validation-s...
...
Pretty much all the form-validation-specialized-input/* documents
(my IE version = 6.0.2900.2180.xpsp_sp2_gdr.070227-2254)
Thankfully, I can view these objects in FF, however, like many of us, I need to be able to develop functional, browser agnostic content.
So here is what I'm confused about:
Pascal Barbier opened a bug report (ticket #6741).
Clearly the bug was serious, and reproducible; the ticket went through a process of being milestoned and raised to high priority.
Then Ticket 6741 was assigned to "jburke". jburke closed the ticket as "invalid" because he was unable to reproduce the issue. So is that the end of it? IMHO, this still appears to be a significant and reproducible condition, seemingly related to IE's propietary way of loading & parsing the DOM.
Perhaps Pascal's path to reproduction is not sufficient to recreate the issue in Ticket 6741, but browsing to the pages pointed out in this thread and this post will, and still do.
Is there any possibility that this issue will be resolved? Or, Is there a DOJO approved (and documented) method of patching the existing code? Or does the version I just downloaded (1.1.1) address and fix this?
~robb
Robb, The operation aborted
Robb, The operation aborted errors normally happen because some code tries to grab something in the DOM before the element is considered "available". This is usually the result of the script in the HTML file not using dojo.addOnLoad() to wrap the code that will be modifying the DOM.
This was the case for the Dojo Online Book pages that you mention above. I have edited them to use the correct dojo.addOnLoad() idiom.
As for ticket #6741, I did try to reproduce, doing a build and creating a test page. The test page is linked in the bug report, and you can try it for yourself. However, I could not reproduce the error with that test page. I tried again just now with IE 6 and still do not get the error. However, I did get the error via the book pages you mentioned above.
Thanks for pointing out the bugs in the Dojo book. The book content is starting to get a little stale, and we are in the process of building up new documents at http://docs.dojocampus.org. If you visit the new site, be warned that it is still in flux and content shifts around daily.
If you want to retry the book pages you mention above again in IE6, they should work now, but be sure to clear your cache first.
Hi JBurke, I did retry the
Hi JBurke,
I did retry the book pages, each loads successfully for me as well now - amazing response, thanks!
"script in the HTML file not using dojo.addOnLoad() to wrap the code that will be modifying the DOM ... use the correct dojo.addOnLoad() id" - thanks for the clarification. This concept seems a core best practice and seems to render 6741 an "education issue" and of course invalid.
Do you mind sharing what "J" in jburke is? I searched a little.
robb
Robb, the "J" is for James:
Robb, the "J" is for James: http://tagneto.blogspot.com