Closed
Bug 278065
Opened 20 years ago
Closed 19 years ago
Change Event Fires On Radio Control That Receives, Not Loses, Focus
Categories
(Core :: DOM: Events, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 222384
People
(Reporter: dhgm, Unassigned)
References
()
Details
(Keywords: helpwanted)
Attachments
(1 file)
|
1.76 KB,
text/html
|
Details |
According to W3C specification [1], "the change event occurs when a control loses the input focus and its value has been modified since gaining focus". In Mozilla, the change event is fired as a duplication of the click event for the control (in a group of radio controls) that receives focus. Compared to that, MSIE seems to work like W3C suggests, and fires on change for the control that loses focus. Although W3C specification [1] states, that the "value" of the control has to have been modified to get a change event on focus loss, both Mozilla and MSIE respond to changes of the "checked" property, not the "value" property. Assuming responding on checked-changes is correct, I would consider the MSIE implementation (see below) as the correct interpretation of W3C specification [1] of change events for radio controls. Reproducible: Always. Steps to reproduce: 1. Load test case [2] into (both) Mozilla (and MSIE), 2. Click on both radio controls and then on document background, 3. Watch output in textarea control (in both browsers) when a) clicking on first radio control b) clicking on second radio control after that c) clicking document background after that Actual Results in Mozilla: 3.a) Both a click and a change event for the first radio 3.b) Both a click and a change event for the second radio 3.c) No click or change event for neither radio Actual Results in MSIE: Like expected results below. Expected Results: 3.a) A click event for the first radio. No change event for neither radio 3.b) A click event for the second, and a change event for the first radio 3.c) A change event for the second radio Footnotes: [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings- htmlevents [2] http://www.innoline-systemtechnik.de/dhgm/radioevents.html
|
Reporter | |
Comment 1•20 years ago
|
||
|
||
Comment 2•20 years ago
|
||
Mozilla's behaviour seems consistent with: http://whatwg.org/specs/web-forms/current-work/#the-change
|
|
Reporter | |
Comment 3•20 years ago
|
||
(In reply to comment #2) > Mozilla's behaviour seems consistent with: > http://whatwg.org/specs/web-forms/current-work/#the-change I would expect an UA that supports interpretation of different doctype declarations to behave like stated in the correspondent specification if an appropriate doctype ist declared in the document. The doctype declaration I've supplied in the test case is <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> so I expect the UA to behave like stated in [1]. Even if it's intended that an UA implements some features of Web Forms 2.0 today, the application should be aware of differences in behaviours between the different specifications it implements. If the doctype declaration provided is HTML 4, change events should be fired as stated in the HTML 4 specification, and analogical change events should be fired as stated in the Web Forms 2.0 specification only if the doctype provided is the one that will be given in [2] at a later date. If there is a need for different event behaviours for events with one and the same name, and a document's author cannot determine in which way events are fired by declaring the appropriate document type, cross-browser scripting becomes even more complicated again. [1] http://www.w3.org/TR/html4/interact/scripts.html#adef-onchange [2] http://whatwg.org/specs/web-forms/current-work/#conformance
|
||
Updated•20 years ago
|
Keywords: helpwanted
|
||
Comment 4•19 years ago
|
||
*** This bug has been marked as a duplicate of 222384 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•