Closed Bug 1310454 Opened 3 years ago Closed 2 years ago

Japanese IMEs spontaneously switch to Hiragana while typing in the address bar

Categories

(Core :: Widget: Win32, defect, P2)

49 Branch
x86_64
Windows 10
defect

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox-esr52 - wontfix
firefox53 --- wontfix
firefox54 --- verified
firefox55 --- verified

People

(Reporter: jaimebug, Assigned: masayuki)

References

Details

(Keywords: inputmethod, Whiteboard: tpi:+)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

This is on Windows 10, which switches the input mode to Half-width Alphanumeric (on Microsoft IME) or Direct Input (on Google Japanese Input) when the address bar is selected (which is itself annoying because the address bar is also used for search, but I digress). I'm using a US keyboard. Open a new Firefox window and type in Hiragana in a field other than the address bar. (I used テスト [tesuto] as a string, but any seems to work.) Then select the address bar. The input mode switches to an alphanumeric mode (as described). Then type.


Actual results:

After one or two characters, the input mode switches to Hiragana by itself. I've tried this on two computers, one with Anniversary Update and one without AU and with a new profile. It's one character on the former, two on the latter. Same problem with MS IME and with Google Japanese Input. The problem also occurs at other times, but this is the surefire way to reproduce it.


Expected results:

The expected result is for the input mode to stay alphanumeric.

(It would be even better if it could be stopped from switching to alphanumeric mode in the first place, as it seems to be on Opera, but that is apparently part of Windows 10's design.)
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Makoto, could you check this issue, please.
Component: Untriaged → Widget: Win32
Flags: needinfo?(m_kato)
Keywords: inputmethod
Product: Firefox → Core
This depends on bug 1240208.  Since Microsoft IME and Google IME support input scope and awesomebar has inputmode=url, input mode will be changed by IME.
Depends on: 1240208
Flags: needinfo?(m_kato)
Is this a duplicate of bug 1253165, effectively?
Flags: needinfo?(masayuki)
Although I would like the pref suggested in bug 1253165 to stop the input mode from changing to alphanumeric, that is not the bug here, per se. The bug here is that, after the input mode changes to alphanumeric according to inputmode=url, it changes back to Hiragana by itself while typing. So I type the keys "wrs" (I normally use kana input, not romaji input, but either produces the bug), and the address bar shows "wすと". This occurs in a new window when the steps to reproduce are used and does not occur immediately again in the same window, but does occur later unpredictably.
(In reply to jaimebug from comment #4)
> Although I would like the pref suggested in bug 1253165 to stop the input
> mode from changing to alphanumeric, that is not the bug here, per se. The
> bug here is that, after the input mode changes to alphanumeric according to
> inputmode=url, it changes back to Hiragana by itself while typing. So I type
> the keys "wrs" (I normally use kana input, not romaji input, but either
> produces the bug), and the address bar shows "wすと". This occurs in a new
> window when the steps to reproduce are used and does not occur immediately
> again in the same window, but does occur later unpredictably.

It's already fixed by bug 1288318 which is included starting from 50. Could you check if it's fixed in 50?

Now, 50 is Beta:
https://www.mozilla.org/en-US/firefox/channel/desktop/
Flags: needinfo?(masayuki) → needinfo?(jaimebug)
Unfortunately, it is not fixed in 50.0b9.
Flags: needinfo?(jaimebug)
Masayuki, can you confirm the state of this bug? You were saying this is fixed in 50, a reporter claims otherwise.
Flags: needinfo?(masayuki)
It's odd, I reproduce this with 50~ on Win10 build 14393 (current release) and Win10 build 14965 (insider build in slow ring).

Although, I have no idea why the fix won't work with released builds and I don't have enough time to take a look this again at least in this year.

First, we need to get a log with |MOZ_LOG=nsTextStoreWidgets:5,sync| and |MOZ_LOG_FILE=<path to log file>| for understanding what's odd of our implementation.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(masayuki)
Priority: -- → P2
Whiteboard: tpi:+
I got what happens when I work on other bug.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
When the URL bar gets focus, it creates popup window asynchronously. The widget tries to init its native IME context with IMEHandler::InitInputContext().  Then, it calls TSFTextStore::SetInputFocus() with GOT_FOCUS as its reason.  However, it's wrong and TSFTextStore is now nothing to do when widgets are created.  Therefore, IMEHandler::InitInputContext() should send correct reason "WIDGET_CREATED" and TSFTextStore should ignore the call. (I though that IMEHandler::InitInputContext() shouldn't call TSFTextStore::SetInputContext().  However, it might cause this bug as regression again.  So, explicitly ignoring the method call by itself is safer and easier to understand.)
Comment on attachment 8869704 [details]
Bug 1310454 part 1 - Log more info when TSFTextStore gets InputContext and InputScopes

https://reviewboard.mozilla.org/r/141292/#review145026
Attachment #8869704 - Flags: review?(m_kato) → review+
Comment on attachment 8869705 [details]
Bug 1310454 part 2 - TSFTextStore::SetInputContext() should do nothing when it's called for initializing native IME context when a widget is created

https://reviewboard.mozilla.org/r/141294/#review145028
Attachment #8869705 - Flags: review?(m_kato) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/19b3aacd8ffe
part 1 - Log more info when TSFTextStore gets InputContext and InputScopes r=m_kato
https://hg.mozilla.org/integration/autoland/rev/ebfb290d0d53
part 2 - TSFTextStore::SetInputContext() should do nothing when it's called for initializing native IME context when a widget is created r=m_kato
https://hg.mozilla.org/mozilla-central/rev/19b3aacd8ffe
https://hg.mozilla.org/mozilla-central/rev/ebfb290d0d53
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Since 54 is likely to be affected, would you like to request uplift? 
Would it be useful to verify this fix, also?
Flags: needinfo?(masayuki)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #18)
> Since 54 is likely to be affected, would you like to request uplift? 
> Would it be useful to verify this fix, also?

Thanks. This is really annoying bug for Google Japanese Input users and the patches are really simple. So, I think that it's worthwhile to uplift them.
Flags: needinfo?(masayuki)
Comment on attachment 8869704 [details]
Bug 1310454 part 1 - Log more info when TSFTextStore gets InputContext and InputScopes

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:

This is not a serious security bug, but very annoying bug for Google Japanese Input users. And fortunately, the patches are really simple. So, it's worthwhile to uplift.

User impact if declined: 

When user uses Google Japanese Input and starts typing something in URL bar, Google Japanese Input closes IME for typing URL (this is expected behavior). However, during typing some characters, Google Japanese Input opens itself. I.e., typing characters becomes Japanese characters during typing URL in the URL bar.

Fix Landed on Version:
55

Risk to taking this patch (and alternatives if risky):
No risk. This patch just changes the MOZ_LOG.

String or UUID changes made by this patch: 
No.

Approval Request Comment
[Feature/Bug causing the regression]:
Regression, but the bug# is not sure.

[User impact if declined]:
See above. This is very annoying bug for Google Japanese Input users.

[Is this code covered by automated tests?]:
No.

[Has the fix been verified in Nightly?]:
Yes.

[Needs manual test from QE? If yes, steps to reproduce]:
Yes.

1. Install Google Japanese Input on Windows.
2. Set focus to the Search bar.
3. Open IME with Alt+` or clicking "A" icon in the language bar and choose "Hiragana" (ひらがな).
4. Move focus to the URL bar.
5. Type 'a' a lot, and check if you can keep typing ASCII characters, not 'あ'.

[List of other uplifts needed for the feature/fix]:
Following patch.

[Is the change risky?]:
No.

[Why is the change risky/not risky?]:
This patch just changes MOZ_LOG code.

[String changes made/needed]:
No.
Attachment #8869704 - Flags: approval-mozilla-esr52?
Attachment #8869704 - Flags: approval-mozilla-beta?
Comment on attachment 8869705 [details]
Bug 1310454 part 2 - TSFTextStore::SetInputContext() should do nothing when it's called for initializing native IME context when a widget is created

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:

See the previous comment.

User impact if declined: 

See the previous comment.

Fix Landed on Version:

55

Risk to taking this patch (and alternatives if risky):

Really low. This adds new value 'WIDGET_CREATED' to InputContextAction::FocusChange and when widget is created on Windows, it uses the new value during initializing its native IME context.  Then, TSFTextStore just ignores the SetInputContext() call since it doesn't need to do anything until the widget gets focus.

String or UUID changes made by this patch: 

No.

Approval Request Comment
[Feature/Bug causing the regression]:

See the previous comment.

[User impact if declined]:

See the previous comment.

[Is this code covered by automated tests?]:

No.

[Has the fix been verified in Nightly?]:

Yes.

[Needs manual test from QE? If yes, steps to reproduce]: 

See the previous comment.

[List of other uplifts needed for the feature/fix]:

The previous patch.

[Is the change risky?]:

No.

[Why is the change risky/not risky?]:

See above. This patch just makes TSFTextStore::SetInputContext() does nothing only when the widget is being created.

[String changes made/needed]:

No.
Attachment #8869705 - Flags: approval-mozilla-esr52?
Attachment #8869705 - Flags: approval-mozilla-beta?
Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
Flags: qe-verify+
Flags: needinfo?(brindusa.tot)
Comment on attachment 8869704 [details]
Bug 1310454 part 1 - Log more info when TSFTextStore gets InputContext and InputScopes

Let's go ahead and uplift this fix to beta and see if we can verify it there.
Attachment #8869704 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8869705 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Hi David, need a second opinion on this one. ESR uplifts are generally limited to severe widespread regressions, stability and security issues. As such, I don't think this bug meets the bar, given that it's at least a 7 month old regression. Do you agree? IME fixes tend to be not so trivial and I'd rather not uplift a risky fix to ESR52. Thanks!
Flags: needinfo?(dbolter)
Ritu I'm torn but I think your assessment is right for ESR. (Glad you got it fixed Masayuki!)
Flags: needinfo?(dbolter)
Reproduced the bug with a Nightly build 55.0a1 from 05/10/2017 on Windows 10 x64.

Verified as fixed on the latest Nightly 55.0a1, build ID 20170526030203 on Windows 10 x64.
Status: RESOLVED → VERIFIED
Flags: needinfo?(brindusa.tot)
Comment on attachment 8869704 [details]
Bug 1310454 part 1 - Log more info when TSFTextStore gets InputContext and InputScopes

Thanks David for your help! Let this fix ride the esr59 train and not uplift to esr52.
Attachment #8869704 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52-
Attachment #8869705 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52-
Reproduced this issue with an affected build (FF 53.0.3 - 20170518000419) on Win 10 x64.

This is not reproducible anymore on 54.0 (20170605134926) under Windows 10 x64.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.