I can understand that after an update that there would be a longer period of time where Firefox would take to shut down, however that does sound quite annoying.

I am happy to help troubleshoot. I would first restart Firefox in Safe Mode to make sure it is not a hanging addon process that could be causing the issue. Diagnose Firefox issues using Troubleshoot Mode

Second, make sure there are no updates that are pending on the operating system. Third, in order to assist you better, please follow the steps below to provide us crash IDs to help us learn more about your crash.

The crash report is several pages of data. We need the report numbers to see the whole report.

1. Enter about:crashes in the Firefox address bar and press Enter. A Submitted Crash Reports list will appear, similar to the one shown below.
2. Copy the 5 most recent Report IDs that start with bp- and then go back to your forum question and paste those IDs into the "Post a Reply" box.

Note: If a recent Report ID does not start with bp- click on it to submit the report.

(Please don't take a screenshot of your crashes, just copy and paste the IDs. The below image is just an example of what your Firefox screen should look like.)

Thank you for your help!

More information and further troubleshooting steps can be found in the Troubleshoot Firefox crashes (closing or quitting unexpectedly) article.

Use one of these to close Firefox if you are currently doing that by clicking the close X on the Firefox title bar.

• "3-bar" menu button -> Exit (Power button)
• Windows: File -> Exit
• Mac: Firefox -> Quit Firefox
• Linux: File -> Quit

guigs, there are two types of crash report -- unsubmitted and submitted, with only the latter beginning with "bp". None are as recent as the upgrades to v53.0.3 or v54.0.

Unsubmitted Crash Reports

03a1aec6-1903-409a-a44f-aad33b641163 4/24/16 6:47 PM eff777da-77e0-4567-a2bd-651e96d8fecf 1/5/16 3:16 PM 156f12e0-c8c2-4109-80fc-2a71e1aa70fc 11/18/15 7:40 PM b156ea90-1d4b-4242-b400-3267b2aa795d 11/18/15 7:38 PM 609dfe03-edef-41ca-bd66-81ec834c8f41 8/6/15 10:06 PM

Submitted Crash Reports

bp-35e65f6a-af67-43d0-9f77-fb31b2151220 12/20/15 11:45 AM bp-8d78d89a-a3e4-4949-806b-d8eae2151219 12/18/15 7:33 PM bp-08c20abe-8d96-4bed-b33e-c8d2d2150606 6/6/15 3:55 PM bp-3beed8be-5cc6-4513-ba0b-7c2a72150529 5/29/15 11:30 AM bp-a163af18-c21d-4ae2-9069-c696d2150529 5/28/15 7:46 PM

I clicked on the first of the unsubmitted links as it was the most recent from late April 2016 and it then reported, but took awhile -- returned the following: ID: 8c63e189-1ce4-49d0-92ad-1bd3f0170616 Signature: F1398665248_____________________________

However, I will note that the app did it AGAIN this morning (default Mozilla start-up page + other standard default settings rather than my personalized ones in most, but not all categories, & had to accept the usual cookies and scripts all over again), after I had waited for at least 10 minutes to shut down the desktop last night following presumed closure of FF (think I used the red "X", but will use the "File|Exit" method next time AND monitor Task Manager to see if it has really closed).

REALLY frustrating.

Could you please open the Browser Console in the Tools > Web Developer menu and look for specific error messages as soon as sluggishness or other performance issues occur, or just occasionally? Especially look for ones starting with the following:

Could not write session state file Error: TypeError: invalid 'in' operand exn Could not write session state file Error: NS_ERROR_OUT_OF_MEMORY: Handler function threw an exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE)

Also: - Is your Firefox set up to use a proxy server or a .pac file to do so? - What is the manufacturer of your graphics chipset or card?

If you are willing to do so, please try a Nightly 55 or 56 build from here (installer) or here (zip), launch that instead of version 53 or 54 but with the same current Firefox profile or a copy of that profile, and report back how things go.

Edit Update without bumping the thread. I did link this to a comment in: Bug 1368321 - Firefox version 53.0.3 appears high memory, high resources usage and might causing for SSD damages

Just commenting so I can easily lurk on this thread. At least whilst we remain on this forum software.

jhvance It may be worth turning on Telemetry & FHR.

• Share data with Mozilla to help improve Firefox
• Firefox Health Report - understand your browser performance

I will follow with interest.

Even if I wait for more than a few minutes to shut down my desktop in the evening after closing FF, I can still get that recovery option with the previous session's tabs when I boot up the next morning and launch FF. Perhaps this is associated with the gonzo-high RAM usage of the FF cache (?) and the time-consuming process needed for properly saving those cache files to reload with the next launch, but both problems are irritatingly troublesome and need to be addressed by the development team. 

<rant> My suggestion links higher up in this post are not going to help you directly and immediately but

• Over time FHR may build up some interesting stats about your problems, and be much more helpful than some simple qualitative report.
• Some maybe even most of the telemetry info is publicly available (once anonymised).
  • It would be good if you joined in and contributed data
  • I personally may have difficulty sometimes deciding which element to examine but hey it should allow us to compare your experience and compare with those of others.
  • I am sure someone will explain specifically what metrics we should look at.

Maybe give DE a Whirl: instead|as well as; Nightly Tonnes suggests you try Nightly. I imagine many|most contributors here use nightly. Personally I am now in the process of swapping default browsers on Desktop and Android to Nightly, however for the purposes of your problems, and for troubleshooting it may be worth trying Developer Edition. My reasoning

• Clean Install
  Whether you use the standard 32 bit or the newer 64 bit version of Firefox the DE (nee Aurora) is a clean install.
• Separate Browser
  By default this installs as a separate additional browser. < br>It does not mess up your ordinary Firefox (Release) or make any changes to your ordinary settings and extensions (Profile)
• Simultaneous
  If you machine has the resources you may not only have multiple versions & profiles, you may run and compare them at the same time. That may be slightly advanced - You do not want to corrupt profiles, or as simple as choosing the App to run.
• DE is Beta based.
  • It has to be safer for ordinary users,
    although Aurora whilst it existed was excellent and rarely - at least for me - crashed more than a Release
  • Beta: lets face it most of the time it is our RC and is solid and reliable.
  • RIP Aurora. - mixed feelings - one less level - one less period for testing;
    but hell I guess others just pump it out anyway. If it does not have a significant userbase why have the delay of a A2.
  • I hope someone gets people trying this [DE|Beta] out and maybe combining Aurora & Beta helps

</rant>

Yesterday evening, I watched in Task Manager the FF entry resurrect itself repeatedly long after I'd gone through the 'normal' quick-shutdown gesture by force of habit -- clicking the red "X" instead of "File|Exit". I had brought up Task Manager to see what the RAM load was, and saw that it was really pretty high (1.8+ Gb, though I've noted it's been higher) after having been running much of the day with only 4 tabs open, none of which were very active in the background.

I have a small resident app named CleanMem that I've used since the browser I previously favored (Opera, before switching to FF in 2012) displayed similarly egregious RAM-hogging behavior, and so after a few minutes as I watched the FF entry in TM extend its RAM-suck at such high levels without variation or shutdown (and no indication of decrease), I began using CleanMem in alternating action to clean the memory and then clean the cache, repeatedly. Every time, the FF RAM load would drop to perhaps <50k before it would quickly rebuild to 200k+ in a few seconds before I took the next manual action to flush it again. A couple of times I waited longer until the RAM load had built up to over 1Gb again before another cleaning cycle. This pattern continued for another several minutes before I simply got fed up with the maverick behavior and terminated the process tree in TM.

Naturally, this morning when FF launched it offered to recover those tabs which I declined, and thankfully there hasn't been another episode where it's lost the customized user-set of opening webpages so it seems to now be acting "normally" in that respect.

I know this help forum is staffed by volunteers who do their best at responding to user issues and not Mozilla developers, but the latter really needs to be boxed about the ears as there is something seriously amiss in the code which a) allows (or forces) the RAM load to reach such egregiously high levels and b) fails to deal with said RAM load properly in executing a normal shutdown command within any reasonable timeframe.

I've got plenty of other things to do in life instead of going through a lot of arcane debugging with alternate profiles and multiple test installations, and though I've been a loyal FF user for many years it is reaching a point where I'm seriously considering a switch to Pale Moon (I detest Google and won't use IE for much of anything unless absolutely necessary).

As I type this, Task Manager is showing the FF RAM load as fluctuating between 2.2-2.8 Gb with 6 tabs open (one of which is this Mozilla webpage and another is the Options|Advanced page where the cached web content is about 7.5 Mb of the 75 Mb I've capped it with the override function). Using CleanMem to flush the memory and cache reduces that load to 700k for a few seconds, but it rapidly builds back to 2.6 Gb.

Absurd...truly absurd. Firefox has become an incredibly bloated memory hog, and my tolerance for its behavior is stretched so thin at this point I'm nearing the point of a permanent change.

When we get problems that everyone sees it is easy we can file bugs and get things fixed.

Testing and then telemetry on pre Release builds should pick up problems. Unfortunately there are still problems that can impact a lot of users but are nowhere near seen universally. Some security software or adblockers are very commonly used and can cause issues.

Unfortunately to identify issues and get correct bugs filed we need to find users that see the issue and have the time and competency to run tests Obviously any issue that is intermittent or only seen after a long period of browsing may be difficult to troubleshoot.

Firefox has for a long while now had a relatively user friendly "about:memory" tool built in. That can be handy to take snapshots of increasing RAM use and will dif the snapshots to show what is increasing:

• https://developer.mozilla.org/docs/Mozilla/Performance/about%3Amemory
• Also https://developer.mozilla.org/docs/Tools/Memory

jhvance said

... Perhaps this is associated with the gonzo-high RAM usage of the FF cache (?) and the time-consuming process needed for properly saving those cache files to reload with the next launch...

In my experience, this behavior (both) could just indicate an issue with Session Restore and one or more corrupt files of it.

Although perhaps unrelated to the above, there was a near-simultaneous flush of the allowed cookies and scripts as well as home-page settings in the upgrade to v53.0.3 that was repeated in the upgrade to v54.0.

This is helpful and may be related, as home page settings affect Session Restore in some way. It may also indicate some other issue in Firefox’s preferences file causing them not to save properly. That could be regardless of the version of Firefox and repeat itself in the next upgrade, since profile data is just reused and the original issue is still there.

Please note that caching behavior may not be as important as you think at this point, and cleaning memory using tools might be to no avail as long as the original issue will cause memory to increase anyway. Also note that you do not seem to have recent crash reports, but I think you can skip that too because nothing appears to be actually crashing.

Forget my 3 previously posted questions above or feel free to answer them now - they are less important than assumed earlier (though it’s best to answer them in general since helpers need such input rather than seeing them ignored and reading new behavior descriptions) - but:

- Did/could you try deleting the sessionstore.js file in your Profile folder after closing Firefox, as suggested in the Firefox hangs or is not responding support article?

If there is no such file when Firefox is closed and no longer active (check the process activity since Firefox shutting down may take a while for you), you can be pretty sure something is wrong with Session Restore. The file needs to be there and if not, Firefox will use backup files from it that may also be damaged and get worse at each use of Firefox for obvious reasons, and memory consumption may rapidly increase. Therefor and either when the file is present or not, it may be good to empty the sessionstore-backups subfolder in the profile folder too. Just opening and closing Firefox once with no tabs open should also "clean" the sessionstore files. If you are worried about losing session data, bookmark all tabs beforehand using the Bookmark All Tabs context menu option on one tab so you can restore them in a new session afterwards.

- Creating a new profile instead - even for testing purposes only - should also help, should take you less than a minute and is useful anyway just to know if an issue is profile related. Additionally you can rule out other preferences that may be corrupt, which may apply here if the above doesn’t help. Recovering important data from an old profile afterwards is a small step.

- Of course you could also choose to refresh Firefox, which is basically similar to the previous option.

Task Manager a few minutes ago was showing that FF (with 7 or 8 tabs open) had a RAM load of 5.05+ Gb and was increasingly slow to respond. Using the about:memory "minimize memory usage" toggle dropped that to about 3.1+ Gb after it's 3-cycle flush was completed. I toggled the "save memory reports" and created a file which is (or should be) available to anyone at the following Dropbox link:

https://www.dropbox.com/s/5b2w9kwawod2de3/memory-report.json.gz?dl=0

Perhaps one of the kind wizards who have responded earlier can make sense of it and provide further insight toward a concise approach of resolution. I simply don't have a lot of time (or much inclination) for tweaking profiles (which then require a lot of customization in order to function without an overwhelming onslaught of ads and unblocked scripting) and no inclination to engage in testing nightly builds, as I have a life which doesn't involve coding (since the days of Fortran, anyway) or in-depth IT diagnostic confabulations.

The memory report shows that lastpass is already using 1.5 GB

• 3,628.40 MB (100.0%) -- explicit
  • 1,598.99 MB (44.07%) -- add-ons
    • 1,551.30 MB (42.75%) -- support@lastpass.com
  • 1,213.22 MB (33.44%) -- js-non-window

• 3,037.43 MB (100.0%) -- js-main-runtime
  • 2,152.13 MB (70.85%) -- compartments

• 2,223.21 MB (100.0%) -- js-main-runtime-gc-heap-committed
  • 2,153.95 MB (96.88%) -- used
    • 2,058.82 MB (92.61%) -- gc-things

Short(er) version of a pre-written reply:

- LastPass is known for issues with Firefox in the past and should be disabled when troubleshooting, as with any add-on. (Too bad it isn’t reported in the question details.)

- It may not be wise to completely ignore suggestions/steps and questions from helpers (let alone this may be considered as unfriendly).

- It may not be wise to write things like "I don't have a lot of time (or much inclination) for..." while knowing both starting Firefox in Safe Mode (=no add-ons) and starting it with a new, fresh or just different profile are kind of prerequisites in order to troubleshoot problems and get help here, and both actions could take less than a minute in total. Both features and the Refresh Firefox feature weren’t invented for nothing and serve a purpose, so they should be used rather than providing ongoing complaints about non-default behavior of Firefox (taking much more valuable time eventually) with a possibly biased thought of Firefox being a memory hog and hence responsible for any issue, even addressing the development team.

- A corrupt session restore file is certainly able to make Firefox consume lots of (or even all) available memory, resulting in slow shutdown/startup times and a memory report such as the one provided, including typical high heap sizes that should normally be a few dozens of MBs at most. Not surprisingly, Firefox may not be able to store some settings at shutdown in such case. I can produce a similar memory report by simply restoring a corrupt session file from an affected profile to a current and properly working profile.

^{Side note: recent Nightly builds do not seem to be affected by a corrupt session restore file this much or even no longer at all, which is the reason I suggested to try one for a minute to pinpoint the cause in another way. Maybe that helps restoring some of your trust in Firefox and its memory management in general; you may actually be surprised to see how well they perform if you just tried, either using your primary profile or by creating a second one and copying the primary one’s content there for proper comparison. Testers are always welcome, especially critical ones.}

So in short:

• Start Firefox in Safe Mode (hold down Shift while clicking the startup shortcut, or use the Restart with Add-ons Disabled… menu item in the Help menu). All fine? -> LastPass or some other non-reported add-on
• Start Firefox with a new session, i.e. do not click Restore Previous Session at startup or choose a different setting than Show your windows and tabs from last time in the Startup section in Options > General (or look for the missing file as suggested above / remove its backups). All fine? -> Corrupt session restore file(s)

Still an issue?

• Download the Firefox 52.0.2 or Firefox 53.0.2 version (2 minutes) and install it after uninstalling version 54.0 - all data and settings will be preserved when uninstalling - to actually prove the issue is version and not profile related and got introduced by 53.0.3. Set Firefox to not automatically update itself before uninstalling 54, or you will only be able to test one session for obvious reasons.

Still an issue in 52.0.2 or 53.0.2 (and it wasn’t in the past)? -> Possibly a different profile issue introduced in your 53.0.3 by coincidence, i.e. some other file may be corrupt. -> Create a new profile, test, and restore important files from the old one as suggested earlier.

I don’t think we can make things easier for you.