1706449 - Prevent thumbnail generation for new tab page in Proton

Status: NEW

(Firefox :: New Tab Page, defect, P3)

Description

[Qwerty]

Looks like updated activity stream in Nightly stopped showing thumbnails of pages at all (not inconsistently as before: Bug 1593563), but Firefox is still visiting pages (bypassing content blocking extensions) and creating thumbnails on disk for no purpose.
This should be disabled now if there is no plan to show thumbnails on new tab page. It will also solve many privacy and performance bugs like Bug 755996, Bug 1509084, Bug 1452388, Bug 1162698, Bug 1449062, Bug 1475785, Bug 1674252.

STR:

1. Create new profile in Nightly
2. Open new tab, pin this page in top sites manually: https://wiki.mozilla.org/Release_Management/Calendar
3. Wait
4. Go to AppData\Local\Mozilla\Firefox\Profiles\profile-name\thumbnails and see a thumbnail file for top site created in 2nd step

Comment 1

[Marcela (Please NI request to Brindusa Tot)]

I was able to reproduce this issue on latest Nightly version 90.0a1 (2021-04-22)(64-bit) on Windows 10.
I'll change flags accordingly. The severity suggested is S3.

Comment 2

[:Gijs (out for now; he/him)]

Romain, can we re-evaluate the priority here given the potential for performance and privacy improvements?

Comment 3

[Romain Testard [:RT]]

Jim, can you please confirm that we're good with removing this capability that is not being used on new tab though negatively impacting performance and privacy?

Comment 4

[Ed Lee :Mardak]

I believe top sites -> edit -> Use a custom image… currently relies on the "thumbnail" ability to locally cache an image url. Originally added in bug 1397390 probably for highlights/bookmarks that have an image then reused for custom images. So that custom image functionality might need to be removed or reworked to cache (avoiding live requests to a web image on new tab).

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Could we perhaps flip the browser.pagethumnails.capturing_disabled (https://searchfox.org/mozilla-central/rev/f351e19360729b351bfc7c1386d6e4ca4ea676e2/toolkit/components/thumbnails/PageThumbs.jsm#534-542) pref in the short term to disable capturing of background thumbnails, even if we can't get around to removing the code yet? That way we should stop performing the captures in the background. I don't know if this would impact the custom thumbnail ability, but I imagine that should keep working and it's probably at least worth checking.

Comment 6

[Ed Lee :Mardak]

Attachment: existing custom maintained with capturing_disabled

The pref is browser.pagethumbnails.capturing_disabled if anybody else was testing based on comment 5. It does break the custom thumbnail functionality to preview then save the image. However, users who have existing custom image urls do seem to work. See attached.

So there could be different product decisions to remove the functionality completely vs disallowing new custom thumbnails.

Comment 7

[Ed Lee :Mardak]

Ah, thumbnails are also used for "Recent Activity" pages and images, so there's more functionality that would break from just flipping browser.pagethumbnails.capturing_disabled. I believe the recent activity is off by default since 89.

Comment 8

[Jim T]

Yes, we should remove this feature, with the dependency that we remove the recent activity section and preferences. Amy, let's add this to our backlog and prioritize accordingly.