#9794 closed defect (fixed)
ContentPane: TabContainer --> BorderContainer --> ContentPane --> Grid display problem
Reported by: | bill | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Dijit | Version: | 1.3.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
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:
- 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.
- 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.
Attachments (1)
Change History (10)
Changed 12 years ago by
Attachment: | testtabs.html added |
---|
comment:1 Changed 12 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(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.
comment:3 Changed 12 years ago by
comment:4 Changed 12 years ago by
comment:5 Changed 12 years ago by
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.
comment:6 Changed 12 years ago by
(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
comment:7 Changed 11 years ago by
(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
Also added a bunch of tests including one for a TitlePane? with a single layout child (refs #8197).
test case, put as sibling to dojo and dijit directories