Send onsubmit query down to the instant extended overlay page when a navigation is performed from t…

chrome/browser/ui/omnibox/omnibox_edit_model.cc

Index: chrome/browser/ui/omnibox/omnibox_edit_model.cc
diff --git a/chrome/browser/ui/omnibox/omnibox_edit_model.cc b/chrome/browser/ui/omnibox/omnibox_edit_model.cc
index 9794fae72cd2c540812bea37d1fb9089ca0a755a..507154fec4660ca4b67b2e0680b37bfcb12b5a11 100644
--- a/chrome/browser/ui/omnibox/omnibox_edit_model.cc
+++ b/chrome/browser/ui/omnibox/omnibox_edit_model.cc
@@ -707,6 +707,18 @@ void OmniboxEditModel::OpenMatch(const AutocompleteMatch& match,
         base::TimeTicks::Now() - time_user_first_modified_omnibox_;
     const GURL destination_url = autocomplete_controller_->
         GetDestinationURL(match, query_formulation_time);
+
+    // If running with instant, notify the instant controller that a navigation
+    // is about to take place if we are navigating to a URL. This can be
+    // determined by inspecting the transition type. Note that only the user-
+    // entered content, not the full match should be sent down to avoid leaking
+    // autocompleted content.
+    if (match.transition == content::PAGE_TRANSITION_TYPED) {

[sreeram, 2013/03/26 20:05:42]

Surprisingly, this works. :)

I thought perhaps it wouldn't work for cases where the match was a NAVSUGGEST,
or a bookmark match or such. But in looking through all the autocomplete
providers, it seems that whenever the match is a URL, it's always of transition
TYPED (even if the user didn't actually type the whole thing, as in the case of
a nav suggest). I'd encourage you to verify my findings, though.

[robertshield, 2013/03/27 21:44:05]

Afaict, this is true. I cannot find any code path which sends this transition
type without the value being a url.

[Peter Kasting, 2013/03/27 21:51:47]

TYPED always indicates a URL, but not all URLs are TYPED.  For example,
AcceptInput() will convert the transition to RELOAD if the user hit enter on the
existing permanent URL or to LINK if the user pasted in a URL and hit enter.

I don't know if you care about cases like this.  If so you may need to hook
AcceptInput() instead of here, to get the unmodified transition.

+      InstantController* instant = controller_->GetInstant();
+      if (instant)
+        instant->OnNavigateToURL(autocomplete_controller_->input().text());

[sreeram, 2013/03/26 20:05:42]

Why do we need to send any text down to the page at all? Per the bug, the page
already knows that the omnibox has a URL, and searchbox.value is already
correct. It just shouldn't change, that's all.

Also, we agreed on the bug that this should only happen when the user explicitly
presses Enter. Whereas, this code path (OpenMatch()) is called for many other
scenarios. We shouldn't be sending any Submit() event in those cases.

[robertshield, 2013/03/27 21:44:05]

Ok, removed the text and now send down the empty string. When we (David, Gideon
and I) discussed this initially, it was suggested to send down the string the
user actually typed. I do not know if the page needs this information.
Afaict, OpenMatch being called for PAGE_TRANSITION_TYPED with disposition being
CURRENT_TAB corresponds to an Enter key stroke. Indeed, this is the heuristic
used by BrowserInstantController::OpenInstant() to send
"INSTANT_COMMIT_PRESSED_ENTER". I have updated the check to include the
disposition, let me know if you feel that is not sufficient.

+    }
+
     // This calls RevertAll again.
     base::AutoReset<bool> tmp(&in_revert_, true);
     controller_->OnAutocompleteAccept(destination_url, disposition,