Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
DimitarChristoff opened this Issue · 8 comments

5 participants

@DimitarChristoff
Collaborator

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
Owner

I think it has to do with 4522d61

ping @csuwldcat

@DimitarChristoff
Collaborator

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
Collaborator

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
Collaborator

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

@DimitarChristoff
Collaborator

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

@DimitarChristoff DimitarChristoff referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@ibolmo ibolmo closed this issue from a commit
@ibolmo ibolmo Fixes #2170.
Using DimitarChristoff's fix. See #2170 and #2172.

PASSED: IE6-9.
5fa8489
@ibolmo ibolmo closed this in 5fa8489
@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.