IME is disabled after changing window focus

RESOLVED FIXED in Firefox 56

Status

()

Core
Widget: Win32
P1
normal
RESOLVED FIXED
3 months ago
3 months ago

People

(Reporter: birtles, Assigned: masayuki)

Tracking

({inputmethod, regression})

Trunk
mozilla56
All
Windows 10
inputmethod, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox54 unaffected, firefox55 unaffected, firefox56? fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

3 months ago
STR:
1. Open Gmail
2. Click "Compose"
3. Write some text in message body with IME enabled (e.g. あ)
4. Alt+Tab to another non-Firefox window.
5. Alt+Tab back to the Firefox window with Gmail.
6. Press 'a' in the keyboard.

Expected results:
IME is still active and, e.g. あ is produced.

Actual results:
The IME is disabled (in the taskbar an 'x' is shown') and hence 'a' is produced. Furthermore, it is not possible to activate to the IME be pressing the 半角/全角漢字 button. If I click the text area again, however, the IME is enabled and activated.

Comment 1

3 months ago
Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=52d81035277456e1efd1f218daa9147e57546f8c&tochange=3bdc87d4e53823781ac103930c6a06f2f0c95f80
Blocks: 1377672
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox55: --- → unaffected
status-firefox56: --- → affected
Hardware: x86_64 → All
Summary: IME is disabled after changing focus → IME is disabled after changing window focus
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Keywords: inputmethod
status-firefox54: --- → unaffected
STR for me (which probably is but might not be the exact same underlying issue):

1. Have IME disabled.
2. Focus an input / textarea.
3. Activate IME, leaving the input / textarea focused.  (For example by pressing a keyboard shortcut to activate IME.)
4. Type some text.

Expected results:

IME handles input.

Actual results:

IME does not handle input.
Thanks for comment 0 for STR and :haycam for the pointer. I can produce this bug on Mac too! The actual result is a slightly different; I am not sure if this is another bug.

STR:
1. Open Gmail
2. Click "Compose"
3. Write some text in message body with IME enabled (e.g. ㄆ)
4. Alt+Tab to another non-Firefox window.
5. Alt+Tab back to the Firefox window with Gmail.
6. Press 'q' in the keyboard.

Expected results:
IME is still active and, e.g. ㄆ is produced.

Actual results:
The IME is disabled (*but* the menu icon still shows it being active) and hence 'q' is produced. Furthermore, it is not possible to activate to the IME by Cmd+space. The menu icon will switch the IME on-and-off but it will never become active. The only workaround I've found so far is moving the focus to address bar and back.
(nit: the window-switching hot key on Mac is obviously Cmd+tab, instead of Alt-tab)
[Tracking Requested - why for this release]: Given that we are approaching beta merge day, it's definitely a bug we are concerning and worth tracking in coming beta release.
tracking-firefox56: --- → ?
Priority: -- → P1
Surprisingly, this is really long standing bug! We were just lucky because we have never met the condition.
Comment hidden (mozreview-request)

Comment 8

3 months ago
mozreview-review
Comment on attachment 8889892 [details]
Bug 1381732 - IMEStateManager::OnChangeFocusInternal() shouldn't set IME state when focus is not being changed, input context of the widget was already set by a remote process and our process is being activated

https://reviewboard.mozilla.org/r/160952/#review166564
Attachment #8889892 - Flags: review?(m_kato) → review+

Comment 9

3 months ago
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/5886dae0a324
IMEStateManager::OnChangeFocusInternal() shouldn't set IME state when focus is not being changed, input context of the widget was already set by a remote process and our process is being activated r=m_kato
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #6)
> Surprisingly, this is really long standing bug! We were just lucky because
> we have never met the condition.

That's true and to me it happened intermittently so that I don't have STR with further help.
Thanks for fixing this bug!

Comment 11

3 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/5886dae0a324
Status: ASSIGNED → RESOLVED
Last Resolved: 3 months ago
status-firefox56: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
status-firefox-esr52: --- → unaffected
(Reporter)

Comment 12

3 months ago
I'm still seeing this in today's nightly based on https://hg.mozilla.org/mozilla-central/rev/2fba314d7de77ad8ab693a2ea0112c0cda5dd564

Is that expected?
Flags: needinfo?(masayuki)
(In reply to Brian Birtles (:birtles, away 31 July~7 Aug) from comment #12)
> I'm still seeing this in today's nightly based on
> https://hg.mozilla.org/mozilla-central/rev/
> 2fba314d7de77ad8ab693a2ea0112c0cda5dd564
> 
> Is that expected?

Oh, that's odd. I can reproduce it only with MS-IME for Japanese, not reproduce with ATOK nor Google Japanese IME. It might be related to disassociating IMM context only when active IME is MS-IME??
Flags: needinfo?(masayuki)
Oh, my guess is correct. Brian, please turn "intl.tsf.hack.ms_japanese_ime.do_not_associate_imc_on_win10" to false and restart your Firefox. I'll remove the hack from Gecko since it failed to prevent crash of MS-IME and also caused another regression.
(Reporter)

Comment 15

3 months ago
I tried switching that pref to false and restarting but I still see the bug. I am using MS-IME.
Oh, really? That's odd... I'll investigate it soon.
Blocks: 1386556
You need to log in before you can comment on or make changes to this bug.