Mozilla should have a "manager" that runs as a separate process to restore windows / tabs after a crash.



17 years ago
15 years ago


(Reporter: rhkramer, Assigned: asa)



Firefox Tracking Flags

(Not tracked)




17 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

The following is basically cut and pasted from on 26 Jan 2003.  More
background is available on that page:

    *  See previous item. Because Mozilla crashes, and when it crashes it closes
all open windows and tabs, there is a need for a Mozilla "manager" which runs as
a separate program and process which keeps track of windows and tabs open and
what they are open to, where the page is scrolled, where the cursor is
postioned, and, in the case of a text box and/or form, the text that has been
entered. In general, it should allow me to restart all previously opened windows
and tabs after a Mozilla crash to their previous state, with some manual
intervention to avoid reopening the window or tab that may have caused the
crash. When someone is ready to work on such a manager I will be happy to
provide some additional thoughts -- some quick ones:
          o Some monitoring tools, so that if total open windows or tabs or
memory used is an indicator of an iminent crash, the user can monitor and avoid
the problem. (Some crashes seem to be related to having a large number of
windows/tabs open, some others seem to be related to opening a specific page
with presumably some problem.)
          o An interface with a series of checkboxes for each previously open
window and tab with the idea that all windows and tabs with the checkbox checked
are restored by the press of a button
          o A means to store multiple "profiles" (really, past sessions), so
that if you crash with 150 windows open, crash again as you are restoring those
150 windows (but possibly have only opened say 5 of the old ones but also opened
5 new ones), you don't lose the information on the 150 older windows (nor the
information on the 10 (or 5) newer windows
          o If possible, some indication of what Mozilla was doing last (i.e.,
just before it crashed) -- which window / tab was it opening -- that may help
pinpoint a specific web page with content that causes a crash (and lead to
resolution of some specific Mozilla problem)

Reproducible: Always

Steps to Reproduce:
1.  I'm sorry, this seems beside the point.  Whenever Mozilla crashes, I
experience the problem of losing all my open windows and tabs which may include
work in progress.  Although I know of a few ways to crash Mozilla (opening
certain pages or opening too many windows / tabs), that is not the point of this
RFE.  (I hope I'm posting an RFE in the right place.)

Actual Results:  
After a Mozilla crash, all my windows and tabs are gone, including work in
progress on my wiki.

Expected Results:  
1. (This RFE) -- keep track of all open windows and tabs including the position
of the scroll and cursor, and contents of forms if a form.  After a crash, let
me call up the manager (if it is gone -- ideally it is not because it is a
separate process) and let me choose to restore all windows and tabs (or some
selection of them) to their previous state.  Provide monitoring tools to help me
avoid crashes.  Don't allow two crashes in a row to wipe out my "restore image"
(name the images or something along those lines).

2. (A different RFE) Allow me to easily create multiple instances of Mozilla so
that a crash in any one window does not wipe out all the other open Mozilla windows.

Just a side note -- when Mozilla crashes, I get no notice like Application
Violation in gkhtml.dll -- should I?

BTW: I guess this should be classified as an RFE, but I was tempted to label it
as "major" because it relates to crashes of Mozilla, which happen too often and
cause too much interruption to my work (because I may have 150 windows / tabs
open, and may have work in progress (TWiki editing) on more than one of those tabs.

Comment 1

17 years ago
PS: I did search for other reports like this before reporting it -- I searched a
lot of bugs containing "instan" or "manage".  (I thought I had reported this
myself some time ago, but, now that I think about it, I may have posted
something on which clearly was not the most
effective approach.)

Comment 2

17 years ago
Sounds like bloat horror. It would be much better if focus were on combing out
the crashers, instead of adding code to work around them.
This RFE is mostly covered in bug 19454 and bug 36810 however.

The reporter has filed a second bug that covers the "2." part under "Expected
results" here.
This is bug 19454 

*** This bug has been marked as a duplicate of 19454 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.