Add a histogram for omnibox answer suggestion types.

components/omnibox/browser/search_suggestion_parser.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 "components/omnibox/browser/search_suggestion_parser.h"
 
 #include <stddef.h>
 #include <algorithm>
 #include <utility>
 
@@ skipping 506 matching lines @@
           suggestion_detail->GetString("q", &suggest_query_params);
 
           // Extract the Answer, if provided.
           const base::DictionaryValue* answer_json = NULL;
           if (suggestion_detail->GetDictionary("ansa", &answer_json) &&
               suggestion_detail->GetString("ansb", &answer_type_str)) {
             bool answer_parsed_successfully = false;
             answer = SuggestionAnswer::ParseAnswer(answer_json);
             int answer_type = 0;
             if (answer && base::StringToInt(answer_type_str, &answer_type)) {
+              UMA_HISTOGRAM_SPARSE_SLOWLY("Omnibox.AnswerType", answer_type);

[Justin Donnelly, 2017/03/02 19:00:13]

Is this the right way to log this? These type IDs used to be sparse values like
2883 and 1372 so this is how I did it in the old Android-only histogram. Now
they're in a new, tight range (currently 1-10). But UMA_HISTOGRAM_ENUMERATION
doesn't seem right because the ID comes from the server so I can't guarantee
it's less than some man enum value. I guess I could define an enum in this file
and if the ID is greater than its max, log an error/0 case? Or is there some
other macro designed for this circumstance?

[Mark P, 2017/03/02 20:59:35]

Aren't there almost always zero or only one answer?
Hopefully sparse histograms are still the right solution.

[Ilya Sherman, 2017/03/02 21:17:32]

I recommend sparse histograms over enumerated histograms in most cases where the
histogram isn't being recorded in a tight loop.  So, yeah, I'd imagine that it's
a good choice here.

[Justin Donnelly, 2017/03/02 21:21:25]

Yes, there's always zero or one. When there's an answer, it includes an int type
and that type is in the range of 1-10 (defined as AnswerTriggererKey in
http://google3/logs/proto/suggest/suggest_extensions.proto).

Is there an implication of fact that there's only 0 or 1 answers I'm not
accounting for here?

[Mark P, 2017/03/02 23:28:48]

No "implication."  It just means that you're not calling
UMA_HISTOGRAM_SPARSE_SLOWLY() repeatedly in a tight loop.  You're calling it at
most once, so its possible slowness doesn't matter.

               answer_parsed_successfully = true;
 
               answer->set_type(answer_type);
               answer->AddImageURLsTo(&results->answers_image_urls);
 
               std::string contents;
               base::JSONWriter::Write(*answer_json, &contents);
               answer_contents = base::UTF8ToUTF16(contents);
             } else {
               answer_type_str = base::string16();
@@ skipping 10 matching lines @@
           base::CollapseWhitespace(match_contents, false),
           match_contents_prefix, annotation, answer_contents, answer_type_str,
           std::move(answer), suggest_query_params, deletion_url,
           is_keyword_result, relevance, relevances != NULL, should_prefetch,
           trimmed_input));
     }
   }
   results->relevances_from_server = relevances != NULL;
   return true;
 }