Open Bug 501995 Opened 15 years ago Updated 2 years ago

Not prompted for session restore after force-quitting due to lock-up

Categories

(Firefox :: Session Restore, defect)

x86
macOS
defect

Tracking

()

REOPENED

People

(Reporter: mozilla, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

I am what you might call a "power browser" of Firefox (or you might also call criminally insane): I tend to open new tabs for every link I click on, as well as new windows any time I shift "contexts". I'm on the computer about 20 hours a day, so this generally means I end up with > 20 windows and > 100 tabs per browsing session. This is a bad habit I've developed since Firefox started shipping with tabs. ;)

Ever since I started playing with the 3.5 releases (alpha, beta, RC) I can't actually quit Firefox (which is usually fine, since I don't have to very often). When I try to do so, I get the spinning pinwheel of death. SPOD means I need to bring up the Force Quit window and kill the Firefox process. Nothing too hairy there.

However, what invariably happens *every* time - I guess because things didn't have a chance to shut down properly - is Firefox will "helpfully" try and re-open all 100+ tabs/windows when I start it up again. This typically causes my Internet connection to become completely saturated, which results in *another* SPOD, and another force quit. The second time I try and restart Firefox, I get the "Well that was embarrassing" screen, where I can at last just select the "Start new session" option and get back to making more windows/tabs. ;)

On Twitter, people have pointed out that Firefox should always be prompting me for new or restored session. And I agree that it did do this in 3.0. But it does not appear to anymore in 3.5.

I imagine this is a duplicate bug report, since it's quite an irritating little problem, but I did try searching for "session restore prompt" as well as browsing the Session Restore component of the two listings on the "Add new bug report" page, and didn't see anything that sounded similar. But I apologize in advance if I'm wasting time - this is my first bug report to Mozilla.

Let me know if there's something I can download and run to send you guys data about my machine state or whatever might help track this down. It's my one and only complaint about 3.5 so far - Great job!! :)

Reproducible: Always

Steps to Reproduce:
1. Start browsing for awhile with lots and lots and lots of windows and lots and lots and lots of tabs. For example, the last time this happened I had 28 windows open, and > 100 tabs.
2. Try to quit Firefox. You'll get the spinning pinwheel of death.
3. Bring up the Force Quit window (ctrl+apple+esc) and force quit Firefox.
4. Start Firefox again. It will not prompt you to restore the session, but will instead proceed to start opening all 28 windows and < 100 tabs.
5. Usually this initiates another spinning pinwheel of death. Bring up the Force Quit window and force quit Firefox *again*.
6. See the "Well that's embarrassing" screen where you can now select "New session."
This sounds like a dupe of something, but I can't find it off-hand.

Question though... For your startup prefs, do you have Firefox set to restore windows & tabs from last session?
For now, just go to about:config and set the pref browser.sessionstore.max_resumed_crashes to 0. That will give you to the desired behavior.
Thanks, Simon! I've made that change and will let you know what happens next time.

Paul: Nope, it's set to show my home page. Good question, though.
In my opinion this is also a security issue, as possible dangerous sites, which you left by force-quitting firefox, will load again when restarting firefox.

example: (ATTACK Vector: JS)
(DANGEROUS - Disable JS before visit)
hxxp://twatter[dot]on[dot]nimp[dot]org/
(NSFW - Tubgirl - Goatse - Executes External Programs)
Closing this bug as INVALID, as the described behavior is by design. If you don't agree, please take the discussion to the mozilla.dev.apps.firefox newsgroup or to IRC and see if our UI guru Alex Faaborg wants to reconsider his decision from bug 448976 comment #10.

(In reply to comment #4)
Note that when you restart Firefox in Safe Mode, you'll always get the new Session Restore page if it's crashed just before. And this isn't a security issue, as the pages being reloaded have already been loaded once and they don't get any new possibilities by being reloaded.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Oh, and please file a new bug about the lock-ups, if you can reliably reproduce them, so that somebody can investigate their cause. Thanks.
Thanks, Simon.

Reading the discussion that led up to the change, I can understand the rationale, and agree that it probably makes the most sense for the majority of users. I will float a discussion on the newsgroup about adding some basic sanity-checking to this default behaviour; maybe if # of windows + # of tabs > 20 (some configurable value), prompt the user regardless of what the browser.sessionstore.max_resumed_crashes variable is set to.

I'll try to get to the bottom of the hangs, but interestingly, ever since I changed the setting recommended in #2, I haven't been able to trigger it again. So double-thanks. ;)
I think a summary of the discussion came down to agreement that the current settings and behavior is just fine for the case where there are few tabs or windows,  but it is not as precise as it needs to be for the case where many tabs and windows are open at the time of last crash.  Under those conditions start up after a crash or problem is quite jarring and the user is pretty much out of control.   Boriss suggested this affects "power users", but I'd suggest having a lot of tabs and windows open is a function of length of browsing session and not tied to any particular skill level.

Lets leave the current behavior as is, but just add a check that looks something like this

if  (more than ALOT_OF_TABS or ALOT_OF_WINDOWS were opened on last crash)
// restoration will be a circus
then
  show more session restore choices
endif

next is to figure out the definition of a lot of tabs and a lot of windows.

I'd suggest more than 5 tabs and more than 4 or 5 windows is a lot.  other suggestions.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Chris: Your comment #8 doesn't have that much to do with this bug as it was filed (which is about reverting .max_resumed_crashes to 0 and not just adding sanity checking to it). Instead of morphing this bug, please file a new one (and link to the discussion in question).

Reresolving this bug as INVALID.
Status: NEW → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → INVALID
re comment 9:

filed bug 507995
(In reply to comment #10)

Number 507995 is a writing mistake. Chris filed bug 507868 with parts of this bug on that day.


(In reply to comment #4)
> ... security issue ...

I see this too. Setting browser.sessionstore.max_resumed_crashes from default 1 to 0 calls the about:sessionrestore page after the first crash and doesn't waits for the second one.
hb, thanks for correcting to the right bug number.
(In reply to webchick from comment #0)

I am this kind of psychopath user too, albeit not reaching your level of insanity :-) .

The request bug 680605 may fulfill your wishes.

My tactic may help you :

Before restoring the crazy session, I unplug the network cable or I turn off AirPort. This is easy and radical. This avoids clogging the Internet connection and the memory and the processor and the speakers with all the music videos starting to play in symphony.
Sorry, I don't know the protocol on re-opening old issues, so I apologize if I'm in the wrong here. Just wanted to point out that this problem became a lot worse in Firefox 25-ish. :\

Here's a ~1 minute video outlying my experiences earlier today: https://dl.dropboxusercontent.com/u/10160/Oops-I-Broke-Firefox.mov

I still think comment #7 (or something like it) is the way to go. There are pretty much no circumstances under which what happens here is what you'd want.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.