Feature/keep track of active session

[DiegoBM]

Implements:

1. Ability to keep track or remember the currently active session, which as a concept, it would be something similar to "the session that the user is currently working with", making sure that such session is always automatically updated instead of the user needing to manually apply the changes to that particular session.

   • In order to set a session as active, the user needs to either open an existing session, or create a new named session by using the "Save" button in the save area.
   • The user can visually see which session is currently active both in the Header and in the Sessions List.
     
   • If the auto-save options are enabled, when they trigger, they'll save the changes to the currently active session, as well as the auto-generated sessions.
   • If the user deletes the currently active session, then no session will be currently active.
   • This functionality can be disabled with a setting in the options screen (it is disabled by default)
     

2. Delayed evaluation of the "shouldShow" setting property, that now supports function calls (which will receive all the current Settings values as a function argument), and allows to compute settings' visibility based on other settings values.

3. Reactive rendering of the Settings form, which now will re-render when settings change, allowing to show/hide options dynamically using "shouldShow".

4. Added new setting that allows to auto-save the active session before switching to a different session. This new setting is only visible if the "Keep track of the active session" setting is enabled. (Note: saving might happen together with other enabled autosave options, for example, apparently when we open on current window "autoSaveWhenOpenInCurrentWindow", if the autosave when window close setting is enabled, it will also save the session).
   

5. Expanded "NameContainer" component to support two new props "forceTruncate" which truncates regardless of the truncateTitle setting, and "canRename" which dictates if the component will be able to be used to rename a session or not

6. Makes sourcemaps inline so that they can be used during development (they were not working, at least in Windows)

Resolves #890

[sienori]

Fantastic! I'll try the build (By the end of next week).

[DiegoBM]

Thank you! Let me know how it goes. It's doing great for me so far :)

[tennox]

@DiegoBM I built it locally and so far, seems working well 👍 😎

One question: does it also auto-save to active session when closing the window / browser?
Because that would mean I could set active session a la "fire and forget" - i.e. be sure it will have my latest state saved.

[DiegoBM]

Thanks!

It should save under the same circumstances and events than the original script was saving

[tennox]

I think I just noticed a problem:
I configured my browser to open empty on startup, but the plugin with your changes would keep the active session setting, so an auto-save would overwrite the prevously saved state with the empty window (or some new tabs I opened in the meantime).

I think a browser restart should reset the active session value.

[DiegoBM]

The behaviour you describe is definitely intended, it should always keep track of the current status of the browser and the active extension should always be active. In my opinion I reckon this functionality only makes sense when you have your browser configured as "continue where you left off", since otherwise it will kill the continuity of the automatic session tracking experience, if you need to re-enable your session every time that you open the browser.

In any case I understand how this may affect any user that has other startup tabs setting configured, so I have included one new setting "Clear active session on Browser close" which I reckon will do what you are asking for. The setting is disabled by default so you'll need to enable it if you want to use it. Using the new settings system, the new setting will only appear if you have "Keep track of the active session" enabled. I hope it will suit your needs.

[tennox]

Funny I was just coding on this too 🙈

I thought to add setActiveSession(null) on startup if the extension is configured to not load last session:

Tab-Session-Manager/src/background/background.js

Line 86 in 7d25609

else if (startupBehavior === "startupSession") openStartupSessions();

else setActiveSession(null)

But you point out another edge case when user configures browser to open last tabs and then doesn't set the setting in this addon.
There might be a way to detect this browser preference, but I didn't find it.

[DiegoBM]

Not sure to follow the other edge case that you mention. You mean the new setting?

[tennox]

I mean there's two ways to open last session:

1. firefox/chrome option reopen last session on startup
2. this addon's Behavior when starting the browser = Open previous session

Which is kind of messy already... But considering this I think it's better to use a setting like you implemented now as I think it would be complicated to cover all the edge cases correctly :/

[DiegoBM]

Yeah, it's an "interesting" feature, but to be honest I've never used it. In any case I reckon that the default setting is "Do Nothing", so the user needs to actively configure it to open a session that way. I reckon that, at that point where the user starts messing with the settings, is the users' responsibility to configure the other settings accordingly. I reckon that the new setting properly describes the functionality and even the possible issue, in any case if it might not be clear I'm happy to change it.

[tennox]

I think you misunderstand me - I totally agree with your way of doing it, given the situation. Just tried to elaborate the thoughts behind my attempt.

In the meantime, here is another PR in which I added a button to unset the active tab tracking (when messing around or switching between sessions, or building a new from parts of another one - I don't want anything to be overwritten):
DiegoBM#1

I'm also looking to improve / streamline the UX a bit more - when to save, when to load - to be able to somehow switch between sessions smoothly... withough needing to think about it too much or loosing changes.
but two concepts I am struggling to differentiate:

Session and Window. 🪟
I've seen both ways:

• have multiple windows open for different projects / sessions
• have one session / project span multiple windows

Personally, I prefer the idea of having one session per window. This also aligns with the UX concept of 'open session in new window' which would set active session to that one - but auto-save would then add other windows tabs, too.

I think with the ability to auto-save towards an 'active session' the UX should to be clear around those concepts...

@sienori maybe have you thought about this differentiation and have your own idea on how to tackle this?
Or you, @DiegoBM ?

Otherwise, I'd suggest to limit auto-saving triggered by active session to one window, but... What about multi-window sessions... maybe it can track only opened windows somehow... I don't see an easy way.

Anyways, I think this addon has the potential to replace Workona/Toby/Qlearly for me and some others - and having an open-source version is always much more delightful 😎 🤓
(aaaand a lot of work... but also, cheaper 😋)

[tennox]

I'm getting close to a version where the basics work well:
DiegoBM#1

Demonstration of working saving on close & switching:

(I have the addon set as homepage, which will has to reload after the extension is initialised)

[DiegoBM]

I think you misunderstand me - I totally agree with your way of doing it, given the situation. Just tried to elaborate the thoughts behind my attempt.

I was actually agreeing with you in my previous response. We must have been lost in translation :)

I'm also looking to improve / streamline the UX a bit more - when to save, when to load - to be able to somehow switch between sessions smoothly... withough needing to think about it too much or loosing changes. but two concepts I am struggling to differentiate:

Session and Window. 🪟 I've seen both ways:

• have multiple windows open for different projects / sessions
• have one session / project span multiple windows

Personally, I prefer the idea of having one session per window. This also aligns with the UX concept of 'open session in new window' which would set active session to that one - but auto-save would then add other windows tabs, too.

I think with the ability to auto-save towards an 'active session' the UX should to be clear around those concepts...

@sienori maybe have you thought about this differentiation and have your own idea on how to tackle this? Or you, @DiegoBM ?

Otherwise, I'd suggest to limit auto-saving triggered by active session to one window, but... What about multi-window sessions... maybe it can track only opened windows somehow... I don't see an easy way.

The one-session-per-window topic has been discussed before regarding this PR. If you check #890 you'll find a detailed explanation of why it won't be implemented in this PR, which you already mentioned above, basically follows one of those two ideologies, but it's properly explained I hope. Also, as you mentioned, it will open a whole new can of worms with probably more complex edge cases having to track one session per window. But primarily it does not match what I consider is the definition of session. If there is need for such functionality and anyone wants to implement it as a separate feature, please feel free to reuse any parts of this PR that might be useful to you, but I'll appreciate if you can keep that as a configurable setting, since that workflow would break the way some other people (or at least myself haha) use sessions.

EDIT: I forgot to mention that I totally agree that the UX should be improved if the setting is enabled. As you mentioned, in particular, with the button text, but in my case I would replace the "Open in current window" with "Open session" and use one single button, since as you mentioned, making the window distinction does not make sense anymore.

[sienori]

Sorry for the very late reply! After my previous reply I got busy and stopped developing TSM.

Thanks for thinking so much about TSM, @DiegoBM @tennox ! Your implementation has given me a lot of insight.
As it turns out, it is difficult to merge the active sessions you have implemented.

There are three roles required of TSMs.

1. Backup tabs history
2. Bookmark frequently opened tabs
3. Switch between workspaces

The current TSM achieves 1 and 2, but not 3. Active Session is a feature that achieves 3.

Your implementation offers active sessions as an option.
This means that users who have the option turned off cannot achieve 3, and users who have it turned on cannot achieve 2.
I would like to provide active sessions in a form that is available to all users.

I have a new idea for workspace switching.
It is to be able to give the session itself an attribute that can track changes.
In other words, to be able to set whether each session is an active session or not.
This will allow all users to achieve objectives 1, 2, and 3.

Specifically, add a "Track Changes" option to the session menu and to the dialog when saving a session.

• When an tracking session is opened, changes to tabs in that window are saved in real time.
• When a new window is opened, it will be added to the session. (Requires an option to disable)
• When the tracking windows are closed, the tracking ends.

I believe this will allow integration of workspace switching into the existing TSM workflow.
I will implement this idea!

I close the PR. Thank you for your contribution!