Opening a new window from a private window restores the previous session
Categories
(Firefox :: Session Restore, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | wontfix |
firefox138 | --- | wontfix |
firefox139 | --- | wontfix |
firefox140 | --- | fix-optional |
People
(Reporter: sajito+bugmozilla, Assigned: sfoster)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [fidefe-session-restore])
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
934.08 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0
Steps to reproduce:
- Disable "Open previous windows and tabs" in firefox settings and close all firefox windows
- Open a firefox window and navigate to any website
- Close the firefox window
- Open a new private firefox window, e. g. by using a shortcut or context menu on the desktop icon
- Open a new normal window from within the private window
Actual results:
The newly opened window will have a tab, with the website from step 1 and a new tab.
Expected results:
The newly opened window should only have a new tab, without restoring any other tabs.
Updated•19 days ago
|
Comment 1•9 days ago
|
||
Sam, could this be an issue on the session restore side?
Assignee | ||
Comment 2•8 days ago
|
||
This sounds like a regression from bug 1915738. I've not confirmed but that patch did change the logic for when we restore a session.
Updated•8 days ago
|
Assignee | ||
Comment 3•7 days ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #2)
This sounds like a regression from bug 1915738. I've not confirmed but that patch did change the logic for when we restore a session.
Ok I can confirm the STR, and also that reverting the part 1 patch from bug 1915738 fixes the issue.
Updated•7 days ago
|
Assignee | ||
Comment 4•7 days ago
|
||
The taskbar tabs work is still underway in 140 and still behind a pref. The changes in question here were to Session Restore logic that was going to be hard to guard behind the pref, but I guess we missed this case in code review.
I can work on a fix for nightly/140, but nrishel and I agree that the safest/simplest solution for 139 is to back out the 2 patches from bug 1915738 if possible.
Updated•7 days ago
|
Assignee | ||
Updated•7 days ago
|
Assignee | ||
Comment 5•7 days ago
|
||
Revert "Bug 1915738 - Part 2: add testing for restore behaviour with taskbar tabs r=sfoster,sessionstore-reviewers"
This reverts commit becacdbeea9b534ed908a359551f4bbbb66b33b1.
Revert "Bug 1915738 - Part 1: end session when all non-taskbartab Firefox windows are closed and prepare for restore r=sfoster,sessionstore-reviewers"
This reverts commit 81fd252f848792a59b68c079b41b0bb6a4b8ccb8.
Updated•7 days ago
|
Updated•7 days ago
|
Updated•7 days ago
|
Comment 6•7 days ago
|
||
The bug is marked as tracked for firefox139 (beta) and tracked for firefox140 (nightly). However, the bug still has low severity.
:pluk, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 7•6 days ago
|
||
(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #6)
The bug is marked as tracked for firefox139 (beta) and tracked for firefox140 (nightly). However, the bug still has low severity.
I think S3 is about right for this bug. Restoring a window's tabs etc. is unexpected but there's no data-loss and the steps to get into this situation are quite specific. Maybe S2.5 if we had such a thing.
Assignee | ||
Comment 8•6 days ago
|
||
:dmeehan, the beta backout patch here has r+ and I think we're just waiting on the ability to get try results for it before landing. I'll leave a need-info here as a reminder but let me know if there's anything I can do.
I'll also mark as leave-open as I'm working on a patch I'll attach here to fix the issue in nightly/m-c (140).
Updated•6 days ago
|
Updated•6 days ago
|
Comment 9•6 days ago
|
||
This is in our uplift request queue so clearing my NI
Updated•2 days ago
|
Updated•2 days ago
|
Comment 10•2 days ago
|
||
uplift |
Updated•2 days ago
|
Assignee | ||
Updated•2 days ago
|
Assignee | ||
Comment 11•1 day ago
|
||
I've spent some time with mozregression and found I can reproduce this bug back to 2023-07-18. I have a profile with a saved session with some tabs in it. When I launch the build from 2023-07-17 with a --private-window
and then open a regular window, nothing gets restored and the previous session is there under History. This is the expected result. Doing the exact same with the build from 2023-07-18 results in the previous session getting automatically restored when the regular window is opened.
When and if session restore happens is determined in SessionStartup.sys.mjs and SessionStore.sys.mjs. Looking at that pushlog, there are 2 patches that change SessionRestore.sys.mjs: Bug 1843587 and Bug 1820660. But looking carefully at those patches, I don't see it; they just don't seem to touch this logic at all?
So, what about bug 1915738? I'm not sure. I confirmed with beta builds that this bug reproduced with those patches and didn't reproduce without. As the taskbar-tabs feature is behind a pref it seemed prudent to back them out now and not block on the full diagnosis. The root cause goes back much further though it seems.
Updated•21 hours ago
|
Updated•20 hours ago
|
Comment 12•19 hours ago
•
|
||
Hey Sam. I was able to reproduce this issue on Firefox 139.0a1 on Ubuntu 24.04. While trying to verify that it doesn't reproduce anymore on Beta 139 after the backout, it seems that this is still reproducible on Firefox 139.0b8 and b9 (treeherder build). I'll attach a screenshot with it. Any idea?
Comment 13•18 hours ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #11)
I've spent some time with mozregression and found I can reproduce this bug back to 2023-07-18. I have a profile with a saved session with some tabs in it. When I launch the build from 2023-07-17 with a
--private-window
and then open a regular window, nothing gets restored and the previous session is there under History. This is the expected result. Doing the exact same with the build from 2023-07-18 results in the previous session getting automatically restored when the regular window is opened.When and if session restore happens is determined in SessionStartup.sys.mjs and SessionStore.sys.mjs. Looking at that pushlog, there are 2 patches that change SessionRestore.sys.mjs: Bug 1843587 and Bug 1820660. But looking carefully at those patches, I don't see it; they just don't seem to touch this logic at all?
So, what about bug 1915738? I'm not sure. I confirmed with beta builds that this bug reproduced with those patches and didn't reproduce without. As the taskbar-tabs feature is behind a pref it seemed prudent to back them out now and not block on the full diagnosis. The root cause goes back much further though it seems.
I think this is an old issue - see bug 1896244 which also has bug 1820660 as the regressor.
Assignee | ||
Comment 14•11 hours ago
|
||
I think this is an old issue - see bug 1896244 which also has bug 1820660 as the regressor.
Yeah it looks like a dupe. I'm sorry I didn't spot that earlier.
(In reply to Catalin Sasca, Desktop Test Engineering [:csasca] from comment #12)
Created attachment 9487930 [details]
Screenshot 2025-05-15 at 12.33.24.pngHey Sam. I was able to reproduce this issue on Firefox 139.0a1 on Ubuntu 24.04. While trying to verify that it doesn't reproduce anymore on Beta 139 after the backout, it seems that this is still reproducible on Firefox 139.0b8 and b9 (treeherder build). I'll attach a screenshot with it. Any idea?
Let me check how I was verifying this. The taskbar tabs feature is not enabled in 139 so I don't think it hurts to have backed those patches out, but based on the findings in comment 11 and comment 13 it seems that the patches we backed out aren't going to fix this issue and its a much older regression.
Assignee | ||
Comment 15•5 hours ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #14)
Let me check how I was verifying this.
Yeah I can confirm the bug still reproduces with the firefox-139.0b8 build. It was a little tricky to get repeatable steps for this initially, as session restore updates the saved session whenever you use a given profile - and the bug won't reproduce unless there's a saved session with tabs to restore. I can only guess that something like that happened when I was first looking for this regression. My apologies for the churn.
Given this has been an issue since bug 1820660 landed in 117, I'm not sure how to update the tracking flags? ESR 128 should be affected, (115 not).
Updated•2 hours ago
|
Description
•