permissionrequest API for guest Download.

content/public/browser/web_contents_delegate.h

Index: content/public/browser/web_contents_delegate.h
diff --git a/content/public/browser/web_contents_delegate.h b/content/public/browser/web_contents_delegate.h
index 6705514a7bc03dd437982049294404eedc0e92ab..128bb9a8d764e4df96d27650ef59109a25bab87f 100644
--- a/content/public/browser/web_contents_delegate.h
+++ b/content/public/browser/web_contents_delegate.h
@@ -223,6 +223,10 @@ class CONTENT_EXPORT WebContentsDelegate {
   virtual bool CanDownload(RenderViewHost* render_view_host,
                            int request_id,
                            const std::string& request_method);
+  virtual void CanDownloadAsync(RenderViewHost* render_view_host,

[asanka, 2013/03/25 18:15:11]

Why are you adding another callback instead of making CanDownload async? 

With this CL, CanDownloadAsync() is only called when
WebContents::GetRenderProcessHost()->IsGuest() is true. And CanDownload() is
only called when that condition is false.

[lazyboy, 2013/03/25 18:36:40]

I was worried of slowing down !IsGuest() case (which should be by far the most
common case) by making them async.
Is it acceptable to make CanDownload async for all cases?
Ty.

[asanka, 2013/03/25 18:58:11]

Yes. The delegate can always invoke the callback synchronously if it can respond
immediately.

Part of the problem is that the distinction between the two callbacks is not
clear at all from the content/ API. On the surface it looks like it's sync vs.
async. But in reality it's based on whether or not the render process host is
associated with a guest renderer.

Having a single API is simpler. Please indicate here that it's permissible to
invoke the callback synchronously.

[lazyboy, 2013/03/25 20:13:05]

Changed back to single CanDownload() function.
Done.

+                                int request_id,
+                                const std::string& request_method,
+                                const base::Callback<void(bool)>& callback);
 
   // Return much extra vertical space should be allotted to the
   // render view widget during various animations (e.g. infobar closing).