Clarification on client update behaviour

[al]

Hey, 

I'm hoping to get some clarity on how updates are rolled out on the client side.

So, my understanding is that Chrome checks for extension updates every ~5-6 hours.

Does this mean Chrome downloads updated packages when available, but only builds/installs them when relaunched?

Or does it download and update the package on next launch? (meaning a connection is required on launch, to update)

Basically, my assumption was that my extension can fetch, say, an updated storage schema, when updated, and make required changes, without trouble as the client should be network-connected since they got the extension update (which itself requires connectivity), if that makes sense?

But if Chrome downloads the updated package whenever, but only installs it on its next launch, then the client could be offline when the extension is updated, meaning the fetch and whatever storage update would fail.

Semi-related, my other assumption was on a Sync install, the above assumption applies as well. Since a connection is required to sign in and download extensions, one can assume that server data can be requested and worked upon, when sync-installed without issue. 

Hopefully I'm making sense here. Thanks

[woxxom]

FWIW, maybe you can use chrome.runtime.onUpdateAvailable + chrome.runtime.reload() inside.

[al]

Ah, I didn't know about, thank you.

Though, it's increasingly looking like your suggestion is almost required (if your update/s are network dependant, or you want users to get them at all?, e.g. they're the never-close-chrome type).

So the de facto solution would be to have it included from to first version, no? Since the aforementioned users may never re-launch.

Or if it isn't included, patch the extension with it in a minor update, then update again, with whatever new changes. But now if you have a content_script, all tabs contain stale code/listeners. I feel like I have to be missing something here.

The wording of onUpdateAvailable is slightly confusing, it makes it seem that adding a listener alone (no callback) can nudge the update installation step - 
"If you do nothing, the update will be installed the next time the background page gets unloaded, if you want it to be installed sooner you can explicitly call chrome.runtime.reload()" or is that just default behaviour, with or without a listener? 

Also, "If your extension is using a persistent background page, the background page of course never gets unloaded", correct me if I'm wrong, but MV3 Service Workers are unloaded when inactive, meaning paired with the above excerpt, the update installation could occur during a browser session (as opposed to after launch), right?

Another question, are there any events/methods of detection for profile syncs (not installation events, just sync storage updates)?

I'm getting the impression that not a lot of extensions use sync storage, as I can't find anything on it, nor in any docs.

These aren't necessarily directed toward you, Woxxom, just prompted from research after your suggestion (thanks!).

[al]

Interesting - thanks for that.

I think my problem with that is that it's fired during normal operations, meaning I'll have to find a way to differentiate between those and profile syncs (unless I'm overthinking it).

Though I think that can be achieved (in my case at least), by simultaneously writing new sync data to local and sync storage, then the during the onchanged, if, it's a sync change, check if local (storage) has it, if not, then it's likely a profile sync.

Luckily for me, I only need to add (cache) to local storage, following sync writes. (Basically, during some sync writes, I cache data to local storage, to save on requests, etc, an obviously during a profile sync, only sync storage is transferred, where I'd like the cache updated as well).

So I think that could do it (unless there are other solutions?)

On Mon, 3 Mar 2025 at 08:00, Mythical 5th <mythi...@gmail.com> wrote:

> Another question, are there any events/methods of detection for profile syncs (not installation events, just sync storage updates)?

That's in the storage API.

https://developer.chrome.com/docs/extensions/reference/api/storage#event-onChanged

The callback parameter has a property called areaName which should be checked to see if the storage area that has been changed is sync.

[Oliver Dunk]

Hi al,

In general I would say that it is not safe to assume there is a network connection after an extension update.

This might not be the case for several reasons:

• We do download and install the update separately. A user might have a network connection for the download but not when the update is installed.
• Even if the user does have a network connection when the update is installed, it might be gone by the time the update finishes and the `runtime.onInstalled` event fires.
• An update might be installed entirely outside of the normal flow, for example if an enterprise deploys your CRX file to a number of machines.

Given all of that, for a schema change I would likely look at bundling it directly in the update. If that isn't possible, make sure you have logic that can handle a network connection not being immediately available and download the schema change at the next available opportunity.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CADFKv7t62qYdLTmaz9i20nGN-wXdRgJ%2BFuZ5bU5bSRDnvvoUEw%40mail.gmail.com.

[Mythical 5th]

> Another question, are there any events/methods of detection for profile syncs (not installation events, just sync storage updates)?

That's in the storage API.

https://developer.chrome.com/docs/extensions/reference/api/storage#event-onChanged

The callback parameter has a property called areaName which should be checked to see if the storage area that has been changed is sync.

On Sunday, March 2, 2025 at 11:11:57 AM UTC al wrote:

[Mythical 5th]

Ah, I see what you mean by "profile sync"

I can't try it at the moment, but I assume chrome.instanceID.getID() will return a different string for each profile. It requires the gcm permission, but that won't add anything to the permissions list seen by the user.

If you include an entry for instanceId every time you update a stored item that needs to be tracked, it will be available in the "changes" argument of the storage change listener, where you can check to see if the change was made locally or remotely. eg.

chrome.storage.sync.set({ profileId: myInstanceId, trackedItem: value });

Note that if a stored item is set to the value it already has, then the storage listener does not run. Similarly, if one of the two items set in my example above is set to the value it already has, then only the other item will be available in the storage listener. This means you might not have the profileId in the "changes" argument, in which case you would have to get it from storage to see what it is. It also means that you might get *only* the profileId, in which case you will know that something has been changed remotely, but won't know what it is!

> simultaneously writing new sync data to local and sync 

You can't write them simultaneously, only consecutively. So the storage listener will run twice. The service worker will be alive for both, so I think it would be possible to track changes this way, but using the instanceId might be preferable.

I hope it goes well.