[Laszlo-dev] Fwd: Problem with LzBrowser.loadJS() in IE6

[Henry Minsky]

---------- Forwarded message ----------
From: Cameron Brown <cbrown at sendio.com>
Date: Jun 10, 2005 3:51 PM
Subject: Problem with LzBrowser.loadJS() in IE6
To: hqm at alum.mit.edu



Henry,

I know you must be extremely busy, but I wanted to share with you a problem
and solution that I came across last night in case it is useful to you.

I was having trouble with LzBrowser.loadJS() in IE6, but not in Firefox.  My
Laszlo app has gotten (much much) too big for a monolithic design, and I
went to multiple Laszlo apps in a frameset with one LZ sidebar app acting as
a controller to bring up the other LZ subapps in a second frame.  Kind of
like the Laszlo doc does, but with some frameset animation, and other
javascripty stuff.  I imagine this will be a common pattern of development
for Laszlo apps.

Anyway the problem is that in IE6, but not Firefox/Mozilla, making multiple
calls to LzBrowser.loadJS() in quick succession causes the earlier calls to
be ignored and only the last call actually executes any javascript.  I saw
my problem during login when I would animate the frameset, update a status
display, and load a frame all at pretty much the same time, though each
action was powered by a different login-related event in my controller.
Worked in Firefox, but in IE I would miss updates to the status text and the
main page wouldn't load.

As you know, Flash getURL() works on the principal of "loading" a javascript
URL into a frame.

I think what is probably happening is that IE figures than any load into a
frame supersedes the last, which makes a lot sense in the context of loading
visible pages.  But when you're just trying to run some javascript to get a
side-effect in other frames it is bad, bad behavior.  I suspect that
Firefox/Mozilla treat javascript URLs as special and make sure to launch
them all and wait for each to complete before running the next.  Even if I
was doing JS alerts, I found that Firefox serialized them nicely where IE
just lost them.

Here is a simple LZ app which effectively demonstrates the problem:

<canvas height="100" width="400">
  <simplelayout axis="x" spacing="5"/>

  <button name="show" text="alert(top.testvar)"
      onclick="LzBrowser.loadJS('alert(top.testvar)')"/>

  <button name="set" text="top.testvar=10"
      onclick="LzBrowser.loadJS('top.testvar=10')"/>

  <button name="inc" text="(3x) top.testvar++">
    <method event="onclick">
      LzBrowser.loadJS('top.testvar++');
      LzBrowser.loadJS('top.testvar++');
      LzBrowser.loadJS('top.testvar++');
    </method>
  </button>

</canvas>

I realize that one solution is to try to reengineer the application to make
one call to javascript, and have the JS function do the several things.  But
this would have made my event structure, Laszlo, and javascript code very
very messy.  Trying to build in some arbitrary delay between JS calls from
Laszlo is obviously unthinkably ghastly.

The workaround I came up with for my application was to create one separate
named frame for each type of update I would do to my app via JS.  One for
frameset animations, one for status text updates, and one for frame loads.
Within each of these categories, I don't care about collisions, I only want
the latest one to take effect.  With these named frames as separate
communication channels, I can call loadJS() for each type of update with its
specific named frame as the second argument and I won't get any collisions.

What I'd REALLY like is for Laszlo to somehow insulate me from having to
think about any of this.  In a Laszlo environment, I think it would be very
useful to provide an execution guarantee for every call to loadJS(), despite
browser behavior to the contrary.

Maybe it would be possible to build into the html lzx template some js to
allocate frames dynamically such that every call to loadJS could start in
its own frame.  Rather than do this by default (since it might be costly)
perhaps the caller could indicate a special target frame name to get this
functionality.

I also posted the basic problem and workaround to:
http://www.laszlosystems.com/developers/community/forums/showthread.php?s=&t
hreadid=3187

Hope you find this information useful.

Thanks again for such a nice product in Laszlo,
Cameron Brown




-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com