just a couple of pedantic coercion fixes where appropriate, and
shuffling a couple of function-scoped variables.
On Mar 24, 2009, at 2:18 PM, Brian Eaton wrote:
Yeah, that is a bit messy. Any changes in there besides delinting?
On Tue, Mar 24, 2009 at 2:00 PM, Paul Lindner <[email protected]>
wrote:
kind of messy due to moving things around, but here you are:
http://codereview.appspot.com/27105
On Mar 24, 2009, at 1:55 PM, Brian Eaton wrote:
Or better than jira, a code review issue over on
http://codereview.appspot.com
On Tue, Mar 24, 2009 at 1:54 PM, Brian Eaton <[email protected]>
wrote:
Somebody's mail server thinks that rpc.js is evil. Can you
attach it
to a jira issue?
On Tue, Mar 24, 2009 at 1:39 PM, Paul Lindner <[email protected]>
wrote:
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?
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.