-
Notifications
You must be signed in to change notification settings - Fork 904
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS Web Push Device Unregisters Spontaneously #8010
Comments
Looks like the same issue as #8013! |
This keeps happening to users. This is the extent of our code. Why would the device stop sending pushes?
|
We are also having the same issue, looks like it works about 3 times on iOS and then just stops until the app is then opened and the token refreshed again. messaging.onBackgroundMessage((payload) => {
const notificationTitle = payload.notification.title;
const notificationOptions = {
body: payload.notification.body,
icon: payload.notification.image ?? "/icon-256x256.png",
click_action: payload.data.link,
};
return self.registration.showNotification(
notificationTitle,
notificationOptions
);
}); |
Could this be related to this? https://dev.to/progressier/how-to-fix-ios-push-subscriptions-being-terminated-after-3-notifications-39a7 Not sure if the onBackgroundMessage message takes care of the waitUntil |
I suspect the issue is iOS thinks this is a invisible push notifications because firebase is doing it async, but until someone actually looks into, I don't know. We are debating moving off of FCM for this reason, it just stops working after some time. |
Alright that is indeed the issue, I just ran a bunch of test and I replace the onBackgroundMessage with this in my service worker:
This is working perfectly, so I just remove all trace of firebase in the service worker. All the notifications are coming in now in iOS. I think this need to be address in the firebase codebase. |
How do we get their attention! |
Yeah, seems like a big deal, since it is not working on iOS |
Wow this solved my exact problem. Thank you!! |
Not working for me. OK for Android but not in IOS. |
Hello. Possible to have a piece of code ? |
Update: After fixing some issues with my service worker and nixing my foreground notification handlers, it seems to work more reliably with the event.waitUntil() solution. Another Update: A notification failed to send after 44 restarts. I was able to reactivate by requesting another token (after an additional restart) but I don't know what causes it as I'm just calling FCM's getToken. I'm thinking of occasionally checking if the token changes against the one stored in local storage and replacing it when needed. More Findings: When FCM's getToken is called, it appears to update that client's token in Firebase's Topics. It's not reactivating the old token. The old token returns UNREGISTERED. The double notification might be that the token gets subscribed twice to a Topic (one is a new subscription, and the other one is mapped from the old one?). I also removed Firebase from the service worker. I then tested if notifications would break by restarting the iOS device over and over while also sending a notification between restarts. Eventually, a notification would fail. It is possible it triggered three silent notifications but I also noticed other PWAs on the same device would not be able to confirm the subscription status either. I don't believe this issue is specific to one PWA's implementation and it's just a bug with Safari. Or somehow another PWA's implementation is causing the others to fail on the same device. I also noticed that requesting a new messaging token seems to "reactivate" the old one. If you subscribe with this new token, and send a notification to the topic, the iOS device will get two separate notifications.
|
@rchan41 Hi! Sorry just to be clear did you get your PWA to send Push notifications to IOS ? Did it work? |
Yes, I didn't have issues sending push notifications to iOS. The issue I described with notifications after restarting the iOS device. However, these issues might be unrelated to the topic's issue. |
@DarthGigi This is working properly? What version of firebase are you using? I am still getting unregistering even when using simple code like:
|
@fred-boink this is the latest iteration of things on one of the projects that I'm working on. I wasn't the original developer so it's been quite a journey trying to troubleshoot. The current iteration of the firebase service worker is still leading to reports of notifications stopping after a while. Don't know what the secret sauce is. firebase-sw.js
Then there's also a component with the following:
|
@fred-boink I'm using Firebase version 10.12.2 which is the latest version at the time of writing. Safari unregistering is still an issue and I don't think we can easily fix it without firebase's help. |
@DarthGigi Yes, none of my changes have worked. They need to fix this, its. a major problem. Anyway we can get their attention? |
@fred-boink It is indeed a major problem, I thought this ticket would get their attention, I have no idea why it didn’t. I don’t know any other ways to get their attention other than mail them. |
Greetings. We have faced the same problem for our PWA on iOS. Code works perfect for Android, Windows, Mac and other systems, except iOS. Version of iOS is 17+ for all our devices. Unfortunately, it stopped to show notifications at all. Before we at least got some, but now we can't get even a single notification for iOS (thus we can see in logs that it was successfully send to FCM).
Can anyone please help? Or any advices how to get them? |
After some reproduction attempts, here's what I've found: Silent Push Device Restarts |
@dlarocque I am using the latest release of 17.6.1. Do you have a specific version or changelog about this? Here are some reports to Apple; |
I just wanna say for the record, that this issue isn't limited to iOS/iPadOS Safari but also macOS Safari (at least at the time I wrote my comments). Maybe this info can help make debugging the issue easier by using macOS Safari. |
That's very helpful to know- debugging in PWA service workers is much harder than ones on macOS 😅 |
If this issue exists in applications that don't use Firebase, I think we can classify this as a WebKit issue, and keep an eye out for new changes in WebKit that might fix this. Even though I wasn't able to reproduce this myself, I'll label is as a bug and keep it open so that others can find it. If anyone believes that this is an issue with Firebase and not WebKit- please open a new issue so that it's easier to spot for the team. If anyone has any updates about this (webkit changes, new errors, workarounds, etc..), please add a comment to this thread! |
This has been added to a list of known issues with FCM in iOS PWAs caused by WebKit bugs in our Wiki: https://github.com/firebase/firebase-js-sdk/wiki/Known-Issues |
@dlarocque Any known workarounds or ways to contact Safari to have this resolved? This is an app breaking bug. |
https://bugs.webkit.org/show_bug.cgi?id=279277 Webkit is saying its silent pushes. @dlarocque Can you confirm? |
It seems that WebKit has not reproduced this issue, and is speculating that it could be an issue with silent push. I cannot confirm whether this issue is caused by silent push, since I have not been able to reproduce the issue. |
@dlarocque I can share with you a link to my app and if you have an iOS device you can see the issue. |
Sure, could you please share the app that produces the issue? Sharing this with the WebKit team may help them as well. |
Do you have an email I can share it to? |
|
I'll chime in with my experience with this bug. Like many of you, my iOS users would also stop receiving push notifications randomly after some period of time. Using some remote logging, I eventually caught the issue in action. The issue was that iOS was completely resetting the state of my app randomly... indexeddb database, localstorage, everything, including push notification tokens. Our logs showed the app having full state, then the app being closed by the user, then opened 10 minutes later with no local state. There was no rhyme or reason, and the user did nothing out of the ordinary (it was a developer on one of our internal test devices). Apple explicitly says they will not reset the state of PWAs added to the Home Screen, but in my experience, this is a flat out lie. Our users suffered from it and we saw it with our own eyes. I believe many of you are seeing it too. I suspect Apple will not fix this "bug" because they don't like competition with PWAs, but that's just my personal opinion. If you are skeptical about this, implement remote logging like I did. Check the local state of the PWA when it loads and log it to your remote server. When the state vanishes, your users will no longer receive push notifications. |
I don't think this is a common issue, at least I haven't experienced it with two apps that have around 80 active users. In my case, resetting the state would result in a user logout (as there's a refresh token stored in local storage for a year), and I've neither encountered this nor received any complaints. My apps have only been in use for 30 days, so there's not a lot of data yet. I have experienced device unregistration with silent push in Safari only after a few notifications (sending push data to the app and notification is conditional), then I found Apple's guidance advising against invisible push notifications and that helped. That said, I still see new Firebase tokens being generated daily for users who haven’t reinstalled the app or cleared their cache entirely, and active IOS users who keep their original token from the beginning. I recently added more metadata to the tokens I'm storing, hoping that will help identify the root of the problem. |
@vitaliit It was not very common in our case too. But it was common enough to make us go a little nuts trying to find the issue when people complained about not receiving notifications. I too found the invisible push advice and made sure we were compliant there (we were), but we still saw the issue. Even if we were in violation of that guidance, it doesn't make sense that we saw all state reset (including local storage). So, at least in our case, something more insidious was happening. |
This is very frustrating for all of our iOS users... |
Oh my god same here, I hope this got fixed.... |
@dlarocque Any luck looking into this? Still not working properly on iOS Safari? |
@amoffat Have you logged an issue with Safari? I can up vote it and follow. |
Looks like the same issue |
I’m experiencing an issue with Firebase Cloud Messaging (FCM) push notifications on iOS Safari. Specifically, notifications stop working after the app receives three consecutive push messages while in the foreground. Notifications work as expected when the app is in the background.
My Assumption: From my understanding, iOS Safari might be unregistering the FCM token after three silent push notifications. It seems that notifications received while the app is in the foreground are treated as silent messages, which might cause the token to become invalidated per Apple’s guidelines. Goal: I need a way to display visible push notifications in the foreground using onMessage to ensure notifications are not treated as silent. This may prevent the token from being invalidated. |
@ChaeHoonK When you write "The messages are received successfully", are these messages regular Firebase messages, or Firebase notifications?
You need to show a notification by your own means when receiving a Firebase notification message and your app is in the foreground. Just handle When your app is in the foreground and you are receiving a Firebase regular message (with no notification payload), my understanding is that you can just process the message in |
@andynewman10 "The messages are received successfully" means that I can receive background push notifications more than 3 times (as many as I want) using Firebase messages (no notification payload). Here is the payload that I used to send data
The code below is how I handled onMessage. But I'm not sure if I'm handling it correctly to be permitted from Safari's silent push restriction.
Lastly, I wrote a simple service worker for background push message.
I still have the same issue. When receiving push messages while on foreground, fcm token is automatically unregistered by itself. |
What happens if you show a notification using eg. Notification.requestPermission().then(function(permission) {
if (permission === "granted") {
const notification = new Notification("Either a regular message or notification message was received", {
body: "You clicked this notification.",
});
}
}); If you always use this code for foreground ( (BTW, sorry about talking about flutter_local_notifications, I was reading a Flutter issue just a few minutes earlier) |
I've just tried it, but somehow I've tried different approach and it work pretty good. I would use this until either Firebase or Safari fix the issue.
|
Operating System
iOS 18.4+
Browser Version
Safari
Firebase SDK Version
10.7.2
Firebase SDK Product:
Messaging
Describe your project's tooling
NextJS 13 PWA
Describe the problem
Push notifications eventually stop being received until device is re-registered. Can take a few hours and lots of messages to occur but eventually stops receiving push.
People mention this can be a cause, Silent Push can cause your device to become unregistered:
https://dev.to/progressier/how-to-fix-ios-push-subscriptions-being-terminated-after-3-notifications-39a7
https://developer.apple.com/documentation/usernotifications/sending_web_push_notifications_in_web_apps_and_browsers
Possible that Firebase does not waitUntil and WebKit thinks its a invisible push?
Steps and code to reproduce issue
public/firebase-messaging-sw.js
The text was updated successfully, but these errors were encountered: