Alarms in event pages (not persistent background script), when to set them up?

Add-ons Development
#1

I’ve been reading Chrome migration guide and there is one piece of code that’s puzzling me:

// background.js
chrome.alarms.create({ delayInMinutes: 3 });

chrome.alarms.onAlarm.addListener(() => {
  chrome.action.setIcon({
    path: getRandomIconPath(),
  });
});

If one would put this code inside a non-persistent background script (or a service worker), the alarm would fire not only 3 minutes after the extension start, BUT also 3 minutes after each waking up of the background event page, right? So this could fire once or 100 times.

So how do I run code only on extension start?
Maybe something like runtime.onStartup but for extensions (since some browsers keeps running even after closing them). Also it would probably not fire after installing extension.

MV3 event page behavior clarification
#2

I know that https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/#event_listeners

extensions must register listeners in the first turn of the event loop. The most straightforward way to achieve this is to move event registration to the top-level of your service worker script.

But chrome.alarms.create() doesn’t register an event listener.
Maybe you can call it in the callback function of chrome.alarms.get() or chrome.alarms.getAll()

#3

But if I call it when the file is first executed, it will be re-executed every time the background script is woken up, right?

I have to say, I’m a bit confused about how the event page actually works when it comes to waking it up.

I would have to create some “runtime stored” variable and check it when the script starts, maybe check if some alarm with a specific name exists and if it doesn’t, I would create it - a dummy one - with infinite repeat cycle. But this feels wrong…

#4

Either that, or create a dummy alarm that fires 100 years from now.
To me, that seems slightly less wrong than an infinitely repeating dummy alarm.

#5

With modern buggy browsers I think it’s better to setup a dummy interval with lower value like 24h than a huge number like above one year - who knows what kind of internal limits there are in Safari / Thunderbird / Chromium / Firefox and 10 other forks :frowning:.

BTW, I’ve found an interesting article about event pages that doesn’t exists anymore:
http://web.archive.org/web/20140302025634/https://developer.chrome.com/extensions/event_pages#best-practices

Best practices when using event pages
8. … Common mistakes include doing unnecessary work at page load time (when it should only be done when the extension is installed); setting an alarm at page load time (which resets any previous alarm); or not adding event listeners at page load time.

EDIT:
Sooooo, actually there is a good chance that Alarms can persist even across browser restarts :smiley:. It was also mentioned here where they suggest to use the new in-memory storage instead - the chrome.storage.session.
I really hope Firefox will implement all these API asap because the time is running out and I’m starting to feel the pressure :frowning:.