Omnibox: Prevent Asynchronous Suggestions from Changing Default Match
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}
Showing
This diff is collapsed.
This diff is collapsed.
Please register or sign in to comment