debugger won't focus on files that are not under the current file's directory in vscode 1.31

[AndyP2]

Unexpected behaviour in vscode 1.31:

• start debug session on a .ps1 file
• step into a .ps1 file on a path that is not below the current file, i.e. whose relative path has .. in it
• observe that focus stays on the original file, even though execution has now paused in the called file
• observe that switching focus to the called file and single stepping switches back to the original file

Downgrade back to vscode 1.30.2 to see desired behaviour:

• start debug session on a ps1 file
• step into the same script file
• observe the focus switches to the called file
• observe that single stepping keeps focus on the called file

What changed between 1.30.2 and 1.31? Is this just a powershell issue or does it occur in other languages? It looks like it's trying to implement 'just my code' but I can find no way to turn it off except to stay on 1.30.2.

[corbob]

I started seeing this near the end of January, but couldn't describe it this well. I suspect as there were no changes to the extension at the time it started to occur to me that it's a vscode issue, but I have no idea where to start looking.

Another thing I noticed is that the debug sidebar doesn't list any variables while it's not in the current file.

[mrboring]

I'm having the same issue with VS Code 1.31. When I debug a Pester test, and step through the code into a function defined in a different file, the focus stays in the Pester file. When I switch back to VS Code 1.30.2, the step through works fine and VS Code switches into the file holding the function.

I get the same behaviour with the PowerShell extension versions: 1.11.0 and 2..0.0 preview.

[corbob]

Part of me is wondering if this is related to vscode bug: microsoft/vscode#67895 unfortuantely I don't know enough about the inner workings of the debugger in vscode to know if they're related ☹️

[exactmike]

having this problem as well. exactly as described.

[rjmholt]

If the same version of the PowerShell extension does or doesn't have this across different VSCode versions, it's likely this is a VSCode issue.

We'll need to work out if it's something they intended to break or not.

[SydneyhSmith]

Thanks guys, we are able to repro this. We will need to investigate further what changed in the release to have caused this.

[weinand]

@SydneyhSmith please see issue microsoft/vscode#68616 that might be related (and my comment microsoft/vscode#68616 (comment)).

Do you set the "deemphasized" hint on the top stack frames?
If yes, do you have an option to turn "deemphasizing top frames" off?
This helped for Node.js debug.

[AndyP2]

Yes, I installed yesterday's 1.32.0-insider to test this, and it also de-emphasises the stack frames.
If I add "smartStep": false to launch.json the hover text says "Property smartStep is not allowed" and the debug behaviour is unchanged.

[weinand]

Yes, the "smartStep" feature is specific to Node.js debugging.
That's the reason why I've asked whether the PowerShell debugger has an option to turn "deemphasizing top frames" off.

[AndyP2]

I did sort of expect that. I couldn't find anything else that seemed relevant though, so I thought I'd try it anyway :-)

[SydneyhSmith]

@weinand I am not aware of a deemphasizing top frames option, are there any plans to address this on the VSCode side?

[weinand]

Please read my comment from above.

[rkeithhill]

We do support deemphasize but there isn't a setting to turn it off. But I can test it with that support disabled.

[Glober777]

This issue is so painful that I had to move back to VSCode 1.30.2.

[weinand]

@isidorn #68616 is a show stopper!

[isidorn]

This is fixed in latest vscode insiders.
Can someone from this thread please verify that everything is ok for powershell now?
Thanks!

[LaurentLienhard]

I tested with the latest insider today I still have the worry 🙄

[LaurentLienhard]

Version: 1.32.0-insider (user setup)
Commit: 393b48d4a5de85b6fa1d2ad0a59588d6715e12ea
Date: 2019-02-25T01:34:48.785Z
Electron: 3.1.3
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.18343

it's confirmed, when I run the debug with F11 it does not go into the function

[rkeithhill]

Yes. I'm looking at either ripping out the feature altogether (not my first choice) or adding a debug config setting that defaults to:

"smartStep": {
    enabled: true,
    sourceDirs: [ "${workspaceFolder}" ]
}

@isidorn @weinand Any input on this approach? We basically look at the script path of each stack frame and if rooted in one of the sourceDirs, then it's a normal stack frame otherwise we deemphasize it. BTW it would be nice if we had an optional way to "force" step into "external" code.

[rkeithhill]

@DarkLite1 can you try the setting "cwd": ""?

[DarkLite1]

@rkeithhill that didn't work I'm afraid. Still the same issue when hitting F5 and executing

"configurations": [
        {
            "type": "PowerShell",
            "request": "launch",
            "name": "PowerShell Launch Current File",
            "script": "${file}",
            "args": [],
            "cwd": ""
        },

[MarkKharitonov]

I need this fixed badly too. Refactoring code across different modules kills the ability to debug it.

[rkeithhill]

OK, initially I'm going to disable this de-emphasize and then come back when I have some more time to implement this with settings to control it. Perhap @rjmholt could push out a bug fix update early next week? We have a few other bug fixes teed up for release.

[mrboring]

OK, initially I'm going to disable this de-emphasize and then come back when I have some more time to implement this with settings to control it.

@rkeithhill Hopefully these will be global settings and not per project.

[TylerLeonhardt]

Considering the following, I think the setting to have de-emphasized stack frames will probably be an opt-in setting:

• When you hit the issue, it's confusing as to what happened.
• the learning curve with debug configurations for PowerShell customers is too high (we've gotten a lot of negativity from customers about the concept of the debug configs)
• Some PowerShell customers are not use to debuggers all-together
• People running scripts in other places is not an edge case IMO

Does anyone feel otherwise?

[rkeithhill]

That's good data. I wasn't sure what was better - using debug config or extension settings. The Node debugger uses debug config for enabling/disabling smartStep. But it sounds like we'd prefer this be a workspace setting. Works for me.

[DarkLite1]

Keep it KISS guys. I've only worked with the PowerShell ISE, before I started using VS Code. So as @TylerLeonhardt stated, I've never worked with a debugger before. The more the window on the left pops-up, the more I try to close it every time as it takes up too much space (but this is another issue).

When I want to see values of variables, I usually hover over them or type it in the console with some other commands to test things out after a breakpoint. I know it's maybe not best practice, but it's what I've learned by using the ISE.

So IMHO, please try to make the config KISS or even unneeded to mimic the PowerShell ISE behavior. But that's just my 2 cents of course. It all depends on the target audience and what they'd expect.

[TylerLeonhardt]

@rkeithhill I'm not apposed to making this a debug config setting, but the point I wanted to drive home was that it should be opt-in not opt-out.

Also, Keith can you open a new issue to track creating the setting so we don't forget?

[MarkKharitonov]

Since the issue is closed I understand there is a workaround. From this discussion I did not understand what it is - could you give detailed instructions how to apply it?
Thank you.

[TylerLeonhardt]

@MarkKharitonov a workaround has been applied. There's no work that needs to be done from the user's perspective. However, you must wait for the next release.

[MarkKharitonov]

Got it. Thank you very much. 

[rkeithhill]

@TylerLeonhardt Issue submitted - #1783

[Stephanevg]

@TylerLeonhardt / @rkeithhill
Could we have information in which version number this bug would be fixed? 1.32.3 ? If so, I am still impacted, and then this issue should be re-opened.

Not having the debugger is something that really impacted our productivity, and I have 20 engineers that were cursing at Vscode each time they need to debug some code these last 2 weeks.

[LaurentLienhard]

@TylerLeonhardt / @rkeithhill
Could we have information in which version number this bug would be fixed? 1.32.3 ? If so, I am still impacted, and then this issue should be re-opened.

Not having the debugger is something that really impacted our productivity, and I have 20 engineers that were cursing at Vscode each time they need to debug some code these last 2 weeks.

In this version, in my case, it works only if I replace "cwd": "$ {file}" by "cwd": "C: \\" in the file launch.json

[DarkLite1]

@MarkKharitonov a workaround has been applied. There's no work that needs to be done from the user's perspective. However, you must wait for the next release.

@LaurentLienhard should it not work without making changes in debug configs?

[corbob]

I believe what Tyler is saying is that it's fixed in the repository for the extension, but you need to wait for a release to be built for it to be fixed in the marketplace version of the PowerShell extension.

[rkeithhill]

without making changes in debug configs?

That is just a "workaround" until the next release hits the marketplace. The fix in that release will not require any changes to your debug config.

[mrboring]

@rkeithhill Has a fix been made for the clicking Debug tests in Pester tests having a hardwired debug configuration?

#1750 (comment)

@mrboring that makes sense. The Pester test debug configuration is hardwired in the the extension.

If not, does a new issue need creating?

[DarkLite1]

Thanks guys, let's hope it gets fixed in the preview extension too. As we're using that one for the PSReadLine support.

[TylerLeonhardt]

The workaround will also be there :)

[decoyjoe]

For those curious about which version of vscode-powershell this issue was fixed in, it was included in release v1.12.0 and v2.0.0-preview.2