1445547 - One or more windows not restored when restoring previous session

Status: ASSIGNED

(Firefox :: Session Restore, defect, P3)

Description

[Reed C Bowman]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180310025718

Steps to reproduce:

Starting with multiple FF windows open with multiple tabs in most windows, exit FF either by right-clicking the taskbar icon and selecting Close all windows, or by shutting down the computer. (Or via a computer crash.) Then restart FF normally and use Restore Previous Session. Most of the time, one or more of the open windows will not be restored. In previous versions, this happened whether I used the menu to get to Restore Previous Session or used the button on the FF start screen. 


Actual results:

For several years, through many, many updates of ff, when starting Firefox and using "Restore Previous Session", MOST of the time if there were 3 or more windows active in the previous session, one or more will not be restored. (I am not sure if this occurs as well with only 2 windows open.) It is unclear which ones it chooses to restore and which to delete. Sometimes one window is missing out of several, sometimes more than one (4 out of 7 missing the most recent time). Often - though not always - it will have lost the window that includes tabs I have Pinned. This occurs more often than not; I would guess at least 75% of the time. If, after restarting and using Restore, I find windows missing, they will NOT appear in the Recently Closed Windows list (it will be empty), but the History list WILL include all the recent locations, including those in the many, many tabs that have been deleted.


Expected results:

All windows should have been restored with all tabs. This does happen some of the time, but I have come to expect it to fail most of the time.

Comment 1

[Cosmin Muntean [:cmuntean], Ecosystem QA]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Firefox: 59.0.1, Build ID: 20180315233128

I have tested this issue and I have managed to reproduce it, but I am not sure if is the same with the described issue.
Here are the STR my behavior:
1. Open 4 new windows with multiple tabs.
2. Right click on the Firefox icon from the Windows Start bar.
3. Click the "Close All Windows" option.
4. Click the "Close tab" option for each window opened.
5. Reopen Firefox browser and from browser options choose the "Restore previous session" option.
6. Observe the behavior.

[Expected results]:
- All the 4 windows are restored.

[Actual results]:  
- In most of the cases the first opened window is not restored.

[Notes]:
- Probability the issue is reproducible depending on the order of the closed windows.
- Here is a screen recording of the described behavior: https://goo.gl/FLPBpG

@Reed C Bowman can you please confirm if this is the same issue that you encounter?

However, I am assigning a component to this issue in order to involve the development team and get an opinion on this.

Comment 2

[Reed C Bowman]

@Cosmin Muntean Thanks for looking into this. It sounds like you have reproduced the bug. Your screen recording is not working, though. Google says it has been removed.

I do not have the "close all tabs?" dialog enabled anymore, but otherwise this sounds the same.

I failed to note in my original report that I do not have it set to restore the previous session on startup in the settings. This is on choosing Restore Previous Session from the menu after opening. Same behavior existed in previous versions when the default start page included a Restore Previous Session button.

Since my computer is often on with multiple sleeps over multiple days, I don't know for certain if it tends to fail to open the first window(s) preferentially, but it would not surprise me, since as I said, it often closes the main one with pinned tabs. On occasions when I am closing and restarting FF multiple times in a short period, each relaunch happens fast enough that I'm not sure which window opens first for reference when shutting it down again. I will try to pay attention to this and see if I can confirm.

It is certain, though, that it sometimes fails to open more than one window, and not just the first one. I do not know if it is failing to reopen the first several windows open in the previous session, or those who have been the longest without focus, or if there is some other subtler behavior going on.

Comment 3

[Reed C Bowman]

A new datum regarding this. A worse version of the failure in a specific circumstance. I used "close all windows" from the taskbar ff icon, ahead of restarting the computer. In this case, one of my windows had an unfinished comment in it on social media, which popped up a warning that there was unsaved stuff on that page. I told it to close anyway. 

When I restarted the computer, and started firefox, only that *one* window (out of six or seven) came up. The History menu had only two more of the windows that had been there listed.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 5

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 6

[Andrew Overholt [:overholt]]

I'm experiencing something similar to this on Fedora which might be a difference between Ctrl-q and GNOME's activity panel thing.

STR

1. have 3 windows open with multiple tabs in each
2. quit Firefox via GNOME's [Firefox] menu thing -> Quit.

Expected

• all 3 windows are restored

Actual

• only 1 of the windows is restored (it seems kind of random which one gets restored)

Interestingly, using Firefox's File -> Quit or Ctrl-q, I get the confirmation "close all 3 windows?" and upon restarting Firefox, they're all back. I'll keep investigating.

Comment 7

[Andrew Overholt [:overholt]]

1. Sam asked me to reset the severity here
2. I wonder if my issue is Linux/GNOME-specific and is related to bug 1858782 ...

Comment 8

[Andrew Overholt [:overholt]]

Martin, are you aware of the differences between Ctrl-q and the GNOME application menu's Quit entry when it comes to closing windows and potentially impacting session restore?

Comment 9

[Martin Stránský [:stransky] (ni? me)]

My understanding is that on system initiated quit nsWindow::OnDeleteEvent() is called from delete window callback:

https://searchfox.org/mozilla-central/rev/2c3d657cbba5484ccac44443c4417baed7b5fafb/widget/gtk/nsWindow.cpp#4234

But I haven't investigated it much yet.

Comment 10

[Sam Foster [:sfoster] (he/him)]

I was able to reproduce what I think is the issue here. Both the GNOME application menu and Window taskbar menu have a "Close {n} windows" option - which results in Firefox quitting. But these don't do quite the same thing as ctrl+q (ctrl+shift+q on windows). I added a little logging to SessionStore.sys.mjs and got the following, using the application menu:

console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore: Calling maybeSaveClosedWindow, isLastWindow?" false
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore: Calling maybeSaveClosedWindow, isLastWindow?" false
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore: Calling maybeSaveClosedWindow, isLastWindow?" false
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore: Calling maybeSaveClosedWindow, isLastWindow?" false
console.log: "SessionStore, handling quit-application-granted"
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore, handling quit-application"

And when I started the browser back up again, only 3 of my 4 windows got restored. (3 is the default value of the browser.sessionstore.max_windows_undo pref).

Using ctrl+Q I get:

console.log: "SessionStore, handling quit-application-granted"
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore, handling domwindowclosed"
console.log: "SessionStore, handling quit-application"

And at the next startup, all 4 windows were restored.

I also noticed the isLastWindow variable I logged out there never goes to true. I'm not sure if that is a smoking gun, but its certainly very fishy.
There's confirmed risk of data loss, STR and what seems to be a lead here so I'm updating priority and severity.

Comment 11

[Sam Foster [:sfoster] (he/him)]

I thought I had good STR here, but some time in mozregression came up empty: I'm not able to reproduce with those builds. Only the local build from moz-central. Same profile, same sessionstore.jsonlz4 being loaded and saved to on exit. With my local build, exiting via the application menu only saves 3 of the 4 windows. Using e.g. mach mozregression --launch 2024-02-01 and pointing at the same profile directory, 4 windows are opened, 4 windows are saved.

Comment 12

[Sarah Clements [:sclements]]

Sam, if this doesn't have reliable STR is this still a P1 or being worked on?

Comment 13

[Sam Foster [:sfoster] (he/him)]

(In reply to Sam Foster [:sfoster] (he/him) from comment #11)

I thought I had good STR here, but some time in mozregression came up empty: I'm not able to reproduce with those builds. Only the local build from moz-central.

A thought: my local builds are debug builds, I suspect that is the difference here, which could mean I was running into a different issue.

(In reply to Sarah Clements [:sclements] from comment #12)

Sam, if this doesn't have reliable STR is this still a P1 or being worked on?

Yeah we should downgrade the priority - regrettably its not actionable right now. This is another case where I hope the logging added in bug 1854373 might throw up some new insights.

If anyone can reproduce this on versions 127+, please comment here with any recent log files from your {profile}/sessionstore-logs directory. Those logs files should be clear of any personal info, but feel free to email me directly if you prefer.