IME causes DOM and PM doc to get out of sync on Android Chrome

[ahixon]

Issue details

On Android Chrome, a user can type a short document and interact with the page, but the document's state is not updated, despite the browser visibly updating the contenteditable with the typed text.

This occurs with the default keyboard type on these devices, rather than some small subset.

Steps to reproduce

https://verdant-margin.glitch.me/

Type some short content (without spaces) and then click the button.

On Desktop Chrome, we get a transaction after each key event, so that if we blur the editor, or click the button, inspecting the state of the ProseMirror document matches the contenteditable.

On mobile, this does not occur:

• the user types some text
• the browser updates the contenteditable's DOM with the content of the typed text
• the browser sends a compositionstart event, along with an input event for each composed character

Now, if the user clicks the button, or away from the editor, the following sequence of events occur:

• the contenteditable receives a blur event
• if clicked, the button receives a click event
• finally, the browser sends a compositionend event (with the final composed input data)
• prosemirror-view only then dispatches a new transaction with the updated document content

This means that inspecting the document state from inside the button click event handler is inconsistent with the DOM. Likewise, interacting with any of the formatting buttons causes strange behaviour, since we apply the formatting transaction before the transaction that contains the document content.

Normally we would expect a compositionend event before the blur. Unfortunately, Chrome seems to send the events in a nonsensical^H^Hdifferent order.

ProseMirror version

prosemirror-view 1.0.1 and 1.2.0

Affected platforms

Chrome 65.0.3225.109 on Android 7

Presumably also earlier versions of mobile Chrome, and probably also not dependent on platform

Possible solutions

Since we still receive input events during composition, we could dispatch transactions that match the browser's visible content before receiving the compositionend.

I tried using a Chinese keyboard, for instance, and although you could compose different characters, only after they were committed in the keyboard did they appear in the editor (and an input event fired).

[marijnh]

This is a known issue, and #543 proposes a solution (but is pretty hard to implement, so no one has gotten around to it).