Add search_terms_replacement_key field to TemplateURL.

chrome/browser/search_engines/prepopulated_engines_schema.json

Index: chrome/browser/search_engines/prepopulated_engines_schema.json
diff --git a/chrome/browser/search_engines/prepopulated_engines_schema.json b/chrome/browser/search_engines/prepopulated_engines_schema.json
index 0838e224f5100ccc3d5a0744e4ac894cabaa5e1e..4904b1f66ce3cc512f3a4b93804f4e5c9fcc5b76 100644
--- a/chrome/browser/search_engines/prepopulated_engines_schema.json
+++ b/chrome/browser/search_engines/prepopulated_engines_schema.json
@@ -23,9 +23,9 @@
       "optional": true
     },
     // If omitted, this engine does not support suggestions.
-    { "field": "suggest_url", "type": "string", "optional": true  },
+    { "field": "suggest_url", "type": "string", "optional": true },
     // If omitted, this engine does not support instant.
-    { "field": "instant_url", "type": "string", "optional": true  },
+    { "field": "instant_url", "type": "string", "optional": true },
     // A list of URL patterns that can be used, in addition to |search_url|,
     // to extract search terms from a URL.
     {
@@ -34,6 +34,15 @@
       "contents": { "type": "string" },
       "optional": true
     },
+    // A parameter that, if present and non-zero in a search_url or
+    // instant_url, causes Chrome to replace the URL with the search term.
+    // The parameter must be in the query if the search terms are in the query,
+    // and in the ref if the search terms are in the ref.

[Peter Kasting, 2012/12/18 01:54:43]

Two generalization questions.  Both of these spring from trying to ensure we
don't enforce any Google-specific constraints on other search providers.
* Is "nonzero" what we want?  Maybe we should make this "nonempty"?  I don't
know if everyone will want a numeric param value for this.
* Is the constraint about query/ref matching something we need to support? 
Perhaps we should just check if this appears anywhere in the URL after the path.

[beaudoin, 2012/12/20 04:23:29]

With "espv=0" GWS does not remove the textbox in the search result page.
@dcblack Can/should this be changed?
Again, I used GWS behavior to guide me here.
@dcblack Can/should we change GWS here? Should we just don't care if URLs with
the "espv=" in query and "q=" in ref (and vice-versa) are never generated?

[David Black, 2012/12/20 19:29:49]

espv being present is fine.  From GWS's perspective espv=0 is conceptually
undefined, but so is espv=2 or espv=foobar currently, so whatever.  Such urls
should never be generated.
The parameter value is explicitly the version of the embedded search javascript
API that Chrome is using.  It's currently 1, and will increment when we make
backwards-incompatible changes.  Its value is not something search providers get
to choose.

On 2012/12/20 04:23:29, beaudoin wrote:

[Peter Kasting, 2012/12/20 19:37:13]

What about the query-versus-ref issue?  Is it OK to just look for the param
anywhere in either one?
I think you're describing the {google:instantExtendedParam} or whatever we call
it, which Chrome generates a value for.  That's different than this field, which
is the param we parse out of the URL to see if we should substitute search
terms.  For Google, these are actually the same param, but for another search
provider, they could completely avoid the Google-specific param entirely.

[beaudoin, 2013/01/03 18:49:40]

Changed the comment to indicate the parameter need only be present.

+    {
+      "field": "search_terms_replacement_key",
+      "type": "string",
+      "optional": true
+    },
     {
       "field": "type",
       "type": "enum",