Network traffic annotation added to chrome::BitmapFetcher.

chrome/browser/autocomplete/chrome_autocomplete_provider_client.cc

Index: chrome/browser/autocomplete/chrome_autocomplete_provider_client.cc
diff --git a/chrome/browser/autocomplete/chrome_autocomplete_provider_client.cc b/chrome/browser/autocomplete/chrome_autocomplete_provider_client.cc
index 12d6b2f1c50ade6f3d7ab02dd611ca7995ebf8eb..6e92cac8697a1f0df02ad66eaddd3add0a492de2 100644
--- a/chrome/browser/autocomplete/chrome_autocomplete_provider_client.cc
+++ b/chrome/browser/autocomplete/chrome_autocomplete_provider_client.cc
@@ -34,6 +34,7 @@
 #include "components/sync/driver/sync_service_utils.h"
 #include "content/public/browser/notification_service.h"
 #include "extensions/features/features.h"
+#include "net/traffic_annotation/network_traffic_annotation.h"
 
 #if BUILDFLAG(ENABLE_EXTENSIONS)
 #include "chrome/browser/autocomplete/keyword_extensions_delegate_impl.h"
@@ -248,7 +249,27 @@ void ChromeAutocompleteProviderClient::PrefetchImage(const GURL& url) {
   BitmapFetcherService* image_service =
       BitmapFetcherServiceFactory::GetForBrowserContext(profile_);
   DCHECK(image_service);
-  image_service->Prefetch(url);
+  net::NetworkTrafficAnnotationTag traffic_annotation =
+      net::DefineNetworkTrafficAnnotation("", R"(
+        semantics {
+          sender: ""

[Justin Donnelly, 2017/02/14 17:01:05]

As pkasting points out, these should be identical to values I specified in my
response for chrome_omnibox_client.cc. Can you add a function here that would
return the proto and use it in both locations? Or would you prefer I do that in
a separate CL?

[Ramin Halavati, 2017/02/15 11:52:02]

To keep the clang tool that extracts annotation simple and remove the need to
use run time data, we would like to have annotations as constants defined in the
same compilation unit that initializes the call. Therefore I think if both these
functions need exactly similar annotation, may be we can create a function Foo
that both these call sites call Foo and Foo creates the annotation and fetches
or prefetches the image. How does it sound?

[Justin Donnelly, 2017/02/15 21:39:44]

That seems reasonable. But if we're going to introduce a new file and/or class
with methods delegating both prefetch and fetch with a callback I wonder if
we're better off just keeping it simple and duplicating the two specifications
with a comment in each directing people to change both at once.

Peter, wdyt?

[Peter Kasting, 2017/02/16 00:05:21]

If the tools can handle the following proposal, it's what I would do, but I
don't know if they can:

* Create a helper function here that takes a Callback
* The helper creates the traffic annotation and executes the Callback, passing
it the annotation
* Callers bind the Prefetch() or RequestImage() calls up into the necessary
callback and pass it in

This way the helper is simpler and doesn't need to take args that would only be
used for the non-prefetch case.

I would try to avoid duplicating the annotation in two places, though.  If all
else failed, I'd go ahead with a helper that took more args and was uglier.  :/

[Ramin Halavati, 2017/02/16 07:03:30]

The Callback solution seems good. If you agree, I would duplicate the annotation
here and add a note on top of both annotations that these will be merged in
another CL.

+          description: ""
+          trigger: ""
+          data: ""
+          destination: WEBSITE/GOOGLE_OWNED_SERVICE/OTHER
+        }
+        policy {
+          cookies_allowed: false/true
+          cookies_store: ""
+          setting: ""
+          policy {
+            [POLICY_NAME] {
+                policy_options {mode: MANDATORY/RECOMMENDED/UNSET}
+                value: ...
+            }
+          }
+        })");
+  image_service->Prefetch(url, traffic_annotation);
 }
 
 void ChromeAutocompleteProviderClient::OnAutocompleteControllerResultReady(