Update: LOG() messages in MostVisitedSites::Refresh and MostVisitedSites::SetMostVisitedURLsObserver are triggered every time ChromeHome is pulled up.

The only path I could find for these updates is TileGroup::startObserving which is used in SiteSection and therefore NTPAdapter and NTPView.
Is it possible that the lifespan of one of these objects is shorter than we would like?

I exposed the MostVisited::Refresh method via MVBridge and included it in the NTPAdapter. This caused this log pattern whenever the sheet was pulled up:

MostVisitedSites::SetObserver
MostVisitedSites::OnMostVisitedURLsAvailable
MostVisitedSites::Refresh
MostVisitedSites::Refresh

--> no further OnMostVisitedURLsAvailable as sites haven't changed after SetObserver.

WIP CL here: http://crrev.com/c/692855


In other words: the tiles are always one cycle late but never stale for long.

Bernhard & Nicolas, can you help me understand why SetObserver is called so frequently?

Adding milestone and pinging the open question.

MostVisitedURLsObserver is registered and listening for changes. So if the backend decides to notify the UI of a change, it will be picked up. It can be seen via transitions from the baked in tiles to the personalised ones on startup.

So I'm missing the issue there. Is it that the native code does not have signal to fetch new data and push it to the UI?

Ah right I get it. When the bottom sheet is closed, we kill the Zine UI. This is a change bauerb@ made some time ago. So I'd say it's WAI.

Ok, so everything works but refreshing is still more a side-effect of a setter than something we consciously do.
I just looked where we rely on that and the answer is: Everywhere (Win, iOS, tests).

Therefore, I will leave this open (& reprioritize) as refactoring/cleanup until we require every caller to call Refresh explicitly.

Applying zine-maintenance label so new owners can decide whether this refactoring is still worth picking up.

Chrome Home is no longer under experimentation.