Bugzilla

(In reply to Luca Greco [:rpl] from comment #3)
> This API has been inherited by the ones supported on Chrome, and [indexedDB and localStorage are two of the supported data types](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/DataTypeSet), and technically they could be used separately from each other by the extensions that uses this API.

I said this in https://bugzilla.mozilla.org/show_bug.cgi?id=1526246#c3 too, but I think the only reasonable course of action is to map these fine-grained deletion requests onto "site data".  I think it's reasonable to separate "cookies".  For a sort of meta-discussion where I expound, at length, on this, check out bug 1488583.

But for a shorter recap here:
- Web standards promise that origins will be cleared at a "bucket" granularity for an origin.  For now this means all "site data".  It's very likely for a site's ServiceWorker to depend on specific IndexedDB and Cache API state and to break if only part of the data is cleared.  If only part of the data is cleared, it's possible that sites will break, which is bad for them and bad for any resulting Firefox support costs, as the only answer to such a problem is "don't do that".
- It's very dangerous for an API that deals with privacy-related things to be able to accidentally miss things.  The user intent of clearing data is very clear.  Because of attempting to follow this API we have bug 1526246 where user-intent is not honored.  If the API gains additional distinct partitions and a WebExtension is not updated to use them, peronsal data will be potentially be left behind, etc.
- It is conceivable that there will be individuals who have a specific reason to want to clear only IndexedDB, etc. as is/was the case in bug 1488583.  However, it's not clear that this is a use-case we want to support for both the aforementioned support reasons and the potential risk for bugs/oversights in WebExtension code where what users of the WebExtension think is happening is not actually what's happening.

(In reply to Luca Greco [:rpl] from comment #3)
> This API has been inherited by the ones supported on Chrome, and [indexedDB and localStorage are two of the supported data types](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/DataTypeSet), and technically they could be used separately from each other by the extensions that uses this API.

I said this in https://bugzilla.mozilla.org/show_bug.cgi?id=1526246#c3 too, but I think the only reasonable course of action is to map these fine-grained deletion requests onto "site data".  I think it's reasonable to separate "cookies".  For a sort of meta-discussion where I expound, at length, on this, check out bug 1488583.

But for a shorter recap here:
- Web standards promise that origins will be cleared at a "bucket" granularity for an origin.  For now this means all "site data".  It's very likely for a site's ServiceWorker to depend on specific IndexedDB and Cache API state and to break if only part of the data is cleared.  If only part of the data is cleared, it's possible that sites will break, which is bad for them and bad for any resulting Firefox support costs, as the only answer to such a problem is "don't do that".
- It's very dangerous for an API that deals with privacy-related things to be able to accidentally miss things.  The user intent of clearing data is very clear.  Because of attempting to follow this API we have bug 1526246 where user-intent is not honored.  If the API gains additional distinct partitions and a WebExtension is not updated to use them, personal data will be potentially be left behind, etc.
- It is conceivable that there will be individuals who have a specific reason to want to clear only IndexedDB, etc. as is/was the case in bug 1488583.  However, it's not clear that this is a use-case we want to support for both the aforementioned support reasons and the potential risk for bugs/oversights in WebExtension code where what users of the WebExtension think is happening is not actually what's happening.