Change tests to prepare for turning on the permission bubble flag.

chrome/browser/download/download_permission_request.cc

Index: chrome/browser/download/download_permission_request.cc
diff --git a/chrome/browser/download/download_permission_request.cc b/chrome/browser/download/download_permission_request.cc
index 18e19959337d86d03d0a7b0f729395e642298789..552a7e149d228bea854a96458e39320a4692365f 100644
--- a/chrome/browser/download/download_permission_request.cc
+++ b/chrome/browser/download/download_permission_request.cc
@@ -29,8 +29,10 @@ base::string16 DownloadPermissionRequest::GetMessageTextFragment() const {
 
 bool DownloadPermissionRequest::HasUserGesture() const {
   // TODO(gbillock): user gesture for multiple downloads is difficult to
-  // propagate, and the normal thing is that it is background.
-  return false;
+  // propagate, and the normal thing is that it is background. So lie to
+  // the manager and say it is user gestured. This needs to be examined
+  // for policy coherence...
+  return true;

[asanka, 2014/08/14 15:49:31]

Why is it necessary to invert this? Downloads that are initiated due to an
explicit user requests ('Save as' etc...) don't make it here. The ones that are
throttled are those that are considered "content initiated." I.e. the decision
to download was made by the content rather than the browser. Even if there was a
user gesture associated with it, it's not clear whether the gesture was
unambiguously indicating consent to download.

[Greg Billock, 2014/08/18 22:28:12]

It isn't clear what we want to do here. I think that's more your department to
figure out. There's no simple way to propagate the signal, so it's something
that if you want policy coherency on, will have to be done upstream. "return
false" is conservative, so that's what I put when I mocked out the original
client code. In practice, now that its going to turn on, it needs to return true
so things actually work.

[asanka, 2014/08/22 20:56:47]

Depends on how it's used. It seems that if any permission request has a user
action then the permission bubble is displayed?

Plumbing the actual user gesture flag up here isn't too hard. You can query it
on the IO thread at the time DownloadRequestLimiter::CanDownloadOnIOThread() is
called using content::ResourceRequestInfo::HasUserGesture().

[Greg Billock, 2014/09/05 17:41:05]

I looked into this, and I can't connect the dots from CanDownloadOnIOThread to a
ResourceRequestInfo object, or anything I think I have that connects to it.

But if this is only handling non-user-gestured requests, then the answer is
always false and I shouldn't change it. I'll just figure out another way to
drive the test.

 }
 
 GURL DownloadPermissionRequest::GetRequestingHostname() const {