Breakpoints pane should update when debugger has switched

[jasonwilliams]

When using both the JS Debugger and XDebug at the same time I lose control of the JS Debugger (even after switching back) in the breakpoints pane (on the left hand side).

All other panes update: "variables", "watch", "call stack", "loaded scripts" but "breakpoints" remains on the Xdebug options when switching back to the JS Debugger. This means its impossible for me to switch off the "Caught Errors" breakpoint without switching off the JS Debugger altogether.

[jasonwilliams]

In this video i start the JS Debugger with chrome running. I check for "Uncaught Breakpoints".

i then start XDebug and the "breakpoints" pane changes (bottom left). However, switching back to Chrome doesn't bring it back, so I'm now stuck on this pane and unable to turn off "Uncaught Breakpoints".

Even after turning off XDebug completely the "breakpoints" pane remains the same

breakpoints_720.mov

[isidorn]

@jasonwilliams I acknowledge this issue.
We simply did not write code to support this. Our current approach with mutli session debugging and exception breakpoints is that they will be similar across different sessions.
If they are not then issues like the one you presented appear.

The fix would be that on focus change the exception breakpoints change.
And thinking about it more, exception breakpoints should probably live on the DebugSession layer and not in the debug model since they are tied to the session, not the overall model.

This should be fixed in vscode core thus unassigning @connor4312
However not sure when I will find to tackle this.

[weinand]

Yes, exception configurations depend on active session and we need to reflect this in the UI.
The problem is that breakpoints do not depend on the active session but that they share the BREAKPOINTS view with the exceptions.

[johnrom]

Probably related, but the topic isn't covered in the OP: #147096

If exceptions lived in DebugSession layer as above, that would likely fix my issue as well.

[nisargjhaveri]

I've attempted a fix in PR #158355.

It does not completely move exception breakpoints to the DebugSession plane, but allows multiple debuggers with different exception breakpoints capabilities to co-exists by showing all exception breakpoints at once.

As an added benefit, it also helps with workspaces where multiple debuggers are used frequently as it does not remove the exception breakpoints for other debuggers automatically and keeps the preferences intact.

This does not fix the issue #147096, where we need different enablement for different sessions.

[roblourens]

Verification steps

• Start a debug session
• Start a second debug session with a different debug type. For example, you can use node/python for this
• Ensure that when you focus the first debug session in the callstack, the breakpoints view shows the exception filters from that debug type, and when you focus the second, it switches to exception filters from the second.
• Try starting, stopping, switching the focused debug session, make sure nothing weird happens
• And test with multiple sessions of the same type- the checked exception filters should still apply to all sessions of the same type

[meganrogge]

@roblourens when I try to debug a python file, it doesn't stay in the view for long enough to actually focus the item

debug.mov

[roblourens]

Sure- it ran and completed. You could try hitting a breakpoint 😄

[meganrogge]

I added a breakpoint but it didn't stop there

[roblourens]

Oh, I didn't notice that. I'm a little confused about what's wrong, it looks like it didn't actually start the program (by default I think that button should open a terminal)

You could open an issue on vscode-python if you want, you might be able to get it to debug with a typical launch config, or you can leave it for someone else to verify.

[johnrom]

@meganrogge if you stop all of your other processes and run only that python script, does it hit the breakpoint? I notice in your screen capture it is set to debug, so theoretically it should.

I noticed that on the live build (I haven't tested this prerelease), if I have another session running in JS or something, it displays an inactive breakpoint for the python script -- but it still hits the breakpoint when I debug using Python 3.11.0. Therefore it's impossible to tell from the screenshot whether the breakpoint is considered mapped to begin with.

• If the python script doesn't hit the breakpoint when all other processes are stopped, it's possible either
  • there is a configuration issue with your VS Code (maybe using an unsupported python version, or some setting specific to your vscode prerelease build and vscode-python) or
  • there is an issue with Python breakpoints in general at this commit.
• If the python script does hit the breakpoint, it's possible this latest commit (or another prerelease change contained in this commit) actually broke something related to multiple sessions and python

[meganrogge]

The python script doesn't hit the breakpoint when all other processes are stopped for me - the output is:

DAP Server launched with command: /Users/meganrogge/.pyenv/versions/2.7.18/bin/python /Users/meganrogge/.vscode-insiders/extensions/ms-python.python-2022.18.2/pythonFiles/lib/python/debugpy/adapter
DAP Server launched with command: /Users/meganrogge/.pyenv/versions/2.7.18/bin/python /Users/meganrogge/.vscode-insiders/extensions/ms-python.python-2022.18.2/pythonFiles/lib/python/debugpy/adapter
[DEBUG 2022-11-1 11:10:14.814]: Cached data exists KeyPrefix=Cache_Method_Output__.ensureEnvironmentContainsPython-Args="/Users/meganrogge/.pyenv/versions/2.7.18/bin/python"

Other note - I've seen it work successfully before, so this not working is new for me

Also, the python terminal doesn't get created for me - which is very odd.

[johnrom]

Unfortunately, I'm not really a python dev so I can't provide any useful help here for this PR. For my next steps, I would confirm breakpoints are working using the same python env (2.7.18) in the latest production release of VS code, and that the commands run match what was posted above (except with different paths).

I would start with the real production install of VS code, making sure the issue doesn't exist there. (I can set breakpoints in python using Windows, the latest VS Code version and vscode-python extension).

If the problem exists there, it's definitely not related to this PR and may be a modified or out of date extension, configuration issue, etc. If it doesn't exist there, I would manually roll back the development vscode build to the latest production release (v1.73.1) and confirm the issue doesn't exist there. Importantly, I'd make sure any extensions that may be installed in the development build are using the production version and not custom or modified versions.

If the issue exists after rolling back, the issue could be with the development build configuration and not necessarily the PR. Checking vscode-python for any documentation / open issues re: breakpoints and development builds would also be helpful.

If the issue doesn't exist when rolling back, this could indicate a regression on the main branch (or this PR, if this is the commit you have checked out).

[roblourens]

Python 2.7 may not be supported for debugging @meganrogge, in any case, I recommend moving to the latest 3.x

@johnrom you seem to think you're commenting on a PR, but this is not a PR

[johnrom]

@roblourens the PR tracked by this issue is #158355 and is what I am referring to by "the PR" and/or mistakenly "this PR"

[roblourens]

It seems like you're trying to be helpful, so thank you, but all this stuff you're saying doesn't really seem relevant to the problem at hand.

[meganrogge]

I'm pretty confused by this python experience - my version is 3.9.5, this pyenv shell 2.7.18 thing is printed to the terminal 🤔 , and the only kernel offered is of 2.xx. Someone else should try to verify this.

[paulacamargo25]

Everything works for me as expected. Nice Job!

[johnrom]

I was under the impression that someone was trying to verify an issue that I'm following, and that individual was not able to because of a likely misconfiguration either in vscode or python itself. I gave steps for ruling out vscode (or at worst, identifying a regression). I'm not sure what is off topic about that, but either way it looks like the situation has resolved itself. I'll avoid commenting on issues that you manage in the future unless I am directly participating in them.