chrome.storage.local not available on background script startup

[Pavel Studeny]

Hi,

we have migrated our users from a manifest v2 to manifest v3 extension a few weeks ago. One of the main changes on the browser side is that the background script used to run all the time. Now, in manifest v3, it can be shut down and restarted any time. For some users, we observe the background script being started every two minutes.

Because of the restarts, the background script relies on chrome.storage to persist state. However, we observe that the storage is not 100% reliable and any state, including credentials, may disappear. We have confirmed that chrome.storage.local may not be defined and only appears after a few hundred milliseconds. But even then, we are observing read and write errors on chrome.storage.local.get and chrome.storage.local.set.

Combined, theses issues would happen in around 0.1% of background script starts, which doesn't look like a big deal. However, it seems that with the same latest Chrome, some users are affected significantly more than others and combined with fairly frequent restarts of the background script, it significantly affects the daily user experience.

More details at #344767727 and#344654368.

Would you advise any alternatives to chrome.storage.local to persist the state or anything else we can do on the extension side?

Pavel

[woxxom]

Use IndexedDB or self.caches?

[Don Schmitt]

This can't be right.  How can it be that chrome.storage.local is not defined on script first-run?  Are you saying that if you have console.log(chrome.storage.local) as the first line in your service worker you would sometimes get undefined?  Wouldn't that be a monumental bug?  And for it to randomly not work?

woxxom, you casually recommended other solutions without pointing this out, which concerns me (considering your domain expertise).  Is there some sense out there that chrome.storage.local is not reliable?

--
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/fa3a580d-079a-492b-b687-4e04aac9f1d9n%40chromium.org.

[Don Schmitt]

Sorry, I didn't see that you entered a bug that literally answers my question that console.storage.local is not defined.  That would be remarkable, I would think that if this is really an issue then any api might not be defined after 2096 runs and you might as well just give up on writing service workers.  Or is there some reason that chrome.storage.local would be special?

How are you restarting the browser 2096 times to reproduce this?

[woxxom]

Don Schmitt, there was a time when I was dramatizing such problems, but not anymore, now I'm more interested in practical workarounds that can be used while waiting for a fix for months or even years. Based on what I've observed for six years of ManifestV3 development while reporting/participating in hundreds of bug reports, indeed I'd say the service worker technology is not reliable in an extension. I wouldn't be surprised if it takes a very long time to reproduce and fix such a subtle bug, just as it happened with previously reported bugs in this area. There are several reported bugs that aren't yet fixed. Such bugs are unavoidable, because service workers are designed for web sites and their purpose to make a remote site load faster and be available offline is completely inconsequential for extensions. There's basically no intersection between the way a service worker is used in the web platform and the way the background script is used in extensions, so there's an inherent tendency for such bugs.

[Pavel Studeny]

It is true that this may not be possible to reproduce on a ad-hoc single computer. Some specific users experience this often - not sure exactly why. With over 100k installations and the background script service worker being restarted fairly often (can be 30x an hour), it will show up. We could see this clearly in our crash reports when we migrated to manifest v3. After adding a small delay and retry when the local storage is not defined, the crashes stopped.

Thanks for the recommendations!

[Don Schmitt]

If chrome.storage.local is not defined, I'd think that would be their most critical extensions platform bug right now.

They may be skeptical of the validity of this report (I obviously am), but it looks like you have an actual error of " Cannot read properties of undefined (reading 'get')".  You  have specific numbers like happened " in 15 500 " cases over two weeks.  Can you detail how you are gathering that information?  We have more users than you and would be happy to add data to this bug using the same logging mechanism you are using.

woxxom:  Thanks for the practical suggestions.  I completely agree that this architecture change was ill-conceived.  It was obvious from the beginning. They started with a brand new architecture and had to immediately add hack after hack after special case after exception.  Alas, no one in management has heard of the sunk cost fallacy.  That said, my thanks to the current team for their incredible responsiveness in trying to help us all survive this change.

[Pavel Studeny]

We are logging this from the extension side. Calling chrome.storage.local.get(...) when it's undefined causes a crash that can be caught in a top-level exception handler. We use Rollbar to collect this - it's similar to Sentry and other services in this category. These tools also allow to send a custom error: in the chrome.storage.local.{get | set}, we check for chrome.runtime.lastError.

[hrg...@gmail.com]

We also receive error reports with some frequency if chrome.storage.local.get() returns undefined.

For example:

chrome.storage.local.get( {key: "value"}, (vars)=>{

    console.log(vars.key) //WILL CAUSE A RUN-TIME ERROR IF `vars` IS UNDEFINED

})

This is not related to MV3 though. It's been happening for a long time, and we just deal with it by checking the variable first.

However, MV3 surely makes this problem way more annoying for having to restart the service worker over and over again.

[Don Schmitt]

Hey Pavel,

Thanks for those details, rollbar looks very useful.  The Chrome team is probably still skeptical about your claims, perhaps you can put something very succinct, isolated, and specific at the very top of your service worker, like: 

if(!chrome.storage.local) {

  setTimeout(() => {

Rollbar.ReportOrWhateverThe APIIs("ISSUE XXX reproduced");

  }, 3000);

}

And if you get those reports, add that very minimal repro to your bug report, including your service worker .js file.  Or if you already have that, then I would add those details to your bug report.

[Viet Ta]

I tried IndexedDB but it seems like when I query for the data that I want in the content-script, it return empty array. Is this expected or can the content-script access data in the IDB (created by the Service Worker) at all?

[woxxom]

The content script runs in the web page, so it sees IndexedDB of the web page.

[Viet Ta]

Yeah, so this means that IndexedDB is not an equivalent replacement for chrome.storage.local since content-script can still access data in chrome.storage.local, while that is not true for IndexedDB. Then what's the equivalent replacement here?

[woxxom]

You can use messaging in the content script and IndexedDB in the background script or in the offscreen document.