BorderContainer: does not layout form widgets

[William Riley]

When adding an input widget, such as dijit.form.SimpleTextarea? or dijit.form.TextBox? to a dijit.layout.BorderContainer?, the BorderContainer? does not position the widget correctly.

[bill]

TextArea isn't supposed to work but SimpleTextArea does work, AFAIK, as of 1.2, as of [12384] (later that change was erased because SimpleTextArea inherits from TextBox, but of course the BorderContainer thing still works).

[William Riley]

I figured out the problem

The form widgets are removing the dijitBorderContainerPane class during focus events, so position:absolute; is missing after it gets focus, but before that it gets laid out correctly.

I've attached a test.

[bill]

Ah, I see. Yah, FormWidget?.js does:

// Get original (non state related, non baseClass related) class specified in template
if(!("staticClass" in this)){
	this.staticClass = (this.stateNode||this.domNode).className;
}

and I guess addClass("dijitBorderContainerPane") happens after that.

I'll work on this.

[William Riley]

I found another (related) problem, if a dijit.form.TextBox? is in a BorderContainer? without a textarea, it doesn't get it's width set.

Changing line 311 to this fixed the problem:

// Nodes in IE don't respond to t/l/b/r, and TEXTAREA/INPUT doesn't respond in any browser
var janky = dojo.isIE || dojo.some(this.getChildren(), function(child){
	return child.domNode.tagName == "TEXTAREA" || child.domNode.tagName == "INPUT";
});

[bill]

(In [15163]) Fixes #7611: BorderContainer?: does not layout form widgets.

Refactor _setStateClass() to be resilient when classes are added to domNode after the widget has been initialized. This is safer but slower than the old version, which saved the node's original class.

For fear of performance issues it's only writing into domNode.className once; code would have been shorter but possibly slower if it made many calls to addClass() and removeClass().

!strict