For a few months now I saw a huge improvement on Linux regarding the memory management of Firefox. Previously I had to run Firefox in a separate cgroup to limit its memory usage, because it could easily deplete my whole RAM. And if I did close most of my tabs it did not release the memory back to the system. Now I never actually get to the limit I've set before and also with Auto Tab Discard extension it is well managed. So kudos to the team for such improvements.
Firefox stability is funny ... I was at Mozilla for 10+ years and used Nightly as my daily driver on my work Mac. I don't think I got more than one or two dozen crashes in total. A crash was a special occasion and I would walk to someone's desk to show an explore. It barely every happened. On Nightly. So much love for all the stability work that is happening.
I can't remember the last time Firefox crashed and I've used it daily on Windows since ... the beginning. Are most issues related to stability more common to Linux/MacOS?
Great work!<p>This is also a good example of the benefit of telemetry: that they have crash numbers coming back from the field lets them tell that this really did work in practice and get a sense of how much of the problem they've solved.
The author left off the part where it was invented by a mother and how dentists hate it! /s<p>I suppose it <i>technically</i> improves stability, but the cause seems like a flaw in the Windows operating system, if I'm understanding correctly.<p>> Stalling the main process led to a smaller increase in tab crashes – which are also unpleasant for the user even if not nearly as annoying as a full browser crash – so we’re cutting those down too.<p>I wonder if this has anything to do with my recent experience with Firefox Nightly on macOS. In the last few weeks I started to experience spontaneous tab crashes that couldn't be explained by anything from what I could tell. I could open a new tab with the exact same page and it would manage to not crash. Then I noticed Firefox would sometimes prevent me from viewing tabs <i>until</i> I restarted to update the software. Haven't seen it in the last few days, but it was incredibly frustrating. IMO, Firefox should make a best effort to render a page and not have its core functionality stop working entirely until updating.
I've been a linux/osx user for 20+ years so I'm not familiar with Windows memory management. It'd be interesting to know why MS chose this approach and if it has any benefits? Why not just let userspace request whatever it wants?
For me, there's been some kind of weird instability or resource leak that resulted in Windows Firefox getting slower all around and less stable the longer the application is running. It's been around and 100% reproducible (over an active session of a few days) for a couple of years.<p>The general problem used to feature some sort of bug where some window processes would completely fail to render/paint UI components - instead, rendering them as pure black. The rendering problem is gone, same with a correlated memory leak, but the complete performance slowdown that accompanied it is still there.<p>One day I'll submit a bug report or profiler trace or something, but I find it odd every time I see a post about stability or performance fix, it never happens to be the big one that I run into, regardless of the window device or extensions.<p>It makes me wonder if some users just have browsing habits that most others don't, so they hit obscure bugs more frequently. But since everyone has their own obscure habits, and thus bugs, there's a theoretical endless deluge of problems with no critical mass to justify prioritization or investigation.
Has Firefox stopped allocating so much RAM that it fills up all my 40GB? Overcommit isn't always enabled, because I'm not making a 64GB page file just to keep Firefox running for more than a week. (That is how large Windows tried to make it before I disabled the page file.)<p>On my computer, Firefox running out of memory is its own damn fault. Retrying memory allocation won't fix anything! And running out of commit space crashes everything else too, so Firefox letting <i>itself</i> crash isn't going to help, because it still brings down half the system. (And it still, already crashes when it runs out of memory.)
Afaik memory-mapped files don't count towards the commit limit. Couldn't they roll a custom file-backed allocator (essentially manual swap) to get around the windows limit?
I use firefox mobile and it has very strange behavior quite often. It's the only browser I would ever use because of the ad block. But sometimes tabs become blacked out and you can't refresh them, you have to close them and start new ones. And sometimes I have two different (consecutive?) youtube tabs, and the second tab basically fuses with the first tab, to where both tabs show the same content and the same video. I wonder if in both of these cases a tab process was killed. It's pretty common
Haha I put sleep-retry to every explicit memory allocation in every delphi program I wrote since windows xp and not one person acknowledged it as a good practice. This is just too good.
Every couple of weeks my firefox was crashing tabs one after another.
And I always had to restart firefox.
This weird trick fixed it.
I made the entire firefox directory readonly.
Thank you for providing more stable experience. Would be great if something could be done about some Unity web games, that sometimes crash whole browser. It is a bit peculiar, while each tab seemingly runs in separate process, but one website crash takes down whole browser.
All these hacks blog posts are really interesting insights by Firefox engineers. Browsers in general are such a complicated system, so it's pretty remarkable what they come up with and what they learn when attempting to update Firefox.
Sounds like this feature should be built into the Windows releases of Firefox. Are there downsides?<p>I almost never had Firefox crash for more than a decade of heavy usage, then starting roughly 2 years ago it got janky quite often. Something changed.
Only somewhat related but what I'd really like to see is an investigation as to why Firefox takes so long to acquire a connection on Linux.<p>I suppose it could be something particular to my setup but it is very slow in comparison to 'ungoogled-chromium' which I keep around as a second browser.<p>On the network tab I routinely find Firefox in a 'blocked' state for 100ms. On chrome this rarely exceeds 1ms. I've tried messing around with various configuration options and haven't found an answer. The end result is Chrome feeling much snappier.
> The first computer I owned shipped with 128 KiB of RAM and to this day I’m still jarred by the idea that applications can run out of memory given that even 15-year-old machines often shipped with 4 GiB of memory.<p>I think a safe number for the modern web is like 64 Gb. At least if you want to have anything productive open besides the browser...
> trimming down Firefox memory consumption<p>Of that Firefox that can fill 16 Gb zram with lz4 compression and all remaining physical RAM with less than 100 tabs loaded?
Click bait title. On Windows, if they get an error on memory allocation, they wait a bit and try again. This gives the OS time to resize the swap file which means that the second try often succeeds.
> but what if we could recover from this situation instead? Windows automatically resizes the swap file when it’s almost full, increasing the amount of commit space available. Could we use this to our advantage?<p>I expect followup by some annoyed blogger that notices swap file ate his system partition and he spent whole day debugging the reason of that...
I’m really not comfortable with people trying to normalize that headline style.<p>This doesn’t work the way adopting kids’ slang “ruins” it and gets them to stop using it. Nobody doing it is worried about looking cool.