This is certainly a bug, I can reproduce it in the common container as well. After stepping through the code I think I figured out what is happening, basically when you switch views after the initial load in the GadgetSite code both the currentGadgetHolder and the loadingGadgetHolder are set to a GadgetHolder pointing to the same DOM element. When we call GadgetSite.onRender when switching views we first call currentGadgetHolder.dispose which removes the element from the DOM and then we finally set currentGadgetHolder to loadingGadgetHolder. Problem is since the currentGadgetHolder and the loadingGadgetHolder point to the same DOM element we end up removing the iframe which contained the new view.
I THINK if you supply a separate buffering element when you create your site you would not run into this problem, you can certainly give that a shot and see if that works. If there is no buffering element the site will use the element in which the gadget is currently rendered in when creating the loadingGadgetHolder, which leads to the problem we are seeing. I reverted the changes Henry made in this review, https://reviews.apache.org/r/4486/ and the problem goes away. Henry can you take a look at this? I am pretty sure it is the changes in SiteHolder.dispose that are causing the problem here. While I think using a buffering element would solve the problem, the API (at this point) indicates the buffering element is optional, so everything should work without it. -Ryan From: daviesd <[email protected]> To: <[email protected]>, Date: 06/01/2012 11:30 AM Subject: Re: requestNavigateTo and beta1 v.s. trunk differences Ya, that was my first thought. But inspecting with firebug reveals that there is not even any content from the view navigated to. Even if I change the code to container.navigateGadget( site, url, [], {} ); It doesn't re-navigate to the default view again (even though that how I rendered the gadget in the first place). I'll double check on the adjustHeight stuff, but I don't think that is it. Thanks Ryan (btw... I watched some of your youtube opensocial sandbox videos yesterday... very nice). doug On 6/1/12 11:18 AM, "Ryan J Baxter" <[email protected]> wrote: > Doug, does the gadget call adjustHeight? There were changes that went > into Shindig [1] [2] that changed some of the CSS inside the gadgets > iframe to allow the inter content to scroll. We noticed in some of our > containers that we had to alter the CSS on our gadget sites to make things > work properly. Is there content actually in the site? Maybe the > adjustHeight call is not working / the CSS for the site element needs to > change. > > > [1] https://issues.apache.org/jira/browse/SHINDIG-1766 > [2] https://issues.apache.org/jira/browse/SHINDIG-1767 > > -Ryan > > > > > From: daviesd <[email protected]> > To: shindig <[email protected]>, > Date: 06/01/2012 10:58 AM > Subject: Re: requestNavigateTo and beta1 v.s. trunk differences > > > > Doh! It¹s Friday. I guess I should have described the symptoms. I end up > with a gadget with no content area (collapsed). > > > On 6/1/12 10:50 AM, "daviesd" <[email protected]> wrote: > >> Does anyone (Dan?) have any idea why this code >> >> container.rpcRegister("requestNavigateTo", function >> requestNavigateTo(rpcArgs, view, params) { >> >> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY], >> url = site.getActiveSiteHolder().getUrl(), >> renderParams = {}; >> >> renderParams[osapi.container.RenderParam.VIEW] = view; >> container.navigateGadget( site, url, params, renderParams ); >> }); >> >> doesn¹t work with the latest 2.5 snapshot? We¹ve been using beta1 since > it >> was created, but will all the activity for beta2 I thought I ought to > get a >> jump start and see what broke for us. This worked in beta1. I¹ve > logged the >> site, url, and view and they all seem legit. >> >> doug > >
