Bug
1747973 - Cache the top-sites query context like we cache other contexts. r=harry
This caches the top-sites context like we cache other contexts. The cache is
cleared when the top sites change or are enabled/disabled.
Unlike other contexts, which are evicted from the cache once too many newer
contexts are cached, the top-sites context is never evicted due to space reasons
because showing the top sites is a frequent action.
I wanted to keep the logic around when/whether the top sites have changed or
been enabled/disabled isolated to the top-sites provider, since it's the class
concerned with top sites in the first place, instead of spreading it out to
`QueryContextCache`. However, by the same token I didn't want to cache contexts
directly in the provider in order to keep all context caching in
`QueryContextCache`. (Contexts are also per window/urlbar, not global, so if we
were to cache contexts in the provider, we'd need to store them in map from
windows to contexts or something similar.)
So I added a more general listener system to the provider. Listeners are called
when the top sites change or they are enabled/disabled. `QueryContextCache` adds
a listener function so it can evict its cached top-sites context. The provider
keeps weak references to the listener functions because currently `UrlbarView`
doesn't have a way to tell when it's destroyed, so it doesn't know when it
should remove listeners.
Finally, there doesn't seem to be a way to observe the `TopSitesFeed` from the
outside, and I don't think it's the role of `TopSitesFeed` to broadcast an
observer message to the entire browser or something like that, so I modified
`AboutNewTab` to subscribe to changes in its activity stream object and then
compare the new top sites to the last seen top sites, and if they're different,
then broadcast a new "newtab-top-sites-changed" notification.
Differential Revision: https://phabricator.services.mozilla.com/
D134863