APIs needed by Tab Session Manager

[RobertAb1]

(1) Do you have a list of APIs needed for Tab Session Manager? APIs for session managers are now in the planning stage (for 2018) at Mozilla so it will be good to provide them with full list of APIs and it could be useful for you in TSM webextension development.

See here response by Tim Nguyen: https://www.reddit.com/r/firefox/comments/7dxmu4/why_firefox_had_to_kill_your_favorite_extension/dr9ul6p/ This is a longer discussion between me and Tim about APIs needed by session managers: https://www.reddit.com/r/firefox/comments/7dxmu4/why_firefox_had_to_kill_your_favorite_extension/dqsbz0u/

Also see first two sentences in Dan Callahan’s comment: https://hacks.mozilla.org/2017/11/new-in-firefox-58-developer-edition/#comment-22461 I got similar response from Mike Conca. In addition, Mike Conca gave the following response in the comments here: https://blog.mozilla.org/addons/2017/11/20/extensions-in-firefox-58/comment-page-1/#comment-224965 “A tab placement API is being worked on right now. It won’t make it for 58, but should appear shortly afterward. Hooks into the keychain service are under discussion (primarily for security review), and session manager API are on the roadmap.”

(2) Tim Nguyen helped audit Session Manager and then filled most of the bugs for needed APIs: https://www.reddit.com/r/firefox/comments/6lcq7r/session_manager_dev_says_session_manager/

The list of APIs needed by session managers (3 ready, 3 unassigned): https://bugzilla.mozilla.org/show_bug.cgi?id=1378647 (session managers-6APIs, unassigned) https://bugzilla.mozilla.org/show_bug.cgi?id=1378651 (session managers-6APIs, unassigned) https://bugzilla.mozilla.org/show_bug.cgi?id=1381922 (session managers-6APIs, unassigned) https://bugzilla.mozilla.org/show_bug.cgi?id=1284886 (session managers-6APIs, fixed FF57) https://bugzilla.mozilla.org/show_bug.cgi?id=1322485 (session managers-6APIs, fixed FF58) https://bugzilla.mozilla.org/show_bug.cgi?id=1322060 (session managers-6APIs, fixed FF57)

http://forums.mozillazine.org/viewtopic.php?p=14762057#p14762057 http://forums.mozillazine.org/viewtopic.php?p=14772668#p14772668 http://forums.mozillazine.org/viewtopic.php?p=14777435#p14777435

(3) New APIs mentioned on Tab Session Manager’s website on GitHub (https://github.com/sienori/Tab-Session-Manager/) - do you need it?: https://github.com/sienori/Tab-Session-Manager/issues/69 https://bugzilla.mozilla.org/show_bug.cgi?id=1413525

Do you need new APIs needed here? https://github.com/sienori/Tab-Session-Manager/issues/30 https://github.com/sienori/Tab-Session-Manager/issues/45 https://github.com/sienori/Tab-Session-Manager/issues/63 https://github.com/sienori/Tab-Session-Manager/issues/97 https://github.com/sienori/Tab-Session-Manager/issues/121

Are there other APIs you need? Are bugs on bugzilla.mozilla.org already filled?

With updated list of needed APIs I could contact Tim Nguyen and other people to ask Mozilla to prepare these APIs in 2018. Other people should also contact people at Mozilla to increase a chance that these APIs will be ready for you. Tim probably could also help to report properly bugs for new APIs.

[RobertAb1]

APIs mentioned on Tab Session Manager’s website on GitHub (https://github.com/sienori/Tab-Session-Manager/) – already on the list of 6 APIs above:

https://github.com/sienori/Tab-Session-Manager/issues/27 https://bugzilla.mozilla.org/show_bug.cgi?id=1381922 (session managers-6APIs, unassigned)

https://github.com/sienori/Tab-Session-Manager/issues/38 https://bugzilla.mozilla.org/show_bug.cgi?id=1322485 (session managers-6APIs, fixed FF58) ?

[RobertAb1]

https://wiki.mozilla.org/Roadmaps https://wiki.mozilla.org/Firefox/Roadmap

[RobertAb1]

https://www.reddit.com/r/firefox/comments/7dxmu4/why_firefox_had_to_kill_your_favorite_extension/drersqx/

Looks like Mozilla is planning to fix up the current session restore system at the beginning of 2018 (meta bug): https://bugzilla.mozilla.org/show_bug.cgi?id=1330633 https://bugzilla.mozilla.org/show_bug.cgi?id=1330635 https://bugzilla.mozilla.org/show_bug.cgi?id=1330638 https://bugzilla.mozilla.org/show_bug.cgi?id=450886

[ElhemEnohpi]

@RobertAb1 , thanks for your efforts on this. I hope you can continue to help move the disussion about session manager extensions forward.

Something you should know though, is that there are two very different approaches to how a session manager can work. All of the bugs and issues mentioned above - except one - are related to the first way, which is the way that all current Web Extension session managers now work. That is, they must implement their own session saving and restoring system which is completely separate and unrelated to the built-in session restore system of Firefox known as "sessionstore". There is one, bug 1413525, that's about the idea of allowing Web Extensions to use, in a limited way, the built-in sessionstore, which is much closer to how the old Session Manager addon worked. If that were possible, then none of the other APIs would be necessary.

When people write, "this is the list of APIs required by (Michael Kraft / morac's) Session Manager", it's really not true - and it's not something that he said himself, he stopped commenting in the forum long ago. Session Manager directly used the internal sessionstore API of Firefox. With Web Extensions, that's no longer possible, and never will be. That list represents (only some of) the API functions that would be needed if Session Manager had to be re-written to do all the session managment on its own like Tab Session Manager does, instead of using the built-in sessionstore like it used to. It's not at all like the old Session Manager could simply start working again if the listed APIs were provided - it would be a very extensive re-write, and even then, it would be missing numerous things. I'm not sure, but I think he's just not interested in doing that, and has given up on Session Manager.

Web Extensions don't have direct access to the "real" session used by Firefox, which is saved in the "sessionstore.js" file. Web Extensions have an API to put data into that "real" session, and read it out after a session is restored by Firefox. But they can't use the built-in sessionstore functions to actually cause a session to be saved or restored. For that reason, any work being done by Mozilla on the built-in sessionstore system, as you have listed in https://github.com/sienori/Tab-Session-Manager/issues/131#issuecomment-353248295 above, has nothing to do with Web Extension-based session managers like Tab Session Manager, because they are not allowed to use sessionstore.

There are many limitations to this approach. For example, Web Extensions are currently not allowed access to certain kinds of data, such as getting and setting a tab's history, so the developer can't write the code to do that for his sessions. That's why you see these requests, like in your list of the six bugs above: "Mozilla, please allow us to access back/forward history, to open tabs in "unloaded" (discarded) state, etc". Each of these APIs has to be approved and implemented by Mozilla, and then has to be incorporated into the WE session manager's code. The ability to read and set tabs' histories for example has not been approved, and nobody is working on it.

Even if all the above APIs were approved and implemented, a big limitation is that, if other extensions store data in the built-in session, then every session manager Web Extension has to support each of these separately for its own session system. For example, Tree Style Tab saves its tree structure to the built-in Firefox session, so it automatically gets restored if you use "show my windows and tabs from last time". But Tab Session Manager had to add its own special code to communicate with Tree Style Tab, so that it could also read, save, and restore the tree structure inside its own separate saved sessions system. And it would have to do this, to add special code, to support every different Web Extension that might save data in the built-in session, in order for that data to be restored.

So that's the current state of Web Extensions based session managers. Now we come to the second approach: allow Web Extensions to use the built-in sessionstore system to save and restore sessions. This is what is requested in bug 1413525. It wouldn't allow full access to use the internal sessionstore system, like Session Manager used to have, so it also wouldn't allow Session Manager to just start working again. But the idea is to provide an API to allow Web Extensions at least in some limited way, to restore the "real" sessions managed by Firefox, using the same mechanisms that Firefox does. It's not yet been decided if this will be supported, and if so, how it would work. It's still in the very early stage of discussion. But it would be a fundamentally and completely different way for session manager Web Extensions to work, as they would not have to duplicate all the functions of the built-in session manager with their own separate systems the way they do now. It would also mean that it's based on the session management code inside of Firefox, which has a team of paid developers working on it, making it more robust and reliable.

To use this approach, totally new session manager extensions would need to be written. It's not something that could simply be added on to Tab Session Manager for example, because it represents an entirely different method and system of working. Tab Session Manager would need to be almost completely re-written - though that might not be too difficult, because this system would make session manager extensions much simpler to write. In my opinion, this would be the best way forward for the future of session managers, and would make all the current session managers, including Tab Session Manager, obsolete.

As I said, this is still only in a very early stage of discussion. I'm not sure what these statements are based on:

APIs for session managers are now in the planning stage (for 2018) at Mozilla ... Mike Conca gave the following response "... and session manager API are on the roadmap."

I don't see any evidence for that. There's nothing on the roadmaps or planning specifically about session manager extensions, other than just the general idea that new APIs for Web Extensions will continue to be added in the future as needed by priority. For example, the bug for an API for current session managers to save and restore tab history is marked as low-priority, has not been approved, and has nobody working on it.

The same goes for an API to allow the use of built-in sessionstore. Even if the idea is approved, it would be a fair amount of work to implement, and would likely require Mozilla to assign a paid developer to work on it. At the moment there's no indication of any plans for that, so it's probably at least many months before it would be realized, if ever. In the meantime, it's still worthwhile discussing what API functions current session managers like Tab Session Manager would need, such as the ability to restore tab history, since it's possible that the other approach will never happen.

You asked whether new APIs were needed by Tab Session Manager, for issues 30, 45, 63, 97, and 121. As far as I can see, no. Because Tab Session Manager uses its own system of sessions, unrelated to Firefox sessions, all of these feature requests would have to be implemented within Tab Session Manager's code. 63 talks about a Tools menu entry, but actually I think that's not needed, as the issue is really about improving the UI, which can be done in a different way. The exception could be 97, allow sync with Dropbox, but I'm not sure, I didn't look at it that closely.

For issue 69, "save window positions", you have bug 1413525 listed, but that's the one about using Firefox's sessionstore do the restoring. Tab Session Manager would need a different API, for Web Extensions to be allowed to get and set window positions. I'm not sure if that's possible or not, maybe the Window API could be used: https://developer.mozilla.org/en-US/docs/Web/API/Window

[RobertAb1]

@ElhemEnohpi

Thank you for you response. I posted this information, because I am trying to speed up the discussion about session managers (not only Michael Kraft's Session Manager, but also Tab Session Manager, MySessions or Tab Mix Plus session manager). State of discussion seems currently not at very advanced state also on Mozilla side.

Recently, I have also started API voting campaign with more APIs/bugs (and I need more APIs/bugs added to that list): https://www.reddit.com/r/firefox/comments/7m8nvx/can_session_manager_tab_session_manager_coexist/drslt43/ MySessions developer (Alexandr Balyaev) also placed this API list on MySessions website (https://addons.mozilla.org/en-US/firefox/addon/my-sessions/ in the section: About the extensions). There is long list of bugs (>100) related to session restoration system which could also be helpful for session managers: https://mzl.la/2DihlMG It would be great if you and session manager developers could check this list for the most important bugs in the context of session manager development. Please, let me know about these APIs so I could add them to the list for voting.

[ElhemEnohpi]

Recently, I have also started voting campaign with more APIs/bugs:

Could you please add a notice that people should vote for the bugs, but not comment, unless they have specific information that will help to resolve the bug? There have been many "me too" advocacy comments lately in these bugs, which is against the rules, annoying for the Firefox developers, and may lead to peoples' Bugzilla accounts being suspended. Please see the Bugzilla Etiquette page.

I think your list can be confusing for people. You have listed under "APIs needed by Session Manager, Tab Session Manager, MySessions, Tab Mix Plus and other session managers", the following: "Bug 1235231 - Sessions restore windows in random order" "Bug 1407486 - no way to configure Firefox to automatically restore sessions" "Bug 1427007 - Firefox can't autosave correctly session on browser exit (the list of tabs and their state) (sometimes)"

But none of those are relevant to any session manager Web Extension, like Tab Session Manager or MySessions. Web Extensions don't use Firefox's Session Restore system, aka sessionstore. All session manager Web Extensions currently must implement their own private system of sessions, completely independent and unrelated to Session Restore. They are not able to use Session Restore in any way.

There is long list of bugs related to session restoration system which I could also be helpful for session managers:

Again, nearly all of those bugs are related to the Session Restore component, which has no connection to any session manager Web Extensions.

It would be great if you could check this list for the most important bugs in the context of session manager development. Please, let me know about these APIs so I could add them to the list for voting.

In my opinion, none of those bugs are important, except bug 1413525, to provide an API allowing new Web Extensions to be written that could make use of the Session Restore system to provide session managment features, for the reasons I noted above. If that happens, then no other APIs should be necessary, because Session Restore can already do those things like restore tab history, window position, restore tabs in the background (unloaded/discarded) and so on. At that point, all current session manager Web Extensions will be obsolete.

[RobertAb1]

I added a notice about voting but not commenting. Fortunately, there was no "me too" advocacy comments for the time this voting was taking place.

Bug 1407486 - see this comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1407486#c11 https://www.mozdev.org/bugs/show_bug.cgi?id=26384#c6

I will keep system restoration system bugs (but with moving Bugs 1235231 & 1427007 to part with system restoration). Also I experienced constantly this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1235231 even with pre-Quantum versions of Firefox with Session Manager installed so will be nice if finally will be fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1235231#c16

[ElhemEnohpi]

[edit: the above comment was edited after I replied to it] I don't know what the purpose of Graham Perrin's comments in bug 1407486 about Session Manager were. There's no reason for a Web Extension based session manager to need an API to force automatic session restore by the built-in Firefox Session Restore. The Web Extension uses its own independent system of session restore. The function is already added to Tab Session Manager in #118. So that API isn't required by any current session manager. If Web Extensions get an API that makes use of Session Restore, then they will be able to control the restoring of sessions as they like. So that API isn't required by any future session manager either. [edit: I suppose this could be useful for eg. Tab Session Manager to force built-in auto-restore off, if it's taking care of it in its own way. On the other hand, it seems like a potential for problems, with conflicts between different extensions trying to set the preference. Extensions of the type described in the bug might try to force auto-restore on, if that's what they need to function, without considering that Tab Session Manager is taking care of that, and needs the pref off. I think it would be better to just inform the user about it and let them set it manually. But it's already been approved, so I guess it will be implemented eventually.]

Also I experienced this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1235231 even with pre-Quantum versions of Firefox with Session Manager installed

That's a bug in the Firefox Session Restore component. You experienced it because Session Manager used Session Restore. Web Extensions don't use Session Restore.

[RobertAb1]

bug 1407486: What is about situation with two session managers? Tab Mix Plus automatically was turning off its session manager functionality if Session Manager was present. Could be this bug fix helpful here?

[ElhemEnohpi]

No. [edit: see comment above]

[RobertAb1]

Can you check these bugs? What do you think about them? https://bugzilla.mozilla.org/show_bug.cgi?id=1408575 https://bugzilla.mozilla.org/show_bug.cgi?id=1308059 https://bugzilla.mozilla.org/show_bug.cgi?id=1399147 https://bugzilla.mozilla.org/show_bug.cgi?id=1411603 https://bugzilla.mozilla.org/show_bug.cgi?id=1364019 https://bugzilla.mozilla.org/show_bug.cgi?id=1307759

It looks like some of them has similar status like previously discussed https://bugzilla.mozilla.org/show_bug.cgi?id=1407486

[ElhemEnohpi]

https://bugzilla.mozilla.org/show_bug.cgi?id=1408575 https://bugzilla.mozilla.org/show_bug.cgi?id=1364019

These are about bugs or issues with the existing API for opening "recently closed tabs/windows", which is not really something a session manager needs to do, though it could since the API is there. On the other hand, the list of recently closed tabs and windows is yet another thing that web extensions like Tab Session Manager can't save and restore, and would require a new API for.

https://bugzilla.mozilla.org/show_bug.cgi?id=1308059 https://bugzilla.mozilla.org/show_bug.cgi?id=1399147

These are about tabs that are synchronized with other devices through a Firefox account. I've never done that, I don't know what might be necessary for a session manager to deal with.

https://bugzilla.mozilla.org/show_bug.cgi?id=1411603

This is to know when Firefox has finished restoring a session with Session Restore. Since Session Restore isn't used by Web Extensions based session managers, it's not relevant.

https://bugzilla.mozilla.org/show_bug.cgi?id=1307759

This has to do with bugs in the existing API for maximizing/minimizing windows. I think a session manager Web Extension should be able to use this API to get, save, and restore window positions, but I'm not sure.

Sorry, I won't be able to go through any more of these bug reports. As I said, I think the approach of a Web Extension having APIs for get/set access to all these different things is just a bad idea. There should be one API for limited access to the Session Restore system, which can already do all that without the privacy and security issues of giving Web Extensions such full access.

[RobertAb1]

Thank you.

I have added 3 bugs: 1307759, 1408575, 1364019. This is new list of API/bugs for session managers and Firefox session restoration system: https://www.reddit.com/r/firefox/comments/7m8nvx/can_session_manager_tab_session_manager_coexist/drslt43/

[ElhemEnohpi]

[edit: the above comment was edited after I replied to it] I certainly did not recommend those bugs! Please remove them from the list.

As I understand, you are looking for cases where a new API is needed for Tab Session Manager and similar extensions. Do you understand what an API is? None of those bugs has anything to do with requesting a new API! If you want to encourage people to go and vote for random bugs, you can, but I don't see how it helps...

For Tab Session Manager to support saving and restoring the list of recently closed windows and tabs, I think it needs a new API. As far as I know, nobody here has requested that feature, and there's no bug filed requesting such an API, so you'd have to do that yourself. Bugs 1408575 and 1364019 are about things that are broken with the already-existing API and internal code for re-opening recently closed tabs while the browser is still open. Tab Session Manager doesn't use that API, so they are irrelevant.

For Tab Session Manager to support saving and restoring window positions (issue #69), it needs an API. I think it can maybe use the already-existing Window API. Bug 1307759 is about some obscure bug in that API and internal code, which probably doesn't affect anyone noticeably - people shouldn't be voting for bugs unless they are really a problem for them.

You should also remove bug 1407486 from the list. Even though it is about requesting a new API, that API is not relevant for Tab Session Manager or any other session manager extension.

[RobertAb1]

So to be clear. You are recommending removing bugs 1408575, 1364019, 1307759 and 1407486, am I correct?

 

For Tab Session Manager to support saving and restoring the list of recently closed windows and tabs, I think it needs a new API. As far as I know, nobody here has requested that feature, and there's no bug filed requesting such an API, so you'd have to do that yourself.

Please, file this bug and let me know about it. Earlier this will be done, more people can vote on this one. Can you do this today or tomorrow?

For Tab Session Manager to support saving and restoring window positions (issue #69), it needs an API. I think it can maybe use the already-existing Window API.

For issue #69, "save window positions", you have bug 1413525 listed, but that's the one about using Firefox's sessionstore do the restoring. Tab Session Manager would need a different API, for Web Extensions to be allowed to get and set window positions. I'm not sure if that's possible or not, maybe the Window API could be used: https://developer.mozilla.org/en-US/docs/Web/API/Window

You are not sure about this API if it can be used to support saving and restoring window positions (issue #69). Can you check this one? Maybe we need new API here?

 

Elhem: Are other session manager functionalities which are not supported by existing or already requested APIs? I think that you know well problems people are having with Tab Session Manager and also you know available APIs. Can you go through issues on Tab Session Manager website to find problems where new API should be filed? Can you file them?

I will be nice to know also about problems which you are not sure if existing API can solve them.

If necessary provide me, please, also with already requested APIs, which I do not know about. Thanks.

[ElhemEnohpi]

So to be clear. You are recommending removing bugs 1408575, 1364019, 1307759 and 1407486, am I correct?

Yes. They're not relevant to Tab Session Manager, as far as I can tell.

Please, file this bug and let me know about it. Earlier this will be done, more people can vote on this one. Can you do this today or tomorrow? You are not sure about this API if it can be used to support saving and restoring window positions (issue #69). Can you check this one? Maybe we need new API here? Can you go through issues on Tab Session Manager website to find problems where new API should be filed? Can you file them?

No, I'm sorry, I can't put any more time into this. As I've tried to explain, I think creating all these APIs is a bad idea. Session saving and restoring should be handled by the built in Session Restore component. There's only one API needed for that, which is already being discussed in bug 1413525. When that happens, then probably Tab Session Manager will be obsolete.

You're welcome to continue your project, maybe it will be helpful in case nothing comes from bug 1413525, or if it takes a long time. Good luck...

PS, when you go back and edit your comments after I've already replied to them, it can make my replies look a bit stupid...

[RobertAb1]

I have just added meta-bug for session managers:

https://bugzilla.mozilla.org/show_bug.cgi?id=1427928

It could place for discussion about needed APIs and how to implement entire system. You could explain there why you prefer bug 1413525 over others.

PS. I am sorry about that.

[nt1m]

No, I'm sorry, I can't put any more time into this. As I've tried to explain, I think creating all these APIs is a bad idea. Session saving and restoring should be handled by the built in Session Restore component. There's only one API needed for that, which is already being discussed in bug 1413525. When that happens, then probably Tab Session Manager will be obsolete.

Hmm, that seems like a terrible idea. The built-in Session Restore component is fundamentally flawed, the internals should probably not be exposed until that's cleared up (getBrowserState/setBrowserState). Mark Hammond makes a really good point that we already started exposing internals (get/setTabValue and get/setWindowValue) and it could actually badly affect performance due to the internals increasing the size of the session restore file.

Instead the approach of having individual APIs (tab history/discarding/...) is much better (but requires more work) because it gives more flexibility, and allows add-ons to not rely on the flawed Session Restore internals. Potentially, it could also allow the built-in Firefox Session Restore to be re-written from scratch exclusively using those WebExtension APIs, and become much less flawed.

[nt1m]

It would also mean that it's based on the session management code inside of Firefox, which has a team of paid developers working on it, making it more robust and reliable.

This is actually one of the most unmaintained/flawed/old parts in Firefox atm, there will be ongoing work on the next quarter to fix some quirks, but that won't fix all the design problems it currently has.

Keep in mind one of the reasons legacy add-ons were dropped is because Mozilla wants to add-ons to stop relying on their old-flawed code, so they can finally re-write and improve it.

One Mozilla developer has clearly seen the problems that the built-in Session Restore has:

• http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/
• http://blog.techno-barje.fr/post/2016/03/16/shipping-firefox-features-as-addon/

and even suggested the solution might be reimplementing it from scratch as a WebExtension for that reason.

I still believe the right approach is creating new APIs for bits of session management.

[galtgendo]

Well, one way or another, the clock is ticking: unless plans change, 2018-05-08 is when 61 (planed as the new ESR) is supposed to go beta. Would be useful if session managing extensions authors would come to an agreement and issued a joined call to Mozilla team long before that, especially with them seemingly passive aggressively discouraging any work to reimplement them post-57 (at least that's the way I perceive what happened in bug 1413525). What bothers me here most, is that this whole discussion should have happened before 57 - it's one thing to make an API break, it's quite another to do that and not provide a migration path. Might just be my personal bias, but TMP and Session manager were quite popular Firefox extensions...

[ElhemEnohpi]

Hmm, that seems like a terrible idea. The built-in Session Restore component is fundamentally flawed, the internals should probably not be exposed until that's cleared up (getBrowserState/setBrowserState).

I agree that exposing those internals, as in the original description of bug 1413525, probably isn't the best approach. But later discussion in that bug is about a different idea. What I'm talking about is a higher-level API, with relatively simple functions like "store current window/session with name abc", "restore window/session named xyz", etc., without needing to pass the session data itself through the extension. A session manager extension generally doesn't need to manipulate the session data itself, only to save and restore it atomically.

Instead, the extension deals with session ID handles and/or encrypted blobs of sessionstore files. An internal Firefox component underlying the API does the actual work of reading, saving, and restoring windows/sessions, isolating the session data from Web Extensions.

That way, each extension isn't required to carry out the process of constructing and modifying all the windows, tabs, tab histories, list of closed tabs and windows, scroll and window positions, session storage, synchronized tabs, Tree Style Tab tree structures, etc., etc., using lower-level APIs. That means we avoid having to get all those low-level things approved to be exposed to all Web Extensions, and the possible security issues with that. I think it would be quite a battle, given that we haven't even been able to get a design decision for an API to restore tab histories approved.

It also means that potentially sensitive session data can be effectively saved and restored. Extensions can write private data to the current session via get/setTabValue and get/setWindowValue, which only they can retrieve. A session manager extension like Tab Session Manager can't read that data, so can't save or restore it via its own storage. That forever rules out any possibility of a Web Extension that can fully save and restore all sessions, as well as the idea of reimplementing the built-in Session Restore as a Web Extension, using individual low-level Web Extension APIs. So continuing to pursue all those APIs is in my opinion somewhat of a futile effort.

The internal component underlying a high-level session-store API would be the same component used for built-in session restore. Whether that's based on existing Session Restore code, or needs to be built with new code, is beside the point. With a high-level API, what's under the hood can be gradually re-written, or completely replaced - that's a separate issue.

The point is you can have a session manager extension that can either fully restore sessions to their original state via a high-level API to an internal session restore component, or you can allow it to access, manipulate, and restore some quite limited set of session data on its own. I'd prefer the former, and don't see any real advantage to the latter.

[RobertAb1]

@ElhemEnohpi

Maybe you could open new bug called "Expose SessionStore.getWindowState and SessionStore.setWindowState" as a spin off of bug 1413525? https://bugzilla.mozilla.org/show_bug.cgi?id=1413525#c37

Did you see this comment? https://bugzilla.mozilla.org/show_bug.cgi?id=1413525#c39

[galtgendo]

@RobertAb1: that result was exactly what I referred to as p-a discouragement from M team. Perhaps the guy quit too early, this is Mozilla team we're talking about - people that were regularly breaking ABI for their external plugins back when they still provided an option for such plugins. On one hand maintaining ABI compatibility and retaining flexibility for internal changes is damn hard, on the other we've got today's problem.

On the other hand though, someone from the team could have been a bit more encouraging and they really should have thought about it before releasing 57.

Yet, as I've said before, the clock is ticking and chances are even the forks won't help much, as M team is likely to break something soon, that the forks won't be able to revert without breaking new functions.

[ElhemEnohpi]

I don't know why Kevin Jones quit volunteering on Mozilla bugs, I hope it's because he found something more interesting to do. But after seeing what he was working on in that bug, I don't think it was the right approach. I'm glad that the Mozilla people didn't encourage him to go ahead with it. It does seem a bit unfair that they approved the idea (after literally five minutes of discussion), got him to work on it, and then changed their minds. But hindsight is 20/20, you can't always think things through at the beginning. I do agree that they should have put more resources and thought toward this, and sooner.

The bottom line is that I want what Session Manager could do, restore my sessions to exactly the way they were when I saved them. The only approach that can work is an API where extensions can save and restore complete windows or sessions without "looking inside" them at all the potentially sensitive session data.

Any approach that relies on handing over the internal session data to the extension with read/write access is doomed to fail. The data can never be complete because it's already been decided that Web Extensions won't have access to certain things, like other extensions' private session data, due to security and privacy risks. Kevin Jones wasn't working on a session manager, just a system for recovering from crashes, and he intended to keep the list of things that can be restored "minimal". He said several times he'd be happy if it was just the URLs that were restored, nothing else. But I would definitely not be happy with that. I think it's entirely possible to allow Web Extensions to fully restore all session data like Session Manager did, without the security risks. I don't want to settle for less than that, which is what we would have got with that code.

Maybe you could open new bug called "Expose SessionStore.getWindowState and SessionStore.setWindowState" as a spin off of bug 1413525?

No, that's part of the same approach of handing over limited parts of the session data, which I now think is not the way to go.

[RobertAb1]

No, that's part of the same approach of handing over limited parts of the session data, which I now think is not the way to go.

So probably changing bug name to more broad will be good (for example, "Expose SessionStore.getBrowserState, SessionStore.setBrowserState, SessionStore.getWindowState and SessionStore.setWindowState"). On there side smaller bugs, could be placed later (after making general agreement about way to implement API) as child bugs under bug 1413525 (for partial discussions and code preparation), the same way like this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1421254 is placed.

I noticed also two small bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1422588 https://bugzilla.mozilla.org/show_bug.cgi?id=1404594 They are related to earlier bugs Kevin was working. It appears that there are some problems with them.

Kevin was working on many bugs. It looks like he was working on lazy tabs. In my opinion, this future is one of the most important for Firefox. (Chrome does not have it and great extension Native Lazy Tabs was removed from Chrome store.)

[ElhemEnohpi]

So probably changing bug name to more broad will be good (for example, "Expose SessionStore.getBrowserState, SessionStore.setBrowserState, SessionStore.getWindowState and SessionStore.setWindowState").

No, because I don't think anymore that those things should be exposed, for the reasons I explained already. It needs to be done in a different way, where a web extension can save and restore a session, without exposing the session data to the extension.

We'll just have to wait to see what happens with the discussion in that bug. We've been waiting for some input from a mozilla developer, who's an expert on the sessionstore system, who's been away for a long time. He'll be back to work next week I think.

[RobertAb1]

Looks like Mike de Boer is back.

[ooofest]

I'm no expert here, but I just want to have a list of saved sessions - with a default "active" session - for saving+ restoring at any time, including startup. Crash recovery would be enabled by such a story, because the add-on could be saving every X time period and prompt for which session to use when restarting, if desired.

No need for session management add-ons to manipulate tab states or even edit which tabs should remain in a session - a user could always load a session, remove some tabs manually and save that session if they want a custom session based on a prior one, if desired (for example).

If that session-saving/restoring add-on could invoke a set of reasonably stable APIs which abstract Firefox's own sessionstore functions and data, so that full tab states could be saved/restored for the current session and used natively by Firefox when requested via the API to load on demand, then great. That seems simplest path from my naive perspective and potentially offers enough abstraction to allow Mozilla Devs the freedom to refactor their sessionstore management code over time.

I really do appreciate sienori's work on Tab Session Manager to use WebExtensions via the only viable path available at this time, but would also like to see this made more foolproof over time. I cannot get Tab Session Manager to work with my v58 Dev Edition install at this time and it's likely due to limitations in how sienori is forced to create a parallel method for session management, outside of what Firefox is already doing internally.

[RobertAb1]

About potential conflict between session managers and other extensions working with Session Restore: https://bugzilla.mozilla.org/show_bug.cgi?id=1407486#c15

[ooofest]

Well, ElhemEnohpi is correct: there is no apparent option in the Quantum UI (perhaps it's under the hood?) to show that an add-on can have responsibility for managing restoration of window+tab states on a restart. That would seem a natural need for an add-on to register this capability, as I'm guessing Session Manager did when I installed it in pre-Quantum Firefox.

Thinking about the above discussion with respect to this item, if the API interface for session save/restore were abstracted calls which requested use of Firefox's native capabilities, it would seem more easy to manage against creation of conflicts for restores. It might also relieve the issue of not being able to reopen "about:addons" and other internal browser pages.

[RobertAb1]

Mozilla Plans for API for SESSION MANAGEMENT:

"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." (source: 2018 Firefox Roadmap [updated on 2018-04-12])