Closed
Bug 1288318
Opened 8 years ago
Closed 8 years ago
Google Japanese IME unexpectedly deactivates in location bar
Categories
(Core :: Widget: Win32, defect)
Tracking
()
RESOLVED
FIXED
mozilla50
People
(Reporter: bugzilla, Assigned: masayuki)
References
Details
(Keywords: inputmethod, regression)
Attachments
(2 files)
92.80 KB,
text/plain
|
Details | |
58 bytes,
text/x-review-board-request
|
m_kato
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details |
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.
Updated•8 years ago
|
Updated•8 years ago
|
Component: Widget → Widget: Win32
Comment 1•8 years ago
|
||
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
Comment 2•8 years ago
|
||
Not reproducible on 32bit Windows 10.
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Comment 3•8 years ago
|
||
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
Updated•8 years ago
|
Component: Widget: Win32 → DOM: Events
Comment 4•8 years ago
|
||
I'm needinfoing Masayuki based on the regression range. Thanks for the regression range, arai!
Flags: needinfo?(masayuki)
Keywords: regression
Assignee | ||
Comment 5•8 years ago
|
||
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.
Assignee | ||
Comment 7•8 years ago
|
||
Hmm, I'm using x86 builds on Win10 x64...
Updated•8 years ago
|
status-firefox49:
--- → affected
status-firefox50:
--- → affected
Assignee | ||
Comment 8•8 years ago
|
||
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
Assignee | ||
Comment 9•8 years ago
|
||
Assignee | ||
Comment 10•8 years ago
|
||
Okay, perhaps, I got it. Taking.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•8 years ago
|
||
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)
Assignee | ||
Comment 12•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=01ee3e58980b
Assignee | ||
Updated•8 years ago
|
Component: DOM: Events → Widget: Win32
Comment 13•8 years ago
|
||
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+
Comment 14•8 years ago
|
||
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
Comment 15•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1523dc120715
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Assignee | ||
Comment 17•8 years ago
|
||
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 18•8 years ago
|
||
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+
Comment 19•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/ed2c14c2c6e9
You need to log in
before you can comment on or make changes to this bug.
Description
•