Skip to content

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

Closed
DimitarChristoff opened this Issue Dec 13, 2011 · 8 comments

5 participants

@DimitarChristoff
MooTools member

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
MooTools member
arian commented Dec 13, 2011

I think it has to do with 4522d61

ping @csuwldcat

@DimitarChristoff
MooTools member

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.

@DimitarChristoff
MooTools member

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.

@DimitarChristoff
MooTools member

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

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

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.

@ibolmo
MooTools member
ibolmo commented Dec 13, 2011

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)

@DimitarChristoff
MooTools member

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

@ibolmo ibolmo added a commit that closed this issue Jan 18, 2012
@ibolmo ibolmo Fixes #2170.
Using DimitarChristoff's fix. See #2170 and #2172.

PASSED: IE6-9.
5fa8489
@ibolmo ibolmo closed this in 5fa8489 Jan 18, 2012
@fanxiaolong

你们会中文吗?

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.