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?
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.
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.)
Put the cursor inside a bold list (1. **bold|**)
Use Chinese IME keyboard and type something longer than two lines
Keep pressing delete and then it froze.
Same as Scenario 1
Same as Scenario 1, but it froze only within the first line.
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？