1874511 - Clicking push notification opens nothing when service worker stopped running

Status: RESOLVED FIXED

(Core :: DOM: Notifications, defect, P2)

Description

[David]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

0. Subscribe to some YouTube channels and enable notifications

1. Wait for a notification to appear

2. Click the notification

Actual results:

The notification vanishes. Then either the YouTube front page is opened in a new tab in an existing window, or nothing further happens.

Expected results:

The notification is dismissed. Then the specific video or short that the notification is about should open in a new tab in the most recently focused Firefox window. (Note that I am trying to transition away from Chrome where this works as expected.)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

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

AFAIK push notification in the current Firefox doesn't work as expected when SW is not running. We need to make sure every notification is processed though SW.

Comment 3

[David]

Please note that bug 1847096 appears to be about the case where the browser is closed when the notification is clicked. I hadn't even considered that case and have not tested it. This issue appears when the browser is open and even in the foreground when the notification is clicked.

Comment 4

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

Yes, but the underlying cause is the same, the notification should be processed by SW but under some conditions it's not.

Comment 5

[David]

Ah, I figured that might be. Thank you.

Comment 6

[David]

Is there a preferred way to set a bounty on a bug like this? It's extremely user facing and I'm sure immediately causes users beside myself to consider desktop Firefox to be a broken experience.
In my opinion that would still be the case even if it were a rare occurrence, instead of the 100% repro that it is.

I can't give a lot, but I would be quite willing to contribute some if possible to see this issue fixed.
I wish I had the experience to code it myself but I'm just not at that level.

Comment 7

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

I'm willing to start investigation as soon as next week unless anything else happens. I've been fixing several notification issues and this is absolutely in my radar.

Comment 8

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

Okay, let's split the issues into two parts:

1. Opening nothing when the browser is still alive but the service worker stopped running. We'll track it here.
2. Opening the front page when the browser is not running. We'll track it in bug 1847096.

Ideally both should at least partially share the same code path: triggering service worker and fire notificationclick event on it. Unfortunately we just stop doing anything when ContentParent actor is down. What's happening on Windows' case for example:

1. Windows fires Activated event on IToastNotification, where the event handler calls ToastNotificationHandler::OnActivate
2. OnActivate triggers mAlertListener->Observe() with the topic alertclickcallback, where mAlertListener is a ContentParent as ContentParent::RecvShowAlert passes itself when opening notification.
3. ContentParent is supposed to call SendNotifyAlertsObserver, but just fails early when it's dead.

Comment 9

[David]

What about the case where it opens the front page while the browser is open? That's nearly as bad as opening nothing, and happens every time that it isn't nothing.

Comment 10

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

(In reply to David from comment #9)

What about the case where it opens the front page while the browser is open? That's nearly as bad as opening nothing, and happens every time that it isn't nothing.

That's also basically bug 1847096 except it opens a new tab instead of a window in the step 4 of https://bugzilla.mozilla.org/show_bug.cgi?id=1847096#c1. So I believe fixing bug 1847096 should fix that issue too.

Comment 12

[David]

Is there any way I can put up a bounty/tip to have this fixed? It's still super frustrating every day.

Comment 13

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

This is still being worked on with high priority. (Not directly visible here but in related bugs elsewhere in the same component.)

Comment 14

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

This should be partially fixed after bug 1928702. Previously service workers registered the observer and later just went to bed, and the parent process had no idea but just to ping the inactive observer. Now with bug 1928702 a sleeping service worker would also properly unregistered the observer so that the browser can do something more proper.

(i.e. in a plain English, now clicking a notification would at least open a window on Windows, since Firefox 134.)

That said, the browser still doesn't properly start up the corresponding service worker yet. That work will continue to be tracked in bug 1847096.