Type Clipboard action and VMware Web Console
This is something I've been wondering about and why it doesn't work with RDM. I've only used Edge/Chrome for VMware Web Console connections to virtual machines, and when trying to use the Type Clipboard action, it never works. If I remember correctly, I also opened a support case about this in the past.
Typically, I connect to an RDP jump box and use the VMware Web Console from there in situations where I need a direct console connection to a VM.
I think I may have found the reason why this is happening. It seems to be the same issue described here, and there may be nothing that can be done on the RDM side. Apparently, the workaround is to use Firefox or VMware Remote Console instead.
The issue is described here in the context of a different Windows application:
https://github.com/jlaundry/TypeClipboard/issues/6
All Comments (5)
Hello,
If the issue is related to VMware Remote Console, it is possible that we cannot do much about it as you suggested. But, just to make sure, have you given accessibility permissions to RDM ? Under your mac settings, privacy & security, accessibility, if RDM is not added there, no typing action will work. We have added a warning when it is turned off in some cases, but type clipboard might not have one. Please verify that the permission has been given to RDM and if not, add it and let us know if it helped.
Best regards,
Maxim Buisson
Hi
Just to be clear - is your client RDM Mac, or RDM Windows? I do understand the cause of this issue and we have a workaround on Windows. I would need to see if the same workaround is possible on macOS.
Kind regards,
Richard Markievicz
I'm using RDM Mac.
Hello
Thanks. Yes, the issue you linked is relevant. When you use "Type Clipboard" in an RDP session, RDM (Windows and Mac) sends the text to the server as Unicode characters rather than physical keypresses. For most applications these are equivalent; the server receives the characters and the application gets the text. The VMWare web console is an exception; it reads raw keyboard scan codes ("which physical key was pressed?") and ignores Unicode entirely, so nothing arrives.
RDM Windows has an optional workaround that converts each character into its matching key press(es) before sending it. On Windows we're able to lean on an API that answers "which key with which modifiers produces this character on the user's current keyboard layout?". macOS has no equivalent API. We'll have to build the mapping by inverting the active layout through Apples text APIs which only answers the question in the other direction (character from key(s)). Then we have to translate from Apple key codes into RDP (Windows) scan codes.
Actually, there are a couple of easier ways to do it, but that solution is the only one that will work for different keyboard layouts than US ANSI. For example, "@" is Shift+2 on my keyboard, but a different combination on many European ones. Another simple solution I thought of would only support alphanumeric, which is obviously not sufficient because I think a prime use case of this is automatically entering passwords.
So, yes it's a known issue and something we need to build on the Mac side. It's technically a bit challenging. I open a ticket on our side (this isn't the first time this has come up, so it can be prioritized accordingly) and we'll post back once there's some news. Hopefully my explanations shows that this, unfortunately, isn't just a straightforward change.
Let me know if something isn't clear
Kind regards,
Richard Markievicz
Hi,
Thanks a lot for such a detailed and precise explanation! It makes perfect sense now, and I really appreciate you taking the time to explain what’s happening behind the scenes and why it’s not such a straightforward change on macOS.
Great to hear that there’s now a ticket for it as well. I’ll keep an eye out for any updates.
Thanks again for looking into this and for the great explanation!