Opened 12 years ago

Closed 11 years ago

Last modified 9 years ago

#5695 closed defect (worksforme)

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

Reported by: rtweed@… Owned by: Douglas Hays
Priority: high Milestone: tbd
Component: Dijit - Form Version: 1.0
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by Douglas Hays)

Ticket 5412 was closed but I'm afraid the diagnosis provided does not completely explain what is going on. Whilst I've been able to fix the simple example I gave you by delaying the parsing, more complex examples still leave Firefox with a hanging progress bar.

By a process of trial and error I've concluded that there is a strange interaction between the dijit.form.Textarea and the dijit.layout.AccordionContainer?. The typical scenario is as follows:

I have a tag, eg a div, with a specific id and first I replace its innerHTML with some markup that contains a number of widgets including a dijit.form.Textarea. This is parsed and renders perfectly and can be used OK.

Wait as long as you like but then replace the innerHTML of the div tag with some markup containing a dijit.layout.AccordionContainer?. When I invoke the Dojo parser (even if I delay it as long as you like), the firefox progress bar immediately gets stuck.

Therefore this problem does not seem to be anything to do with having to wait for the HTML to be loaded - I can create this problem even if I wait 5 seconds before invoking the parser, which would be ample time for everything to get fully loaded.

My hunch is that there's an interaction within Firefox somewhere in the styles. I was able to create the same problem by transitioning from the innerHTML that contained the TextArea? to a fragment containing an ordinary div tag with a style including "overflow:auto". As soon as I removed "overflow:auto;" from the style, the progress bar completed OK. However, put back an accordionContainer and the problem re-appears, even if you ensure the style of the accordionContainer tag does not contain overflow:auto.

Unfortunately I've been unable to provide a simple example that demonstrates the problem. The best I can do are the following:

http://www.mgateway.com/php/dojo/test5.php shows a working transition, fixed by delaying the parser with a setTimeout wrapper. However, using the same technique does not fix a more complex scenario where you have other widgets in each innerHTML fragment. For the life of me I can't see why this simple example works and other, more complex ones don't, other than that the more complex ones include other widgets as well.

http://www.mgateway.com/php/dojo/layout2.php shows a broken example. This does not have any setTimeout delays in use, as these would break other parts of its functionality, but I've been able to prove that the setTimeout fix does not stop the problem in this case. This example is interesting because the accordion pane is in a different layout container, so it's not being replaced with the accordion pane. Here's the sequence of events to see the problem:

  • invoke the URL for layout2.php
  • click the Form Widgets button
  • click it a second time and you'll see Firefox's progress bar gets stuck

If I removed either the textarea or used something other than an accordion container, the problem would go away.

Let me know if you need any other information.

Attachments (1)

5695.html (2.3 KB) - added by Douglas Hays 11 years ago.
an attempt at a recreate testcase that works perfectly

Download all attachments as: .zip

Change History (5)

comment:1 Changed 12 years ago by bill

Cc: rtweed@… removed
Milestone: 1.2
Owner: set to Douglas Hays
Reporter: changed from guest to rtweed@…
Summary: 5412 revisited: apparent problem destroying textarea: FF status line progress bar gets stuckTextArea: 5412 revisited: apparent problem destroying textarea: FF status line progress bar gets stuck

comment:2 Changed 11 years ago by Douglas Hays

Description: modified (diff)
Milestone: 1.21.3

Changed 11 years ago by Douglas Hays

Attachment: 5695.html added

an attempt at a recreate testcase that works perfectly

comment:3 Changed 11 years ago by Douglas Hays

Milestone: 1.3tbd
Resolution: worksforme
Status: newclosed

No standalone testcase has been provided after 6 months. Using the description, I created a testcase (attached) that works for me. Closing this for now.

comment:4 Changed 9 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.