1355650 - Time loss: scrolling in tab strip doesn't work when list of all tabs is opened, therefore user has to spend a lot more time to find tab

Status: VERIFIED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[684sigma]

I have a problem with Firefox Beta 53. It also happens in Nightly 55, Beta 52. Doesn't happen in ESR 45.
Scrolling in tab strip doesn't work when list of all tabs is opened, and it causes major time loss when searching a tab.
Here's how to reproduce the bug:

1. Open 200 tabs with unique names
2. Switch to a tab near the end
3. Open the list of all tabs
4. Scroll the tab strip with mouse wheel to find a random tab

Result: Tab strip doesn't scroll
Expected: Tab strip should scroll


It's often necessary to find a tab in tab strip without switching to that tab. 
In Firefox Beta 52 and above it's at least 3 times slower than in Firefox ESR 45.

Comment 1

[684sigma]

Additional information:
It's often necessary to find a tab in tab strip without switching to that tab. I might want to mute that tab, or pin it or even close it. But after switching to that tab it can start loading and consuming memory, or it can hang the whole browser, or produce some unexpected sound. And also current position in tab strip will be lost after switching to another tab. Therefore switching to another tab is not desired.

In Firefox ESR 45 it was possible to quickly find a tab in the list of all tabs first, and then scroll tab strip to the desired place. In Firefox Beta 52 and above, user is forced, to only rely on tab strip, what means scrolling tabs with animation by 3 at a time and looking at their titles (or open the list of all tabs, find desired tab at the same speed as in ESR 45 and count exact number of tabs between current tab and desired tab in order to know how many times it's necessary to scroll the tab strip to scroll desired tab into view).

The complexity of algorithm ("to find desired tab in tab strip") in ESR 45 is O(n), and in Beta 52 it's also O(n), but with a different constant. F_45 = C_0 * (n/2) + C_1 * ((n-31)/3)
The complexity of algorithm in this case is amount of work (in seconds) to be done by human eye to achieve the goal.

F_45 = 31*C_0 + (((n-31)/2)/3) * (4*C_0)

// C_0 is amount of time necessary to move eyes down to the next line and read part of the title in the list of all tabs
// 31 is amount of tabs visible in the list of all tabs when it's opened
// (n-31)/2 is average number (expected value) of tabs that user has to check
// ((n-31)/2)/3 is average number of scrolling gestures in the list of all tabs that user has to make
// 4*C_0 is amount of time necessary to move eyes from the last visible line in the list of all tabs up two times and down two times


F_52 = 11*C_1 + (((n-11)/2)/3) * (4*C_1 + C_2)

// C_1 is amount of time necessary to move eyes left/right to the previous/next tab and read part of its title
// 11 is amount of tabs visible in the tab strip
// (n-11)/2 is average number (expected value) of tabs that user has to check
// ((n-11)/2)/3 is average number of scrolling gestures in the list of all tabs that user has to make
// 4*C_1 is amount of time necessary to move eyes from the last visible tab two times to the left and two times to the right
// C_2 is amount of time necessary to wait until animation is finished in tab strip to start reading anything

C_1 is at least 4 times greater than C_0, this result is obtained by comparing the distance of human eye movements.
C_2 is approximately equal to 3*C_0, this result is obtained by conducting an experiment, video files attached.
As a result, with a large number of tabs F_52 is significantly slower (at least 3 times slower).

Links
https://en.wikipedia.org/wiki/Computational_complexity_theory
https://en.wikipedia.org/wiki/Expected_value

Comment 2

[684sigma]

Attachment: searching tab in ESR 45, by reporter.webm

Comment 3

[684sigma]

Attachment: searching tab in Beta 52 is significantly slower, by reporter.webm

Comment 4

[684sigma]

Pay attention, if mouse is configured to scroll by 1 screen instead of 3 lines, F_52 is even more slower, because "3" should be replaced with "11", while in F_45 "3" should be replaced with "31" (make sure that you understand the course of reasoning).

Also, on my normal profile (not clear profile that you can see on the video) I have 7 pinned tabs, and only 8 tabs are visible in tab strip. So constant "11" in F_52 should be replaced with "8" - that makes F_52 even more slower.

Comment 5

[Emil Pasca [:emilpasca]]

Last good revision: 49d7fb650c9dde7cf6e4b2c7aa578a4a11e83f83 (2016-04-12)
First bad revision: 564b225d553547fe4aa9a1039278f695c9507db9 (2016-04-13)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=49d7fb650c9dde7cf6e4b2c7aa578a4a11e83f83&tochange=564b225d553547fe4aa9a1039278f695c9507db9

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Bug 982121 in that range looks plausible. Heck of a detailed report, but we also know from telemetry data that users with 200+ tabs are pretty edge case, so I'm calling this fix-optional.

Comment 7

[:Gijs (he/him)]

Just scroll the 'all tabs' popup instead.

Comment 8

[684sigma]

(In reply to :Gijs from comment #7)
> Just scroll the 'all tabs' popup instead.

Please confirm that with new design you want user to spend 3+ times more time than before.

Comment 9

[:Gijs (he/him)]

(In reply to 684sigma from comment #8)
> (In reply to :Gijs from comment #7)
> > Just scroll the 'all tabs' popup instead.
> 
> Please confirm that with new design you want user to spend 3+ times more
> time than before.

I don't think that's an accurate severity assessment of the issue here, and I don't think it should guide what happens here.

Even if one accepted that the behaviour change here is as serious as you're suggesting, it would be better to, for instance, add the tab context menus to the "show all tabs" dropdown, or find other ways (vertical / sidebar tabs, redesigned versions of tab/container grouping, encouraging use of multiple windows, ...) of allowing people with many tabs to manage their tabs better. Just keeping bizarre quirks isn't a sustainable, proper fix for the "I have a lot of tabs and I need to micromanage them" problem. It's also not a problem a lot of our users have. So yes, I'm satisfied that wontfix is an appropriate resolution here.