User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180316100132 Steps to reproduce: Currently the topSites API is rather limited. Thumbnails are available in about:newtab by default, but they cannot be accessed using a programmatic interface. This is a request to make this possible. As for the implementation, maybe https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/topSites/MostVisitedURL can be extended with a thumbnail?

Certainly one issue is that if we do this, it has to be done in a way that it doesn't add overhead to users of topSites who don't care about thumbnails. That is, unless it is very cheap to get thumbnails (which I suspect it is not) then callers should explicitly ask for them. But first we need to know how supportable this is from the activity stream side. :Mardak can you address that question?

The thumbnails tend to be cached on disk already, although we have had memory concerns of passing around thumbnail data and converting to strings, etc. A separate concern is privacy in that thumbnails can have logged in information, e.g., email. Not sure if that would require a different permission level or not at all?

(In reply to Ed Lee :Mardak from comment #2) > The thumbnails tend to be cached on disk already, although we have had > memory concerns of passing around thumbnail data and converting to strings, > etc. > > A separate concern is privacy in that thumbnails can have logged in > information, e.g., email. Not sure if that would require a different > permission level or not at all? I think that privacy conceren is covered with the topSites permission, since also there there might be sensitive sites (URLs).

Knowing that you use gmail is not the same as knowing what's your email address and your email contents, etc.

Hi Geoffrey, this bug has been added to the WebExtensions APIs triage for July 10, 2018. Would you be able to join us? Here’s a quick overview of what to expect at the triage: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting * Meeting agenda: https://docs.google.com/document/d/1Y_oYPldTT_kQOOouyJbC-8y3ASIizScLKFRhQfsDQWI/edit#heading=h.mr8julfcusgv * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

I couldn't make it to the meeting. If there are questions, I'm usually online on IRC at #webextensions.

This bug was reviewed at the meeting. Outcome: Approval is pending. More input from the ActivityStream team is desired. Specifically, 1) are thumbnails in the long-term roadmap? 2) what are the performance considerations? 3) what are the memory considerations? In general, would the activity stream team be comfortable exposing thumbnails to extensions? For privacy, it was felt that extensions would need host permissions for the URLs of the thumbnails for each site.

(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #7) > 1) are thumbnails in the long-term roadmap? There's a meta bug 1445085 for improving thumbnails usage in activity stream, but one not tracked (but has come up several times in the past year) is removing thumbnails due to its constant issues with privacy, performance, maintenance and actual value. Activity Stream happens to be the main user of thumbnails right now, but it existed before and has some other consumers, so even if we don't use thumbnails, it would probably continue to exist. Activity Stream primarily gets thumbnails by calling BackgroundPageThumbs.captureIfMissing with a url. This will end up loading the url and related styles, scripts, images, etc. if a thumbnail isn't already cached on disk in the profile directory. This means a large / problematic page could cause high cpu and memory usage while thumbnailing. In the recent past, we've had memory issues with thumbnails because they were being read from disk and converted to base64 encoded data uris and passed around as messages then referenced from pages, so bug 1436615 switched over to blobs. Some other notes about the API: it's asynchronous, so if there's multiple sites that need a thumbnail, each could take maybe 30 seconds to capture (or fail). The size of the resulting thumbnail has various hardcoded heuristics for aspect ratio and limits. The way pages get loaded for creating thumbnails is also relatively special, e.g., always tracking protection, no videos, anonymously. All of these can lead to unexpected results, e.g., a relatively blank thumbnail of part of a redirected login page.

Extremely useful info, Ed. Thanks for the detailed response. Seeing as how Activity Stream is having to navigate around several of the thumbnail quirks, it seems like extensions could generate frustrating user experiences quite easily. The general concept of having topSites return thumbnails, though, still seems like a good idea. So instead of denying this, I'm going to leave this feature in the design-decision-pending state with a dependency on meta bug 1445085.

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958