Cool thanks for taking a look. I can make that change in addition to the
other ones once you have a chance to do a review.
-Ryan
Email: rjbax...@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: John Hjelmstad <johnfa...@gmail.com>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: Dan Dumont/Westford/IBM@Lotus, dev@shindig.apache.org, Ryan Baxter
<rbaxte...@gmail.com>
Date: 08/10/2011 03:55 PM
Subject: Re: Review Request: RPC calls coming from iFrames within
the same domain when using the same site id fail
Hey Ryan,
I'm taking a look @ the review shortly. Re: using window.frames, the
original reason was basically laziness. For parent-to-child communication,
we could do getElementById('id').contentWindow where available.
-j
On Tue, Aug 9, 2011 at 11:02 AM, Ryan J Baxter <rjbax...@us.ibm.com>
wrote:
> John, in addition to the review below I was wondering if you could shed
> some light on getTargetWin in rpc.js. I was wondering why we chose to
> decide to use the window's frames array to get the iFrame instead of
trying
> getDocumentById first?
>
> -Ryan
>
> Email: rjbax...@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile<
http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/RyanJBaxter
>
>
>
>
> From: "Ryan Baxter" <rbaxte...@gmail.com>
> To: johnfa...@gmail.com, Dan Dumont/Westford/IBM@Lotus,
> Cc: "shindig" <dev@shindig.apache.org>, "Ryan Baxter" <
> rbaxte...@gmail.com>
> Date: 08/09/2011 01:57 PM
> Subject: Review Request: RPC calls coming from iFrames within the
> same domain when using the same site id fail
> ------------------------------
>
>
>
>
> -----------------------------------------------------------
>
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1428/
>
> -----------------------------------------------------------
>
> Review request for shindig, johnfargo and Dan Dumont.
>
>
> Summary
> -------
>
>
> I think I found a bug which was introduced by a recent change to how we
> create gadget site ids.
> Looks like it was these changes
> https://reviews.apache.org/r/1011/#.
>
> The change in the code above changed how we generate site ids. We used
to
> increment a counter every time a new site is created. Now if the DOM
element
> has an id attribute we use that as the site id. If the container chooses
to
> use the same DOM element for two different instances of a gadget site,
(for
> example closing an existing gadget site and using the DOM element of the
> previous gadget site for a new gadget site) the site id will be the same
> between both instances. We also use the gadget site id to generate the
> iFrame id. In rpc.js there is a variable called sameDomain which appears
to
> keep a map of gadget iFrame ids to the the iFrame window's same domain
> function. It doesn't look like we ever remove these functions when the
> gadget iframe is removed from the DOM. Since now you can now generate
two
> different site instances with the same id it will be possible to use the
> previous gadget window's same domain function (which is no longer exist
when
> the gadget is close) for RPC requests coming from the new window
>
> I do not think the solution is to revert the gadget site changes, I
think
> the correct solution is to remove the function from the sameDomain map.
The
> question I have is what is the best way to do this? A strait forward
> solution is to have the gadget sites close function remove the function
from
> the map when it removes the iFrame from the DOM.
>
>
> This addresses bug https://issues.apache.org/jira/browse/SHINDIG-1565.
>
>
https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/SHINDIG-1565
>
>
> Diffs
> -----
>
>
>
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js1155104
>
>
> Diff: https://reviews.apache.org/r/1428/diff
>
>
>
> Testing
> -------
>
> Tested reference implementations which were broken do to this bug
>
>
> Thanks,
>
> Ryan
>
>
>
>
