New issue
Advanced search Search tips

Issue 753866 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 654839
Owner: ----
Closed: Aug 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

hterm: copy'n'paste drops a combining mark

Project Member Reported by js...@chromium.org, Aug 9 2017

Issue description

Chrome Version: 60.0.3112.90 (Official Build) (64-bit)

What steps will reproduce the problem?
(1)  Copy the following line to the paste buffer (command+C)
i̇é

(it's U+0069 U+0307 U+0065 U+0301 )
(2) In a shell on a remote machine (SecureShell session), run the following command and paste what's copied in step 1

$ iconv -t UTF-16BE | hexdump -C
i̇é
<press ctrl-d>

(3) Copy the above string now from the ssh session and repeat step 2

What is the expected result?

In both steps 2 and 3, the following is printed:

00000000  00 69 03 07 00 65 03 01  00 0a

What happens instead?

In step 2 (when the string is copied from outside the secure shell), the expected result is obtained. U+0307 and U+0301 are present. 

In step 3 (when the string is copied from the secure shell), U+0307 and U+0301 are dropped and the output is 

00000000  00 69 00 65 00 0a


 
Labels: -OS-Mac OS-All
Mergedinto: 654839
Status: Duplicate (was: Untriaged)
Summary: hterm: copy'n'paste drops a combining mark (was: copy'n'paste drops a combining mark )
fairly certain this is the same as issue 654839.  since we're splitting on codepoints, and the width of a combining character is 0, we end up dropping them from the display.

Comment 2 by js...@chromium.org, Aug 10 2017

Oh. Thanks.  we should split NOT on code point boundaries but on grapheme cluster boundaries. 

Comment 3 by vapier@chromium.org, Aug 10 2017

everyone agrees :).  the code in question is quite old and i think it's just a matter of ignorance of proper unicode parsing.  if English/ASCII works, it must be correct right ?

Sign in to add a comment