Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4753 closed defect (fixed)

keyboard behavior of radiobuttons incorrect on IE

Reported by: Becky Gibson Owned by: davidb
Priority: high Milestone: 1.0
Component: Accessibility Version: 0.9
Keywords: Cc: Adam Peller, Douglas Hays
Blocked By: Blocking:

Description

The keyboard behavior of dijit radiobuttons should behave the same way as a standard html radio button. In a group, when user tabs, the first radio selected should be in the tab order. Once focus is within the radio group, up and down arrows should move between radios in the group and select the radio with focus. If no button in a group is selected, tab should go to the first radio in the group and then arrow keys are used to select and move from radio to radio. Arrow keys do not work in IE6 & 7 but they do work in FF

Attachments (3)

4753.diff (511 bytes) - added by davidb 12 years ago.
fixes bug... will test for regressions.
4753.2.diff (7.5 KB) - added by davidb 12 years ago.
expanded fix.
4753.3.diff (7.9 KB) - added by davidb 12 years ago.
added name to Form template (thanks peller)

Download all attachments as: .zip

Change History (16)

comment:1 Changed 12 years ago by davidb

Cc: davidb added

comment:2 Changed 12 years ago by Becky Gibson

Owner: changed from Becky Gibson to davidb

comment:3 Changed 12 years ago by davidb

In FF using fireclipse I can see the name attribute specified on the radio buttons in the test file making it through to the rendered dom input radio node. In IE7 using the IE Developer Toolbar I don't see the name attribute. Having a common name attribute is used for browser grouping of radio inputs. It has been a while since I looked at Checkbox.js and quite a bit has changed.

We'll need to triage where/how the name attribute gets dropped on IE.

Note: I think we'll want to update the test file as the 'set value to "fish"' button doesn't seem to do anything anymore.

comment:4 Changed 12 years ago by davidb

Cc: Adam Peller added; davidb removed

Peller, are you familiar with the parsing of attributes? (Please see my previous comment).

comment:5 Changed 12 years ago by bill

Priority: normalhigh

If name isn't being copied to the DOM node then form submit won't work at all, so marking this as critical.

Changed 12 years ago by davidb

Attachment: 4753.diff added

fixes bug... will test for regressions.

comment:6 Changed 12 years ago by davidb

severity: normalmajor
Status: newassigned

I suspect there is a problem related to the fact that in IE: "The NAME attribute cannot be set at run time on elements dynamically created with the createElement method." (from MSDN).

The patch just posted adds the name attribute to the template so that it is added during creation.

comment:7 Changed 12 years ago by bill

Cc: Douglas Hays added

Hmm, if you add the "name" attribute to the template then should remove it from attributeMap. But also, if what MSN says is true then how does the code in MappedTextBox? work, that creates a new element (the hidden textbox) and sets it's name?

Changed 12 years ago by davidb

Attachment: 4753.2.diff added

expanded fix.

comment:8 Changed 12 years ago by davidb

I'm at a loss as to why form submission worked with dijit radio buttons on IE, given the name attribute, dynamic element creation issue; but it seems to have been working (even though the attribute wasn't showing up in the IE developer toolbar for dijit radio buttons).

I'm not sure which fix we should pursue... a minimal one (the first one I attached). Or if we should consider something like the second, which worries me given the little time to catch regressions.

Changed 12 years ago by davidb

Attachment: 4753.3.diff added

added name to Form template (thanks peller)

comment:9 Changed 12 years ago by bill

Actually, it's not so surprising to me that IE semi-works (but doesn't completely work) when name is set after node creation. So your attached patch looks good to me.

comment:10 Changed 12 years ago by davidb

Resolution: fixed
Status: assignedclosed

(In [11226]) Fixes #4753: removed name attribute from attribute map for form widgets and added to templates; IE requires the name attribute at the time of DOM element creation.

comment:11 Changed 12 years ago by davidb

(In [11227]) Refs #4753, name attribute must be specified at the time of input element creation (for IE).

comment:12 Changed 12 years ago by davidb

(In [11228]) Refs #4753, unit test.

comment:13 Changed 12 years ago by bill

(In [11272]) Refs #4753, fixes #4964: missing name=${name} in combobox template

Note: See TracTickets for help on using tickets.