Migrating timers to alarms in Manifest V3

[Cameron Eckelberry]

I'm currently in the process of identifying everything that needs to change for our extension to be compatible with Manifest V3.

I see background timers are not recommended and the solution is to use the alarms API.

The problem is that the alarms API will require more permissions to be granted by the user.

There are numerous articles documenting best practices for updating user permissions, but is this the only solution?

Many of our timeouts are baked into how the app works and aren't optional without an overhaul of the extension -- not to mention forcefully upgrading users disables their extension.

Best,

Cameron

[Jackie Han]

The problem is that the alarms API will require more permissions to be granted by the user.

The "alarms" permission is not a warning permission. This type of permission doesn't need to be granted by the user (don't disable your extension when upgrading).

PS: The real problem of the alarm api is that it's minimal delay/interval is 1 minute(and may delay some time. For an unpacked extension, it doesn't have this limit). That means developers can't have a timer less than 1 minute in service worker.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1c9ac2ca-d201-4b77-8487-e3d65bc5068cn%40chromium.org.

[Simeon Vincent]

Hey Cameron,

I wanted to share a couple points of clarification.

First, requesting the "alarms" permission does not require the end user to grant any additional permissions. For future reference, the declare permissions page lists permissions that require user grants and the strings the end user sees. Additionally, you can use getPermissionWarningsByManifest to see the strings Chrome will show for a given manifest string.

var manifest = `{

  "name": "Demo",

  "version": "1.0",

  "manifest_version": 3,

  "permissions":["alarms"]

}`;

chrome.management.getPermissionWarningsByManifest(manifest, (prompts) => {

  conole.log(prompts)

});

Second, you can still use setTimeout, it's just important to understand it's limits in service worker contexts. The biggest issue you should be aware of is that setTimeout and setInterval execution is not guaranteed due to the ephemeral nature of service workers. That said, you can still use these methods and you may be able to combine them with the Alarms API to achieve your goal.

Simeon - @dotproto

Chrome Extensions DevRel

[Cameron Eckelberry]

Hey Simeon & Jackie,

Thanks so much! That helps a lot to know that the "alarms" permission does not deactivate the users extension 😅.

Considering that the alarms API only supports times 1 minute or longer, is it safe to assume that we can user timers for anything below that? Or is that still a danger area due to the service worker's ephemeral nature?

Best,

Cameron

[Simeon Vincent]

It's still a danger area. Chrome's implementation of service workers has a hard 5 minute cap. To put this another way, if a service worker has not spun down after about 5 minutes after it was spun up, it will be terminated regardless of what it is doing at that point. 

To make this more concrete, let's say you have a critical setTimeout operation that will execute 30 seconds in the future, but it was scheduled at 4 minutes and 55 seconds into the SW's lifetime. In this case, the service worker will be terminated around the 5 minute mark, so the callback will not fire and any stateful data not persisted with an extensions or web platform storage API will be lost.

You can avoid unexpected terminations caused by this hard limit by letting your SW thread go idle (settling all outstanding promises and callbacks). This will signal to Chrome that the SW is no longer needed and it will reclaim those resources.

Simeon - @dotproto

Chrome Extensions DevRel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/7498377f-4352-40ab-90e0-f8585e273001n%40chromium.org.

[Cameron Eckelberry]

Okay gotcha. Thanks so much for the details! 

Get Outlook for iOS

---

From: Simeon Vincent <sim...@chromium.org>
Sent: Tuesday, June 8, 2021 5:08:43 PM
To: Cameron Eckelberry <cecke...@malwarebytes.com>
Cc: Chromium Extensions <chromium-...@chromium.org>
Subject: Re: [crx] Migrating timers to alarms in Manifest V3

 

[Simeon Vincent]

I should also note that the only exception that we plan to support for this 5 minute cap is long lived neative messaging ports (e.g. chrome.runtime.connectNative). There is currently a bug where native messaging ports do not extend the lifetime of an extension service worker as intended.

Simeon - @dotproto

Chrome Extensions DevRel

[hrg...@gmail.com]

 Hi Simeon. A couple of question about this:

 

I should also note that the only exception that we plan to support for this 5 minute cap is long lived neative messaging ports (e.g. chrome.runtime.connectNative).

1. Will a native messaging port keep the SW alive indefinitely or is there still a time limit?

2. How much longer will the SW live once a native messaging connection has been closed?

Thanks.

[Cuyler Stuwe]

It's a good thing that we're looking into fixing this problem w/ native messaging ports -- It's the first I've heard of it, and it'll be great because once that's fixed, I can seriously look at porting over some of my clients' code that relies on it.

But while useful, this is also a little strange: If one of the "pedestals" of Extensions is "webbiness", why should native messaging work better in extensions than web sockets would?

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/55fb2ec6-f707-4ddc-bf25-e9a980212587n%40chromium.org.

[Simeon Vincent]

Hey all,

Sorry for dredging up an old thread. I just stumbled on a reply I started drafting about 3 months ago, but never actually finished because I didn't have time to get my answer to Cuyler's question into a state I was happy with. In the interest of getting more info out there, I'm dropping the part I'm not happy with and sharing the part I am.

1. Will a native messaging port keep the SW alive indefinitely or is there still a time limit?
2. How much longer will the SW live once a native messaging connection has been closed?

As I understand it, our current intent is that a native messaging port should keep a SW alive indefinitely and that after the port is closed the SW will stay alive for another 30 seconds. This additional buffer is meant to give the SW enough time to persist session data (I'd recommend doing this periodically anyway just in case), notify the user that the connection ended, attempt to reestablish a connection with the native app, and otherwise perform cleanup work. 

Simeon - @dotproto

Chrome Extensions DevRel

[hrg...@gmail.com]

Thanks for the answer.