Troubleshooting Safari-Specific Issues with PWA Push Notifications and IndexedDB

Question

corrideat OP

Created Nov ’24

Replies 2

Boosts 1

Participants 3

Hi,

I'm developing a PWA and I'm experiencing a host of strange issues exclusively with Safari and push notifications, none of which happen with other browsers (Chrome, Firefox, Edge, other Chromium-based browsers). I've been testing primarily on mobile, so it may be (although it's unlikely) that desktop Safari behave differently.

The most severe issue is that the indexedDB global is undefined when the service worker is awoken by a push notification. This completely breaks things. I've recently updated to iOS 18.1.1 and I've seen this issue only recently, so it may be related to an update.
The notifications endpoint keeps changing and notifications are missed. This issue is weird to make sense of, but the gist of it is that, after restarting the app, registration.pushManager.getSubscription() will, seemingly incorrectly, give null, triggering a call (in our app) to registration.pushManager.subscribe, which will give entirely different subscription information.
"Deleted" notification endpoints keep on working (POSTing to them will return 201), instead of returning an error like Google, Microsoft & Mozilla do. This is perhaps not a critical, but it does complicate things on the backend, as we have few meaningful ways of automatically removing these endpoints.
This may be related to 2 in that the endpoint is "created" but "forgotten". Sometimes (quite often) pushing a push notification will not result in any notification on the device, even if the handler has debug code to always display a notification for incoming messages. The endpoint will return a 201 response code. I've added some logic to our server to send a push notification as soon as a new push endpoint is seen, and this notification is shown, so it's the "background" notifications that are somehow missed. Testing shows that this may be related to 2, as in instances where the endpoint remains consistent, notifications seem to be delivered.
Notification permissions are displayed inconsistently depending on the API used. Notification.permission seems to have the correct value, but navigator.permissions.query seems to always return 'prompt', regardless of the actual permission status. As a corollary to this, the onchange listener never seems to fire on Safari when a permission change occurs.

I've searched in this forum, the Web and the WebKit bug tracker, and haven't been able to find anyone else experiencing these issues, other than the inconsistency of querying permissions.

I suspect these are WebKit bugs, but it may also be that things are being done in a sequence that is "wrong" for Safari, which is not documented anywhere. Like I said, things work well in all other browsers.

I have code to share where the issues can be reproduced reliably, but I don't at the moment have a minimal example.

I would appreciate any help or direction with these matters.

Boost

Answer 1

cbarkey OP

Feb ’25

Hi,

I would like to emphasize that I experience some how the exact same issue No. 2.

There is no issue with other browsers / desktop versions, only iOS / Safari (i.e. PWA!) is behaving weired. The subscription is changing randomly. I've tried to get around by repeadetly checking the subscription information gotten from registration.pushManager.getSubscription() and compare with a local copy, and in case of differences, send the subscription information to my backend to get around this. This works very well for desktop / browser on desktop, but not really on iOS/PWA. From what I saw, it is not the pushManager, but the registration which was not given back correctly and therefore not pushManager.getSubscription() was possible. Nevertheless, and I believe this is the most important point: When there is no change to the application / pwa, why does the subscription information change, i.e. is not stable?

Another thread on github (https://github.com/firebase/firebase-js-sdk/issues/8010) related to firebase and some kind of similar problem finally conviced everybody that this is actually a bug in Webkit.

Actually Web Push Notifications are mission critical for my PWA and I would like to draw attention from Apple to this.

My current sample implementation is:

`self.addEventListener('push', function (event) { console.log("ServiceWorker: Eingehende Push Nachricht:", event);

let data = {};
try {
    data = event.data ? event.data.json() : {};
    console.log("Parsed Push Data:", data);

    // Benachrichtigung anzeigen, falls gültige Daten vorliegen
    if (data.head && data.body) {
        event.waitUntil(self.registration.showNotification(data.head, {
            body: data.body,
            icon: data.icon || '/default-icon.png',
        }));
    } else {
        event.waitUntil(self.registration.showNotification(('Unbekannte Nachricht', {
            body: 'Die Nachricht hat eine falsche Struktur',
        })));
    }
} catch (e) {
    console.error("Fehler beim Verarbeiten der Push-Daten:", e);
    event.waitUntil(self.registration.showNotification('Unbekannte Nachricht', {
        body: 'Die Nachricht konnte nicht gelesen werden.',
    }));
}

// Nachricht an alle Clients senden

event.waitUntil(sendToClients(data));

});`

Especially keep in mind the event.waitUntil() call for the showNotification at the end seemed to be quite important as cited by some other sites.

I'm looking forward to get this issue solved soon.

0

Answer 2

andykmcc OP

Feb ’25

I have a PWA that also relies on mobile push notifications. The notification code is here. Without them there is no point in the app existing. I've tested desktop Firefox and Chrome, both work fine, and iOS mobile safari saved to Home Screen (PWA) has issues.

I see in consistent responses from pushManager.getSubscription(). the user excepts notification permission, then I create a subscription and save it to my server. at this stage everything works fine. if I close the app (swipe it up and away) then reopen the app pushManager.getSubscription() return null but notifications still come through. Since the response is null the UI shows a "subscribe" button. If you click it, another subscription is created. Now every notification get delivered twice because the initial subscription, while null on the device still exists in my server.

0