User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20101203 Firefox/3.6.13 GTB7.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20101203 Firefox/3.6.13 GTB7.1 I use the setting, "When Firefox starts, show my windows and tabs from last time." What I've noticed over time is that there are various circumstances that defeat this capability. Two that I've noticed recently are: * Firefox crashing while the "having trouble restoring this session" tab is open. (The "having trouble" tab comes back but the old pages don't.) * Firefox indicates at startup that it failed to install a mini update and offers to download the full version of the update. If you click the button to read what the update does, that information loads in a standard Firefox tab. Now if you go ahead and allow it to download and install the full update, session restore displays the "what's in this update" again instead of the old tabs from before. I'm sure I've seen other weird circumstances that caused this; I've been doing this awhile. Anyway it seems to me that the common thread in all of these issues is that the session restore feature always saves the session on exit, even if the session never got far enough to load the previous one. So, here's my suggested fix for all these issues. If there's a session waiting to be restored (either from a crash or the "save & quit" stuff), session restore shouldn't be saving a new session. Don't save any tabs until you've gotten around to restoring the last set. Does this sound doable? I think something like this would make the session restore feature more reliable. Reproducible: Always Steps to Reproduce: 1. Do anything that would cause a tab to open before the previous session was restored. (Usually this involves updates or the session restore feature itself.) 2. Exit before that previous session is restored. Actual Results: The sesion is lost. Expected Results: The session gets restored at the next start-up.
The first point is deliberate because it's likely something in the tabs is causing the crashing, so this prevents an endless loop after the second crash.
#1 - I don't see how that's the case. The original session, the one that the "having trouble" page is displayed for, hasn't been restored, and thus didn't cause the second crash. The second crash either came from Firefox itself, or some kind of extension. Failing to keep the session isn't saving anybody here; only safe mode would do that. Anyway, the second case of Firefox trying to update itself is probably a more likely scenario - I just listed both of the things that have happened to me recently. As I also stated I'm sure there are other strange ways to trigger this. On the whole, it makes session restore seem not very dependable.
These are really two separate issues which should be tracked in separate bugs. A bug for "Session not restored after software update". A bug for "Session not restored after crashing on 'having trouble' page" I know the point of your bug is "don't save new tabs before restoring old tabs" but this is as designed. When session store is enabled, all tabs are saved -- that's the point. In either case can you reproduce this situation using Firefox 4.0b8 or the Minefield nightlies?
sir moon, can you please try to reproduce this in the latest nightly? We need your test results before proceeding. Thanks.
> These are really two separate issues which should be tracked in separate bugs. Those were two different examples of what I saw as a more general problem. I understand the desire to address them separately, but I thought it would be more effective to address the class of problem rather than trying to hunt down every instance of it. > sir moon, can you please try to reproduce this in the latest nightly? We need > your test results before proceeding. Thanks. Part of the nature of this kind of problem is it's hard to reproduce on-demand. Or has something been added to help test this - like a circular update or something? > When session restore is enabled, all tabs are saved -- that's the point. Except that they're not always saved long enough that they don't get overwritten - that was my point. When given the choice between continuing to remember my tabs long enough to restore them, and remembering tabs generated by Firefox that in any other program would be dialogs, the choice seems obvious to me. You restore the user's content, not application dialogs. But perhaps you can do both - can session restore be made to "append" in the case that previous restore data hasn't been used? Either way, the current restoration behavior is fragile, and over the years, in strange, rare, non-reproducible circumstances not involving updates or the "having trouble" page, Firefox has found other ways to dump saved pages before restoring them. This bug is about making that impossible, period. Regardless of when session restore has been invoked or why, it should not be discarding un-restored session data. If everyone else is content to leave open this general problem, and just wants to tweak the update algorithm a bit or what have you, then so be it. But even though it was a recent update that finally drove me to put this forward, I've seen this enough times and am frustrated enough by it that I really think Firefox should provide a stronger guarantee that a saved session will actually be restored, period, regardless of when or why session restore was invoked. Because otherwise, what is the point of even having it?
(In reply to comment #0) > * Firefox crashing while the "having trouble restoring this session" tab is > open. (The "having trouble" tab comes back but the old pages don't.) This issue does not reproduce using Mozilla/5.0 (Windows NT 6.1; rv:2.0b9) Gecko/20100101 Firefox/4.0b9.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #3) > These are really two separate issues which should be tracked in separate > bugs. > > A bug for "Session not restored after software update". > A bug for "Session not restored after crashing on 'having trouble' page" > > I know the point of your bug is "don't save new tabs before restoring old > tabs" but this is as designed. When session store is enabled, all tabs are > saved -- that's the point. I believe both of these issues is gone. Can you still reproduce?
Resolved per whiteboard