Transitioning to chrome.storage in MV2, prepping for MV3

[Mike-O]

1. I need the Chrome Extensions Team at Google to respond. My MV2 extension has been using localStorage. In prepping for an easier transition of my extension users from MV2 to MV3, can I add the "storage" permission now to my v2 manifest and then do the following?

try {

  chrome.storage.local.set(localStorage);

} catch (e) {}

2. I'm worried about the above only working in development mode. Will that work in production?

3. What is the minimum browser version where this will work?

[Cuyler Stuwe]

1. This doesn’t seem like such a pressing urgent question that you’re likely to end up having the team themselves respond. 😅

2. Chrome APIs are async. This is different from the web local storage API, where all operations are synchronous (“blocking”).

3. Last I checked, Google still hasn’t converted all of the callback-based async functions to return promises that can be awaited. I don’t remember whether the storage functions were converted or not. If they are, you’re gonna want to await this call and wrap it (and any logic depending on it having been set) into an async function. If this isn’t one of the ones that has been carried over, then you’ll either need to wrap it in a Promise yourself or set up a callback as the last param.

--
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/1d7860cc-b60f-4173-9766-c3d9448588b3n%40chromium.org.

[Mike-O]

In my case, I'm just using this as a means for the transition, not to actually call chrome.storage.local.get() API until my extension eventually migrates to MV3. I just want to know that when I roll out the MV3 extension, previous people updating from my last MV2 extension to this new MV3 extension will have those settings migrated so that I can call it in chrome.storage.local.get(). Therefore, awaiting any promise isn't really necessary for me in my MV2 extension, but will be necessary for me in my MV3 extension. Note, that I tested the above function in my MV2 extension in development mode, then used the third party Chrome Storage Explorer extension to view chrome.storage.local, and sure enough those localStorage entries were there. I just need to know if I can rely on this in production, or does this only currently work in staging. And then I need to know what the minimum browser version needs to be before I implement chrome.storage because I have to place that in my manifest. As for the Chrome Extension team, I would certainly hope they would read this because now is the time to get ready for MV3 and have one's extension ready by mid Fall so that you can iron out any last minute tweaks before the hard deadline of Jan 1.

[Cuyler Stuwe]

The question still isn't totally clear, but I'll do my best:

1. localStorage doesn't exist in service workers.

2. The chrome.storage.local API works just fine in both MV2 and MV3. It's not specific to MV3 whatsoever; It's a very old API and has been the "correct" way to store things locally to your extension for the past decade.

3. The function you presented in your OP won't do anything useful after upgrading to an MV3 extension, because there will be no localStorage object existing within the service worker. However, window.localStorage is tied to an origin, and it seems to me that whatever had been stored there should be accessible post-upgrade to any chrome-extension:// window spawned by your extension.

4. Another option for something that works in both windows and service workers is IndexedDB. Dexie is my favorite library for smoothing out its awkward API.

[Mike-O]

Salem,

In response to your points:

1. Yep, aware of that, but didn't explain that to you. In my MV2 extension, I don't use a service worker, but a background.js, and localStorage works there, as does chrome.storage if I implement the "storage" permission. When my MV3 extension rolls out, it will not call localStorage. It will check chrome.storage.local for those entries (hopefully migrated from a previous MV2 extension I had), and, if they are there, then it will use them. Otherwise, it will start fresh settings in chrome.storage.local. And my MV3 extension, when it rolls out, will have a service worker instead of a background.js.

2. I didn't know that, if true. If it's such an old API, then how come Chrome DevTools still doesn't have a management panel for chrome.storage? How come I have to install a third party plugin called Chrome Storage Explorer to interact with it? And I especially want to know why I can read/write chrome.storage from my service worker but the Chrome Storage Explorer plugin won't work on the service worker DevTools?

3. That function will push things into chrome.storage.local in my MV2 extension so that when the upgrade to the MV3 extension occurs, I'll be able to read chrome.storage.local. Note, again, my MV3 extension will not talk to localStorage at all.

4. True that -- IndexedDB is a weird animal. I wish they would have implemented it as some sort of SQL. I've gotten it to work after a lot of hard work with promises. I'll take a look at Dexie -- it's probably doing the same thing that I figured out with my idb.js script that I created.

[Cuyler Stuwe]

1. Right. The stuff in chrome.storage.local should be there after the transition. I can't guarantee that Google won't break something, but there's no good reason why the stuff you put in chrome.storage.local in the MV2 extension shouldn't just be there after the MV3 upgrade.

2. I'd say the reason there's no management panel there is that Google has largely ignored the extensions platform over the past decade. To read/write data manually, I generally do e.g., "chrome.storage.local.set({key: val})" and "chrome.runtime.local.get(null, console.log)" in the background.js console. I would guess the reason the Chrome Storage Explorer plugin won't work in the SW is that it wasn't written to work properly within a service worker context (and perhaps even can't).

3. Timing is the only concern; If you're going to rely on this as your "upgrade mechanism" but aren't actually going to use chrome.storage.local in your current extension, then you need to have users run this as close to MV3 upgrade as possible (otherwise you risk stale data).

4. Dexie is great; It also seems to me to be the most widely-accepted library for this.

[Mike-O]

Exactly. You understand me now.

[Cuyler Stuwe]

Yeah.

I think what happened is mostly that you tripped yourself up by assuming this third-party storage explorer would work seamlessly in an MV3 environment. Relying on that for your representation of reality distorted your perception.

It's a nifty little tool, but it's not a great way to establish a mental model of what is accessible from where (for example, you can actually use the chrome.storage APIs directly within a content script, though the third-party extension you referenced doesn't allude to this).