Powertoys: Installer notifications spamming notification center

Created on 3 Sep 2020  ·  20Comments  ·  Source: microsoft/PowerToys

ℹ Computer information

  • PowerToys version: 0.21.1
  • PowerToy Utility: N/A
  • Running PowerToys as Admin: No
  • Windows build number: [run "winver"] 19042.450

📝 Provide detailed reproduction steps (if any)

  1. Run the installer/update

✔️ Expected result

_What is the expected result of the above steps?_

Only one notification in the notification center

❌ Actual result

_What is the actual result of the above steps?_

4 notifications

📷 Screenshots

_Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form_
image

Area-SetuInstall Issue-Bug Priority-2 Resolution-Fix-Committed

All 20 comments

Ditto, mine were slightly as I got the updated successfully notification twice:

image

we've done some work for 0.23, we still need to do some more.

we need to investigate if it's possible to update the current toast with new info and verify what happens if it's been already dismissed.

Here are the results of research on what we can do with toasts:

  • we can change the existing toast title and message if we mark it with a tag
  • if the toast was already dismissed, Windows stores a new one in the action center, but doesn't display it
  • if the toast wasn't dismissed, and it didn't "disappear" to the action center, changing its contents will prolong its lifetime
  • ... we also must supply actually different toast contents while calling the toast update API, otherwise Windows doesn't prolong its lifetime. (that's why I've had to implement a fake ever-increasing progress bar for bootstrapper so the notification doesn't go away)
  • if the toast has already disappeared to the action center, we can't bring it up from there by updating its contents
  • we can delete the existing notification by tag and supply a new one.

So, if we want to have only a single notification for the whole updating process, we can mark all of them with a single tag and update the contents, but once the toast goes away to the action center, we can't bring it back from there. Windows hides the toast notification after its contents weren't updated for the ~3 seconds, so we'll definitely hit it.
Therefore, it looks like the most viable option is to remove the previous tagged notification and supply the next one.
We can also remove some of the existing notifications altogether.
I've created a draft PR with the toast contents update API for anyone who wants to experiment with toasts lifetime locally - #7410

@crutkas @enricogior @htcfreek
Thoughts?

I think we should optimize which notifications are shown. (Maybe only success, error and progress bar.)
And do we really have to use toast notification? If we have this problems, maybe it is better to have an own updater ui.

@yuyoyuppe
If we work on this issue we could also implement #2699.

@yuyoyuppe
I am not sure but can this article help us: MS Docs - toast-pending-update

@htcfreek oh nice! updated my post to include this info! I'll play with this API to see how it works...

@htcfreek oh nice! updated my post to include this info! I'll play with this API to see how it works...

See: https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Notifications.ToastNotificationHistory?redirectedfrom=MSDN&view=winrt-19041#methods

@htcfreek yeah, I've only checked ToastNotificationManager initially, since it sounds like a perfect place to have this API...

@yuyoyuppe
Think #7004 is related to this issue in some way.

Alright, to sum up: we can only remove the existing toasts with the same app ID, i.e. PowerToys.exe cannot remove toasts originated from PowerToysSetup and vice versa, Meaning, as long as we use toasts in the bootstrapper, we'll have at least 2 different notifications.
I'll proceed by merging all of the existing notifications from PowerToys.exe into one, and we'll get rid of the toasts altogether in bootstrapper as a separate task in the future.

@yuyoyuppe
OK

Alright, to sum up: we can only remove the existing toasts with the same app ID, i.e. PowerToys.exe cannot remove toasts originated from PowerToysSetup and vice versa, Meaning, as long as we use toasts in the bootstrapper, we'll have at least 2 different notifications.
I'll proceed by merging all of the existing notifications from PowerToys.exe into one, and we'll get rid of the toasts altogether in bootstrapper as a separate task in the future.

@yuyoyuppe
Are the apps from different app packages because there exists methods that allow an AppID parameter. But it must be the same app package. (See Microsoft Docs link above.)

@htcfreek

there exists methods that allow an AppID parameter

  • we _must_ use methods which use app ID, because we're not a packaged app
  • different apps (installer/PowerToys) must have different app IDs, otherwise things like toast activation won't work
  • to have Windows recognize the app ID, you must create a .lnk for the .exe with app ID attribute
  • even though the methods accept app ID param, you cannot control/remove other apps' toasts

It might be possible to somehow circumvent the toasts removal restriction from other app ID by e.g. registering multiple .lnk with multiple app IDs etc. or some other hack, but that would complicate the already convoluted toast notification workflow and will require to allocate a too high an amount of time for research/implementing/testing all of this for the issue we're having at hand.

moving to 0.27, will change bootstrapper UI as part of this task.

moving to 0.27, will change bootstrapper UI as part of this task.

okay. make sense.

Kann we mark the two related issues as this or do you have them in mind?

We should simply remove the usage of Toast Notification in the installer.
https://github.com/microsoft/PowerToys/issues/8045 provides a good reason for doing so.

We should simply remove the usage of Toast Notification in the installer.
https://github.com/microsoft/PowerToys/issues/8045 provides a good reason for doing so.

What was the original reason for using toast notifications in the installer?

@htcfreek
reusing some code already in place for the auto-update. Not an ideal approach, saving time in one place can cause problems later on. It should have not been used in the first place.

Was this page helpful?
0 / 5 - 0 ratings