Describe the bug
In the iOS mobile app, typing an emoji followed immediately by text causes the emoji to transform into a question mark (?). However, if the entire message (including the emoji) is copied and pasted into the input field, the emoji renders and sends correctly.
To Reproduce
Open a conversation in the Chatwoot iOS app (v4.4.0).
Type any emoji (e.g., 😊) into the message composer.
Immediately start typing a word (e.g., "Hello"), or type other emoji
Observe that the emoji changes to a ?.
Expected behavior
The emoji should remain rendered correctly as a Unicode character regardless of whether it was typed or pasted.
Screenshots
Observed behavior
The emoji is replaced by a question mark placeholder during the active typing state. It appears the input listener is failing to handle the Unicode character correctly when subsequent keystrokes are detected.
Environment
- self hosted installation of Chatwoot.
- Device Name: iPhone17
- OS Version: ios 26.3.1
- Chatwoot App Version: 4.4.0
- Chatwoot Server Version: 4.12.1
Additional context
The issue seems isolated to the live input event. Pasting the text bypasses the character-by-character processing that occurs during typing, which is why the paste method works as a workaround.
Possible fixes
Describe the bug
In the iOS mobile app, typing an emoji followed immediately by text causes the emoji to transform into a question mark (?). However, if the entire message (including the emoji) is copied and pasted into the input field, the emoji renders and sends correctly.
To Reproduce
Open a conversation in the Chatwoot iOS app (v4.4.0).
Type any emoji (e.g., 😊) into the message composer.
Immediately start typing a word (e.g., "Hello"), or type other emoji
Observe that the emoji changes to a ?.
Expected behavior
The emoji should remain rendered correctly as a Unicode character regardless of whether it was typed or pasted.
Screenshots
Observed behavior
The emoji is replaced by a question mark placeholder during the active typing state. It appears the input listener is failing to handle the Unicode character correctly when subsequent keystrokes are detected.
Environment
Additional context
The issue seems isolated to the live input event. Pasting the text bypasses the character-by-character processing that occurs during typing, which is why the paste method works as a workaround.
Possible fixes