Hide notifications (info, warning) even when showing buttons

[eamodio]

Currently there is no way to have a notification offer actions but also have it go away after a timeout. I would love the ability to specify that the actions provided to the notification api (showInformationMessage, etc) should only be shown (and cause the notification to "stick") if the user interacts (i.e. clicks) on the notification itself.

That way the notification would appear & behave the same as a notification without actions, unless the user clicks on the notification, and then it would expand to show the action buttons (in which case it would also turn off the hide timeout). And maybe these type of notifications are shown a bit longer than normal ones to give the user more time to interact if desired

/cc @bpasero

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Notifications with buttons should fly out after a timeout (#44128)
• Improve notification APIs (#44121)
• Integrate with OS Notification Center (#45578)
• Unimportant notifications should not need to draw attention from status bar (#44185)

[eamodio]

@bpasero is this something you'd accept a PR on? If so, what approach should be used? Ideally imomodal would be used to signal that notifications should stay open even if they have buttons, but that would change backward compat. Maybe if modal is explicitly set to false (vs undefined) it could be honored and allow the notification to go away even if there are buttons?

Thanks!

[bpasero]

@eamodio we did an explicit design decision that notifications with buttons should be treated like prompts that require user interaction and thus never hide. What is the use case for changing the semantic here? For a user it is then very hard to know if a notification stays open or suddenly closes if there is no visual difference.

[eamodio]

In CodeStream we use notification for @mentions and DM messages (by default). And we don't want these notifications to stick around, but we do want a user to be able to interact with it (e.g. open the message). Right now because notification don't have a click action, nor the ability that have non-http[s] links (either command: custom scheme from registered UriProviders), we have no ability to support this. So we either show notifications with buttons that will never hide (bad ux) or have no ability to interact with the notification (currently we do that latter - but many users are complaining about it).

An alternative is maybe to just have a click action on the notification to allow a callback for when a notification is clicked on?

[eamodio]

Although I was thinking that from the user point of the the ux for notifications with (that aren't model) and without buttons would be the same, until the user clicks on the notification. At which time the notification would expand, revealing the buttons, and also stopping the auto hide. So its behavior wouldn't be much of a user ux change.

[bpasero]

Lets close as duplicate of #46571. The right UX is to use links in this case.

[eamodio]

While links will work, I still feel like being able to have buttons provides a better experience.

So this would be the notification the user would see if they do nothing:

And this is what they would see if they click on the notification:

Versus links:

or everything is a link:

While the ux of the last works better of the 2 link options (because you can just click anywhere to perform the action), imo it is definitely strange for a user because I can see them asking why that notification a different color than the others.