-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
opt out of input events for ie 10 and 11 #4051
Conversation
Ditto this one, I know ya'll are the most busy, but it'd be great to get a fix for this into 0.14. Let me know if there is anything I can do to help. |
if (activeElement.attachEvent) { | ||
activeElement.attachEvent('onpropertychange', handlePropertyChange); | ||
} else { | ||
activeElement.addEventListener('propertychange', handlePropertyChange, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this will work. According to MSDN, the propertychange
event is only fired when listened via the attachEvent
API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya I saw that as well, but right below that it also demonstrates it using addEventListener
, and it does seem to work in my testing. It could probably stand further testing
This solution feels simple and clean to me, it avoids having a whole additional browser-dependent code path to follow (ie. better than #3826). I'll leave it unmerged for a day so people can raise any objections. If there are none, let's ship it. |
if (activeElement.attachEvent) { | ||
activeElement.attachEvent('onchange', manualDispatchChangeEvent); | ||
} else { | ||
activeElement.addEventEventListener('change', manualDispatchChangeEvent, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this actually be reached? It's kind of hard to tell at first glance, but this only targets IE8 right? So it shouldn't be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@syranide Prior to this change, this code path targeted IE8 and IE9. This change makes IE10 and IE11 also follow the same code path. IE11 does not have attachEvent
which is why this is reachable. See #3826 (comment) for context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jimfb But...
doesChangeEventBubble = isEventSupported('change') && (
!('documentMode' in document) || document.documentMode > 8
);
if (doesChangeEventBubble) {
getTargetIDFunc = getTargetIDForChangeEvent;
} else {
handleEventFunc = handleEventsForChangeEventIE8;
}
doesChangeEventBubble
should only be false for IE8 and thus it shouldn't go down that path for any other browser as far as I can tell. Or am I reading this wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll defer to @jquense ; Jason, thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is currently unreachable yeah, Its been a few months but I may have just been overzealous refactoring. Let me remove it...
@jquense updated the pull request. |
opt out of input events for ie 10 and 11
Thanks @jquense! |
cc @salier as a heads up since you've been dealing with this sort of stuff. |
while supported, the "input" event is too noisy in IE. It Fires on
placeholder sets, and when an input is focused with a placeholder.
This is an potential alternative fix to #3826
cc @syranide
fixes #3377 and fixes #3484