1162698 - Thumbnail generation should have a time limit

Status: NEW

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

Description

[Trevor Rowbotham [:rowbot]]

Attachment: memory-report.json.gz

The thumbnail service seems to cause high CPU usage and high memory when trying to get a screenshot of a page that has a long load time.  The latest x64 nightly maxed out at 4.6 GB for me with only the about:newtab page open. Once the browser obtains the thumbnail, high CPU usage and high memory usage no longer occur.  I have also attached a report from about:memory when this occurs.  I did notice that the child process has about 930 MB in heap-unclassified, which seems really bad.

** Warning ** - The page in question is a PHP script that contains an infinite loop that just prints "Inifinite Loops! \o/".

STR:
1) Create a new profile.
2) Load [1] so that it gets put as a tile on about:newtab.
3) Close the browser and reopen it.
4) Open a new tab or browse to about:newtab.

[1] http://trowbotham.com/bug_tests/iloop.php

Actual Results:
For me, plugin-container consumes 15% CPU usage and memory usage quickly skyrockets.

Expected Results:
Normal resource usage when the browser is trying to obtain a thumbnail.

Comment 1

[Trevor Rowbotham [:rowbot]]

Forgot to mention that I am on Windows 7.

Comment 2

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

As master in these cases can you look on this issue?

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

Sorry, my next two weeks look rather busy due to a lot of traveling. Might not be able to look into it anytime soon.

Comment 4

[Trevor Rowbotham [:rowbot]]

Just wanted to pop back in to say that the runaway thumbnail service is still a thing. The example URL in comment #0 is obviously contrived, however, the point is that any misbehaving site that makes it into about:home's Top Sites can cause high CPU usage and high memory usage to persist for the duration of the user's browsing session (and every session after that since opening the browser will navigate to about:home by default resulting in the browser trying to get a thumbnail again) and will continue to use those resources until either a thumbnail is obtained, the site stops misbehaving, or it gets knocked out of the list of Top Sites.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

The problem here appears to be it trying forever to generate thumbnails; we really should have a time limit on thumbnailing a site. (it's especially bad if we restart thumbnailing when the browser restarts).

Comment 6

[Pablo]

Hi trevor, is this bug still valid? i could not reproduce on windows10 with firefox release94 and opening about:newtab.

but after i go to that site and I close firefox, firefox.exe was still showing up in task manager. had to close it manually in the task manager.

Comment 7

[Trevor Rowbotham [:rowbot]]

Its hard to say given that the new tab page no longer uses a capture of the page as a tile image. Is the thumbnail capture service still used somewhere in the browser in a way that can be tested? If I had to guess, the underlying problem likely still exists.

As you mentioned, loading the page prevents the browser from shutting down in a timely manner, which I believe is related to Bug 1164189 in this particular case. If not, perhaps a new bug should be made for that problem.

Comment 8

[Marco Bonardo [:mak]]

We could potentially add a timeout to thumbnail generation as said, where we'd abort the network socket after a certain amount of time, but in the end a page like this also looks like a potential DOS attack to the user.
Does the DOM team have any plans to prevent or notify something like this to the user?

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Marco Bonardo [:mak] from comment #8)

We could potentially add a timeout to thumbnail generation as said, where we'd abort the network socket after a certain amount of time, but in the end a page like this also looks like a potential DOS attack to the user.
Does the DOM team have any plans to prevent or notify something like this to the user?

Hi Marco, no, we don't have any plans here. Please feel free to let us know if the front-end needs additional information from the platform side to solve this bug. Thanks.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:amy, could you have a look please?

For more information, please visit BugBot documentation.