Firefox on Android seems to drop subscriptions

[Interghost]

I'm not sure this is the correct place for this bug report, so if its not please redirect me where it should go... thank you in advance.

We are starting to deploy push notifications via our web site and upon initial testing we see that we are losing FF (Firefox) on Android subscriptions/endpoints after a random period of few hours / up to day at most.
The cycle goes as follows
1 - When the user initially subscribes he is asked to allow notifications
2 - A subscription/endoint is created
typing about:serviceworkers in FF lists the worker and endpoint
3 - Sending notifications works for a period of time
4 - At some point notifications stop arriving
typing about:serviceworkers in FF lists the worker but endpoint is NULL

After this if you try to resubscribe you get to step 2 (it no longer askes to allow as in step 1)
and the cycle repeats.

Further notes, "past" endpoints that get lost can still be sent to server-side without any error.. the payload just never arrives anywhere. Tested on Galaxy S8, and Nexus tablet same results.
It works fine on FF on desktop, not related but also works fine on Chrome both desktop and Android. Is this a bug or what could be wrong here?

[jrconlin]

Sadly, there are a number of reasons for this.

For Android, we have to use a device specific system for Push Notifications. What this means is that once the subscription is created, the actual message transaction is handled by a third party system (FCM, iOS, etc.). That system may return back an error or status requiring that the subscription be restarted. Unfortunately, once that connection is broken, it can be very difficult to re-establish it, or for the mobile device to know that the service is broken.

We're working on a few solutions to try and resolve this problem, but we have limited things we can do as well. (e.g. we can't have the device poll to see if the connection is valid because our app would be flagged for excessive battery use. There are also privacy concerns we would very much like to avoid.)

That said, I'm a bit surprised that you're seeing both the endpoint being set to NULL and that the connections are being reset faster than we've seen in the past (Previously, we would see this sort of error occur after 2 weeks or so.) I'll pass along that information to our client side folk and see if they can figure out what might be going on.

We're working on a new codebase for Android that includes an improved WebPush client side which should help with some of this. Your app may see more frequent re-registration requests as part of that.

Sorry, but thanks for the detailed bug.

[Interghost]

I have figured out what is the issue, its quota. I've been looking at about:serviceworkers after each notification send/display. And after each the quota value inside the endpoint in decreased by 1, when it reaches 0 endpoint becomes NULL.

According to the docs, pushes that show notifications should not be counted toward quota:
https://developer.mozilla.org/en-US/docs/Web/API/Push_API (search for "quota")

[jrconlin]

Yeah, that's definitely a bug in the client code. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1590156. Please correct any inaccurate information or add whatever additional info you can.

Thanks!

[Interghost]

Thank you for the assist... I'm waiting for Push support in the new Firefox to try it out.
In the meantime a related "bug" here that again Im not sure where it belongs, when quota managment disables the subscription, I think that should be registered in the backend services... ie when I try to send a push to that subscription I should get a 4xx error instead of 200 as if all is OK.