1978792 - www.perplexity.ai - Korean/Japanese input composition unexpectedly stops

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[Calin Tanase]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile [phone]

Preconditions:

• Korean keyboard installed (한국어)

Steps to reproduce:

1. Go to https://www.perplexity.ai/
2. Dismiss the app pop-up.
3. Type something valid in korean. (e.g. 한국)

Expected Behavior:
Syllabic blocks are formed. (e.g. 한국)

Actual Behavior:
Characters get displayed individually, in most cases. (e.g. ㅎㅏㄴㄱㅜㄱ)

Notes:

• Does not reproduce every time
• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/168054

Comment 1

[Calin Tanase]

Attachment: Nightly vs Chrome.mp4

Comment 2

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Korean keyboard installed (한국어)

Depends on what keyboard is installed. Swiftkey has no problem, while Samsung keyboard has a problem.

1. Type 'ㅎ' or any consonant on the blank input box
2. See the underline persists - Sometimes the underline disappears (meaning the composition stopped and further input will be considered as a separate character), or sometimes not.

Comment 3

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

The same thing happens for Japanese with Samsung keyboard, which prevents selecting candidate words.

Comment 4

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

This doesn't happen on desktop (or at least not on Windows and macOS default keyboards), perhaps something GV specific? 🤔

Comment 5

[Makoto Kato [:m_kato]]

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #4)

This doesn't happen on desktop (or at least not on Windows and macOS default keyboards), perhaps something GV specific? 🤔

Yes, It seems to commit each character, not keeping composing state. But I don’t have Samsung device, so I cannot test this.

Comment 6

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

This is not Samsung specific though. I can also reproduce with Gboard Korean input (but not with Gboard Japanese input). Does that work for you to take a look?

Comment 7

[Makoto Kato [:m_kato]]

Thanks, I can reproduce this with Gboard + Korean input. First character is rarely committed. I will investigate why.

Comment 8

[Makoto Kato [:m_kato]]

Since IME requests to commit string (IME calls InputConnection.finishComposingText()) after IME calls InputConnection.getSurroundingText , this occurs.

GeckoEditable: onTextChange("\u3145\u200b", 2, 3)
GeckoInputConnection: > getSurroundingText(60, 60, 1)
GeckoInputConnection: < getSurroundingText: android.view.inputmethod.SurroundingText@86279a9
GeckoInputConnection: > finishComposingText()

I guess that getSurroundingText result is unexpected for IME. So IME calls finishComposingText. Text (from Gecko's text) has zero-width charactor (U+0x200b) when this occurs. But I am not sure that this issue depends on it.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you Makoto-san for investigating this.

I wonder, if InputConnection.getSurroundingText is called during a composition, we could need to return content which is not changed by the web app like we're doing on Windows. If so, it might be better to implement the feature in ContentCacheInParent level.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I believe that the root cause is same as bug 1905481. ContentCacheInParent should contain the changes which are not yet handled by the remote process.