[
https://issues.apache.org/jira/browse/SHINDIG-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288672#comment-13288672
]
Henry Saputra commented on SHINDIG-1787:
----------------------------------------
Add proposed patch (the fix is in
features/src/main/javascript/features/container.site.gadget/gadget_site.js):
1. Only create loading gadget holder if loading element is passed and reset
current gadget holder.
2. If current gadget holder exist then simply set it to loading gadget holder.
3. SiteHolder.destroy only called if gadget site is closed or gadget site has
loading element.
> 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
>
> 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,
> 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
