Open
Bug 1407486
Opened 7 years ago
Updated 2 years ago
no way to configure Firefox to automatically restore sessions
Categories
(WebExtensions :: General, enhancement, P5)
WebExtensions
General
Tracking
(Not tracked)
NEW
People
(Reporter: dietrich, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Whiteboard: [design-decision-approved])
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•7 years ago
|
||
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•7 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.
Comment 3•7 years ago
|
||
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•7 years ago
|
||
(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•7 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.
Comment 6•7 years ago
|
||
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•7 years ago
|
||
(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)
Comment 8•7 years ago
|
||
(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)
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•7 years ago
|
||
It's about letting add-ons set that option for the user, to provide a more useful and complete experience.
Updated•7 years ago
|
Severity: normal → enhancement
status-firefox57:
--- → wontfix
Priority: -- → P5
Whiteboard: [design-decision-needed]
Comment 11•7 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•7 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).
Comment 13•7 years ago
|
||
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•7 years ago
|
Flags: needinfo?(amckay)
Comment 14•7 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]
Comment 15•7 years ago
|
||
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•7 years ago
|
||
(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•7 years ago
|
||
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•7 years ago
|
||
(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•6 years ago
|
Product: Toolkit → WebExtensions
Updated•6 years ago
|
Blocks: Session_managers
Updated•6 years ago
|
status-firefox57:
wontfix → ---
No longer blocks: Session_managers
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•