Open Bug 1381922 Opened 3 years ago Updated 27 days ago
Allow modifying/restoring back-forward history for each tab
Spin off bug 1378651
Can we get a real description on this bug?
There needs to be a way to either setting/modifying/restoring each tab's back-forward history, in the context of session managers.
Whiteboard: [design-decision-neeed] → [design-decision-needed]
@comment 4: while I *strongly* agree with the sentiment (I consider TMP and Session Manager absolutely crucial), let's bring this back to rational level. Whenever sufficient API gets implemented, could we expect an early uplift (on near security vulnerability level of priority) if not straight to stable, then at least to beta ?
Just to confirm the value of an API to allow access to this information. Consider this use case: Using portions of the API that were not completed in the latest version, a user could use firefox as a tool, similar to word or excel. We could: - open a series of tabs and work on them over time - if we closed a tab accidentally, we could reopen the tab - if we closed a window and needed something in that window, we could reopen that window - if we had an important session, we could save it to our history for recovery later In general, this functionality makes firefox so useful, it is hard to imagine not having this functionality.
To provide more examples of the value of this feature, here are two other addons that are unrelated to session management, that I do not think can be updated without this feature. Admittedly, they do the same thing, and did not have many users, but they're a good example of the utility of a tab history API. https://addons.mozilla.org/en-US/firefox/addon/backtrack-tab-history/ and https://addons.mozilla.org/en-US/firefox/addon/tab-history/.
Hi Tim, this has been added to the agenda for the January 30, 2018 WebExtensions APIs triage meeting. Would you be able to join? Here’s a quick overview of what to expect at the triage: * 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/WebExtensions/Triage#Next_Meeting * Meeting agenda: https://docs.google.com/document/d/1x80jYXicAotNjlitY5RZDcSRpRM3lmaSHp_q4co4OEg/edit# * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
A design decision for this bug has been deferred pending a more holistic overview of session manager. Mike Conca to create a PRD.
Whiteboard: [design-decision-needed] → [design-decision-needed] [needs-follow-up]
This feature may or may not be needed, depending on how other parts of the sessionStore are exposed via the WebExtensions API. One idea is to create a simple save/load mechanism that extensions could use, rather than expose each session control point (like history) individually.
(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #17) > This feature may or may not be needed, depending on how other parts of the > sessionStore are exposed via the WebExtensions API. One idea is to create a > simple save/load mechanism that extensions could use, rather than expose > each session control point (like history) individually. Does the same applies to Bug 1378647 and Bug 1378651?
Yeah, it does. The general mechanism Mike is describing is probably something similar to bug 1413525.
You need to log in before you can comment on or make changes to this bug.