[
https://issues.apache.org/jira/browse/SHINDIG-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Baxter reassigned SHINDIG-1787:
------------------------------------
Assignee: Henry Saputra
> Calling navigateGadget again after the initial one destroys the content
> iframe and fails to navigate to the view
> ----------------------------------------------------------------------------------------------------------------
>
> Key: SHINDIG-1787
> URL: https://issues.apache.org/jira/browse/SHINDIG-1787
> 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
>
>
> 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,
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
