1751484 - Long restyle/reflow in parent process for browser.xhtml when entering/exiting fullscreen mode for web content (with lots of tabs)

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: sample "custom URLs" value to paste into preferences, to make your new windows have 1000 about:robots tabs

STR:

1. Open 1000 tabs. Here's one easy/reliable way to do this:
   (a) open about:preferences, "Home" section
   (b) for Homepages and New Windows, choose "Custom URLs"
   (c) In the "Paste a URL..." textfield, paste in the contents of the attached text file (which is just 1000 repetitions of about:robots|)
   (d) Open a new window. That new window will get 1000 about:robots tabs.

(2) Wait a bit (maybe 30-60sec, up to you) for your tabs to finish loading (just to minimize contention & background noise in the profile).

(3) In your newly-opened window with 1000 tabs, open an additional tab with some fullscreenable site, e.g. https://davidwalsh.name/demo/fullscreen.php

(4) Start profiling (Ctrl Shift 1)

(5) Click the button in the site to enter fullscreen mode.

(6) Wait a few seconds, and press Esc to exit fullscreen mode.

(7) Capture your profile (Ctrl Shift 2)

ACTUAL RESULTS:
The resulting profile shows a few fairly-long restyles/reflows in the parent process, which are associated with the fullscreen operation. The length of the restyle/reflows seems to grow with the number of tabs.

EXPECTED RESULTS:
Fullscreening web content should not cause substantial jank (and probably shouldn't cause jank that's dependent on your number of tabs).

Here's a profile of the STR (with 1000 about:robots tabs), zoomed in to the part where we enter fullscreen mode:
https://share.firefox.dev/32m7XtJ
...and when we exit fullscreen mode:
https://share.firefox.dev/3FPZqg7

In both cases (for entering and exiting), there are two long (over 100ms) restyles. This is on my fast hardware; on slower user hardware, this is probably substantially longer. (bug 1733227 comment 8 is an example)

For comparison: if I perform the STR without having opened any/many tabs, then the restyles are pretty trivial/short.

Comment 1

[Daniel Holbert [:dholbert]]

Note: I started this out in the Core:CSS component for analysis/thought, but I suspect the issue is probably some frontend code that's causing the restyles (e.g. by setting an attribute or something to that effect), and we'll perhaps want to make some recommendation to them about what to do instead.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

... there are two long (over 100ms) restyles. This is on my fast hardware; on slower user hardware, this is probably substantially longer. (bug 1733227 comment 8 is an example)

For reference, here's the profile from a user's machine in that other bug, which has a 1.9s restyle:
https://share.firefox.dev/3nNjv0l

(This one has "Elements traversed: 69,892" and "Elements styled: 47,085", both of which are about ~2x the values that I got for my profile in my STR, which makes me wonder if maybe that user has ~2x my number of tabs open, i.e. maybe they have ~2000 tabs.)

Comment 3

[Emilio Cobos Álvarez (:emilio)]

So we're starting a gazillion transitions, most of the style time is in UpdateAnimations.

Adding a bit of logging, I see that we're animating 4 elements for each tab. Looking a bit closer, it is because of this transition rule, combined with this style rule, which changes the visibility of a ton of elements to collapse.

So the restyle is considerably expensive because it switches a lot of stuff to be visibility: collapse since it's an inherited property. If we could achieve the same effect by setting reset properties it'd be cheaper. That said, it should still be fast, most of the issue is with the transition.

That said, visibility animates discretely, so this only serves as a purpose to delay setting the visibility by 25ms (which is barely perceptible, it's basically 1 frame). So perhaps we should consider removing that transition?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1751484 - Remove expensive, barely perceptible transition that triggers at unwanted times. r=dao

See https://bugzilla.mozilla.org/show_bug.cgi?id=1751484#c3, this
transition triggers on all tabs whenever the visibility of an ancestor
changes (like it does for DOM full-screen).

I think this is barely perceptible (it only applies visibility: hidden
for one frame, tab open animation looks equally neat on my machine
without it), so removing this is easier, but let me know if you instead
want to add an attribute to the tab to stop applying the transition, or
something of that sort around here:

https://searchfox.org/mozilla-central/rev/f7eeca4e34daea900fbedbc392c8c99f90923143/browser/base/content/tabbrowser-tabs.js#171

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d67ad48adb3c
Remove expensive, barely perceptible transition that triggers at unwanted times. r=dao

Comment 6

[Marian-Vasile Laza]

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

Comment 7

[Cristian Tuns]

Backed out for increasing the failure rate on mochitest failures on Bug 1751733

• Backout link

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/62f8cfde7123
Remove expensive, barely perceptible transition that triggers at unwanted times. r=dao

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/62f8cfde7123

Comment 10

[Daniel Holbert [:dholbert]]

Here's a profile of me entering & exiting fullscreen in Nightly 98.0a1 (2022-02-07):
https://share.firefox.dev/3Lgv5vd

I do still get a ~100ms restyle for entering, as well as one for exiting, but at least now it's just the one restyle. And the red jank bars seem to be contained within a 300-400ms period, rather than >1s as in my profiles linked at the end of comment 0. So: this is indeed a lot better than it was.

Comment 11

[Daniel Holbert [:dholbert]]

As an additional test: I tried the STR with 3000 tabs (up from 1000 in comment 0), since the original reporter in bug 1733227 had >2000 tabs and I wanted to overshoot that a bit for good measure.

Here's a profile under that configuration:
https://share.firefox.dev/3J9cY8K

Observations:

• With the additional tabs, the long-restyle on enter/exit fullscreen does get proportionally longer (3000 tabs incurs a ~240ms restyle, around 2.5x the duration of the restyle that we incur for 1000 tabs).
• ...and we do spend a substantial amount of time in a "red jank bar" state -- about 1.7s when entering full screen and 1.4s when exiting
• ...and a substantial portion of that seems to be dispatching DOM events (presumably to each tab), with the DOM event called "underflow" on entering fullscreen (~330ms spent spent dispatching those) and "overflow" on exiting fullscreen (~280ms spent dispatching those).