Chromium Code Reviews Chromium Code Reviews
Issue
481693004:
Omnibox: Prevent Asynchronous Suggestions from Changing Default Match (Closed)
DescriptionOmnibox: 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
Committed: https://crrev.com/6c18367d228b0360f2a7d1a06b9b88de61262ff0
Cr-Commit-Position: refs/heads/master@{#293049}
Patch Set 1 #Patch Set 2 : fix interactive test #
Total comments: 58
Patch Set 3 : mike's extensive changes to tests #
Total comments: 12
Patch Set 4 : Mike's minor comments #Patch Set 5 : rebase #
Messages
Total messages: 21 (3 generated)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
