Storage API: what entrypoints can this be used at?

[marcellino-ornelas]

👋🏽 Hello, love your library and have a quick question I couldn't find a answer for. Where can the storage API be used at? is this supported in all places? I thought I read that this cant be used in content scripts but wasn't sure 🤔 If we did need to use localStorage in a content script do we need to just default back to the old way and use the native local storage?

[aiktb]

The storage API can be used in content script, background, popup and other extension contexts. In fact, the reason why chrome.storage exists is to solve the problem that localStorage cannot be accessed across extension contexts.

If you don't need to access certain data in popup or background, then you don't need to store it in chrome.storage. Just be aware that localStorage can be modified by sources other than your extension, such as the website itself and other content scripts injected into the website.

Additional Information:

options and popup can share localStorage, but background cannot, because localStorage is not available in Service Worker. options, popup, and background can share indexeddb.

[marcellino-ornelas]

Perfect 🙌🏽 thank you for your response

options and popup can share localStorage, but background cannot, because localStorage is not available in Service Worker. options, popup, and background can share indexeddb.

Can content scripts and popups share the same storage?

[aiktb]

The localStorage of popup pages and content scripts are not interoperable, and there is no easy way to synchronize data between the two.

The easiest way to share data between the two is chrome.storage, but by using the background as a proxy, content scripts can actually access indexeddb as well, which is useful when storing more data than the maximum quota of chrome.storage can hold.