Notification Background Updates

[docluv]

I see some discussion about exposing the API to service workers. I honestly think this should be the primary path for badge updates. To me badging is something done in the background, silently, sort of like a push notification.

So how would you trigger a badge update?

Use a push notification, at least it would use an existing channel, but also open it up to silent updates, which would get abused, but I still like.

Create a new channel exclusively for background badge updates. This would require platforms to create a new service to handle badge updates.

Allow the PWA to silently poll an API (this is sort of how IE did live tiles back in the day) to get updated data. This would be similar to the previous option, but require no service infrastructure to be created. It would/could increase network traffic, but you could also allow the consumer to control frequency.

[docluv]

also just sort of thought, should this be gated behind a user permission, like push notifications? Would make implementing a polling schedule a bit more explicit for the user to manage.

[mgiuca]

There's now a detailed discussion of this issue in the explainer:
https://github.com/WICG/badging/blob/master/explainer.md#background-updates

We'll keep this issue open while we discuss what to do (in particular, see "the push problem").

In summary, supporting the API through service workers is easy, and in fact is already part of the spec. The hard part is not requiring a notification to be shown upon receipt of the push. This isn't directly a problem with the badge API, it just makes it difficult to use push messaging to deliver silent badge updates (and that has privacy ramifications).

[marcoscaceres]

Just a heads up that Mozilla is coming out firmly against periodic background sync, as we see it as too great of a privacy risk. I don't know if it has a significant impact on the current design, but I think the "push problem" might actually be a "feature, not a bug".

I hear rumors that an alternative design for periodic background sync may be coming that works more like a download manager... the user gets notified that a download has finished in a manner similar to push notifications, which they may choose to ignore, or otherwise act on: which opens an application, allowing the badge to be set as normal. However, the "passive" running the service worker in the background for any reason might never be allowed by Gecko (and possibly by WebKit, given that I think they share the same privacy concerns - but would need to check with them).

[mgiuca]

I'm not really proposing any particular solution here. I think this is a super hard problem, and something I have not personally spent enough time thinking about. In the explainer, we proposed two vague "ideas" of a solution: using Periodic Background Sync and creating a new Push channel for badge updates that would not allow code to run on the client when a badge is updated. Both of these have serious problems, as outlined in that doc, and I'm not currently seriously considering either of them.

I think the first thing to do is get the Badge spec and implementations out the door, letting developers set badges in service workers whilst also showing the mandatory notifications. It may turn out that that's all we need, and most developers are happy to show a notification alongside updating the badge. We can circle around on this problem if there's legitimate demand for setting a badge without a notification while the app isn't running.

Aside: The "push problem" is actually not even, technically, a spec problem, because the Push spec doesn't say anything about requiring a notification to be shown on a push. That's an implementation detail of the browsers. I filed a bug on the spec because I think it needs to be explicit: w3c/push-api#313

[docluv]

Marco,

I get the concern over privacy. I have had some pretty shady requests already for PWAs.

That aside I have several clients that are concerned about deploying updates to users. It will really help if there were a way to notify the service worker in a similar way to how push works so a workflow can execute that updates cached assets to the latest version.

You can gate it behind a user permission etc.

I think we fixate on push being the channel to reach out because it will be the easiest conduit to hook into without building another pipe if you will.

Many native applications utilize this sort of background update process. I have several, along with my operating system and browsers.

I actually had an extended discussion with a client this afternoon on this very topic and I have these conversations at least once a month now it seems. This is a way higher demand that geo-fencing beacons for example.

Right now I have to wait for the user to open the application and putting some checks in place when the service worker spins up. At that point I can perform a background update if the TTL has expired. Once updated I can then notify the user to update.

But most of my customers would really like the ability to just update the application and lets say the next time it is launched or the next page loaded the new version is just used and the application user does not know the difference.

[marcoscaceres]

Right now I have to wait for the user to open the application and putting some checks in place when the service worker spins up. At that point I can perform a background update if the TTL has expired. Once updated I can then notify the user to update.

Unfortunately, that's a feature of the web - not a bug. We don't want service workers waking up on their own because they can too easily track people.

But most of my customers would really like the ability to just update the application and lets say the next time it is launched or the next page loaded the new version is just used and the application user does not know the difference.

Understood. However, that update can happen while the user is using the app - it doesn't need to happen in the background... and, once the update is ready, then the site can tell the user a new version is available (refresh!). Doing it in the background falls into the "nice to have" bucket.

[shishirarora3]

Silent Badge updates should be supported in browser extensions.

When service-worker receives a push event, there is no way, at present, to update badge, silently, without showing a notification to user. I understand the security issues behind taking such a stance. But when we talk of browser extensions, they are considered more priviledged. User generally trusts a browser extension, more than any site or pwa.

[LuthandoMaqondo]

I think the most important part is to increment and decrement as separate functions in the Badges context. Where ever a developer wants to put an update to the number they can just increase or decrease the badge count by the number they have passed.

These could be implemented by negative and positive numbers as arguments to the navigator.setAppBadge() call. Or else, these could be just implemented as separate functions.

[jerrygreen]

To me badging is something done in the background, silently, sort of like a push notification

100% agree on you!

Currently, though, we have two completely different features that make one think it is already the reality:

• background-sync
• periodic-background-sync (also known as periodicSync)

Those things made so much confusion among the PWA community... Because their names state one general thing "Background Sync", then you hear about periodic-background-sync and think: "Wait, so the first wasn't periodic?", and when you deep dive, you figure out:

• background-sync is actually more like something that should be named background-retry or background-fetch-retry: this process cannot be initiated in background, so it is only useful to redo the requests that user made online, i.e. it has to do something with background, but its capabilities is a too narrowed use-case.
• periodic-background-sync (& periodicSync), on the other hand, sounds something like what we all want here, but browser developers (notably mobile browsers developers) don't seem to hurry up implementing that:

Some progress happened from back then, now those experimental features are being replaced with new ones, that have some slight improvements, and more importantly, - they're named a little less confusing:

• background-sync -> background-fetch (& BackgroundFetchManager)
• periodic-background-sync -> ... still periodic-background-sync & periodicSync (one name used in permission system, another name is used in API), but now also PeriodicSyncManager

Which, again, - still a lot of confusion... But at least pretentiously sounding background-sync is now humble background-fetch. They're still two different features, but I guess background-sync is going to stay in experimental state, and lose support, leaving background-fetch to shine. But again, - its purpose is very limited, so it is not as interesting here as periodic-background-sync...

The bad news: after all those years, periodic-background-sync is still not implemented in WebKit. Though they need to initially support the more basic Badging API and Push API probably:

• WebKit Issue - Push API
• WebKit Issue - Badging API

Basically this means that on iOS, whatever browser you use, this feature is not present, - since on iOS it is the only browser engine allowed. Means:

• Quarter of the phone market cannot have periodic background syncs
• Half of the tablet market cannot have periodic background syncs

Which is unfortunate... Can be used on Android Chrome though. And on desktops, too, - but honestly people don't rely on badging icons there as much as on mobile platforms, so supporting mobile platforms is more important for this feature IMO.

Background Features - Compatibility Tables (Oct 2021 Preview)

(Click images to open links for live data)

Spoiler

[marcoscaceres]

I'm going to ahead on close this. The spec is exposed in "worker context", which means it's (theoretically) possible to set a badge as a result of service worker waking up due to a push notification.

[jerrygreen]

it's (theoretically) possible to set a badge as a result of service worker waking up due to a push notification

Yes but hopefully Apple will also support this:

• periodic-background-sync (more info: Web Periodic Background Synchronization, PeriodicSyncManager)

Being able to update badge silently in background, without disturbing user in such explicit way as Push Notifications, – is so neat feature iOS is missing. Already supported on other platforms though. Should I create a separate issue for this, specifically for Apple devices, to keep track of it? Because it's definitely an issue still.