Issue metadata
Sign in to add a comment
|
Chinese language input not working: CJK candidate window doesn't show up |
||||||||||||||||||||||
Issue descriptionChrome Version : 73.0.3669.0 Platform : 11578.0.0 － snappy, coral_santa What steps will reproduce the problem? (1) set IME to Pinyin input method (2) try to enter "tiananme" in the omnibox or any input field. Then, check the Chinese candidate window What is the expected result? The candidate window should appear while entering. What happens instead? The candidate window doesn't show up while entering the input Please provide any additional information below. Attach a screenshot if possible. Unable to reproduce the issue on 72.0.3626.49/11316.66.0 - cave Mark the "releaseblock_dev" since CJK users are not able to enter CJ & Hanja(Korean) properly.
,
Jan 15
Bisect result : Bad build : 73.0.3666.0/11555.0.0-snappy Good build : 73.0.3664.0 / 11552.0.0 - Coral Changelist : https://chromium.googlesource.com/chromium/src/+log/73.0.3664.0..73.0.3666.0?pretty=fuller&n=10000
,
Jan 15
xiyuan@ Could you check the bug whether it is related to issue/919183. thanks
,
Jan 16
(6 days ago)
I don't think it is related to issue 919183 . How reliably the bug repros? And when the bug happens, do you notice whether chrome runs in single process mash mode (if it is, there should be a label on top-right corner of the desktop/lock/login screen).
,
Jan 18
(4 days ago)
I'm seeing multiple reports from users with language set as EN or ZH who say that Pinyin input is not working on M73. Probably not Release-Block-Dev issue, but should be fixed by Beta or Stable. Reports from 73.0.3669.0 dev with logs: https://listnr.corp.google.com/report/85915541061 https://listnr.corp.google.com/report/85915431671 https://listnr.corp.google.com/report/85911901593 https://listnr.corp.google.com/report/85914114211 https://listnr.corp.google.com/report/85911362885
,
Jan 18
(4 days ago)
,
Jan 18
(4 days ago)
This is a recent regression and happens without single process mash. Doing a bisect now.
,
Jan 18
(4 days ago)
Bisected to https://chromium-review.googlesource.com/c/chromium/src/+/1396794 The problem is caused by putting the candidate window in kShellWindowId_VirtualKeyboardContainer. The container has KeyboardLayoutManager, which probably blocks the candiate window SetBounds call.
,
Jan 18
(4 days ago)
,
Today
(13 hours ago)
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2515f154344593adc5bd81f9dce036d5845dbe58 commit 2515f154344593adc5bd81f9dce036d5845dbe58 Author: Xiyuan Xia <xiyuan@chromium.org> Date: Tue Jan 22 17:13:51 2019 Fix the missing IME candidate window https://crrev.com/c/1396794 moves IME candidate to VK container managed by KeyboardLayoutManager. KeyboardLayoutManager was expecting only the VK contents window and blocks bounds change for all other windows. As a result, IME candidate window bounds change is ignored. This CL fixes the issue by making the layout manager to allow other windows to change bounds. Bug: 921689 Change-Id: I351543fc3129425e01773798f4abc08cf9d5e684 Reviewed-on: https://chromium-review.googlesource.com/c/1423298 Reviewed-by: Darren Shen <shend@chromium.org> Commit-Queue: Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/heads/master@{#624804} [modify] https://crrev.com/2515f154344593adc5bd81f9dce036d5845dbe58/ui/keyboard/keyboard_layout_manager.cc
,
Today
(11 hours ago)
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by cindyb@chromium.org
, Jan 15