Fix auto completer on IE

[jorgefilipecosta]

Autocompleter did not work on IE mainly because IE does not handle onInput events on editables. We now make use of a newly implemented BackCompatibleOnInput component that falls back to key events when onInput is not supported.

Fixes: #3409

How Has This Been Tested?

Test auto-completer, in IE and other browsers, verify it works well.

[aduth]

Not a fan of the mutation observer. Not only does it invoke its callback excessively, even when input isn't occurring (once for each block at initialization, once or twice when clicking within a block), but it also adds a fair bit of code complexity.

As I see it, this feature is a convenience, not the only mechanism for block insertion or user mentions. The basic functionality is possible either way, so I'd be more inclined to file it under progressive enhancement and ignore the fact that IE bugs prevent it from working correctly, rather than impose a performance cost upon the larger majority of users, and maintenance cost on future developers.

That said, I'd be curious to explore targeting this compatibility to buggy browsers: Use onInput where supported, else onKeyDown or a mutation observer. Could even imagine it abstracted to some generalized component to reuse when we need to capture onInput for a non-input element.

[jorgefilipecosta]

Hi @aduth thank you for the feedback, it was applied. Now, we have a component that abstracts on input browser compatibility and if we detect support of onInput we just use it, if support is not detected we use key events.

[aduth]

Wondering two options for avoiding the wrapping div:

• Apply as a div, but use in place of, not as a child, of the original component's div (i.e. the one with className="components-autocomplete")
• Use cloneElement to apply the normalized event to the original child

[jorgefilipecosta]

Not using a wrapper is challenging as the same component, may want a back-compatible onInput but also have an onKeyUp event (the case of autocomplete).
One option would be to use cloneElement but on the onKeyUp event pass a handler that does the logic of our component but also calls the existing onKeyUp event handler the component had.
I'm not certain if it the best way for this case, or if the additional complexity is valuable when compared to use a div wrapper.

[aduth]

Typo on file name: back-compatile-on-input -> back-compatible-on-input

Aside: Not sure I love the name, mostly because it's an abbreviation of "backwards", though also thinking there might be some alternative like NormalizedOnInput or ContentEditable

[aduth]

For supported browsers, both the onInput and onKeyUp will be triggered on the first keypress. Is there a way we can cancel handling of the onKeyUp if we'd already done onInput ? Maybe an instance variable which is checked here (or state, if it's already reflected).

[jorgefilipecosta]

It was improved, we now handle that case so we don't fire the first key two times.

[jorgefilipecosta]

The issue was fixed using an alternative approach: #6667. Thank you @brandonpayton!