Move BrowsingDataRemover to content/

content/public/browser/content_browser_client.h

Index: content/public/browser/content_browser_client.h
diff --git a/content/public/browser/content_browser_client.h b/content/public/browser/content_browser_client.h
index f360af58e0c3c3613fb5d3b86bd224d49d289a19..3c8feca852ac7416d60d8e45ac45cf22b226e9a7 100644
--- a/content/public/browser/content_browser_client.h
+++ b/content/public/browser/content_browser_client.h
@@ -542,15 +542,18 @@ class CONTENT_EXPORT ContentBrowserClient {
   virtual void BrowserURLHandlerCreated(BrowserURLHandler* handler) {}
 
   // Clears browser cache.
+  // TODO(crbug.com/668114): Deprecated. Use BrowsingDataRemover instead.
   virtual void ClearCache(RenderFrameHost* rfh) {}
 
   // Clears browser cookies.
+  // TODO(crbug.com/668114): Deprecated. Use BrowsingDataRemover instead.
   virtual void ClearCookies(RenderFrameHost* rfh) {}
 
   // Clears |browser_context|'s data stored for the given |origin|.
   // The datatypes to be removed are specified by |remove_cookies|,
   // |remove_storage|, and |remove_cache|. Note that cookies should be removed
   // for the entire eTLD+1 of |origin|. Must call |callback| when finished.
+  // TODO(crbug.com/668114): Depreacated. Use BrowsingDataRemover instead.
   virtual void ClearSiteData(content::BrowserContext* browser_context,
                              const url::Origin& origin,
                              bool remove_cookies,
@@ -558,6 +561,9 @@ class CONTENT_EXPORT ContentBrowserClient {
                              bool remove_cache,
                              const base::Closure& callback) {}
 
+  // Whether the embedder allows deleting history for |browser_context|.
+  virtual bool MayDeleteHistory(BrowserContext* browser_context);

[jam, 2017/04/20 00:39:48]

it looks like DATA_TYPE_DOWNLOADS is only set by the embedder (i.e. in response
to settings UI or extensions code). if so, instead of chrome telling content to
delete downloads, and content having to check back with chrome, why not have
chrome do this check before telling content? then you don't need this method

[msramek, 2017/04/21 15:22:12]

Isn't that dangerous though? If someone adds a new DATA_TYPE_DOWNLOADS deletion
callsite inside content/, this check would be skipped. And it's an intended
result of this refactoring that people may start using BrowsingDataRemover for
deleting datatypes in content.

If DATA_TYPE_DOWNLOADS is to stay in content/, I think we need the current
format. Alternatively, we can move it into the embedder until someone needs it
in content/ for the first time.

[jam, 2017/04/21 22:58:30]

Can you perhaps add a dcheck that DATA_TYPE_DOWNLOADS is only specified by the
embedder? then only if we need to call this in content do we add this new api

[msramek, 2017/04/25 01:29:09]

Unfortunately, no. Inside BrowsingDataRemoverImpl::RemoveImpl, we don't know who
the caller is.

But now that we decided to keep BrowsingDataRemoverDelegate after all, can we
just put the method there? I have done that in my latest patchset. The name
MayRemoveDownloadHistory() is still somewhat Chrome-specific at this point, but
can be easily expanded to something more generic like MayRemove(int remove_mask)
if needed.

+
   // Returns the default download directory.
   // This can be called on any thread.
   virtual base::FilePath GetDefaultDownloadDirectory();