Skip to content
This repository

`propertychange` on an input[type=radio] with this.checked fires standard onChange #2170

Closed
DimitarChristoff opened this Issue December 13, 2011 · 7 comments

4 participants

Dimitar Christoff Olmo Maldonado Arian Stolwijk Daniel Buchner
Dimitar Christoff

http://jsfiddle.net/5CvBb/5/

document.getElements("input").addEvents({
    "change": function() {
        alert("change");
    }
});


document.id("dom").removeClass("validation-failed");

run this with a simple dom of:
<input type="radio" name="foo" value="yes" class="validate-one-required" /> yes
<input id="dom" type="radio" name="foo" value="no" checked="checked" /> no

possibly to do with the new Event Delegation when w/o eventListenerSupport, this does not break in 1.3.2 or earlier.

Arian Stolwijk
Owner

I think it has to do with 4522d61

ping @csuwldcat

Dimitar Christoff

oh, very cool.

/*<ltIE9>*/
delete Element.NativeEvents.propertychange;
delete Element.Events.change;
/*</ltIE9>*/

does not fix my issue, in fact, it makes intended change events really unpredictable. is the bug to do with the fact that radios and checkboxes don't really fire a change but a propertychange instead? hence, the bug is in the condition which fires a change on any propertychange event, as long as the this.checked is true.

Dimitar Christoff

yep. anything you d that does a propertychange fires the change event. http://jsfiddle.net/5CvBb/7/ with a .set("data-attrib") does it too.

Dimitar Christoff

erm. fixed though I am not sure how 'safe' it is.

 return !!((this.type != 'radio' || this.checked) && event.event.propertyName == 'checked');
Daniel Buchner

Wow, I can't believe I didn't check to make sure the attribute that changed was "checked". Haven't tested the patch, but I will tomorrow. Thanks for catching this.

Olmo Maldonado
Owner

I'll try to include this in 1.4.3, otherwise will be included in 1.4.4 (two week sprint) or 1.5 (depends on feature set)

Dimitar Christoff

@ibolmo please consider DimitarChristoff@6abff54 instead as it was the only safe-ish option that did not break normal input[type=text] change, read #2172 (comment)

Dimitar Christoff DimitarChristoff referenced this issue from a commit January 17, 2012
Commit has since been removed from the repository and is no longer available.
Olmo Maldonado ibolmo closed this issue from a commit January 17, 2012
Olmo Maldonado Fixes #2170.
Using DimitarChristoff's fix. See #2170 and #2172.

PASSED: IE6-9.
5fa8489
Olmo Maldonado ibolmo closed this in 5fa8489 January 18, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.