tagging for my search needs.  ZeroSuggest.

Which experiment are you referring to? The OmniboxBundledExperimentV1 Finch experiment, or NTPPopularSites? We don't move popular sites into TopSites, but we combine tiles on the NTP from different sources (TopSites or Most Likely, then filling the remainder with Popular Sites).

Just for my understanding: On a blank installation of Chrome that has Most Likely suggestions (but no TopSites), we also wouldn't show anything in Zero Suggest, even though we'd have Most Likely on the NTP, right?

For the phone I tested on, OmniboxBundledExperimentV1 was opted into control and NTPPopularSites was in one of the test branches. It's possible that something else was causing the issue, but I didn't see any likely suspects in the Finch experiment list.

I am not entirely sure what happens when there is Most Likely, but no TopSites. The behaviour I would want is for the Most Likely sites to show up in suggest, but I am not sure whether that's the case.

I saw the issue on a non-blank account though. The data returned for GetMostVisitedURLs was very strange and definitely did not have anything to do with the user's navigation history. Instead it seemed thematic based on the current page.

I would almost suspect it of being EtherSuggest, but I specifically checked OmniboxBundledExperimentV1 and that wasn't on.

Please note that "TopSites" and "PopularSites" are completely different things.

TopSites are suggestions from your on-device history, based on "frecency". This has been around since ~forever.

PopularSites are non-personalized ("popular") suggestions, based only on your location on a country-level. This is the new experiment.

I'm 99% sure that PopularSites don't interact with the Omnibox at all. In particular, if it's talking to the TopSites class, then that is completely unrelated to the PopularSites experiment.

Thanks for the explanation that they are completely different things.  That said, I think Maria's concern is warranted.  On Android, in the past we've made users expect the same tiles that appear on the NTP--I usually think of these as most visited tiles even though it turns out I'm wrong in this case--will appear in the omnibox dropdown when they focus on the omnibox.  I worry that if we break this behavior through something about this popular sites rollout, we'll end up training users to ignore the omnibox suggestions that appear on omnibox focus because these suggestions will initially have no relation to the sites that appear on the NTP.  Parsing the list of suggestions that appear on omnibox focus will have higher cognitive load because they won't be the familiar items in the familiar order.  Thus, even after the NTP popular sites tiles are replaced by most visited tiles, we may have taught users that there is no relationship between these UI surfaces and perhaps even taught users to ignore the focus-on-omnibox suggestions.

I would encourage making the omnibox-focus suggestions be the same as the NTP tiles unless you can give a good argument for deviating.

In that case, we should probably copy the exact behavior, i.e. show Most Likely suggestions when we have them, instead of Top Sites.

So, I guess at that point the easiest thing to do would be to actually get that information from MostVisitedSites. +Chris, because he is working on refactoring MVS anyway.

I believe there are two orthogonal issues here:

1) Current behaviour of zero suggest is unexpected -- and cannot be explained just by PopularSites not integrating with TopSites because we've seen zero suggest items that are in no way related to anything the user has gone to before.

2) Feature design for PopularSites should include correct zero suggest behaviour (thank you, Mark, for explaining).

I will investigate (1) further to see where we are currently getting the suggestions from and hopefully someone on your end can handle (2).

Agreed on #6 and #7. The Omnibox should just use "the NTP tiles", wherever they come from. I actually suspect that there are several more places in Chrome that talk to TopSites directly, and thus get inconsistent results if MostLikely suggestions show up on the NTP. I know the Windows jump list is one such case.

Let's use this bug to track (1) from #7, and I'll file a separate one for (2).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0d5075cf3b4263ca3ff59206ac4e57b3d25fb7ae

commit 0d5075cf3b4263ca3ff59206ac4e57b3d25fb7ae
Author: mariakhomenko <mariakhomenko@chromium.org>
Date: Thu Apr 28 22:41:03 2016

Get rid of pre-focus call which was used for URL fading only.

This was causing us to call autocomplete with the URL as the input text.

BUG= 604076 

Review-Url: https://codereview.chromium.org/1933453002
Cr-Commit-Position: refs/heads/master@{#390516}

[modify] https://crrev.com/0d5075cf3b4263ca3ff59206ac4e57b3d25fb7ae/chrome/android/java/src/org/chromium/chrome/browser/omnibox/LocationBarLayout.java

Your change meets the bar and is auto-approved for M51 (branch: 2704)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/661c3e6e7786eb6c9071a91427ecb4c07e382b65

commit 661c3e6e7786eb6c9071a91427ecb4c07e382b65
Author: mariakhomenko <mariakhomenko@chromium.org>
Date: Sat Apr 30 00:07:23 2016

Regression test and clean up.

Added a test that would have caught the zero-suggest issue. Also removed the
now unused API.

BUG= 604076 

Review-Url: https://codereview.chromium.org/1941473002
Cr-Commit-Position: refs/heads/master@{#390811}

[modify] https://crrev.com/661c3e6e7786eb6c9071a91427ecb4c07e382b65/chrome/android/java/src/org/chromium/chrome/browser/omnibox/LocationBarLayout.java
[modify] https://crrev.com/661c3e6e7786eb6c9071a91427ecb4c07e382b65/chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java
[modify] https://crrev.com/661c3e6e7786eb6c9071a91427ecb4c07e382b65/chrome/android/java/src/org/chromium/chrome/browser/toolbar/CustomTabToolbar.java
[modify] https://crrev.com/661c3e6e7786eb6c9071a91427ecb4c07e382b65/chrome/android/javatests/src/org/chromium/chrome/browser/omnibox/OmniboxTest.java
[modify] https://crrev.com/661c3e6e7786eb6c9071a91427ecb4c07e382b65/chrome/test/android/javatests/src/org/chromium/chrome/test/util/OmniboxTestUtils.java

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c09c84d4b3c2a2b732dec9f046e511c362b5116

commit 0c09c84d4b3c2a2b732dec9f046e511c362b5116
Author: Maria Khomenko <mariakhomenko@chromium.org>
Date: Mon May 02 17:26:27 2016

Get rid of pre-focus call which was used for URL fading only.

This was causing us to call autocomplete with the URL as the input text.

BUG= 604076 

Review-Url: https://codereview.chromium.org/1933453002
Cr-Commit-Position: refs/heads/master@{#390516}
(cherry picked from commit 0d5075cf3b4263ca3ff59206ac4e57b3d25fb7ae)

Review URL: https://codereview.chromium.org/1939873002 .

Cr-Commit-Position: refs/branch-heads/2704@{#334}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/0c09c84d4b3c2a2b732dec9f046e511c362b5116/chrome/android/java/src/org/chromium/chrome/browser/omnibox/LocationBarLayout.java

Chrome version: 51.0.2704.36

Devices tested:
Svelte / KOT49H , Asus Zenfone 5 / 4.4.2

Zero suggest shows first four results from NTP top sites, Hence closing this issue. Hence closing this issue. Thanks