Rails spinoffs - Jun 2005 - Problems with repeated calls to setTimeout?

Prototype.js and Thomas''s effects scripts use repeated setTimeout calls
for timed looping, for instance in time-based observers.

On Konqueror 3.4.1 (possibly other khtml-based browsers, too), these 
observers reproducibly crash the browser. Just keeping open a browser 
with such an observer is enough. After some time it invariably 
segfaults. When I substitute setInterval for setTimeout (mutatis 
mutandis), no such thing occurs. For instance, when I open

http://mir.aculo.us/

in a fresh browser and wait for a couple of minutes, Konqueror crashes.

I''ve tried to track the problem down, but it''s not as easy as
just
looped calls to setTimeout or even a TimedObserver. There must be 
something more to it. My conjecture is that each time through the loop 
and setTimeout some resources are acquired, but never freed. I''m unable
to set up a minimal demonstration case for this, though.

Has anyone else encountered this bug? Possibly with other browsers, too?

Michael

-- 
Michael Schuerig                 Not only does lightning not strike
mailto:michael@schuerig.de       twice, it usually doesn''t strike once.
http://www.schuerig.de/michael/  --Salman Rushdie, Fury

On Jun 28, 2005, at 5:07 AM, Michael Schuerig wrote:
>
> Prototype.js and Thomas''s effects scripts use repeated setTimeout
> calls
> for timed looping, for instance in time-based observers.
>
> On Konqueror 3.4.1 (possibly other khtml-based browsers, too), these
> observers reproducibly crash the browser. Just keeping open a browser
> with such an observer is enough. After some time it invariably
> segfaults. When I substitute setInterval for setTimeout (mutatis
> mutandis), no such thing occurs. For instance, when I open
>
> http://mir.aculo.us/
>
> in a fresh browser and wait for a couple of minutes, Konqueror  
> crashes.
>
> I''ve tried to track the problem down, but it''s not as
easy as just
> looped calls to setTimeout or even a TimedObserver. There must be
> something more to it. My conjecture is that each time through the loop
> and setTimeout some resources are acquired, but never freed. I''m  
> unable
> to set up a minimal demonstration case for this, though.
>
> Has anyone else encountered this bug? Possibly with other browsers,  
> too?
Michael,

Yes--Safari is doing the same thing.  I mentioned it on the list at  
one point, however, I don''t have enough JS knowledge (voodoo  
skills? :) ) to approach a solution to the problem.

Duane Johnson
(canadaduane)


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20050628/731c5cad/attachment-0001.html

*Should "reply to all" :)*

On mir.aculo.us, i guess it''s the live search field. The current  
version of prototype uses
setInterval to achieve the same thing, and should be "easier" on the  
browsers.

(see http://dev.conio.net/repos/prototype/src/form.js)

Thomas



Am 28.06.2005 um 13:07 schrieb Michael Schuerig:
>
> Prototype.js and Thomas''s effects scripts use repeated setTimeout
> calls
> for timed looping, for instance in time-based observers.
>
> On Konqueror 3.4.1 (possibly other khtml-based browsers, too), these
> observers reproducibly crash the browser. Just keeping open a browser
> with such an observer is enough. After some time it invariably
> segfaults. When I substitute setInterval for setTimeout (mutatis
> mutandis), no such thing occurs. For instance, when I open
>
> http://mir.aculo.us/
>
> in a fresh browser and wait for a couple of minutes, Konqueror  
> crashes.
>
> I''ve tried to track the problem down, but it''s not as
easy as just
> looped calls to setTimeout or even a TimedObserver. There must be
> something more to it. My conjecture is that each time through the loop
> and setTimeout some resources are acquired, but never freed. I''m  
> unable
> to set up a minimal demonstration case for this, though.
>
> Has anyone else encountered this bug? Possibly with other browsers,  
> too?
>
> Michael
>
> -- 
> Michael Schuerig                 Not only does lightning not strike
> mailto:michael@schuerig.de       twice, it usually doesn''t strike
> once.
> http://www.schuerig.de/michael/  --Salman Rushdie, Fury
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>