Tab Session Manager causing Firefox to Relaunch immediately after launch.

[McBobb]

Short description

Whenever I open Firefox 80.0.1 over the past week or so, it opens as normal, with my saved tabs, but very quickly "relaunches"; the current session vanishing for a split second and window collapsing while at the same time, a new app window opens, again with the saved tabs. This is not a problem when I open Firefox from its shortcut, but when Firefox opens when I click an external link, like from an email or Discord, when the browser relaunches, the tab for the clicked link is not present. This happens every single time. Disabling Tab Session Manage completely fixes the issue, so the addon is at fault

Steps to reproduce

1. Start browser with clean profile
2. Install Tab Session Manager
3. Close browser
4. Click and external link/URL (like from an email or a Discord Channel)

Expected result

Firefox opens with saved tabs, plus a tab for the clicked link, and doesn't do an immediate relaunch

Actual result

Firefox opens with saved tabs, plus a tab for the clicked link, but within 1-2 seconds of firefox launching, it "Relaunches", and the new app window has all my saved tabs, but the tab for the clicked link is missing.

Platform information

• Platform (OS): Windows 10 Home
• Version of browser: 80.0.1
• Version of Tab Session Manager: 6.201

Additional context

[kenyoni]

Interestingly, I have -always- had this issue since I started using it in the early days of FF quantum and I finally got tired of it (yes, took a couple 3 years) and came here seeking a fix. The big irritation is the loosing of the tabs that @McBobb mentioned.

I believe the issue is replace vs append to window. Mine has always been stuck in "replace" and has recently flipped for you. I know at one point there was a config option but I spent a good 30+ minutes going through every config option for FF and TSM, crawled through the about:config and have come up with nothing. Hence coming here.

Platform Info

• Platform (OS): Linux 5.7.19-2-MANJARO
• Version of Browser: All since 57 (Quantum)
• Version of Tab Session Manager: All since Quantum

[skalfate]

I think I suffered from this issue for a bit until I realized, you cannot have both [firefox settings and tab session manger settings] set to "open previous session"/"restore previous session".

Only one can be active at a time.

However if there is a way to reduce the redundancy through code, it should be looked into.

[kenyoni]

This is not the case for me. I have, and always have had, "Open previous windows and tabs" unchecked in FF settings.

I just came back to this after uninstalling TSM for the past several months. The issue still exists. This evening I went so far as to turning off most everything in "about:config" related to sessionstore. Two things I have noted since doing this:

1. No matter what I do, I can't seem to prevent FF from creating the session backup files in sessionstore-backups/ and it always creates the sessionstore.jsonlz4 when exiting FF. But they are not the issue since deleting them before starting FF has no effect.
2. FF starts pretty slowly. This is actually a plus atm because I made a screen capture of FF starting up and it shows what's happening. The original FF window is clearly being closed and replaced by the TSM session.

For some reason, when I upload the mp4 to github, it gets corrupted. Here is a link to it on dropbox:

              https://www.dropbox.com/s/9aaloq2rqocv7gq/FF-start-demo.mp4?dl=0

If/when I figure out how to do a successful upload to github, I'll edit this comment. Until then, it will remain on DB at least until this issue is closed.

[tennox]

I suspected this might be because of the setting Behavior when starting the browser, but I could not reproduce:

https://user-images.githubusercontent.com/2084639/149260718-d4e44da7-00cd-4a2d-a757-163db32c081d.mp4

Either way, try setting the setting to Do Nothing as I suspect your issue is caused by this code (maybe IsStartup is not set back to false or somehow the opening of firefox for this link would call the startup listener... :thinking:

[AyoungDukie]

~~Just to add a new data point, this still seems to affect the Windows version of FF as of 106.0.1, with TSM 6.12.1.~~ Edit: after review, this does not seem like a platform bug, but the way the default behavior for openLastSession() is set up.

I did try adjusting the "Popup" setting for Open button behavior to Add to current window and set my Startup to Do nothing, and can manually create the behavior I'd want (adding a single window session to my opened window, and additional windows as needed). So openSession() function from open.js seems to work as intended.

Looking into the code highlighted by @tennox, openLastSession() seems to be the only function here that would close a current window. opensStartupSession() seems to simply call openSession to either open in the current or a new window.

Exploring openLastSession(), the culprit looks like a combination of how it calls openSession()

  await openSession(browserExitSessions[0], "openInNewWindow");

Which ignores the current window and simply opens the last session in a new window regardless, even for a single window session (which itself isn't necessarily a problem). However, the next block is a for loop that closes the current windows without any additional checks/info storing:

  for (const window of currentWindows) {
    await browser.windows.remove(window.id);
  }

I haven't dug into previous versions of this function, but currently it does seem like "expected" behavior as set up currently (if not the desired one from some of us in this thread). There also does not appear to be a way to alter this behavior with the current settings.

[AyoungDukie]

What would the next steps for discussing potential alternative behaviors? E.g. it shouldn't be too complex to implement a similar check to the opensStartupSessions version of that call:

  for (const i in startupSessions) {
    await openSession(startupSessions[i], i == 0 ? "openInCurrentWindow" : "openInNewWindow");
  }

And then disable the for-loop that closes the startup window, since that would follow the behavior of openStartupSessions(); I could put that in a pull request, but it seems like the project may want to discuss the desired behavior first. It may be preferred to have a setting about closing the first window being opened, and/or to follow the behavior of the setting for Open button behavior. And technically it would be good to match this with openStartupSessions() for consistency.