Select: programmatic, disabled select gets focus in Firefox 3.5

[Becky Gibson]

Load ​http://archive.dojotoolkit.org/dojo-2009-11-05/dojotoolkit/dijit/tests/form/test_Select.html in Firefox 3.5. Scroll down to the "Disabled" and "Programmic and other tests" sections at the bottom of the page. Note that you can not tab to the HTML created disabled select but you can tab to the disabled select that was created programmatically.

If you look at the generated source in Firebug the programmatically created and disabled select has a tabindex=0 while the select generated from HTML does not.

Note that in IE 8 neither disabled select receives tab focus (this is correct>

[bill]

Hmm, well the original code shouldn't be looking at srcNodeRef at all. That's the parser's job.

As for the patch, disable/enable code should be in _setDisabledAttr(), not postCreate(). _setDisabledAttr() will get called automatically on initialization.

Actually Select._setDisabledAttr() and Select._setReadonlyAttr() seem useless, they are already implemented in _FormWidget.js (and inherited from there).

I'll make those changes.

I think I see a general problem with the form widgets though. _FormWidget._setDisabledAttr() explicitly calls focusNode.removeAttribute('tabIndex') (apparently to work around a firefox bug?), but, when the tabIndex parameter has been specified as an argument to the widget constructor, then focusNode.tabIndex is set again, because of attributeMap.

[bill]

(In [20727]) Fixes #10274: programmatic, disabled select gets focus in Firefox 3.5

[bill]

(In [20741]) Intermediate checkin to get Select working again for when items are added to the drop down after the select has been created. Also remove special readonly handling for 1-item in the drop down, to better match normal select behavior. Refs #10274, fixes #10289 !strict.

[bill]

(In [20742]) Fix a few typos, refs #10274 !strict.

[bill]

(In [20748]) Remove code to effectively disable a Select when there are no choices in the drop down. Instead always show the drop down, with a blank drop down for when there are no options. The disabling behavior could be implemented in user code or even as a subclass (or option) to Select, but it seems like the default behavior should mimic the native <select> behavior.

I can see the argument for disabling/setting readOnly on a Select with 0 or 1 elements -- to tell the user that there's no action possible -- but I can also see users getting confused about why they can't open the drop down. With the native behavior at least it's clear what the possible options are.

Refs #10274 !strict.

[bill]

(In [20750]) Remove some unneeded startup(). Looks like it was copied over from DropDownButton but it isn't needed for Select. Refs #10274 !strict.