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

chrome/browser/download/download_permission_request.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/download/download_permission_request.h"
 
 #include "content/public/browser/web_contents.h"
 #include "grit/generated_resources.h"
 #include "grit/theme_resources.h"
 #include "ui/base/l10n/l10n_util.h"
@@ skipping 11 matching lines @@
 base::string16 DownloadPermissionRequest::GetMessageText() const {
   return l10n_util::GetStringUTF16(IDS_MULTI_DOWNLOAD_WARNING);
 }
 
 base::string16 DownloadPermissionRequest::GetMessageTextFragment() const {
   return l10n_util::GetStringUTF16(IDS_MULTI_DOWNLOAD_PERMISSION_FRAGMENT);
 }
 
 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 {
   const content::WebContents* web_contents = host_->web_contents();
   if (web_contents) {
     return web_contents->GetURL();
   }
   return GURL();
 }
 
@@ skipping 12 matching lines @@
 }
 
 void DownloadPermissionRequest::Cancelled() {
   // TODO(gbillock): There's currently no suitable method for telling the host
   // that a request is cancelled.
 }
 
 void DownloadPermissionRequest::RequestFinished() {
   delete this;
 }