User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180516032328 Steps to reproduce: This is a feature I would love to see together with Bug 1340511: I want to be able to get some statistics grouped by domain using the browsingData API. As a web-extension I'd like to be able to inspect what the "Manage Cookies and Site Data" dialog currently shows, but for all the data available in the browsingData API. I would imagine this to look something like this: browsingData.getStatistics(): Promise<BrowsingDataStatisticsEntry[]> This could be a hash with key=hostname instead of a list as well, doesn't matter that much to me. With: interface BrowsingDataStatisticsEntry { hostname: string; lastUsedTimestamp: number; cacheSize: number; cookieCount: number; downloadCount: number; fileSystemsSize formDataCount: number; historyCount: number; indexedDBSize: number; localStorageSize: number; passwordsCount: number; pluginDataSize: number; serverBoundCertificatesCount: number serviceWorkersCount: number; totalSize: number; } My usecase: My extension "Forget Me Not" wants to clear data on certain events. Currently, there is no way to list most of these data entries, so I'd have to track all domains in the background to even be able to delete by domain. There is no security risk, since I don't need access to the actual data, just some statistics, so I can see there is a domain which needs to be cleaned. It would be really nice if this landed at the same time or even before Bug 1340511 to unleash it's full potential. Actual results: The API is not yet available Expected results: The API should be available.

Forgot that it would be good to have a cookieStoreId attribute on it as well and get one entry per cookie store that has data (i.e. support for contextualIdentities)

Hi Lusito, this bug has been added to the agenda for the WebExtensions APIs triage on July 10, 2018. Would you be able to join us? Here’s a quick overview of what to expect at the triage: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting * Meeting agenda: https://docs.google.com/document/d/1Y_oYPldTT_kQOOouyJbC-8y3ASIizScLKFRhQfsDQWI/edit#heading=h.mr8julfcusgv * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Hi Caitlin, I will be there.

This was discussed at the last triage meeting. Outcome: Approved, but conditional on an engineering and privacy review. There isn't time in a triage meeting to properly understand the scope of this proposed API, and there was some feeling that it might be a bit complicated to implement. We'd also want to verify that there are no privacy or security concerns when surfacing this information.