How to make "Reopen Closed Tab" actually reopen closed tabs again?
Up until Firefox 116, Reopen Closed Tab (Ctrl+Shift+T) would reopen closed tabs, and Reopen Closed Window (Ctrl+Shift+N) would reopen closed windows. There was a clear bifurcation, so I could freely close windows and not worry about it polluting my tab history in another window.
The latest change has thrown out that advantage, and now Reopen Closed Tab reopens both tabs and windows, while Reopen Closed Window still just reopens windows. This makes the later essentially useless and the former much more difficult to use for me.
I assume this was done to just continue copying Chrome in all respects since that's how it handles it, but the changelog just vaguely states, "This change is in anticipation of upcoming changes to recently closed tabs."
Does anyone know if there's a setting to separate the two functions again?
Gekozen oplossing
First of all, I completely missed this change.
This has been a pain point for Chrome users switching to Firefox who thought Firefox had no feature to restore a closed window, so I agree that their needs probably drove this, more than comments from long time Firefox users. (Also, if you've ever tried to explain the difference between a tab and a window to someone on a forum, it may surprise you to know that many people do not get it.)
As far as I can tell, this change doesn't affect either:
- right-click any tab > Reopen Closed Tab
- (menu bar/button) > History > Recently Closed Tabs
But I understand you are used to the keyboard shortcut, and its the keyboard shortcut that now uses a different queue that appears to be purely chronological (not separated by window).
When I examine the source code, it seems that the legacy command
<command id="History:UndoCloseTab" oncommand="undoCloseTab();" data-l10n-args='{"tabCount": 1}'/>)
is still in Firefox, but the keyboard shortcut was reassigned to a new command
<command id="History:RestoreLastClosedTabOrWindowOrSession" oncommand="restoreLastClosedTabOrWindowOrSession();"/>
instead.
Unfortunately, Firefox does not have a feature to repurpose built-in keyboard shortcuts.
What can you do about this:
(1) Advocate for a preference to revert the shortcut to the old behavior.
I don't think this would be a heavy lift for the developers, but there is a bit of an allergy to adding new preferences because each one increases the testing burden for every build. If the community feels strongly enough, and someone steps up to code it, it could happen within a couple of months.
Not sure whether the Connect site would get speedy results. Maybe file a bug? https://bugzilla.mozilla.org/
(2) Advocate for a general keyboard shortcut customization feature.
This is nowhere near approval to proceed, but you can give it a thumbs up on Connect: Customizable hotkeys.
(3) Find an add-on that can do it.
Some keyboard shortcuts (like Ctrl+B for toggling the Bookmarks Sidebar) can be intercepted and replaced by web page scripts, while some cannot (like Ctrl+W for close tab).
In this case, Ctrl+Shift+T can be blocked by a page script, but then I don't know whether an add-on can assign it back to the old command. It might be worth testing one of the general purpose key switchers to see whether they can do it:
- Saka Key: https://addons.mozilla.org/firefox/addon/saka-key/
- Shortkeys: https://addons.mozilla.org/firefox/addon/shortkeys/
Please be aware that in order to inject their script into every site, they require all access permissions. They don't have the best reviews; maybe someone will make a dedicated one?
(4) Use an unsupported startup script solution.
As an example, when Ctrl+Shift+B was changed from opening the stand-alone library window to toggling the display of the Bookmarks Toolbar, a Reddit user posted a startup (Autoconfig) script that switched it back:
Restore Ctrl+Shift+B = Library by setting config.js
This is more of an advanced level of browser h*cking; I have a page about it on my site here: https://www.userchrome.org/what-is-userchrome-js.html.
Just to be clear, that is beyond the normal scope of this site, and while you might get some suggestions here, you may have better luck reaching out to the wizards on https://www.reddit.com/r/FirefoxCSS/ for assistance (while that site is more focused on style modification, there are some overlaps).
Dit antwoord in context lezen 👍 3Alle antwoorden (6)
Install an extension like Tab Uncloser and customize the keyboard shortcut.
Hmm...just tried it, and nope, this change broke that extension too. It also now reopens windows instead of the local tabs.
Dropa said
I never had that issue with either Windows or Firefox using those key combo. I think something is going on or a userChrome.css was installed causing the hotkey confusion here. And using 116.0.2 right now.
userChrome.css can't change keyboard shortcuts at all. Are you saying they still work separately for you or that Ctrl + Shift + T was always combined for you? It's listed as a change in the changelog, but it just seems like a major step backwards for usability.
Gekozen oplossing
First of all, I completely missed this change.
This has been a pain point for Chrome users switching to Firefox who thought Firefox had no feature to restore a closed window, so I agree that their needs probably drove this, more than comments from long time Firefox users. (Also, if you've ever tried to explain the difference between a tab and a window to someone on a forum, it may surprise you to know that many people do not get it.)
As far as I can tell, this change doesn't affect either:
- right-click any tab > Reopen Closed Tab
- (menu bar/button) > History > Recently Closed Tabs
But I understand you are used to the keyboard shortcut, and its the keyboard shortcut that now uses a different queue that appears to be purely chronological (not separated by window).
When I examine the source code, it seems that the legacy command
<command id="History:UndoCloseTab" oncommand="undoCloseTab();" data-l10n-args='{"tabCount": 1}'/>)
is still in Firefox, but the keyboard shortcut was reassigned to a new command
<command id="History:RestoreLastClosedTabOrWindowOrSession" oncommand="restoreLastClosedTabOrWindowOrSession();"/>
instead.
Unfortunately, Firefox does not have a feature to repurpose built-in keyboard shortcuts.
What can you do about this:
(1) Advocate for a preference to revert the shortcut to the old behavior.
I don't think this would be a heavy lift for the developers, but there is a bit of an allergy to adding new preferences because each one increases the testing burden for every build. If the community feels strongly enough, and someone steps up to code it, it could happen within a couple of months.
Not sure whether the Connect site would get speedy results. Maybe file a bug? https://bugzilla.mozilla.org/
(2) Advocate for a general keyboard shortcut customization feature.
This is nowhere near approval to proceed, but you can give it a thumbs up on Connect: Customizable hotkeys.
(3) Find an add-on that can do it.
Some keyboard shortcuts (like Ctrl+B for toggling the Bookmarks Sidebar) can be intercepted and replaced by web page scripts, while some cannot (like Ctrl+W for close tab).
In this case, Ctrl+Shift+T can be blocked by a page script, but then I don't know whether an add-on can assign it back to the old command. It might be worth testing one of the general purpose key switchers to see whether they can do it:
- Saka Key: https://addons.mozilla.org/firefox/addon/saka-key/
- Shortkeys: https://addons.mozilla.org/firefox/addon/shortkeys/
Please be aware that in order to inject their script into every site, they require all access permissions. They don't have the best reviews; maybe someone will make a dedicated one?
(4) Use an unsupported startup script solution.
As an example, when Ctrl+Shift+B was changed from opening the stand-alone library window to toggling the display of the Bookmarks Toolbar, a Reddit user posted a startup (Autoconfig) script that switched it back:
Restore Ctrl+Shift+B = Library by setting config.js
This is more of an advanced level of browser h*cking; I have a page about it on my site here: https://www.userchrome.org/what-is-userchrome-js.html.
Just to be clear, that is beyond the normal scope of this site, and while you might get some suggestions here, you may have better luck reaching out to the wizards on https://www.reddit.com/r/FirefoxCSS/ for assistance (while that site is more focused on style modification, there are some overlaps).
I, too share the opinion that the update to this feature was haphazard.
I wrote about it here, but it seems that is not an active forum: https://discourse.mozilla.org/t/can-ffs-superb-reopen-tab-reopen-closed-window-logic-be-restored-please/123181 No response apart from being liked by the maker of https://addons.mozilla.org/en-US/firefox/addon/winger/
I also opened a bug report to ask for a setting, but got sidetracked and not it's closed: https://bugzilla.mozilla.org/show_bug.cgi?id=1857205
Apart from the superiority of the previous implementation for pro users the current solution also makes tabs unrecoverable (via shortcut) as soon as you have recently closed tabs from a mix of different windows.
Did you already take further action, @mminer237 ? I tried contacting the UX designer and engineer involved in the original feature change ticket but no success.
This is so frustrating, It is really impacting my productivity. I'd love to form a common plan of action.
I don't believe this feature will be reverted, and apart from requesting I see another sufficient solution (for Mac users at least): Offer separate Menu Commands for the strict and mixed functionality, which users can map shortcuts to on their own.
Bewerkt door FF__Fan op
jscher2000 - Support Volunteer said
First of all, I completely missed this change. This has been a pain point for Chrome users switching to Firefox who thought Firefox had no feature to restore a closed window, so I agree that their needs probably drove this, more than comments from long time Firefox users.
I suspect you've hit the nail on the head here. I had noticed that Chrome handled tab/window restoration differently from Firefox.
Ironically, this change is one of the things that may drive me to Chrome from Firefox...