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

Issue 829224 link

Starred by 4 users
Status: Duplicate
Merged: issue 826615
Owner:
█ rlanday@chromium.org
Last visit > 30 days ago
Closed: Apr 2018
Cc:
susan.boorgula@chromium.org
editing-dev@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

contenteditable inserts first character before IME kicks in

Reported by jhro...@atlassian.com, Apr 5 2018 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Example URL:
https://jsfiddle.net/jirka/y4Lfmh4j/14/

Steps to reproduce the problem:
1. Use Chrome 65
2. Set keyboard to Hiragana (Japanese)
3. Place cursor in the 2rd cell now (the preceding cell is not empty)
4. Type two characters: k + i
5. Result: IME enters k and い into the cell (NOT expected)

What is the expected behavior?
3a. Place cursor in the 3rd cell (the preceding cell is empty)
4a. Type two characters: k + i
5a. Result: IME enters き into the cell (expected)

What went wrong?
The first character inputs into the document. It should wait for IME.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? N/A 

Did this work before? Yes 64

Does this work in other browsers? Yes

Chrome version: 65.0.3325.181  Channel: stable
OS Version: OS X 10.13.4
Flash Version: 

Only happens in table, not in the first cell in a row, not if the preceding cell is empty.
This did not happen in Chrome 64.
Happens in OSX, Windows. Haven't tested Linux.
screencast 2018-04-05 15-34-46.gif
7.4 MB View Download

Comment 1 by krajshree@chromium.org, Apr 5 2018

Labels: Needs-Bisect Needs-Triage-M65

Comment 2 by jjang...@gmail.com, Apr 6 2018 

I have a same problem.
201804061022.png
239 KB View Download

Comment 3 by rsesek@chromium.org, Apr 6 2018

Components: Blink>Editing

Comment 5 by susan.boorgula@chromium.org, Apr 6 2018

Cc: susan.boorgula@chromium.org
Labels: -Pri-2 -Type-Compat -Needs-Bisect ReleaseBlock-Stable Triaged-ET RegressedIn-65 M-66 FoundIn-66 Target-66 Target-65 FoundIn-65 hasbisect OS-Windows Pri-1 Type-Bug-Regression
Owner: rlanday@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Mac OS 10.12.6 and Windows 10 on the reported version 65.0.3325.181 and the latest Beta 66.0.3359.81 and the issue is fixed on the latest Canary 67.0.3389.0
Note: Unable to reproduce the issue on Ubuntu 14.04.

Reverse Bisect Info:
=====================
Good Build: 67.0.3387.0
Bad Build : 67.0.3386.0

On executing the per-revision bisect build, all good builds are getting invoked. Hence providing the manual changelog URL from omahaproxy.
https://chromium.googlesource.com/chromium/src/+log/67.0.3386.0..67.0.3387.0?pretty=fuller&n=10000

From the above CL, suspecting the below change
Reviewed on: https://chromium-review.googlesource.com/987385

rlanday@ Please check and confirm if this issue is related to your change, else help us in re-assigning.

Adding ReleaseBlock-Stable as it is a recent regression. Please feel free to remove if it is not applicable.

Thanks!

Comment 6 by rlanday@chromium.org, Apr 6 2018

Mergedinto: 826615
Status: Duplicate (was: Assigned)
This is a duplicate of  crbug.com/826615 . Will be fixed in M67. I think it's too late to merge into M66 since it's not a new issue in that release.

Comment 7 by vnt...@gmail.com, Apr 10 2018 

Please fix this issue asap

Comment 8 by rlanday@chromium.org, Apr 11 2018 

It will be fixed in Chrome 67, targeted for release around May 29. We're releasing 66 next week but we can't include this fix because there's not enough time for testing.
►

Sign in to add a comment