RenderText: Cursor placement and movement broken for obscured emoji. |
||||
Issue descriptionRenderText: Cursor placement and movement broken for obscured emoji. What steps will reproduce the problem? (1) Copy the camera emoji char: '
,
Jun 24 2016
,
Jun 26 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 22 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by msw@chromium.org
, Jun 21 2016It seems like the bug tracker can't handle emoji characters in the message above. Here's the original description without the camera char: RenderText: Cursor placement and movement broken for obscured emoji. What steps will reproduce the problem? (1) Copy the camera emoji char: (omitted for bug tracker defect) http://www.fileformat.info/info/unicode/char/1f4f7/index.htm (2) Type in a Views password/obscured textfield (eg. Views Examples, http auth dialog) https://www.httpwatch.com/httpgallery/authentication/ (2) Paste numerous copies of the character; you'll see asterisk chars '*' instead. (3) Observe the cursor position; move the cursor back and forth over the chars. Expected: Cursor moves by one asterisk '*' char at a time; pasting at end keeps cursor at end. Actual: Cursor moves by multiple asterisk '*' chars at a time; pasting at end moves cursor to mid-string. Issue 606009 fixed a crash when itemizing obscured emoji chars. There's some bad index logic elsewhere in RenderText for obscured emoji, etc. (likely something is using display indices when it should use layout/text indices)