hterm: Emoji are sometimes double-width, sometimes single-width (weird cursor movement in crosh)
Reported by
anowlcal...@gmail.com,
Apr 27 2018
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS armv7l 10323.67.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.209 Safari/537.36 Platform: 10323.67.0 (Official Build) stable-channel nyan_big Steps to reproduce the problem: 1. Open a terminal. 2. Enter a (double-width) emoji like "🐍", and notice that the cursor moves two cells to the right to accommodate the width of the character. 3. Press backspace, and notice that the cursor only moves one cell to the left. 4. Insert two double-width emoji, then press backspace twice; notice that one emoji is still displayed on the screen, but is not actually there (if you press enter now, you won't get an error about 🐍 not being a valid command). What is the expected behavior? Emoji should be editable like normal text – entering an emoji then pressing backspace should not change the state of the world. What went wrong? You can get into some really weird states by entering emoji, then backspacing over them, especially if the line gets long enough that it wraps around. Did this work before? N/A Chrome version: 65.0.3325.209 Channel: stable OS Version: 10323.67.0 Flash Version: 29.0.0.113 I originally found this because I had emoji in my prompt that sometimes didn't display, but appeared when I selected any text on the screen (using tmux's mouse support, not the native selection), though I guess that's not really the same issue as this.
,
Apr 27 2018
correct behavior depends on the remote side having up-to-date unicode tables U+1f40d (🐍) is a double-width char and hterm correctly treats it as such. but if the remote side thinks it's a single-width char, then the cursor behavior you describe would happen, and there isn't much hterm can do about it. when you press backspace to delete chars and move the cursor, hterm doesn't interpret that locally ... it sends a backspace request to the remote side, and the remote has to respond to hterm telling it how many cells to move the cursor and what cells to clear. so please check the system you're connecting to first and make sure it's handling these correctly. on the system i'm connecting to, it has no problem processing U+1f40d.
,
Apr 27 2018
It's happening in plain crosh (from the ctrl-alt-T terminal accessible without enabling developer mode) as well as a crouton chroot, so it's definitely *something* in ChromeOS, but I guess it's not hterm itself then. Apologies for mislabelling the issue!
,
Apr 27 2018
in that case, it's probably because we're not building some core packages/libs with USE=unicode so it doesn't support UTF8 properly. hterm only supports UTF8, so it gets out of sync. i'll poke a crosh setup to see. |
||
►
Sign in to add a comment |
||
Comment 1 by dtapu...@chromium.org
, Apr 27 2018