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 > > > >