1956254 - Restoring a Session will show Tab groups twice in the List all tabs menu

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect, P1)

Description

[Rares Doghi, Desktop QA]

Found in

• Nightly 138.0a1 (2023-08-25)

Affected versions

• Nightly 139.0a1 (2025-04-17)
• Nightly 138.0a1 (2023-08-25)
• Beta 137.0b11

Affected platforms

• All

Steps to reproduce

1. Create a few Tab groups and close Firefox.
2. Start Firefox in offline mode or normal mode.
3. Restore the previous session.
4. Open the list all tabs menu.

Expected result

• There should only be 1 of each created Tab groups.

Actual result

• Each tab group is duplicated after restoring the previous session in Offline or normal Browsing mode.

Regression range
I will update with a regression range as soon as possible.

Comment 1

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

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Rares Doghi, Desktop QA]

I think I found a regression range for this issue but im not entirely sure its correct since the GUI stopped:

13:26.69 INFO: Last good revision: ba305ce7ad141ea641cf08868285b4372403e0b0
13:26.69 INFO: First bad revision: 4374d7fb7f40240e75f41519202eaf8127f323cc
13:26.69 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ba305ce7ad141ea641cf08868285b4372403e0b0&tochange=4374d7fb7f40240e75f41519202eaf8127f323cc

It says its Bug 1951750 that might have caused this but I'm not sure.

Comment 3

[Dão Gottwald [:dao]]

(In reply to Rares Doghi, Desktop QA from comment #2)

I think I found a regression range for this issue but im not entirely sure its correct since the GUI stopped:

13:26.69 INFO: Last good revision: ba305ce7ad141ea641cf08868285b4372403e0b0
13:26.69 INFO: First bad revision: 4374d7fb7f40240e75f41519202eaf8127f323cc
13:26.69 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ba305ce7ad141ea641cf08868285b4372403e0b0&tochange=4374d7fb7f40240e75f41519202eaf8127f323cc

It says its Bug 1951750 that might have caused this but I'm not sure.

I think this is likely not the correct range. I can't access the bug, but judging by the changesets it seems like it should be unrelated :/

Comment 4

[Stephen Thompson [:sthompson]]

I haven't been able to reproduce this in Nightly 139.0a1 (2025-04-17) (aarch64) on macOS

1. Create tabs and 2 tab groups, close Firefox with Cmd + Q
2. Start Firefox (and select File > Work Offline to test offline mode)
3. Restore the previous session using Cmd + Shift + T
4. Open the List All Tabs menu by clicking on the downward arrow button

Result:

• the 2 tab groups are listed at the top of the List All Tabs menu with the heading "Recent Tab Groups." This is expected behavior.
• the menu version of the tab strip with the heading "Current Window" lists all tabs and tab groups in the correct order with no duplicates

I've tried a number of variations

• before restoring the session, open and then close the list all tabs menu
• before restoring the session, open the list all tabs menu and leave it open

Comment 5

[Stephen Thompson [:sthompson]]

Attachment: List all tabs menu displaying correctly (bug not visible)

Comment 6

[Rares Doghi, Desktop QA]

Attachment: duplicated.mp4

Adding a Screen recording of this issue. It still occurs in our latest Nightly 139.0a1 (2025-04-21)

Comment 7

[Rares Doghi, Desktop QA]

Attachment: dupe2.mp4

Hi @Stephen can you take a look at this screen recording ? it seems that if we simply reopen those Saved groups they will all be displayed twice in the list all tabs menu, could this be caused by the same issue ? or is this related more to Bug 1961159

Comment 8

[Stephen Thompson [:sthompson]]

This is great, thank you! I think bug 1961159 may be causing the problems at the very end of dupe2.mp4, but I think the other issues might be caused by something else. I will try the repro steps on Windows to see if that helps me.

Comment 9

[Stephen Thompson [:sthompson]]

I can reproduce this on Windows 11. I can't reproduce it on macOS.

What's supposed to happen:

• closing the window puts the tab groups on the tab strip into the list of saved tab groups
• opening a window shows the saved tab groups in the list all tabs menu
• restoring the session puts the saved tab groups into the tab strip and removes them from the session's list of saved tab groups

That's happening on macOS, but in Windows, restoring the session puts the saved tab groups into the tab strip but keeps the saved tab groups in the session. Since the list all tabs menu is supposed to list both saved tab groups and open tab groups, this appears as duplicate tab groups. A tab group should only be in one place at a time: 1) tab strip, 2) saved groups, 3) closed groups.

I will investigate on Windows

Comment 10

[Stephen Thompson [:sthompson]]

Attachment: Bug 1956254 - fix saved tab group behavior on session restore r=dao,dwalker

Current behavior on Windows: if you close a window that has open tab groups, the tab groups are automatically saved. Opening Firefox into the initial deferred restore state properly shows the tab groups as saved. However, after restoring the previous session manually, the tab groups exist both in the tab strip (correct) and in the list of saved tab groups (incorrect).

Bug 1950611 and bug 1954488 dealt with several edge cases around saved groups + session restore. In Windows, it looks like on session startup, _prepDataForDeferredRestore receives a state where the open tab groups from last session are stored in both savedGroups and windows[].groups[]. _prepDataForDeferredRestore has logic to convert the open tab groups in windows[].groups[] into saved groups, but it'll skip any that are already present in the list of saved groups. This was fine until the fix for bug 1954488, which unsets removeAfterRestore from the saved group; the windows[].groups[] groups get the removeAfterRestore flag set, but that does not get put into savedGroups because the group already exists in savedGroups.

I amended the logic so that when a group is in windows[].groups[] and savedGroups, the tab group state from savedGroups will get removeAfterRestore set back to true.

Not totally sure why I could reproduce this on Windows but not on macOS. It looks like the saved groups in defaultState.savedGroups still have removeAfterRestore: true set even after the delete group.removeAfterRestore. I don't understand how that would happen.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b0a25baf9a34
fix saved tab group behavior on session restore r=dwalker,sessionstore-reviewers

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/b0a25baf9a34

Comment 13

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

The patch landed in nightly and beta is affected.
:sthompson, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox138 to wontfix.

For more information, please visit BugBot documentation.

Comment 14

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Nightly 139.0a1 (2025-04-24)

Comment 15

[Rares Doghi, Desktop QA]

Updating the main status flag.