927173 - Australis: scrolling tabs into view doesn't work very well

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

Attachment: screenshot

STR:
1) Open enough tabs to get into overflow (be generous)
2) Select the first tab
3) Scroll the tab strip to the end (but don't select another tab)
4) Close the selected tab (Cmd+W)

Expected: tab closes, next tab selected and scrolled into view
Actual: tab closes, next tab selected and only a little bit of it is scrolled into view (see screenshot)

Comment 1

[:Gavin Sharp [email: [e-mail]]]

(I'm using today's UX build, Mac)

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Similar issue occurs if you manually select a new tab instead of closing the current tab (e.g. replace step 4 with "press Cmd+2 to select the second tab").

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Marking this as P5 since the comment #0 STR are pretty edge-casey and I don't think that flow is likely to be hit by many users. Comment #1 is no longer an issue since bug 875180 has been fixed.

Comment 4

[:Gijs (he/him)]

So this is caused by the fact that we set the selected tab to the next tab, but then we remove the previous tab, and so we scroll by exactly not enough, so to speak. :-)

In particular, in removeTab(), we call _blurTab(), which ends up setting the selected tab, causing us to scroll it into view. Then we remove the other tab.

What we should do is make sure that ensureElementIsVisible works irrespective of the tab animations which are in progress. However, I don't have any great ideas on how to make that happen...

The alternative would be calling ensureElementIsVisible a second time, but that's kind of sucky...

Gavin, do you have ideas, seeing as you filed this? ;-)

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Well the obvious answer is "only call ensureElementIsVisible after removing the tab", but I have no idea how feasible that is or what the constraints here are.