Allow modifying/restoring back-forward history for each tab

NEW
Unassigned

Status

enhancement
P5
normal
2 years ago
15 days ago

People

(Reporter: ntim, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-needed] [needs-follow-up])

(Reporter)

Description

2 years ago
Spin off bug 1378651
Can we get a real description on this bug?
Flags: needinfo?(ntim.bugs)
(Reporter)

Comment 2

2 years ago
There needs to be a way to either setting/modifying/restoring each tab's back-forward history, in the context of session managers.
Flags: needinfo?(ntim.bugs)

Updated

2 years ago
Priority: -- → P5
Whiteboard: [design-decision-neeed]
(Reporter)

Updated

2 years ago
Whiteboard: [design-decision-neeed] → [design-decision-needed]
Comment hidden (me-too)
Comment hidden (me-too)

Comment 5

2 years ago
@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 ?

Comment 6

2 years ago
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.
Comment hidden (me-too)
Comment hidden (me-too)

Updated

a year ago
Severity: normal → enhancement
Comment hidden (advocacy)

Comment 10

a year ago
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/.
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (advocacy)
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.
Flags: needinfo?(mconca)
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.
Flags: needinfo?(mconca)

Comment 18

a year ago
(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?
Flags: needinfo?(mconca)
(Reporter)

Comment 19

a year ago
Yeah, it does. The general mechanism Mike is describing is probably something similar to bug 1413525.
Flags: needinfo?(mconca)

Updated

11 months ago
Product: Toolkit → WebExtensions

Updated

5 months ago
See Also: → 1378651

Updated

5 months ago
See Also: → 833791

I have another use-case here.

When uMatrix blocks a page in toto, it swaps in a 'blocked by uMatrix' page instead with a different URL. If you then tell uMatrix to allow the load and refresh, that 'blocked by uMatrix' page helpfully auto-redirects to the original destination... but it stays in the history and breaks the back button. See https://github.com/uBlockOrigin/uMatrix-issues/issues/100

There are a couple of options here, but possibly the best one (IMO) is for the extension to be able to delete its 'blocked by uMatrix' page from the back/forwards history at the same time as it navigates to the destination, which this bug's feature would allow (well, if content scripts would be allowed to use it, which I think it would make sense to do).

(An alternative solution, which I don't think there's a bug for, would be something like a new privileged API to navigate to a URL and replace the current page's entry in history with the destination. But I don't know how many extensions would benefit from that, wheras being able to manipulate history could be quite generally useful.)

Updated

2 months ago
Type: enhancement → defect
(Reporter)

Updated

2 months ago
Type: defect → enhancement
You need to log in before you can comment on or make changes to this bug.