+++ This bug was initially created as a clone of Bug #1674295 +++

I'm cloning bug 1674295 in case there is a graphics issue buried in here too.

Quoting bug 1674295 comment 12:

I can confirm that Facebook is eating up memory on chrome as well (shame on Facebook!) however there are certain differences:
...
As said above the GPU process is eating up the memory on par with Facebook tab. This is happening both on Firefox and on chrome. However in chrome the memory on GPU is immediately released when the Facebook tab become idle (e.g. I don't hit space to load more posts). In Firefox GPU process memory does not decrease.

:jonco, can you attach about:support to this bug?

Since the initial comment was mine, I assume it is me to provide about:support requested.

Since the original comment was mine, I guess it is me to provide about:support

The issue is similar in Firefox rev 83.
Attached is about:support the the Firefox 83 I'm using at this moment.

From about:support, WebRender was used.

In the memory report from bug 1674295 comment #19 it looks like WebRender is not being used. Tudor, can you attach a new memory report to this bug when you confirmed that about:support has "WebRender" listed as "Compositor"?

Jeff, the bug 1674295 comment #19 is not mine.
I will provide a new memory report, about:support and a procexp.exe capture for Nighly restarted with two tabs (Facebook and about:memory) where procexp reports 2G usage for gfxand 1G usage for Facebook tab.
I don't know how to read the about:memory contents but it seems that the firefox memory report and porcexp memory report does not reconcile.

I believe process explorer can report GPU memory usage can you check that as well?

The memory usage did not decrease after about one hour.
The system GPU was about 667M and increased to about 800M when I switched to Facebook tab

I continued to use Facebook (watch some videos, loaded some more posts) on this Nightly running instance until the memory for GPU porcess was about 4G an for Facebook tab was about 3G. The entire laptop became more and more sluggish/unresponsive so I had to kill the facebook tab's process.
For about two minutes the entire laptop was still unresponsive. During this time the GPU process' memory decreased to something reasonable.
Killing Facebook tab created the following crash report:
https://crash-stats.mozilla.org/report/index/26e0acc4-46a5-45bb-b458-9842c0201127

Can you try setting media.hardware-video-decoding.enabled=false, restarting, and checking if you see similar leaking?

I can confirm that setting media.hardware-video-decoding.enabled=false made a big improvement.
The procexp.exe reports GPU process reached at most 350M Private Bytes, 310M System GPU 210M Commited GPU after some browing on Facebook (when the Facebook tab reachd 1.2G usage).
Thank you for this workaround.

Tudor, can you get a new memory report with a Nightly with a build id of 20201215213427 or newer (and media.hardware-video-decoding.enabled set back to true)?

Memory used initially on Facebook page

Memory used after loading a few posts on facebook

Memory uses after reloading Facebook page

Please note the procexp reports a usage of about 660MB for the GPU process 5084 despite the fact that the the 3rd report appears to suggest some memory release.
Please note that the web process 15776 reports a memory usage of 238.43 MB (60.67%) -- window-objects/top(<anonymized-10737418242>, id=30) for Facebook that does not seem to be released .
The memory is still in use even if I load bing.com on the same tab:
375.03 MB (100.0%) -- explicit
├──226.33 MB (60.35%) -- window-objects/top(https://www.bing.com/?toWww=1&redig=07D8E04E0BD34AE880FDC7837A6933A3, id=30)
│ ├──210.40 MB (56.10%) -- active
│ │ ├──204.31 MB (54.48%) -- window(https://www.facebook.com/REDACTED/)
│ │ │ ├──163.40 MB (43.57%) -- js-realm(https://www.facebook.com/REDACTED/)
│ │ │ │ ├──154.60 MB (41.22%) -- classes
│ │ │ │ │ ├───91.08 MB (24.29%) -- class(Object)/objects
│ │ │ │ │ │ ├──49.32 MB (13.15%) -- malloc-heap
│ │ │ │ │ │ │ ├──44.49 MB (11.86%) ── slots [2]
│ │ │ │ │ │ │ └───4.83 MB (01.29%) ── elements/normal [2]
│ │ │ │ │ │ └──41.76 MB (11.14%) ── gc-heap [2]
│ │ │ │ │ ├───27.08 MB (07.22%) -- class(Function)/objects
│ │ │ │ │ │ ├──23.15 MB (06.17%) ── gc-heap [2]
│ │ │ │ │ │ └───3.93 MB (01.05%) ── malloc-heap/slots [2]
│ │ │ │ │ ├───19.40 MB (05.17%) -- class(Call)/objects
│ │ │ │ │ │ ├──19.36 MB (05.16%) ── gc-heap [2]
│ │ │ │ │ │ └───0.04 MB (00.01%) ── malloc-heap/slots [2]
│ │ │ │ │ ├───13.89 MB (03.70%) -- class(Array)/objects
│ │ │ │ │ │ ├──13.13 MB (03.50%) ── gc-heap [2]
│ │ │ │ │ │ └───0.76 MB (00.20%) ++ malloc-heap
│ │ │ │ │ └────3.15 MB (00.84%) ++ (19 tiny)
│ │ │ │ ├────8.48 MB (02.26%) -- scripts
│ │ │ │ │ ├──5.82 MB (01.55%) ── gc-heap [2]
│ │ │ │ │ └──2.66 MB (00.71%) ── malloc-heap/data [2]
│ │ │ │ └────0.31 MB (00.08%) ++ (3 tiny)
│ │ │ ├───21.16 MB (05.64%) -- dom
│ │ │ │ ├──18.45 MB (04.92%) ── element-nodes [2]
│ │ │ │ └───2.71 MB (00.72%) ++ (5 tiny)
│ │ │ ├───19.69 MB (05.25%) -- layout
│ │ │ │ ├──18.49 MB (04.93%) ── style-sheets [2]
│ │ │ │ └───1.20 MB (00.32%) ++ (2 tiny)
│ │ │ └────0.05 MB (00.01%) ── property-tables [2]
│ │ ├────5.70 MB (01.52%) ++ window(https://www.bing.com/?toWww=1&redig=07D8E04E0BD34AE880FDC7837A6933A3)
│ │ └────0.39 MB (00.10%) ++ (3 tiny)
│ ├───10.79 MB (02.88%) -- js-zone(0x23ffcc9d000)
│ │ ├───5.83 MB (01.55%) ++ (9 tiny)
│ │ └───4.96 MB (01.32%) -- shapes
│ │ ├──4.55 MB (01.21%) ++ gc-heap
│ │ └──0.41 MB (00.11%) ++ malloc-heap
│ ├────3.88 MB (01.04%) ++ js-zone(0x23f8e115000)
│ └────1.26 MB (00.33%) ++ js-zone(0x23f85ed9000)

Tudor, we've fixed memory reporting in the GPU process. Is it possible for you to get some a new memory report?

Attached files 9198899: m210124_1.json.gz 9198899: m210124_2.json.gz 9198899: m210124_3.json.gz
contains memory usage after loading a facebook page (1), memory usage after loading multiple posting on the facebook page (2) and memory usage after many minutes of leaving the browser idle when procexp finally reports some memory release.
While this might not be technically a memory leak, the fact that memory is released many minutes makes Firefox and in the end the entire system to become sluggish.

Matt will try to look locally some more.

It looks like shut down the video decoders for videos that have been paused and scrolled offscreen, but we still frequently retain frames in the video queue (usually 4 from what I see, but seems like it could be up to 10).

If you scroll for a long time, on a feed with a lot of HD videos, then this could accumulate a lot of extra memory usage. We probably want to make sure we drop all but the current frame being displayed (and maybe that too eventually).

I can't reproduce this anywhere near as badly as the reporter, but I do see an accumulation of video frames.

Depends on D104141

https://hg.mozilla.org/mozilla-central/rev/80dd9df92e33
https://hg.mozilla.org/mozilla-central/rev/9bae9681f892