No ctrl character passthrough in the Web Client

[AKostur]

OK, ran into another web client problem this morning.  Ctrl-C isn't being passed through to the VM when using the web client's console application.   Tried Ctrl-C, Ctrl-Z, and Ctrl-D (to invoke the usual Linux behaviours with those keystrokes) and the VM doesn't react at all.  Typing normal characters works, so the keyboard is being appropriately trapped by the VM, but no ctrl characters.    Running Chrome on Mac OS X, vCenter 5.5.  What magic is required to get the ctrl characters working again?

[codecrank]

Same problem here, vCenter 5.5.  Linux Chrome 30 + bundled Flash 11.9 r900 .

[eric20817]

Also having this issue in Chrome on OSX.  Makes the console basically useless. 

How can we escalate to VMWare support?

-Eric

[eric20817]

Found out that this seems to be related to Chrome and Safari.  It works on Firefox 24.0 on OSX. 

On Safari, it doesn't even open the pop-up window unless you turn the pop-up blocker off.  And even then, you can't send control characters.

Not sure what the difference in how each browser instantiates the VMWare console on OSX but there is definitely something up there.

-Eric

[vreihen]

My guess would be that this is a WebKit problem, since it is used as the rendering engine for both Safari and Chrome.

Has anybody found a fix yet that doesn't involve Firefox on OS-X?  This is *uber* annoying, as we are sooooooooo close to having a useable VMware management app on the Mac after waiting forever and a day.....

[hardersen]

This is very painful, can't be that hard to fix.

[athomas24]

Bump.

Same problem.

[ActionJack]

Same problem on Mavericks running Chrome Version 34.0.1847.116 using vCloud Director 5.5

[Bleeder]

Perhaps related, but Ctrl-select of multiple objects (VM guests, for example) does not seem to work either.

[dbaker57]

Bump!

[jnielsenmygn]

Bump.

The absurd part is that flash was used at all. Its been known to be an ultimate dead end for a good five or more years. Should have just used at most dynamic HTML for the interface and then a separate application for the console such as Java, even as much as I hate Java, at least its alive and well. NX libraries are GPL and work wonders at providing full access to consoles, desktops etc. Probably the best move they could make would be using the likes of it as opposed to reinventing the proprietary single platform wheel.  Hopefully HTML5 total migration is slated and soon to occur.

[CPollati]

If you have the Keyboard Viewer open and the console window is open, you can click the ctrl key in the Keyboard Viewer and then type C. This should register as ^C in the console. At least it did for me in Chrome with vCloud Director 5.5.

I have System Preferences -> Keyboard -> "Show Keyboard & Character Viewers in menu bar" checked, for just such an emergency.

[Kristofer Nurmia]

Thanks for the work around. Was running ping on a linux VM and wasn't able to cancel the ping because of this "feature".

Kris

[jnielsenmygn]

Can you give details on:

"If you have the Keyboard Viewer open and the console window is open"

Have been trying for two hours to figure out what this Keyboard Viewer is and where it is at. Nothing in chrome, no extensions, nothing in vcenter, nothing in the vcenter console. I have even tried using virtual keyboard extensions in chrome with no success because they refuse to run when the vcenter console is running.

[zyxxel]

What is this magical Keyboard Viewer?

Something run in the virtual machine, assuming the virtual machine is in a GUI?

Something you have in your host OS?

Something you have in your browser?

Yesterday I had to send ctrl-alt-del to the poor virtual machine since I couldn't break the ping command.

Today, it seems to be time for the same treatment - can't ssh in and kill the process until I have correctly configured the network inside the vm.

The screen keyboard in Windows does not manage to send in any Ctrl-C.

And another interesting thing is that my virtual machine is running with swedish keyboard. But I get totally garbled keyboard if my PC runs with Swedish keyboard. To get correct keys, I have to switch to US keyboard - then VMwares "magic" will remap the key codes so a key with a swedish character will have my Windows machine produce a "US key" that will then be remapped into a Swedish character inside the virtual machine. While if I connect to a virtual machine using ssh, I can keep the local keyboard language setting the same as in the virtual machine. All very logical. Seems like VMware is not picking up key codes from Windows but instead picking up pre-converted characters. Then guessing - without knowing language  what key code that just _might_ have been. And then feeding that into the virtual machine. And that conversion chain just does not care about control characters.

[IamTHEvilONE]

I'm also looking into this as well.  What I need to know is the versions of the following:

1. Browser Version, and what OS are you using it from

2. What is your keyboard locale in the OS (please try US English if you are using a different locale)

3. What VMware Product and version/build is the console from (vRA / vCD / vCenter web client)

As a side note: the HTML5 Console, aka webmks, is more like VNC then the classic 'VMRC' you might be use to.

If you are on the more current versions of vCenter, you can install the Standalone VMRC and then open the VM console there.  This will provide your more traditional 'capture' of the mouse cursor.  I know the Windows and OSX standalone versions are available, not so sure about Linux.

http://www.virtuallyghetto.com/2015/04/standalone-vmrc-now-available-for-mac-os-x.html

[vreihen]

Talk about coincidence!  I was just going to come update this thread when I received a notice about the above post.

I upgraded our vSphere Server Appliance from 5.5 to 6.0 yesterday. VCSA 6.0's web client appears to be working in Chrome on OS-X now!  Even better, each VM's summary tab now includes links to "Download Remote Console" and "Launch Remote console" to open a separate window using VMware Remote Console (VMRC).  There are now VMRC installers available for Windows and OS-X, with Linux in the works according to the download site.  Long story short, I can actually use my desktop Mac for VMware stuff now without having to fall back to Windows...

[carini]

Apparently no, only

"VMware is currently working on a standalone VMware Remote Console for Linux. Linux users can also use VMware Workstation 11 or VMware Player 7 to launch VMRC for Linux operating systems." (VMware KB 2091284), I'll try in the next days

[IamTHEvilONE]

Unfortunately not all products can leverage the standalone, and not all users are allowed to install something.

In the case of the HTML5 based consoles, I don't expect ctrl+c to be passed.  In vRealize Automation 6.2.2, there is a button on the console page to pass the crtl+c action into the guest operating system.  The HTML5 console will cover 95+% of actions in a VNC style connection.

A leading reason we had to move away from the 'classic' VMRC to the new VMRC Standalone, is because the code relied on NPAPI.  NPAPI is being deprecated to the point of being disabled/removed from Chrome/FF now.

[darperson]

If anyone is still interested, I got around the Ctrl-X problem by pressing F2.  I assume other function keys will perform other functions...

[Unspoken]

I can confirm that this issue is still not fixed in ESXi 6.5 under Firefox. I am hitting Control + W and this is closing by firefox tab.

Web client is an absolute piece of crap...

Regs.

[shobbs]

I have the same problem with InterSystems Caché running under Windows 7 under Fusion 8.5.3 running on my Mac.  However, my friend down the hall with a similar configuration does not have the problem.  The major difference is that I run Cygwin on my Windows system to give me Unix capabilities so I can run bash scripts on Windows.  The lack of Ctrl-C pass through occurs in an InterSystems supplied Windows console application that provides terminal access to Caché.  If I directly connect to a Caché job from a cmd.exe window I get the same behavior where the Ctrl-C is not passed through to the running application but instead cmd.exe sees the ctrl-C and terminates my applicaition.

The reason why I suspect Cygwin is involved is that if I run a Caché session from a Cygwin bash shell window then things are much worse.  The Caché csession application is not getting Ctrl-C passed through so that bash kills the application if a ctrl-C is typed but now the of the graphic characters that I type seem not to be recognized.  The prompt string is correctly printed in the Cygwin bash window but after that if I type a command line followed by a return then that command is just echoed back in the bash window but it is not executed by the Caché application.

Are any of the other people with this Ctrl-C problem using Cygwin on the Windows system?

[vish_ux]

Even in 2018 I am facing this issue.  Still not fixed. Web-client is nothing but absolute crap.