Secure shell cursor issue

[李常坤]

OS: win10.0.14393  Build 14393

Chrome Version: 58.0.3029.110 (64-bit)

 

The cursor always cover the last letter, there are no case like this on the other computers.

 

 

How can I handle the issues ?

 

Thank you

[Mike Frysinger]

i'm guessing it's because of your prompt.  what is your PS1 set to ?  can you copy & paste the actual content rather than take a picture ?

-mike

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/81c942f6d5f94c989d8760fd3e977578%40HQMB03.intra.legendsec.com.

[李常坤]

Welcome to Secure Shell version 0.8.36.3.

Answers to Frequently Asked Questions: https://goo.gl/muppJj (ctrl+click on links to open)

 

[Pro Tip] Use 'Open as Window' to keep Control-W from closing your terminal!

[Pro Tip] See https://goo.gl/muppJj for more information.

 

正在连接 xxxxxx，端口为 22...

Loading NaCl plugin... done.

xxxxxxxx's password:

Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-83-generic x86_64)

 

* Documentation:  https://help.ubuntu.com

* Management:     https://landscape.canonical.com

* Support:        https://ubuntu.com/advantage

 

0 packages can be updated.

0 updates are security updates.

 

Last login: Mon Jul  3 14:28:03 2017 from 127.0.0.1

➜  ~ echo $PS1

${ret_status} %{$fg[cyan]%}%c%{$reset_color%} $(git_prompt_info)

➜  ~

 

 

发件人: vap...@google.com [mailto:vap...@google.com] 代表 Mike Frysinger
发送时间: 2017年6月2日 22:41
收件人: 李常坤 <licha...@b.360.cn>
抄送: chromiu...@chromium.org
主题: Re: [chromium-hterm] Secure shell cursor issue

[Mike Frysinger]

you'll need to quote "$PS1".  alternatively, run:

declare -p PS1

what shell are you using ?  bash ?

-mike

[李常坤]

The remote target shell is zsh.

I have two Computers, one(surface pro 4) is ok, the other one (PC) doesn’t work fine, when I connect the same remote target by secure shell on chrome.

 

The below is what you need:

 

Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-83-generic x86_64)

 

* Documentation:  https://help.ubuntu.com

* Management:     https://landscape.canonical.com

* Support:        https://ubuntu.com/advantage

 

0 packages can be updated.

0 updates are security updates.

 

Last login: Mon Jul  3 21:39:55 2017 from 127.0.0.1

➜  ~ declare -p PS1

typeset PS1='${ret_status} %{$fg[cyan]%}%c%{$reset_color%} $(git_prompt_info)'

➜  ~

 

 

发件人: vap...@google.com [mailto:vap...@google.com] 代表 Mike Frysinger

发送时间: 2017年7月3日 23:52

收件人: 李常坤 <licha...@b.360.cn>
抄送: chromiu...@chromium.org

主题: Re: 答复: [chromium-hterm] Secure shell cursor issue

[Mike Frysinger]

i'm guessing it's related to the ➜ in your prompt.  it seems to feature more prominently than in my hterm.  have you changed the fonts from the defaults ?  if so, what if you use the default set of fonts instead ?

-mike

[李常坤]

When I change shell from zsh to bash, It works fine. I think the key is :➜

Thank you, very much !!

 

 

发件人: vap...@google.com [mailto:vap...@google.com] 代表 Mike Frysinger

发送时间: 2017年7月4日 10:23

收件人: 李常坤 <licha...@b.360.cn>
抄送: chromiu...@chromium.org

主题: Re: 答复: 答复: [chromium-hterm] Secure shell cursor issue

[Zhulduz Zhankenova]

I have the same issue, I use fishshell.

[c...@0x1.net]

This occurs with fonts with glyphs that are wider than their defined width, most notably affecting "powerline" symbols. hterm only appears to position the cursor based on fixed character width.

[Mike Frysinger]

yes, bad fonts are bad.  claiming to be monospace and then including glyphs that are not monospace is the definition of dumb.

i did some poc work this weekend to deal with this and it seems to work.  i use a canvas element to get the width of a single glyph and then detect when it's too wide or narrow, and then stuff the character in a span that forces it to the correct width.  i couldn't quite get the glyph to center though when the content is wider than the box, although i might land a version that lacks that feature ahead of time.

you can star https://crbug.com/737454 for updates.

-mike

On Mon, Jul 31, 2017 at 11:11 AM, cjp via chromium-hterm <chromiu...@chromium.org> wrote:

This occurs with fonts with glyphs that are wider than their defined width, most notably affecting "powerline" symbols. hterm only appears to position the cursor based on fixed character width.

--

You received this message because you are subscribed to the Google Groups "chromium-hterm" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/bdcecc0b-86f9-4e60-aeb0-334030ebb3bf%40chromium.org.

[Robert Ginda]

I think it may be worth some time experimenting with a different screen implementation that uses a single DOM element for each character cell.  It would probably be slower for bulk operations without text attributes (like `cat /var/log/messages`), but I've never benchmarked it.  It may be worth the time to hack something together for measurement purposes.  If the performance is still acceptable, we could kill the not-monospace-font bugs dead, and probably improve fullscreen app performance.

Rob.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CAAbOScm5fSZS%2Bz8Z86zWLuVywG85j6BfvQk%3DB2Ym4_ygRMsaiQ%40mail.gmail.com.

[Mike Frysinger]

the way i'm doing it atm is extending the current wc-node implementation.  since hterm.TextAttributes.splitWidecharString already walks every codepoint, i add a check (after the optimize-for-ascii part) that looks at the width and if it's outside of an epsilon (i'm going with 0.5px atm), it sticks it into a narrow-node span which forces the width to the calculated char width.  (i'm not addressing the fundamental problem of we want to split on graphemes, not codepoints, as that's a preexisting problem.)

there isn't a perf hit in the common case (all ASCII), and the hit otherwise isn't large ... even in a pathological case of displaying the first 4k codepoints in a single screen.  only a small percentage fall outside the char width normally.

the issue is the one time cost for building up the table of widths based on the font selection.  it takes about 500ms on my X1 carbon to process ~12k glyphs, and we have to do that every time the fonts change.  when Secure Shell loads, it ends up changing the set of fonts 3 or 4 times which means ~2sec delay :).  so i'm looking at:

- building the cache on demand which shouldn't be too hard (and then there is only a one-time hit everytime we see a new codepoint)

- maintaining the cache in local storage so it persists across runs ... this is a bit more difficult for two reasons

  - we don't want it in sync storage (since the exact fallback fonts used are diff between OS's) and hterm only has a single backing store atm (so i need to plumb it out)

  - figuring out how to package these elements so they don't take up a ton of space.  while the app asks for unlimitedStorage, we still want it to work on web platforms if possible.  JSON stringifying on a non-sparse array doubles the size (100k elements -> 200k bytes), and we'll have a diff entry for each font set.  in the vast majority of cases, we'll only have one fontset, and most people aren't displaying all possible codepoints in Unicode, so an initial naive implementation of storing as a hashmap on demand is probably fine.

-mike

[Robert Ginda]

On Mon, Jul 31, 2017 at 12:15 PM, Mike Frysinger <vap...@chromium.org> wrote:

the way i'm doing it atm is extending the current wc-node implementation.  since hterm.TextAttributes.splitWidecharString already walks every codepoint, i add a check (after the optimize-for-ascii part) that looks at the width and if it's outside of an epsilon (i'm going with 0.5px atm), it sticks it into a narrow-node span which forces the width to the calculated char width.  (i'm not addressing the fundamental problem of we want to split on graphemes, not codepoints, as that's a preexisting problem.)

Interesting.  Certainly sounds like less work than rewriting the existing screen code.

 

there isn't a perf hit in the common case (all ASCII), and the hit otherwise isn't large ... even in a pathological case of displaying the first 4k codepoints in a single screen.  only a small percentage fall outside the char width normally.

the issue is the one time cost for building up the table of widths based on the font selection.  it takes about 500ms on my X1 carbon to process ~12k glyphs, and we have to do that every time the fonts change.  when Secure Shell loads, it ends up changing the set of fonts 3 or 4 times which means ~2sec delay :).  so i'm looking at:

- building the cache on demand which shouldn't be too hard (and then there is only a one-time hit everytime we see a new codepoint)

- maintaining the cache in local storage so it persists across runs ... this is a bit more difficult for two reasons

  - we don't want it in sync storage (since the exact fallback fonts used are diff between OS's) and hterm only has a single backing store atm (so i need to plumb it out)

The fallback fonts could even change on a single machine, if they are installed or removed.

[Mike Frysinger]

On Mon, Jul 31, 2017 at 4:08 PM, Robert Ginda <rgi...@chromium.org> wrote:

On Mon, Jul 31, 2017 at 12:15 PM, Mike Frysinger <vap...@chromium.org> wrote:

the way i'm doing it atm is extending the current wc-node implementation.  since hterm.TextAttributes.splitWidecharString already walks every codepoint, i add a check (after the optimize-for-ascii part) that looks at the width and if it's outside of an epsilon (i'm going with 0.5px atm), it sticks it into a narrow-node span which forces the width to the calculated char width.  (i'm not addressing the fundamental problem of we want to split on graphemes, not codepoints, as that's a preexisting problem.)

Interesting.  Certainly sounds like less work than rewriting the existing screen code.

 

there isn't a perf hit in the common case (all ASCII), and the hit otherwise isn't large ... even in a pathological case of displaying the first 4k codepoints in a single screen.  only a small percentage fall outside the char width normally.

the issue is the one time cost for building up the table of widths based on the font selection.  it takes about 500ms on my X1 carbon to process ~12k glyphs, and we have to do that every time the fonts change.  when Secure Shell loads, it ends up changing the set of fonts 3 or 4 times which means ~2sec delay :).  so i'm looking at:

- building the cache on demand which shouldn't be too hard (and then there is only a one-time hit everytime we see a new codepoint)

- maintaining the cache in local storage so it persists across runs ... this is a bit more difficult for two reasons

  - we don't want it in sync storage (since the exact fallback fonts used are diff between OS's) and hterm only has a single backing store atm (so i need to plumb it out)

The fallback fonts could even change on a single machine, if they are installed or removed.

right ... i was hoping to avoid dealing with that.  i guess if i throw out the persistent caching mechanism entirely, it makes the rest of the code simpler.  i'll do some perf analysis and see if the ondemand route is that problematic even in the pessimistic scenario.  testing a single glyph takes <0.1ms which would be a one-off-per-non-ASCII-codepoint cost.

-mike

[Robert Ginda]

Have our scientists invented an API to figure out which font was actually selected?

[Mike Frysinger]

Google says no.  the Chrome JS console has a way of showing the provenance of glyphs -- in the Element browser, select "Computed" on the right and scroll down and it'll tell you which fonts are being used for how many glyphs.  but that's the closest i've gotten.

if we're being pessimistic, a font could update and change the rendering for any of the active glyphs.  the name wouldn't change, and i don't think there's any unique info we could get out of the system (like a version, but that assumes people would change it).  there isn't a way i've seen to be given the font source directly so we could hash it, but i don't really want to go down the rabbit hole of parsing font files :(.

font changes might not be a big deal with local fonts, but if people are employing webfonts, inplace updates seem even more likely.  i guess i've talked myself out of maintaining a persistent cache (at least for now) :/.

-mike

[cellcore...@gmail.com]

Exactly, you nailed it :o)

I also had a lot of trouble to set up Powerline on iTerm2 and also oh-my-zsh and just recently bought a Chromebook and I had the same issue again.

SOLUTION:

Use the right fonts -> https://github.com/wernight/powerline-web-fonts

No Problem with hterm or iTerm or any other terminal emulator.

Use one of those fonts with zsh and you will be happy :o)

Cheers guys.