Add new textChange event: input + IE shim #75

sophiebits · 2013-06-09T11:24:01Z

IE8 doesn't support oninput and IE9 supports it badly but we can do almost a perfect shim by listening to a handful of different events (focus, blur, propertychange, selectionchange, keyup, keydown).

This always triggers event handlers during the browser's event loop (not later in a setTimeout) and after the value property has been updated.

The only case I know of where this doesn't fire the event immediately is if (in IE8) you modify the input value using JS and then the user does a key repeat, in which case we fire the event on the second keydown.

Test Plan:
Modify ballmer-peak example to add es5-shim and to use onTextChange instead of onInput. In IE8, IE9, and latest Chrome, make sure that the event is fired upon:

typing normally,
backspacing,
forward-deleting,
cutting,
pasting,
context-menu deleting,
dragging text to reorder characters.

After modifying the example to change .value, make sure that the event is not fired as a result of the changes from JS (even when the input box is focused).

Questions:

Does it make sense to pass on the native event? Since it could be one of seven different types, I'm not sure that application code would be able to do anything useful with it.
The propertychange event doesn't bubble so we can't just attach it to document with the other events but is it preferable to have it go through ReactEventTopLevelCallback like the other events even though we're the only ones who'll be interested? Doing so will get rid of the manual enqueueAbstractEvents/processAbstractEventQueue calls I have but I imagine it'll be slower and won't give any other advantages.
Is the IE9 sniffing code for isInputSupported reasonable? I don't know the preferred way here to handle situations like this.
IE loses the textarea cursor position when updating the textarea contents during the selectionchange event and having ReactInputSelection attempt to restore the contents doesn't seem to help so I've disabled the event on textarea for now. Ideas?

IE8 doesn't support oninput and IE9 supports it badly but we can do almost a perfect shim by listening to a handful of different events (focus, blur, propertychange, selectionchange, keyup, keydown). This always triggers event handlers during the browser's event loop (not later in a setTimeout) and after the value property has been updated. The only case I know of where this doesn't fire the event immediately is if (in IE8) you modify the input value using JS and then the user does a key repeat, in which case we fire the event on the second keydown. Test Plan: Modify ballmer-peak example to add es5-shim and to use onTextChange instead of onInput. In IE8, IE9, and latest Chrome, make sure that the event is fired upon: * typing normally, * backspacing, * forward-deleting, * cutting, * pasting, * context-menu deleting, * dragging text to reorder characters. After modifying the example to change .value, make sure that the event is not fired as a result of the changes from JS (even when the input box is focused).

zpao · 2013-06-10T23:54:27Z

cc @yungsters

petehunt · 2013-06-10T23:58:02Z

src/eventPlugins/TextChangeEventPlugin.js

+
+// IE9 claims to support the input event but fails to trigger it when deleting
+// text, so we ignore its input events
+var isInputSupported = isEventSupported('input') && (


Please use ExecutionEnvironment.canUseDOM such that this module could be required and not fatal if there is no document symbol in scope. I'm not sure if it'll get required in practice or not, but a good idea nonetheless.

Done. (I had canUseDOM originally but lost it somewhere along the way.)

yungsters · 2013-06-12T03:40:25Z

src/eventPlugins/TextChangeEventPlugin.js

+var isInputSupported;
+if (ExecutionEnvironment.canUseDOM) {
+  isInputSupported = isEventSupported('input') && (
+    !("documentMode" in document) || document.documentMode > 9


This check looks good to me.

yungsters · 2013-06-12T03:41:21Z

Does it make sense to pass on the native event? Since it could be one of seven different types, I'm not sure that application code would be able to do anything useful with it.

Yes, keep passing it along. It's up to the end user to do what they will with it, but I have a new set of "synthetic events" that will allow us to normalize the API for both DOM and custom events like the one you're adding.

yungsters · 2013-06-12T03:46:12Z

src/eventPlugins/TextChangeEventPlugin.js

+        nativeEvent
+      );
+      EventPropagators.accumulateTwoPhaseDispatches(abstractEvent);
+      EventPluginHub.enqueueAbstractEvents(abstractEvent);


Add a comment about how propertychange does not bubble so we cannot listen to this using top-level event delegation and have to enqueue and process manually. (By the way, @jordow, can you explain why we need two steps for enqueuing and processing instead of one?)

Add new textChange event: input + IE shim

…orm elements Upgrade `TextChangeEventPlugin` to be the `onChange` event that React fires. In React, `onChange` will now fire when `input` fires for form elements in modern browsers. Handle this for: input[type=text] input[type=password] input[type=checkbox] input[type=radio] textarea select Support: - OSX Chrome - OSX Safari - OSX Firefox - Win 7 / IE8 - Win 7 / IE9 - Win 7 / IE10 Everything works but caret selection / placement differs from browser to browser. For <select> elements, the event is fired with `change`. This is a conscious decision, even though in some browsers (OSX firefox, IE), it can be argued that the event should fire more due to how the UI looks. Builds on facebook/react#75, which handled only text inputs.

Fix double-adding fibers when traversing

… frame type Lays groundwork for #75 by reducing the flamechart data passed around the app. Was also intended to help #50 by moving some division operations from the hot render loops into preprocessFlamechart, but any performance gains are negligible. * `yarn flow`: no errors in modified code * `yarn lint` * `yarn start`: no performance difference

…orm elements Upgrade `TextChangeEventPlugin` to be the `onChange` event that React fires. In React, `onChange` will now fire when `input` fires for form elements in modern browsers. Handle this for: input[type=text] input[type=password] input[type=checkbox] input[type=radio] textarea select Support: - OSX Chrome - OSX Safari - OSX Firefox - Win 7 / IE8 - Win 7 / IE9 - Win 7 / IE10 Everything works but caret selection / placement differs from browser to browser. For <select> elements, the event is fired with `change`. This is a conscious decision, even though in some browsers (OSX firefox, IE), it can be argued that the event should fire more due to how the UI looks. Builds on facebook/react#75, which handled only text inputs.

petehunt reviewed Jun 10, 2013
View reviewed changes

Check canUseDOM before calling isEventSupported

932c45a

yungsters reviewed Jun 12, 2013
View reviewed changes

sophiebits added 2 commits June 11, 2013 21:51

Refactor based on review feedback

6b572b3

Missing semicolon

0dc08c2

yungsters added a commit that referenced this pull request Jun 12, 2013

Merge pull request #75 from spicyj/textchange

dfd76be

Add new textChange event: input + IE shim

yungsters merged commit dfd76be into facebook:master Jun 12, 2013

bvaughn pushed a commit to bvaughn/react that referenced this pull request Aug 13, 2019

Merge pull request facebook#75 from gaearon/fix-double-add

387ad54

Fix double-adding fibers when traversing

Add new textChange event: input + IE shim #75

Add new textChange event: input + IE shim #75

sophiebits commented Jun 9, 2013

zpao commented Jun 10, 2013

petehunt Jun 10, 2013

sophiebits Jun 11, 2013

yungsters Jun 12, 2013

yungsters commented Jun 12, 2013

yungsters Jun 12, 2013

Add new textChange event: input + IE shim #75

Add new textChange event: input + IE shim #75

Conversation

sophiebits commented Jun 9, 2013

zpao commented Jun 10, 2013

petehunt Jun 10, 2013

Choose a reason for hiding this comment

sophiebits Jun 11, 2013

Choose a reason for hiding this comment

yungsters Jun 12, 2013

Choose a reason for hiding this comment

yungsters commented Jun 12, 2013

yungsters Jun 12, 2013

Choose a reason for hiding this comment