• mpearson's avatar
    Omnibox: Prevent Asynchronous Suggestions from Changing Default Match · 6c18367d
    mpearson authored
    This is a re-land of
    https://codereview.chromium.org/471673002/
    which was reverted because it caused a failure in
    interactive_ui_tests
    InstantExtendedPrefetchTest.SetPrefetchQuery (run #1):
    [ RUN      ] InstantExtendedPrefetchTest.SetPrefetchQuery
    ../../chrome/browser/ui/search/instant_extended_interactive_uitest.cc:867: Failure
    Value of: SearchProvider::ShouldPrefetch(*( omnibox()->model()->result().default_match()))
      Actual: false
    Expected: true
    [  FAILED  ] InstantExtendedPrefetchTest.SetPrefetchQuery, where TypeParam =  and GetParam() =  (1613 ms)
    
    http://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Tests&number=12979
    
    It has two changes:
    - revises the failing tests
    - does some requested cleanup of the unit tests
    
    The original changelist description follows:
    ---
    
    Calls to the suggest server may normally result in a new inline
    autocompletion.  This can be disruptive because it means pressing enter
    may bring the user to different places depending on how long he/she
    waits after typing the last key.
    
    This change prevents new suggestions from becoming the default match.
    In other words, the default match is only allowed to change on a
    keystroke, not due to a reply coming back from the server.
    
    The consequence of this change is that if previously we'd show an
    inline suggestion on a server reply, now we only show it one keystroke
    later.  I think this trade-off (one keystroke versus inconsistent
    omnibox behavior) is a good one to make.
    
    We still end up with default matches (inline autocompletions within
    the omnibox) from the suggest server after this change.  Here's an
    example of why:
    
    User types "facebo"
    We send a suggest server request.
    Server asynchronously returns "facebook" as a top suggestion,
      beating the server-provided verbatim score for "facebo".
    We decide not to show it within the omnibox.  It's instead shown
      somewhere in the dropdown.
    User types "o".
    We send a suggest server request.
    We reuse our cached suggestions and suggestion scores.  <<< THE KEY
    We show "facebook" as an inline suggestion because it beats
      the default verbatim score that gets assigned to "faceboo".
      (This is the score that we assign by default without having
      yet received the most recent suggest server response.)
    We receive the response, which includes "facebook" as a top
      suggestion, beating the server-provided verbatim score
      for "faceboo".
    We show "facebook" as an inline suggestion.  i.e., we decide
      not to demote it because it was already being shown inline
    
    TESTED:
    unit tests plus interactive tests (facebook.com/l, google.com/a)
    
    BUG=398135
    
    Review URL: https://codereview.chromium.org/481693004
    
    Cr-Commit-Position: refs/heads/master@{#293049}
    6c18367d
search_suggestion_parser.h 11.5 KB