We reverted the original change because it was causing flaky interactive_ui_test failures in DeleteItem.

Those were due to a poorly written test.

The test has been fixed.  Now, we can revert the revert to submit the original change.

Revert 166450 - Revert 166441 - Omnibox: Move Relevance Code from HistoryURL to HistoryQuick provider

(Causing interactive_ui_tests flake in DeleteItem)

This changelist:
* adds code to HistoryQuick provider (and helper classes) to allow it to order and score results in a manner similar to HistoryURL provider (in addition to how it currently scores results).  The change keeps the order of HQP's highly scoring results, but for results that might score better with HUP-like scoring, it orders results according to HUP and assigns them scores similar to HUP would give.
* gates the logic in HistoryURL provider to prevent it from searching its URL database, meaning the only thing it can return is URL-what-you-typed results.
* creates a field trial that simultaneously turns off HUP searching behavior and turns on the additional also-score-like-HUP in HQP.  This field trial will aid evaluating this change.

If the change turns out to be neutral or positive, the natural next step is to remove all the URL search features from HUP, leaving it a lightweight shell of its old self.

Causes for known discrepancies (in rough order by how often they affect an omnibox input, as judged by my omnibox input log):
* Because there's now only one provider of URLs from history, at most the URL can see three history URLs total.  This is in contrast to the current behavior when HistoryURL and HistoryQuick could each provide 3 and, assuming they didn't overlap much and scored well, users could easily see 4 or 5 or even 6 (the whole omnibox!) of URL results from history.
* HistoryURL provider returns three results after redirect culling.  HistoryQuick provider chooses its three results and returns them before the autocomplete controller comes along and removes likely redirects.  The typical consequence of this is that when users used to see three URLs from history now they see two because one has been eliminated late in the game.
* HUP and HQP disagree on typed_count == 0 results.  HQP often (always?) doesn't have them.  HUP sometimes will find or construct them (e.g., from hulu.com/castle, it'll construct hulu.com/).  (This is a comment about missing URLs.)
* when there are typed_count == 0 and typed_count > 0 results, and HUP for some reason decides to put the typed_count == 0 result first (e.g., because the typed_count == 0 result is shorter than the longer matches), it'll demote the scores of all later matches so no matches are inlineable and all matches stay in the proper order, even if other URLs (on different hosts) would normally be inlineable.  (This is a comment about the order URLs that exist.)

BUG=
TEST=examined diffs using Christos's comparison javascript tool

Review URL: https://chromiumcodereview.appspot.com/10834437

TBR=mpearson@chromium.org
Review URL: https://codereview.chromium.org/11275194

TBR=scottmg@google.com
Review URL: https://codereview.chromium.org/11365187

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167097 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions