Call Stack "Paused On Breakpoint" UI not visible for long thread names

[sean-mcmanus]

• VSCode Version: 1.31.0
• OS Version: Windows 10

Steps to Reproduce:

1. Use the C/C++ extension to debug our Microsoft.VSCode.CPP.Extension.exe.
2. Hit a breakpoint.

Bug: The "Paused on Breakpoint" UI is not visible for the threads with long names, so I can't see which thread call stack I'm actively debugging.

Does this issue occur when all extensions are disabled?: Yes, but needs the C/C++ extension to debug.

[WardenGnaw]

Do you see the pause if you expand that window very far to the right?

[sean-mcmanus]

Yes -- it shows "Paused on Breakpoint" if I expand the window to the right more -- but that hogs too much vertical screen space for me to keep such a wide left pane.

[WardenGnaw]

@sean-mcmanus Thanks. Just clarifying if the debugger was not sending that the thread was paused.

[isidorn]

IMHO the most common case is that the PAUSED ON BREAKPOINT label gets cut and becomes PAUSED ON B... which is much better than cutting the name of the thread, which the users can not infer.
I understand that in your case the thread names are very long and not that useful, but why don't you limit cut them on the adapter side.

Also this would make it inconsistent in the way we hide things for stack frames. The name of the stack frame gets hidden last. Since it is the most important

Due to that I have no plans to change this in the immediate future. Thus moving to backlog.

[sean-mcmanus]

I think the fix for #68616 (no active thread highlighting/scrolling) will make this issue less important, so putting it the back log would be okay with me. In addition, we could set more of our thread names in our code.

But FYI our C/C++ debugger guy @WardenGnaw says:
"It does not make any sense to limit this on the adapter side. In the protocol, we supply the “name” to StackFrame (see https://microsoft.github.io/debug-adapter-protocol/specification#stackframe) and that is what is shown in the Call Stack Window.

There is no way for us to know how many characters are available to the user in the call stack window and no good way to determine where to truncate the thread name.

I believe VS Code should be truncating it to “Microsoft.VSCode.CPP.Extension.exe!thead_start<unsigned int (__stdcall …. [PAUSED ON BREAKPOINT]” and if you want to see the full name of the thread, you should be able to hover over that thread and see the full name as a tooltip."

[WardenGnaw]

There is currently no good way to limit it on the debug adapter side. The adapter has no knowledge on how big the CallStack WindowPane is or many characters are available to display. Setting the limit to an arbitrary number would be a bad experience for customers on varying monitor sizes or how they setup the VS Code window.

If we modify the protocol to send over a the display limit, this would be broken if the user decides to resize the window. Sending another StackFrameRequest would be a big overhead just to recalculate the thread name.

My proposed solution is for VS Code to truncate the long thread name.

E.g.
Microsoft.VSCode.CPP.Extension.exe!thead_start<unsigned int (__stdcall ... [PAUSED ON BREAKPOINT]

Where to truncate the thread name can be determined by the UI and if the user resizes the window, the UI can recalculate this.

If you want to see the full name of the thread, you should be able to hover over that thread and see the full name as a tooltip.

[sean-mcmanus]

@WardenGnaw Yeah, that truncation solution sounds good, but you'd probably want the thread name to at least be as wide as the "Paused..." label so that the thread name isn't 0 width. Not sure if that is hard to implement.

[isidorn]

More people want this (Java). Assigning to march to investigate if I should change the ux

[isidorn]

Now we first hide the thread and session name.

You can try it out in vscode insiders from next week.
Try it out and let us know how ti works for you.

@testforstephen fyi
@joaomoreno thanks a lot for help!