Actually I guess it's possible there may be timing issues if we just return before closing the views. In that 180ms when the panel is closing, another panel might be trying to open the same view that was already open in the previous panel, in which case we need the views to be released. Ugh.
Gijs can you help me with this? I think we can't really let other callers pass
animate = true until resolving this, because of the possibility that, for example, user has the app menu open to the history view, and then clicks the history toolbar button. Then the history view needs to instantly disappear from the app menu while it's still animating, or else the history panel will appear empty for several frames.
I guess it's possible to eliminate that conflict by checking here whether the open view is in an animating panel, and then, if it is, release the view immediately. But maybe there's a better way, and like you said before there are a lot of callers that might want to be animating, so it's potentially a pretty big decision.
Edit: Actually, on third thought... I don't think it's possible that we're calling this method as a result of user clicking a button that opens a panel. When we do that, I'm pretty sure it just calls
panel.hidePopup(true) and not
PanelMultiView.hidePopup(true). So it's not closing all the views in the first place.
I am testing it right now (what I just described about the history view in app menu/history panel) and it seems like we currently resolve this by not opening the history panel until the app menu has fully closed (awaiting popuphidden event I guess). So maybe this is not a big deal at all, and I can just add
return after the
popup.hidePopup(true) call. But maybe you have some insights on how I can make sure that same behavior will be applied to