Re: Out of order JS file execution in WebKit

On 14.04.2010 19:32, Tristan Seligmann wrote:
> On Mon, Apr 12, 2010 at 8:37 PM,<[email protected]>  wrote:
>> There's no need to extend it.  This is exactly how it's supposed to
>> work.
>
> I believe there is a bug in the import mechanism that arises when
> dynamically instantiating widgets. It's been some time since I
> investigated the issue, and I've never found the time to file a proper
> bug report or fix the problem (we just worked around it by adding
> additional imports in places), but I think the details go something
> like this. If you are dynamically instantiating multiple widgets at
> once, the server notices that the client is missing certain modules
> required directly or transitively by the widget you are instantiating,
> and passes this information along with the serialised widget. However,
> the modules are then immediately added to the list of "modules already
> imported"; thus, if instantiating a second widget requires these
> modules, the server will assume they are already loaded on the client.
> If the second widget loads up before the imports triggered by the
> first widget have completed, you'll run into trouble.
>
> I'm not sure if this is the same problem that Werner is experiencing;
> it's not clear to me whether the widgets in question are being
> instantiated statically (at LivePage render time), or dynamically (by
> passing them to the client with callRemote).
>
> Note that this bug should be able to manifest in any browser, not just
> WebKit; however, since the problem is essentially a race condition,
> changing browsers / internet connections / etc. may cause the race to
> go one way or another.

Hi

Hmm, I am injecting dynamically instantiated widgets into the page and 
it is exactly that race condition I observed. It definitely showed 
reliably only in the WebKit family, but after reading your post this 
might only be a symptom and not a bug or misinterpretation in the WebKit 
programming.

Just to keep the tally updated
- I'm on the safe side with the code previously posted
- this code can reside in userland thus not touching the nevow/athena base
- it would be better to invest some time into fixing the actual bug 
instead of coding around it

Tristan, can you give me a pointer for attacking this problem, I like 
the nevow/athena codebase very much and have quite a few projects 
depending on it and these projects are more and more dependent on having 
widgets injected dynamically. I recently tried to integrate qooxdoo and 
nevow and also processing and nevow which leads to some interesting 
perspectives for future solutions.

Thxs, Werner