Needed for r-b and fenix in the future.

Probably a way to select which parts of data to be cleared similar to fennec (with an new API):

GeckoBundle().apply {
    listOf(
        "openTabs",
        "history",
        "searchHistory",
        "downloadFiles",
        "formdata",
        "cookies_sessions",
        "cache",
        "offlineApps",
        "siteSettings",
        "syncedTabs",
        "passwords"
    ).map {
        putBoolean(it, true)
    }
}.also { bundle ->
    geckoSession.eventDispatcher.dispatch("Sanitize:ClearData", bundle)
}

Needed for r-b and fenix in the future.

Flagging Chris to add the right whiteboard labels and priorities.

[geckoview:fenix:p2] nice-to-have for Fenix MVP unless someone speaks up.

See r-b #81 for the UI work.

Adding [geckoview:fenix:m5] whiteboard tag because the Fenix team would like this API for Fenix MVP.

https://github.com/mozilla-mobile/android-components/issues/1798
https://github.com/mozilla-mobile/fenix/issues/225
https://github.com/mozilla-mobile/fenix/issues/980

Eugen, can you take a look at this bug for Fenix MVP?

The Fenix team would like a user option to clear all user data for Fenix MVP: mozilla-mobile/fenix#225. Selectively clearing data for individual sites or data types is not needed for Fenix MVP, but snorp says that we should probably go ahead and implement the GV API for selective clearing now.

(In reply to Chris Peterson [:cpeterson] from comment #5)

Eugen, can you take a look at this bug for Fenix MVP?

The Fenix team would like a user option to clear all user data for Fenix MVP: mozilla-mobile/fenix#225. Selectively clearing data for individual sites or data types is not needed for Fenix MVP, but snorp says that we should probably go ahead and implement the GV API for selective clearing now.

I think what I was getting at is that we need Sanitizer.jsm or something like it exposed in GV. But for the public API maybe we'd just start with a "nuke everything from orbit" API and add the selections later.

James is concerned that GV's sanitizer stays in sync with desktop if new user data types are added.

I think we could provide a powerful API here by exposing a subset of nsIClearDataService through our StorageController API.

Proposed API:

StorageController {
  ClearFlags {
    COOKIES
    NETWORK_CACHE
    IMAGE_CACHE
    HISTORY
    DOM_STORAGES
    AUTH_SESSIONS
    PERMISSIONS
    ALL_CACHES
    SITE_SETTINGS
    SITE_DATA
    ALL // 0xFFFFFF so shouldn't be affected by changing or new flags
  }

  void clearDataFromHost(String host, ClearFlags flags)

  void clearDataInTimeRange(Time from, Time to, ClearFlags flags)

  void clearData(ClearFlags flags)
}

The ClearFlags selection would be composed based on desktop's Sanitizer setup to provide a powerful yet not overloaded API.

The ClearFlags constants would need to maintain a consistent mapping to nsIClearDataService, which we hopefully can monitor through tests. Any additions to nsIClearDataService would need to be exposed through the GV API, if applicable.

Baku and snorp, do you see any issues with exposing this API to app consumers and would you agree with the proposed flag selection?

Looks good to me!

It seems a good idea. I have a couple of comments:

void clearDataFromHost(String host, ClearFlags flags)

This is fine, but:

1. what about OriginAttributes? How to delete data for 1 particular container, for instance, for 1 particular GeckoView session ID?

2. We need good documentation here, because this method would delete data for 1 single origin and I suspect it could be used wrongly: for instance, if we have 1 tab open, when deleting the first-party origin, firefox doesn't delete all the third party origins...
   This is actually an existing bug in 'forget about site'.

void clearDataInTimeRange(Time from, Time to, ClearFlags flags)

The time range is not fully supported by all the flags/storages. For some of them, we have to delete all. In your list, time range is not supported by: network cache, image cache, dom storages and auth sessions.

(In reply to Andrea Marchesini [:baku] from comment #10)

It seems a good idea. I have a couple of comments:

void clearDataFromHost(String host, ClearFlags flags)

This is fine, but:

1. what about OriginAttributes? How to delete data for 1 particular container, for instance, for 1 particular GeckoView session ID?

Sorry for the confusion, I've left it out because that's already been reviewed in bug 1501108. I'm actually moving the clearSesssionContextData API out of bug 1501108 into this.

2. We need good documentation here, because this method would delete data for 1 single origin and I suspect it could be used wrongly: for instance, if we have 1 tab open, when deleting the first-party origin, firefox doesn't delete all the third party origins...
   This is actually an existing bug in 'forget about site'.

Interesting, is there a way around that bug? Maybe you can link me to the existing bug so that I can make sure the docs reflect that properly.

void clearDataInTimeRange(Time from, Time to, ClearFlags flags)

The time range is not fully supported by all the flags/storages. For some of them, we have to delete all. In your list, time range is not supported by: network cache, image cache, dom storages and auth sessions.

I can add that to the docs, or we could leave this out of the API completely, since it isn't part of the current requirement.

Thanks!

Depends on D31329

Depends on D32153

Removed the time range-based clearing because it has too many implementation restrictions that would need to be communicated and enforced.
Removed the session context-based clearing because it's still blocked on bug 1501108.

Moved the clear flags mapping into the JSM module to help with keeping the values in sync.

Extended and fixed tests. We can't load from the local test path due to the URI scheme restrictions and setting/getting localStorage or cookies via evaluateJS yielded a security error.
The tests now depend on Agi's WebExt support for evaluateJS to fix that.

Landing the API patch now to unblock Fenix, will land test patch once bug 1553515 lands.

https://hg.mozilla.org/mozilla-central/rev/1912d221317a

Comment on attachment 9066725 [details]
Bug 1489669 - [1.4] Add Storage Controller API.

Beta/Release Uplift Approval Request

• User impact if declined: This a Fenix MVP release blocker.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This adds a new GeckoView API without affecting existing features.
  There are automated tests (second patch on this bug) and they pass, but they depend on bug 1553515 to land.
• String changes made/needed: None

Comment on attachment 9066725 [details]
Bug 1489669 - [1.4] Add Storage Controller API.

new gv API, approved for 68.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/d6c54c50418c

https://hg.mozilla.org/mozilla-central/rev/b310943c988b