Issue metadata
Sign in to add a comment
|
CJK:Delete doesn't work properly when the input isn't committed on Google document/Presentation, omnibox, Findinpage |
||||||||||||||||||||||
Issue descriptionChrome Version : 60.0.3112.0 Platform : 9592.0.0 - Reks, What steps will reproduce the problem? (1) open Google document (2) set IME to Korean (3) enter "gksrmf",한글, and don't commit the input (4) hit "backspace" key time to delete the input,ㄹ (5) hit "backspace" key time to delete the input,ㅡ (6) hit "backspace" key time to delete the input,ㄱ (7) hit "backspace" key time What is the expected result? On step#4,"ㄹ" should be deleted. Should be able to see the "한그" On step#5, "ㅡ" should be deleted. Should be able to see the "한ㄱ" On step#6, "ㄱ" should be deleted. Should be able to see the "한" On step#7, "한" should be deleted. What happens instead? On step#4, The "ㄹ" isn't deleted. "한그글" appears On step#5, "ㅡ" isn't deleted. "한ㄱ그글" appears On step#6, "ㄱ" is deleted. "한 그글" appears On step#7, the cursor is stuck on after "한". Still seeing the "한 그글" Please provide any additional information below. Attach a screenshot if possible. Unable to reproduce the issue on 59.0.3071.71/9460.50.0 - Candy
,
May 31 2017
Not reproducible in Chrome 60.0.3112.7 - Win7, Ubuntu 14.04
,
Jun 1 2017
CJK delete doesn't work properly on the omnibox and findinpage.
Steps for Pinyin (Simplified Chinese) :
1. set IME to Pinyin
2. enter "tian" on the omnibox or Findin page, and don't commit the input
3. hit "backspace" key few times
Actual Result : 1st time hit the "backspace" key, "n" is deleted
2nd time hit the "backspace" key, "tia" is deleted. All strokes are deleted
Expected result : 1st time hit the "backspace", "n" should be deleted
2nd time hit the "backspace", "a" should be deleted
============
Unable to reproduce the issue on another input fields (Gmail, google search, Daum site)
,
Jun 1 2017
comment#3 happens on 9592.3.0/60.0.3112.10 - Peppy
,
Jun 1 2017
,
Jun 2 2017
This actually 2 separated issues: 1. On native text input fields (Omnibox, FindInPage box, etc.), each Backspace key press generates a ConfirmComposition op. 2. On Docs, the Docs editor seems processing Backspace KeyUp event which isn't muted by IME. (Yingbing will confirm/fix this) songsuk@, can you please help to bisect for #1? Thanks! +ggalante@ to grab Docs team's awareness for #2.
,
Jun 2 2017
,
Jun 2 2017
For #2, I verify it's not "keyup" issue. I don't find the root cause now.
,
Jun 2 2017
For #2, I found when clears the composition, but IMF doesn't fire composition end event. IMF should fire the event. For Pinyin/Korean/Japanese IME, type "a" (Japanese should press space more), then BS then Space. We found should append the additional text in Doc. That means Doc enter wired states. So let IMF to fire correct events sequence first, it may fix the issue.
,
Jun 2 2017
songsuk@, we're looking for the bisect result. Thanks!
,
Jun 2 2017
Good build : chrome 60.0.3103.0/CrOS 9568.0.0 -Peppy Bad build : Chrome 60.0.3105.0/CrOS 9569.0.0 -Peppy
,
Jun 2 2017
@wuyingbing, Here is the changelist-url and I could't find specific culprit CL : https://chromium.googlesource.com/chromium/src/+log/60.0.3103.0..60.0.3105.0?pretty=fuller&n=10000
,
Jun 2 2017
Confirm that I got the same bisect result for Case1&2 on comment#6 : Good build : chrome 60.0.3103.0/CrOS 9568.0.0 -Peppy Bad build : Chrome 60.0.3105.0/CrOS 9569.0.0 -Peppy
,
Jun 3 2017
Assigning to me for CL bisect.
,
Jun 3 2017
Scanned by my eyes, suspecting https://codereview.chromium.org/2872343003. Hadi, mind taking a look and confirm? Thanks.
,
Jun 3 2017
Not sure if this is related, but does https://codereview.chromium.org/2916673002/ which fixes some problem with the CL shuchen@ pointed fixes this? If not, I'll debug it.
,
Jun 3 2017
I don't think the cl https://codereview.chromium.org/2916673002 will fix this. Just saw you're reverting the cl by https://codereview.chromium.org/2872343003, so hopefully this can be fixed after the revert cl is landed. Btw, I don't have a dev machine to build/verify the CLs (over the weekend) but I will try to review the cl https://codereview.chromium.org/2872343003 to see whether there are some issues.
,
Jun 4 2017
Just reviewed cl https://codereview.chromium.org/2872343003 and didn't find the issue. The fix cl https://codereview.chromium.org/2916673002 might target the root cause. Will verify on Monday.
,
Jun 5 2017
Confirmed https://codereview.chromium.org/2872343003 is the root cause of this regression. Confirmed https://codereview.chromium.org/2916673002 has fixed this regression.
,
Jun 5 2017
Requesting merge of https://codereview.chromium.org/2916673002.
,
Jun 6 2017
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 6 2017
I merged the fix to M60 at https://codereview.chromium.org/2926473004/. Thanks, Hadi
,
Jun 7 2017
,
Jun 8 2017
Verified it on 9592.13.0/60.0.3112.23 - Cyan, Winky
,
Jun 8 2017
,
Jun 9 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 10 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by shuchen@chromium.org
, May 31 2017Status: Assigned (was: Untriaged)