You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ryan J Baxter <rj...@us.ibm.com> on 2011/08/04 02:52:33 UTC

Bug In RPC Code

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.  However, I would 
like to have the rpc code remove the function from the map itself without 
having the gadget site code to tell it to remove the function.  Since I am 
not to familiar with this code I am looking for some thoughts from others 
on what they think the best solution is.

(Note:  I assume this is only a problem when everything is running on the 
same domain.)


-Ryan

Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile