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 http://twiki.org/cgi-bin/view/Wikilearn/MozillaManager 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.) 2. 3. 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.
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 email@example.com which clearly was not the most effective approach.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.