[SHINDIG-1787] Calling navigateGadget again after the initial one destroys the content iframe and fails to navigate to the view

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.5.0-beta1
• Fix Version/s: 2.5.0-beta2
• Component/s: Javascript
• Assignee: Henry Saputra
• Reporter: Doug Davies
• Created: 01/Jun/12 19:53
• Updated: 05/Jun/12 20:20
• Resolved: 05/Jun/12 20:20

Description

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.