Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3904 closed defect (fixed)

0.9: SplitContainer/ContentPane/TabContainer issue with Firefox and Safari

Reported by: Jared Jurkiewicz Owned by: bill
Priority: high Milestone: 0.9
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:


0.9: ContentPane/TabContainer? issue with Firefox and Safari

When nesting a tabContainer inside a content pane, which is contained by a split container, I get varying behavior based on browser.

IE 6: Works fine. TabContainer? renders can execute the buttons to flip open tab, can adjust tab container size with the splitcontainer stretcher.

Firefox Mostly works. TabContainer? renders can execute the buttons to flip open tab. However, adjusting the size via the splitcontainer separator causes the tab container to vanish. Invoking selectChild (via the buttons), cause it to reappear.

Safari: TabContainer? doesn't render at all in the splitcontainer contained view.

I have a testcase for this and will attach shortly.

Attachments (1)

tabContainer_layout_bug.html (4.9 KB) - added by Jared Jurkiewicz 12 years ago.

Download all attachments as: .zip

Change History (7)

Changed 12 years ago by Jared Jurkiewicz

comment:1 Changed 12 years ago by bill

Resolution: invalid
Status: newclosed

Usually when people nest a layout container inside a contentpane they are misunderstanding how to use the system. The TabContainer? should probably be a direct child of the SplitContainer?. So reopen this if that's not the problem here.

comment:2 Changed 12 years ago by Jared Jurkiewicz

Resolution: invalid
Status: closedreopened

While that seems to resolve the tab container doing the vanishing act, I don't agree that you shouldn't be able to nest containers in content panes. There's a very good reason you should be able to; the href argument to content pane.

That could very likely load in a .html file that itself contains a tab container or whatnot. If that happens, then your split container adjuster causes failures (as noted in the defect).

This also causes issues with things like dojox.wire, where they are non-visual 'widgets' that act as the binding logic described in DOM. If you have it in the content pane along with the tab container, it splits and loads the view fine. If you have to put TabContainer? outside of the content pane, you also end up having to put the wiring widgets outside, which *then* causes splitContainer to create an expanding section for non-visual dom nodes. What is the solution for that?

Ultimately, I think the bigger problem is the href support of ContentPane?, which can pull in other view layouts into the container ... and they are not rendering properly in FireFox?. Amusingly, they *do* render properly in IE.

comment:3 Changed 12 years ago by Jared Jurkiewicz

One possible solution to embedding dojox.wire code into a tab container as its controller seems to be something like:

<div id="mainTabContainer" dojoType="dijit.layout.TabContainer?">

<div id="tab1" dojoType="dijit.layout.ContentPane?" title="Tab 1">TAB ONE!</div> <div id="tab2" dojoType="dijit.layout.ContentPane?" title="Tab 2">TAB TWO!</div> <div id="tab3" dojoType="dijit.layout.ContentPane?" title="Tab 3">TAB THREE!</div>


<!-- Register a listener for button actions to flip which panel is viewed. --> <div dojoType=""

triggerTopic="buttonAction" sizeShare="0" sizeMin="0"

<div dojoType=""

parameters="arguments[0]" object="mainTabContainer" method="selectChild">





Where it's contained in a non-widget div inside the TabContainer?'s div. That keeps the TabContainer? from treating it like a contained layout widget.

It's a bit hacky, but it does seem to work to at least resolve associating the 'controllers' with a particular widget/layout widget. But again, that doesn't solve the problem if the href on ContentPane? pulls in a page that contains a tab container. Same issue with visibility flakiness occurs.

Personally, I'd like to see the visibility flakiness issue resolved so TabContainer? can be sucked into a content pane via an href to a separate file. It makes building independent 'views' a lot cleaner and separate.

And I know this probably shouldn't matter, all things given with 0.9, but doing such worked perfectly fine in 0.4.X.

comment:4 Changed 12 years ago by bill

If you do want to have


then you need to set a size on the tab container. But there's also a bug where the TabContainer? doesn't get resize events; I'll fix that.

comment:5 Changed 12 years ago by bill

Resolution: fixed
Status: reopenedclosed

Oh actually I already fixed the bug where TabContainer?.startup() doesn't get called (see fixes from #3448, #3406). So if you just add height/width to your TabContainer? then this works.

comment:6 Changed 12 years ago by Jared Jurkiewicz


On latest extract, and with setting style on the TabContainer? of width/height, the problem goes away. If I don't set the style, I get the odd appears until you resize, then vanishes, effect, in Firefox. In either event, setting the style seems to resolve it, so I'm considering this fixed.

Note: See TracTickets for help on using tickets.