MV3 in-memory storage API (storage.session)
Categories
(WebExtensions :: Storage, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: mixedpuppy, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
(Whiteboard: [addons-jira][wecg])
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Added link to the related Chromium bug as a see also.
Based on a quick look to the issue comment and patches attached, the related API namespace in Chrome is going to be chrome.storage.session.
Updated•4 years ago
|
Comment 2•3 years ago
|
||
Hello,
After migrating many of my addons to Manifest V3 in the past few weeks, I can tell you this is the API I miss the most and it would help a lot with the MV3 compatibility for the uses that want to support both Firefox and Chrome.
Before with persistent background scripts, everything defined on the top level was automatically "in-memory-storage".
In MV3 this changed drastically so now one have to use chrome.storage.session API instead.
Even for a trivial things like:
- running code after extension start (since service worker re-starts all the time)
- storing any session related values
- storing sensitive values, like decryption keys
I don't know how hard it is to implement, but the API is mostly the same as browser.storage.local, except for:
- stored in memory only
- not available in content scripts
- lower quota (1MB)
Thanks!
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Why is there a dependency on the Service Worker bug 1573659?
I would say this API is needed also for the event pages since they can't store session data anymore.
BTW, Safari only recently added 'storage.session' in the Technology Preview Release 151.
| Comment hidden (me-too) |
| Comment hidden (advocacy) |
| Comment hidden (advocacy) |
Comment 7•2 years ago
|
||
The limit is going to be 10 MB, not 1 MB - https://github.com/w3c/webextensions/issues/350
Comment 8•2 years ago
|
||
Copying comment from https://bugzilla.mozilla.org/show_bug.cgi?id=1724754#c1 :
The storage.session API is supposedly restricted to extension processes (not content scripts) by default (https://developer.chrome.com/docs/extensions/reference/storage/#storage-areas)
When storage.session (bug 1687778) is implemented, we should at least implement the
storage.session.setAccessLevelAPI, which should be documented asStorageArea.setAccessLevel.
I have added details to the storage.session documentation at https://github.com/mdn/content/pull/24873 ; we should document the setAccessLevel method and update the BCD once this bug is fixed.
Comment 9•2 years ago
|
||
According to 115beta release notes, an (initial?) implementation of storage.session is available from that version. I assume that is https://bugzilla.mozilla.org/show_bug.cgi?id=1823713 which is closed and I'm not allowed to add comment to it.
But this bug, the mentioned 1823713 or the doc at https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/storage/session doesn't tell if this is for MV3 only, or if it also can be used with MV2. But since all the talk and references generally is all about MV3, I assume it can't be used with MV2?
But MV2 supports non-persistent background scripts, and storage.session is (or would be) a great help for making use of that. Also as a step to easier MV3 migration later. Just a thought, I have no idea if it is just a simple switch or if it would be a lot of work to make available in both MV2 and MV3.
Comment 10•2 years ago
|
||
There's nothing in the patch for bug 1823713 that limits this to mv3. If something doesn't work for you, please file a bug.
Comment 11•2 years ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Description
•