Hello,
We are currently testing a fix for the Tab key not working correctly in Visual Studio. If testing goes as expected, we are aiming to release it around the second or third week of September.
Regarding your other question, I cannot comment on how the Windows App handles keyboard input, but the behavior you described involves a relatively uncommon input-handling scenario.
Here is what happens with a chord shortcut such as Ctrl+E, C:
During a remote session, keystrokes can be sent to the remote computer in one of two ways:
As a physical key event (a scan code or virtual key), which identifies the specific key that was pressed.
As a Unicode character, which represents the resulting character but does not identify the physical key that produced it.
When you hold a modifier such as Ctrl, the keystroke must be sent as a physical key event. Therefore, Ctrl+E is sent using physical key events. However, after you release Ctrl and press C by itself, the C is sent as a Unicode character.
Visual Studio’s chord shortcuts, such as Ctrl+E, C, expect the second part of the shortcut to arrive as a physical key event. Because the standalone C arrives as a Unicode character, with no corresponding physical key information, Visual Studio does not recognize it as the second part of the chord, and nothing happens. Pressing Ctrl+C causes the C to be sent as a physical key event again, providing the key information Visual Studio is expecting and allowing the shortcut to execute.
Unfortunately, there is no reliable way for the application to know that a standalone C should be sent as a physical key event because it is intended to complete a Visual Studio chord. The only general solution would be to send every keystroke as a physical key event, which is how keyboard input was handled in earlier versions of the application.
However, that approach has an important drawback: the keyboard layout on the remote computer may differ from the layout used by the local Android keyboard. For example, if the remote computer uses a French AZERTY layout while the Android device uses a QWERTY layout, pressing Q locally could produce A remotely. This also caused several other inconsistencies. Although it was possible to configure the local keyboard layout for an RDP entry, some scenarios remained unreliable. Sending Unicode characters resolves these layout-related issues because the character entered on the Android device is the same character received by the remote computer, regardless of the remote keyboard layout.
I have performed some tests and confirmed that forcing physical key events allows these chord shortcuts to work correctly in Visual Studio. If this would be useful, we could consider reintroducing an option to force keystrokes to be sent as virtual keys while retaining our modern input-handling implementation. However, enabling it could cause the keyboard-layout and input inconsistencies described above.
Best Regards,
Frederick Simard
