Sounds like Firefox might not commit data fast enough when the killswitch hits, probably leaving loose ends behind. Do you have a big session open (lots of tabs, multimedia, full cache load)? What sort of hardware are you running Firefox on (storage, RAM, CPU)?

I rebooted and then shut down to see how mine would react; the previous session is restored no problem after both, but I only had two tabs open and Firefox set to clear cache on every exit.

I would suggest the following:

1. Update Firefox. Your details say 45.0, the latest for Windows 7 is 45.0.1. Obtain here: https://www.mozilla.org/en-US/firefox/all/.
2. Clear your cache. May help a lot or just a little, but it's basic maintenance: https://support.mozilla.org/en-US/kb/how-clear-firefox-cache. Note that you'll need to preserve the site-specific cookies to retain your login on those sites (e.g. Google, Youtube).
3. Reboot with no tabs open in Firefox, then gradually increase count if you find success.
4. Disable all Extensions, Themes and Plugins from about:addons to see if they're affecting things.

FF44 or 44.0.1 same issue. Clearing cache, disabling all add-ons, and using a minimal session did not help. Using refresh did not help.

The issue does not seem to be from shutting down FF too fast, since it is always able to preserve recent changes in a saved session available in the next startup session window. I do use session manager.

To recap: I am able to get my sessions restored automatically if I quit FF from the FF menu, but not if I let the OS shutdown FF. The session IS saved properly, but somehow marked as a browser crash, preventing its automatic restore. The behavior seems the same on XP and Win7 platforms.

Alright, let's explore the crash angle as well then. Do you have recent reports in about:crashes, preferably ones that coincide with the shutdowns?

Regarding improper exits, I found this recent bug in Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1260461. It sounds like the sort of problem this would be, i.e. Firefox is not exiting (correctly) if prompted by a system shutdown. The fix is marked for "48", but my 45.0.1 already exhibits correct behaviour, so there could be a setup difference at play like in any case where the issues aren't universal.

The Session Manager add-on sounds like it could be related, but if you tried a completely fresh Firefox and profile with nothing even installed, it would not have had an opportunity to affect things. I don't use it myself, so I have no knowledge of how it works (mainly whether or not it makes changes to your profile and Firefox settings).

I have nothing under about:crashes since I recently cleared it. At this point I can only tell you what I see in context of session manager. In SM, I cleared all backup sessions and rebooted a bunch of times. Looking at the 10 most recent .session files, (using notepad) I can see that almost every other session backup is marked as a crashed session. Despite this out of those 10 reboots, only one restored automatically and nine caused the SM window to pop up saying my session crashed, so pick a session to restore.

For the session that did restore, I had waited after boot to start FF rather than start it asap. This win7 starts really fast, and I thought there might be some issue there, but the waiting part did not seem to be the key factor though.

There seems to be a disconnect between what SM states in the session backup file and how it behaves. These 'crashes' it claims are not creating crash reports, perhaps because the system is shutdown before it can?

How long does it take Firefox to close completely if you check that in the Windows Task Manager?

Are you using "Clear history when Firefox closes" to clear any personal data as that can add to the time needed to close Firefox?

If I watch task manager during a menu exit of FF, I have seen it take as much as 20secs to shutdown but it can also take as little as 3 secs. I don't use that clear history setting. I did refresh yesterday so I don't have much history.

I examined the SM backups at each stage of a reboot. During shutdown I saw a session backup file appear. After bootup I looked at this same file and it was not marked as crashed. Then I started FF, and got the SM load window, and a new session backup appeared. Looking in the file, this one was marked as crashed. This only took a second or two, so its not like it went through a real crash scenario. FF/SM can create session backups on both shutdown and startup, and whatever the issue is, it is not being identified during shutdown.

All of these backups can be loaded successfully from the SM window, with all prior changes preserved - nothing wrong with those.

So

45.0.2 got released recently, is the issue still present in that version?

Phoxuponyou said

45.0.2 got released recently, is the issue still present in that version?

YES

I've been racking my brain over the weekend about this, but all avenues seem explored. The only thing that feels like it could prevent the behaviour would be changes in Firefox's code (see the Bugzilla bug) that account for your shutdown scenario - again, mine seems to recover sessions fine for now (sans Session Manager).

PS. My knowledge of Firefox is just user level stuff - there could be settings and parameters that affect shutdown behaviour buried in about:config, but no relevant ones come to mind. You can find explanations for most stuff at http://kb.mozillazine.org/Category:Firefox if you feel like digging further or come across recommendations on what to do config-wise.

To add to the data, I have done another clean install of 7pro on a second machine, installed all windows updates, installed FF (no add-ons at all), and I get the "this is embarassing" screen every time on reboot. This seem to be pretty convincing evidence of a FF bug.

My OS installs are 7pro x64. On this latest machine I have yet to install much additional SW, but I DO have: msse, malwarebytes free, pdfredirect free, 7zip x64, irfanview x64,

Nothing that should interfere with FF behavior.

Lets just consider your normal practice per the original post.

... If I quit FF using the menu before reboot, session restore still works automatically on bootup. If I shutdown/reboot without first quitting FF (my normal practice), ....

• Why are you dong that ?
• Why deliberately prevent Firefox from working as intended ?

Firefox is designed to be allowed to shutdown in an orderly manner. In recent releases there may sometimes have been problems with the shutdowns. If Firefox does not closedown properly, either because of some fault or because it was killed prematurely there may then be knock-on problems when it restarts.

If for at least a couple of consecutive closedown and starup cycles you ensure Firefox has a good ten minutes to closedown do things improve ? Or do crash reports get generated ?

If Firefox fails to closedown properly it should timeout. It should then attempt to generate and submit a crash report.

Crash Reports ? Are you seeing the Crash Reporter at all, or are you finding crashes listed if you look in about:crashes

• Please see Mozilla Crash Reporter

tns1 said

To add to the data, I have done another clean install of 7pro on a second machine, installed all windows updates, installed FF (no add-ons at all), and I get the "this is embarassing" screen every time on reboot. This seem to be pretty convincing evidence of a FF bug.

It depends what you are doing. A clean install of Firefox, with a clean Firefox profile. You open and allow Firefox to open its default tab. No plugins enabled (You may need to disable them). Then close Firefox using the Firefox menu. Allow it a few minutes, and only then shutdown Windows 7, using its own closedown option. In those circumstances are you seeing the embarrassing page ?

If a menu exit is used, there is never an issue. If the OS shuts down FF, there are issues restoring the session almost (but not) every time. Add-ons seem to make no difference. The latest box is as described - a clean FF install with no profile.

My normal practice is to use sleep or hibernate, so no session is being saved or restored. If I do reboot, I might use a menu exit for FF or I might not. After all, even lowly notepad can block a shutdown if there are unsaved edits. I had assumed all along that most programs including FF would use a similar mechanism to delay shutdown if there were housekeeping left to do.

Setting up a new OS involves many reboots, and I was rebooting into each OS to look at settings and use FF in each. The failure to restore seemed like new behavior, but what I was doing was atypical. All this may have brought a behavior of FF to my attention that was there all along but didn't notice before.

The big question: is having FF shutdown by the OS something that is supported or not? If not, why not?

I am not sure anything is designed to guarantee being cleanly shutdown by the OS. It would certainly be preferable to allow Firefox to close down itself. I probably have some Linux distros that don't even reliably sleep/hibernate.

Firefox itself may get race conditions on close down add into the mix the fact that I imagine different OSs have their own timeouts, and possibly unpredictibke behaviour depending on what is running or closing it would seem plausible to me that forcing close down could result in problems.

We can add to that the problem that recent Releases of Firefox have had issues with close down and restart.

Your issue may be a change in behaviour & it may be a big - known or otherwise, but I am not sure it is the sort of issue that will be likely to warrent investigation

Don't know if this will help or not...

Recently I found a copy online of the add-on Evernote Clearly, and installed it for use in Firefox. I had to disable Firefox's permissions restrictions to do so.

I've found that as long as Clearly is enabled, Firefox will not restore sessions. I can disable Clearly and things go back to normal.

So, the question is, is Clearly the cause of the fault, or is any unsigned add-on going to do the same thing? I probably won't experiment further...my problem is solved. But perhaps this may lead the orginal questioner in a positive direction.