Change:
See for example code. When setting and removing focus from an empty field with some text, the event is triggered for IE 11 (I have not tested older versions). It does not trigger for other browsers. My current work-around is to test the that was last passed to the input with what is returned by , and only act if they are different, but it would be nice if React would not send the change-event in the first place.
Sounds like a browser quark that we should normalize against, right? Is there anything other than value that we would need to check?
Yeah, this seems odd. Probably on the challenging side for a first bug, but it would be good to figure out why this is happening and how we can prevent it, while still making it possible to type the placeholder text in directly as says.
, not really related but I imagine both could be solved by a similar fix.
Also goes for IE10.

Discussion:
var isInputEventSupported = false; if (ExecutionEnvironment.canUseDOM) { // IE9 claims to support the input event but fails to trigger it when <del> // deleting text, so we ignore its input events </del> <ins> // deleting text, so we ignore its input events. // IE10+ fire input events to often, such when a placeholder // changes or when an input with a placeholder is focused. </ins> isInputEventSupported = isEventSupported('input') && ( <del> !('documentMode' in document) || document.documentMode > 9 </del> <ins> !('documentMode' in document) || document.documentMode > 11 </ins> ); } /** <del> * (For old IE.) Replacement getter/setter for the `value` property that gets </del> <ins> * (For IE <=11) Replacement getter/setter for the `value` property that gets </ins> * set on the active element. */ var newValueProp = {

}; /** <del> * (For old IE.) Starts tracking propertychange events on the passed-in element </del> <ins> * (For IE <=11) Starts tracking propertychange events on the passed-in element </ins> * and override the value property so that we can distinguish user events from * value changes in JS. */

); Object.defineProperty(activeElement, 'value', newValueProp); <del> activeElement.attachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.attachEvent) { activeElement.attachEvent('onpropertychange', handlePropertyChange); } else { activeElement.addEventListener('propertychange', handlePropertyChange, false); } </ins> } /** <del> * (For old IE.) Removes the event listeners from the currently-tracked element, </del> <ins> * (For IE <=11) Removes the event listeners from the currently-tracked element, </ins> * if any exists. */ function stopWatchingForValueChange() {

// delete restores the original property definition delete activeElement.value; <del> activeElement.detachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.detachEvent) { activeElement.detachEvent('onpropertychange', handlePropertyChange); } else { activeElement.removeEventListener('propertychange', handlePropertyChange, false); } </ins> activeElement = null; activeElementID = null;

} /** <del> * (For old IE.) Handles a propertychange event, sending a `change` event if </del> <ins> * (For IE <=11) Handles a propertychange event, sending a `change` event if </ins> * the value of the active element has changed. */ function handlePropertyChange(nativeEvent) {

} } <del> // For IE8 and IE9. </del> function handleEventsForInputEventIE( topLevelType, topLevelTarget,

// In IE8, we can capture almost all .value changes by adding a // propertychange handler and looking for events with propertyName // equal to 'value' <del> // In IE9, propertychange fires for most input events but is buggy and </del> <ins> // In IE9-11, propertychange fires for most input events but is buggy and </ins> // doesn't fire when text is deleted, but conveniently, selectionchange // appears to fire in all of the remaining cases so we catch those and // forward the event if the value has changed