Omnibox: Change |inline_autocomplete_offset| to |inline_autocompletion|

chrome/browser/ui/omnibox/omnibox_controller.cc

 // Copyright 2013 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_controller.h"
 
 #include "base/metrics/histogram.h"
 #include "chrome/browser/autocomplete/autocomplete_classifier.h"
 #include "chrome/browser/autocomplete/autocomplete_match.h"
 #include "chrome/browser/autocomplete/search_provider.h"
@@ skipping 51 matching lines @@
 
 void OmniboxController::OnResultChanged(bool default_match_changed) {
   const bool was_open = popup_->IsOpen();
   if (default_match_changed) {
     // The default match has changed, we need to let the OmniboxEditModel know
     // about new inline autocomplete text (blue highlight).
     const AutocompleteResult& result = this->result();
     const AutocompleteResult::const_iterator match(result.default_match());
     if (match != result.end()) {
       current_match_ = *match;
-      // TODO(beaudoin): This code could be made simpler if AutocompleteMatch
-      // had an |inline_autocompletion| instead of |inline_autocomplete_offset|.
       // The |fill_into_edit| we get may not match what we have in the view at
-      // that time. We're only interested in the inline_autocomplete part, so
-      // update this here.
+      // the time because there is a possibility that the *match prefix differs
+      // from the omnibox content (e.g., swapping spaces for %20).  Hence,
+      // we need to replace it.

[Peter Kasting, 2013/07/16 21:48:50]

I'm still confused by all this (sorry).  Why is it a bad thing if the
fill_into_edit doesn't quite match the user's typing?  If the only thing we use
the fill_into_edit for is showing something when the user arrows down and back
(or similar), there's no reason it has to exactly match the user's typing.

[beaudoin, 2013/07/18 17:50:18]

omnibox_edit_model.cc uses current_match() quite a bit so I have not completed
an extensive analysis but, IIRC, the problem was that it looked weird if you
arrowed down through the suggestions and hit ESC or arrowed back up. It was a
bit hard to trigger since the prefix almost always match. Maybe it can be
simulated by deliberately messing up with current_match_.fill_into_edit here and
see if any visible adverse effect happen as the user edit, arrows, hits esc,
etc.

       current_match_.fill_into_edit = omnibox_edit_model_->user_text();
-      if (match->inline_autocomplete_offset < match->fill_into_edit.length()) {
-        current_match_.inline_autocomplete_offset =
-            current_match_.fill_into_edit.length();
-        current_match_.fill_into_edit += match->fill_into_edit.substr(
-            match->inline_autocomplete_offset);
-      } else {
-        current_match_.inline_autocomplete_offset = string16::npos;
-      }
-
       if (!prerender::IsOmniboxEnabled(profile_))
         DoPreconnect(*match);
       omnibox_edit_model_->OnCurrentMatchChanged();
     } else {
       InvalidateCurrentMatch();
       popup_->OnResultChanged();
       omnibox_edit_model_->OnPopupDataChanged(string16(), NULL, string16(),
                                               false);
     }
   } else {
@@ skipping 25 matching lines @@
     if (profile_->GetNetworkPredictor()) {
       profile_->GetNetworkPredictor()->AnticipateOmniboxUrl(
           match.destination_url,
           predictors::AutocompleteActionPredictor::IsPreconnectable(match));
     }
     // We could prefetch the alternate nav URL, if any, but because there
     // can be many of these as a user types an initial series of characters,
     // the OS DNS cache could suffer eviction problems for minimal gain.
   }
 }