#10274 closed defect (fixed)
Select: programmatic, disabled select gets focus in Firefox 3.5
Reported by: | Becky Gibson | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Dijit - Form | Version: | 1.4.0b |
Keywords: | Cc: | Douglas Hays | |
Blocked By: | Blocking: |
Description
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>
Attachments (1)
Change History (8)
Changed 13 years ago by
Attachment: | 10274.patch added |
---|
comment:1 Changed 13 years ago by
Milestone: | tbd → 1.4 |
---|---|
Owner: | set to bill |
Status: | new → assigned |
Summary: | select: programmatic, disabled select gets focus in Firefox 3.5 → Select: programmatic, disabled select gets focus in Firefox 3.5 |
comment:2 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 13 years ago by
comment:5 Changed 13 years ago by
(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.
comment:6 Changed 13 years ago by
comment:7 Changed 11 years ago by
Component: | Dijit → Dijit - Form |
---|
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.