Open Bug 1427928 (Session_managers) Opened 6 years ago Updated 2 months ago

[tracking] Support session managers (Session Manager, Tab Session Manager, MySessions, Session Sync, Session Boss, Session Buddy, Tab Mix Plus) as webextensions

Categories

(WebExtensions :: General, enhancement, P3)

Product:
WebExtensions
Component:
General
Platform:
Unspecified
All
Type:
enhancement

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: robert_abc3, Unassigned)

References

(Depends on 12 open bugs, Blocks 6 open bugs)

Details

(Keywords: meta) 

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36



There are several extensions with session manager functionality:
* Session Manager (300 000 users in 2016) 
* Tab Session Manager (60 000 users and growing)
* MySessions (8000 users and growing)
* Session Sync
* Session Boss
* Tab Mix Plus (600 000 users in 2017).

The aim of this meta-bug is to group all bugs related to missing and available APIs needed by session managers. Especially, Michael Kraft’s Session Manager had a lot of options and it would be great if they can be supported by APIs. 

Here, it can be also the place to discuss what is the best way to support session managers with APIs.


https://addons.mozilla.org/en-US/firefox/addon/session-manager/
http://forums.mozillazine.org/viewtopic.php?f=48&t=2308889
https://www.mozdev.org/bugs/show_bug.cgi?id=26384

https://addons.mozilla.org/en-US/firefox/addon/tab-session-manager/
https://github.com/sienori/Tab-Session-Manager/issues?page=1&q=is%3Aissue+is%3Aopen

https://addons.mozilla.org/en-US/firefox/addon/my-sessions/
http://forums.mozillazine.org/viewtopic.php?f=48&t=3044441

https://addons.mozilla.org/en-US/firefox/addon/session-sync/
https://github.com/ReDEnergy/SessionSync/issues

https://addons.mozilla.org/en-US/firefox/addon/session-boss/

https://addons.mozilla.org/en-US/firefox/addon/tab-mix-plus/
http://tabmixplus.org/forum/


_________________________________________________________________________________________
**IMPORTANT!** 
Currently, there are several bugs which needs to be fixed before the work on session management API could start: 
Bug 1564412 (Bug 1474130, Bug 1549973, Bug 1544371, Bug 1549975, Bug 1507287 and more), and probably Bug 1467221.
In addition, Bug 944918 is causing issues/errors with session managers using IndexedDB (like, Tab Session Manager).
Blocks: 1226546
Depends on: 1378647, 1378651, 1381922, 1413525, 1235231, 1284886, 1322485, 1322060
Keywords: meta
OS: Unspecified → All
Priority: -- → P3
FWIW, I believe bug 1322060 is a footgun - I mentioned this in bug 1322060 comment 60, the tl;dr of which is that it will blow up the size of the session restore file (potentially causing Firefox startup to get slower) and doesn't provide a way to cleanup this data when addons are removed. IMO, a better solution would be facilities to allow addons to keep this state in their own private managed storage.
Discussion about needed APIs:
https://github.com/sienori/Tab-Session-Manager/issues/131
Alias: Session_managers
Summary: Support session managers (Session Manager, Tab Session Manager, MySessions, Tab Mix Plus) as webextensions → Support session managers (Session Manager, Tab Session Manager, MySessions, Session Buddy, Tab Mix Plus) as webextensions
Because bug 1322060 implemented saving of other extensions' data with full privacy, it's impossible for a session manager based on Web Extensions to read, save, or restore that data. That means it's impossible to write a Web Extension that can fully restore a session to its original state, the way "show your windows and tabs from last time" can, if it depends on the extension having read/write access to the session data itself. Legacy Session Manager had that access, but Web Extensions don't and never will.

The only way to create a session manager that can accurately restore a session is if there's an API to an internal Firefox component that can save and restore multiple sessions, without exposing the session data to the extension. There are some beginnings of a discussion about that in bug 1413525.

Therefore in my opinion it's rather futile to continue to pursue the list of all the individual low-level APIs that a session manager might need, to manipulate things like back-forward tab histories (bug 1381922), list of closed tabs and windows, session storage, etc., etc., because we know already that it can never be complete.

Yes, existing extensions like Tab Session Manager could be incrementally improved, for example with the ability to restore tab histories. But even if a design decision for that was approved (it was declined at the last meeting where it was discussed), there will always be something else missing. This is the way things are in Chrome, where for years extensions like SessionBuddy have been severely limited, compared to what Session Manager could do on Firefox. They still can't even restore tab history... I think we can do better.
I am one of those who wants these features, even willing to accept some risk, as long as the risk is known.  However, Elhem comment above is also something good to consider.  Here is what I know:
1) more than a million people were using some form of session manager, an awful lot of people think that was something important enough to go find and use
2) there are some really smart dev's on firefox
3) establishing an api that allows re-instantiating without reading should be possible, assuming the methods are built into the api 

Perhaps we need to create a data file to hold this data, data that can be used via an api, but not read directly.  For example, via api it could say, recreate the session from 1-1-2018, or save my current session as 'session name'. In the end, if we are going to do exactly what chrome does, then what is the purpose of firefox other than not being chrome (not saying that is bad purpose...).

Most people using session managers are looking for tools that will increase their productivity, or reduce their risk when firefox crashes and you lost all your tabs and history.  Some people, spend a lot of time in firefox, curating and storing up data that is being used for many of their projects.  Sometimes I have a set of pages/sites that I use for specific tasks on an intermittent basis, I was then able to save that session and recall it later when I wanted to  have the same setup.

Hopefully those making the design decisions can see how this can just go on and on.  There are so many use cases for this type of tool, it is surprising more attention isnt being spent on it to bring the functionality back.

Really do appreciate all the work the devs do.

David
Severity: normal → enhancement
@Mike

Bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1226547
https://bugzilla.mozilla.org/show_bug.cgi?id=1214733
are marked as P2 normal.

Thus, I believe that importance of this meta-bug should be higher than "enhancement". Many people did not update their Firefox to Quantum or just moved away to Watefox 56 because of the lack of good session manager.
I agree with Robert. I also won't update to Quantum until this is solved & I know several pro users who are the same.
(In reply to Robert Ab from comment #6)
> @Mike
> 
> Bugs:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1226547
> https://bugzilla.mozilla.org/show_bug.cgi?id=1214733
> are marked as P2 normal.
> 
> Thus, I believe that importance of this meta-bug should be higher than
> "enhancement". Many people did not update their Firefox to Quantum or just
> moved away to Watefox 56 because of the lack of good session manager.


Many similar meta-bags have priority P2 normal (examples: Bug 1226547, Bug 1214733) or P2 enhancement (example: Bug 1215064).
Priority: P3 → P2
Blocks: webextensions-additional-apis, webext
About potential conflict between session managers and other extensions working with Session Restore:
https://bugzilla.mozilla.org/show_bug.cgi?id=1407486#c15
I just want to present a usecase.
I hope you consider building better support for session managers as my daily workflow depends on useful and reliable window/tab management.

I'm one of those users who keep hundreds of tabs open at a time. The main reason I use Firefox over Chrome is because I can scroll through my tabs and the titles don't get minimized to a ridiculous small size. I have considered switching back to a pre-quantum version of firefox or a different browser altogether.

I keep my windows organized per subject (games, development, planning a specific trip, banking, etc...). 
Each window contains multiple tabs. If I think returning to the current page is useful, I will open links in a new tab instead of staying in the same tab. That way I have an array of tabs open with useful information I can return to.
This approach works best for me because I am very forgetful. If I close the tab I will forget about it. The History is too crowded to find the pages I need. 
After I am done with it, I will save that window as a session so I am able to return to those tabs when I need it.
For example when planning a trip The first time I open pages with interesting hotels and spots to visit. I save the window as a session planning this trip. Then a week later or so I revisit the same pages to make an actual decision and reservation.
Another example is I always have a certain set of webpages open when I play a certain game. I can close these windows when I am done playing and reopen these specific pages when I play again. (this reaches tens sometimes even 50+ tabs).

Without extensive session/window/tab managers this becomes a serious hassle.
Keeping pages open without actually using them (because I need them in a few days but not right now) hurts my user experience by hogging up resources and cluttering my browser with too many windows.

I hope this is given a proper priority.
Thanks and good luck developers.
Hi all, thanks for the ping. Most of these bugs are approved. Unfortunately, our engineering team currently doesn't have the capacity to work on these. 

Would anyone here be interested in creating experimental APIs for patches? We have some information about WebExtensions Experiments available here: https://webextensions-experiments.readthedocs.io/en/latest/
Great that these bugs have been approved! (I wish I could contribute, but I lack the skills.) I know many people are only waiting for support of session managers before they can/will switch to 57+. But waiting is not so bad; of course not everything can be of the highest priority. Any idea as to when some more engineering capacity might be available to deal with this eventually?
(In reply to Caitlin Neiman [:caitmuenster] from comment #11)
> Hi all, thanks for the ping. Most of these bugs are approved. Unfortunately,
> our engineering team currently doesn't have the capacity to work on these. 




We understand that Mozilla engineering team has a lot of work. And we are aware that you are working on some important projects like “Design and implement an API for Toolbars” and other ones.
However, session managers’ developers and approx. 1 million users would appreciate if you could schedule work to solve this bug and related ones soon enough, just after completion of other work you have started. Please also consider to setup a way to collect monetary contributions from users, which could be used directly to fund/hire additional program engineers in WebExtensions team (even on temporary basis, for example for this project). 

The fix for this bug and related ones (found in page section Tracking/Depends on) are supported by developers of:
* Tab Session Manager
    https://addons.mozilla.org/en-US/firefox/addon/tab-session-manager/   (in the section: About this extension)
* MySessions
    https://addons.mozilla.org/en-US/firefox/addon/my-sessions/   (in the section: About this extension)
* Tab Mix Plus
    https://addons.mozilla.org/en-US/firefox/addon/tab-mix-plus/   (in the section: About this extension)
    http://tabmixplus.org/support/troubleshooting/data/legacy-tabmix.html

These API/bug fixes are also supported by many users of these extensions (including Session Manager). Many of them voted on these bugs to be solved. As you can see more than **100 users** voted on this bug already; many other related bugs got also strong support with >>100 votes. 

Many users are asking session manager developers about futures depended on Bug 1378647, Bug 1378651 or Bug 1381922. But this is just the top of iceberg. Michael Kraft’s Session Manager offered much more. Discussion started in Bug 1413525 should be continued for the best and the most efficient support for these extensions. 

We are not asking about new futures here, but recovery of that what was lost during Quantum/WebExtensions revolution. Please, consider this meta-bug as the one for fixing Firefox regressions done during Quantum introduction.
(In reply to Robert Ab from comment #8)
> (In reply to Robert Ab from comment #6)
> > @Mike
> > 
> > Bugs:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1226547
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1214733
> > are marked as P2 normal.
> > 
> > Thus, I believe that importance of this meta-bug should be higher than
> > "enhancement". Many people did not update their Firefox to Quantum or just
> > moved away to Watefox 56 because of the lack of good session manager.
> 
> 
> Many similar meta-bags have priority P2 normal (examples: Bug 1226547, Bug
> 1214733) or P2 enhancement (example: Bug 1215064).

Moving this back to P3.  Per the Bugzilla CoC: "Unless you are the bug assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields."  Per the Bug Triage Guidelines (https://wiki.mozilla.org/Bug_Triage/Process/Triage), P3 is indicative of an item in the backlog, which is appropriate for this request.
Priority: P2 → P3
(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #14)
> (In reply to Robert Ab from comment #8)
> > (In reply to Robert Ab from comment #6)
> > > @Mike
> > > 
> > > Bugs:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1226547
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1214733
> > > are marked as P2 normal.
> > > 
> > > Thus, I believe that importance of this meta-bug should be higher than
> > > "enhancement". Many people did not update their Firefox to Quantum or just
> > > moved away to Watefox 56 because of the lack of good session manager.
> > 
> > 
> > Many similar meta-bags have priority P2 normal (examples: Bug 1226547, Bug
> > 1214733) or P2 enhancement (example: Bug 1215064).
> 
> Moving this back to P3.  Per the Bugzilla CoC: "Unless you are the bug
> assignee, or have some say over the use of their time, never change the
> Priority or Target Milestone fields."  Per the Bug Triage Guidelines
> (https://wiki.mozilla.org/Bug_Triage/Process/Triage), P3 is indicative of an
> item in the backlog, which is appropriate for this request.


During filing a bug, I set priority/severity level as P3 normal. 
Then you changed severity normal  → enhancement and I changed priority P3 → P2 (after looking at other bugs mentioned above, so this change is not unreasonable). 
Now you have changed priority P2 → P3. 

So as you can see, I did change priority level which I had set up during bug filing.
As Mike Conca notes, our engineers have the final say on bug prioritization. This is not up for negotiation.

Robert, I strongly encourage you to read the Bugzilla etiquette and contributor guidelines available here:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html 

and to take them to heart. If you have meaningful contributions to make that will move these bugs forward, by all means add them. If however you continue to try to game our triage process by abusing the priority and CC fields, my next action will be to suspend your account.

Have a good evening.
As I think it might provide useful insight, I'd like to share my use case.

I fully trust Firefox's session serialization machinery. In the years since I first started using Mozilla Suite in 2001, and with sessions ranging from one tab to over a thousand, it's never lost or corrupted a session for me and there have been only two pre-e10s instances where I had to uncheck a tab to prevent the browser from crashing on restore.

What I don't trust is Firefox's recovery UX. I run Session Manager on Firefox 52 ESR because I've occasionally clicked "new session" by mistake and I've lost count of the number of times where, during a restart (triggered or crash-caused), the browser has gotten confused and either created a new session to receive a tab Thunderbird requested opened (race condition?) or restored just one window of my session, or some other mess which required me to do a clean shutdown, reopen the browser, and then try again with the same saved session rather than the one the clean shutdown created.

If I didn't have Session Manager providing a stack of the last 5 crash/shutdown sessions so I can step backward until I get a good one, I'd have had to resort to winding Firefox back to last 4AM's incremental backup and living with that data loss.

I would have no problem with a session-management API that treats sessions as opaque blobs with a couple of pieces of read-only metadata hanging off them (I typically tell recovery sessions apart by their tab and window counts) and a writable title as long as a browser or extension bug couldn't blow away my backup sessions without actively looping through them and deleting them one-by-one.

Furthermore, it seems like an API built around "sessions are opaque blobs that have metadata and can be saved, loaded, duplicated, and renamed" would be relatively simple to design as extensible (eg. an options parameter which could later gain things like "replace or append to current tabs when loading?" and implement soon in a basic form, allowing most of the decisions to be deferred.
No longer depends on: 1235231
(In reply to Stephan Sokolow from comment #17)
> [SNIP]
> I would have no problem with a session-management API that treats sessions
> as opaque blobs with a couple of pieces of read-only metadata hanging off
> them (I typically tell recovery sessions apart by their tab and window
> counts) and a writable title as long as a browser or extension bug couldn't
> blow away my backup sessions without actively looping through them and
> deleting them one-by-one.
> 
> Furthermore, it seems like an API built around "sessions are opaque blobs
> that have metadata and can be saved, loaded, duplicated, and renamed" would
> be relatively simple to design as extensible (eg. an options parameter which
> could later gain things like "replace or append to current tabs when
> loading?" and implement soon in a basic form, allowing most of the decisions
> to be deferred.

I like this!

Offering session saving addons an encrypted serialised blob per tab/window and accepting that stream back again during restore (to add/replace current session), should provide no security issues for web extensions (if that is the problem here). The encryption key is of course placed in the profile folder. This tightly couples the saved sessions to the profile, which may not be what everyone wants, but most users probably never moves these files between profiles in the first place. If this is an issue, a simple conversion program to the standard session saving feature could be offered (which I assume is not encrypted and hence can be moved between profiles).

Attaching metadata (e.g. title/url) to the encrypted tab data should be considered (is available to web extensions today so why not?).
I see having the session data in an encrypted form the extension itself can serialize/deserialize but not decrypt (as opposed to an "resource handle" to be fed to Firefox's session manager controls) to be a footgun which doesn't enable new functionality.

Suppose the following were true:

1. The browser's (already well-established to be reliable) session-recovery machinery gets extended to support saving to/loading from more than just the default session.

2. APIs for managing sessions are exposed to extensions (similar to how, unless you have a container tabs extension, you've just got the default container).

3. Firefox Sync is extended to support this.

With Firefox's excellent serialize/deserialize machinery, any low-level storage machinery an extension could write would be less reliable (unlike Chrome, the only time I lost a Firefox session was when a bug caused Firefox to bypass the crash recovery dialog with the assumption that I'd asked to discard... thus my need for multiple recovery snapshots.)

With Firefox Sync support, you've covered the only use case I can think of for "encryption key in the browser profile and extensions can't see it". (Without the extension having the encryption key, Sync is the only use case I can think of where there's merit in being able to store the extension data outside of Firefox's own session machinery.)

...and discussion on the constellation of bugs surrounding this has already shied away from exposing raw, unprotected session data to extensions. Hence my proposal of an API where extensions can manage sessions without extracting data from them.

If WebExtensions allowed extensions to do their own raw filesystem I/O within the Firefox profile folder, things might be different but, even then, I'd still trust Firefox's disk I/O logic more than an extension's own solution.
a hash/unique id for every tab in addition to a serialized string could be useful as well
the lifetime of this id should equal the lifetime of the tab

and hashes are more performant than the browser creating, decrypting and serializing strings constantly

possible api suggestions:
Get all tabs (from window x) (that are in container x (work, etc.)) (that haven't been used in the last x) (that have been modified in the last x) (that are/aren't private) (that have id x) (that have domain x)

the APIs should expose the tabs position number in the window

get icon/title of a tab (to show them to the user), maybe even a preview (something that the user can select tabs to restore from) 

In general there should be methods to tell Firefox to export/import tabs/windows to/from a file.
of course not encrypted.
Calling the function, Firefox could show an open/save dialog to the user.

get/set tab's container field.

get tab's last modification date, date of creation, date of last page reload

get tab's domain (useful for different cycles, see below)

Maybe adding/attaching datafields to a tab could be useful for addons like treetabs or session managers.
Session managers could then backup this additional data as well or even modify it (to keep trees in-tact when restoring them only partially, or to show the tabs in the restore window as a tree)
for session managers:  the tab is part of window x at this point in time (date of backup)

ids and knowing data fields (like tree structures) could allow session managers to offer functionality like different saving cycles for different tabs: local pages, pages from YouTube, Google etc. could be handled differently.
or tabs by domain x: only backup on page reload (and not just when the value of an input is modified)

should backups be saved in the same db as normal tabs? (with the same tab hash/id then)

addons could provide functionality like history of each tabs (snapshots)
right click on tab -> restore to 1hour ago/to one of these dates of modifications
maybe even create another snapshot before resetting, so that you can return again to the future
example: I wrote text an hour ago and I accidentally deleted it, no problem reset tab to that date, copy the text, return to the most current snapshot, done


a search bar at the top of the backup/restore window to filter for titles/domains or to filter for tabs modified/created in, could be created together with get all tabs function
for example: export all tabs from domain mozilla.org

or export tabs that I haven't touched in ages to file and then remove them from the current list of tabs

for export: addons should be able to keep track of a folder to export to by default (once the user selected one with the save dialog), so that it doesn't have to open that dialog for every export


how should deletion/aging of snapshots be handled? how big is the database allowed to grow?
should addons take care of calling deletion? or should there be a default garbage collector that addons can configure?

What about several backup addons? only allow one such add on at time or infinitely many?

that's all my input for now :D
My main desire is to find a minimal useful subset that can be implemented quickly without crippling the ability to then extend it to other desired use cases over successive releases.
Summary: Support session managers (Session Manager, Tab Session Manager, MySessions, Session Buddy, Tab Mix Plus) as webextensions → [tracking] Support session managers (Session Manager, Tab Session Manager, MySessions, Session Buddy, Tab Mix Plus) as webextensions
Opaque blobs are not enough.

Consider the following scenario, which I have personally experienced any numbers of times: I have a window with many tabs. One of the tabs causes a crash. I reopen Firefox, reload the session, and... of course, it crashes again!

The Session Manager extension had the very important feature of allowing me to uncheck certain tabs when restoring an extension. If you were to implement the API in terms of opaque, encrypted blobs, not only would this crash-loop prevent me from using the UI to restore my session, there's a very good chance I'd be unable to do it even with basic command-line tools!

I'm fine with an extension having the ability to see all my saved tabs, just like I'm fine with Firefox itself being able to. I don't know what technical impediments there are in WebExtensions around this, but you will never have a reliable session manager without the ability for the user to interact with the *contents* of a saved session.

[Accidentally posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1413525 initially. Whoops. That bug also has some other good discussion around session managers needing access to session data.]
(In reply to Tim McCormack from comment #23)
> Opaque blobs are not enough.
> 
> Consider the following scenario, which I have personally experienced any
> numbers of times: I have a window with many tabs. One of the tabs causes a
> crash. I reopen Firefox, reload the session, and... of course, it crashes
> again!
> 
> The Session Manager extension had the very important feature of allowing me
> to uncheck certain tabs when restoring an extension. If you were to
> implement the API in terms of opaque, encrypted blobs, not only would this
> crash-loop prevent me from using the UI to restore my session, there's a
> very good chance I'd be unable to do it even with basic command-line tools!

When I say "opaque blobs" , I mean opaque to the extension.

It would still be possible for Firefox to interject with an "Uncheck tabs if you want" dialog when asked to restore things.

(My focus is APIs that could be implemented quickly, then polished up later without breakage.)

> 
> I'm fine with an extension having the ability to see all my saved tabs, just
> like I'm fine with Firefox itself being able to. I don't know what technical
> impediments there are in WebExtensions around this, but you will never have
> a reliable session manager without the ability for the user to interact with
> the *contents* of a saved session.
> 

As I understand it, the impediments aren't technical but, rather, due to concerns about extensions exfiltrating or allowing leakage of sensitive user data. 

My "opaque to the extension" idea is focused on deferring as much of that discussion until later in the hope that I'll have *something* I can use when Firefox 52 falls out of ESR.
(In reply to Stephan Sokolow from comment #24)
> As I understand it, the impediments aren't technical but, rather, due to
> concerns about extensions exfiltrating or allowing leakage of sensitive user
> data. 

How about a system of permissions? The user could give some extension(s) the permission to get tabs information, while the other extensions would not be able to get any information. At install time, an extension could ask for some specific permissions, and the user would be able to choose.
(In reply to Vincent Lefevre from comment #25)
> How about a system of permissions? The user could give some extension(s) the
> permission to get tabs information, while the other extensions would not be
> able to get any information. At install time, an extension could ask for
> some specific permissions, and the user would be able to choose.

The problem there is that it's likely to get bogged down in discussion, both of whether it's the right approach and of the implications of various design decisions, such as unintended consequences of granting each permission. (Why do you think seemingly every extension needs permission to "read all your data"?)

Hence my encouragement of an API that combines as much minimalism and extensibility as possible to maximize the chance that the bare minimum functionality is out in time for ESR to drop the legacy extension API.

(On multiple occasions over the last decade, I've had Firefox accidentally create a new session without my permission. Were is not for Session Manager keeping a record of my last five sessions, it would have required me to rewind to the previous night's incremental backup, sacrificing today's tabs to recover the hundreds in my backlog. It's bad enough that I had to write an external utility which hooks Ctrl+Q events on Firefox windows at the X11 window system level and then discards them to prevent accidental closes in my post-52.x profile.)
Due to the implementation of bug 1322060, which allows extensions to store private data inside sessions, it's not possible for a session manager extension to read full session data including other extensions' private data, and almost certainly never will be. See comment 4.

Therefore if full session data were to be stored in a session manager's extension's local storage, the way current session managers like Tab Session Manager do, it would have to be encrypted so the extension couldn't read the private data contents. One advantage of saving sessions in the session manager extension's local storage is that if the extension is removed, all its session data is cleaned out too. Another is that it would have exclusive control over them, in terms of organizing, naming, tagging, deleting, and so on, and not worry about other extensions interfering. The extension would pass the encrypted session to Firefox's internal session storage system, which would restore it. The extension could still have access to a list of tab and window titles stored outside the "blob" as metadata, so the user could choose to tell Firefox not to restore certain ones after a crash etc., or Firefox could present the existing built-in "session restore" window that allows the user to choose which tabs to restore.

On the other hand, session data could be stored in a central repository in the profile folder, unencrypted. Only the internal session storage system would have direct access, and it would pass "handles" or names on to extensions, along with lists of windows and tabs the extension could display. One advantage is that multiple extensions could access the sessions. One extension could manage automatic backups, while another could deal with saving and restoring named favorite sessions for example, or other functions. You could change session manager extensions and still access your sessions. It would be more flexible, but maybe have more risk of conflicts between extensions.

Personally I'd lean toward the latter, a central database of saved sessions that can be used by different extensions.
Elhem's solution sounds attractive, not only because of the advantages he mentions, but also because it allows for maximum manual control for the user. The user could e.g. salvage a session from a broken profile (profiles have always tended to break eventually to some degree), make and restore manual back-ups, etc.
The latter also has the advantage that all code actually involved in translating between an active session and a serialized batch of data on disk would be internal to Firefox and shared between all extensions, rather than having every inexperienced extension developer having to reinvent part of the pipeline. (Thus minimizing the chance of an extension causing data loss.)
Summary: [tracking] Support session managers (Session Manager, Tab Session Manager, MySessions, Session Buddy, Tab Mix Plus) as webextensions → [tracking] Support session managers (Session Manager, Tab Session Manager, MySessions, Session Boss, Session Buddy, Tab Mix Plus) as webextensions
New webextension Session Boss: 
https://addons.mozilla.org/en-US/firefox/addon/session-boss/
Mozilla Plans for API for SESSION MANAGEMENT
(from 2018 Firefox Roadmap https://wiki.mozilla.org/Firefox/Roadmap updated on 2018-04-12):

"More Extension APIs: Firefox extensions will become more capable with additional features for tab management and organization, including a full implementation of Tab Hiding (61) and User Scripts (61) APIs. Two other highly requested feature areas, Toolbars and Secure Overlays (Q4) will land an initial set of development APIs, while other feature areas such as Session Management, Bookmark Management (Q3) and Clipboard Interaction (Q2) will be rounded out with incremental APIs."
Blocks: 1459029
Blocks: 1333837
Depends on: tab-unloading
No longer depends on: 1378647, 1284886, 1322485
Depends on: 1378647
New version of Tree Tabs has now tiny session manager: 
https://addons.mozilla.org/en-US/firefox/addon/tree-tabs/
Loading lots of tabs at once makes Firefox Unusable until tabs load. Sometimes Firefox can crash.
We need tabs creation as discarded.
Related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1378647
Tab Session Manager loses all its backed up sessions every time I update FF.  A comment for MySessions, by 200rabbits, observes the same thing happening there.  I don't know if it is the API or the fault of the developers; but a session manager that forgets its sessions every update is virtually useless - especially with FF's frequent release schedule.

IMHO, FF Quantum should never have been released without a working session manager plugin, or at released as an independent, experimental branch.  It's present and working on most modern browsers.  The rush to support a new API is almost never so great that moving forward leaving a trail of important broken libraries or plugins is better.
No longer blocks: 1459029
https://bugzilla.mozilla.org/show_bug.cgi?id=1459029#c1
https://bugzilla.mozilla.org/show_bug.cgi?id=1459029#c2


David Durst:
>>> Bug 1427928 no longer blocks: 1459029

Robert Ab:
>> Will bug 1427928/session manager API be prepared in 2018? Originally, it was planned for Q3 2018 (https://bugzilla.mozilla.org/show_bug.cgi?id=1427928#c33); initial target for these APIs was FF63.

David Durst:
> Session management is something we are pursuing still. I want to separate it a bit so we can discuss it apart from pre-existing session manager extensions, so that we frame the approach first and then the applicability to those manager extensions. We'll be filing a separate (new) metabug to track that work, and that should subsume bug 1427928.
(In reply to Robert Ab from comment #37)

> Robert Ab:
> >> Will bug 1427928/session manager API be prepared in 2018? Originally, it was planned for Q3 2018 (https://bugzilla.mozilla.org/show_bug.cgi?id=1427928#c33); initial target for these APIs was FF63.

Hmm I don't see a quarter for session management? You think it's grouped with bookmark management in Q3? (At least Session Boss seems to work well enough for the time being, though. Hmm, on second thought, recent reviews seem to be complaining about its (un)reliability, which would be a big issue.)
Depends on: 833791
(In reply to swleefers from comment #38)
> (At least Session Boss seems to work well enough for the time being, though. Hmm, on second thought, recent reviews seem to be complaining about its (un)reliability, which would be a big issue.)

Can confirm unreliability of Session Boss. Used it for a month or so. Randomly switches tabs' pages.
Assuming that can be fixed, though, it's proof of concept of session management in Quantum.
I'm sure it would be nice to have the reliability of a built-in mechanism and API, though.
Depends on: 833790, 1300399
https://bugzilla.mozilla.org/show_bug.cgi?id=833790(In reply to Jack from comment #39)
> (In reply to swleefers from comment #38)

> Can confirm unreliability of Session Boss. Used it for a month or so.
> Randomly switches tabs' pages.
> Assuming that can be fixed, though, it's proof of concept of session
> management in Quantum.
> I'm sure it would be nice to have the reliability of a built-in mechanism
> and API, though.

Ah, how unfortunate. I suppose we need built-in session management more than ever. Unless the problem in Session Boss could be fixed (or is it due to a bug in Firefox?).
(In reply to swleefers from comment #40)
> Ah, how unfortunate. I suppose we need built-in session management more than ever. Unless the problem in Session Boss could be fixed (or is it due to a bug in Firefox?).

If the bug is incidental, it's a proof of concept. If the bug is necessarily triggered by doing whatever sessiony stuff SB is doing, then we're no better off.

The developer said he'd work on it, but nothing has happened in a while. I don't know any more about the source of the bug.
Depends on: 833792, 833794
I would just like to confirm that Session Boss is currently not reliable at all. And I'd like to confirm that we are still in desperate need of proper session management in Firefox. I currently have no choice but to stay on the ESR until this is resolved although I would very much like to upgrade to Quantum.
(In reply to mozilla from comment #42)
> I currently have no choice but to stay on the ESR until this is resolved although I would very much like to upgrade to Quantum.
Me too.
Another reason to wait is bug 1467057.
Session management is SO bad, I periodically just do a "save all tabs" with the date and time on it. Please make this work again.
Product: Toolkit → WebExtensions
(1)
These are the confirmed and prioritized APIs, with their corresponding tentative target release version in parentheses:

API	                target release
userScripts	        63
topSites	        62
desktopCapture (TBD)	63
declarativeContent	63
Session management	63 (TBD)
Toolbars	        63 (TBD)
Overlays	        64 (TBD)

Source (Jun 23, 2018): 
https://wiki.mozilla.org/Add-ons/Projects#New_WebExtension_APIs


(2)
In the next six months, we anticipate landing WebExtensions APIs for clipboard support, bookmarks and session management (including bookmark tags and further expansions of the theming API).

Source (Jun 23, 2018): 
https://blog.mozilla.org/addons/2018/06/21/add-ons-at-the-san-francisco-all-hands-meeting/
(WebExtensions APIs)
Depends on: 1364019, 1307759
Depends on: 1375546
No longer depends on: 833794
Depends on: 1476144
No longer depends on: 1307759, 1308059, 1364019, 1399147, 1405249, 1407486, 1408575, 1411603, 1413263
No longer depends on: 1378647
Session Manager API - about work progress and plans:


Question:
Shane - Thank you for working on session manager-related bugs, including Bug 1378647, which is crucial for many session manager developers.
Can you also look into Bug 1413525? There are some other bugs related to Bug 1413525: Bug 1378651, Bug 1381922, Bug 833791, Bug 833792.
Thanks!!
[Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1413525#c54]


Answer:
Bug 1474130 (and Bug 1564412) might end up blocking much work here, but for now bug 1378651 and bug 1364019 are possibly reasonable to do.  There are other priorities in the way.
[Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1413525#c55]
Depends on: 1474130
Depends on: ss-SM
No longer depends on: 1474130, ss-SM
Depends on: ss-SM
No longer depends on: ss-SM
See Also: → ss-feature, ss-reliability, ss-perf
Depends on: ss-SM
Bug 1378647 was fixed and MySessions developer used it to improve his webextension:
https://bugzilla.mozilla.org/show_bug.cgi?id=1378647#c63
Depends on: 960572
Depends on: 1246236, webextensions-startup
Blocks: 1457567
Depends on: 1474130
(1)
Session management, originally planned for 2018, is being moved to 2019. Two primary reasons:
- Underlying platform code is being moved to C++ (Bug 1474130, Bug 1564412), so basing WebExtensions API on current platform code could likely be wasted effort.
- Engineering resources on the add-ons team are being reprioritized to focus on search hijacking, a top-level company initiative.

Source (message written by Mike Conca on July 31, 2018; copied on Aug 16, 2018):
https://trello.com/c/dyUKgHJJ/39-new-webextension-api-development
https://trello.com/c/elTMzfQ6/126-session-management-api
	

(2)
These are the confirmed and prioritized APIs, with their corresponding tentative target release version in parentheses:

API                                                  target release
UserScripts                                          63
topSites (places support)                            63
declarativeContent                                   64
Content handler API                                  64
desktopCapture (analogous solution by WebRTC team)   TBD
Overlays                                             65 (TBD)
Session management                                   (TBD)
Toolbars                                             (TBD)

Source (page last modified on July 26, 2018; copied on Aug 16, 2018):
https://wiki.mozilla.org/Add-ons/Projects#New_WebExtension_APIs
Depends on: 1422436
Depends on: 944918, 1406181, 1474562
Summary: [tracking] Support session managers (Session Manager, Tab Session Manager, MySessions, Session Boss, Session Buddy, Tab Mix Plus) as webextensions → [tracking] Support session managers (Session Manager, Tab Session Manager, MySessions, Session Sync, Session Boss, Session Buddy, Tab Mix Plus) as webextensions
Depends on: 1423917
As explained in previous comments, improving the sessions management API is something that Mozilla has in its backlog, but has not scheduled for a release.  The current priority of P3 reflects this.  We have landed a few of the dependent bugs, but several others remain. As always, the priority of session management is continually evaluated together with many other feature requests and bug fixes.

The last few months of comments have either been advocacy or off-topic, doing nothing to advance the understanding or resolution of this bug (see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html for guidelines on posting bugzilla comments).  I have requested that further comments be restricted.
Restrict Comments: true
Depends on: 1512802

Status update for broken indexedDB bug fixes (Bug 944918, Bug 1423917) can be found in Bug 1482662.

Depends on: 1482662

SESSION MANAGEMENT AND CONTAINERS:

(1)
Consider assigning different sessions to separate containers
https://bugzilla.mozilla.org/show_bug.cgi?id=1524959
https://bugzilla.mozilla.org/show_bug.cgi?id=1528598#c6
https://bugzilla.mozilla.org/show_bug.cgi?id=1528604#c2

(2)
Consider allowing individual session management of containers
https://bugzilla.mozilla.org/show_bug.cgi?id=1512802

Consider supporting save/restore of individual containers within/from a session (GitHub)
https://github.com/mozilla/multi-account-containers/issues/1325

Depends on: mult_sessions2

The ability to manage multiple sessions by Firefox session managers could be included in newly designed and improved session management API.
Please, check these two alternative bugs related to Firefox build-in Session Restore for more details:

The major benefits of this future would be:

  • session(s) could be added or removed to/from current set of sessions opened in the browser;
  • different sessions could be saved independently from each other and
  • the names of opened sessions should be remembered by Firefox/extension, and these names should be suggested by Firefox/its extension during manual saving of session.

Examples in Bug 1528598 comment 1, and in Bug 1524948 comment 1, are just showing what this new future could provide us.

Depends on: mult_sessions1
Depends on: mult_sessions_API

WebExtension API to manage multiple sessions at the same time (Bug 1528604) could be based on one of two alternative Session Restore bugs: Bug 1528598 (mult_sessions1), or Bug 1524948 (mult_sessions2).
This WebExtension API (Bug 1528604) should be a part of session management API (bug 1427928).

Please, see also Bug 1427928 comment 61.

Depends on: 1475240
Depends on: 1253129
Depends on: 1544371
Depends on: 1507287
Depends on: 1541370
Depends on: 1545886
Depends on: 1404626

This bug doesn't appear to serve any concrete purpose, and has a large number of dependencies which don't appear to have any relation to session management add-ons.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
No longer depends on: webextensions-startup
No longer depends on: 1482662
No longer depends on: mult_sessions2, mult_sessions1
No longer depends on: 1545886
No longer depends on: 960572

Moving bugs related to data storage and IndexedDB to meta-bug 1546264

Depends on: IndexedDB-SM
No longer depends on: 833792, 944918, 1246236, 1541370, 1406181, 1423917, 1474562

Moving Bug 1474130, Bug 1544371, Bug 1507287 to meta-bug 1482682.

No longer depends on: 1474130, 1507287, 1544371

(In reply to Kris Maglione [:kmag] from comment #63)

This bug doesn't appear to serve any concrete purpose, and has a large number of dependencies which don't appear to have any relation to session management add-ons.

I have re-organized approx. 40% bugs and removed few. I hope that it should be now easier to navigate among these bugs.
Listed bugs describe approved and proposed APIs needed by session managers. Thus, I am re-opening Bug 1427928.

IMPORTANT!
Currently, there are several bugs which needs to be fixed before the work on session management API could start:
Bug 1564412 (Bug 1474130, Bug 1549973, Bug 1544371, Bug 1549975, Bug 1507287 and more), and probably Bug 1467221.
In addition, Bug 944918 is causing issues/errors with session managers using IndexedDB (like, Tab Session Manager).
These bugs are not direct dependencies of Bug 1427928 now - I have moved them to other meta-bugs for clarity.

Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Blocks: 1571368
Depends on: 1373490
Blocks: cuts-control
Blocks: cuts-addons

What are the current plans for session management API?

Underlying platform code has been moved to C++ (Bug 1564412, Bug 1474130, and more), so basing WebExtensions API on new platform code can be done now.
I am not sure if Bug 1467221 is necessary for session management API.

Reference:
Bug 1427928 comment 33
Bug 1427928 comment 37
Bug 1427928 comment 45
Bug 1427928 comment 46 (!)
Bug 1427928 comment 48 (!) / https://trello.com/c/dyUKgHJJ/39-new-webextension-api-development
Bug 1427928 comment 66

Flags: needinfo?(mixedpuppy)
Flags: needinfo?(mconca)
Flags: needinfo?(mconca) → needinfo?(philipp)

I hope you appreciate the spirit of honesty and frankness with which I say this. Our schedule is very full with current platform needs and that is unlikely to change through the rest of the year. This bug unfortunately has become very overloaded, just filtering through what is important and how that fits into our goals is going to be significant effort, which further lowers the probability that it will happen.

Flags: needinfo?(mixedpuppy)
Flags: needinfo?(philipp)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.