Open Bug 1687778 Opened 4 years ago Updated 2 days ago

MV3 in-memory storage API (storage.session)


(WebExtensions :: Storage, enhancement, P3)



(Not tracked)


(Reporter: mixedpuppy, Unassigned)


(Depends on 2 open bugs, Blocks 2 open bugs)


(Whiteboard: [addons-jira][wecg])

No description provided.
Type: task → enhancement

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

Summary: MV3 in-memory storage API → MV3 in-memory storage API (storage.session)

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 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, except for:

  • stored in memory only
  • not available in content scripts
  • lower quota (1MB)


Whiteboard: [addons-jira]
Points: --- → 5
Priority: -- → P2

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.

The limit is going to be 10 MB, not 1 MB -

Whiteboard: [addons-jira] → [addons-jira][wecg]

Copying comment from :

The storage.session API is supposedly restricted to extension processes (not content scripts) by default (

When storage.session (bug 1687778) is implemented, we should at least implement the storage.session.setAccessLevel API, which should be documented as StorageArea.setAccessLevel .

I have added details to the storage.session documentation at ; we should document the setAccessLevel method and update the BCD once this bug is fixed.

Depends on: 1823713
Depends on: 1823714
Depends on: 1823717

According to 115beta release notes, an (initial?) implementation of storage.session is available from that version. I assume that is which is closed and I'm not allowed to add comment to it.
But this bug, the mentioned 1823713 or the doc at 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.

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.

Depends on: 1908925
You need to log in before you can comment on or make changes to this bug.