TEST ONLY - DO NOT SUBMIT - FOR TRYBOTS

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 05e51d32cff8483805593f637021c3aef4b300a0..4feefb0001566771557c51e16e5dd71ef3f4cb78 100644
--- a/chrome/browser/ui/omnibox/omnibox_edit_model.cc
+++ b/chrome/browser/ui/omnibox/omnibox_edit_model.cc
@@ -257,8 +257,6 @@ void OmniboxEditModel::RestoreState(const State* state) {
   bool url_replacement_enabled = !state || state->url_replacement_enabled;

[Justin Donnelly, 2014/12/03 16:07:25]

One of the reasons I thought it would be helpful to combine the two changes is
that with both features gone, I'm pretty sure we don't need
url_replacement_enabled and all it's associated logic anymore. If you want to
keep the two changes separate and remove u_r_e in a third, that's fine, just
FYI.

Update: on second thought, possibly not. Is this still used for search term
replacement?

[Peter Kasting, 2014/12/04 00:23:19]

Yes, but given that the origin chip and search button were the mechanisms
proposed for enabling search term replacement, that's dead as well.  Unless
someone has a proposition for how to address the negative data we saw with it? 
I think this patch leaves the user without any flags to enable the feature, so I
wouldn't leave any of its plumbing either, unless we have some sort of set of
experiments in the pipe.

It makes me kind of sad, because search term replacement is something I
personally thought was interesting and viable, but AFAIK we haven't come up with
a way to do it that doesn't seem to measure as clearly bad.

I might check with dcblack to be sure that he agrees that this is dead.  If so,
I'd remove it as well -- doesn't matter what the combination of CLs is. 
Removing the search term replacement functionality entirely would probably allow
some API simplifications (assuming it amounts to reverting a lot of the changes
I originally did to make the underlying model amenable to search term
replacement; it's possible that some of those were good refactoring that should
stick around, though, and I'd have to peer through the original CLs to know).

[Justin Donnelly, 2014/12/04 00:54:43]

I think search term replacement is actually launched on mobile. If not, there's
some very similar type of behavior on Android.

[Peter Kasting, 2014/12/04 01:44:31]

I would be very surprised if this code is used on mobile -- AFAIK they have a
completely different omnibox implementation, and what with the various projects
going on internally (codenames and descriptions redacted here), that looks
likely to become more diverged rather than less.

Worth checking, though, so good to raise it.

[groby-ooo-7-16, 2015/01/10 00:54:06]

Filed as http://crbug.com/447810

   controller_->GetToolbarModel()->set_url_replacement_enabled(
       url_replacement_enabled);
-  controller_->GetToolbarModel()->set_origin_chip_enabled(
-      url_replacement_enabled);
   permanent_text_ = controller_->GetToolbarModel()->GetText();
   // Don't muck with the search term replacement state, as we've just set it
   // correctly.
@@ -518,17 +516,7 @@ void OmniboxEditModel::SetInputInProgress(bool in_progress) {
     autocomplete_controller()->ResetSession();
   }
 
-  // The following code handles two cases:
-  // * For HIDE_ON_USER_INPUT and ON_SRP, it hides the chip when user input
-  //   begins.
-  // * For HIDE_ON_MOUSE_RELEASE, which only hides the chip on mouse release if
-  //   the omnibox is empty, it handles the "omnibox was not empty" case by
-  //   acting like HIDE_ON_USER_INPUT.
-  if (chrome::ShouldDisplayOriginChip() && in_progress)
-    controller()->GetToolbarModel()->set_origin_chip_enabled(false);
-
   controller_->GetToolbarModel()->set_input_in_progress(in_progress);
-  controller_->EndOriginChipAnimations(true);
   controller_->Update(NULL);
 
   if (user_input_in_progress_ || !in_revert_)
@@ -993,15 +981,6 @@ bool OmniboxEditModel::OnEscapeKeyPressed() {
     view_->Update();
   }
 
-  // When using the origin chip, hitting escape to revert all should either
-  // display the URL (when search term replacement would not be performed for
-  // this page) or the search terms (when it would).  To accomplish this,
-  // we'll need to disable URL replacement iff it's currently enabled and
-  // search term replacement wouldn't normally happen.
-  bool should_disable_url_replacement =
-      controller_->GetToolbarModel()->url_replacement_enabled() &&
-      !controller_->GetToolbarModel()->WouldPerformSearchTermReplacement(true);
-
   // If the user wasn't editing, but merely had focus in the edit, allow <esc>
   // to be processed as an accelerator, so it can still be used to stop a load.
   // When the permanent text isn't all selected we still fall through to the
@@ -1009,8 +988,8 @@ bool OmniboxEditModel::OnEscapeKeyPressed() {
   // <esc> to quickly replace all the text; this matches IE.
   const bool has_zero_suggest_match = match.provider &&
       (match.provider->type() == AutocompleteProvider::TYPE_ZERO_SUGGEST);
-  if (!has_zero_suggest_match && !should_disable_url_replacement &&
-      !user_input_in_progress_ && view_->IsSelectAll())
+  if (!has_zero_suggest_match && !user_input_in_progress_ &&
+      view_->IsSelectAll())
     return false;
 
   if (!user_text_.empty()) {
@@ -1019,11 +998,7 @@ bool OmniboxEditModel::OnEscapeKeyPressed() {
                               OMNIBOX_USER_TEXT_CLEARED_NUM_OF_ITEMS);
   }
 
-  if (should_disable_url_replacement) {
-    controller_->GetToolbarModel()->set_url_replacement_enabled(false);
-    UpdatePermanentText();
-  }
-  view_->RevertWithoutResettingSearchTermReplacement();
+  view_->RevertAll();
   view_->SelectAll(true);
   return true;
 }