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 descriptionUserAgent: 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
,
Mar 28 2018
,
Mar 28 2018
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!
,
Apr 2 2018
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>
,
Apr 2 2018
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
,
Apr 3 2018
,
Apr 3 2018
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!
,
Apr 4 2018
Following the same steps as yours, the result in my case is different. Please see attached clip.
,
Apr 4 2018
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
,
Apr 5 2018
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..
,
Apr 6 2018
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.
,
Apr 6 2018
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..
,
May 28 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by mngabu...@gmail.com
, Mar 28 2018427 bytes
427 bytes View Download