apparent problem destroying textarea: FF status line progress bar gets stuck

[rtweed@…]

Browser: Firefox 2.0.0.11 OS Windows XP SP2

I'm integrating Dojo widgets into our Ajax framework (eXtc Web Developer (EWD) : http://www.mgateway.com/ewd.htm), with great success. The EWD ajax framework uses innerHTML replacement of "fragments" of markup into main "container" pages. The idea is that the fragments may contain new (or new instances of) Dojo widgets. EWD automatically destroys any previously instantiated dojo widgets to ensure the new ones come in to a "clean" Dojo environment.

This works well except for a fragment containing an Accordion container and panes. In Firefox, the first time you bring in this fragment, it works perfectly. I then replace the innerHTML with some other markup and the accordion disappears and is destroyed - again this works perfectly. However if I now bring the accordion fragment in again, Firefox renders it perfectly (and allows me to interact with it perfectly) but the Firefox progress bar in the bottom right of the browser's status line never completes.

I've tried everything I can think of to work around whatever it is that's upsetting Firefox in this way. It's not a show-stopper as the accordion panes work just fine when loaded, but something is clearly upsetting Firefox. Having the progress bar not completing also gives the impression to users that they should wait, but it never completes.

For the record, here's the example markup in the fragment I'm testing:

   <div dojoType="dijit.layout.AccordionContainer" id="myAcc" style="overflow:auto;height:300px;width:400px;">
      <div dojoType="dijit.layout.AccordionPane" id="accordion23" selected="true" title="Pane 1">blah blah blah</div>
      <div dojoType="dijit.layout.AccordionPane" id="accordion30" title="Pane 2">jgjg ggjg ghjgjg</div>
      <div dojoType="dijit.layout.AccordionPane" id="accordion33" title="Pane 3">khkjh hkhkh hjkhkh hjkhh hkjhhkjk</div>
   </div>

The fragment gets re-rendered by the following code that gets executed after this innerHTML is swapped into the container page:

dojo.require("dijit.layout.AccordionContainer");
// array of widgets that will need to be destroyed later
EWDdojo.widget=new Array();
EWDdojo.widget['myAcc']='';
EWDdojo.widget['accordion23']='';
EWDdojo.widget['accordion30']='';
EWDdojo.widget['accordion33']='';
// now reparse to render the fragment properly as Dojo
dojo.addOnLoad(function(){
dojo.parser.parse(dojo.byId('ewdthewholepage'));
});

and it's all cleaned up when you initiate another innerHTML swap by:

for (wid in EWDdojo.widget) { if (dijit.byId(wid)) dijit.byId(wid).destroy(); }

All other browsers behave impeccably - it's just an issue with Firefox.

[bill]

(FYI, I just cleaned up the formatting in your above post by adding the triple braces around code.)

You should be able to come up with a stand alone testcase for this, not involving EWD (or even involving a server... unless the problem is timing related, which is possible.)

Are you destroying the widgets before or after you null out innerHTML? If you destroy innerHTML first then maybe the widgets are getting confused.

Also, BTW, note that new Array() can (and should) simply be [], but in your case you don't want an array at all, but rather a hash, so you should replace new Array() with {} .

[guest]

Thanks for the suggestion about using {} for the hash - you're quite correct!

I've isolated the problem now - the problem occurs if the accordion fragment is swapped out for a fragment containing a dojotype=textarea. Even though I destroy the textarea widget before reloading the accordion fragment into the innerHTML, Firefox's progress bar gets stuck. It takes a couple of cycles before Firefox gets upset which is interesting. But it's 100% reproduceable. Firefox gets stuck when reloading the accordion fragment - never when reloading the textarea fragment.

I suspect it's because the dojo textarea actually embeds an iframe into the page, and the iframe contains a page of stuff generated by the Dojo parser. My guess is that the textarea destroy() isn't getting rid of everything because of the stuff in the embedded iframe page. I've tried destroyRecursive() also without success.

Hope this helps to isolate the problem

[bill]

Ah, I'm sure that will help. Can you make a simple test case for this?

The good news is that we'll be getting rid of the iframe for FF3 so this won't be a problem for long. I'l assign to Doug since this seems to be a textarea issue.

[guest]

Here's the stripped-down example that demonstrates the problem:

http://www.mgateway.com/php/dojo/test5.php

Click the button that appears and you'll see the div id="section" gets replaced with a form containing just a dojo textarea. Then click the "go to frag 5" button. The "section" div's innerHTML will be replaced with an accordion panel. Now click the "Go to Frag 4" button. The textarea should reappear. Now click "go to frag 5" again and you should see the FF progress bar gets stuck.

What's happening in this example is that the two fragments alternately replace the innerHTML of the div id="section" in the original "container" page. Between clicks, I'm destroying all the dojo devices that are present in the fragment that is being replaced by using destroyRecursive() for each dijit, so all the dijit stuff should be getting cleared out before the new innerHTML is swapped in.

You'll see that IE and Safari work great, and indeed FF works OK even though the status bar gets stuck. But clearly something's not quite right with FF, I assume because something related to the dijit textarea environment is being left behind.

Note that if you click another time and bring back the textarea, FF is quite happy and the progress bar completes, but click again and bring back the accordion pane and it's stuck again. So it just seems to affect the accordion container. I haven't tried any other containers, so I'm not sure what else might be affected. However, hopefully this example will provide some clues that Firebug or whatever will reveal for you.

[doughays]

So far I've been unable to recreate outside the user's environment. Still investigating...

[doughays]

tiny recreate

[doughays]

The application is setting innerHTML and calling parse without waiting for the HTML to be rendered - see tiny 5412.html recreate.