Using the newest preview inserts " in the commandline after debug run of selected line/s

[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 the commands Get-Credentials or read-host (dont know if there might be others), a " will be written to the inputline after the command finished.

PowerShell Version

Name                           Value
----                           -----
PSVersion                      7.2.2
PSEdition                      Core
GitCommitId                    7.2.2
OS                             Microsoft Windows 10.0.19043
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}       
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

1.66.2
dfd34e8260c270da74b5c2d86d61aee4b6d56977
x64

Extension Version

ms-vscode.powershell@2021.12.0
ms-vscode.powershell-preview@2022.4.0

Steps to Reproduce

Use any of these in debugging with F8 (not F5):

• get-Credentials
• read-host

Visuals

2020-04-13_PS_VSCode_KeyPress.mp4

Logs

No response

[MrFly72]

Actually short after opening this, I even tested it with different commands and it seems like an " is introduced at all runs.
Write-Host "Test" did also introduce a " to the inputline when using F8.
2022.4.1 still has this problem.
Dont know if this is really realted to PowerShell/PowerShellEditorServices#1754 as this also happens to me on other calls?
This is filed by request on #3881 by @andschwa

[andyleejordan]

I have a fix for this, need a new release of PSReadLine. Working on it!

[andyleejordan]

The fix will be in the final release. We're getting a PSReadLine update out tomorrow.

[MrFly72]

Great! Thank you for the support!

[andyleejordan]

You're very welcome!

[andyleejordan]

This should be resolved via PowerShell/PowerShellEditorServices#1758

[ghost]

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

[andyleejordan]

@MrFly72 Can you confirm this is now fixed for you?

[MrFly72]

I have not got any update so far? still 2022.4.1 ?

[MrFly72]

Ok nevermind, download it "by hand" and will check

[andyleejordan]

That's strange, it's not usually so slow! I see 2022.4.2 on the marketplace website.

[MrFly72]

Sorry, not yet fixed and very confusing. This happened to me, using the code from #3881 :
Fresh start of the terminal, subsequent start of the script with same state, all starts use F5:

1. Start: Its behaving quite normal, but the "enter" you have to use to acknowledge the choice will be transported to input line (not a major thing in my eyes, just want to mention)
2. Start: Behaving normal at the choice, BUT additional to the "enter" it will transport to the input line, it will also put again the " into the next line looking like this:
   
   And now the most crazy stuff:
3. Start: Choice will only accept second keypress and the character is transported to the input line "again". So basically Host.ChoiceDescription need additional keypress for choosing option #3881 is back on 3rd start.
   Additional Stuff: Doing a clear in this situation will clear the screen but bring back "
   Hitting Backspace 2-3 times fast after each other will bring this:
   
   At the moment I would not say, that it is production ready, sorry.

But it looks like "clear", backspace problem etc. only brings up errors, when you already got into the error path from 1+2+3
just plain in fresh started, this does not happen.

[MrFly72]

Oh and one "funny" sidenote. This all only happens on F5 now, not F8 anymore as my first tests show. very weird!
Please note, that the F5 was used of an unsaved window (no filename presented, just code)
Edit: Also tested it with saved .ps1, as the call is different and F5 will "." the .ps1, but the problem also showed up there and start 1+2+3 could be repoduced, altough it seems not every time or not necessarily at each time testing....

[andyleejordan]

Can you share what it is you're debugging? There is a known issue if you re-enter ReadLine (which can happen like here: #3751)

[andyleejordan]

That Ctrl+" Escape Ctrl+" is very interesting. Can you also remove ms-vscode.powershell@2021.12.0 and reinstall the preview?

[andyleejordan]

Oh! Also are you using an extensions like VsVim, or/and to you have any custom key handlers or prompt? Sorry, asking a lot of questions, but while I could repro this previously, I can't any more with the latest fix. So we certainly addressed the first cause we found, and I'm trying to figure out what else could be going on in your particular case.

[MrFly72]

Can you share what it is you're debugging? There is a known issue if you re-enter ReadLine (which can happen like here: #3751)

The code is in #3881

[andyleejordan]

Do you have anything similar to:

Set-PSReadLineKeyHandler -Chord 'Oem7','Shift+Oem7' `
                         -BriefDescription SmartInsertQuote `
                         -LongDescription "Insert paired quotes if not already on a quote" `
                         -ScriptBlock {
    param($key, $arg)

    $line = $null
    $cursor = $null
    [Microsoft.PowerShell.PSConsoleReadLine]::GetBufferState([ref]$line, [ref]$cursor)

    if ($line[$cursor] -eq $key.KeyChar) {
        # Just move the cursor
        [Microsoft.PowerShell.PSConsoleReadLine]::SetCursorPosition($cursor + 1)
    }
    else {
        # Insert matching quotes, move cursor to be in between the quotes
        [Microsoft.PowerShell.PSConsoleReadLine]::Insert("$($key.KeyChar)" * 2)
        [Microsoft.PowerShell.PSConsoleReadLine]::GetBufferState([ref]$line, [ref]$cursor)
        [Microsoft.PowerShell.PSConsoleReadLine]::SetCursorPosition($cursor - 1)
    }
}

In your profile?

[andyleejordan]

Can you share what it is you're debugging? There is a known issue if you re-enter ReadLine (which can happen like here: #3751)

The code is in #3881

That I used as example and was originally able to repro, found a bug, and was able to fix. So with that example it doesn't repro for me any more 😭 is there more code around it (I noticed it was indented)?

[MrFly72]

This is my profile:

function Global:prompt {
    $Unit="ms"
    $executionTime = ((Get-History)[-1].EndExecutionTime - (Get-History)[-1].StartExecutionTime).Totalmilliseconds
    if ($executionTime -gt "1000") {
        $Unit="s"
        $executionTime=$executionTime/1000
    }
    $time = [math]::Round($executionTime,2)
    $promptString = ("PS $time $Unit | " + $(Get-Location) + ">")
    Write-Host $promptString -NoNewline
    return " "
}

Set-PSReadLineOption -PredictionSource History -PredictionViewStyle InlineView

[ghost]

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

[MrFly72]

Can you share what it is you're debugging? There is a known issue if you re-enter ReadLine (which can happen like here: #3751)

The code is in #3881

That I used as example and was originally able to repro, found a bug, and was able to fix. So with that example it doesn't repro for me any more 😭 is there more code around it (I noticed it was indented)?

No actually I copied the code from there again and put it into Code.
Remember to do it more then once.
It does not happen first start.
Additional to that I did not configure "jump to terminal" after F5 (if that helps)

[MrFly72]

Dont know why the bot marks this as fixed?

[MrFly72]

Oh! Also are you using an extensions like VsVim, or/and to you have any custom key handlers or prompt? Sorry, asking a lot of questions, but while I could repro this previously, I can't any more with the latest fix. So we certainly addressed the first cause we found, and I'm trying to figure out what else could be going on in your particular case.

Dont know what VSVim is, but yes I use a custom prompt. Posted the code in one of the previous posts.

[MrFly72]

@MrFly72 And with the German language pack, I can repro your original issue, not easily (it takes a lot of tries), but with both F5 and using the GUI. The only good news is that it's only with German enabled, not with English, and that's good news only because it narrows down the problem.

@MrFly72 Can you repro your original issue if you set the Windows language back to English (and restart Code)?

Have to look. its a corporate client, so dont want to mangle to much with it. will see what I can do, but you know its weekend here already ;-)
My 3 year old daughter wants Invoke-Play method on the Daddy-Object ;-)
But I can tell you that a Server 2019 - MUI ENG, German Regional Settings (Date+Number-Format), Keyboard DEU does the quote in code when hitting CTRL+SPACE (and that even with PS5.1) using in an RDS Session.

[daxian-dbw]

I could not reproduce the issue in the following environment:

• Microsoft Windows [Version 10.0.19042.1645] (20H2)
• English (US) Windows display language + German (Germany) language pack (for keyboard/input)
• Windows Terminal 1.13.10983.0
• PowerShell 7.2.2 + PSReadLine 2.2.3

I tried with English keyboard enabled and German keyboard enabled, and Ctrl+Space returns the following in both cases:

KeyChar      Key Modifiers
-------      --- ---------
        Spacebar   Control

Not sure if I miss something in the environment.

[MrFly72]

Tried it again with the old PS-Ext, the output for CTRL-SPACE is the same in PS-EXT + PS-EXT-Preview:


In Terminal it shows this in both (PS5.1 + PS7.2.2)

[MrFly72]

As a sidenote. Feature CTRL+Spacebar (Menu Complete from psreadline) does not work.
And it even does not work with the productive PS-EXT (never tested that).
Instead I will always get my loved "quote" ;-)

[andyleejordan]

It's tricky. Starting Windows Terminal normally did not repro for me; it only repro'd when I used the PowerShell shortcut to start the app. I have no idea why 🙄

[andyleejordan]

In English, in the "I started the terminal" scenario, ReadKey shows Control Spacebar, but in the "PowerShell shortcut started the terminal" scenario, ReadKey shows Shift, Control, D2, but does not emit a quote.

After closing the two windows and switching to German, the "I started the terminal" scenario remains the same, but the "PowerShell shortcut started the terminal" both shows Shift, Control, D2 and emits a quote.

Something funky with PSReadLine and localization. I'm going to transfer the issue, I guess?

[daxian-dbw]

Something funky with PSReadLine and localization. I'm going to transfer the issue, I guess?

Maybe something funky there, but I'm not clear how is Ctrl+Space related to the reported issue. According to the repro steps, the quote appears when reading anything from terminal in debugging mode (e.g. respond to the prompt, read-host, get-credential). The exception screenshot shows the last 5 keys are Ctrl+", Escape, Ctrl+", Backspace, and Backspace, so I don't think Ctrl+Space was used in the repro, does it?

[andyleejordan]

I'm agreement, I'm not clear how it's related, but I'm 85% sure it is given that the environments where Ctrl+Spacebar emitting " corresponds exactly to the environments where F5, F5, F5 to launch the script emits ". If it's not related, I'm back to square one. I think we need to understand why the Windows OS being set to German causes Ctrl+Spacebar to emit a quote and show up as Shift, Control, D2, and if we understand that, I'm betting we'll understand why a quote gets emitted in the terminal in VS Code when running scripts.

[daxian-dbw]

One more thing about this comment from #3937

Additional Stuff: Doing a clear in this situation will clear the screen but bring back "
Hitting Backspace 2-3 times fast after each other will bring this:

I believe "Doing a clear" means pressing Escape key. And then Backspace was pressed for 2 times. According to the description, @MrFly72 didn't press Ctrl+", but that key showed up in the key buffer. This indicates that somehow the terminal sent Ctrl+" after pressing Escape, which will be rendered as a double quote by PSReadLine.

Besides, the "Queue empty" exception after 2 Backspace also indicates something is wrong with the keys read from the terminal.

[andyleejordan]

@daxian-dbw and I did some digging. In this thread he found, microsoft/terminal#6454 (comment) indicates that NUL (or \0, which is what I'm having the client send as the fake key press to "cancel" ReadKey) gets encoded as Ctrl+Space, which is also what we've found sends Ctrl+"

So we're going to test sending some other character, something simple, like p as the character to discard.

[andyleejordan]

Soo we've learned two things:

1. Ctrl+Space in Powershell Core produces double quote character microsoft/terminal#6454 (comment) does not appear to be fixed in Windows Terminal 1.12.10983.0
2. It appears that VS Code is sending other text to the terminal sometimes.

When I switched to p instead of \0, I occasionally see it getting emitted as if our cancelation didn't consume it, which indicates some other character was sent first (not by the user or the extension). @meganrogge back to this looking like a VS Code issue.

[meganrogge]

Thanks for the updates @andschwa. My windows computer is slow to the point of useless, so we'll have to wait until @Tyriar is back to further investigate.

[andyleejordan]

Dongbo and I are continuing to debug...we think we've found a race condition.

[MrFly72]

When will this come into vscode-powershell extension?
This error is really driving me nuts .....
It seems that the " strikes me more and more. quite often also just on typed commands
Switches back to production now

[andyleejordan]

Working on it! Today or at the latest, tomorrow.

[andyleejordan]

@MrFly72 it's out! https://github.com/PowerShell/vscode-powershell/releases/tag/v2022.4.3-preview

[MrFly72]

Worked on it today. Never had the issue again so far. Also the Choice is now working.

[andyleejordan]

Hurrah! Thanks so much for all your help testing @MrFly72. This ended up being a race condition in the pair threads spawned by PSReadLine. The place we'd originally put the consumption of the faux key meant to cause ReadKey to return was in a different thread than the cancellation token was getting updated, so when the former lost the race, it wouldn't consume the key as intended! All thanks to @SeeminglyScience for figuring that out.

[MrFly72]

Pretty cool. Glad that I could help ;-)