shindig-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Baxter (JIRA)" <>
Subject [jira] [Commented] (SHINDIG-1787) Calling navigateGadget again after the initial one destroys the content iframe and fails to navigate to the view
Date Tue, 05 Jun 2012 13:53:24 GMT


Ryan Baxter commented on SHINDIG-1787:

Heny the reviews site is still down :(  Could you upload the patch to the old review site
[1] and add me and Dan as reviewers?  I would like to get this checked in today if at all

Just looking at the code already I am not sure what the point was of moving the dispose method
in GadgetSite.  The content looks the same it just looks like you moved the code.

> Calling navigateGadget again after the initial one destroys the content iframe and fails
to navigate to the view
> ----------------------------------------------------------------------------------------------------------------
>                 Key: SHINDIG-1787
>                 URL:
>             Project: Shindig
>          Issue Type: Bug
>          Components: Javascript 
>    Affects Versions: 2.5.0-beta1
>            Reporter: Doug Davies
>            Assignee: Henry Saputra
>             Fix For: 2.5.0-beta2
>         Attachments: SHINDIG-1787.patch, navigate-to-view.xml
> Here's the description from Ryan:
> 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, 
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message