Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
sean-mcmanus opened this issue Feb 8, 2019 · 9 comments

Comments

Projects
None yet
5 participants
@sean-mcmanus
Copy link

commented Feb 8, 2019

  • 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.

image

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

@vscodebot vscodebot bot added the new release label Feb 8, 2019

@WardenGnaw

This comment has been minimized.

Copy link
Member

commented Feb 8, 2019

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

@sean-mcmanus

This comment has been minimized.

Copy link
Author

commented Feb 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 8, 2019

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

@vscodebot vscodebot bot removed the new release label Feb 10, 2019

@weinand weinand removed their assignment Feb 11, 2019

@weinand weinand added debug bug labels Feb 11, 2019

@isidorn isidorn added this to the February 2019 milestone Feb 18, 2019

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2019

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.

@isidorn isidorn modified the milestones: February 2019, Backlog Feb 20, 2019

@isidorn isidorn added feature-request and removed bug labels Feb 20, 2019

@sean-mcmanus

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

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

@isidorn isidorn modified the milestones: Backlog, March 2019 Mar 1, 2019

@isidorn isidorn modified the milestones: March 2019, April 2019 Mar 27, 2019

@isidorn isidorn closed this in d356e5b Apr 2, 2019

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2019

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!

callstack

@vscodebot vscodebot bot locked and limited conversation to collaborators May 17, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.