Call Stack bounces when short-lived second requests start/stop

[dariusj18]

Issue Type: Bug

When using the PHP debugger I have a request paused and awaiting, however while that request is running other requests are also running but not pausing, as expected. The problem is that while there is only one request in the call stack, the call stack for the paused request is expanded, however when a second request is running the paused call stack gets collapsed and it shows two requests, with the paused request having an expansion arrow. Then the second request ends and the call stack again shows the full single request's call stack. Because of the nature of the application and my local dev environment, this is constantly happening, and focusing on anything or expanding it doesn't prevent me form losing my place.

VS Code version: Code 1.55.2 (3c4e3df, 2021-04-13T09:35:57.887Z)
OS version: Windows_NT x64 10.0.19041

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (8 x 2592)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.96GB (3.41GB free)
Process Argv	--crash-reporter-id 7d9cd352-3b0d-45b8-a763-88770b5a2e02
Screen Reader	no
VM	0%

Extensions (47)

Extension	Author (truncated)	Version
vscode-base64	ada	0.1.0
Bookmarks	ale	13.0.4
project-manager	ale	12.1.0
vscode-intelephense-client	bme	1.7.0
npm-intellisense	chr	1.3.1
bracket-pair-colorizer	Coe	1.0.61
dakara-foldplus	dak	1.5.1
hex-to-rgba	dak	1.0.0
php-class-generator-composer-psr-4	dam	1.0.1
vscode-eslint	dba	2.1.20
gitlens	eam	11.4.1
EditorConfig	Edi	0.16.4
vscode-npm-script	eg2	0.3.21
phpunit	ema	4.1.1
prettier-vscode	esb	6.3.2
php-debug	fel	1.14.12
auto-close-tag	for	0.5.10
php-awesome-snippets	hak	1.1.3
composer	ika	0.7.1
phpcs	ika	1.0.5
code-select-until	jak	0.6.0
vue	jcb	0.1.5
vscode-cfml	Kam	0.5.3
string-manipulation	mar	0.5.2
rainbow-csv	mec	1.8.1
vscode-language-babel	mgm	0.0.31
git-graph	mhu	1.30.0
dotenv	mik	1.0.1
laravel-intellisense	moh	0.2.0
vscode-apache	mrm	1.2.0
remote-wsl	ms-	0.54.6
php-docblocker	nei	2.1.0
indent-rainbow	ode	7.5.0
react-proptypes-intellisense	OfH	1.0.3
laravel-blade	one	1.25.0
vscode-versionlens	pfl	1.0.9
vscode-php-getters-setters	php	1.2.3
vscode-yaml	red	0.18.0
laravel-artisan	rya	0.0.27
uridecode	sry	0.3.5
addDocComments	ste	0.0.8
code-spell-checker	str	1.10.2
vscode-input-sequence	tom	0.2.0
lorem-ipsum	Tyr	1.2.0
vscode-w3cvalidation	Umo	2.9.1
vscode-icons	vsc	11.4.0
vscode-proto3	zxh	0.5.3

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
pythonvspyt602cf:30294773
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry914:30276682
pythonvspyt639:30291489
pythontb:30283811
vspre833cf:30267465
pythonptprofiler:30281270
vsdfh931cf:30280410
vscnewfilehidden:30294815
vshan820:30294714
vscoreces:30290705
pythondataviewer:30285071
vscus158:30286553
vscgsv2:30294352

[isidorn]

Please file this against the php debug extension that you are using.
This does not happen with other debug extensions.
If you think this is a vscode issue please fork https://github.com/microsoft/vscode-mock-debug and create a reproducable issue. Thanks

[dariusj18]

I see a similar situation with the mock debugger, when a new debugging request has started the currently focused stack thread loses focus and the new break point it automatically focused. Even when the new request has continued, the focus never goes back, nor is there a way to know readily where the focus was. Additionally when the first request was in the stack trace, it did not act as a collapsible entity, however after the second request was added, the stack trace window was rearranged so that each request was collapsible, though after the second request was completed the first request did maintain it's status as a collapsible entity.

Given the nature of the mock debugger I am not sure if this is caused by the fact that you have to execute a new request manually. I chose to add a new test2.md file and a new launch.json entry to simulate.

[dariusj18]

Also from what I can tell this is definitely VSCode that tries to show the stack traces in a different format if there is one of them vs. if there are multiple. Screen shots are attached to this issue: xdebug/vscode-php-debug#558 (comment)

[isidorn]

If you can repro with mock debug can you write concise exact steps so I can repro on my machine as well. Thanks

[dariusj18]

1. Run the extension
2. Set a breakpoint in test.md (not sure if this is required)
3. Start Debugging "Debug test.md"
4. While debugging session is still paused, Start Debugging "Debug test.md" again. The first debugging session becomes a collapsed section.
5. Continue the debugging session "Debug test.md 2" The first debugging session remains as a collapsed section, which is better than what is happening with the PHP Debug extensions, where it changes back into a single thread not under a collapsible section.

[isidorn]

So the gist is: "the session gets auto collapsed when a new session pauses on a breakpoint". Right?

[dariusj18]

Sort of, the session originally isn't in a collapsible section and when another request is shown on the call stack (whether is it a paused or just showing as running) it transforms into a collapsed section. Then when the other session is no longer there it becomes a non collapsible list again, losing ones place.

[isidorn]

Ok, let me reopen and I can investigate more in the future

[weinand]

I agree, we should not collapse a paused session when a new session arrives.

[rzhao271]

I still hit #122775 (comment) using Mock Debug

[isidorn]

That is expected. When there is only one session we do not show it in the call stack view (to simplify). Thus in that case it is not collapsable. What I fixed here is
"We should not collapse a paused session when a new session arrives."

No further changes planned here, as we did not receive any other negative feedback regarding this behaviour

[dariusj18]

This doesn't seem to have been fixed. The call stack still collapses when a new one is added @rzhao271 is right and the issue isn't resolved. If you happened to have fixed some other issue as a result, happy accident, however the behavior described above still persists.

[isidorn]

Ok, let's reopen. I will follow steps from #122775 (comment)

[isidorn]

Somehow forgot to forward this to @roblourens when he took over Debug.
I am not sure if this still repros after Rob's change regarding firing events after fetching call stack parts.

[roblourens]

This still reproes

[roblourens]

Notes- we have this code that autoexpands sessions:

vscode/src/vs/workbench/contrib/debug/browser/callStackView.ts

Line 196 in d4cd8bb

toExpand.add(s.parentSession);

. Should we autoexpand a thread/session whenever it pauses? I'm actually not sure, it can be noisy and also lead to losing your place.

What I see is slightly different than the screenshots above, which is that the first session remains expanded, but the new one is collapsed, so your focus can stay on the current one. This seems not that bad to me.