Quick pick items warning/error handling

[rebornix]

Here are three common scenarios in notebooks where we want to present warning/error messages to users and improve the UX

• Empty results from a quick pick item entry. This usually happens when users pick a quick pick item, which goes to the next quick pick step, but at the end there is no result in that step. We currently show a placeholder quick pick item there but

  • It might be too late to show this option
  • The quick pick item is not actionable and also doesn't look like a warning/error message, compared to the validation message we usually show in quick picks.
    Dupe of Asynchronous error handling in quick pick #174476

• Input validation. When users try to connect VS Code to a remote Jupyter, we would show an error message to users if the server is not available. A common error in browsers is CORS and currently we only show a plain text message to users. It would be helpful if we could show some useful links that users can visit to get the server CORS enabled themselves Dupe of Support clickable links for input box descriptions #82112

• Invalid Python environment in the kernel selection list. This usually happens when users have a partially broken Python environment. Jupyter or Python extension might be able to fix it, so we still present it to users (we don't automatically fix it for users, as it requires user consent). Currently, we put a warning codicon in the quick pick item title, but users don't know what the reason behind the "warning" is. Dupe of Allow quick pick to show a tooltip #174473

[daviddossett]

Seems like there are three different concepts going on here. Some ideas from the hip:

• Input validation: probably makes sense to look like your screenshot above
• Inline warnings: this one looks like it could be more obvious—maybe warning text on the second line could work here?)

• Empty states: it could be as simple as a diabled item with the option to customize the message? Else it falls back to a sensible default e.g.

[rebornix]

Thanks @daviddossett, the proposals above look neat. here is a real world example for scenario 3.

Screen.Recording.2023-02-08.at.5.01.01.PM.mov

On startup, we have two remote servers stored in cache, and we present both of them to users. Only when users pick them, we will attempt to fetch kernels from the server. For the second one, since the server is already dead, we won't get any kernels back but only an error message, which can potentially explain why it fails.

[TylerLeonhardt]

This issue captures a lot of different use-cases and now that the dust has settled we should move these into smaller issues.

[TylerLeonhardt]

Linked each idea with a respective issue