1470690 - All Tabs list flickers before showing the set of tabs that are shown on the tab strip

Status: NEW

(Firefox :: Tabbed Browser, defect, P3)

Description

[Itiel]

Attachment: Screencast.gif

Using Windows 10 x86.

STR:
1. Using the latest Nightly, open many new tabs so the tab strip would contain about x3 its tab capacity
2. Scroll to the middle of the tab strip and select one of the tabs. Load any webpage on this tab
3. Click the All Tabs button

AR:
The list fickers before showing the set of tabs that are shown on the tab strip, and for a split second shows the first tabs on the tab strip

ER:
When clicking the All Tabs button, the popup should immediately show the displayed set of tabs on the tab strip.

This was okay in the previous implementation of the All Tabs list.

See attached.

Comment 1

[Pascal Chevrel:pascalc (PTO until April 26)]

Dao, this bug is an unassigned P2, should we re-prioritize this bug? Thanks

Comment 2

[Dão Gottwald [:dao]]

Mark, can you look into this?

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix in 63. We can still take a fix in 65 or potentially in 64.

Comment 4

[Mark Striemer [:mstriemer]]

I tried digging into this again, wasn't able to sort it all out.

The best bet seems to be to move the scroll to ViewShowing from ViewShown. This needs to be done in a `requestAnimationFrame()` as far as I can tell, I'm guessing due to when ViewShowing is called. This sort of works, but once ViewShown is called the panel has shrunk by 15px. Making some of the optional UI hidden in the XUL seems to increase that to 74px. I guess something is changing here, but I wasn't able to track it down. I can't see the panel visibly changing size during its transition to showing, so I'm not sure what's up with that.

I'll look into this more at a later date, but don't have much more time to spend right now.

Comment 5

[Pascal Chevrel:pascalc (PTO until April 26)]

Dao, this bug has been marked as a P2 since 61 (P2 = "Fix in the next release or iteration") can this be either assigned or moved to the backlog (P3) if there are no plans to fix it in 67? Thanks!

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Happy to take a patch here of course, but given that this has gotten some developer attention, and then it's had the priority set to P3 which is basically backlog, I'm marking this fix-optional again to remove it from weekly triage.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 78 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 8

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.