1418178 - more than six thumbnails needed when Ctrl+Tab is used

Status: ASSIGNED

(Firefox :: Tabbed Browser, enhancement, P5)

Description

[csongor]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170903140023

Steps to reproduce:

Sample use case: 

In the beginning, I have 20 browser tabs, 19 old ones plus a particular one amongst them that I am working on. I denote it with "WORK" below. Then I google for somethings in a new tab. Then I open 10 related hits from the hit list, each of them on a new tab. Then the tab bar looks like this:

old1-old2-...-WORK-...-old19-old20-google-1-2-3-4-5-6-7-8-9-10

and the last one is in focus. 

Now I want to go back to the WORK tab. I should press Ctrl+Tab 12 times (if MRU is used, more otherwise) but Firefox only shows 6 thumbnails so I cannot go back this way.


Actual results:

Instead of Ctrl+Tabs, I have to click the tab which is hard to find and is slow as well because I have to touch the mouse.  


Expected results:

I would like to see all of the browser tabs while I am Ctrl-Tabbing so that, say, 7 is visible at a time, the actual destination in the middle and the previous/next three on both sides. 

Or, the thumbnails of the tabs should be organised in more than one row in order to show all of them on one screen.

Comment 1

[Kohei Yoshino [:kohei]]

Firefox has no ability to show tab thumbnails. If you are using any extension, please report the issue to the extension author.

Comment 2

[Krzysztof]

Reporter means thumnails on ctrl+tab, with browser.ctrlTab.previews = true. 

It is actually Firefox's feature.

Comment 3

[Anders Stedtlund]

Enhancements in this area would be most welcome. Tab Mix Plus did this with a popup list containing all the tabs for current window. That would be enough for me, though thumbnails are also nice.

Comment 4

[csongor]

I have several ideas how it could be done niceley and in a user friendly way. I am sure others also have nice ideas and I don't think Firefox should pick any of them. 

The best would be if Firefox offered an API for add-on developers so that the most committed ones can build their own ideas. 

The API should offer the following services:
- the list of the tabs with their details (domain name, full URL, time of last usage, time of opening, etc.) so that the add-on can order them
- static preview image for each tab
- dinamic preview for each tab
- access to a HTML layer that covers the browser window so that the addon can put the images there 

Once the add-on registers itself, the broser could send events to the add-on:
- Ctrl+Tab pressed (Ctrl is still down)
- Shift+Ctrl+Tab pressed (Ctrl is still down)
- Tab pressed while Ctrl is beeing pressed
- Shift+Tab pressed while Ctrl is beeing pressed
- Ctrl released

Comment 5

[Anders Stedtlund]

The preview of the tabs needs indeed to be done in a dynamic way. As it is now they overlap on a narrow screen. At least in Win7.

I agree that an API would be good. Don't know how easy that would be to provide though...

Comment 6

[Miha Psenica]

Number of tabs that show up when hitting CTRL-Tab should be customizable. Default is 6 now and it can't be changed through the about:config. I'm a heavy tab user and the increase of tabs in the list (even without previews) would be most welcome, so I voted for this improvement here in Bugzilla.

Comment 7

[oleksandrkushchak]

This feature is exactly what I am looking for, it would be much appreciated if this gets more attention.

Comment 8

[Uwe Voigt]

Also vote for this request. Users that have many tabs open would enjoy having the option to increase the maxCtrlTabs value.

Comment 9

[Bálint Czúcz]

I would also vote for this request, even a very simple (about:config) implemetation would help a lot.

Comment 10

[Anders Stedtlund]

Now this bug hopefully can get more attention as with FF63 the default behaviour has changed so that Ctrl+Tab shows tabs in recently used order.

Comment 11

[Anders Stedtlund]

The actual code seems to be here:
https://searchfox.org/mozilla-central/source/browser/base/content/browser-ctrlTab.js
Specifically this line is interesting: 
maxTabPreviews: 6
Don't know how to do changes and test though...

Comment 12

[Peter]

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

Comment 13

[Peter]

(In reply to Peter from comment #12)

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

Comment 14

[csongor]

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.

Comment 15

[Miha Psenica]

I'm also disappointed that this got pushed back without explanation or discussion. I search for the solution for this every few months and every time I stumble back to this bug I see the priority is lower. In other words, it's not taken seriously enough to ever implement.
However, if the number of tabs (6) is hardcoded, I suppose making it an about:config option wouldn't be too hard? There are many many things customizable in Firefox, but it escapes my reasoning why not this one.

Comment 16

[Eric Jacobsen]

Vote to simply allow configuration of the number of recent tabs shown on Ctrl-Tab. I use Fast Tab Switcher which is nice for searching among open tabs, but find I usually want to go back to the last 10-15 tabs and am frustrated when the one I want isn't in the most recent 6.

Comment 18

[duncan.a.woods]

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.

Comment 19

[igor.pellegrini]

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.

Comment 20

[Shane Hughes [:aminomancer]]

(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.

Comment 21

[campbell_kerr]

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!

Comment 22

[Eric Jacobsen]

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.

Comment 23

[Shane Hughes [:aminomancer]]

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.

Comment 24

[Robin A. Meade]

(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.

Comment 25

[Davi Medrade]

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

Comment 26

[Peter Lyons Kehl]

How about a computation cost & usability tradeoff: Unlimited/higher limit MRU, but with lazy/delayed thumbnails?

Current MRU Ctrl+TAB+mouseover behavior:

• Show 7 thumbnails
• Each of the 7 thumbnails with a (limited) prefix of the title
• On mouse hovered over the thumbails: Show the full title + URL.

Suggested behavior:

• Show as many thumbnail placeholders as fit on the screen, or up to a configured limit. Or unlimited, as a moving sub-range (data view) of all tabs (the sub-range having a length that fits given the space for placeholders in the current window).
• Each of the 7 thumbnails with a (limited) prefix of the title (current behavior).
• On mouse hovered over the thumbails: Show the full title + URL (current behavior) + thumbnail (new behavior).
  And, (for accessibility/RSI/keyboard preferred) show the thumbnail after "resting" at a thumbnail placeholder (positioned to/navigated to with Ctrl+TAB+TAB+TAB... or with a mouse) for a configured time.

For people with fast hardware we could even configure a more eager behavior to calculate thumbnails earlier (for example, as navigating with Ctrl+TAB-TAB..., or as a mouse is approaching a thumbnail placeholder), or calculating them always.

Comment 27

[Shane Hughes [:aminomancer]]

Attachment: Bug 1418178 - Allow users to configure ctrlTab maxTabPreviews by pref. r=dao,#desktop-theme-reviewers

Comment 28

[Shane Hughes [:aminomancer]]

Responding to a phabricator comment.

In D194909#6523357, @c21 wrote:

I'm a user, not a contributer. I came here because my FF (Mac) installation shows only 7 tabs for CTRL-TAB.
I wanted to give the feedback that I don't think you need to consider situations where users will enter "50 tabs" to toggle through. The point is rather that SEVEN is not enough. I think you could proceed like this:
take the current number that's being desplayed. At least in my case, it's 7.
Now check the vertical space of the screen: how many additional tabs could be shown?
If the user defines 9, then simply show a line of 7 plus 2 more in the second line, preferably centered so it looks better.
If the user defines 185, then limit the number by the amount per line AND the available space on the screen for additional rows, so 185 is not actually reached unless the user has a very weird super high screen ;)
You could also limit the number that can be defined, for example to 28. This would already be a huge improvement over 7.

I've chosen 49 as a limit, not necessarily because of screen space (though it does start to look ugly past a few rows), but because of performance. The thumbnails are useful for most users and can be considered an accessibility feature, but we don't want to load too many of them since this panel is also supposed to feel very responsive.

Also, I don't need those screenshots of pages. This just wastes data written to the SSD. I would appreciate an option that will just simply show the last tabs in a list with no images. (unless that option already exists).

I suspect that's more of a niche request, and it would look awkward unless we put a lot of effort into the visual presentation. I'd prefer to keep the scope of this enhancement as small as possible, since it's not really my prerogative to make big decisions about the design of the panel. Using the existing row layout means we can most likely land the enhancement sooner.

I've also said that seeing tabs in a list without previews is already the purpose of the "all tabs" menu (click the V shaped button to the right of your tabs row, or press Ctrl+Shift+Tab). There are other things that could be done to improve the "all tabs" menu for users that haven't found it useful yet. Maybe you prefer the keyboard navigation in the Ctrl+Tab panel because it sorts tabs by recently used order, whereas navigating to recent tabs in the "all tabs" menu could require tabbing through a lot of other tabs. But issues with navigating the "all tabs" menu could be resolved by enhancements to that menu, or by the implementation of a vertical tabs pane, as proposed in bug 1698376. That makes more sense to me than adding previewless rows to the Ctrl+Tab panel, whose role in the UI is largely defined by the large preview thumbnails it shows.

As for storage, thumbnails should be pretty negligible. It's just a couple megabytes for me. Compared to many gigabytes of caches, local storage, etc. We'll run into the other limiting factors first, anyway (performance and screen space). But I don't think that's a good reason to show Ctrl+Tab items without thumbnails, just a reason to place a reasonable limit on the number of Ctrl+Tab items that can be present simultaneously.

Comment 29

[Peter Lyons Kehl]

Workaround for anyone wanting more than 7 most-recently-used tabs (NOT per window, but across all windows): https://addons.mozilla.org/en-US/firefox/addon/fast-tab-switcher = https://github.com/tapapax/firefox-fts.

Comment 30

[Vagif]

wrap it. I don't care about the visuals. if y'all care, keep it pretty, but give us an option to choose the functionality over visual. just put a simple option, I don't want to modify the source code just to modify a number. the code is all there. just give me a mru with 21 max preview

Comment 32

[ciprian.tomoiaga]

Shane Hughes [:aminomancer] when could this feature be shipped ? It looks like it was almost ready 1 year ago, but then it stopped ? Seems like all reviews and approvals are there too.

Thanks ! Looking forward to shredding that Tab button ! <3

Comment 33

[Shane Hughes [:aminomancer]]

(In reply to ciprian.tomoiaga from comment #32)

Shane Hughes [:aminomancer] when could this feature be shipped ? It looks like it was almost ready 1 year ago, but then it stopped ? Seems like all reviews and approvals are there too.

Thanks ! Looking forward to shredding that Tab button ! <3

I'm just really busy with my official work (my team has other responsibilities and this was just a voluntary thing), so I haven't had an opportunity to work on it. The code is currently not approved and requires an automated test. Feel free to commandeer it if you like.