Use Instant suggested match type for Instant temporary text.

chrome/browser/autocomplete/search_provider.h

Index: chrome/browser/autocomplete/search_provider.h
diff --git a/chrome/browser/autocomplete/search_provider.h b/chrome/browser/autocomplete/search_provider.h
index 16f669f3bc095ccbc56d6f9629670011c1f3eece..2ea78f4a8a18d16063e61bee38240eb05c3c71fa 100644
--- a/chrome/browser/autocomplete/search_provider.h
+++ b/chrome/browser/autocomplete/search_provider.h
@@ -73,6 +73,17 @@ class SearchProvider : public AutocompleteProvider,
                             const InstantSuggestion& suggestion);
   void ClearInstantSuggestion();
 
+  // Sets |match| to be a search for |query|, using the default search provider
+  // or current keyword provider (based on |is_keyword|). |original_query| and
+  // |accepted_suggestion| are used to fill in AQS (Assisted Query Stats).
+  // Returns true if successful (i.e., the |match| was filled in correctly).
+  bool GetSearchWhatYouTypedMatch(const string16& query,

[Peter Kasting, 2013/04/12 00:29:01]

I wonder if this should be static.  Is it correct for it to access members like
the current DSP and keyword provider, or might that need to be recalculated at
the time of the call in case the call happens not in the same callstack as those
are otherwise accessed?  Similar concerns apply to if the function were to
access things like |input_|.

Nit: I think it'd be slightly nicer (and more consistent with the HUP) to return
an AutocompleteMatch by value here.  You can return the empty match if there's
no DSP, which will allow callers to check for failure by asking if the
destination_url is_valid().

Along those consistency lines, it might make sense to call this
SuggestExactInput(), which also is clearer in the keyword case (because we don't
usually use the phrase "what you typed match" with keywords).  OTOH it might be
more confusing due to the word "Suggest".  I don't have a strong opinion.

[sreeram, 2013/04/12 22:36:18]

The only new caller of this method is the one in omnibox_edit_model.cc. There,
this is only called if we have temporary text. It's impossible to have temporary
text when the user isn't actively editing. In particular, if the user switches
tabs or unfocuses the omnibox, the temporary text will become user text. So the
user can't change to another tab and switch the DSP from underneath us. (Should
I worry about group policy updates? Or the TemplateURLService completing its
load?)

The name of the method itself doesn't imply this guarantee, of course. But then
again, if you randomly call any of the other SearchProvider methods after
changing the default search provider, I suspect they will also break (e.g.:
FinalizeInstantQuery).

So, is it okay to leave this as non-static?
Done.
Done.

[Peter Kasting, 2013/04/12 22:50:59]

You do have to worry about pointers changing any time there's asynchronicity,
but looking more closely this code doesn't do anything like that.
I'm kind of torn.  On the one hand, it probably won't hurt anything.  On the
other hand, it's a little bit weird to be depending on existing state.  This is
the first function the SearchProvider has added that's intended to be called by
someone other than the AutocompleteController.  The HUP's SuggestExactInput() is
static.

I think I would be more comfortable with this being static.  It just seems
easier for the caller to reason about and clearer that this is something of a
"public utility function, namespaced to the SearchProvider class".

+                                  const string16& original_query,
+                                  int relevance,
+                                  int accepted_suggestion,
+                                  bool is_keyword,
+                                  AutocompleteMatch* match);
+
   // AutocompleteProvider:
   virtual void Start(const AutocompleteInput& input,
                      bool minimal_changes) OVERRIDE;