Support paging of stack frames

[weinand]

Currently we show only a fixed number (20) of frames of a stack trace.
We should improve this in the following way:

• in the CALLSTACK view show a 'more' affordance at the bottom of the stack trace if there are more frames available than the PAGESIZE specifies.
• pressing 'more' loads another PAGESIZE frames.
• if there are no frames available no 'more' affordance is shown.
• the PAGESIZE value can be configured in the debug settings.

[weinand]

@isidorn I've added paging support to the debug protocol, vscode and node-debug.

[weinand]

@isidorn backward compatibility: if StackTraceResponse has no totalFrames attribute, fall back to old semantics, that is do not show 'more' button.

[isidorn]

@weinand check it out and let me know what you think.
I will also create a test plan item for this. Here it is #4819

[weinand]

@stevencl I think we need your help with the UX for this:

I think we should at least use a different font face, e.g. Italic to make it clear the "Load more stack frames" is not a frame but an action.

[stevencl]

Is there a cost to loading the additional stack frames? If not, I wondered if it might be worth loading the additional stack frames automatically when the user scrolls to the bottom of the call stack?

If there is a cost I would do a little clean up:

1. Remove the '...' as this is used to indicate that a dialog or more information will be requested upon clicking.
2. Consider one or more of the following
   2a. Centre the text to make it even clearer that it is not a frame.
   2b. Add a highlight on hover that differs from the list and that only spans the text, not the full width of the control
3. Don't allow the text to be selected the same way that a frame can be selected - I noticed that when the stack frame contains two pages worth of stack frames that the 'Load more stack frames' button is selected when viewing the second page (i.e., I clicked the button twice in succession after loading two pages worth of stack frames).

[weinand]

@stevencl thanks, these are great suggestions.

Loading stack frames might be expensive. It depends on the debug adapter, so we don't really know in the frontend.

[isidorn]

@stevencl great suggestions, thanks!

@weinand @stevencl I was also thinking of loading more stack frames once the user scrolls all the way down (similar to how Joao is loading more extensions on scroll down in quick open). As Andre pointed out we do not know how expensive this operation can be. But let me know your preference if I should try to load more on scroll down or go with the current solution + Steven's suggestions

[stevencl]

@isidorn @weinand Assuming that automatically loading the additional stack frames doesn't freeze the UI, I think it would be worth trying.

[weinand]

@isidorn Because loading those frames is expensive we would have to make sure not to load more than the 20 frames initially (even if more than these 20 would fit into the view). So only scrolling should trigger loading more.
But the user experience for this would be strange: the view shows 20 but there is already room for more. But why would the user then start scrolling in this situation?

[isidorn]

@weinand yes I agree the solution is not so nice in that case. We would always have to load as much as the view can show to make the user experience nice. However since this operation is expensive I would go with the explicti load more action as we have it today + polish from Steven.

[stevencl]

Good point @weinand I didn't think of that. It makes more sense then to go with the load more button at the bottom of the list.

[weinand]

@isidorn lets go with the "more action" for now.

Here is more detail about the underlying node.js problem: dependent on what version of node the user is running, it actually could make node.js totally unresponsive because node.js tries to move tons of datastructures over the wire in an uncontrollable way. For newer versions of node, VS Code is able to inject code that prevents this, but in older versions it cannot. In this case the UI would not freeze, but the debugging could grind to a halt.

To reduce the likelihood of this, we only show 20 frames (that's even more than node's default of 10).

[isidorn]

@stevencl I addressed your feedback with the exception that I still allow the 'Load more stack frames' to be selectable since it has to be keyboard accessible like all our other actions. I just now nicely clear the selection and focus upon clicked.
Try it out and let me know what you think