1882464 - Firefox should retry to use native GNU/Linux desktop notifications again

Status: RESOLVED FIXED

(Toolkit :: Alerts Service, enhancement)

Description

[Jure Repinc (JLP)]

It can happen that the native GNU/Linux desktop notification service becomes unavailable for a short time. And if Firefox wants to show a notification during that moment it just gives up on using this native notifications system forever, and only showing its own notification popup windows which are quite intrusive (stealing focus and showing up in the middle of the screen), badly integrated into desktop. Firefox should retry checking for the native GNU/Linux desktop notifications system from time to time and resume using it when it becomes available again. Currently I have to restart Firefox so that the native notifications are being used again.

Steps to reproduce

1. Start Firefox
2. Wait for a notification to see it uses the native GNU/Linux desktop notifications system
3. Kill the desktop shell (e.g. by running "kquitapp5 plasmashell" for KDE Plasma desktop)
4. wait for notifications to see it uses Firefox ntoification popup windows
5. Restart desktop shell (e.g. by running "plasmashell --replace" for KDE Plasma desktop)
6. Wait for notifications

Actual result
All notifications still use Firefox popup windows for notifications until Firefox is restarted

Expected result
Firefox should notice that native GNU/Linux desktop notifications service is back and use it again it without restarting

Comment 1

[Punam Dahiya [:pdahiya]]

NI @nalexander to help triage thanks!

Comment 2

[Nick Alexander :nalexander [he/him]]

Kagami -- thoughts? I know you were active in a similar area recently.

I will note that you might need not restart. If you toggle alerts.useSystemBackend on and off, does the situation recover? If not, it seems to me that we should make that work, which would allow to recover.

I'm going to put P3 (we should improve this, but not urgently) and S4 (since intermittently failing OS notification systems are surely not that wide spread).

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Switching backend currently throws away the previous one, which makes things tricky as it forgets all notification data it opened. We should figure out some way to restore it anyway for browser restart case, so maybe worth revisiting after figuring that out.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

I feel like it's not worth permanently throwing the backend away, opening notification is not and never a hot code path and we can freely retry without worrying about performance.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1882464 - Remove automatic fallback to XUL r=nalexander,nrishel

UL backend will be removed in bug 1983279, and this removes the fallback to prepare for that.

This would mean that systems without libnotify won't have notifications, but:

1. Consumer-facing desktop distros generally have it
2. Desktop environment-less distros may not, but then the XUL window positioning behavior is weird on such environment anyway

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/830f42a59408
https://hg.mozilla.org/integration/autoland/rev/24d1c54255ee
Remove automatic fallback to XUL r=nalexander

Comment 8

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/24d1c54255ee