Another hypothesis is that it’s possible our tab unloading sometimes kicks in a fraction too late and finds the tabs in a state where they can’t even be safely unloaded any more.įor example, unloading a tab requires a garbage collection pass over its JavaScript heap. With tab unloading, this event is fired after all possible unloadable tabs have been unloaded.
#Mozilla crash reporter everytime i close firefox windows
Before tab unloading was introduced, Firefox already responded to Windows memory-pressure by triggering an internal memory-pressure event, allowing subsystems to reduce their memory use. The increase in OOM crashes, also very counter-intuitive, is harder to explain. Much like in the archetypal example of the Allied WWII bombers with bullet holes, browser sessions that had such high memory usage would have crashed and burned in the past, but are now able to survive by unloading tabs just before hitting the critical threshold. The latter may seem very counter-intuitive, but is easily explained by survivorship bias. We also found that average memory usage of the browser increased. Most encouragingly, people who had tab unloading enabled were able to use the browser for longer periods of time. Of those remaining crashes, we saw an increase in OOM crashes. However, after the month-long experiment, we found an overall significant decrease in browser crashes and content process crashes. With our experiment on the Nightly channel, we hoped to see a decrease in the number of OOM crashes hit by our users. We’ll continue to monitor the results as the feature ships in Firefox 93. We’ve seen encouraging results with that experiment. Recently we have been conducting an experiment on our Nightly channel to monitor how tab unloading affects browser use and the number of crashes our users encounter. We have now approached the problem again by refining our low-memory detection and tab selection algorithm and narrowing the action to the case where we are sure we’re providing a user benefit: if the browser is about to crash. We have experimented with tab unloading on Windows in the past, but a problem we could not get past was that finding a balance between decreasing the browser’s memory usage and annoying the user because there’s a slight delay as the tab gets reloaded, is a rather difficult exercise, and we never got satisfactory results. Firefox is now better at surviving these situations. And of course, there are the tab hoarders, (no judgement here).
Or perhaps those users simply trying to play a memory-intensive game or using a website that goes a little crazy. We believe this may especially benefit people who are doing heavy browsing work with many tabs on resource-constrained machines. Unloading tabs allows Firefox to save memory leading to fewer crashes and avoids the associated interruption in using the browser. On Windows, out-of-memory (OOM) situations are responsible for a significant number of the browser and content process crashes reported by our users. The tab’s scroll position and form data are restored just like when the browser is restarted with the restore previous windows browser option. When a tab is unloaded, the tab remains in the tab bar and will be automatically reloaded when it is next selected. This feature is currently enabled on Windows and will be deployed later for macOS and Linux as well. Starting with Firefox 93, Firefox will monitor available system memory and, should it ever become so critically low that a crash is imminent, Firefox will respond by unloading memory-heavy but not actively used tabs.