Host.ChoiceDescription need additional keypress for choosing option

[MrFly72]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

When using System.Management.Automation.Host.ChoiceDescription in VSCode terminal, I have to press the key two times. First keypress will not be shown. The keypress will even be delivered to the next entry line and cloak it at the front.
It works in PSextension v2021.12.0 but NOT in current preview.

PowerShell Version

Name                           Value
----                           -----
PSVersion                      5.1.19041.1320
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1320
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Visual Studio Code Version

1.65.2
c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1
x64

Extension Version

ms-vscode.powershell@2021.12.0       
ms-vscode.powershell-preview@2022.3.0
tobysmith568.run-in-powershell@1.1.1

Steps to Reproduce

Use this code:

    $AvailableEnvironments = @(
        @{Choice = '&IAT'; Value = "IAT"; Help = "Test" }
        @{Choice = '&Prod'; Value = "Prod"; Help = "Production" }
        @{Choice = '&Dev'; Value = "Dev"; Help = "Development" }
    )
    $title = "Please choose the environment"
    $msg = "Which environment do you want to use ?"
    $Choices = foreach ($Choice in $AvailableEnvironments) {
        New-Object System.Management.Automation.Host.ChoiceDescription $Choice.Choice, $Choice.Help
    }
    $options = $Choices
    $default = 0  # 0=Yes, 1=No
    $response = $Host.UI.PromptForChoice($title, $msg, $options, $default)
    $MainEnvironment = $AvailableEnvironments[$response].Value
    $MainEnvironment

Visuals

Pressed "P" as an answer and then hit enter like expected.
Behaviour: Default value will be used instead and the "P" will end up in the input-line:

Logs

No response

[andyleejordan]

Ah ha, this one repros. Curiously enough, only when run via F5. After everything is defined, executing the script with . repro.ps or manually pasting $response = $Host.UI.PromptForChoice($title, $msg, $options, $default) works just fine.

[andyleejordan]

Curious, @SeeminglyScience, making the change:

        public override int PromptForChoice(string caption, string message, Collection<ChoiceDescription> choices, int defaultChoice)
        {
            // return _consoleHostUI is not null
            //     ? _consoleHostUI.PromptForChoice(caption, message, choices, defaultChoice)
            //     : _underlyingHostUI.PromptForChoice(caption, message, choices, defaultChoice);
            return _underlyingHostUI.PromptForChoice(caption, message, choices, defaultChoice);
        }

Seems to resolve this...when are we supposed to use _consoleHostUI?

That change did not resolve this, it was just difficult to repro as I wasn't quite following that it's a double-press bug.

[andyleejordan]

@MrFly72 Can you test the build I just posted in this comment: #3876 (comment)? Throw the UI through everything you can.

[MrFly72]

@andschwa Still the same problem on F5/F8, dropping my entry and presenting it later on in the normal prompt. Choosing the Default instead of the letter pressed (which is even the worst in this)
There is a difference between F5 and F8:
F5 will take the default, will not print the letter I pressed AND will not show the letter in the prompt....
F8 will take the default, will not print the letter I pressed BUT will put the letter I pressed in the following PS-Entryline
In both cases pressing the letter two times then chooses the choice of the letter, eg. type "pp". The behaviour for the letter to show up is the same as above, the letter will also only show up once in F8-case (not two times, how someone might expect)

[andyleejordan]

Ah ha...ok so this doesn't repro at all on macOS, only on Windows. As @SeeminglyScience astutely pointed out, it's due to a workaround of ReadKey on Windows so we can host PSReadLine, our custom ReadKey is buffering that first letter, but since the prompt is using the default from PowerShell, it's not being given that consumed (and buffered) letter after the PSReadLine task is canceled. I can repro your issue precisely on Windows...and we're not sure if they'll be a clean fix. This explains why before the pipeline rewrite we had essentially rewritten all the prompt and Read-Host logic, which we really don't want to have to do (again).

[MrFly72]

Just tested it on my Raspberry Pi 4 running VSCode and it's not failing there. So it seems really to be Windows.....

[andyleejordan]

How much of a blocker is this for you @MrFly72? Do you have a workaround available? It might prove to be quite a pain to get fixed.

[MrFly72]

Currently it is only a blocker when using VSCode. Usually I am the only one using it for generally running my scripts.
It tends to be a problem if the question asked is important, as Default will be choosen, although you have pressed something else.
EG:
Do you want to delete this file (y/n) (Default:Yes)
If you press N and it will not be accepted as in this case it would delete the file anyway, as it is the default and that will be choosen instead of the N pressed.
So there is a risk of something happening that should not

[andyleejordan]

LOL, repeat of #1753

[MrFly72]

Yes, seems like a reintroduced bug ;-)

[andyleejordan]

Hi there, we just released v2022.4.0-preview! Could you please try PowerShell Preview for VS Code and verify this is fixed? It seemed to be in my testing, so marking as resolved, but please let me know if it's still occurs (or if new bugs show up)!

[ghost]

This issue has been marked as fixed. It has been automatically closed for housekeeping purposes.

[MrFly72]

Hello Andy,

It is still not fixed completely. The keypress is now taken ok, but there is still some dirty keys that appear in the commandline.
I will attach a video, which also includes #3914.
You can see, that after debugging the lines (either Choice or Get-Credential) the following Inputline will somehow I believe have a " put in, so that it will search history in my case for any command starting with "

2020-04-13_PS_VSCode_KeyPress.mp4

[andyleejordan]

@MrFly72 Can I ask you what happens if, outside of the Get-Credential or anything, you press DownArrow, or a combination of DownArrow and Spacebar simultaneously? There's a remaining issue in PSReadLine that I know we're going to have to fix, and I wonder if it's leading to this. Please do open a new issue for the quote!

[MrFly72]

@MrFly72 Can I ask you what happens if, outside of the Get-Credential or anything, you press DownArrow, or a combination of DownArrow and Spacebar simultaneously? There's a remaining issue in PSReadLine that I know we're going to have to fix, and I wonder if it's leading to this. Please do open a new issue for the quote!

If I understood you right, basically pressing downarrow or a combination just in the terminal window without anything running?
That does basically nothing on my system. Except space will introduce a space as expected.

[andyleejordan]

You understood correctly. You can see in PowerShell/PowerShellEditorServices#1754 that when we cancel ReadKey we return a DownArrow + ' ', which should be a no-op but seems to introduce a " for you. Fortunately, I'm pretty sure we know how to fix this, it just will take a bit since we need to get it fixed in PSReadLine and then consume an update there. Thanks for testing!