"maxTabPreviews":
I'd be happy without preview, if only the limit would has (or have?) gone.

(In reply to Peter from comment #12)

And, of course, the "recently used" order stays.

May I ask why this request has been degraded to the lowest priority?

There are many comments above from other users who also would welcome this change.

If an anticipated Feature Request gets discarded then it would be nice to see some further details:

• who made this decision (probably not a single person, who made the ticket change, but a smaller team made it)
• based on what reasons has his decision been made.

If there has been a formal discussion then it would be nice to see the notes of that meeting and the arguments that support this decision. Otherwise, it may look just like an "I personally don't like it, therefore I sweep it under the carpet" reaction from one single person.

By contrast, with the above details it would be clear for everybody that

• the request had been taken seriously and
• there are real reasons why the development won't happen.

Before somebody would censor this comment out: this is meant to be a constructive comment and not an offensive one. I am asking for explanations that can be useful for the future developers who decide to work on this. Based on the explanation it can be clear for them that it would be much more work than it seems to be. Or, they can think that the refusal did not take into consideration an alternative solution. Whichever happens, an explanation would help a lot. Thanks.

I think this counts as an accessibility issue so please boost it's priority. If you have to use a keyboard because of e.g. RSI issues with a mouse, then this hard limit of 6 tabs means that many tabs are unreachable. MRU is important for workflows like e..g. doing your accounts requiring a dozen tabs.

Three possible fixes that would be an improvement:

i) don't show the overlay - just focus tabs directly without the overlay - like how it works without MRU enabled. Note this is how most tabbed GUIs work so it really should be available.

ii) always show the "all tabs" button at the bottom of the overlay for more than 6 tabs. On a 4k screen, this button only appears if I have more than 48 tabs so there is a big gap between 6 and 49 that causes unreachable tabs.

iii) the overlay should scroll through all open tabs and not just cycle between the last 6. This really should have been the original minimal requirement for the feature. Until it does that, we really need to have the i) style behaviour.

I'm thinking if it would be possible to change the behavior via an extension, given that I do not see much feedback from mozilla regarding the matter.
Is there any news?
Would it be possible to override the CTRL+Tab behavior or an extension would simply create conflicts?

In the end it's simply necessary to implement a variable-length stack listing the last active tabs and cycle through that (with or without thumbnail) with CTRL+Tab or CTRL+SHIFT+Tab.
But it's sad that 95% of the code is there already implemented...... we would just need a setting to vary the arbitrary limit of 7 tabs.

I'm just not sure what's the workflow for accepting Merge-Requests and if that would be accepted by the team for a future Firefox release.

(In reply to duncan.a.woods from comment #18)

i) don't show the overlay - just focus tabs directly without the overlay - like how it works without MRU enabled. Note this is how most tabbed GUIs work so it really should be available.

This is already how ctrl+tab works by default. The overlay is only shown if you set browser.ctrlTab.sortByRecentlyUsed to true. The 7 tabs limit only applies when this pref is enabled. If you want to be able to ctrl+tab to all tabs, and you don't care about thumbnails, you can just disable this pref.

ii) always show the "all tabs" button at the bottom of the overlay for more than 6 tabs. On a 4k screen, this button only appears if I have more than 48 tabs so there is a big gap between 6 and 49 that causes unreachable tabs.

I think this has been changed, and the button does always show.

iii) the overlay should scroll through all open tabs and not just cycle between the last 6. This really should have been the original minimal requirement for the feature. Until it does that, we really need to have the i) style behaviour.

Cycling between the last 6 is the point of the panel - see the name of the pref that enables it, browser.ctrlTab.sortByRecentlyUsed. If we cycled between ALL tabs in recently used order, we would need to include an arbitrary number of thumbnails in the panel, which is an absurd concept. I have over 500 tabs open. For 500 thumbnails to even appear on the screen is impossible. For all of them to load is most likely going to cause the browser to hang and make the feature feel very unresponsive. In the ctrlTab panel code, we actually do track all tabs, we just limit the number that can be accessed because we have to limit the number of thumbnails for the feature to be practical. This isn't really any different from Ctrl+Tab on macOS or Alt+Tab on Windows, we just have a lower max limit because we don't want the panel to wrap into a big block.

By the way, there is an unrelated feature that allows you to navigate through tabs with the keyboard. You can focus tabs by simply hitting the Tab key. Shift+Tab back to the tabs and when the activate tab is focused, hit the arrow keys to switch tabs.

I suppose one possibility would be to de-couple the ctrlTab panel from the "Sort by recently used" feature. They're not necessarily connected. The problem is that the panel serves to allow the user to choose something other than the most recently used tab. Hitting ctrl + Tab + Tab allows you to choose the 2nd most recently used tab instead the 1st most recently used tab. This is essential because if the keyboard shortcut immediately switched tabs as soon as Tab is pressed (like it does when "sort by recently used" is disabled), then hitting ctrl + Tab + Tab would just return you to the tab you were originally on. The "most recently used tab" changes every time you switch tabs, so hitting the shortcut once would mean the next time you hit it, you are returned to where you started, not taken to the 2nd most recently used tab as you might have expected.

So the panel is currently essential to support this "sort by recently used" behavior. It totally changes the behavior of the Tab key — instead of switching tabs, it focuses a tab preview, and the tab itself is not selected until Ctrl is released. This is how you can avoid getting stuck in the loop of switching from tab A to tab B, back to tab A, back to tab B, and so on. If we were going to allow the "sort by recently used" behavior without a thumbnails panel (which would be necessary in order to remove the tab limit), we would need to come up with some other way to change the behavior of the Tab key, and some new UI designs to visually represent that to the users. So it's not just fixing an accessibility issue, it's effectively a new feature that requires. product management and UX design.

I rather like the way VS Code handles this. VS Code does support the "sort by recently used" behavior, but hitting ctrl+tab in VS Code does not open thumbnails (they wouldn't be particularly useful for a code editor anyway). Instead it opens a vertical dropdown where each tab is represented as a row with only its title and file path as the text. That allows an arbitrary number of rows, and the dropdown panel can actually scroll to accommodate them. Instead of Tab immediately selecting the most recently used tab, it simply focuses the row for the most recently used tab, and does not select the tab until the user releases the Ctrl key.

Dão, do you know who we could talk to about creating a new UI feature like this? A vertical ctrl+tab panel without thumbnails? It could look visually similar to the existing "all tabs" panel, but with the tabs sorted in recently used order instead of insertion order. I would be interested in working on this.

(In reply to igor.pellegrini from comment #19)

I'm thinking if it would be possible to change the behavior via an extension, given that I do not see much feedback from mozilla regarding the matter.
Is there any news?
Would it be possible to override the CTRL+Tab behavior or an extension would simply create conflicts?

It's not really practical to change this with an extension. Extensions can't override the behavior of the keyboard shortcut. The closest an extension could come would be to dynamically re-order the tabs in recently-used order. Then, if you disabled the "sort by recently used" pref, hitting Ctrl+Tab would let you navigate ALL tabs in recently-used order. But this would be pretty difficult to implement, because as I mentioned before, hitting the keyboard shortcut once would cause the recently-used order to change. You'd need some pretty "smart" logic to prevent this from annoying the user, because the recently-used order does have to change. But you don't want it to change while the user is still holding Ctrl. But you'd need some visual way to convey that the re-ordering is blocked until Ctrl is released. And extensions don't have permissions to make UI elements in the browser chrome.

In the end it's simply necessary to implement a variable-length stack listing the last active tabs and cycle through that (with or without thumbnail) with CTRL+Tab or CTRL+SHIFT+Tab.
But it's sad that 95% of the code is there already implemented...... we would just need a setting to vary the arbitrary limit of 7 tabs.

According to bug 1651310, the limit is not arbitrary. And a limit is necessary or the feature becomes quite unwieldy. Removing thumbnails might be the way to go, but thumbnails are useful to most users who don't need to ctrl+tab to more than 7 recently used tabs. So we're really talking about creating a new feature. Although most of the ctrl+tab code can be reused, new UI elements would be required, and to the best of my understanding, that isn't the kind of thing we normally do in response to bug reports, because it requires product planning and coordination with a lot of different folks.

I'm just not sure what's the workflow for accepting Merge-Requests and if that would be accepted by the team for a future Firefox release.

There's a guide on this workflow. But removing the 7-thumbnail limit certainly would not be accepted because it's likely to cause massive hangs or crashes for large tab counts. And adding a new panel without thumbnails is unlikely to be accepted without the approval of a product manager. Unfortunately it's just not a good first bug for a volunteer contribution since it's quite a large, unplanned feature.

I would be happy with something like Windows 10's alt+tab. It's multi-row and you can show 16 (maybe more?) previews at once:

https://www.windowslatest.com/wp-content/uploads/2020/11/Windows-Alt-Tab.jpg

Windows also has overflow, so you can alt+tab to 50 windows if you keep hitting Tab enough times.

On my 1920x1080 screen, the current 7 horizontal Ctrl+Tab firefox previews horizontally fits well, would be awesome to have another 2x rows which could show 21 tabs!

Shane,
Thanks for taking the time to write up your thoughts on this bug, lots of details I hadn't considered.

Campbell,
I agree completely. I understand the need to limit the number of MRU preview tabs, but always need just a few more. Something like 3 rows of 7 sounds ideal to me. Number of rows could be an option, where the default stays at the current 1x7 grid.

Windows' alt+tab is a bit of a different situation, because computing the "thumbnails" of your windows is a quicker, cheaper endeavor for a desktop window manager than computing the thumbnails of your tabs is for Firefox.

Increasing the limit to something more dynamic (like, a space-based limit instead of a simple numerical limit) seems easy enough, but not everybody is going to desire that. Showing up to three rows of 7 tabs is nice for people trying to access more tabs from ctrl+tab, but it means those with many open tabs who don't necessarily want to access unloaded tabs from the panel will need to hit Tab 14 more times to loop back to the first preview, or to reach the "List all x tabs" button.

I think 7 is the right max for this, personally. It's not the same thing as alt+tab. Alt+tab also doesn't have a button. If we were going to increase the limit further, why stop at 24? Users are still going to complain that 24 is not enough, so we're not really resolving anything. And then users are going to complain that having 24 previews makes it tedious when they only care about the first few previews. I think at that point it would just make more sense to make an unlimited tab switcher component with vertical rows like VS Code's or Windows Terminal's.

(In reply to Shane Hughes from comment #20

i) don't show the overlay - just focus tabs directly without the overlay - like how it works without MRU enabled. Note this is how most tabbed GUIs work so it really should be available.

This is already how ctrl+tab works by default. The overlay is only shown if you set browser.ctrlTab.sortByRecentlyUsed to true. The 7 tabs limit only applies when this pref is enabled. If you want to be able to ctrl+tab to all tabs, and you don't care about thumbnails, you can just disable this pref.

I believe comment #18 was saying that sacrificing thumbnails to get unlimited MRU would be an improvement. I agree. Setting browser.ctrlTab.sortByRecentlyUsed to false disables MRU tab switching. That would not be an improvement.

I think at that point it would just make more sense to make an unlimited tab switcher component with vertical rows like VS Code's or Windows Terminal's.

That would be a big improvement, IMO.

In the meantime, would it be possible for the value of maxTabPreviews to be a setting in about:config instead of hardcoded?