Closed
Bug 1381732
Opened 7 years ago
Closed 7 years ago
IME is disabled after changing window focus
Categories
(Core :: Widget: Win32, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | ? | fixed |
People
(Reporter: birtles, Assigned: masayuki)
References
Details
(Keywords: inputmethod, regression)
Attachments
(1 file)
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.
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 | ||
Updated•7 years ago
|
status-firefox54:
--- → unaffected
Comment 2•7 years ago
|
||
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.
Comment 3•7 years ago
|
||
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.
Comment 4•7 years ago
|
||
(nit: the window-switching hot key on Mac is obviously Cmd+tab, instead of Alt-tab)
Comment 5•7 years ago
|
||
[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
Assignee | ||
Comment 6•7 years ago
|
||
Surprisingly, this is really long standing bug! We were just lucky because we have never met the condition.
Comment hidden (mozreview-request) |
Comment 8•7 years 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+
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
Comment 10•7 years ago
|
||
(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•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Updated•7 years ago
|
status-firefox-esr52:
--- → unaffected
Reporter | ||
Comment 12•7 years 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)
Assignee | ||
Comment 13•7 years ago
|
||
(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)
Assignee | ||
Comment 14•7 years ago
|
||
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•7 years ago
|
||
I tried switching that pref to false and restarting but I still see the bug. I am using MS-IME.
Assignee | ||
Comment 16•7 years ago
|
||
Oh, really? That's odd... I'll investigate it soon.
You need to log in
before you can comment on or make changes to this bug.
Description
•