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 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.js 1155104 Diff: https://reviews.apache.org/r/1428/diff Testing ------- Tested reference implementations which were broken do to this bug Thanks, Ryan
