Omnibox refactor. OmniboxController now holds an AutocompleteMatch.

chrome/browser/autocomplete/autocomplete_match.h

Index: chrome/browser/autocomplete/autocomplete_match.h
diff --git a/chrome/browser/autocomplete/autocomplete_match.h b/chrome/browser/autocomplete/autocomplete_match.h
index 146586ea2f8a0667c70ad2263cfae3d89c556cf1..9c740943b65cd74b15d65bc2f5a915446918966b 100644
--- a/chrome/browser/autocomplete/autocomplete_match.h
+++ b/chrome/browser/autocomplete/autocomplete_match.h
@@ -247,6 +247,10 @@ struct AutocompleteMatch {
   // not be inline autocompleted.
   size_t inline_autocomplete_offset;
 
+  // The completion suggested by instant, displayed in gray text besides
+  // |fill_into_edit|.
+  string16 gray_suggestion;

[Peter Kasting, 2013/06/11 22:42:55]

It doesn't seem right to put this on AutocompleteMatch.  Basically, the presence
of grey text indicates that we effectively have two different "matches" in play
in the UI:

* This match, which has a particular text and destination
* The instant-suggested match, which necessarily has different text (which
presumably starts with the same text) and a different destination

It seems more like these should be distinct AutocompleteMatches, or else an
AutocompleteMatch + some other data that the controller (or someone) is keeping
track of.

[beaudoin, 2013/06/14 21:39:38]

I agree. For now I will just keep that gray text in omnibox_controller.h.

Still, let me give you a bit of context here, in case you have a suggestion...

The goal here is for OmniboxController to keep all the information that is
needed for the Omnibox to render its content and act correctly, no matter
whether the match comes from AutocompleteController or InstantController. At the
moment we fake this with a flurry of booleans in OmniboxEditModel (and these are
not correctly updated when you switch tabs).

That information is not a strict subset of the current AutocompleteMatch (as it
needs the grey text). However, it needs to be kept in a structure as it's passed
around quite a bit.

Sreeram's idea here was to save the need for a new structure that would share
many fields with AutocompleteMatch. I've never been a fan of the approach. I
would rather define another structure (ie. MatchInfo) and either duplicate the
required fields or have AutocompleteMatch hold a MatchInfo.

Then, as you suggest, we could then have two MatchInfo in OmniboxController (ie.
base_match_info_, suggestion_match_info_).

+
   // The URL to actually load when the autocomplete item is selected. This URL
   // should be canonical so we can compare URLs with strcmp to avoid dupes.
   // It may be empty if there is no possible navigation.
@@ -284,8 +288,7 @@ struct AutocompleteMatch {
   // for both explicit "keyword mode" matches as well as matches for the default
   // search provider (so, any match for which we're doing substitution); it
   // doesn't imply (alone) that the UI is going to show a keyword hint or
-  // keyword mode.  For that, see GetKeywordUIState() or
-  // GetSubstitutingExplicitlyInvokedKeyword().
+  // keyword mode.  For that, see GetSubstitutingExplicitlyInvokedKeyword().
   //
   // CAUTION: The TemplateURL associated with this keyword may be deleted or
   // modified while the AutocompleteMatch is alive.  This means anyone who