Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#12349 closed defect (fixed)

TabContainer: nested TabContainer resize glitch in IE9

Reported by: Andy Owned by:
Priority: high Milestone: 1.5.2
Component: Dijit Version: 1.6.0
Keywords: TabContainer IE9 Cc:
Blocked By: Blocking:

Description (last modified by bill)

Using http://download.dojotoolkit.org/release-1.6.0rc1/dojo-release-1.6.0rc1/dijit/themes/themeTester.html#bogus

1) Click the tab labelled 'Nested tab container'
2) Click any of the top menu items

The nested tabs now render behind the tab strip. A resize of the splitter puts everything right.

Tested with IE9 (RC) on Win7. Works fine on IE7 - not tested IE8.

Change History (19)

comment:1 Changed 8 years ago by Kenneth G. Franqueiro

I would note that in both IE8 and 9, when opening a menu for the first time while the Nested TabContainer tab is active, a scrollbar appears for a split second, then disappears. The reported tab-stomping only occurs in IE9.

comment:2 Changed 8 years ago by bill

Description: modified (diff)
Milestone: tbd1.6.1
Summary: Nested TabContainer resize glitch in IE9TabContainer: nested TabContainer resize glitch in IE9

comment:3 Changed 8 years ago by bill

This is working fine for me on IE9 (I tried the exact link you specified), maybe this is something they fixed between the RC and the release. Does it still reproduce for you?

I tried clicking View/Outline? from the menu. Is that what you meant?

comment:4 Changed 8 years ago by Kenneth G. Franqueiro

I can reproduce the symptoms, in rc, final, and trunk. Just open any menu for the first time - you'll see the tabcontainer glitch out even on other tabs, actually. It looks as if the contents are just all getting shifted up so they start behind the tabs, in IE9.

Here's a thought, Bill: what size window have you been attempting with? Try smaller.

comment:5 Changed 8 years ago by bill

Version: 1.6.0rc11.6.0

Ah, you are right, making the window smaller reproduces the problem. I think it's when the window is small enough that the tabstrip gets scrolling (with left/right arrows). I can also reproduce the problem without using the MenuBar by just making the viewport smaller until the left/right scroll buttons show up.

comment:6 Changed 8 years ago by bill

The problem isn't limited to nested TabContainers. Upon resizing the browser window, when there are left/right scroll buttons on the top TabContainer, you can see for any tab that the contents get shifted up too high.

TabContainerBase.js calls layoutChildren() to position the tab list and content. LayoutChildren?() ends up calling something like dojo.marginBox(node, {w: 700}); on the topTabs_tablist, to set it's width. Then it calls dojo.marginBox(node) on the topTabs_tablist to get it's height.

Although node.offsetHeight was previously 30px (for the tablist node), after the dojo.marginBox(node, {w: 700}); call node.offsetHeight becomes 0px. Thus dojo.marginBox(node) returns a height of 0, which eventually leads to the tab content being positioned incorrectly.

comment:7 Changed 8 years ago by bill

Actually, resizing the topTabs_tablist is a more complicated operation than just dojo.marginBox(node, {w: 700}), it does a bunch of stuff (inside of ScrollingTabController.resize()), and the line that actually triggers offsetHeight --> 0 is setting aria-disabled on the left scroll button.

However, I think that's a red herring, the basic issue is that querying a node's size right after you've changed the contents is unreliable. I have a patch which I'll check in shortly.

comment:8 Changed 8 years ago by bill

Resolution: fixed
Status: newclosed

(In [24097]) Make ScrollingTabController.resize() return the new size of the widget, and make layoutChildren() take advantage of that return value and avoid calling dojo.marginBox() to query the size.

This works around IE9 glitch in TabContainer layout because after laying out the tablist, dojo.marginBox(tablist) returns height of 0 because tablist.node.offsetHeight is incorrectly 0.

Fixes #12349 on 1.6 branch, !strict.

comment:9 Changed 8 years ago by bill

(In [24098]) Make ScrollingTabController.resize() return the new size of the widget, and make layoutChildren() take advantage of that return value and avoid calling dojo.marginBox() to query the size. This works around IE9 glitch in TabContainer layout because after laying out the tablist, dojo.marginBox(tablist) returns height of 0 because tablist.node.offsetHeight is incorrectly 0. Fixes #12349 on trunk, !strict.

comment:10 Changed 8 years ago by darth

Can you take a look at http://dojo-toolkit.33424.n3.nabble.com/Dojo-1-6-1-release-candidate-1-is-available-tp2820167p2840649.html

Changing position to absolute is causing a regression by forcing layout container children having their CSS overwritten. Does one need to now change something to counter that change?

comment:11 Changed 8 years ago by bill

I can't imagine why that would break your layout, please attach a test case, thanks.

comment:12 Changed 8 years ago by darth

Try this in 1.6 like below, and then in dojo 1.6.1

comment:13 Changed 8 years ago by darth

for some reason I cant paste code here, the website throws an error, its linked in the RC1 thread... http://dojo-toolkit.33424.n3.nabble.com/Dojo-1-6-1-release-candidate-1-is-available-tp2820167p2845206.html

comment:14 Changed 8 years ago by bill

That test case is invalid because you haven't specified a size on your LayoutContainer widget. Also, it doesn't have a TabContainer at all. Note also that you can attach files here using the button marked "Attach file".

comment:15 Changed 8 years ago by darth

Well the changelist shows the change was made in _LayoutWidget, which is the parent for all these layout containers. So yeah its nothing to do with TabContainer?, just a side effect.

Specifying a size on the layout container doesn't change the fact that the children are position absolute and all squished into a corner. In the test case even if you add a style and give it a height or width, you will see that the div's are all squished in the 1 same absolute place. While in 1.6.0 they were fine, one below the other.

comment:16 Changed 8 years ago by bill

I forgot to mention, you also need to specify a layoutAlign for each child (each ContentPane) of a LayoutContainer. That's not needed for children of a TabContainer. So, maybe you should attach a test case of TabContainer showing the problem you are having.

comment:17 Changed 8 years ago by darth

Yes I was just about to post that. I wasn't suggesting a new bug was created, I think this bug fixed caused some bad practice that my stuff was using to regress, let me try and maybe giving each child a layout align will fix the issue.

comment:18 Changed 8 years ago by darth

One thing I noticed though, since positions are absolute one needs to have a non-auto height. So if dojo.fx animation is used like dojo.fx.wipeIn, it ends up setting height as auto...

comment:19 Changed 8 years ago by Kenneth G. Franqueiro

Milestone: 1.6.11.5.2

Updating milestone to 1.5.2 to reflect inclusion in changeset [26956] for ticket #14199.

Note: See TracTickets for help on using tickets.