Opened 13 years ago

Closed 13 years ago

Last modified 11 years ago

#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:


Load 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)

10274.patch (2.4 KB) - added by Becky Gibson 13 years ago.

Download all attachments as: .zip

Change History (8)

Changed 13 years ago by Becky Gibson

Attachment: 10274.patch added

comment:1 Changed 13 years ago by bill

Milestone: tbd1.4
Owner: set to bill
Status: newassigned
Summary: select: programmatic, disabled select gets focus in Firefox 3.5Select: programmatic, disabled select gets focus in Firefox 3.5

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.

comment:2 Changed 13 years ago by bill

Resolution: fixed
Status: assignedclosed

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

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by bill

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

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by 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.

comment:7 Changed 11 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.