1644041 - Closing a tab in FF 77 leaves a spot for several seconds before the tabs are resized, other UI parts become unresponsive as well

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[MarjaE]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Closed a tab.

Actual results:

It took a long time for the other tabs to resize.

Expected results:

This was not an issue in FF76.

The resizing in general makes it harder to close a number of tabs in succession, but the delayed resizing is worse for this. It might work better to have all tabs take the same space, without resizing.

Comment 1

[MarjaE]

Attachment: Screen Recording 2020-06-08 at 1.25.31 PM.mov

Recording of the delay.

Comment 2

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

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Dão Gottwald [:dao]]

Marja, can you reproduce this problem with a new user profile? Are you able reproduce it in Firefox Nightly too?

Comment 4

[MarjaE]

Sorry, lost Firefox installation. Bug 1647375.

Comment 5

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

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[MarjaE]

Tried again, mostly rebuilt, still some work to do.

Comment 7

[MarjaE]

possible duplicate of bug 596875, but on Mac

Comment 8

[MarjaE]

After a while the buttons, url bar, and search bar all go unresponsive.

Comment 9

[Dão Gottwald [:dao]]

(In reply to MarjaE from comment #7)

possible duplicate of bug 596875, but on Mac

That's a super old bug so let's not reuse that.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Hey MarjaE,

Would you be willing to use mozregression to help us find a regression window? Or, if you're able to reproduce this reliably, a performance profile? (See: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem)

Comment 11

[MarjaE]

Thank you.

It bibisects to here:

Bug 1633635 - Make tab animations obey prefers-reduced-motion. r=jaws

https://phabricator.services.mozilla.com/D72791

Note that for safety reasons, I already use my own user css to block the tab throbbers, and use Reduce Motion.

Comment 12

[MarjaE]

Commenting out related css means the tab throbber animation still gets through, but the spacing issues go away.

I need to keep

/* Another Attempt to Remove Tab Throbbers */

.tab-throbber {display: none }

And comment out or cut

/* Close the useless Tab Bar Full, animate New Tab, from this author : http://forums.mozillazine.org/viewtopic.php?f=38&t=2282765 */
.tabbrowser-tab:not([pinned]) {
max-width: 250px !important;
min-width: 100px !important;
}
.tabbrowser-tab:not([pinned]):not([fadein]) {
max-width: 0.1px !important;
}
.closing-tabs-spacer {
width: 0 !important;
}

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Ah - so it sounds like there's a conflict with some userChrome.css customization going on here.

Hey dao, any idea why the CSS in comment 12 might conflict with the work in bug 1633635? And in particular, why it might cause the rest of the UI to become unresponsive?

Comment 14

[Dão Gottwald [:dao]]

(In reply to MarjaE from comment #12)

Commenting out related css means the tab throbber animation still gets through, but the spacing issues go away.

Bug 1431237 makes the throbber animation respect prefers-reduced-motion starting in Firefox 80.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #13)

Ah - so it sounds like there's a conflict with some userChrome.css customization going on here.

Hey dao, any idea why the CSS in comment 12 might conflict with the work in bug 1633635? And in particular, why it might cause the rest of the UI to become unresponsive?

This is likely just a side-effect from tab animations obeying prefers-reduced-motion when they would previously obey the toolkit.cosmeticAnimations.enabled pref. I.e. the problem likely existed before bug 1633635 with that pref set. While it would be interesting to understand what exactly is happening to the UI, I'm not sure it's worth to investigating further. Custom CSS can break all kinds of things, and you generally cannot assume that a CSS snipped that worked nine years ago won't break something today. Users need to be very cautious when hacking the UI like this.