Open Bug 1538119 Opened 5 years ago Updated 5 months ago

Duplicate sessionId in browser.sessions.getRecentlyClosed() after "Restore previous session"


(WebExtensions :: General, defect, P3)

66 Branch


(Not tracked)


(Reporter: qw2g64, Unassigned)


(Blocks 1 open bug)



(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

  1. Enable "Restore previous session" in preferences.
  2. Open several tabs, and close them.
  3. Exit and restart Firefox.
  4. Open several tabs, and close them.
  5. Debug an extensin with sessions permission and run:


Actual results:

The returned objects have duplicate sessionId, e.g. multiple tabs with sessionId: "0".

This makes browser.sessions.restore unreliable; restoring a tab may bring up a window or another unrelated tab instead.

Expected results:

Each returned object has unique sessionId.

Possible reason: when "Restore previous session" is invoked, the closed tabs and windows from the last session are brought back with the sessionId unchanged. However, the counter


is not adjusted accordingly. Since new closed tabs get auto-incremented sessionId from _nextClosedId, they can be duplicate with the restored ones.

This gets more complicated with the ☰ → "Restore previous session" button. If the user open and close some tabs and then click this button, it is possible for the restored tab to have duplicate sessionId with (and override) the existing ones.

I'm not sure what is the best way to fix it; maybe it is possible to adjust _nextClosedId so it is still larger after "Restore previous session", or prefix the sessionId to differentiate the current session and all the restored sessions.

Priority: -- → P2
Has STR: --- → yes

I tried to use with latest FF66, but I was not able to reproduce the issue. Can you please attach the extension you used when reproducing this?

Flags: needinfo?(qw2g64)

I can see the bug with the session-state extension. Please see the screenshot, starting from a fresh profile on Firefox 66.

Flags: needinfo?(qw2g64)

After following the steps from video I can confirm that the issue is reproducible.

Thank you.

Ever confirmed: true

I confirm the problem. And I was thinking why, in my extension, sometimes browser.sessions.restore restores a completely wrong tab.

"lastModified": 1567290681379,
"tab": {
"sessionId": "176",
"index": 14,
"windowId": 26,
"highlighted": false,
"active": false,
"pinned": false,
"hidden": false,
"incognito": false,
"lastAccessed": 1567290681360,
"url": "",
"title": "1407486 - нет способа настроить Firefox для автоматического восстановления сеансов",
"favIconUrl": ""

"lastModified": 1567238855459,
"tab": {
"sessionId": "176",
"index": 98,
"windowId": 14,
"highlighted": false,
"active": false,
"pinned": false,
"hidden": false,
"incognito": false,
"lastAccessed": 1567238855412,
"url": ",searchweb201602_6,searchweb201603_55",
"title": "50 pcs Pairs Soft Clear Silicone Replacement Eartips Earbuds Cushions Ear pads Covers For Earphone Headphone-in Earphone Accessories from Consumer Electronics on | Alibaba Group",
"favIconUrl": ""

Version: Firefox 66 → 66 Branch

This is still an issue with FF 72.0.1
It happens several times a day, actually every few times I want to restore a previously closed tab.

In my humble opinion, this should be on your top priority to-do list, right after any security-related issues.
"You" being those who are responsible the most for tinkering with this whole tabs/windows/sessions system.

Assign unique IDs, make it work forward and backward and sideways as flexibly as possible,
Save them in an indexed list to speed up operations,
Test! QA! Comment! Add markers so you'll be notified of any future changes or discrepancies in your code!
check and recheck and then test some more,
then pass down your work to all qualified branches..

Sorry for (maybe?) seeming a bit toxic here, but this kind of issue is purely related to two aspects: consistency and QA

The tab data is saved to "closedTabs":
And the window data is saved to "_closedWindows"

I wonder where they get restored if the browser restarts. Does this happen inside "SessionStore.jsm"? And if so: Where?

Finding the maximum in this list and presetting _nextClosedId to the maximum value + 1 would be an easy fix if I knew where the stored session data gets placed into these arrays.

I completely forgot that it is (was?) possible to restore a previous session into the current one. This is currently just done with "concat":

Is there still an UI for restoring a session into the current one?

Would it be possible to renumber all the restored tabs and windows session ID or are there any cross-references that could get lost in this case? I guess I could just try that and replace the "concat" here with a proper loop which creates a new ID for every single restored entry based on incrementing _nextCloseId.

Hi Mike,
would you mind to take a look to this?
based on the comments it looks like there could be an issue on the sessionstore side (and not in the extension API layer).

Flags: needinfo?(mdeboer)
Blocks: 1476144

Marco, does comment 9 ring any bell? This looks like a bug in session store causing a duplicate id.

Severity: normal → S4
Flags: needinfo?(mak)
Priority: P2 → P3

Based on the description in comment 0, it seems to be an architectural bug in how sessionId is generated, for which I think it would be a good idea to file a bug in the SR component that blocks this bug. We need a new owner for SR, but I still don't know who may be, I'd suggest to directly ping mdb on Slack to move this on.
I can't easily answer the question, because I'm not even sure why sessionId was defined as a number, and not a uuid or a guid, that would have a much smaller chance of being a dupe in case of code mistakes. Probably the fix here is about changing the sessionId on restore and not trust the old one, or immediately increase _nextClosedId, unless the architecture can be easily changed to use a likely-unique identifier.

PS: while searching the source I found a typo (sesionId) here not sure if/how this has consequences.

Flags: needinfo?(mak)

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(mdeboer)

Is it possible that the issue here has been resolved "by accident" while bug 1789652 and bug 1845836 were fixed?

I tried with a modified version of my "Undo Close Tab" Add-on with some "console.log" entries patched in.

I did several restarts and compared the session IDs. I was no longer able to make Firefox report duplicated IDs.

You need to log in before you can comment on or make changes to this bug.