Note that we already have code that will conditionally clear various main-thread page-data caches once rendering completes, see

So one thing that you could try experimenting with is setting this.#pendingCleanup = true in GECKOVIEW-builds, once rendering completes, since that might help without having to adding a bunch more complexity (e.g. ´WeakRef`s to the code)?

This should help reclaim memory faster, using existing code; obviously at the expense of needing to re-parse pages more often.

The main advantage of the WeakRef approach is that we'd be able to adapt to the device, I mean if the device as a low memory (even if it has a lot of memory but a lot of open apps) then a GC is triggered when potentially GC'd be less frequent if the device has enough memory. For example, myself I'm not able reproduce the bugs we've because I've a recent device with a lot of memory and in my case I'd prefer rendering performance over memory use.
In general, the problem with hard-coded values is they're well-tuned for some device/usage/users... when they aren't for some others.
That said in term of complexity, we should likely just have a cache object with all the caching logic inside instead of spreading some little piece everywhere, which could help us to make some experimentations.

Trying the WeakRef approach seems most promising for a good balance between perf / memory.

That said, I can reproduce the bug, if you have any quick patch I could try it out to confirm a potential cause for the problem.

Since #18148 (comment) sounds a little bit like it's written by an AI, please note that you're not allowed to write code using AI for Mozilla projects (based on a general question about AI in the Mozilla Matrix "developers" channel).