[Bug] iOS: cjk ime unable to work continuously in ANYTHING other than plain text

Bug graveyard
, , ,
1

Platform

iOS
Android

Obsidian Mobile version: v1.4.2(90)

When inputing Chinese in the list item, the same problem shows up again.

To reproduce:

  1. create a note
  2. create a list
  3. turn on Chinese input method, and type random letters very fast.

What is expected:

  • corresponding letters or Chinese will show up in the note

What is observed actually:

  • the cursor disappears and the input is interrupted.
1 Like
2

Add a screen record for this(in which I turned off the live preview mode):

Oct-23-2022 01-19-49

3

I quote words from the author of the codemirror who provide the analytics about the cause of the previous bug mentioned in the post 1

Finally figured this out—the backspacing was causing a scroll event, and another iOS hack was delaying DOM reading on backspace-like changes because those sometimes continue trashing around in the DOM for a bit asynchronously, and in combination that led to the editor trying update its DOM at a point where it hadn’t read a change yet, confusing the composition-preserving code and thus interrupting the composition.

When input in a list, or editing a heading, the output result is different from input a line of ordinary text, i.e. some style is applied to the line dynamically. So, is it possible that the reason which cause the fixed bug that affects the input of a line of ordinary text also affects the editing list, heading and other things which is NOT a line of ordinary text? And a similar fix can be applied for them?

4

When editing the heading, i.e. text after # , typing a lot of things fast will also trigger this bug.

And editing in code block will also facing this issue.

I guess for anything which is not ordinary text, i.e. a style is applied the text inputed, the bug will affect the input of these things.

5

This bus is still in Obsidian Mobile 1.4.2(90)

6

Out of curiosity, is this still happening in v1.4.4.?

7

The issue remains:

if the input is in an empty line, i.e does not start with “-” or anything else, it is OK, the issue does not appear immediately. But if the content that you inputed including something like “==”, i.e. an additional style is applied to the content of the line(even in the source editor mode), the bug will appear immediately after those triggers(i.e. “==” in this example).
if the input is in an line with something like “-” or "# ", even in the source editor mode, one can notice after input “-” or "# ", there is a style change one this line, and after that, the bug will appears.

8

More details:

  • Only happens on iPad with external keyboard
  • Inconsistently reproducible, must type pretty fast?
  • Unable to repro on cm6’s try website

So far I couldn’t find a fix…

9

Hi Licat, actually this also happens on iPhone without external keyboard. And you don’t need to type very fast, just type somehow long.
Here are two scenarios (I can’t tell the difference on reproducing steps between them, but you will encounter one of them.)

Scenario 1

  1. Put the cursor inside a bold list (1. **bold|**)
  2. Use Chinese IME keyboard and type something longer than two lines
  3. Keep pressing delete and then it froze.

IMB_gusVfg

Scenario 2

  1. Same as Scenario 1
  2. Same as Scenario 1, but it froze only within the first line.

IMB_0gvkU5

Hope these will help a bit.

10

I mean, I can reproduce it on the iPad but I have no idea how to fix it.

11

The similar issue which is solved before is an upstream issue:

Could this be also an upstream issue?

FYI:
Observation 1: after the fix of the aforesaid upstream issue, the input of plain text, i.e. a new line of text beginning with no special decoration(“- “, etc) and containing no style decoration(”==”, “**”, “_”, etc), becomes normal in Obsidian. But any text with any style related controls/decorations mentioned above remains confronting a similar issue.

Proposal 1: I suspect that for these cases, a similar upstream issue is still there.

Observation 2: However, as this issue only appears within Obsidian now and this issue is not able to be reproduced on the CM6 website, I don’t know what kind of information can be provide to the author of CM6 to identify or even to prove that it is an issue of CM6.

Proposal 2: Could you help providing some information which may help to identify or locate the owner of this issue？

12

just to correct this:
the issue can be reproduced with internal keyboard too

13

I think this problem is very common among users who type with cjk on iPad. I have this problem too for a long time. It will be great if you can solve this problem

14

@GLight Are you still running into this bug? I can’t seem to reproduce this anymore - testing on iOS 17.3.

15

Hi, Licat,

thank you for telling me about this.

I’d like to have a test on the weekend, :smiley:

16

Hi, Licat,

I think this issue is solved.

Very happy about this!

Also, I noticed that by turning-on the dynamic-highlight of @NothingIsLost , the issue comes back.

1 Like
17

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.