Closed Bug 1891353 Opened 1 year ago Closed 1 year ago

Add config option to bring back separate shortcuts for restore tab/window

Categories

(Firefox :: Tabbed Browser, enhancement)

Firefox 124
enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: u753033, Assigned: u753033, NeedInfo)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

Close a tab in window 1.
Close window 2.
Go to restore the closed tab in window 2 via Ctrl+Shift+T keyboard shortcut.

Actual results:

Window 2 is restored.

Expected results:

Tab in window 1 should have been restored.

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Tabbed Browser
Assignee: nobody → mulej.matej
Attachment #9396536 - Attachment description: WIP: Bug 1891353 - Add config option to restore old behaviour for → Bug 1891353 - Add config option to restore old behaviour for Ctrl+Shift+T keyboard shortcut.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

I don't fully agree with the expected results here. The undo last closed action as a simple stack you pop from with ctrl+shift+t is relatively intuitive. Having a pref to change that keyboard shortcut to undo last closed tab specifically is a highly individual choice, and without some preferences UI isn't going to be discovered by most people. Each pref and behavior branch adds complexity that compounds over time, and in this case I don't think the benefit outweighs the cost, so this is not something we would want to maintain.

It might make a nice extension though. You should be able to use the session API to restore a tab if you keep an array of session ids as tabs get closed.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX

Up until a few months ago the ctrl+shift+t shirtcut did just restore the last tab. Infact I thought that the way it currently works was a bug up until a week ago.

The way it worked previously was, in my opinion, much better. If i wanted to restore a tab, I would restore a tab. If I wanted to restore a window, I would restore a window. As it works right now, if I want to restore a tab and the last action was a closed window I first have to restore the window, which takes focus, alt+tab back into the other window, and then restore the tab. To me this seems strictly worse.

Not to mention there are edge cases which make this even worse than that. For example: say I have a popup window which will auto close if the tab that spawned it is closed. Now what happens is that I try to restore the tab, the popup window is restored instead, takes focus, and then immediately closes, which means it's now on the top of the stack again...

I'm not sure why the way it worked originally was changed, and can see that the change will not be reverted, but would at the very least like an option to go back to the good old days.

(In reply to mulej.matej from comment #5)

For example: say I have a popup window which will auto close if the tab that spawned it is closed. Now what happens is that I try to restore the tab, the popup window is restored instead, takes focus, and then immediately closes, which means it's now on the top of the stack again...

Can you file a bug for this? I agree that we should try to find a way to avoid this kind of window ending up on the undo stack. If you have an example or a reduced test case that would be great.

Flags: needinfo?(mulej.matej)

This config option isn't getting accepted, huh?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: