[Search] Store and recall search terms using NavigationEntry to improve search term extraction

chrome/browser/ui/omnibox/omnibox_edit_model.cc

 // Copyright 2012 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 "chrome/browser/ui/omnibox/omnibox_edit_model.h"
 
 #include <string>
 
 #include "base/auto_reset.h"
 #include "base/format_macros.h"
@@ skipping 642 matching lines @@
     // all have IDs above the maximum, and will be automatically lumped
     // together in an "overflow" bucket in the histogram.
     UMA_HISTOGRAM_ENUMERATION("Omnibox.SearchEngine",
         template_url->prepopulate_id(),
         TemplateURLPrepopulateData::kMaxPrepopulatedEngineID);
   }
 
   if (disposition != NEW_BACKGROUND_TAB) {
     base::AutoReset<bool> tmp(&in_revert_, true);
     view_->RevertAll();  // Revert the box to its unedited state
+    if (controller()->GetInstant() &&
+        controller()->GetInstant()->IsInstantExtendedSearch()) {
+      // In the case of an instant-extended search, actually revert to
+      // |last_omnibox_text|, which is what the user is searching for. This
+      // avoids a flash of the previous query.
+      view_->OnTemporaryTextMaybeChanged(
+            controller()->GetInstant()->last_omnibox_text(),
+            true);
+    }

[sreeram, 2013/01/22 04:34:47]

I see what you are trying to do here, but I'd like to understand something
first:

To be clear, the flash we are trying to fix is this:

1. You are on a committed search results page for "foo". The omnibox is
therefore showing the extracted search terms, i.e., [foo].
2. You type "bar" and press Enter quickly.
3. The omnibox flashes "foo" briefly before showing "bar" again.

I think what's happening is that view_->RevertAll() goes back to the permanent
text, which is what we had in step 1, thus showing "foo". Then, the
controller_->OnAutocompleteAccept() call below ends up calling
InstantController::CommitIfPossible(), which sends "bar" to the page (via
InstantTab), which asynchronously (i.e., at some later time) updates the URL to
contain "#q=bar", thus we end up seeing "bar" again in the omnibox.

Now, my questions are:

1. Why do we not see this flash when committing the Instant overlay (as opposed
to when the query is sent to InstantTab)?
2. More generally, in regular omnibox (i.e., without any Instant whatsoever,
without extended mode), say you are on "foo.com" and now type "bar.com" and
press Enter. Clearly, we come through this same code path. Why do we not see a
flash of "foo.com"?

I think the answers to those questions will help me understand whether this is
the only way to fix the flash (or say whether we could also fix it by not doing
search terms extraction when in_revert_ is true, as opposed to encoding more
Instant knowledge into the omnibox edit model).

   }
 
   if (match.type == AutocompleteMatch::EXTENSION_APP) {
     ExtensionAppProvider::LaunchAppFromOmnibox(match, profile_, disposition);
   } else {
     GURL destination_url(match.destination_url);
     // Append the query formulation time (time from when the user first typed a
     // character into the omnibox to when the user selected a query) to the AQS
     // parameter if other AQS parameters were already populated.
     if (template_url && match.search_terms_args.get() &&
@@ skipping 671 matching lines @@
     instant->OmniboxFocusChanged(state, reason, NULL);
 
   // Update state and notify view if the omnibox has focus and the caret
   // visibility changed.
   const bool was_caret_visible = is_caret_visible();
   focus_state_ = state;
   if (focus_state_ != OMNIBOX_FOCUS_NONE &&
       is_caret_visible() != was_caret_visible)
     view_->ApplyCaretVisibility();
 }