Closed Bug 524366 Opened 15 years ago Closed 15 years ago

Tab memory overwritten by other windows - should be amalgamated

Categories

(Firefox :: Session Restore, defect)

defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: mike-yates, Unassigned)

Details

(Whiteboard: [DUPEME])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

This might be a duplicate of othe "Lost Tabs" bugs, but here I have a specific cause.
Quite simply, I have found that if you are using multiple tags, open a fresh window (with a single or new tabs) close the first window first (or it happens to get shut first on system shutdown) the only tabs which can be recovered are in the second window.
There are many scenarios, seen in the othe bug reports, where this can occur accidentally.

Reproducible: Always

Steps to Reproduce:
1. Create several tabs.
2. Open a new window (single tab appears)
3. Close the first window
4. Close the second window
5. Start Firefox again.
Actual Results:  
Only the tabs (if any) in the second window are remembered.

Expected Results:  
At least "Recently Closed Tabs" in history should show the tabs from any previous window, if not all the tabs be reproduced in the new instance.
This is AFAIK working as designed.
The session restore only remembers only the windows and tabs that are active while Firefox is closed and that is in your example only the last window.

If you have 2 windows open and want to remember all windows you have to use file/exit
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
This cannot be a duplicate of an INVALID bug - it is still a problem!
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
How can that design be correct?
Often a second window is a popup, followed by a system shutdown, so the user does not know how he has "Lost his tabs".
Surely tab memory should be amalgamated between windows?
It is being overwritten, which is NOT preservation.
If he's "lucky" the second window will shut first.
That is why this bug is "intermittent".
Suggested solution:
Keep "Recently closed tabs" from this session only.
Keep the last 10 (configurable default) "Recently closed windows" from all sessions (however closed) and reproduce all their tabs if restored.

At present, only this session's windows are available to restore.
If you look at the steps to reproduce you should notice that both bugs contain the same steps to reproduce and that means that they are dupes of each other.
bug 506058 is older and that means that this bug is a dupe of bug 506058.

Only the last state before you closed Firefox will be stored, if you close the windows one by one, only the last window will be restored on startup, if you close several windows with file/exit then all windows will be restored.
If you closed the windows one by one and you will get one window at startup but you can restore the other windows from the history menu.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → DUPLICATE
(In reply to comment #6)
> *** This bug has been marked as a duplicate of bug 506058 ***

The 2 bugs have a lot in common, though the problem being reported is fundamentally different. This bug is (basically) saying that closed tabs should not be window specific. Bug 506058 is about losing windows when closing X windows in a row to quit.

Mike, your solution from comment #5 is actually implemented. Default number of windows is 3. "Recently closed windows" is right by "recently closed tabs" in the "history" menu. If you remember windows & tabs across sessions, your closed tabs are remembered as well.

Recently closed tabs are specific to the window they are closed from. This isn't something that will change for 3.6, but as I'm about to mention, could be made into a enhancement request.

All that said, this is likely a dupe of another bug. I'm going to close it INVALID for now. If you would like to turn this into a real enhancement request please file a new bug in the session restore component with an appropriate title.
Component: General → Session Restore
QA Contact: general → session.restore
Resolution: DUPLICATE → INVALID
Whiteboard: [DUPEME]
You need to log in before you can comment on or make changes to this bug.