hterm: AltGr+2 does not work with pt_PT layout if open as window |
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Open hterm as window, change the keyboard layout to pt_PT and press AltGr+2 What is the expected behavior? Should write the @ sign. What went wrong? Didn't write anything WebStore page: https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo Did this work before? N/A Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version: Initially reported as issue 727906 , which was closed as duplicate of issue 211925 . However, in version 0.8.36.8 this still happens.
,
Dec 19 2017
what OS are you using exactly ? this seems to work just fine for me in CrOS. when you say "pt_PT", i'm guessing you mean "the Portuguese QWERTY keyboard layout as used in Portugal": https://en.wikipedia.org/wiki/QWERTY#Portugal this is working fine for me in CrOS. i select the "Portuguese keyboard" there (which lines up with the layout listed in wikipedia above), open a new Secure Shell window, and then press AltGr+2 and i get back @.
,
Dec 19 2017
Windows 10, Chrome Version 63.0.3239.84 (Official Build) (64-bit), Secure Shell version 0.8.40.1.
Keyboad is that one. This is 100% reproducible. In fact, just tried now the Alt-Gr combinations don't produce the expected output, if they produce output at all. For example:
AltGr+ | Standard | Shell-in-Tab | Shell-in-window
1 | (nothing) | (nothing) | 1
2 | @ | @ | ^@
3 | £ | £ | ^[
4 | § | § | ^\
5 | € | € | ^]
6 | (nothing) | (nothing) | ^^
7 | { | { | ^_
8 | [ | [ | ^H (backspace)
9 | ] | ] | 9
0 | } | (nothing) | (nothing)
,
Dec 19 2017
When I wrote ^H, I meant ^?. It seems hterm is sending control characters.
,
Dec 19 2017
this looks like a bug in Chrome's handling of AltGr keys inside of "apps", and might be outside the control of Secure Shell. on the other hand, apps are deprecated/dead on Windows, so no one cares how well they work. this might "fix" itself when the Secure Shell Extension variant launches.
,
Dec 19 2017
Except for the fact that this is the only way we can SSH in corp from a gWindows machine... are you sure that this is a no one cares scenario?
,
Dec 19 2017
BTW, AltGr+0 also doesn't work even in in-tab mode.
,
Dec 19 2017
from Chrome's pov, yes, no one cares about Chrome Apps on Windows. that's why we're launching an Extension version of Secure Shell in 2018Q1. also, i'm fairly certain the Chrome Secure Shell app is not the only way you can do corp ssh. http://go/corpssh-faq talks about putty/cmdline ssh too.
,
Dec 19 2017
I can wait 2018 Q1 with in-tab shells. Putty is way worse...
,
Dec 20 2017
you can star b/31225897 for updates and then redo your tests when it's ready and let me know how it goes. i tried getting a windows vm in the past and it didn't really work out, so maybe i'll have to request a windows laptop or something :/.
,
Dec 20
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. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 Deleted