New issue
Advanced search Search tips

Issue 826583 link

Starred by 0 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

During Japanese character input, input field remains on pending state even if i modify the input value via javascript

Reported by mngabu...@gmail.com, Mar 28 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
create onKeyUp event with below logic

inputValue = this.value;
newValue = convertKatakanaToRomaji(inputValue);
this.value = newValue;

What is the expected behavior?
input field has the new value and
the pending state (attached screenshot, the underline below '1') should not be displayed

What went wrong?
before this release, if you change the value of the input field on keyup, the composition of Japanese input will be completed if input value is changed via javascript.

this release, even if you change the input value, the japanese input remains on pending state and will only be completed on press of enter key.
I wonder if this is the expected behavior of this new release

Did this work before? Yes 64.0.3282.186

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

This conversion of japanese to romaji onkeyup was implemented because chrome does not support ime-mode:disabled behavior on input fields
 

Comment 1 by mngabu...@gmail.com, Mar 28 2018

toRomaji.PNG
427 bytes View Download
Labels: Needs-Bisect Needs-Triage-M65
Labels: Triaged-ET Needs-Feedback
Tested the issue on chrome reported version 65.0.3325.181 using windows-7 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_onkeyup
2) Tried to replace the data in it with
inputValue = this.value;
newValue = convertKatakanaToRomaji(inputValue);
this.value = newValue; (as provided in comment#0)
3) On output part didn't observed anything related to the issue

@Reporter: Could you please provide sample Test file/URL that reproduces the issue which helps us in further triaging the issue in better way, any inputs from your end are most helpful.

Thanks!

Hi viswa.karala,

Thank you for your reply.

The issue only occur on IME-mode ON. Please input a double byte number(Japanese character) on below URL.
https://www.w3schools.com/code/tryit.asp?filename=FPYBOZ5XOZ8J

Sample Input:
1
12
123
(not copy-paste) 

Problem:
case '1' <-- the underline below 1 still display
case '12' or '123' <-- the previous inputs were not cleared after executing x.value = <newValue> 

Project Member

Comment 5 by sheriffbot@chromium.org, Apr 2 2018

Cc: viswa.karala@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

Components: -Blink Blink>Forms>Text
Labels: Needs-Feedback
Tested the issue on chrome reported version using Windows-7 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://www.w3schools.com/code/tryit.asp?filename=FPYBOZ5XOZ8J
2) Clicked on RUN in the opened URL and Changed the input language source to Japanese, typed '1' in the input field, seen underline for '1' and clicked on enter, then underline disappear
3) Typed '2 3', underline is seen only for '2 & 3', clicked on enter, then underline disappear
4) Again typed '1 2 3', seen underline for '1 2 3' and underline disappear after clicking Enter
Observations: Tested the issue on 64.0.3282.186, seen the same behaviour as mentioned above.

@Reporter: Please find the attached screen cast for your reference and provide your feedback on it. if possible provide the screen cast of the issue which helps us in better understanding, any further inputs on it are most helpful.

Thanks!

826583.mp4
1.5 MB View Download
Following the same steps as yours, the result in my case is different.
Please see attached clip.
826583.mp4
959 KB View Download
Project Member

Comment 9 by sheriffbot@chromium.org, Apr 4 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: susan.boorgula@chromium.org
Labels: -Needs-Bisect -Type-Bug-Regression M-67 Target-67 FoundIn-67 OS-Mac Type-Bug
Status: Untriaged (was: Unconfirmed)
mngabutan@ Thanks for the update.

Able to reproduce the issue on Windows 10 and Mac OS 10.13.3 on the latest Canary 67.0.3387.0 and Stable 65.0.3325.181 by following the given steps as per comment #7.
Unable to reproduce this issue on Ubuntu 17.10.

The issue is observed when On-screen keyboard is used and when keypad is used, the issue is not seen.
Attached is the screen cast for reference.

This is a Non-Regression issue as this behaviour is observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks..
826583.mp4
2.4 MB View Download
Components: Blink>Editing>IME UI>Input>Text>IME
Labels: -Type-Bug Needs-Bisect Type-Bug-Regression
viswa.karala@, the reporter didn't mean '1 2 3' (ASCII 1, space, ASCII 2, space, ASCII 3), but meant '123' (Three non-ASCII characters; U+FF11 U+FF12 U+FF13).

I reproduced this on Windows 10 with a physical keyboard + Google Japanese Input. Please bisect again with a physical keyboard.



Labels: -Needs-Bisect -Type-Bug-Regression Type-Bug
Able to reproduce the issue on Windows 10 and Mac OS 10.13.3 on the latest Canary 67.0.3389.0 and Stable 65.0.3325.181 with a physical keyboard.
Note: unable to reproduce the issue while entering text from Numlock keys
Unable to reproduce this issue on Ubuntu 14.04 and 17.10.

This issue is seen from M60 chrome builds and the same behaviour is observed on M64 - 64.0.3282.186 build and M65 - 65.0.3325.181 build.
Attached is the screen cast of the behaviours of the above versions for reference.

Considering this issue as Non-Regression issue as this is seen from M-60 chrome builds.(We consider M-60 as the base for Non-Regression issue).
Hence removing 'Needs-Bisect' label. Please feel free to add if further bisect is required.

Thanks..
826583-issue.mp4
2.8 MB View Download

Comment 13 by yosin@chromium.org, May 28 2018

Status: Available (was: Untriaged)

Sign in to add a comment