Manifest v3 and polling under 1 minute

[Jason Savard]

I relied on persistent background pages to perform a task every 30 seconds.

Is the only alternative chrome.alarms? although it still wouldn't work because it has a minimum interval of 1 minute.

[wOxxOm]

FWIW you should be able to use `when` parameter in chrome.alarms.create to specify the exact time, which is not restricted. The only minor inconvenience is that you'll have to recreate the alarm each time.

[Jason Savard]

This contradicts what's in the documentation for chrome.alarms.create for the "when" parameter.

when can be set to less than 1 minute after "now" without warning but won't actually cause the alarm to fire for at least 1 minute

https://developers.chrome.com/extensions/alarms#method-create

[wOxxOm]

Yeah I misunderstood the task. It will become impossible to implement in a straightforward fashion. We would have to use hacks to force the background script to stay alive, there are several such hacks that should still work in ManifestV3, one of them is maintaining an open messaging port from another page e.g. using a random tab's content script.

BTW we still haven't heard from the proponents of ManifestV3 about all the use cases they are about to destroy by deprecating the background page to gain tentative, negligible, or even imaginary, benefits listed in the pompous official announcements.

[Simeon Vincent]

Apologies for not replying to this thread a long time ago. As Jason mentioned the minimum period of the alarms API is 1 minute. While there aren't currently plans to lower this limit, I'd be love to hear about use cases that aren't possible with the current period.

Jason, based on some of your other posts I'm assuming that you're using this to poll for updates to Gmail and other services. In that case I'd recommend moving to FMC or web push notifications as that will be closer to real time while also reducing the impact on laptop/tablet battery. 

I'm happy to talk about the issue wOxxOm raised, but I'd prefer not to hijack this thread to do so. I've got some other stuff I need to take care of before I can find/start a new thread. If I forget to follow up I'd appreciate it if you could bump or start a thread, wOxxOm.

Simeon - @dotproto

Extensions Developer Advocate

[Jason Savard]

1st use case: Gmail polling

Correct, I am polling for updates to Gmail, however, most of my extension users use the default option which auto-detects their signed in account and uses the Gmail inbox feed to poll for new emails.

This allows a user to install my extension and it starts working immediately without requiring any Oauth permissions to be granted by the user if I were to use the FCM method via Gmail's API.

Note that my extension also offers the real time polling of FCM as an option, but the vast majority use the out of the box auto-detect method.

2nd use case: Allowing a user to choose how long a notification is displayed.

Currently the only method is to set the requireInteraction to true in the chrome.notificiations API and then use a timeout to close it after xx seconds.

3rd use case: Network or error retries

Sometimes I set timeouts to retry network failed requests and ideally that's between 5 and 60 seconds

[Simeon Vincent]

1st use case: Gmail Polling

TBH this is the first I've heard about Gmail's https://mail.google.com/mail/feed/atom. I'm assuming it's using session cookies to enable this behavior. That's pretty slick. 

While polling every 60s is 2x your current rate, it doesn't sound like this fundamentally breaks the use case. It may be (frustratingly) slow compared to what you or your users want, but I don't think it's an unreasonable period.

Since you already have FCM support, it seems like a good flow for users that want faster updates would be to prominently display a "enable push notifications" option in your settings UI next to the polling periods. This would give users really want to get faster updates would have a clear, easy to enable way to do so.

2nd use case: Allowing a user to choose how long a notification is displayed.

Apologies, but I'm not quite following here. FCM in extensions shouldn't require you to display a notification. Assuming you're using OAuth, your can push a notification to your extension over FCM and silently handle it. To my knowledge web push notification should also behave the same way in extension service workers.

3rd use case: Network or error retries

Service workers should address this. A service worker can take up to 30 seconds to execute sequential code, but async requests are given up to 5 minutes to settle (source). You should be able to use this to fetch() an update and chain .catch() handlers to retry in the event of a failure.

Simeon - @dotproto

Extensions Developer Advocate