setBackgroundMessageHandler never fired

[devictor47]

The background handler is not working: no matter what I do, the sw always use the regular onMessage, displaying the actual notification I sent instead of the custom one set on the handler.

My code is the exact same as the one in the repo:

messaging.setBackgroundMessageHandler(function(payload) {
    console.log('[firebase-messaging-sw.js] Received background message ', payload);
    // Customize notification here
    const notificationTitle = 'Background Message Title';
    const notificationOptions = {
        body: 'Background Message body.',
        icon: '/Content/Img/logo-amezze-120.png'
    };

    return self.registration.showNotification(notificationTitle,
        notificationOptions);
});

[mllrmat]

@wizzar how did you solve this? I have the same problem...

[devictor47]

Turns out the problem was in my json. There's a footnote on the documentation that says if your json defines notification property, then the setBackgroundMessageHandler is sort of ignored.

"Note: If you set notification fields in your HTTP or XMPP send request, those values take precedence over any values specified in the service worker."
https://firebase.google.com/docs/cloud-messaging/js/receive

So, this won't trigger the handler:

{
    "to": "abc",
        "notification": {
        "title": "Hello",
        "body": "world"
    }
}

but this will:

{
    "to":  "abc",

    "data": {
        "notification": {
        "title": "Hello",
        "body": "world"
    }
    }
}

This way you can send the notification in the data.

[mllrmat]

Thank you so much!

[alexisvapillon]

I had the same problem, but not due to the "notification" field.
The problem was the "content_available" field.

This was NOT working (despite the lack of "notification"):

{
   "content_available": true,
   "data": {
      "aaa": "bla bla"
      "bbb": "bli bli"
   }
}

This is working:

{
   "content_available": false,
   "data": {
      "aaa": "bla bla"
      "bbb": "bli bli"
   }
}

Sounds like a bug, since according to the FCM doc this "content_available" flag is only for iOS...
https://firebase.google.com/docs/cloud-messaging/concept-options

[nemphys]

I am wondering why the included notification should take precedence over the service worker...
It is not some kind of hard limitation, since the firebase-messaging.js code clearly handles the notification part (it is even easy to understand from the minified code).

The problem is that this "feature" ruins my efforts to use the same messages for different platforms (eg. Web and Android), since I do not want to populate the "click_action" field in the sent message (as it would break the click handling in Android), but I still want to send the user to a page when the notification is clicked on the web.

It would be easy to achieve this if I could eg. include the desired target url in a special field of the data payload and use the service worker to inject it as a click_action in the generated notification...

[UniBrowse]

@nemphys I have been having the exact same problem. It seems like a catch 22. You must include the "notification" object for IOS to display a notification when the app is not in the foreground. If you include the "notification" object then you cannot customize the "click_action" in a Web app. If you specify a "click_action" as a URL then Android will not open your app when it is clicked (IOS opens your app fine surprisingly). If you are not worried about IOS then you could implement the FirebaseMessagingService in your Android app and remove the "notification" object. You could then use custom data keys and control the code to show the notification yourself in both the Web app and the Android app. Doing this would cause IOS not to show any notifications when your app is not in the foreground though.

I completely agree with you, they should allow you to override the notification code (to set a custom "click_action") even when a "notification"object is specified. Or they should allow for an "android_click_action" which overrides the "click_action" for Android apps.

[nemphys]

@UniBrowse Nice to know that I am not alone here :-)
One can either go with the method you propose, or decide to separate the logic for the web and handle the apps (Android & iOS) differently (which is what I think I will eventually do, since it makes more sense to me).
It is a shame though, since it would be really easy to implement something like this in firebase-messaging.js.
People from Google: anybody listening to this (and care to explain why you made this decision?)

PS. I have a feeling that I will go through all the trouble to create a separate message logic server-side for the web app and after a few days they will finally implement it...

[ivanff]

+1

[kaziller]

How can you cutomize the click_action? My messages are sent without the notification property. I tried to add the click_action property to the notificationOptions in my BackgroundMessageHandler like this:

...
const notificationOptions = {
    body: 'Background Message body.',
    icon: '/Content/Img/logo-amezze-120.png'
    click_action: 'http://localhost:30321/'
};
...

But nothing happens when I click on the notification. I read somewhere, that this is not supported. So created an Event Listener, that reacts to a click on the push notification, something like this:

self.addEventListener('notificationclick', function (event) {
    console.log('On notification click: ', event.notification.tag);
    event.notification.close();

    // This looks to see if the current is already open and
    // focuses if it is
    event.waitUntil(clients.matchAll({
        type: "window"
    }).then(function (clientList) {
        for (var i = 0; i < clientList.length; i++) {
            var client = clientList[i];
            if (client.url == '/' && 'focus' in client)
                return client.focus();
        }
        if (clients.openWindow)
            return clients.openWindow('http://localhost:30321/');
    }));
});

(I got this from here: https://developer.mozilla.org/en-US/docs/Web/API/WindowClient)

By trying this, the clientList is empty. So by clicking on the notification it opens a new window even if the tab, where my application is running, is still open. Anyone have an idea how to fix this?

[gauntface]

@nemphys this is a known limitation at the moment and something that I've raised as an issue with the FCM team.

[Birowsky]

@gauntface where do we track progress on this "catch 22" api?