1353726 - Consider extending browsingData.RemovalOptions to allow removal by cookieStoreId

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Jonathan Kingston [:jkt] he/him]

For the containers experiment we are getting requests for the ability to behave like private tabs in certain circumstances or move from one container to another.

Adding the ability to do the following:
browser.browsingData.remove(
  {cookieStoreId: "firefox-default"},
  {cookies: true, history: true, formData: true, cache: true, ...}
);

For moving to another container we actually might need (this might need a separate bug though):

browser.browsingData.move(
  {cookieStoreId: "firefox-default"},
  {cookieStoreId: "firefox-container-1"},
  {cookies: true, history: true, formData: true, cache: true, ...}
);

This would allow a website to move it's data from one context to another cleanly.

Comment 1

[Andy McKay]

The move is probably more contentious, could you move that to a seperate bug. The ability to pass a cookieStoreId to browsingData makes sense though, we should do that.

Comment 2

[diyism]

Any progress? I'm still waiting for upgrade from firefox 57 to firefox quantum to use the two addons: "Private Tab" and "Proxy Privacy Ruler"

Comment 3

[diyism]

https://github.com/Infocatcher/Private_Tab_WE#issues  the addon Private Tab WE is blocked by issue #47 and issue 1353726

Comment 4

[diyism]

https://github.com/Infocatcher/Private_Tab_WE#issues  the addon Private Tab WE is blocked by issue 1283320(https://bugzilla.mozilla.org/show_bug.cgi?id=1283320) and issue 1353726(https://bugzilla.mozilla.org/show_bug.cgi?id=1353726)

Comment 5

[diyism]

Any progress? I'm still waiting for upgrade from firefox 56 to firefox quantum to use the two addons: "Private Tab" and "Proxy Privacy Ruler"

https://github.com/Infocatcher/Private_Tab_WE#issues  the addon Private Tab WE is blocked by issue 1283320(https://bugzilla.mozilla.org/show_bug.cgi?id=1283320) and issue 1353726(https://bugzilla.mozilla.org/show_bug.cgi?id=1353726)

Comment 6

[Ranjith Raj]

Hello, I'm the developer of a add-on that uses container feature. I found this bug when I was looking to add new feature of adding custom settings to the containers. Please update on status of this work.

Comment 7

[Tom S [:evilpie]]

I have written experimental implementation of this that uses nsIClearDataService.deleteDataFromOriginAttributesPattern. The means the user can't select which type of data (cookies, downloads etc.) is deleted. Instead it's just whatever this method deletes.

I think this could be used like browser.browsingData.remove({cookieStoreId: contextualIdentity}, {}). The second empty object is important, it basically tells the user that they can't select what they are going to delete. But maybe instead of abusing this API like that we should just add a new method?

Comment 8

[Tom S [:evilpie]]

Attachment: Bug 1353726 - Implement browsingData.remove({cookieStoreId})

Comment 9

[Rob Wu [:robwu]]

(In reply to Tom Schuster [:evilpie] from comment #7)

I think this could be used like browser.browsingData.remove({cookieStoreId: contextualIdentity}, {}).
The second empty object is important, it basically tells the user that they can't select what they are going to delete.

Ordinarily, if the second value is an empty object, nothing would be deleted. The proposed semantics is the opposite of that, and may be confusing.

But maybe instead of abusing this API like that we should just add a new method?

This implementation/proposal appears to largely be guided by the current implementation details.
If implementation details weren't a concern, then a cookieStoreId parameter to remove relevant data would be ideal.

Have you considered changing the internals to support deletion of data for a specific container tab? It looks like there is one (deprecated?) "clear-origin-attributes-data" notification and a bunch of deleteByOriginAttributes override that together are responsible for deleting all data: https://searchfox.org/mozilla-central/rev/165e8d8f80c02605c2f3e89c5de462abfce91c32/toolkit/components/cleardata/ClearDataService.jsm#1297-1327

Comment 10

[Tom S [:evilpie]]

Sadly it looks like deleteByOriginAttributes is not implemented by a lot of the existing cleaners, that is why I didn't go that route initially.

Comment 11

[Tom S [:evilpie]]

Okay. I guess we can start implementing this for cookies and indexedDB at least. And maybe for localStorage when GenLocalStorage is enabled.

Comment 12

[Rob Wu [:robwu]]

Consider filing a new blocking bug with the implementation (if it is a very narrow subset), or a follow-up bug (dependent on this bug) if your patch offers almost all functionality. Makes it easier to track the completeness of this feature.

Comment 13

[Tom S [:evilpie]]

Bug 1670811 just landed. browsingData.remove now supports the option cookieStoreId.

• This allows deleting default, private or container cookies.
• Deleting default or container indexedDB data.
• Deleting default or container localStorage data on Nightly. (Next-gen local storage is not enabled on release: bug 1599979)

Adding support for other data types is going to be more troublesome. It's going to require changes to nsIClearDataService. I am probably not going to work on that in the foreseeable future.

Comment 14

[Luca Greco [:rpl] [:luca] [:lgreco]]

The browsingData API docs and compatibility tables should be updated to mention this enhancement.

Some notes about the changes introduced are available in Tom's comment 13.

Comment 15

[Tom S [:evilpie]]

Let's move the dev-doc-needed to Bug 1670811.