Manifest V3: what to do about localStorage?

[Kent Brewster]

From a recent response by Simeon Vincent to [crx] "Minimum Permission" for "Copy Unicode URLs":

> With regard to your question about localStorage, I'd recommend against using that because it won't be available to service workers in Manifest V3.

I don't see any mention of localStorage being deprecated in https://developer.chrome.com/extensions/migrating_to_manifest_v3, and my poor socially-isolated brain does not recall hearing anything about it prior to right now. (Yes, it makes total sense, because service workers have no DOM, but I feel like it ought to be surfaced a bit higher and maybe even mentioned in the migration guide?)

Do we know if IndexedDB is working/will work for background service workers in Chrome extensions with Manifest V3? If so, can anyone show me how to migrate data currently in localStorage in a Manifest V2 extension to IndexedDB when updating to Manifest V3?

The specific problem I'm trying to solve: we have a persistent UUID for each install in localStorage, and we would dearly love to keep it when we go to Manifest V3.

Thanks very much,

--Kent

[Jerry Krinock]

On 2020 Apr 24, at 09:33, 'Kent Brewster' via Chromium Extensions <chromium-...@chromium.org> wrote:

> we have a persistent UUID for each install in localStorage, and we would dearly love to keep it when we go to Manifest V3.

We do a similar thing and would also appreciate an answer to this question.

Jerry

[Hr Gwea]

The solution is simple. Stop using the synchronous window.localStorage API and start using the asynchronous chrome.storage.local API.

IndexedDB is available in workers, so yes, it should be available in the new MV3 service worker too. But chrome.storage.local is a simpler API, so use that one.

//Get the UUID from localStorage
let UUID = window.localStorage.getItem('UUID');
//Save the UUID to chrome.storage
chrome.storage.local.set( {UUID}, ()=>{
    console.log('UUID saved successfully') ;
}) ;

[Extension Developer]

The question is not how to use chrome.storage API.
The question is how to access localStorage value in service worker?

[PhistucK]

localStorage is not supported in service workers, so you cannot.

☆PhistucK

On Sun, Apr 26, 2020 at 10:46 AM Extension Developer <soldatovm...@gmail.com> wrote:

The question is not how to use chrome.storage API.
The question is how to access localStorage value 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/176c2bae-bd6e-4972-8600-b74db4dddd9e%40chromium.org.

[Kent Brewster]

Here's what I have so far, please correct me if I'm mis-hearing:

1: I'm correct in assuming chrome.storage.local (sorry, should not have abbreviated this to localStorage, because it could be interpreted as window.localStorage running in a content scriptt) will not work in Manifest V3.

2: IndexedDB is available in service workers so it SHOULD be available in Manifest V3.

It sounds like one way forward -- remember the goal: what we want to do is rescue our current UUIDs, which live in chrome.storage.local on the background page's DOM -- may be to get indexedDB working under Manifest V2, transfer our UUIDs, and then see if our service worker can access the same indexedDB under Manifest V3.

Does this seem sane? If so, can anyone point me to an example of an extension's service worker talking to indexedDB?

Thanks very much,

--Kent

[Hr Gwea]

chrome.storage.local is an asynchronous API so it'll keep working in the MV3 service worker. If you are already using it, you don't need to change anything.

[Simeon Vincent]

1. This is incorrect. Service workers can access the following storage related APIs: chrome.storage.local, chrome.storage.sync, and the indexedDB. The localStorage API is not available in service workers because it is a synchronous API.

2. I'd tweak your statement slightly to say that indexedDB is available in service workers and IS available in Manifest V3. 

Since you're already using chrome.storage.local, you don't have to replace your storage API with another option if you don't wish to.

Cheers,

Simeon - @dotproto

Extensions Developer Advocate

[Kent Brewster]

That's great, thanks! Sorry to rattle cages uneccessarily!

--Kent

> --
> 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/1f62b5d4-39e8-49e2-a3ec-1b23c9f1abf3%40chromium.org.

[馮韋元]

Any suggestions on how to migrate window.localStorage to chrome.storage.local when the "storage" permission was not previously granted?

Adding a new permission generally results in the extension being disabled. Would there be exceptions when switching from Manifest V2 to V3?

[wOxxOm]

> Any suggestions on how to migrate window.localStorage to chrome.storage.local when the "storage" permission was not previously granted?

Adding a new permission generally results in the extension being disabled. Would there be exceptions when switching from Manifest V2 to V3?

The "storage" permission doesn't have a warning at installation (more info) so adding it won't disable the extension. As for migration, you'll have to open an onboarding page on upgrade (it's simply an html file with scripts inside your extension package), which will be able to transfer the data from localStorage to chrome.storage.local.

[Dylan Barrell]

Storage is actually suggested as the way to persist state in V3 https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/#state