Wide characters not displaying on OS X and Windows

[LeftyBC]

On my OS X Mavericks machine, connecting to a remote machine via Mosh extension (0.2.0.20, precompiled version from the Chrome App Store) produces corrupted output.

Attaching to tmux produces a blank screen, and curses-based apps fail to draw correctly on the screen. I initially thought it was my relatively fancy bash PS1 prompt, but setting PS1 to \u@\h \w \$ still produced issues.

Attached is a screenshot of running man set on the remote machine via Mosh.

Connecting to the same machine using the same version of the extension from the app store on a Linux machine works flawlessly, so I believe this may be limited to OS X.

[rpwoodbu]

Interesting. Can you also include what version of Chrome and Mac OS you're running? I'll see if I can get my hands on a Mac and reproduce this.

Also, is this problem new with v0.2.0.20? That was released last last night.

[LeftyBC]

I'm new to this extension as of 0.2.0.20, so I don't have a point of comparison currently. That's the version I get from the chrome store.

Currently running:

• Mac OS X 10.9.1
• Chrome v 32.0.1700.102

[LeftyBC]

Restarted Chrome and it updated itself to 32.0.1700.107 - same issue, however.

[rpwoodbu]

I am able to reproduce this on Max OS 10.8.5 using Chrome 32.0.1700.107. It seems only to happen when there are Unicode characters on the screen, such as when running tmux with a divided window, or apparently even bringing up a man page. I suspect curses-based apps are also using Unicode characters to draw borders.

@LeftyBC, can you try running one of these programs while disabling Unicode support and see if they display "correctly" for you (some characters will be replaced with ugly versions, perhaps). E.g,:

$ LANG=en_US tmux
$ LANG=en_US man locale

(Salt to taste based on your locale.)

For my reference: Secure Shell, which also uses hterm, doesn't seem to have this problem. But it is probably using glibc and locale data generated by locale-gen or equiv., whereas I'm using newlib and the built-in en_US.UTF-8. Nonetheless, I should check what version of hterm I'm using.

[LeftyBC]

Confirmed, both tmux and man locale display properly when setting en_US as the locale.

Tmux appears to use "qqqqq" as the line-drawing characters as expected.

I do have a unicode character in my PS1 on that machine - so it'd look something like:

❖ [colin@lucy] ~ $

[rpwoodbu]

I have learned that I'm using the wrong (read: old) source for hterm. I should try the new location (I understand it is on GitHub somewhere), and see if that resolves the issue.

[rpwoodbu]

I tried updating hterm to the latest version (in SHA 3382cbe), but the problem persists. Investigation continues.

[LeftyBC]

Any testing you need me to do, let me know - I've got a couple of Macs, a couple of Windows boxes, and a linux machine or two kicking around.

[rpwoodbu]

@LeftyBC Cool, thanks. See if you can reproduce this running Mosh for Chrome on Windows. Also confirm that if you run the upstream "mosh" program in Terminal on the Mac that you cannot reproduce this (I am borrowing a Mac to test, and don't want to install any new software on it).

[LeftyBC]

Left side is native OSX mosh, right side is mosh-chrome. Both connecting to the same machine then running man locale. Weechat/irssi have the same behaviour - works on native, not in chrome.

Interestingly, I have the same problem now on my Windows box - mosh via cygwin works fine, but via Chrome it's broken. I can upload a screenshot of that if you need it.

[rpwoodbu]

Interesting that Mosh for Chrome is broken for you on Windows. I can't repo this on Linux or Chrome OS; can you repo on Linux, per chance?

Also, compare the output of the "locale" command when connecting with the upstream Mosh vs. connecting with Mosh for Chrome, and make sure that they're both using UTF-8.

[jpwoodbu]

This screenshot is running mosh-chrome 0.2.3.24 on Windows 7. I have a tmux window split into three panes. Note that the border lines are not being drawn.

[rpwoodbu]

OK, looks like this is a wider issue than just Mac OS. Updated the description.

[rpwoodbu]

Fixed in SHA e1163cf.

Whew! This one took some sleuthing. There's a bug in NaCl: The $LANG variable is missing from the environment on Mac (and probably Windows, but unverified). That upsets ncurses. I'll bring this up with the NaCl folks; the environment really must be the same across platforms for portability.

[LeftyBC]

Thanks for pushing through and getting this one squashed!