dijit.Editor in dojox.layout.TableContainer resize/layout bug

[patrickzope]

When a dijit.Editor is placed in a dojox.layout.TableContainer, an exception is raised, because the editor's layout method expects a "_contentBox" attribute to be set on the instance, but in this case it is not (see attached test case).

The Editor seems to assume that the layout widget will call its resize method and pass in an argument; the TableContainer calls resize without passing in any arguments.

We've worked around this in our code with the following:

editor.resize = function () {
    dijit.layout._LayoutWidget.prototype.resize.apply(
        editor, arguments);
};

[patrickzope]

test case that demonstrates the bug

[bill]

Well I think the issue is that TableContainer is calling layout() on it's children, rather than calling resize(). Here's the code in TableContainer:

// Refresh the layout of any child widgets, allowing them to resize
// to their new parent.
dojo.forEach(children, function(child){
	if(typeof child.layout == "function") {
		child.layout();
	}
});

[PEM]

A simple fix would be to just make use of the _LayoutWidget property : isLayoutContainer

// Refresh the layout of any child widgets, allowing them to resize
// to their new parent.
dojo.forEach(children, function(child){
	if(typeof child.layout == "function" && this.isLayoutContainer) {
		child.layout();
	}
});

can someone please fix this ? Note that this is *not* a bugfix, but it allows you to specify if the TableContainer? should layout or not it's children. You can set to false when you have an editor for example.

I believe the real bug comes from the Editor which does not really comply to what layout widget should.

Anyway, it would be nice to add the check on isLayoutContainer, or add a doLayout.

[dylan]

I will apply PEM's suggested change in TableContainer? for 1.11.

[dylan]

Ok, after massive triage, ended up with about 80 tickets for 1.11 and 400 or so for 1.12. That's a bit unrealistic, so first I changed all 1.12 to 1.13 (with the plan to move some forward to the new 1.12. Now, I'm moving some of the 1.11 tickets that are less likely to get done this month without help to 1.11. Feel free to help out in January if you want to see this ticket land in 1.11.

[dylan]

Ticket planning... move current 1.12 tickets out to 1.13 that likely won't get fixed in 1.12.