Browser-specific patches undefine declaredClass

[Adam Peller]

dijit.form.TextBox has two browser branches (e.g. "dijit.form.TextBox.MozMixin") that declare an anonymous mixin based on TextBox and replace the original class definition. The declaredClass is lost. As a result, TextBox gets a declaredClass of uniq_nnn which breaks back-compat for apps expecting it to be "dijit.form.TextBox"

Setting TextBox.prototype.declaredClass = "dijit.form.TextBox"; after applying the branch fixes the problem. Not sure if that can be wrapped in the declare instead.

[bill]

Either

TextBox.prototype.declaredClass = "dijit.form.TextBox"

or adding

declaredClass: "dijit.form.TextBox"

to the prototype break the tests/_BidiSupport/form/robot/Textarea.html test, among others. In tests/_BidiSupport/form/test_Textarea.html, when the Textarea widgets are created _TextBoxMixin::_setTextDirAttr() calls applyTextDir(), but that call goes to the empty _WidgetBase.applyTextDir() rather than the _BidiSupport.applyTextDir() method.

[bill]

In [26473]:

TextBox.js declares an initial "TextBox" class, but depending on the browser either returns that class or a subclass. In both cases, for the user's benefit, the returned (aka public) class must have declaredClass == "dijit.form.TextBox?". Conversely, in the case where there is a base class and a subclass, the base class must *not* have declaredClass == "dijit.form.TextBox?", as this breaks inheritance.

On the flip side, regardless of whether or not there is a subclass, we need the base class to appear in the documentation as dijit.form.TextBox?.

This change hopefully achieves that.

Fixes #13854 !strict.

[bill]

In [28599]:

Use simpler design to implement TextBox browser specific code paths.

Colin fixed the doc parser to understand the old design (ie, a TextBox base class and browser specific TextBox subclasses), but this new design seems easier for the doc viewer, and given browser-specific builds, I don't see that one design is better than the other.

Refs #13854 !strict