Closed Bug 1288318 Opened 8 years ago Closed 8 years ago

Google Japanese IME unexpectedly deactivates in location bar

Categories

(Core :: Widget: Win32, defect)

50 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox49 --- fixed
firefox50 --- fixed

People

(Reporter: bugzilla, Assigned: masayuki)

References

Details

(Keywords: inputmethod, regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160720030208

Steps to reproduce:

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0

1. Use Google Japanese IME's hiragana input mode
2. Open new tab (Ctrl+T). The location bar is focused.
3. Type a Japanese string into the location bar, e.g., あいうえお ("aiueo"), for the purpose of using the location bar as a web search bar.


Actual results:

The Japanese input deactivates only for the second character in the string, resulting in the improper string あiうえお and only うえお being selected for kanji conversion.


Expected results:

The string あいうえお should appear and the entirety should be selected for kanji conversion.

This issue is not observed when entering text into the search bar (Ctrl+K) or in the search box that appears right above the frequently visited sites grid, nor when using the Microsoft IME for Japanese in Windows 10 instead of Google's.
Component: Untriaged → Widget
Keywords: inputmethod
Product: Firefox → Core
Component: Widget → Widget: Win32
Confirmed the issue on Nightly.

on Firefox 47, hiragana input is deactivated after step 2, so there should be behavior change between them.
will bisect it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not reproducible on 32bit Windows 10.
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Here's the range the behavior change (comment #1) happens:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=663a28f984ab&tochange=63073a47

So, this should be something related to bug 1267526.
not sure if this is a really regression from it, as previous behavior (deactivate hiranaga input) is also not expected results.
See Also: → 1267526
Component: Widget: Win32 → DOM: Events
I'm needinfoing Masayuki based on the regression range. Thanks for the regression range, arai!
Flags: needinfo?(masayuki)
Keywords: regression
Hmm, I have no idea why bug 1267526 causes such regression since it just prevents redundant selection change notifications to IME. Especially, I cannot reproduce this bug with x86 Aurora nor x86 Nighty build. It could be not our bug...

If you can reproduce this bug with x64 Nightly, I suppose that this is a bug of Google Japanese Input because current Nightly build does not notify TSF of anything during composition. So, sounds like that Google Japanese Input changes its input mode asynchronously.

> as previous behavior (deactivate hiranaga input) is also not expected results.

It's designed by TIP. Our location bar notifies TSF of URL input field. That causes the behavior (I forgot the bug#).

I guess that we should hide the information at setting input context when Google Japanese Input or Japanese MS-IME is active. Then, perhaps, we can avoid this bug too since Google Japanese Input does not need to close its open state.

Unfortunately, I don't have much time to work on this, though...
Flags: needinfo?(masayuki)
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #5)
> Especially, I cannot reproduce this bug with x86 Aurora nor x86 Nighty build. 

I was able to reproduce it on the x86 Nightly build on 64-bit Windows 10 (Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0, build ID 20160721030216). Tooru mentioned not reproducible in 32-bit Windows 10, so it likely is related to differences in our OS and/or Google IME build.
Hmm, I'm using x86 builds on Win10 x64...
Oh, I find bug 1253165 that's the closing issue in the location bar. Then, I remembered Status-4-Ever disables the feature unexpectedly. That must be the reason why I cannot reproduce this bug.
QA Whiteboard: https://bugzilla.mozilla.org/show_bug.cgi?id=1253165
Okay, perhaps, I got it. Taking.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
In CreateAndSetFocus(), SetInputScope() is called *after* setting focus to the context. At this time, Google Japanese Input retrieves InputScopes. Therefore, TSFTextStore returns IS_DEFAULT. But after that, Google Japanese Input tries to retrieve InputScopes after every notification (in this case, a call of ITextStoreACPSink::OnLayoutChange()). Then, we return IS_URL due to set after returns IS_DEFAULT.

This is actually our fault, but according to the other TIPs, Google Japanese Input shouldn't commit composition at detecting an InputScope change, though.

Review commit: https://reviewboard.mozilla.org/r/66470/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/66470/
Attachment #8773775 - Flags: review?(m_kato)
Component: DOM: Events → Widget: Win32
Comment on attachment 8773775 [details]
Bug 1288318 Initialize TSFTextStore::mInputScopes at initializing its members rather than after setting focus to the context

https://reviewboard.mozilla.org/r/66470/#review63434
Attachment #8773775 - Flags: review?(m_kato) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/1523dc120715
Initialize TSFTextStore::mInputScopes at initializing its members rather than after setting focus to the context r=m_kato
https://hg.mozilla.org/mozilla-central/rev/1523dc120715
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Please request uplift to Aurora, and thanks!
Flags: needinfo?(masayuki)
Comment on attachment 8773775 [details]
Bug 1288318 Initialize TSFTextStore::mInputScopes at initializing its members rather than after setting focus to the context

Approval Request Comment
[Feature/regressing bug #]: Bug 1267526 fix causes to show our this hidden bug.
[User impact if declined]: As explained this bug, user sees odd behavior (committed forcibly during composition) with Google Japanese IME when user inputs some Japanese text immediately after setting focus to the location bar.
[Describe test coverage new/current, TreeHerder]: Landed on m-c.
[Risks and why]: Low, because this patch changes the timing of TSFTextStore storing the input context information. This is caused by Google Japanese Input retrieving the information before TSFTextStore has it.
[String/UUID change made/needed]: No.
Flags: needinfo?(masayuki)
Attachment #8773775 - Flags: approval-mozilla-aurora?
Comment on attachment 8773775 [details]
Bug 1288318 Initialize TSFTextStore::mInputScopes at initializing its members rather than after setting focus to the context

Fix a regression, taking it.
Attachment #8773775 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: