Guide | Browser Session, Saved Sessions, and How they Work Together
-
Preamble
I had written parts of this post in replies to several threads over the past year or so. To save myself time in the future, and provide new users with an easy reference, I decided to put it all together in this guide as an explication to a frequently confused aspect of the browser's functionality. Hopefully this successfully reduces that confusion, and enhances the utility of this functionality for users.
A few core points to understand include:
- All browser windows and the tabs they contain are part of the same session -- different windows are not separate sessions.
- Saved Sessions only exist on-disk, and currently cannot be updated. They provide users with the ability to restore a historical snapshot of the browser's prior state.
- When a saved session is restored its contents become a part of the single current session, and the restored tab(s) as well as any additional windows do not retain any association with the saved session.
Current Session & Last Session
The concept of the session as browser state was created over a decade ago, and is both defined & implemented in the Chromium backend code base. Chromium only has on-disk storage of the two most recent sessions (including the current one). "The state of the currently open browsers‡ is referred to as the current session. The last session corresponds to the last run of the browser [that had normal and/or tabbed browser windows]."¹ The important takeaway is that all the open windows & tabs are part of just one session - namely the current session - and different windows are *not* part of separate sessions. The current session isn't limited to only that. There are a lot more data that can be part of the session, including the navigation history & state, how the current page was loaded, even form data can be part of it.
‡ Note: "browsers" in this context refers to normal browser windows and browser windows containing tabs; it does not include private windows nor portable web apps (PWAs or just "apps").¹
Key points & behavior include:
-
All open windows and tabs are part of the same session, called the Current Session (excepting apps & private windows). There are two files in the profile folder that correspond to this for persistent on-disk storage of the current session, even after the browser is exited. Opening a new window in the same profile, no matter how it is done, doesn't create a separate session, as every normal & tabbed browser window currently running is part of one single session.
-
If the browser is configured to restore the previous session when started, if my memory serves, it restores the content of those 2 files and moves them to two equivalent files for on-disk storage of what has now become the last session (replacing the old files if they existed). Then it resets the current session files to handle the newly created window(s).
- That will include all windows & tabs that were open at the time the browser was exited. Note that closing windows before exiting the browser will remove them from the current session, and therefore will not be restored the next time the browser starts. In order to have multiple windows restored at startup, the exit command needs to be executed with all of those windows open.
Vivaldi's Saved Sessions
Vivaldi, being Chromium-based, inherits all this. Browser windows & open tabs are all part of the single current session, there are the same 4 files in the profile directory for the current & last sessions, and if the user chooses to restore the previous session at startup the same behavior occurs.
Vivaldi has extended this functionality, allowing users to write a (presumably) arbitrary number of sessions to disk, called Saved Sessions. Saving a session is essentially an on-demand trigger of the base session backend (from the Chromium code base). As well as the single historical session that is written to disk at browser startup†, users can create a snapshot of the current session (or a subset of it) at any time; this action creates the saved session.
† Note: the last session is handled by the inherited Chromium code, and does not appear in the list of saved sessions.
How these saved sessions work, and how they interact with the current session, is described next.
-
Saved Sessions are static objects -- once saved, they will never change other than if deleted. When creating a saved session, the user has the option of saving the entire current session (which is what the AutoSave Sessions Mod does), or limiting it to only the active window. That's a very useful option. Users do not have to close all the windows & tabs they don't want to include in the saved session; they can move all the tabs to be saved into a new window and limit the saved session to just that window. I make use of this frequently -- I'll typically have what I want to save already stacked, and just move the stack to a new window; after creating the saved session I can close that window if I'm not going to be using the tabs right then and want to free up resources.
-
When "opening" a saved session, regardless of whether the session is opened in the active window or a new one, its contents are merged into the current session -- because the action does not close any existing tabs or windows. Saved sessions can themselves contain multiple windows; when the user chooses to open that in the current window only tabs from one of the windows in the saved session are placed in the current window, the rest of the windows are restored as they were. This perhaps more than anything, outside of the implementation, illustrates that all windows are part of one session, not unique sessions unto themselves.
-
Once a saved session has been restored, all the tabs & windows belong to the current session. There is no persistent association with the saved session -- that is an immutable object. Nothing the user does (creating new tabs, closing old tabs, creating new windows, moving tabs to a new or different window, etc.) will affect the saved session. If the user wants to save any changes like that, a new saved session need be created and the user can optionally delete the old saved session. Saved session names must be unique, so saving a session with the same name as an existing one will automatically have a number appended to it in parentheses
(X)
depending on how many already exist.
That covers the most important aspects of how sessions - current, last, and saved - are structured and how to work with them.
In addition to the mod mentioned above, to automatically create saved sessions at regular time intervals, there is another mod that has greatly enhanced my workflows for saved sessions. The Advanced Panels Mod with Sessions Panel turned saved sessions from a feature I only made occasional use of for limited purposes into an important part of my everyday workflows. I find the panel to be a much better user experience than the native UI for creating, managing & restoring saved sessions.
I highly recommend installing both mods, instructions for doing so are in the pinned thread in the Modifications category of the forum. The AutoSave Sessions Mod will protect your current session state not only from crashes, but against user error as well (should you accidentally close a large number of tabs/windows). The Sessions Panel is an extremely useful way of working with saved sessions.
Let me know if any questions remain, or anything still needs further clarification.
--
ModEdit: Title
-
@BoneTone said in Browser Session, Saved Sessions, and How they Work Together:
when the user chooses to open that in the current window only tabs from one of the windows in the saved session are placed in the current window
Not having worked with "multiple window sessions":
Is there any way to predict or control which "saved window tabs" are merged into the current window?
E.g. Is it always the tabs from the window which was active when the session was saved? -
@BoneTone Nice work. Some thoughts fwiw:
-
"Saved Sessions only exist on-disk, and currently cannot be updated. They provide users with the ability to restore a historical snapshot of the browser's prior state" ...
1.1 Yes, but afaik users need to be clear in understanding what constitues "state". Afaik for instance, bookmarks are excluded, ie, if user uses the browser in a session, manually saves a session, then makes changes to non-tab features like BM's, the later restoration of that prior session does not return the BMs to that prior time too; they'll retain their latest content. Ergo, for my part, when i think of "prior state", i'm implicitly thinking of "prior tabs & windows state", not "prior global browser data state". -
"Users do not have to close all the windows & tabs they don't want to include in the saved session; they can move all the tabs to be saved into a new window and limit the saved session to just that window. I make use of this frequently -- I'll typically have what I want to save already stacked, and just move the stack to a new window; after creating the saved session I can close that window if I'm not going to be using the tabs right then and want to free up resources." ...
2.1 that of course works & is fine, but it's not strictly necessary. Without creating a new window, one can simply use the context menu on the selected tabs, in tabs row/column & in Window Panel, to save just those selected tabs as a new session. -
Some of us have had historical discussions already of this next point. It is debatable whether this behaviour is a bug or not, but IMO even if it is not a bug it is highly annoying behaviour. Fyi i now paste my own cumulative Notes on this annoyance:
Spoiler
Steffie 14 days ago ... 13/4/19
@LonM said in Adjust the Speed Dial size – Vivaldi Browser snapshot 1511.4:
a bug I reported a while back where saving a session that involves some pinned tabs doesn't always record which tabs are pinned correctly
Update. I've done more testing, & i need to retract/amend/expand some of my earlier text.
I now think that your bug IS strongly related to "my" bug [my apologies], but with a slight twist [of lemon?].
When earlier i wrote
after closing the 2nd window, sadly causing its tabs wrongly to materialise in the 1st window, some of them become pinned [they weren't before].
...i was only partly correct. I've now discovered this real weirdness:
\1. When only one window exists, & i create my various tabs that i intend to save as a new session, NONE of these tabs was pinned [several other, older, tabs are pinned, but none of these new ones (by intent)].
\2. Save those targeted tabs as session.
\3. Open this new session in window2 [new].
\4. Previously not noticed by me before, SOME of these new session tabs have erroneously become pinned [in fact most of them, but not all... weird within weird!].
\5. Yesterday, coz i'm a fool & failed to notice that in window2 many of those session tabs were now pinned, once i then closed window2 ALL those wrongly-pinned session tabs materialised back in window1, for the exact correct reason you originally described.
\6. i chose to omit it in my prior posts as i had not realised its major significance, & felt my text was already complex enough as is, but in fact it is [duh], ONLY those wrongly-pinned win2 tabs that later appear in win1... none of the few win2 unpinned tabs rematerialise in win1 once win2 closes [ie, that part at least = correct behaviour].
\7. Ergo, in win2, if before closing it i take the time to identify each falsely-pinned tab & unpin it, then when i close win2 NOTHING rematerialises in win1 [ie, = correct behaviour].
\8. Thus IMO i was completely wrong in correcting your characterisation before [sorry again], & i don't need to raise a new bug, coz this is merely another instance of your already-raised bug manifesting. It's new to me, but not new per se.
\9. The solution presumably requires identifying WHY some tabs get assigned an incorrect pin-state during session-creation. Once that initial error occurs, all the subsequent misbehaviour is inevitable.
Steffie about 5 hours ago ... 27/4/19
Hi @LonM. FYI, further to my 14-days-ago https://forum.vivaldi.net/post/286102 post, today's the first subsequent time i've needed to work with the session i'd created back then... but now of course being in 2.5.1525.4. Sadly the identical misbehaviour continues... most but not all of the reinstated tabs now in Window2 erroneously have become pinned again. I've now tediously re-unpinned each of them, so i expect in a few hours when i'm ready to close W2 they'll not rematerialise back in W1.
Have you also been experiencing this bug still in the current SS? Btw pls could you share the Bug# with me?
3 hours later... once i was finally ready to close W2, but before actually doing so, i saved a new session from it [as per above, i'd previously unpinned all W2 tabs]. Then [still with W1 & W2 open], from W2 i opened new W3 for that latest session. It was perfect, no pinned tabs. Hence closing W3 did not transfer any tabs into W2 or W1. Then i closed W2, & again W1 stayed untouched. Hence, now i'm quite puzzled re if this bug is actually already fixed, or not...
["my brain hurts, my br-ain hurts!
No, open the door & come in.
Oh, Sorry."].
Linux Manjaro18 KDE Plasma5 + Vivaldi Snapshot & Stable x64.
0
LonM MODERATOR 2 minutes ago
@Steffie Hi, I haven't had any issues recently with tabs becoming erroneously pinned (in the manner you described) in the recent snapshot.
But my earlier reported bug, where some tabs become pinned on saving a session, still occurs. For reference, mine was VB-46973.
.
.
5/4/20: It appears this Bug remains active [i have not used any Sessions for a very long time, so atm this is not affecting me even if it still exists] -- https://forum.vivaldi.net/topic/45464/saved-sessions-are-opened-with-pinned-tabs/6
.
.
8/4/20: Today i performed more Sessions tests, & now have derived an important insight into a hallmark of this ongoing bug. In my original notes on this bug, up above, i had said
Previously not noticed by me before, SOME of these new session tabs have erroneously become pinned [in fact most of them, but not all... weird within weird!].
Now i understand this part of the bug's behaviour. The number of falsely-pinned tabs in my restored session [either into a new window, or even just the current one] equals the total number of pinned tabs in the original window... even if none of those pinned tabs was selected in the set of tabs saved as the session. Ie, simply having any pinned tabs in the original window, causes that same number of tabs to become falsely pinned whenever i later restore the session. Fsck!
Ergo, now that i have discovered this idiosyncrasy, i have decided to unpin my standard 7 pinned tabs... & now my session-restores behave.
Ipso facto, until Vivaldi Devs fix this shitty bug, i can use pinned tabs OR sessions, but not both. Gahhhhhh.3.1 Since i last edited those notes i have reverted to permanently having some tabs pinned, consequently each time i restore a session into a second window, the damn hassle repeats with previously unpinned tabs becoming wrongly pinned in the new window... & if i'm not paying attention to manually unpin them prior to closing that second window, they damn well reflect back into my main window as this unwelcome new batch of pinned tabs that i need to manually remove. It is exasperating.
-
-
@TbGbe said in Browser Session, Saved Sessions, and How they Work Together:
@BoneTone said in Browser Session, Saved Sessions, and How they Work Together:
when the user chooses to open that in the current window only tabs from one of the windows in the saved session are placed in the current window
Not having worked with "multiple window sessions":
Is there any way to predict or control which "saved window tabs" are merged into the current window?
E.g. Is it always the tabs from the window which was active when the session was saved?I'm not certain, I'd have to do a fair amount of additional testing to figure it out, or possibly dig into the code but that might actually take more time than creating the prerequisites and executing the testing for a dozen distinct scenarios.
From the testing that I have done thus far, my SWAG would be that it restores the tabs from the "primary" (my word) window from the saved session into the current window. I *think* that primary is the "oldest" window in the current session.
Because a saved session with multiple windows will always be a snapshot of the current session at that time it is created, I don't think Vivaldi is doing any work on its own to determine what the contents of the saved session are, or how they are organized. They just need to call into the Chromium code for saving a session and redirect the output to the desired location on disk. For that reason, I wouldn't expect the active window at the time the session is saved would have any special significance.
So based on all that, and what I've noticed in the past, I think it's just what the first window is. If that had been closed, then maybe the second, and so on.
Just some more background details.
If I am remembering correctly, the code for handling sessions in Chromium is somewhat spread around different files, even in different parts of the source tree. Additionally, saved sessions is unique to Vivaldi, so at least some of the code handling the restoration of saved sessions will be maintained in Vivaldi's source, but they probably call into the session service code in Chromium after preparing what needs to be restored.
This is possibly a scenario that didn't get much attention in development or QA. Saved sessions are great, but not built with broad functionality. It was a wise design decision to write a bit of code that calls into Chromium's already stable but limited session functionality for creating the content of the files, writing them to disk, reading the files, and creating the necessary windows, tabs, navigation histories & states, etc. This way Vivaldi provides a very useful feature that was easy to launch, and requires little maintenance.
To create a more complex feature that supports scenarios like updating saved sessions, they would have needed to build (nearly) all of that either themselves or by making significant patches to the existing Chromium code and merge those changes (along with all the necessary QA) every time a new version was pulled from upstream.
To make it such that each window was its own session, and support a persistent association between the windows & saved sessions, Vivaldi would need to completely scrap Chromium's existing session code and build it all from scratch. It's a different design paradigm and they're not compatible. Even a cursory glance at some of the session code would give one an idea of just how enormous that project would be.
Whether this is a bug or not, I'm not sure and there are probably differing opinions. Would it be better, if a saved session has multiple windows, to just restore all those windows as they were and not place any tabs into the current window regardless of which restore option is chosen?
Even if so, I'm not sure if that's a reasonably easy change to make. Sessions are stored on disk with their own very convoluted format. It's not any kind of text-readable format, nor is it SQLite. Determining how to handle the tabs would require opening the session through the Chromium service first, but without affecting the current session, then after deciding what to do and possibly have to pass the on-disk file to the session service again -- causing significant delays.
Personally, I always restore to new windows regardless of the saved sessions content. So I'd be fine with just eliminating the open in current window option which would simplify this and get rid of this confusing scenario at the same time.
-
Sessions are clearly an important feature for many users. There are currently 70 Feature Requests about Sessions, and the top feature request is for a Sessions Panel.
To use them effectively it is important for users to understand what a session is, so thank you for the detailed explanation.
-
@Steffie I appreciate the detailed feedback. I'm super busy getting the house ready for Thanksgiving - a lot of cleaning to do, selling a desk, setting up a new home theater - so I'll be AFK until the weekend, maybe after. But I'll respond in full & update the OP as soon as I have a chance.
-
could it be, that the files at the harddisk have changed? wether I can't find the
current session
norcurrent state
file within my default profile -
New location for session & tabs files is:
Users/xxx/AppData/Local/Vivaldi/User Data/Default/Sessions/
xxx = user OS account name
-
It took me ages to find where the session data was located on a mac, and eventually I found it in:
/Users/<username>/Library/Application Support/Vivaldi/Default/Sessions
Hope this might help someone who might want to also back it up.