Open Bug 1670278 Opened 3 years ago Updated 7 months ago

Enable extensions to send network requests (fetch) with a specific cookieStoreId (container tab context)


(WebExtensions :: Request Handling, enhancement, P3)



(Not tracked)


(Reporter: robwu, Unassigned, NeedInfo)


(Depends on 1 open bug, Blocks 1 open bug)


(Whiteboard: mv3:m2 [mv3-m2] )

Extensions do currently not have a way to send network requests on behalf of container tabs. We should offer an API to allow extensions to perform requests for a specific container. Currently, the only work-around is to open a (background) tab with a specific cookieStoreId and performing the request from there. That's not ideal as it may distract the user.

PS. There has been much more discussion about relevant forms of isolation at

See Also: → 1649106

It kind of feels weird to have a separate extension API that is almost identical to fetch, so I suggested adding a chrome/extension only param to fetch in bug 1578405 comment 4, but that also kinda feels weird.

Severity: -- → S3
Priority: -- → P3

The number of ways to isolate requests is becoming increasingly large, and it is not feasible to keep updating extensions to support all scenarios:

  • Container tabs (this bug at first, following discussion from bug 1578405)
  • Private browsing mode (similar, following discussion from bug 1578405 , where incognito: "split" is used to force an isolation)
  • Cache Partitioning (bug 1687569)
  • (dynamic) First-Party isolation
  • HTTPS-Only mode (bug 1685862 has some discussion but we need a new bug)
  • Features tied to first-partiness (e.g. tracking protection, sameSite cookies)

It affects APIs that trigger requests, such as:

  • fetch / XMLHttpRequest

There are other APIs where the context may be relevant, such as:

  • browsingData (removing all data associated with a specific origin/partition/whatever form of isolation we have).
See Also: → 1687569, 1685862
See Also: → 1691907
Depends on: 1698863
Whiteboard: mv3:m1
See Also: → 1710251
See Also: → 1705134
No longer blocks: 1578405
Depends on: 1578405
Whiteboard: mv3:m1 → mv3:m2
Whiteboard: mv3:m2 → mv3:m2 [mv3-m2]

Does this issue track all kinds of contextual requests or just the container?

(In reply to eight04 from comment #3)

Does this issue track all kinds of contextual requests or just the container?

Originally filed for container tabs, but the scope has been expanded to cover more, e.g. see comment 2.

If possible, making cookieStoreId writeable is an option.

The option would be of great benefit when an extension has to make an HTTP request from background scripts while maintaining contextual identity (e.g. userscript managers etc)

fetch('', {
  method: 'GET',
  cookieStoreId: tab.cookieStoreId

const xhr = new XMLHttpRequest();'GET', '', true);
xhr.cookieStoreId = tab.cookieStoreId;

Note on
It is already possible to set cookieStoreId: 'firefox-container-1' but not cookieStoreId: 'firefox-private'

Error: Illegal to set private cookieStoreId in a non-private window{
  conflictAction: 'uniquify',
  cookieStoreId: tab.cookieStoreId !== 'firefox-private' ? tab.cookieStoreId : 'firefox-default',
  incognito: tab.incognito
Points: --- → 1
Whiteboard: mv3:m2 [mv3-m2] → mv3:m2 [mv3-m2]

Any update or workaround for this issue?

Also looking for an update on this, please consider addressing this.

Flags: needinfo?(lgreco)
You need to log in before you can comment on or make changes to this bug.