I'm not sure reorganization will solve the problem -- in either case a queueing mechanism should be implemented to avoid race conditions, on a per-transport basis. But let me know if I've missed something in your changes.
On Mon, Apr 6, 2009 at 5:59 PM, Paul Lindner <[email protected]> wrote: > I reorganized the javascript in rpc.js which I believe may have mitigated > this issue. > > On Mar 4, 2009, at 8:52 AM, Weygandt, Jon wrote: > > Which should come first, the call to gadgets.rpc.setAuthToken or the >> placement of the iframe on the page? >> >> If the setAuthToken comes first, then I have seen the "nix" and "fe" >> methods don't get properly initialized, so in IE6 and FF2 I see it will >> use "ifpc". Which is OK, but it means that there is lots of "dead" code >> in rpc.js. "nix" and "fe" methods will never get properly set up. >> >> If the setAuthToken comes after the iframe, there is a race condition, >> where the iframe can be initialized and make the first rpc call before >> the container is ready to receive it, which creates functional issues. >> Even if you try to place the setAuthToken call right after the iframe >> tag, there will still be a potential race condition. It is most common >> when using the browser back button, but depending upon the page layout, >> happens other times as well. >> >> Thanks, >> Jon >> > >
