User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Expected results:

It takes a very long time to close tabs which are hidden, if you have a lot of them.
Although it would be very easy to give an option "Close all hidden tabs" somewhere, it would already mean a lot to just offer an "x" close button at the right side of each tab item in the new Tab Manager being worked on here (https://bugzilla.mozilla.org/show_bug.cgi?id=324227).
This comes from my personal frustration mentioned here:
https://support.mozilla.org/en-US/questions/1279465
But I suspect it's gonna be better for more users, if not even a default expected behavior.

Closing all hidden/overflowing tabs can already be done via right-clicking last visible tab on the tab bar and choosing Close Multiple Tabs => Close Tabs To Right.
IMHO, remaining issue is having Close button on each tab item. Bug 618791 is a dup of this one.

https://hg.mozilla.org/mozilla-central/rev/df28e8348fcd

Release Note Request (optional, but appreciated)
[Why is this notable]: Users previously needed to know to middle-click tabs in the tab manager to close them; now there's a close button to accomplish this
[Affects Firefox for Android]: No
[Suggested wording]: The tab manager dropdown now features close buttons, so you can close tabs more quickly
[Links (documentation, blog post, etc)]: n/a

Thanks, added to the beta release notes. Leaving the relnote nomination to track inclusion in the final release notes.

This just landed for me in Firefox Developer Edition. On macOS, the »close« buttons seem to have an extreme performance impact.

I have about 150 tabs open. When I open the tab manager with the new close buttons, both scrolling the menu as well as hovering over the individual items now has a noticeable and very annoying lag. This didn't happen before close buttons were added.

I can open a new ticket for this issue if it's more appropriate?

(In reply to Joachim Kuebart from comment #8)

This just landed for me in Firefox Developer Edition. On macOS, the »close« buttons seem to have an extreme performance impact.

I have about 150 tabs open. When I open the tab manager with the new close buttons, both scrolling the menu as well as hovering over the individual items now has a noticeable and very annoying lag. This didn't happen before close buttons were added.

I can open a new ticket for this issue if it's more appropriate?

Hi! Thanks for raising this concern. There's a related bug 1820171 for improving the performance of the tab manager you may want to watch.

(In reply to Cieara Meador [:cmkm] from comment #9)

(In reply to Joachim Kuebart from comment #8)
Hi! Thanks for raising this concern. There's a related bug 1820171 for improving the performance of the tab manager you may want to watch.

Thanks Cieara, that one isn't specifically about the new close buttons, but it sounds like the proposed solution with content-visibility would indeed also address this.. so I'll hope to be able to get and test this soon! ;-)

(In reply to Joachim Kuebart from comment #10)

(In reply to Cieara Meador [:cmkm] from comment #9)

(In reply to Joachim Kuebart from comment #8)
Hi! Thanks for raising this concern. There's a related bug 1820171 for improving the performance of the tab manager you may want to watch.

Thanks Cieara, that one isn't specifically about the new close buttons, but it sounds like the proposed solution with content-visibility would indeed also address this.. so I'll hope to be able to get and test this soon! ;-)

Thanks for following up! If it's possible, it would also be super helpful if you'd be willing to share a profile. You can find instructions to do this here.

(In reply to Cieara Meador [:cmkm] from comment #11)

(In reply to Joachim Kuebart from comment #10)

(In reply to Cieara Meador [:cmkm] from comment #9)

(In reply to Joachim Kuebart from comment #8)
Hi! Thanks for raising this concern. There's a related bug 1820171 for improving the performance of the tab manager you may want to watch.

Thanks Cieara, that one isn't specifically about the new close buttons, but it sounds like the proposed solution with content-visibility would indeed also address this.. so I'll hope to be able to get and test this soon! ;-)

Thanks for following up! If it's possible, it would also be super helpful if you'd be willing to share a profile. You can find instructions to do this here.

Here's the profile with 114.0b9 which is snappy: https://share.firefox.dev/435bK87
Here's the profile with 115.0b9 which is slow: https://share.firefox.dev/44oT3gK

The activities in both cases were: start profile, open tab manager, scroll around a little, close tab manager, stop profile.

At first glance, Graphics -> Other spikes from 941 (on 114.0b9) to 4823 (on 115.0b9) which seems to be the biggest concern.

(In reply to Joachim Kuebart from comment #12)

(In reply to Cieara Meador [:cmkm] from comment #11)

(In reply to Joachim Kuebart from comment #10)

(In reply to Cieara Meador [:cmkm] from comment #9)

(In reply to Joachim Kuebart from comment #8)
Hi! Thanks for raising this concern. There's a related bug 1820171 for improving the performance of the tab manager you may want to watch.

Thanks Cieara, that one isn't specifically about the new close buttons, but it sounds like the proposed solution with content-visibility would indeed also address this.. so I'll hope to be able to get and test this soon! ;-)

Thanks for following up! If it's possible, it would also be super helpful if you'd be willing to share a profile. You can find instructions to do this here.

Here's the profile with 114.0b9 which is snappy: https://share.firefox.dev/435bK87
Here's the profile with 115.0b9 which is slow: https://share.firefox.dev/44oT3gK

The activities in both cases were: start profile, open tab manager, scroll around a little, close tab manager, stop profile.

At first glance, Graphics -> Other spikes from 941 (on 114.0b9) to 4823 (on 115.0b9) which seems to be the biggest concern.

In 115, an mozilla::nsDisplayOpacity::Paint() call shows up inside mozilla::nsDisplayList::Paint() which wasn't visible in 114.

Inside nsDisplayOpacity::Paint(), most of the time is taken by blit_row_s32a_blend() inside DrawTargetSkia, SkCanvas, SkBaseDevice, SkBitmapDevice, SkDraw, Sprite_D32_S32.

Thanks, Joachim. Your profiles are consistent with the ones gathered in bug 1839037, where we think we addressed this. The patches for that fix landed in Nightly, and an uplift request for Firefox 115 is underway.

Now on Developer Edition 116.0b1 and I can confirm that the performance problem is solved. Thank you!