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

Issue 677050 link

Starred by 5 users

Issue metadata

Status: Duplicate
Merged: issue 620549
Owner:
Last visit > 30 days ago
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression



Sign in to add a comment

compositionupdate event.data not correct

Reported by andreabo...@gmail.com, Dec 26 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce the problem:
1.  open this fiddle https://jsfiddle.net/t6jxnhdd/
2.  switch to japanese ime input
3. input in fiddle textarea `nonono`

What is the expected behavior?
The composition update event should report the data property populated with the string we are compositing that should be:

- n
- の
- のn
- のの
- ののn
- ののの

insead we get just the first sillabe の  on the data property.

What went wrong?
we get just the first sillabe の  on the data property.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 55.0.2883.95  Channel: stable
OS Version: OS X 10.12.2
Flash Version: Shockwave Flash 24.0 r0
 
I just downloaded chrome 48 and verified that it was working fine before.
Current firefox and internet explorer works fine too.
Cc: kkaluri@chromium.org
Labels: Needs-Feedback
Tested this issue with mentioned steps in comment #0 on Mac 10.12.2 with chrome version #55.0.2883.95 and Firefox version #50.1.0.

Observed same  behavior in both chrome and firefox, on typing "nonono" in the text field it displayed "ノノノ"

Please look into the attached screen-cast and let us know your observations
Issue 677050.mp4
1.0 MB View Download
just to be clear the visual output is correct. the event.data is not. as you can see there are first 1 then 2 then 3 kangi underlined in the textarea and this should be mirrored in event data as it was before in chrome48. in firefox is still like this amd also safari and ie.

Comment 4 by dev.d...@gmail.com, Dec 29 2016

Hi,

I also have this issue.
I created a new jsfiddle in order to show the behavior without the dev console. https://jsfiddle.net/w83ofuta/

It works fine with the version  54.0.2840.71. It doesn't work with the version 55.0.2883.87 

It seems that data field of the update event only keep the last character typed during the composition.

In the version 54, we had all the text involved in the composition(from the compositionstart event).

I hope, it will help.

Comment 5 by dev.d...@gmail.com, Dec 29 2016

This issue also exist on Windows and Linux
kkaluri you have to look at the dev console to view the composition data to see the difference. Compare the screenshots of firefox and chrome attached. The composition data on FF looks correct.
Firefox - composition.png
333 KB View Download
chrome - composition.png
173 KB View Download
Cc: dtapu...@chromium.org yosin@chromium.org chongz@chromium.org
Components: Blink>Editing
Labels: -Type-Bug -Needs-Feedback Needs-Bisect Type-Bug-Regression
Per #1/#4 this is reported to be a regression in Chrome 55.  Any chance we can get a bisect?

dtapuska/chongz: is this Blink>Input or Blink>Editing?
Components: -Blink>Input
Labels: Hotlist-Input-Dev
Owner: chongz@chromium.org
Status: Assigned (was: Unconfirmed)
Cc: aelias@chromium.org yabinh@chromium.org
Components: -Blink>Editing Blink>Editing>IME
Labels: -Needs-Bisect -OS-Mac OS-All
Mergedinto: 620549
Owner: yabinh@chromium.org
Status: Duplicate (was: Assigned)
This issue was introduced in M55 and fixed in M57 (e.g. Current Canary).
Also see  https://crbug.com/620549#c22 

Sign in to add a comment