Use the native `beforeinput` event if it's supported

[ianstormtaylor]

Do you want to request a feature or report a bug?

Improvement.

What is the current behavior?

Right now, the synthetic onBeforeInput event is being created based on two other events:

• textInput when possible—which is in Webkit.
• keypress as a fallback.

But these days in Chrome, Safari and Opera the spec'd beforeinput event is available and actually fires. And when it does, it includes other spec'd properties which can be extremely helpful:

• inputType tells you whether the event is inserting text, replacing text, inserting a line break, etc.
• getTargetRanges() tells you where the input is taking place in the DOM.

Right now this information isn't exposed, because even if the browser supports beforeinput, it's not being checked for.

What is the expected behavior?

Instead React should treat textInput as a slightly-preferred fallback for native beforeinput support, but add beforeinput as the true goal. So we'd end up with a fallback stack of:

• beforeinput
• textInput
• keypress

Which guarantees that the nativeEvent will always be the most spec'd and have the most relevant information associated with it.

---

The beforeinput event's extra properties are critical in contenteditable situations, when you want to prevent the default browser behavior from firing but perform the logic on an internal model instead. (I'm looking to do this for Slate.)

Without that extra information you have to fallback to hackier behavior—allowing the event to occur, trying to parse the DOM for what the change was, then re-rendering to remove it, etc. I want to avoid this on the more modern browsers, because it results in reduced performance.

---

There is another situation that this fixes, which is that spellcheck right now doesn't trigger React's onBeforeInput handler, even though modern browsers fire the beforeinput event, because it's not being listened for right now.

[ianstormtaylor]

Any word from any maintainers about this? Just curious what the opinion is. Thanks!

[aweary]

@ianstormtaylor do you know if there's any reliable way to detect if beforeinput is natively supported? It looks like logic we currently use for event support detection won't work in this case.

it includes other spec'd properties which can be extremely helpful

How hard do you think it would be to polyfill those spec'd properties for other browsers? We usually don't include event properties if we can't provide them consistently.

[ianstormtaylor]

@aweary why is it that the current logic doesn't work? We use what seems like a similar detection method for it right now. (Although I have to be honest, I'm not sure if it's as reliable as needed by React with it's much broader browser targets.)

As for polyfilling the spec'd properties. I'm not sure, but I think it would be hard. I'd actually advise that instead of trying to polyfill the properties as top-level properties on the synthetic events, that users reach into the nativeEvent to retrieve them.

But I think there might be a larger issue that React's onBeforeInput is not currently the same as the browser spec for beforeinput. It seems like React's is only concerned with explicitly inserting characters of text, whereas the browser spec has things like formatBold and formatItalic, which don't insert text and would be the result of keys like cmd+b.

I'm not super familiar with React's events, but it seems like the existing onBeforeInput should really be named onTextInput, leaving open the option to add a full onBeforeInput in it's place.

[aweary]

@ianstormtaylor I tested isEventSupported and your detection method and both return false in the latest Chrome (63.0.3239.132). It seems like beforeinput events are being triggered though, so I'm not sure why it doesn't work.

https://jsfiddle.net/t4dsqLj9/

As for polyfilling the spec'd properties. I'm not sure, but I think it would be hard. I'd actually advise that instead of trying to polyfill the properties as top-level properties on the synthetic events, that users reach into the nativeEvent to retrieve them.

That seems fine to me until it has better browser support.

But I think there might be a larger issue that React's onBeforeInput is not currently the same as the browser spec for beforeinput. It seems like React's is only concerned with explicitly inserting characters of text, whereas the browser spec has things like formatBold and formatItalic, which don't insert text and would be the result of keys like cmd+b.

If it doesn't implement the spec'd behavior we could potentionally see if we could update the event plugin so it does? I don't think the inconsistencies are intentional.

[ianstormtaylor]

@aweary ah gotcha, it might be because Chrome doesn't implement the spec fully yet? Not sure on that one.

Updating could be good! I don't know enough about the internals to be able to suggest things there I think. The issue is that right now it's text input only, whereas the newer specs result it in being used for events that aren't necessarily character-inserting.

[johan]

@aweary While the hack slate uses to test for beforeinput support now generates a false negative for chrome:

const testEl = window.document.createElement('div');
testEl.contentEditable = true;
'onbeforeinput' in testEl; // => false in chrome 66.0.3359.181, despite support

...might something that tests for the inputType property in an input event instead do the trick?

'inputType' in (new InputEvent('input'));

• it's false in Firefox 59.0.2 (64-bit), which doesn't support it (but has Input Events level 0 support, where less meaty/informative input events fire, but beforeinput events don't exist)
• it's true in chrome 66.0.3359.181, which support Input Events Level 1 and fires beforeinput
• it's true in safari 11.1 (13605.1.33.1.4), which support Input Events Level 2 and fires beforeinput

It might be further splayed out to handle arbitrarily old browsers with something like this, too:

'inputType' in (window.InputEvent ? new InputEvent('input') : {});

[ianstormtaylor]

@johan you're right. That's interesting. I did a little investigating, and it looks like this tests end up as:

const event = window.InputEvent ? new InputEvent('input') : {}
const hasLevel1 = 'inputType' in event

const element = document.createElement('div')
element.contentEditable = true
const hasLevel2 = 'onbeforeinput' in element

Depending on whether you're testing for Input Events Level 1 support (true in Safari, Chrome, Opera). Or for Input Events Level 2 support (true in Safari).

Seems like React doesn't need to distinguish for its purposes, so the Level 1 test is the way to go. (Also because the Level 2 test seems a bit fishy anyways.)

[ShannonLCapper]

We've been taking a look at this issue because we're experiencing a problem with cancelling textInput events in the flavor of Safari that runs in Outlook add-ins on Mac. We'd argue that React should only use the native beforeinput event if it has level 2 support, since there are consumers that currently rely on the synthetic onBeforeInput being cancellable.

I will probably be opening up a PR to React to implement this behavior, but React has such a huge net of supported browsers that I don't know how to go about determining that adding this behavior won't break anything...