ContentPane: TabContainer --> BorderContainer --> ContentPane --> Grid display problem

[bill]

See attached test case from Jose Noheda. The hidden tab has a grid that doesn't get displayed properly.

The hidden tab is the hierarchy:

BorderContainer --> ContentPane --> Grid

The cause is:

1. on page load, the BorderContainer's ContentPane thinks it's shown but actually it's hidden indirectly, because the BorderContainer is hidden. ContentPane.startup() calls _scheduleLayout(), which calls _isShown(), and since _isShown() returns true it tries to layout instantly. Besides being inefficient, this leads to the next problem.

2. selecting the BorderContainer pane calls ContentPane.resize() but ContentPane.resize() doesn't recurse to it's children since it thinks they've already been laid out.

There's also another problem/inefficiency but it's not the cause of this error: _Grid.startup() calls _render(). _render() shouldn't really be called until resize(). The layout widgets have code where startup() calls resize() but only if the layout widget is "top level", not if the parent widget is going to call child.resize(). Grid would benefit from this.

[bill]

test case, put as sibling to dojo and dijit directories

[bill]

(In [20000]) Make nested ContentPanes defer loading of href and resizing of child widgets until the ContentPane is shown. Specifically addressing complicated cases like nested TabContainers or TabContainer --> BorderContainer --> ContentPane. When ContentPane is a child of a layout container it's hard to efficiently determine whether it's shown or not, but we know that resize() will be called the first time it's shown (perhaps on page load), so if resize() _hasn't_ been called then defer loading of href and resizing of child widgets.

[Nathan Toone]

(In [20007]) Refs #5528 #9794 - changelist r20000 means that resize does not get called for already-selected (default) values - so we need to ensure that _transition is called for these items

[Nathan Toone]

(In [20009]) Refs #5528, #9794 - If we have an open value, we should use that if we have been resized - so that we honor at least that flag, since it is fast to check !strict

[bill]

Note that [20007] (listed above) is for a problem limited to _SelectedStackMixin.js, that (as far as we know) resize() is getting called fine in the general case.

[bill]

(In [20012]) Bunch of tests to make sure that resize() gets called correctly on ContentPane? children, when ContentPane? is the child of a layout widget.

Refs #9794

[bill]

(In [20099]) Various TabContainer? href-loading and children resizing fixes, centered around ContentPane?'s role as a layout widget:

• Fix doLayout=false TabContainer? (broken by recent checkins for #5528, #9794)
• Fix problem where resizing the TabContainer? would refresh a pane with refreshOnShow=true. It's only supposed to refresh when the pane is hidden then shown again. (fixes #8969 !strict)

Differentiated between onShow(), which indicates that the ContentPane? is being shown, and resize(), which, when the ContentPane? is in a layout widget hierarchy, occurs both when the ContentPane? is shown but also when it changes size.

It's complicated because a ContentPane? being made visible is indicated in different ways depending on the situation:

• For a TitlePane?, opening the TitlePane? just generates an _onShow() notification
• For a TabContainer? --> BorderContainer? --> ContentPane? configuration, the ContentPane? just gets a resize() call when first made visible
• For the typical TabContainer? --> ContentPane?, it gets both an _onShow() and a resize() call

Refs #5528, #9794 !strict

Also added a bunch of tests including one for a TitlePane? with a single layout child (refs #8197).

[bill]

(In [20905]) Update comments for isContainer and isLayoutContainer flags for how they are currently being used (specifically since ContentPane defines them now, even though it's not a typical layout widget).

Refs #5528, #9794 !strict

[bill]

(In [20926]) Fix comment for getParent(), refs #5528, #9794 !strict