Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

fix for any propertychange firing onChange in ie7/8 on checkboxes AND radios #2172

Closed
wants to merge 1 commit into from

4 participants

@DimitarChristoff
Collaborator

see #2170, updated to also support checkboxes. testcase: http://jsfiddle.net/5CvBb/12/

@arian
Owner

nice, I'll wait for others to comment (@ibolmo, @csuwldcat, @cpojer), but it looks good to me!

@DimitarChristoff
Collaborator

no, I am actually checking this atm for breakages on other input types which will likely fail.

@arian arian reopened this
@DimitarChristoff
Collaborator

actually. this causes errors.

return !!(event.type === 'change' || event.type === 'propertychange' && event.event.propertyName == 'checked')

works for all elements and change is fine. http://jsfiddle.net/5CvBb/23/ - however, it fires a change event on a radio group sharing the same name to all elements that experience propertychange of checked. not sure if this is the accepted dom model.

commit / sha:
DimitarChristoff@6abff54

let me know if i should make a new pull request.

@csuwildcat

Being that I haven't tested this yet, I hate to ask the seemingly obvious question: Why can't you just add a condition that ensures the changed attributed is "checked" to the part of the existing conditions that affect only radios and checkboxes?

@DimitarChristoff
Collaborator

because it broke change for input[type=text], i can dig out the jsfiddle that did this but it's been a lot...

@DimitarChristoff
Collaborator

this fixes it so it only fires the change once per radio group:

return !!(event.type === 'change' || this.checked && event.type === 'propertychange' && event.event.propertyName == 'checked')

DimitarChristoff@53b0dc5
it also does one less property lookup due to base which already has read the type and set the event accordingly.

@csuwildcat

Did you run the tests in all the various browsers yet? Other than that, the logic seems to make sense.

@DimitarChristoff
Collaborator

i haven't got the test/spec runner or repo at home (windows), will do tomorrow morning at work - just tested IE7 and IE8 so far, don't even have an IE6 VM

@arian
Owner

You don't need that, just open the html file I linked to, it's in the -core repo now, and that file doesn't require the spec-runner.

@DimitarChristoff
Collaborator

@arian that spec file is out of date, it references Type/Event.js not DOMEvent.js. fixed here: DimitarChristoff@6c8f004

tests pass, btw - at least on IE9 in IE7 and IE8 doc mode (forced). if you want to try it's here http://fragged.org/dev/mootools-core/Specs/1.4client/Element/Element.Event.change.html

@csuwildcat

This fix prevents change from firing when unchecking a checked checkbox in IE7 and IE8, probably 6 too, but I don't have access to it right now. I will revisit the issue this week.

Source of error: http://fragged.org/dev/mootools-core/Specs/1.4client/Element/Element.Event.change.html

@ibolmo ibolmo referenced this pull request from a commit in ibolmo/mootools-core
@ibolmo ibolmo Fixes #2170.
Using DimitarChristoff's fix. See #2170 and #2172.

PASSED: IE6-9.
5fa8489
@ibolmo ibolmo closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 1 deletion.
  1. +1 −1  Source/Element/Element.Event.js
View
2  Source/Element/Element.Event.js
@@ -175,7 +175,7 @@ if (!window.addEventListener){
return (this.get('tag') == 'input' && (type == 'radio' || type == 'checkbox')) ? 'propertychange' : 'change'
},
condition: function(event){
- return !!(this.type != 'radio' || this.checked);
+ return !!(this.type != 'radio' || this.checked && event.event.propertyName == 'checked');
}
}
}
Something went wrong with that request. Please try again.