1905481 - Cannot enter some Thai alphabet in the input text on a webpage on Linux

Status: ASSIGNED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Wises Keshom]

Attachment: mozilla-bug-report.pdf

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

OS: Fedora 40
DE: GNOME 46
Firefox version: 127.0.2
Notes: This issue occurs in both rpm and flatpak versions.

Steps:

1. Open a webpage that contains an input box or text editor that we can input the text. (In my case, I am changing the README.md file in a Github repo.
2. Switch input language to Thai.
3. Type-in the following input key (refer to the position of QWERTY English keyboard layout but keep typing in Thai input method
   z
   y
   d

Actual results:

it produces below result

ผก

There are only 2 characters there.

Expected results:

expected result is

ผัก

There are 3 chars as we typed-in. the 2nd char in on the top of the 1st char.

Attached please find a captured screenshots for your reference.

Comment 1

[Wises Keshom]

additional information.

I don't encounter this issue on Windows (10) and Android (14) versions.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Hi Masayuki,
can you please add this into your queue and investigate what's up? Thank you.

Comment 5

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

I cannot reproduce this bug on Ubuntu. I'll try to install Fedora.

Comment 6

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

I installed Fedora 40, and I tried to reproduce this bug with Firefox which is pre-installed. However, I couldn't reproduce this bug. I see the expected result in <input>.

Wises Keshom: Did you customize your keyboard settings or IME settings? What would you see if you start Firefox with MOZ_LOG=IMEHandler:4,sync? In my environment, I get:

[Parent 5276: Main Thread]: I/IMEHandler 0x7f6ce53211c0 Init(), mOwnerWindow=7f6cd924ce00, mContext=7f6cd92d5720 (im="wayland"), mIsIMInAsyncKeyHandlingMode=false, mIsKeySnooped=true, mSimpleContext=0, mDummyContext=7f6cd92d5800, gtk_im_multicontext_get_context_id()="wayland", PR_GetEnv("XMODIFIERS")="@im=ibus"

in the terminal. I installed the default language as Japanese. So the IME related settings may be different from yours.

Comment 7

[Wises Keshom]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #6)

I installed Ubuntu 40, and I tried to reproduce this bug with Firefox which is pre-installed. However, I couldn't reproduce this bug. I see the expected result in <input>.

Wises Keshom: Did you customize your keyboard settings or IME settings? What would you see if you start Firefox with MOZ_LOG=IMEHandler:4,sync? In my environment, I get:

[Parent 5276: Main Thread]: I/IMEHandler 0x7f6ce53211c0 Init(), mOwnerWindow=7f6cd924ce00, mContext=7f6cd92d5720 (im="wayland"), mIsIMInAsyncKeyHandlingMode=false, mIsKeySnooped=true, mSimpleContext=0, mDummyContext=7f6cd92d5800, gtk_im_multicontext_get_context_id()="wayland", PR_GetEnv("XMODIFIERS")="@im=ibus"

in the terminal. I installed the default language as Japanese. So the IME related settings may be different from yours.

I start Firefox from the terminal with flag --MOZ_LOG=IMEHandler:4,sync then I got

[Parent 5875: Main Thread]: I/IMEHandler 0x7f2aa5314970 Init(), mOwnerWindow=7f2a99446100, mContext=7f2a8bf8b410 (im="wayland"), mIsIMInAsyncKeyHandlingMode=false, mIsKeySnooped=true, mSimpleContext=0, mDummyContext=7f2a8bf8b560, gtk_im_multicontext_get_context_id()="wayland", PR_GetEnv("XMODIFIERS")="@im=ibus"

I believe that I haven't changed anything related to IME setting.

I did 1 change with my Keyboard setting via Tweaks which is I changed the Cap Lock behavior to Swap Esc and Caps Lock (I am a Vim user).
I am not sure if this is the case or not. However, I tired to change this option back to default behavior but I still have the same issue.

Thanks to Masayuki Nakano and everyone here for the helps, If you need more info please let me know.

Comment 8

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

(In reply to Wises Keshom from comment #7)

I start Firefox from the terminal with flag --MOZ_LOG=IMEHandler:4,sync then I got

[Parent 5875: Main Thread]: I/IMEHandler 0x7f2aa5314970 Init(), mOwnerWindow=7f2a99446100, mContext=7f2a8bf8b410 (im="wayland"), mIsIMInAsyncKeyHandlingMode=false, mIsKeySnooped=true, mSimpleContext=0, mDummyContext=7f2a8bf8b560, gtk_im_multicontext_get_context_id()="wayland", PR_GetEnv("XMODIFIERS")="@im=ibus"

I believe that I haven't changed anything related to IME setting.

Thank you! Oddly, your environment seems exactly same as my fresh environment about IME. So, I don't understand why there is the difference...

I did 1 change with my Keyboard setting via Tweaks which is I changed the Cap Lock behavior to Swap Esc and Caps Lock (I am a Vim user).
I am not sure if this is the case or not. However, I tired to change this option back to default behavior but I still have the same issue.

Yeah, I agree. It shouldn't cause this.

Thanks to Masayuki Nakano and everyone here for the helps, If you need more info please let me know.

Well, could you attach the log when you start Firefox from terminal with MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=/path/to/log/file firefox? (You'll get a log file whose file size is not zero around the path specified with MOZ_LOG_FILE.) When the Firefox launch, copy data:text/html,<input> and use "Paste and go" in the URL bar. Then, type "zyd" in the <input>. Then, quit from Firefox with mouse. (I.e., without the 3 key presses, not key should be used while you run the Firefox with enabling the logging.)

Comment 9

[Wises Keshom]

Attachment: firefox-en.moz_log

Comment 10

[Wises Keshom]

Attachment: firefox-th.moz_log

Comment 11

[Wises Keshom]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #8)

(In reply to Wises Keshom from comment #7)

Well, could you attach the log when you start Firefox from terminal with MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=/path/to/log/file firefox? (You'll get a log file whose file size is not zero around the path specified with MOZ_LOG_FILE.) When the Firefox launch, copy data:text/html,<input> and use "Paste and go" in the URL bar. Then, type "zyd" in the <input>. Then, quit from Firefox with mouse. (I.e., without the 3 key presses, not key should be used while you run the Firefox with enabling the logging.)

Attached please find the log files. There are 2 files were uploaded, I recorded it twice both in En and Th (I switched the language with mouse).

Comment 12

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

Thank you very much.

First, the log looks really odd. No GDK_KEY_PRESS events are notified us. Probably, the IME consumes the event before us. Instead, we receive:

1. Insertion of "ผ" from IME
2. Release event of KeyZ
3. Release event of KeyY
4. Insertion of "ก" from IME
5. Release event of KeyD

So, #3, KeyY must be not handled as expected. After handling #1, we receive a request of surrounding text of the insertion point. Then, we fail to handle it.

I/IMEHandler 0x7efcc3d19410 GetCurrentParagraph(), mCompositionState=NotComposing
D/IMEHandler 0x7efcc3d19410   GetCurrentParagraph(), selOffset=1, selLength=0
E/IMEHandler 0x7efcc3d19410   GetCurrentParagraph(), FAILED, The selection is invalid, queryTextContentEvent={ mReply={ mOffsetAndData={ mOffset=0, mData="" (Length()=0), Length()=0, EndOffset()=0 }, , mContentsRoot=0x0, mIsEditableContent=false, mFocusedWidget=0x0x7efcb7d33d00, mFontRanges={ Length()=0 } } }

It's here. It seems that the parent process has not get the latest content from the focused content process.

I guess cannot you type the characters as expected in URL bar, search bar and/or the find bar of Firefox?

Comment 13

[Wises Keshom]

Attachment: Screenshot from 2024-08-02 18-00-34-typing-in-the-address-bar.png

This screen captured pictur is shown that I am able to type in the search/address bar as I expected.

Comment 14

[Wises Keshom]

Attachment: firefox-with-lang-switch.moz_log

This is a log file of how I can enter the Thai character in Y position (the 2nd one) by typing 5 times key press including 2 extra language switch (with my Left Alt + Shift key binding) as I mentioned in the 1st comment.

Comment 15

[Wises Keshom]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #12)

It's here. It seems that the parent process has not get the latest content from the focused content process.

I guess cannot you type the characters as expected in URL bar, search bar and/or the find bar of Firefox?

Strangely enough, I have no issue when typing in the URL bar, search bar and/or the find bar. This made me very confused too.
I have attached file Screenshot from 2024-08-02 18-00-34-typing-in-the-address-bar.png to show the result I got there. It worked as expected.

If you want me to send you a log during I am typing in the URL bar, please suggest me the commands/methods how to get it.

I also uploaded a log file (firefox-with-lang-switch.moz_log) that I am able to enter the word that I wanted by entered 5 key press for your reference. There were 2 extra Alt+Left shift. The key press I typed were "zAlt_LAlt_Lyd"

from the latest uploaded log file, when I searched for a word "commitString" with command

grep "commitString" firefox-with-lang-switch.moz_log

The result was

[Parent 5807: Main Thread]: I/IMEHandler 0x7fea365162f0 OnCommitCompositionNative(aContext=0x7fea26e9d1e0), current context=0x7fea26e9d1e0, active context=0x7fea26e9d1e0, commitString="ผ", mProcessingKeyEvent=0x0, IsComposingOn(aContext)=false
[Parent 5807: Main Thread]: I/IMEHandler 0x7fea365162f0 OnCommitCompositionNative(aContext=0x7fea26e9d1e0), current context=0x7fea26e9d1e0, active context=0x7fea26e9d1e0, commitString="ั", mProcessingKeyEvent=0x0, IsComposingOn(aContext)=false
[Parent 5807: Main Thread]: I/IMEHandler 0x7fea365162f0 OnCommitCompositionNative(aContext=0x7fea26e9d1e0), current context=0x7fea26e9d1e0, active context=0x7fea26e9d1e0, commitString="ก", mProcessingKeyEvent=0x0, IsComposingOn(aContext)=false

The 2nd row is a string that cannot be found in the log when I just type "zyd".

I also have 2 more info to let you know.

1. my current OS is not a clean install, it was upgraded from Fedora 39. but, I don't heavily make changes my machine at all, I just installed a few software and all of them are from the official Fedora's rpm repository and the Flathub.
2. I just realized I am now using English United state rather than English UK which was the default keyboard layout from the OS. I added the US layout and removed the UK one. If this possible to be the root clause?

Thanks for you help again.
Wises

Comment 16

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

(In reply to Wises Keshom from comment #15)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #12)

It's here. It seems that the parent process has not get the latest content from the focused content process.

I guess cannot you type the characters as expected in URL bar, search bar and/or the find bar of Firefox?

Strangely enough, I have no issue when typing in the URL bar, search bar and/or the find bar. This made me very confused too.

Thank you. The behavior makes sense to me. I think that you're a victim of a bug of ContentCacheInParent which caches focused remote process's editable content in the parent process and URL bar etc in Firefox UI works in the parent process without ContentCacheInParent. So, it's an evidence of my guess.

Comment 17

[mozartilize]

I'm hitting the same bug with my Vietnamese IME (daklak-rs) on Firefox contenteditable fields (Facebook/Telegram). The symptom: typing tư then applying a tone mark drops the leading consonant — you get ự instead of tự.

I did wireplumber protocol traces and the failure cascade is clear:

Batch 1 — delete+commit silently dropped:

→ compositor: delete_surrounding_text(1, 0)     ← delete 'u'
→ compositor: done(5)
→ Firefox:    set_surrounding_text("tu", 2, 2)   ← text unchanged! delete silently dropped
→ compositor: commit_string("ư")
→ compositor: done(5)
→ Firefox:    set_surrounding_text("tu", 2, 2)   ← 130ms later: still "tu", commit also dropped

Both events arrived at Firefox (confirmed in the trace) but were ignored by contenteditable. The IME's shadow buffer updated to tư while Firefox still has tu.

Batch 2 — cascade failure:

→ compositor: delete_surrounding_text(2, 0)     ← IME thinks it's deleting 'ư' (2 bytes)
→ Firefox:    set_surrounding_text("tu", 2, 2)   ← still "tu"
→ compositor: commit_string("ự")

The delete_surrounding_text(2, 0) operates on tu (2 bytes = 2 chars), deleting both characters. Then commit_string("ự") produces just the bare diacritic. Result: tu → ự. The t is gone.

The bug is flaky. Sometimes delete+commit works, sometimes it doesn't. The address bar always works.

Comment 18

[Andreas Farre [:farre]]

Masayuki, do you think that this deserves the S2 or can we downgrade it?

Comment 19

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

Is this fixed by bug 2053737 or is this different?

Comment 20

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

(In reply to Andreas Farre [:farre] from comment #18)

Masayuki, do you think that this deserves the S2 or can we downgrade it?

I still believe that this is an important bug for some keyboard layout users on Linux. Currently, I plan to fix this bug in H2.

(In reply to Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them) from comment #19)

Is this fixed by bug 2053737 or is this different?

No. It must be different issue. This is caused by that ContentCacheInParent does not modify the cache for inputs.