Issue metadata
Sign in to add a comment
|
Japanese IME left-right arrow navigation issue in text input fields
Reported by
mas...@japancreate.jp,
Jan 4 2017
|
||||||||||||||||||||||
Issue description
Chrome Version : 55.0.2883.87 m (64-bit)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Firefox: PASS (50.1.0)
IE: PASS (38.14393.0.0)
What steps will reproduce the problem?
(1) Open Chrome browser
(2) Go to a random web page with any text or textarea input fields
(3) Change input method to Japanese (MS IME or Google IME)
(4) Type some long-ish Japanese text with multiple words, e.g. なまえ、じゅうしょ、でんわばんごう
What is the expected result?
I should be able to use left and right arrow keys to navigate between 3 words:
- なまえ
- じゅうしょ
- でんわばんごう
and press space to see the candidate lists for each of them before I commit the whole text.
These are the visual indicators:
- Word in current position: solid underline
- Other words: dotted underline
What happens instead?
Although navigation seem to work internally, there are no visual indicators of the current position.
I can test this by pressing right arrow a few times and pressing space to see my current position.
Please provide any additional information below. Attach a screenshot if possible.
Japanese input works as expected on non-web environments such as text editors.
OS: Windows 10 Pro (10.0.14393)
For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.
,
Jan 5 2017
This problem doesn't exist in Chrome Canary (57.0.2971.0)
,
Jan 6 2017
,
Jan 6 2017
Adding localization component for this issue for triaging the issue further. Some one from Localization team please look in to this issue. Thank you!
,
Jan 8 2017
> This problem doesn't exist in Chrome Canary (57.0.2971.0) We should test this issue with M56 branch. Find and merge a fix to M56 if the issue is reproducible, do nothing otherwise.
,
Jan 13 2017
Tested on Mac: Repro with Beta (56.0.2924.59) Doesn't repro with Canary (57.0.2977.0)
,
Jan 17 2017
Able to reprduce the issue on win10 chrome version 56.0.2924.59. But this is working fine in latest canary 57.0.2983.0 Manual Bisect Info: Last bad build:57.0.2951.0 First good build :57.0.2952.0 Bisect Tool Info: You are probably looking for a change made after 438488 (known good), but no later than 438493 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/59343ca9b2680dee482a9ac246c944705a0bd3d0..7d85923117fbe38350e7022f6003d37b58b013f2 Possible suspect : https://codereview.chromium.org/2530843003 yabinh@, Could you please merge the fix to M56 Please reassign if this is not related to your change.
,
Jan 17 2017
,
Jan 17 2017
OK. We should merge the CL. BTW, it's also needed for issue 680537. changwan@, can you do that for me? I'm not a committer yet.
,
Jan 17 2017
,
Jan 17 2017
This bug requires manual review: We are only 13 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 18 2017
Re #9, we can also consider merging the mentioned CL and the new CL (https://codereview.chromium.org/2634243002/) as one CL in M56.
,
Jan 18 2017
Hmm, the fix patch itself caused another regression http://crbug.com/681822 . The cherry-pick story is getting too complicated for 56, so I guess we should unfortunately hold off and let the fix roll out on the M57 schedule, since this bug has already hit stable channel.
,
Feb 2 2017
,
Mar 8 2017
Fixed in M57. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Jan 4 2017Labels: Needs-Triage-M55