Ticket #6741 (closed defect: fixed)

Opened 14 months ago

Last modified 7 months ago

Function registered with dojo.addOnLoad is executed before document loaded on IE6.0.2900

Reported by: guest Owned by: jburke
Priority: high Milestone: 1.2
Component: Core Version: 1.1.0
Severity: major Keywords: dojo addOnLoad document IE IE6
Cc: pbarbier@…

Description

From pbarbier at novell dot com (Pascal Barbier).

Bug occurs only with IE6.0.2900 (maybe with more recent IE6 versions but not tested).

Bug does not occur with Firefox and IE7.

No direct error message, but if the registered function performs a innerHTML="" or an appendChild, you'll get a 'Operation Aborted' error or a browser crash.

Test case to reproduce the bug: 1) Have a custom dojo module such as:

mymodule/common.js:

/* Begin file content */ dojo.provide("mymodule.common");

mymodule={};

dojo.addOnLoad(function(){

alert(document.readyState);

}); /* End file content */

2) Have a custom build of dojo 1.1 from this profile:

dependencies.layers.push({

name: "dojo.js", dependencies: [

"dojo.date.stamp", "dojo.parser", "dojo.string", "dojo.i18n", "dojo.regexp", "dojo.cookie", "dojox.collections.ArrayList?", "dojox.collections.Stack", "dojox.fx", "dijit.dijit", "dijit.form.Button", "dijit.Menu", "dijit.layout.StackContainer?", "dijit.layout.TabContainer?", "dijit.layout.ContentPane?", "dijit.layout.LayoutContainer?", "dijit.Tree", "mymodule.common"

]});

dependencies.prefixes.push(

["dojo", "../../dojo"], [ "dojox", "../dojox"], [ "dijit", "../dijit"]); [ "mymodule", "../mymodule"]);

3) Setup a html page where the custom build from step 2 is referenced in the page <head>

4) Open the page in IE6

You'll get a alert box which content is "interactive".

With IE7, the alert box will read "complete".

When document readyState is "interactive", it is not yet loaded completely. Hence the bug.

Current workaround for this bug, to be placed at the very beginning of the custom module (after dojo.provide):

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);

}

};

}

Change History

Changed 13 months ago by jburke

  • milestone set to 1.2

Changed 12 months ago by jburke

  • priority changed from normal to high

Be sure to read the full forum thread above, there is more discussion in it. Pascal also references MSDN 927917 in his comment.

Marking as priority high, so it does not get scrubbed out of 1.2.

Changed 12 months ago by jburke

  • owner changed from anonymous to jburke

Changed 12 months ago by jburke

  • status changed from new to closed
  • resolution set to invalid

I cannot seem to reproduce the error using the latest trunk code (r14229). I am using Windows XP SP 2 with IE 6 version number: 6.0.2900.2180.xpsp_sp2_gdr.070227-2254

I create a dojo build using the steps above, although the format of my build profile is slightly different (I did not use .push methods off of dependencies).

You can see the test here: http://jburke.dojotoolkit.org/temp/mymodule/mymodule/test.html

The build profile is here: http://jburke.dojotoolkit.org/temp/mymodule/mymodule.profile.js

I am going to close this as invalid for now, but please post back if I am missing something important in the code or the test file.

Changed 7 months ago by millennium

  • status changed from closed to reopened
  • resolution deleted

I can confirm the IE6 bug is still present in Dojo 1.2.3 (standard build).

However I couldn't isolate the problem to a simpel test page. After applying the second patch in the forum thread, the IE6 "aborting error" is gone.

it's not that hard to add:

if (d.isIE){
  if (document.readyState != "complete"){
    setTimeout(d._modulesLoaded,100);
    return;
  }
}

to "dojo._modulesLoaded"

Changed 7 months ago by jburke

  • status changed from reopened to closed
  • resolution set to fixed

millennium: without a test case, this kind of bug is hard to fix. I prefer not to use a setTimeout fix without a test case to verify the fix. I am going to close this for now, but please reopen if you do find a test case we can use for testing a fix.

Note: See TracTickets for help on using tickets.