Extend the browserSettings.newRelatedTabPosition API to support reverse order of related tabs

REOPENED
Unassigned

Status

enhancement
P5
normal
REOPENED
Last year
3 months ago

People

(Reporter: yurivkhan, Unassigned)

Tracking

(Blocks 1 bug)

60 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

Last year
Bug 1344749 implements browserSettings.newRelatedTabPosition with support for “afterCurrent” and “endOfTabStrip”. The “afterCurrent” value actually means “after the last existing tab related to current”, so having two tabs [a][b] and middle-clicking links to [1], [2] and [3] in this order will produce [a][1][2][3][b].

Tab Mix Plus had an option to reverse the order of related tabs. The same case would produce [a][3][2][1][b]. Along with a possibility to customize tab closing to focus the preceding tab, as suggested in bug 1422509, it leads to the desirable outcome that opening several related tabs and then closing them returns focus to the original tab [a].

(Bug 1226546 should depend on this one.)

Proposal:

* Add another possible value for newRelatedTabPosition, let’s say, “immediatelyAfterCurrent”.
* Add a corresponding preference, let’s say, browser.tabs.insertRelatedImmediatelyAfterCurrent, boolean, default false.
* When insertRelatedImmediatelyAfterCurrent is true, open new related tabs at the position immediately following the current tab, regardless of any existing related tabs.

(Names subject to discussion.)

The corresponding new unrelated tab API does not need to change accordingly.
Flags: needinfo?(mconca)
Reporter

Updated

Last year
Blocks: 1344749
No longer blocks: 1344749
Depends on: 1344749
Reporter

Updated

Last year
Blocks: 1344749
No longer depends on: 1344749
Reporter

Updated

Last year
No longer blocks: 1344749
Reporter

Updated

Last year
Blocks: 1226546
The decision has been made to not pursue bug 1344749. As a dependency of that bug, this one can no longer be implemented.
Status: UNCONFIRMED → RESOLVED
Closed: Last year
Flags: needinfo?(mconca)
Resolution: --- → INVALID
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---

Updated

Last year
Blocks: 1442843
Reporter

Updated

Last year
No longer blocks: 1226546

Updated

Last year
Product: Toolkit → WebExtensions
Status: REOPENED → RESOLVED
Closed: Last year9 months ago
Resolution: --- → WONTFIX

Comment 3

8 months ago
Bug 1344749 is now verified fixed. Does that make this one feasible again?
Flags: needinfo?(mconca)
(In reply to Jack from comment #3)
> Bug 1344749 is now verified fixed. Does that make this one feasible again?

It makes this feasible again. The biggest issue is that the browser does not currently support this behavior, and I'm not aware of any plans to add that support.

I will mark this as P5 (patches accepted) and if/when Firefox supports the desired behavior (perhaps via another patch), it would be good to expose it via the WebExtensions API.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Flags: needinfo?(mconca)
Priority: -- → P5
Resolution: WONTFIX → ---
You need to log in before you can comment on or make changes to this bug.