1772749 - [GTK][Fcitx] When I input korean characters followed by a space, the location of the character and the space is transposed

Status: UNCONFIRMED

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

Description

[gnuykeat.mik]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36

Steps to reproduce:

I am using opensuse tumbleweed with fcitx IM with hangul (Korean alphabet) module. In every other app except firefox, I can input korean characters with this setting without any issue.

In firefox, if I type a korean character and a space, the locations of the character and the space are transposed; for example, if I try to input '가 ', I type '가' first and a space ' ', but the actual result is ' 가'.

Actual results:

' 가' as I described.

Expected results:

'가 ' of course.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Daniel Holbert [:dholbert]]

masayuki, I know you work on IME-releated stuff -- maybe you could take a look here?

Comment 3

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

I don't have much time to work on this, but sounds like a bug of IMContextWrapper. I think I can work on this after requesting review for current my work.

gnuykeat.mik:

Could you attach a log file in your environment?

1. Run Firefox from the terminal with this command MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=~/fx-im ./firefox in where you installed Firefox
2. Paste and go to data:text/html,<textarea></textarea> with using mouse or something pointing device
3. Then, reproduce this bug
4. Quit Firefox with mouse

Note that the log will contain a lot of information for every key press. Therefore, please do only the minimal things with keyboard. And DO NOT type anything your privacy, e.g., passwords.

And I have a question, is it a recent regression? If so, could you look for which change caused this bug with mozregression?

Comment 4

[gnuykeat.mik]

Attachment: fx-im.moz_log

I followed the instructions from masayuki and upload the log file. The correct string would be

"나의 살던 고향은 꽃피는 산골, 복숭아꽃 살구꽃, 아기진달래."

but it produces:

"나 의살 던고향 은꽃피 는산,골 복숭아 꽃살구,꽃 아기진달.래"

Thanks.

Comment 5

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

Thank you for attaching the log.

I/IMEHandler 0x7f07dc4455e0 OnChangeCompositionNative(aContext=0x7f07c78fa170), mComposingContext=0x7f07c78fa170
I/IMEHandler 0x7f07dc4455e0 GetCompositionString(aContext=0x7f07c78fa170), aCompositionString="의"
I/IMEHandler 0x7f07dc4455e0 DispatchCompositionChangeEvent(aContext=0x7f07c78fa170)
I/IMEHandler 0x7f07dc4455e0 CreateTextRangeArray(aContext=0x7f07c78fa170, aCompositionString="의" (Length()=1))
D/IMEHandler 0x7f07dc4455e0   SetTextRange(), succeeded, aTextRange= { mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause, mRangeStyle={ mLineStyle=LineStyle::Solid, IsUnderlineColorDefined=false, mForegroundColor={ R=0xFC, G=0xFC, B=0xFC, A=0xFF }, mBackgroundColor={ R=0x3D, G=0xAE, B=0xE9, A=0xFF } } }
W/IMEHandler 0x7f07dc4455e0   SetTextRange(), FAILED, due to current clause length is 0
D/IMEHandler 0x7f07dc4455e0   CreateTextRangeArray(), mStartOffset=1, mEndOffset=1, mRangeType=TextRangeType::eCaret
I/IMEHandler 0x7f07dc4455e0 OnRetrieveSurroundingNative(aContext=0x7f07c78fa170), current context=0x7f07c78fa170
I/IMEHandler 0x7f07dc4455e0 GetCurrentParagraph(), mCompositionState=CompositionChangeEventDispatched
D/IMEHandler 0x7f07dc4455e0   GetCurrentParagraph(), selOffset=1, selLength=0
D/IMEHandler 0x7f07dc4455e0   GetCurrentParagraph(), succeeded, aText=낭, aText.Length()=1, aCursorPos=1
I/IMEHandler 0x7f07dc4455e0 OnSelectionChange(aCaller=0x7f07bfea3c00, aIMENotification={ mSelectionChangeData={ mOffset=2, mString="" (Length()=0), GetWritingMode()=h-ltr, mReversed=false, mCausedByComposition=true, mCausedBySelectionEvent=false, mOccurredDuringComposition=true } }), mCompositionState=CompositionChangeEventDispatched, mIsDeletingSurrounding=false, mRetrieveSurroundingSignalReceived=true, isSelectionRangeChanged=true
I/IMEHandler 0x7f07dc4455e0 SetCursorPosition(aContext=0x7f07c78fa170), mCompositionTargetRange={ mOffset=1, mLength=4294967295 }, mContentSelection={ HasRange()=false }
I/IMEHandler 0x7f07dc4455e0 SetCursorPosition(aContext=0x7f07c78fa170), mCompositionTargetRange={ mOffset=1, mLength=4294967295 }, mContentSelection={ HasRange()=false }
I/IMEHandler >>>>>>>>>>>>>>>>

When you type the second Hangul character, it exists as a composing character. (Oh, bu the first character is different from 나, why...?)

I/IMEHandler 0x7f07dc4455e0 OnKeyEvent(aCaller=0x7f07bfea3c00, aEvent(0x7f078a99c020): { type=GDK_KEY_RELEASE, keyval=m, unicode=0x6D, state=, time=5542080, hardware_keycode=58, group=0 }, aKeyboardEventWasDispatched=false)
I/IMEHandler 0x7f07dc4455e0   OnKeyEvent(), mMaybeInDeadKeySequence=false, mCompositionState=CompositionChangeEventDispatched, current context=7f07c78fa170, active context=7f07c78fa170, mIMContextID=Fcitx, mIsIMInAsyncKeyHandlingMode=true
<snip>
D/IMEHandler 0x7f07dc4455e0   OnKeyEvent(), succeeded, filterThisEvent=false (isFiltered=false, mFallbackToKeyEvent=false, probablyHandledAsynchronously=true, maybeHandledAsynchronously=false), mPostingKeyEvents.Length()=0, mCompositionState=CompositionChangeEventDispatched, mMaybeInDeadKeySequence=false, mKeyboardEventWasDispatched=false, mKeyboardEventWasConsumed=false
I/IMEHandler <<<<<<<<<<<<<<<<

I/IMEHandler >>>>>>>>>>>>>>>>
I/IMEHandler 0x7f07dc4455e0 OnKeyEvent(aCaller=0x7f07bfea3c00, aEvent(0x7f078a99c020): { type=GDK_KEY_RELEASE, keyval=l, unicode=0x6C, state=, time=5542144, hardware_keycode=46, group=0 }, aKeyboardEventWasDispatched=false)
I/IMEHandler 0x7f07dc4455e0   OnKeyEvent(), mMaybeInDeadKeySequence=false, mCompositionState=CompositionChangeEventDispatched, current context=7f07c78fa170, active context=7f07c78fa170, mIMContextID=Fcitx, mIsIMInAsyncKeyHandlingMode=true

Then, you release m and l keys, and Fcitx5 or the conversion engine queries current paragraph, however, the second character has not been handled in the remote process yet.

I/IMEHandler 0x7f07dc4455e0 OnRetrieveSurroundingNative(aContext=0x7f07c78fa170), current context=0x7f07c78fa170
I/IMEHandler 0x7f07dc4455e0 GetCurrentParagraph(), mCompositionState=CompositionChangeEventDispatched
D/IMEHandler 0x7f07dc4455e0   GetCurrentParagraph(), selOffset=1, selLength=0
D/IMEHandler 0x7f07dc4455e0   GetCurrentParagraph(), succeeded, aText=나, aText.Length()=1, aCursorPos=1
D/IMEHandler 0x7f07dc4455e0   OnKeyEvent(), succeeded, filterThisEvent=false (isFiltered=false, mFallbackToKeyEvent=false, probablyHandledAsynchronously=true, maybeHandledAsynchronously=false), mPostingKeyEvents.Length()=0, mCompositionState=CompositionChangeEventDispatched, mMaybeInDeadKeySequence=false, mKeyboardEventWasDispatched=false, mKeyboardEventWasConsumed=false
I/IMEHandler <<<<<<<<<<<<<<<<

I/IMEHandler 0x7f07dc4455e0 SetCursorPosition(aContext=0x7f07c78fa170), mCompositionTargetRange={ mOffset=1, mLength=4294967295 }, mContentSelection={ HasRange()=false }

Then, selection is modified by Fcitx5 or the conversion engine us to end of handled text by the remote process.

I/IMEHandler >>>>>>>>>>>>>>>>
I/IMEHandler 0x7f07dc4455e0 OnKeyEvent(aCaller=0x7f07bfea3c00, aEvent(0x7f078a99cd40): { type=GDK_KEY_PRESS, keyval=space, unicode=0x20, state=, time=5542432, hardware_keycode=65, group=0 }, aKeyboardEventWasDispatched=false)
I/IMEHandler 0x7f07dc4455e0   OnKeyEvent(), mMaybeInDeadKeySequence=false, mCompositionState=CompositionChangeEventDispatched, current context=7f07c78fa170, active context=7f07c78fa170, mIMContextID=Fcitx, mIsIMInAsyncKeyHandlingMode=true
I/IMEHandler 0x7f07dc4455e0 OnRetrieveSurroundingNative(aContext=0x7f07c78fa170), current context=0x7f07c78fa170
I/IMEHandler 0x7f07dc4455e0 GetCurrentParagraph(), mCompositionState=CompositionChangeEventDispatched
D/IMEHandler 0x7f07dc4455e0   GetCurrentParagraph(), selOffset=1, selLength=0
D/IMEHandler 0x7f07dc4455e0   GetCurrentParagraph(), succeeded, aText=나, aText.Length()=1, aCursorPos=1
I/IMEHandler 0x7f07dc4455e0 OnCommitCompositionNative(aContext=0x7f07c78fa170), current context=0x7f07c78fa170, active context=0x7f07c78fa170, commitString=" ", mProcessingKeyEvent=0x7f078a99cd40, IsComposingOn(aContext)=true
I/IMEHandler 0x7f07dc4455e0 DispatchCompositionCommitEvent(aContext=0x7f07c78fa170, aCommitString=0x7ffd0194d470, (" "))
I/IMEHandler 0x7f07dc4455e0 MaybeDispatchKeyEventAsProcessedByIME(aFollowingEvent=eCompositionCommit), dispatch eKeyDown processing event: { type=GDK_KEY_PRESS, keyval=space, unicode=0x20, state=FcitxKeyState_IgnoredMask, time=5542432, hardware_keycode=65, group=0 }
I/IMEHandler 0x7f07dc4455e0   MaybeDispatchKeyEventAsProcessedByIME(), keydown or keyup event is dispatched
D/IMEHandler 0x7f07dc4455e0   OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFallbackToKeyEvent=false, probablyHandledAsynchronously=true, maybeHandledAsynchronously=false), mPostingKeyEvents.Length()=0, mCompositionState=NotComposing, mMaybeInDeadKeySequence=false, mKeyboardEventWasDispatched=true, mKeyboardEventWasConsumed=false
I/IMEHandler <<<<<<<<<<<<<<<<

Then, you typed space and it's handled before committing the preceding composition!

I/IMEHandler 0x7f07dc4455e0 OnCommitCompositionNative(aContext=0x7f07c78fa170), current context=0x7f07c78fa170, active context=0x7f07c78fa170, commitString="의", mProcessingKeyEvent=0x0, IsComposingOn(aContext)=false

Then, Fcitx5 sends commit event for the preceding composition... I guess that this odd order is a bug of Fcitx5 or the conversion engine, but it's caused by returning unexpected surrounding text which does not contain the composing string.

Comment 6

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

Oh, no, surrounding text should not contain composing string according to here...
https://searchfox.org/mozilla-central/rev/a6d25de0c706dbc072407ed5d339aaed1cab43b7/widget/gtk/IMContextWrapper.cpp#3030-3039

Comment 7

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

Then, selection is modified by Fcitx5 or the conversion engine us to end of handled text by the remote process.

Ah, no, it notifies IME of caret's screen position, not notifying selection offset. And I think that we return correct value for retrieve-surrounding signal. So, currently, I'm think that this is a bug of Fcitx5 or the Korean conversion engine because it commits the latter white-space first, then, commit the pending and preceding composition. So the result is what the IME expects...

Comment 8

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

I could add a hack for committing same character as pressed key if there is ongoing composition which contains only one Hangul character, but it's hard to maintain such code, and I'm afraid to break inputs of the other IMs such as iBus and/or other languages' conversion engines. So could you file an issue to Fcitx5? (I currently don't have the environment to check this, so I'm not a good person to report it.)

Comment 9

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

Oh, it's not fcitx5, it's fcitx... I just did typo.

Comment 10

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

It might fix this bug if we do:

• return paragraph containing the composition string
• use new API, gtk_im_context_set_surrounding_with_selection

But it's really terrible change if the former fixes this. I have no idea why GTK's document does not define whether it should contain preedit string or not obviously...