Improve iOS IME handling

[lishid]

FIX: Avoids text duplication in some cases caused by weird behaviors of IME composition on iOS.

This might not be the best code to fix this issue, please let me know if there's a better way to achieve this.

This patch fixes a specific case of iOS IME composition - it doesn't seem to happen everywhere but I have one case that triggers this (notice the space in the outer span).

<span class="outer"><span class="inner">-</span> </span>

When the cursor is placed at the end, typing causes exponential character duplication. I've logged the events and it seems that the following happens:

• compositionstart
• MutationObserver event, during which
  • view.composing is false but view.inputState.compositionFirstChange is true.
  • m.oldValue is " " and m.target.nodeValue is " g" (assuming g is typed).
• In this case, if flush is called, then iOS will immediately trigger another mutation and insert the entire composition string again (in this case, "g").
• Each new character typed repeats this process, each time inserting a full copy of the composed string, causing exponential insertion.

This patch causes flushSoon to be used when that happens, which causes iOS to properly keep detecting the correct composed string in the DOM and avoids inserting a new copy.

RPReplay_Final1643727583.mov

[marijnh]

In this case, if flush is called, then iOS will immediately trigger another mutation and insert the entire composition string again (in this case, "g").

This tends to happen on Webkit browsers when the selection or DOM is modified by the script during a composition. So the root cause of the issue is probably in the composition-protection code (CompositionWidget in docview.ts) somehow failing to do what it should do (create a decoration that 'pins' the DOM around the selection, preventing the view from messing with it).

[marijnh]

Does using view.compositionStarted instead of view.composing in this check (and making no other changes) help with this issue for you?

[lishid]

Does using view.compositionStarted instead of view.composing in this check (and making no other changes) help with this issue for you?

I can give it a try. If I remember correctly it would not be sufficient because of this part:

m.oldValue is " " and m.target.nodeValue is " g" (assuming g is typed).

This causes the check to fail: m.oldValue!.length > m.target.nodeValue!.length because it's expecting the new value to be shorter than the previous value.

[lishid]

I have just tested that removing m.oldValue!.length > m.target.nodeValue!.length is indeed required to properly fix the issue from the video.

[lishid]

Updated PR to use view.compositionStarted instead.

[marijnh]

I think I've found the root cause of this issue (though I've only reproduced a very-similar looking issue in Safari since I don't have an iOS device handy) and fixed it in attached patch. Could you take a look and see if it helps for you?

[lishid]

This seems to have fixed the underlying bug which generates extra characters, definitely an improvement.

The patch seems to have introduced a small visual glitch with the cursor though. I'm hoping it's a simple fix 🙏

GCCV3250.MP4