last character (to be more specific, IME composing character) from modal is moved to editor when, selection is programmatically moved from modal to the editor.
Environment
SYSTEM INFO:
Obsidian version: v1.8.10
Installer version: v1.8.10
Operating system: Darwin Kernel Version 24.4.0: Fri Apr 11 18:32:50 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6041 24.4.0
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
Additional information
I am a web-text editor developer and this is well-known bug regarding CJK.
This problem will persist on any other input box unless there is a proper abstraction of uievents for CJK.
In my opinion this is due to wrongful implementation of text passage per w3c spec on Chromium-end
We can do event target check on uievent pipeline (keydown, compositionstart, input, selection …) and prevent further firing of subsequent events if event target changes to block character movement.
While often grouped, Korean composition differs from how CJ (Chinese, Japanese) input methods typically function.
The key differences is that for a lot of Korean IME, composition occurs character by character and it feels a lot like roman alphabet typing (except that it uses composition for each letter). Whereas CJ, there is distinctive composition updating step before a word (not character) is actaully completed.
There is actually another bug due to this(did not check for duplicate):
autocompletion does not work during typing [[wikilink]].
For korean, the event should be hooked on compositionupdate, not compositionend to feel natural. See below:
Here, I am searching for a file named ‘뇌가 변하면 사람도 변한다’, you see that during the typing of each character (still in compositionupdate state), autocompletion does not show up, but it feels like it should.
Occational autocompletion popping up is due when space is typed so it is not in composition state.
For CJ, this is not a problem since actual Chinese or Japanese Character makes sense once composition actually ends. For example, they can be typing roman alphabet to actually complete CJ character using IME. Typing roman alphabet using IME makes input state to be in compositionupdate state, but it would not make sense to show autocompletion popup because it in roman alphabet.
@WhiteNoise Hello,
I’ve been thinking of creating a module to iron out Korean IME issue once and for all(that is, until proper w3c spec rolls out in browsers which is far far away. Also not sure if this is actually possible or not), but since all input related codes are different, I am not sure how I should approach designing interface/API.
Just asking opinion here, how does obsidian commonly handle in-middle-of-typing event?
And what are the few bugs that you mentioned?
Unintentional character added at the beginning of a note.
Environment
SYSTEM INFO:
Obsidian version: v1.4.16
Installer version: v1.4.13
Operating system: Darwin Kernel Version 22.3.0: Thu Jan 5 20:48:54 PST 2023; root:xnu-8792.81.2~2/RELEASE_ARM64_T6000 22.3.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on
