Closed Bug 1765091 Opened 2 years ago Closed 2 years ago

In Firefox for Linux, the IME (using fcitx5-mozc) does not accept Japanese conversion process when copying or pasting in input and textarea.

Categories

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

Firefox 99
defect

Tracking

()

VERIFIED FIXED
101 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- verified

People

(Reporter: takumikobayakawa, Assigned: masayuki)

References

(Regression)

Details

(Keywords: inputmethod, regression)

Attachments

(4 files)

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

Steps to reproduce:

  1. Install Fcitx5-mozc on Xubuntu.
  2. Open a website in Firefox.
  3. Paste a string from clipboard into textarea, or copy a string from textarea to clipboard.

Actual results:

Japanese input by Mozc does not active even if I press the set conversion key.

Expected results:

Mozc is activated.

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

I am also facing the same phenomenon.

Linux Mint 20.3(X11)+Firefox99.0.1+Fcitx(4)-mozc
LMDE5(X11)+Firefox99.0.1+Fcitx(4)-mozc
ubuntu20.04LTS(X11)+Firefox99.0+Ibus-mozc

Even with a new profile created by FF99.0 .
There was no package updated at the same time as FF99.0 .
Does not occur in Chromium .
It doesn't happen with the FF96 that remained on another PC .

https://forums.mozillazine.jp/viewtopic.php?f=5&t=19665

Japanese input by Mozc does not active even if We press the set conversion key.

Component: Widget: Gtk → DOM: UI Events & Focus Handling
Keywords: inputmethod

Set release status flags based on info from the regressing bug 1753173

:masayuki, since you are the author of the regressor, bug 1753173, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(masayuki)

(I guess that this occurs on all input frameworks of Linux. At least, I can reproduce this when using ibus/mozc)

Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Makoto Kato [:m_kato] from comment #7)

(I guess that this occurs on all input frameworks of Linux. At least, I can reproduce this when using ibus/mozc)

Odd, I cannot reproduce this with ibus/mozc on Ubuntu 21.10.

Flags: needinfo?(masayuki)

In all of my PC environments below, that phenomenon occurs.
・Linux Mint 20.3(X11)+Firefox99.0.1+Fcitx(4)-mozc
・LMDE5(X11)+Firefox99.0.1+Fcitx(4)-mozc
・ubuntu20.04LTS(X11)+Firefox99.0+Ibus-mozc

A window server happens on X11 and not on Wayland?I imagine.
Why is that regression because the FF99 added X11 security support.

Could somebody to attach a log file here? You can get it with launching firefox with MOZ_LOG=IMEHandler:4,sync and MOZ_LOG_FILE=~/fx-im? (Only the main process's log file is required, and don't type/paste something your privacy, e.g., passwords, while you record the log.)

Please elaborate on this method.

with MOZ_LOG=IMEHandler:4,sync and MOZ_LOG_FILE=~/fx-im

(In reply to E1Tmntshow from comment #11)

Please elaborate on this method.

with MOZ_LOG=IMEHandler:4,sync and MOZ_LOG_FILE=~/fx-im

They are env, so that if you launch firefox from terminal, you do:

> MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=~/fx-im ./firefox

Then, open a page and set an editor to focus, then, paste something and (try to) activate IME and type a character. Finally, close the window with mouse. (Using mouse makes the log smaller and cleaner.)

In my log, those methods are correctly called before activating Mozc.

[Parent 14711: Main Thread]: I/IMEHandler 0x7f5d51cda3a0 SetInputContext(aCaller=0x7f5d57ac8400, aContext={ mIMEState={ mEnabled=ENABLED }, mHTMLInputType=textarea })
[Parent 14711: Main Thread]: I/IMEHandler 0x7f5d51cda3a0 OnFocusChangeInGecko(aFocus=true), mCompositionState=NotComposing, mIsIMFocused=false, mSetInputPurposeAndInputHints=true
[Parent 14711: Main Thread]: I/IMEHandler 0x7f5d51cda3a0 Focus(), sLastFocusedContext=0x7f5d51cda3a0

Then, all following keyboard events go to GTK's IM Module first.

MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=~/fx-im ./firefox

LMDE5(Debian11 base)
:$ MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=/fx-im ./firefox
bash: ./firefox: そのようなファイルやディレクトリはありません

貼り付け書式がおかしいですが、コードはこんな返りでした。

(In reply to E1Tmntshow from comment #15)

MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=~/fx-im ./firefox

LMDE5(Debian11 base)
:$ MOZ_LOG=IMEHandler:4,sync MOZ_LOG_FILE=/fx-im ./firefox
bash: ./firefox: そのようなファイルやディレクトリはありません

Did you go to the directory which contains firefox? Or set PATH to be able to run firefox from anywhere. (I recommend to go to the directory.)

I forgot it.
I will prepare and then report to you.
Thank you.

Attached file moz log

IME focus seems to be lost.

[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 OnFocusChangeInGecko(aFocus=true), mCompositionState=NotComposing, mIsIMFocused=false, mSetInputPurposeAndInputHints=true
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 Focus(), sLastFocusedContext=0x7f059783b3a0
[Parent 1895337: Main Thread]: D/IMEHandler 0x7f059783b3a0 EnsureToCacheContentSelection(), Succeeded, mContentSelection={ HasRange()=false }
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 SetCursorPosition(aContext=0x7f0593522cd0), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }, mContentSelection={ HasRange()=false }
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 SetInputContext(aCaller=0x7f05a0fc0800, aContext={ mIMEState={ mEnabled=ENABLED }, mHTMLInputType=textarea })
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 SetInputContext(aCaller=0x7f05a0fc0800, aContext={ mIMEState={ mEnabled=DISABLED }, mHTMLInputType= })
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 Blur(), mIsIMFocused=true
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 SetInputContext(aCaller=0x7f05a0fc0800, aContext={ mIMEState={ mEnabled=ENABLED }, mHTMLInputType=textarea })
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 OnSelectionChange(aCaller=0x7f05a0fc0800, aIMENotification={ mSelectionChangeData={ mOffset=25, mString="" (Length()=0), GetWritingMode()=h-ltr, mReversed=false, mCausedByComposition=false, mCausedBySelectionEvent=false, mOccurredDuringComposition=false } }), mCompositionState=NotComposing, mIsDeletingSurrounding=false, mRetrieveSurroundingSignalReceived=false, isSelectionRangeChanged=true
[Parent 1895337: Main Thread]: I/IMEHandler >>>>>>>>>>>>>>>>
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 OnKeyEvent(aCaller=0x7f05a0fc0800, aEvent(0x7f056e10c2e0): { type=GDK_KEY_PRESS, keyval=a, unicode=0x61, state=, time=825641765, hardware_keycode=38, group=0 }, aKeyboardEventWasDispatched=false)
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0   OnKeyEvent(), mMaybeInDeadKeySequence=false, mCompositionState=NotComposing, current context=7f0593522cd0, active context=7f0593522cd0, mIMContextID=IBus, mIsIMInAsyncKeyHandlingMode=true
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 SetCursorPosition(aContext=0x7f0593522cd0), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }, mContentSelection={ HasRange()=false }
[Parent 1895337: Main Thread]: I/IMEHandler 0x7f059783b3a0 OnCommitCompositionNative(aContext=0x7f0593522cd0), current context=0x7f0593522cd0, active context=0x7f0593522cd0, commitString="a", mProcessingKeyEvent=0x7f056e10c2e0, IsComposingOn(aContext)=false
See Also: → 1763995

テキストエディタからFirefoxへクリップボード経由で貼り付け時のタスク切り替えで、
マウスでFirefoxをアクティブにすると、この不具合が発症し、
Alt TabでFirefoxをアクティブにすると、この不具合が発症しない
ことに気づきました。

Thank you very much. It's indeed really odd. I still don't understand who stole the focus from our window temporarily. And then, we failed to restore IME focus. Keep investigating...

Perhaps, IMContextWrapper::Blur shouldn't be called by IMContextWrapper::SetInputContext because nsIWidget::SetInputContext is called with every IME state change, but without a focus move, IMEContentObserver never sends NOTIFY_IME_FOCUS. That's the reason why IMContextWrapper fails to restore focus of IME.

Assignee: nobody → masayuki
Status: NEW → ASSIGNED

Hmm, but the approach is too risky. So I'll make 3 state of IME focus.

Severity: -- → S2
Priority: -- → P1

申し訳ないです。私には難しいと思います。
私はLinuxディストリビューションにプリインストールのFirefoxしか使ったことがありません。
本家版をインストールした経験がないので、環境整備やそこからの勉強になります。
トライはしますが、私の結果を待たないでください。

Flags: needinfo?(dnfuf5pcp)

Just unzipm it under your home direcctory first, then run firefox in it. It does not reuse your profile by default. I creates its own profile newly so that it wont break anything.

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

I think that this build fixes this bug. Could you check it?
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NbvZPUfJRVaY7J4aftMlYw/runs/0/artifacts/public/build/target.tar.bz2

It seems to be fixed.

私も、直っていることを確認できました。

Thank you, I'll post it.

In bug 1753173, we needed to make IMContextWrapper wait for a focus
notification from IMEContentObserver because it's not ready to query
content when the input context is enabled.

However, this means that, if the input context is enabled without focus change,
IMContextWrapper does not have a change to set focus to IME. Therefore,
if IMContextWrapper blurs IME without focus move, the state should be
remembered as IME blurred but it's caused by that the input context is disabled.
Then, IMContextWrapper can restore focus immediately if the input context
gets enabled and focus has not been changed.

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/9ee9675516cd
Make `IMContextWrapper` set focus to IME immediately if IME was blurred by disabling the input context r=m_kato
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Flags: qe-verify+

I could not reproduce the issue on Ubuntu 20.4 using build 99.0.
Can you please confirm issue is fixed on latest Beta (https://archive.mozilla.org/pub/firefox/candidates/)? Thank you so much.

Flags: needinfo?(takumikobayakawa)

This issue has not yet been fixed in version 100.0.2, but I have confirmed that it has been fixed in 101.0b9. Thank you for fixing it.

Flags: needinfo?(takumikobayakawa)

Issue is fixed only starting with 101 builds. Marking as verified based on comment35.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: