Fix autocompletion in IE11 #6667

brandonpayton · 2018-05-09T20:31:56Z

Description

This is a PR to fix autocompletion in IE11.

Details

The cause for this breakage is that IE11 doesn't dispatch input events for contenteditable, only for <input> and <textarea> elements.

The proposed fix is to update our TinyMCE component to listen for IE11's comparable textinput event and manually creating and dispatching an input on the same target. In addition, because textinput isn't dispatched for deletions, we also dispatch input for Delete and Backspace keyup events.

How has this been tested?

Loaded Gutenberg in IE11, Chrome, Firefox, and Safari and exercised the block and user completers.

I also used the IE11 and Chrome debuggers to verify the fix is applied for just IE and that its event listeners are removed when unmounted.

Screenshots

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.

brandonpayton · 2018-05-09T21:40:46Z

I'm finding that compareDocumentPosition only appears to work for testing direct containment. It's breaking when selection enters a grandchild of the container.

We can still use it if we want, but we'd need to loop and check if parent nodes are contained until we reach the document root or find containment.

jorgefilipecosta · 2018-05-16T19:10:47Z

Hi @brandonpayton thank you for creating this PR. I like this version and I think it is better when compared to what was proposed in #5914 as it avoids the need for a new component.

I'm finding that compareDocumentPosition only appears to work for testing direct containment. It's breaking when selection enters a grandchild of the container.
Would using the check used in #5914 solve the problem:

				if ( ! container.contains( selection.anchorNode ) &&
					selection.anchorNode &&
					! container.textContent.includes( selection.anchorNode.textContent.trim() )
				) {
					throw new Error( 'Invalid assumption: expected selection to be within the autocomplete container' );
				}

brandonpayton · 2018-05-18T03:26:13Z

Hi @jorgefilipecosta, thanks for commenting on this. I'll work to clean this up for merge.

I haven't found a good feature test, so for now, I plan to conditionally add the textinput mapping to input when /Trident/.test( navigator.userAgent ) is true. I don't like it, but it's better than nothing IMO.

Would using the check used in #5914 solve the problem:

I was uncomfortable with the string-based containment check because we could have false positives. It's not really that important because this is just for a development warning, but since we may want to use Node#contains elsewhere, I went ahead an added a containsNode function to @wordpress/dom that should should work cross-browser. It may deserve its own PR, but I'll see if we can just discuss it here.

brandonpayton · 2018-05-18T04:13:06Z

I played around with this a bit more and found a couple of things that could be used for a feature test:

Adding an empty text node to contenteditable in IE11 causes a textinput event to be dispatched.
Deleting a zero-width space using document.execCommand( 'delete', false ) causes an input event to be dispatched in IE11 for <input> and <textarea> elements.

☝️ I'm posting this in case this is interesting to someone, but I don't want to use such complicated testing per TinyMCE instance, which is what we'd need to do since IE11 contenteditable input behavior depends on the element. Something like this is simpler and at least limited to IE11:

const listenForTextInput =
  /Trident/.test( navigator.userAgent ) &&
  ! /input/i.test( tagName ) &&
  ! /textarea/i.test( tagName );

noisysocks · 2018-05-29T05:42:06Z

Is this still WIP?

brandonpayton · 2018-05-30T00:01:20Z

@noisysocks Yeah, I need to make the fix conditional and probably split out the change to @wordpress/dom to its own PR.

brandonpayton · 2018-05-31T05:15:54Z

It turns out that IE11's textinput isn't dispatched for deletions. We can probably use keydown or keyup to listen for backspaces and deletes, but we should be careful to preserve typical event ordering (keydown before input, input before keyup) since we're actually dispatching an input (or input-like) event in response.

I like that this fix produces a real input event, but on the other hand, I like how #5914 simply called the component's onInput method which skips the ordering concern.

I plan to look at this more tomorrow.

IE11 doesn't dispatch `input` events for contenteditable, just for `<input>` and `<textarea>` elements. However, it does dispatch a similar `textinput` event for contenteditable. In this change, we listen for `textinput` events and manually dispatches an `input` event on the same target. In addition, because `textinput` isn't dispatched for deletions, we also dispatch `input` for Delete and Backspace `keyup` events.

brandonpayton · 2018-06-01T23:17:57Z

This is ready for review.

noisysocks

Tested in IE11, Edge and Chrome. It fixes the bug!

I left some minor comments but nothing blocking.

noisysocks · 2018-06-04T04:54:27Z