BTW, the KTHML issues is due to the onDomReady code.  We have to do 
quite a bit of work to get this to work right in KHTML - 
setIntervals(), a bunch of recursion and nested functions - so this 
extra overhead to show content on DOM ready is why the stack limit is 
being reached.

Several hours of work and what i have determined is... KHTML/Safari, 
and the like have unrealistically low stack size limits.  We are not 
doing anything tremendously out-of-the ordinary with the exception of 
doing a lot of initialization (DIMP is a complex app - what do you 
expect?)  Apparently these browsers are going to need quite an 
overhaul in order to be able to handle the next generation of web 
applications.  (Honestly, the more I work with Safari, the less 
impressed I am with it.  In many instances it is worse than IE).



So we will simply have to revert to normal onload behavior.  Which 
means it will take a bit longer for these apps to show initial 
content, but nothing we can do about it.

I have seen this too a few time, and I see it reproducable always in 
Konqueror. I haven't mentioned it yet because we don't support 
Konqueror officially and I wasn't able to reproduce it reliably in any 
other browser.

I _do_ see this problem on Safari (2.0.4) as well.



According to http://bugs.webkit.org/show_bug.cgi?id=4045 the stack 
limit in Safari/WebKit is 99, where it is much higher in FF/IE 
(500-1000).

I don't see this in any other browser (FF, IE, Opera, and most 
important - Safari).  Considering there is no stable release of WebKit 
at this point, I'll be that this is a webkit issue rather than a dimp 
issue.

When I first load Dimp in Webkit, I get the following error in a 
pop-up window:



Event._onloadWindow: Maximum call stack size exceeded.