no way to configure Firefox to automatically restore sessions

NEW
Unassigned

Status

enhancement
P5
normal
2 years ago
27 days ago

People

(Reporter: dietrich, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-approved])

Reporter

Description

2 years ago
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.
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…
Reporter

Comment 2

2 years ago
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.
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…
(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. :)
Reporter

Comment 5

2 years ago
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.
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
(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.
Flags: needinfo?(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.
Flags: needinfo?(bwinton)

Comment 9

2 years ago
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?
It's about letting add-ons set that option for the user, to provide a more useful and complete experience.

Updated

2 years ago
Severity: normal → enhancement
Priority: -- → P5
Whiteboard: [design-decision-needed]

Comment 11

2 years ago
Cross reference, for Session Manager: 

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

Comment 12

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

The mozdev bug is NEW (_not_ verified fixed).
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

Updated

2 years ago
Flags: needinfo?(amckay)

Comment 14

2 years ago
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.
Flags: needinfo?(amckay)
Whiteboard: [design-decision-needed] → [design-decision-approved]

Updated

2 years ago
Depends on: 1413306

Comment 15

Last year
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?
(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

Last year
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

Last year
(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".

Updated

Last year
Product: Toolkit → WebExtensions

Updated

11 months ago
Blocks: 1476144

Updated

11 months ago
No longer blocks: Session_managers
You need to log in before you can comment on or make changes to this bug.