Affected versions

• 81.0a1 (BuildId:20200727203201)
• 80.0b3 (BuildId:20200803045446)

Unaffected versions

• 79.0 (BuildId:20200720193547)
• 78.1.0esr (BuildId:20200722151235)
• 68.11.0esr (BuildId:20200720181548)

Affected platforms

• Windows 10 64bit

Unaffected platforms

• Ubuntu 18.04 64bit
• macOS 10.14

Steps to reproduce

1. Launch Firefox.
2. Access the about:preferences page and make Firefox the default browser.
3. Set date and time to reflect a 24hr period from now.
4. Open Microsoft Edge and set it as the default browser.
5. Set date and time to reflect a 24hr period from now.
6. Click the “Move notification to action center” button.

Expected result

• The toast notification is dismissed and moved inside the Windows action center.

Actual result

• The toast notification is permanently dismissed (it doesn’t get moved inside the Windows action center). I think that this may generate user confusion since a user may expect that the toast notification would be moved inside the action center (and maybe take action for that toast notification later on) after clicking the “Move notification to action center” button but, in fact, it doesn't align with the button's described functionality.

Regression Range

• I don’t think that this is a regression.

Notes

• Please observe the attached screencast for further information regarding this issue.
• [Suggested Severity] I think that this is an S3 issue maybe... since a workaround for users may exist (by switching back via Firefox -> about:preferences page or from the next toast notification which is going to be displayed after 7 days). But this may block a user to switch back to Firefox at a later time (same day) by interacting with the toast notification inside the action center.

We had a lot of back and forth about making this easy to dismiss. Originally, the design called for an 'X' icon, but that proved not possible with the notifications API, hence this use of the dismiss icon.

I think it's probably worth revisiting and just adjusting the behaviour to actually 'Move notification to action center' when this is clicked to avoid user confusion.

Aaron, since you consulted with us on the original UX, would you support us making this change?

(In reply to Rachel Tublitz [:rachel] from comment #1)

We had a lot of back and forth about making this easy to dismiss. Originally, the design called for an 'X' icon, but that proved not possible with the notifications API, hence this use of the dismiss icon.

I think it's probably worth revisiting and just adjusting the behaviour to actually 'Move notification to action center' when this is clicked to avoid user confusion.

Aaron, since you consulted with us on the original UX, would you support us making this change?

Yeah I think that's a reasonable change, and probably the most expected outcome from people. Sounds good to me!

As Rachel mentioned, this currently the expected behavior. I believe that actually sending notifications to the Action Center would be quite a bit more difficult than it sounds. The notification doesn't know how to make the appropriate actions when its buttons are clicked. It just tells the WDBA which button was clicked and lets it handle the event. But we can't just guarantee that the WDBA will always be running. And if it isn't, the notification continues to hang around, but interacting with it fails to produce any effect.

I think that there is some mechanism for handling this sort of thing when the application isn't running, but I'm not sure whether it is available to us. The only documentation I can find is for UWP, and Firefox is not a UWP App. There seems to be basically no documentation whatsoever for using Toast Notifications from non-UWP apps. This is a big part of the reason we decided to use WinToast - it provides us with a documented API for creating and interacting with Toast Notifications.

Another option is to just let the WDBA run for much longer, so that the notification can persist in the action center, at least for a while. This raises some questions though. How long should it run? Is it possible for these notifications to persist across reboots? I've read some documentation suggesting that this could happen, but the WDBA will definitely not be running after a reboot.

I should note that, as currently designed, if we just let the WDBA run while the notification is in the action center, it won't send (or even save) ping data related to showing the notification until it has been interacted with or dismissed. If the user shuts down the computer while the notification is in the action center, that data would be lost forever. We would need to redesign parts of the WDBA if we want to change that.

This feature is no longer confidential.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

WDBA bugs have previously gone in Toolkit::General.