vscode: DAP's progress events do not show on status bar if they end within 500ms

I switched some progress events over to the DAP ProgressStartEvent recently but discovered that there’s a delay of 500ms before these progress events appear:

https://github.com/microsoft/vscode/blob/5de3aa7eace377f095000787129534a11b54734f/src/vs/workbench/contrib/debug/browser/debugProgress.ts#L49

And although the ProgressEndEvent takes a “final message”, it’s never used by VS Code.

The result is that short-lived progress messages (for example hot reloading an app) the message is never shown to the user (this has come up a few times - for example https://github.com/Dart-Code/Dart-Code/issues/2597).

It feels like a debug adapter should have some control over this - right now I need to decide between:

Doing nothing and having users confused about whether the hot reload ran
Put a fake delay of 500ms in before sending the ProgressEndEvent - this makes the progress visible, but it’s delayed by half a second which is also confusing
Switching back from DAP requests to using my own custom events and displaying my own progress

I think it would be better if the delay was removed (and left to the DA), reduced, or DAP-provided and the ProgressEndEvent's final message was displayed for a short period after it arrived.

(cc @isidorn - delay was added in a47badb3d682b079e59e3f852f5bffdd29377915)

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 15 (14 by maintainers)

Commits related to this issue

Switch back to using own progress notifications from DAP Fixes #2597. We may be able to switch back to the DAP events if VS Code allows us to always show the notifications instead of waiting 500ms (... — committed to Dart-Code/Dart-Code by DanTup 4 years ago

Most upvoted comments

If there is an end message, it comes immediate (even before the delay).

So the following is not true:

The longer the delay between a user pressing something and them seeing feedback, the less attractive using this API is because it makes things feel slower.

That’s true for an operation that completes quickly, but not for one that doesn’t. For example, say a hot reload usually takes 50ms. They’ll be used to pressing Save and seeing the “Hot reload completed!” message after around 50ms.

However, in the case where the hot reload takes longer (say 1s), it would still be the full delay period before they saw anything at all. While 300ms is probably short enough that they won’t go hitting Save again, it’s still a noticable delay if they’re used to seeing something appear much quicker.

We just have to avoid that every tiny operation triggers the whole progress UI to appear which results in lots of flicker.

I understand this - but the current design feels compromising for good extensions (that want immediate feedback, but will use the progress sparingly) in order to prevent this. How about making the debounce optional but enabled by default? This would allow DA to provide immediate feedback when it works better (like Hot Reload) but still generally prevent flicker?

DanTup on Jun 30, 2020