1407486 - no way to configure Firefox to automatically restore sessions

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[Dietrich Ayala (:dietrich)]

I'm filing this because the APIs required to build something like Tab Groups have been made a priority by the add-ons team.

A key requirement in Tab Groups was that session restore was turned on permanently.

Otherwise, you'd lose all your tabs (and therefore all your groups) every time the browser restarted.

Comment 1

[Blake Winton (:bwinton) (:☕️)]

Assuming that the API in bug 1322060 that lets us store data per-tab persists that data across sessions, I don't think we need an API to force session restore, since when the tabs get restored the data associated with them will also get restored, and Tab Groups could use that to re-construct the groups…

Comment 2

[Dietrich Ayala (:dietrich)]

Yes, I'm already using those APIs to store the data in my tab groups prototype.

(In reply to Blake Winton (:bwinton) (:☕️) from comment #1)
> since when the tabs get restored the data associated with

How do these tabs get restored?

The default in Firefox is to not restore automatically.

Comment 3

[Blake Winton (:bwinton) (:☕️)]

We have various session restore buttons around the UI. (One in the hamburger menu on recent versions, and another in the tabstrip if you flip a hidden pref.) When you click them, your session gets restored. (Did you want to check to see if the tab data also gets restored when they get clicked? I would hope they do, but it might be good to make sure…

Comment 4

[Blake Winton (:bwinton) (:☕️)]

(After a discussion with Dietrich, I agree that this should be an API, and can think of a few different use-cases for it. It shouldn't be tied to any tab-showing/hiding/sessiondata apis, but that's not what's being asked for here. :)

Comment 5

[Dietrich Ayala (:dietrich)]

Yes, this bug is solely about an API for configuring Firefox to automatically restore the session automatically after a restart.

Tab Groups, when in Firefox, worked this way because the user expectation is that the groups they've created, and the tabs they've filled them with, will persist.

There's a long history of problems stemming from us enabling users with customization options that are then lost unexpectedly: pinned tabs, sessions, tab groups being per-window. To the user it's all data loss.

So, if we're allowing these types of experiences to exist via tab curation extensions, let's allow those extensions the option to provide a lossless experience.

For the API, I'm imagining something like browser.sessions.persist(boolean) or .persist = boolean, whichever is idiomatic for the sessions APIs.

For implementation, it could probably just set the internal pref to "restart once" mode. Extensions would call it in their background script.

We'd need to figure out what happens when extensions make conflicting calls - one turns on persistence, one turns it off.

Comment 6

[Bob Silverberg [:bsilverberg]]

I think this belongs in the browserSettings API [1], rather than the sessions API. browserSettings will automatically deal with multiple extensions trying to set the same thing (the most recently installed extension wins).

What is the name of the pref in question, and why are you suggesting that the implementation set it to "restart once" mode?

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserSettings

Comment 7

[Bob Silverberg [:bsilverberg]]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #4)
> (After a discussion with Dietrich, I agree that this should be an API, and
> can think of a few different use-cases for it. It shouldn't be tied to any
> tab-showing/hiding/sessiondata apis, but that's not what's being asked for
> here. :)

Can you describe some of those use-cases? This will help with a decision of whether to implement the API or not.

Comment 8

[Blake Winton (:bwinton) (:☕️)]

(In reply to Bob Silverberg [:bsilverberg] from comment #7)
> (In reply to Blake Winton (:bwinton) (:☕️) from comment #4)
> > (After a discussion with Dietrich, I agree that this should be an API, and
> > can think of a few different use-cases for it. It shouldn't be tied to any
> > tab-showing/hiding/sessiondata apis, but that's not what's being asked for
> > here. :)
> Can you describe some of those use-cases? This will help with a decision of
> whether to implement the API or not.

As Dietrich mentioned, over the years we've had a lot of people complain about losing pinned tabs when they don't restore their session, so "PinSaver", an extension that sets it to auto-restore when you have >=1 pinned tabs, would be an interesting thing to write (and possibly test through Shield).

The previously-mentioned Tab Groups are another.

Having an Uber-Forget button which set your session to not restore on the next restart seems like it could be useful for some people.

Heck, I would be interested in seeing what the uptake was on an extension that just always restored your session. If enough people liked it, perhaps we would make that the default in the product.

Comment 9

[mirh]

How is this different from Save&Quit (from browser.showQuitWarning=true) or the "show my windows and tabs from last time" option?

Or is this about having an add-on set that in place of the user?

Comment 10

[Blake Winton (:bwinton) (:☕️)]

It's about letting add-ons set that option for the user, to provide a more useful and complete experience.

Comment 11

[Graham Perrin]

Cross reference, for Session Manager: 

Bug 26384 – Not compatible with firefox 57+?
<https://www.mozdev.org/bugs/show_bug.cgi?id=26384>

Comment 12

[Graham Perrin]

Sorry, I forgot that the `Bug …` phrase would be automatically hyperlinked. Ignore the automated strike-through. 

The mozdev bug is NEW (_not_ verified fixed).

Comment 13

[Caitlin Neiman [:caitmuenster]]

Hi Dietrich, this bug has been added to the agenda for the October 31 WebExtensions APIs triage meeting. Let us know if you or a delegate plan to attend on Vidyo or IRC! 

Here's a few things about the triage to keep in mind: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/Add-ons/Contribute/Triage
* Meeting agenda: https://docs.google.com/document/d/1qqE6fkqr-RNWaFvMpv0Z8O5FLDgQ3AT5eGdbTt7lRGg/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 14

[Andy McKay]

Seemed to people in the meeting like a good idea. We'd also need to be sure we surface this preference back up to the about:preferences page so that users can see that this change has been made. I'll file that bug and that should block on this.

Comment 15

[Elhem Enohpi]

Allowing extensions to force auto-restore on would cause conflicts with session-manager type extensions that replace the built-in auto-restore function with their own. For example, Tab Session Manager has its own method for auto-restoring the last session, which requires built-in auto-restore to be disabled. In the case of conflicts, is it only decided by "the most recently installed extension wins", or can the user manually override this in Preferences, or by some other method?

Comment 16

[Worcester12345]

(In reply to Elhem Enohpi from comment #15)
> Allowing extensions to force auto-restore on would cause conflicts with
> session-manager type extensions that replace the built-in auto-restore
> function with their own. For example, Tab Session Manager has its own method
> for auto-restoring the last session, which requires built-in auto-restore to
> be disabled. In the case of conflicts, is it only decided by "the most
> recently installed extension wins", or can the user manually override this
> in Preferences, or by some other method?

This sounds similar to the Thunderbird issue of junk mail controls. There should be a "master control" checkbox or radio button to indicate how people want sessions to be managed. All this session manager stuff needs its own space/interface, just like they did with junk mail controls.

Comment 17

[mirh]

There already is everything you need for handling that in the UI (I, for one, love more Save&Quit dialog, but that's another matter)

This bug is just about an API for add-ons to (selectively I guess?) force load (or force not-load?) a tab notwithstanding global preferences.

Comment 18

[Elhem Enohpi]

(In reply to mirh from comment #17)
> There already is everything you need for handling that in the UI

The UI presently gives only the option to "show your windows and tabs from last time", or not to. There's no way to indicate that another extension is already handling that function, so that the built-in one shouldn't be forced on by this API.

> This bug is just about an API for add-ons to (selectively I guess?) force
> load (or force not-load?) a tab notwithstanding global preferences.

It's about an API for extensions to *change* the global preference for "show your windows and tabs from last time".