What happened:
In the document editor, undo behaves incorrectly after typing Korean (Hangul) characters via IME. A single typed Hangul character appears to be registered as two separate undo history entries, so undo seems to "toggle" the character between visible and hidden states before it is actually removed.
Concretely, after typing a single Hangul character:
- 1st Undo: the character disappears
- 2nd Undo: the same character reappears
- 3rd Undo: it disappears again
- 4th Undo: it reappears again
The character is only truly removed from the document after an even number of undos. Odd-numbered undos restore it. Both isolated vowels (e.g. "ㅏ") and fully composed Hangul syllables (e.g. "가") show this pattern.
English input does not exhibit this issue — undo works normally character by character.
This strongly suggests the undo history is pushing both the IME compositionstart (or interim composition state) and compositionend as separate history entries, instead of merging them into a single user-visible insertion.
What you expected to happen:
A single Hangul character typed via IME should be a single undo history entry. One Undo should remove it cleanly, matching the behavior of typing a single English character.
This matches the behavior of Google Docs, Notion, and other collaborative editors that handle IME composition.
How to reproduce it (as minimally and precisely as possible):
- Open a document on https://wafflebase.io/
- Switch the system input source to Korean (Hangul) IME
- Click into a regular paragraph (not a table cell)
- Type a single Hangul character, e.g. "가" (composed of ㄱ + ㅏ) or just "ㅏ"
- Press Cmd + Z once → the character disappears
- Press Cmd + Z again → the character reappears
- Repeat → the character toggles between visible and hidden
For comparison:
- Switch the input source to English
- Type a single English character, e.g. "a"
- Press Cmd + Z once → the character is cleanly removed (no toggling)
Anything else we need to know?:
- This is specific to Korean IME input. English input works correctly, which points to composition-event handling rather than the undo stack itself being broken.
- The most likely cause is the undo history capturing IME composition lifecycle events (
compositionstart / compositionupdate / compositionend) as multiple entries instead of collapsing them into a single insertion. Other CJK IMEs (Japanese, Chinese) likely exhibit the same behavior — worth testing as a control.
- Occurs in plain paragraphs. I haven't isolated whether it also occurs in tables or headings; the behavior is consistent enough in plain paragraphs to file separately.
- Filing this for visibility — I'm not planning to take this on myself right now.
Environment:
- Operating system: macOS Sonoma 14.6.1
- Browser and version: Chrome 148.0.7778.96 (arm64)
- Input method: Korean — macOS 2-Set Korean (system default)
What happened:
In the document editor, undo behaves incorrectly after typing Korean (Hangul) characters via IME. A single typed Hangul character appears to be registered as two separate undo history entries, so undo seems to "toggle" the character between visible and hidden states before it is actually removed.
Concretely, after typing a single Hangul character:
The character is only truly removed from the document after an even number of undos. Odd-numbered undos restore it. Both isolated vowels (e.g. "ㅏ") and fully composed Hangul syllables (e.g. "가") show this pattern.
English input does not exhibit this issue — undo works normally character by character.
This strongly suggests the undo history is pushing both the IME
compositionstart(or interim composition state) andcompositionendas separate history entries, instead of merging them into a single user-visible insertion.What you expected to happen:
A single Hangul character typed via IME should be a single undo history entry. One Undo should remove it cleanly, matching the behavior of typing a single English character.
This matches the behavior of Google Docs, Notion, and other collaborative editors that handle IME composition.
How to reproduce it (as minimally and precisely as possible):
For comparison:
Anything else we need to know?:
compositionstart/compositionupdate/compositionend) as multiple entries instead of collapsing them into a single insertion. Other CJK IMEs (Japanese, Chinese) likely exhibit the same behavior — worth testing as a control.Environment: