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

Status: NEW

(WebExtensions :: Request Handling, enhancement, P3)

Description

[Rob Wu [:robwu]]

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1578405#c11

Comment 1

[Tomislav Jovanovic :zombie]

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.

Comment 2

[Rob Wu [:robwu]]

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:

• browser.downloads.download
• 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).

Comment 3

[eight04]

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

Comment 4

[Rob Wu [:robwu]]

(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.

Comment 5

[erosman]

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('https://example.com/', {
  method: 'GET',
  cookieStoreId: tab.cookieStoreId
})


const xhr = new XMLHttpRequest();
xhr.open('GET', 'http://example.com/', true);
xhr.cookieStoreId = tab.cookieStoreId;
xhr.send(null);
});

Note on downloads.download
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

browser.downloads.download({
  url,
  filename,
  saveAs,
  conflictAction: 'uniquify',
  cookieStoreId: tab.cookieStoreId !== 'firefox-private' ? tab.cookieStoreId : 'firefox-default',
  incognito: tab.incognito
});

Comment 6

[Arnoud Kooi]

Any update or workaround for this issue?

Comment 7

[z0mb]

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

Comment 8

[Dmitry Alexandrov]

Currently, the only work-around is to open a (background) tab with a specific cookieStoreId and performing the request from there

Can anyone suggest an example of webext that works around of this bug?