Issue with unresponsive javascript

[Rob]

I have a bug that I am trying to resolve and i can't figure out what
is going on here. Basically, there is a section at the top of the
page which gets populated by an AJAX call. Below that there is a
table. When this table has only a few rows, say 25, and you click on
a button in the top section which initiates the AJAX call, it
downloads and everything is fine. If the report has a lot of rows,
clicking on the button causes the browser to chug for a minute and
then pop up a dialog stating that the Javascript appears to be
unresponsive.

The interesting thing here is that the javascript returned in the
first case is exactly the same as the javascript returned in the
second case. More importantly, THIS CODE DOESN'T INTERACT WITH
ANYTHING ELSE ON THE PAGE! By that I mean that it doesn't modify any
of the existing nodes in the DOM or modify any of the existing JS
objects in memory. However, it does make a lot of calls to
Builder.node and other Builder functions (i.e. the Builder object in
Scriptaculous). When these are inserted in the DOM, does it take the
browser proportionally longer to do if there are more DOM nodes below
it? It seems like it might, but I am having trouble testing that
theory. Does anyone know if this is, in fact, true?

Thanks,
Rob

 

[SAM]

Le 12/12/08 11:38 PM, Rob a écrit :

I have a bug that I am trying to resolve and i can't figure out what
is going on here. Basically, there is a section at the top of the
page which gets populated by an AJAX call. Below that there is a
table. When this table has only a few rows, say 25, and you click on
a button in the top section which initiates the AJAX call, it
downloads and everything is fine. If the report has a lot of rows,
clicking on the button causes the browser to chug for a minute and
then pop up a dialog stating that the Javascript appears to be
unresponsive.

With any browser ?
Or only IE (and probably only IEs < 7) ?

The interesting thing here is that the javascript returned in the
first case is exactly the same as the javascript returned in the
second case. More importantly, THIS CODE DOESN'T INTERACT WITH
ANYTHING ELSE ON THE PAGE! By that I mean that it doesn't modify any
of the existing nodes in the DOM or modify any of the existing JS
objects in memory. However, it does make a lot of calls to
Builder.node and other Builder functions (i.e. the Builder object in
Scriptaculous). When these are inserted in the DOM, does it take the
browser proportionally longer to do if there are more DOM nodes below
it? It seems like it might, but I am having trouble testing that
theory. Does anyone know if this is, in fact, true?

IE (at least < 7) is very lazy with tables ...

Hu ... by inserting in the DOM you mean :
- appendChild
or
- innerHTML
?

 

[David Mark]

I have a bug that I am trying to resolve and i can't figure out what
is going on here.  Basically, there is a section at the top of the
page which gets populated by an AJAX call.  Below that there is a
table.  When this table has only a few rows, say 25, and you click on
a button in the top section which initiates the AJAX call, it
downloads and everything is fine.  If the report has a lot of rows,
clicking on the button causes the browser to chug for a minute and
then pop up a dialog stating that the Javascript appears to be
unresponsive.

The interesting thing here is that the javascript returned in the
first case is exactly the same as the javascript returned in the
second case.  More importantly, THIS CODE DOESN'T INTERACT WITH
ANYTHING ELSE ON THE PAGE!  By that I mean that it doesn't modify any
of the existing nodes in the DOM or modify any of the existing JS
objects in memory.  However, it does make a lot of calls to

WHAT DOES THAT MEAN?

Builder.node and other Builder functions (i.e. the Builder object in
Scriptaculous).  When these are inserted in the DOM, does it take the

That's at least part of the problem. Prototype/Scriptaculous (sp?) is
a dog.

[snip]