Can't input Japanese on iOS

[craftzdog]

I'm excited to try CodeMirror 6!
I found that it can't input Japanese on iOS (14.3) if a line is empty.
I've attached a video here:

RPReplay_Final1611395076.MP4

You can reproduce it on the website of CodeMirror 6.

[DGCK81LNN]

Chinese too, the empty line stays empty on composition end. iOS 14.3.

[craftzdog]

@marijnh I would love to contribute but where should I look into it?

[marijnh]

At a glance, I think this is related to the way selection and composition interact on iOS. It appears that the composed text is being selected (which doesn't happen on most platforms), and that the Enter press is somehow deleting that selection. A good direction to start would be to test (possibly on a plain contentEditable element to avoid confusion) what the DOM selection is supposed to be when inputting text via the Kanji keyboard, and what kind of events are fired when you press enter there (most platforms don't fire keydown events during composition, but Safari has some odd behavior there).

[DGCK81LNN]

I found that when inputting Chinese, iOS Safari doesn't fire keydown and keyup on composition end, while Chromium does. Does that cause things to break?

Start composing:
keydown - compositionstart - compositionupdate - keyup

Continue composing:
keydown - compositionupdate - keyup

Confirm composition:
(Chromium) keydown - compositionupdate - compositionend - keyup
(iOS Safari) compositionupdate - compositionend

There's also different behavior when the whole composition is deleted

Delete last existing character of composition:
(Chromium) keydown - compositionupdate - compositionend - keyup
(iOS Safari) keydown - compositionend - keyup

[DGCK81LNN]

After more experiments I've concluded that on iOS Safari the composed text is not selected; that is selected only during compositionupdate, which is consistent with Chromium.

[marijnh]

It could be that patch codemirror/view@75ae928 has made this better—at least, it doesn't seem to behave like in the screencast anymore. Could someone who is experienced with this type of virtual keyboard take another look with @codemirror/view 0.17.11 and see how it does now?

[craftzdog]

Thank you for taking the time to fix it! I've tried it but it is still not working:

RPReplay_Final1614341282.MP4

I confirmed that I'm on main branch of codemirror/view.

[marijnh]

I can confirm that on finishing a composition its text is removed. Not a lot of progress in figuring out why, though—it appears to just vanish from the DOM, before the editor does anything. Will spend more time on this later.

[marijnh]

I think I got it (see codemirror/view@9ed075a). The browser would delete the composed text when confirming the composition, deliver the DOM mutation events for that deletion, and then reinsert it (for some reason). CodeMirror would, when seeing the deletion, move the cursor, which apparently prevented the reinsertion from happening. Slightly delaying the handling of mutation events during composition seems to avoid the problem.

[craftzdog]

Thank you, @marijnh, it works!
But, I found another issue related to this.
It's a bit complicated.
While you can input Japanese with Chinese characters, the cursor position moves back to the head of the line when inputted another character without confirming the composition.
Please take a look at the video:

RPReplay_Final1614949868.MP4

I guess that's due to those deletion & reinsertion behaviors.
So, preserving the cursor position would be needed somehow.

[ttakuru88]

I found similar case

case.mov

1. input "123456"
2. compositionend "123"
3. compositionend "456"
4. result "456123"
   • expected "123456"

---

iOS 14.4 safari
commit c723309

[marijnh]

Thanks for the number-based reproduction instructions—those were a lot easier for me to follow. Attached patch (released as @codemirror/view 0.18.2) seems to solve that case. Please take a look and let me know whether you are still seeing things like this. (If so, please explain them as you would to someone who doesn't know anything about your writing system, because I have a lot of trouble even figuring out what's going on with most of these instructions.)

[ttakuru88]

Thanks!
I tried it. But it's not fixed.

sample.mp4

• input 123456.
• tap between 3 and 4.
• tap 123 on IME candidate list.
  • result: 123 and selected 456 and 456
  • expected: 123 and selected 456
• tap 456 on IME candidate list.
  • result: 123 and selected 456 by safari and selected 456 by CodeMirror
  • expected: 123456

[DGCK81LNN]

The new problem doesn't happen for Chinese so I'm outta here.

[marijnh]

That's the same reproduction sequence as before, right? With the current code, on this iPhone (iOS 14.4.1), I'm now seeing this behave as expected (the 456 isn't duplicated).

[SH-Wi]

There is similar issue when typing Korean on iOS Safari.
It only happens at first typing after focusing block.

20210425_004201672.mp4

[marijnh]

I can see this problem on the version on the website, but can't reproduce this with the current code anymore. I've updated the website. Could you take a look to see if it's better now?

[craftzdog]

It's better! But #379 (comment) still persists.
Thank you for the hard work🙏

[marijnh]

@craftzdog I'm going to need more detailed instructions to reproduce that. When I press the top-left character multiple times, it changes the character before the cursor, rather than inserting multiple copies, so I can't even start the sequence shown in that video. (In general, I much prefer written reproduction steps to videos, especially fast-moving ones like that one.)

[craftzdog]

@marijnh Sure.

1. Press 'あ' x 2, procucing 'ああ'
2. Press '次候補', meaning the next conversion. '嗚呼' should be highlighted. But do not press '確定' (submit).
3. Press 'か'

Expected result

嗚呼か

Actual result

か

'嗚呼' disappears.

Can you reproduce that?

[marijnh]

If I press あ I get a different character replacing the first あ, not two あs. That is with the Japanese Kana keyboard, which looks like the one you showed in the screencast.

[ttakuru88]

Change to 'い' if press 'あ' twice quickly.
Try this procedure.

- 1. Press 'あ' x 2, procucing 'ああ'
+ 1. Press 'あ', Wait 2 seconds or press '→', Press 'あ', procucing 'ああ'
2. Press '次候補', meaning the next conversion. '嗚呼' should be highlighted. But do not press '確定' (submit).
3. Press 'か'

'→' key is localed this

[craftzdog]

Sorry, I didn't mention that I'm using the Flick Only option of the Kana keyboard.
You can enable it from General -> Keyboards -> KANA -> Flick Only.

[marijnh]

Finally got around to looking into this. With that option I could reproduce the problem. Apparently, the browser would when you typed the third character, end the composition, move the selection to cover those two characters, and then start a new composition that inserted the third character. CodeMirror would conclude, when the first composition ended, that it needed to sync the selection, and that ended up breaking the effect of the second composition.

Attached patch seems to help.

[craftzdog]

Thanks for the fix! I found that it's solved for the previous case with '嗚呼か'.
But it happens with other compositions like '赤い花'.

1. Press 'あ' -> 'か' -> 'い' (Flick left あ)
2. Press '次候補' to select '赤い' (Do not press '確定' to submit)
3. Press 'は' -> 'な', then, select '花'

Expected result

赤い花

Actual result

When pressing 'は' in step 3, the cursor moves back to the head of the line and '赤い' does not get inserted.

は|あかい

| is the cursor position.
I don't know why Safari behaves differently based on a sentence like so..

[iiz00]

Besides @craftzdog's '赤い花' problem (it's very weird..), the problem @ttakuru88 mentioned above remains in my environment (iOS 14.6).

• input abcdef (trying to convert abc/def to ABC/DEF).
• move the cursor between abc and def .
• tap ABC on candidate list.
  • expected result: ABC and selected def
  • actual result: disappeared ABC and selected def and abcdef
• tap DEF on candidate list.
  • def is converted to DEF, with a space before DEF.
  • expected final result: ABCDEF
  • actual final result: DEFabcdef

RPReplay_Final1623118294_d.mov

[marijnh]

@craftzdog @iiz00 I don't know which virtual keyboards you are using there. If the problem still shows up with recent @codemirror/view versions, please file new, separate github issues with a detailed textual description of how you get them to occur and, if not obvious, what you'd expect to happen. (Again, I only speak Latin-script languages and my most advanced routine use of IME is adding basic accents with the X multi key.)

Closing this since it has become an unfocused grab-bag of different issues.