363693 - input type=radio doesn't fire onchange event for unchecking

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Filip Jirsák]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; cs-CZ; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs-CZ; rv:1.8.1) Gecko/20061010 Firefox/2.0

For <input type=radio> onchange event is fired when changing state from unchecked to checked only. When state is changed from checked to unchecked, no onchange event is fired.

Reproducible: Always

Steps to Reproduce:
1. select some input type=radio
2. select other input type=radio in same group
Actual Results:  
In step 2, only onchange event for second input is fired

Expected Results:  
In step 2, first onchange event for first input should be fired, after that onchange event for second input should be fired

Comment 1

[Filip Jirsák]

Attachment: testcase for this bug

Should generate pairs of "radio# false radio# true". Actually generate only "radio# true" events.

Comment 2

[Steve England [:stevee]]

Well, IE doesn't return 'radio# false radio# true' pairs either (just the same as firefox) and Opera doesn't seem to return anything.

Comment 3

[Jesse Ruderman]

Safari also fires onchange only for checking, not for unchecking.

http://www.whatwg.org/specs/web-forms/current-work/#the-change doesn't seem to make it clear what should happen for radio buttons.

Comment 4

[Filip Jirsák]

(In reply to comment #3)
> http://www.whatwg.org/specs/web-forms/current-work/#the-change doesn't seem to
> make it clear what should happen for radio buttons.
> 
DOM3 says:

"onchange - A control loses the input focus and *its value has been modified* since gaining focus. This event can occur either via a user interface manipulation or the focus() methods and the attributes defined in [DOM Level 2 HTML]. This event is valid for INPUT, SELECT, and TEXTAREA element."

See http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-eventgroupings-htmlevents

Working draft web forms 2.0 modifies it from after-focus-lost event to after-selection-complete event:

"Specifically, for controls implemented with a non-editable stateful UI (e.g. select  elements, checkboxes, or *radio buttons* as deployed in typical desktop Web browsers), the change event shall be fired when the selection is completed, even if the control does not lose focus."

Comment 5

[Boris Zbarsky [:bzbarsky]]

The problem with a radio is that what changes value is the _radio group_, not the individual radio the value of an individual radio does NOT change; what changes is whether it submits at all.  The use of <input> for radios is really quite unfortunate that way...  In any case, per the DOM spec there should be no onchange events here at all.  Which just points out that the DOM spec authors didn't think about this case when writing the spec.

Given that all the UAs does this the same way, we should just specify that way (and wontfix this bug), imo.

Ian, want to do the WHATWG honors? ;)

Comment 6

[Hixie (not reading bugmail)]

I have noted this bug and will deal with it when I next work on this topic.

Comment 7

[Hixie (not reading bugmail)]

Done; HTML5 now defines precisely when 'change' is fired and covers this case. Let me know if you see anything wrong with it. Thanks!

Comment 8

[Mounir Lamouri (:mounir)]

It is working with 3.6 and current trunk.