In fact, ZeroSuggestProvider (components/omnibox/browser/zero_suggest_provider.cc) talks to TopSites directly, which means that if MostLikely is active, it'll also show inconsistent suggestions.

Once MostVisitedSites has moved into a component, we should use that instead of TopSites.

I'm not sure I understand this bug.  Omnibox ZeroSuggest should show topsites/mostlikely/popularsite (i.e., whatever shows on the NTP).  Omnibox ZeroSuggest on desktop shows contextual suggestions.

I don't see why:
(i) this bug is marked OS=All if it's about integrating with MostLikely and PopularSites, as that's only relevant on Android
(ii) why this is blocked on a related to componentizing the desktop NTP

What am I misunderstanding?

"Omnibox ZeroSuggest should show topsites/mostlikely/popularsite (i.e., whatever shows on the NTP)."
on Android

(i) MostLikely is relevant on all platforms, not just Android.

(ii) On desktop, MostLikely suggestions are currently fetched by JS code on the NTP, while the rest of Chrome has no way to get those suggestions. (ZeroSuggest and some other places, such as the Windows "jump list", have in fact used the wrong thing ever since MostLikely was introduced years ago.)
The new components/ntp_tiles will be the One Place to get "whatever shows on the NTP" on all platforms.

re (i): I understand.
But on desktop, ZeroSuggest doesn't have anything to do with MostLikely, MostVisited, PopularSites, NTP tiles, whatever.  It provides suggestions relevant to the current page, nothing related to any of that stuff.  I don't see why this bug is tagged with "All" platforms.  It has no relevance to desktop platforms at all.

i.e., your comment (ii) is not relevant.  It doesn't matter how MostLikely suggestions are fetched on desktop because ZeroSuggest doesn't fetch them or use them on desktop...

Ah, I see. I simply noticed that ZeroSuggestProvider talks to TopSites (here: https://cs.chromium.org/chromium/src/components/omnibox/browser/zero_suggest_provider.cc?rcl=0&l=319); I wasn't aware that that code isn't active on desktop. I guess the field trial that it's behind is only active on Android?

> I guess the field trial that it's behind is only active on Android?
Correct.

This came up today when talking about zerosuggest (contextual on desktop and non-contextual on Android).  Most of us were confused about what we see on our ZeroSuggest suggestions on Android and were wondering why some highly-positions NTP tiles don't appear and other appear out of order.  The consensus was that zerosuggest on Android displays some random subset of the tiles on the NTP.

Can this get some attention from you Zine folks?  Some of us are working on improving contextual zerosuggest (improving it on desktop, mixing it on mobile), and it would be nice to have a coherent base on which to build.  You guys are the experts at this.

What happens is that tiles on the NTP can come from several sources: from local history (called TopSites), from synced history (called SuggestionsService in Chrome, known as MostLikely otherwise), or from PopularSites (regionally popular, non-personalized).

ZeroSuggest only talks to TopSites, so what shows up will generally be different from the NTP, for signed-in users in particular. The solution is to talk to ntp_tiles::MostVisitedSites instead, which does all the multiplexing.

sfiera or mastiz, does one of you have cycles for this?

I can take care.

Hi mastiz@,

Can you please provide an update on this bug?

thanks,
mark

Sure, sorry for the long silence.

We originally thought this is blocked on  crbug.com/619584 . I'm no longer sure this is the case, after recent changes that have made loading of Popular Sites faster.

I still envision MostVisitedSites being a keyed service, the question is whether it's worth integrating with the omnibox earlier. How would you prioritize this, mark?

> How would you prioritize this, mark?

"Nice to have."  Zero suggest gets used a lot on Android.

I think the question of prioritization is best answered by you: how much of an improvement did you see when you switched from TopSites to ntp_tiles::MostVisitedSites (the combination that includes MostLikely and PopularSites)?

In other words, I'm less concerned about the polish question and more simply about the quality question.

Quick update: we're planning an experiment (pending LR approval) to compare TopSites vs MostLikely, which would answer your question above about quality. So far, we don't have a good, unbiased comparison between the two.

Grace complained about this bug again on a thread this week.  Any case we can get this bug fixed soon?  Or at least an update on the eval (if any) thus far?  (E-mail me directly if it's non-public information.)

 Issue 733080  has been merged into this issue.

We believe that either  bug 619584  or (more probably) 650589 needs to be addressed. I'll coordinate with sfiera@ as per what the latest plans and status are.

sfiera@ is OOO today and the next week so that part (implementation) will need to wait a bit.

As per eval, the experiment to compare quality between TopSites and MostLikely has been started this week on stable and we should have preliminary data after some days.

Any update on the eval?

I can speak about TopSites vs MostLikely: experiments suggest TopSites is superior and we're planning to dig deeper, but meanwhile I'd stick to integrating PopularSites directly with zero-suggest without relying on ntp_tiles::MostVisitedSites.

Hence, removing  crbug.com/619584  as dependency but 650589 is still relevant. Reassigning to sfiera@.

I'd advise against using PopularSites directly. IIUC the intention is for ZeroSuggest to mirror what you see on the NTP, and that's exactly what ntp_tiles::MostVisitedSites does.

ntp_tiles::MostVisitedSites does fit nicely but IMO it's not ready to be consumed for this purpose, in particular due to MostLikely caveats: a) lower quality; b) use of landing URL in case of redirects (which is inconsistent with omnibox autocomplete, hence presumably also inconsistent for zero-suggest).

A similar option would be to instantiate MostVisitedSites() with |suggestions_service==nullptr|, which is currently disallowed by the API but trivial to change.

(not working on client-side Chrome any more)

adding keyword for easier searching zerosuggest, zero suggest, most visited, mostvisited, most likely, mostlikely, topsites, top sites, popular sites, popularsites

dimich@, should this belong to your team now?