New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 727952 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS , Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

CJK:Delete doesn't work properly when the input isn't committed on Google document/Presentation, omnibox, Findinpage

Project Member Reported by songsuk@chromium.org, May 30 2017

Issue description

Chrome 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
 
Owner: wuyingbing@chromium.org
Status: Assigned (was: Untriaged)
Yingbing, can you please take a look? Thanks.

Not reproducible in Chrome 60.0.3112.7 - Win7, Ubuntu 14.04
Summary: CJK:Delete doesn't work properly when the input isn't committed on Google document/Presentation, omnibox, Findinpage (was: Delete doesn't work properly when the input isn't committed on Google document/Presentation - CJK )
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)
comment#3 happens on 9592.3.0/60.0.3112.10 - Peppy
Cc: chongz@chromium.org
Cc: ggalante@google.com wuyingbing@chromium.org
Owner: songsuk@chromium.org
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.

Labels: Needs-Bisect
For #2, I verify it's not "keyup" issue.
I don't find the root cause now.
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.

songsuk@, we're looking for the bisect result. Thanks!
Labels: -Needs-Bisect
Owner: wuyingbing@chromium.org
Good build : chrome 60.0.3103.0/CrOS 9568.0.0 -Peppy

Bad build : Chrome 60.0.3105.0/CrOS 9569.0.0 -Peppy



@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

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

Owner: shuchen@chromium.org
Assigning to me for CL bisect.

Cc: moshayedi@chromium.org
Scanned by my eyes, suspecting https://codereview.chromium.org/2872343003.

Hadi, mind taking a look and confirm? Thanks.

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.
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.

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.

Confirmed https://codereview.chromium.org/2872343003 is the root cause of this regression.
Confirmed https://codereview.chromium.org/2916673002 has fixed this regression.

Labels: Merge-Request-60
Owner: moshayedi@chromium.org
Requesting merge of https://codereview.chromium.org/2916673002.

Project Member

Comment 21 by sheriffbot@chromium.org, Jun 6 2017

Labels: -Merge-Request-60 Hotlist-Merge-Approved Merge-Approved-60
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
I merged the fix to M60 at https://codereview.chromium.org/2926473004/.

Thanks,
Hadi
Status: Fixed (was: Assigned)
Verified it on 9592.13.0/60.0.3112.23 - Cyan, Winky
Labels: OS-iOS
Status: Verified (was: Fixed)
Project Member

Comment 26 by sheriffbot@chromium.org, 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
Labels: -Merge-Approved-60 merge-merged-3112

Sign in to add a comment