running rpc.js through jslint (as Henning did a while back) reveals
some potential issues.
The issue here appears to be that:
setAuthToken() calls setupFrame(), which in turn relies upon
relayChannel variable to be set. However that variable is set below
this function, so there's really an implicit declaration of relayUrl
prior this this..
I've attached a cleaned up rpc.js, anyone want to try it out on those
platforms?
ScanMail detected and removed a file that violated policy from the original mail entity. You can safely save or delete this replacement attachment.
On Mar 24, 2009, at 12:09 PM, Weygandt, Jon wrote:
On a related issue for fe and nix methods:
Which should come first, the call to gadgets.rpc.setAuthToken or the
placement of the iframe on the page?
If the setAuthToken comes first, I have seen the "nix" and "fe"
methods not getting properly initialized, so in IE6 and FF2 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.
Thanks,
Jon
-----Original Message-----
From: Brian Eaton [mailto:[email protected]]
Sent: Tuesday, March 24, 2009 11:50 AM
To: [email protected]
Subject: Re: killing "fe" channel for gadgets.rpc
On Tue, Mar 24, 2009 at 11:43 AM, Paul Lindner <[email protected]>
wrote:
Any idea why this breaks?
I'm digging now. There is something wrong with the fall back to IFPC.
I am not in love with the Chrome javascript debugger.
Also, any idea why Chrome does not use the wpm method? I thought it
was based off a fairly recent version of WebKit, no?
Not recent enough.
