1809630 - Extremely slow render times with scrollbar-width: thin on many elements

Status: VERIFIED FIXED

(Core :: Layout: Scrolling and Overflow, defect)

Description

[fischer.andreas.atf]

Attachment: reflow_with_thin_scrollbars.profile.json.gz

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Steps to reproduce:

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

Preconditions:
Activate thin scrollbars for a page, which contains many (also nested) flexboxes (don't know if a flex box is the trigger of the issue or not).
Thin scrollbars are enabled by using the following CSS rule:

• { scrollbar-width: thin }

(Hint: I also limited the selector to only match divs for example, which did not do the trick, since all the scrolling containers are divs anyways. I also cannot know which containers will scroll. There is no dedicated scroll container type.
In my case 1693 elements have the property set to "thin")

Actual results:

The render performance will drop significantly after style reflows. Depending on the number of matching elements (see selector above), the client does not respond for SECONDS on my machine.
V.S.
No performance drop, without the "scrollbar-width" property beeing set to "thin".

I attached two performance profiles to this ticket. One with and one without thin scrollbars. The profiles have been recorded with the exact same application state, performing the exact same user actions.

With thin scrollbars enabled, i find the following stack which looks rather suspicios:
Reflow
get Element.hasVisibleScrollbars
get isScrollable
_onReflows
$bound
_emit
emit
emit
_startEventLoop
$bound
notify
XPCWrappedJS method call

This must be native code from Firefox, which causes an additional reflow. Could be nothing, though...

Expected results:

No render performance drop should occur what so ever. Altering scrollbar styles works with all the other major browsers without any performance issues.

Comment 1

[fischer.andreas.atf]

Attachment: reflow_without_thin_scrollbars.profile.json.gz

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Timothy Nikkel (:tnikkel)]

Can you attach the testcase you are using?

Comment 4

[fischer.andreas.atf]

@Timothy
You mean an example page/app? I am working on our big client. I first would have to extract or reconstruct the DOM from our app state. You mean that?

I guess i should mention one more thing:
The issue does not occur with the same Firefox version under Linux Mint 20.2.

Comment 5

[Timothy Nikkel (:tnikkel)]

Either a page accessible on the public internet, or an html file attached to this bug that reproduces the long render times. Something that a Firefox developer could load to investigate the problem. It doesn't need to be small or minimized or anything, just a page, it can be big with lots of extra things in it.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

For reference, links to the profiles attached to this bug:

• Bad: https://share.firefox.dev/3GUfrW6
• Good: https://share.firefox.dev/3X41BGs

Which... just doesn't make any sense to me, that's scarily different.

If you could attach a test-case (as Timothy said, just a dump of the page that reproduces the issue or something like that, or even a link if you can put it somewhere) I'd be happy to take a look.

Curious, does the issue reproduce on Linux if you go to the settings page and enable "Always show scrollbars"? What about Windows 11? I presume this needs to happen with non-overlay scrollbars only. If it happens with overlay scrollbars I'd be baffled...

Thanks!

Comment 7

[fischer.andreas.atf]

@Timothy, @Emilio

I was trying to reproduce it with a dump, but there is more going on there, since we need script to trigger some reflows.
But i would be able to offer you a guest access to one of our demo systems via private message (don't want to share it with the public ;) ).
I could do that by tomorrow.

Comment 8

[Timothy Nikkel (:tnikkel)]

Sure. You could email the access info to [e-mail] and [e-mail] and we'll take a look. Thanks!

Comment 9

[fischer.andreas.atf]

I sent you a login link.

Comment 10

[Timothy Nikkel (:tnikkel)]

Thanks. I tried to reproduce on macos with both kinds of scrollbars. It seemed to stay snappy for me. I'll try on Windows and Linux and look in more detail tomorrow if Emilio doesn't beat me to it.

Comment 11

[fischer.andreas.atf]

All clear. I am running on Windows 10 still ;)

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Same, I couldn't repro on Linux either, with and without overlay scrollbars. This was on nightly tho, will try release as well...

Comment 13

[Emilio Cobos Álvarez (:emilio)]

If you can reproduce on your machine, it'd be great to check whether this bug still happens on a Nightly build (https://nightly.mozilla.org)

Comment 14

[Emilio Cobos Álvarez (:emilio)]

It does repro on Windows (11, with "always show scrollbars") on nightly fwiw. Quite bizarre, but digging.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

I have an idea about what might be going on...

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Attachment: Standalone test-case.

This reproduces the issue. I haven't reduced it yet, but I noticed that commenting out this line fixes the issue. Also, commenting out this fixes some stuff as well (so that perf is acceptable but not as good as the "good" case).

This can be reproduced on Linux if you enable the windows scrollbars (yay, I can use rr).

I think there's something in either the scrollbar styling or the windows native theme that's causing the thin scrollbar to not have the expected size in a way that it triggers unstable layout in a way that causes all the cached flex sizes to get thrown out of the window.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1809630 - Make thin scrollbars on Windows have a reasonable minimum size. r=tnikkel,spohl,mstange,#layout

The way the code was set up before this patch ends up causing minimum
scrollbar sizes to be 0x0 for thin (non-overlay) scrollbars.

This is rather problematic, since it means that we would always try to
place the scrollbar even if it doesn't fit (think of an element with
height: 0).

This causes a lot of extra reflow, which with very complex layouts is
even worse, because the extra scrollframe reflows cause us to miss the
flex caches, causing O(n^2) performance.

Add assertions to make sure we never end up with a zero minimum
scrollbar size, and change the size computation to match for both
thin and thick scrollbars.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/51619d94e92d
Make thin scrollbars on Windows have a reasonable minimum size. r=tnikkel,layout-reviewers

Comment 20

[Cristian Tuns]

Backed out for causing reftest failures on percent-height-overflowing-image-1.html

• Backout link
• Push with failures
• Failure Log
• Failure line: REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/scrolling/percent-height-overflowing-image-1.html == layout/reftests/scrolling/percent-height-overflowing-image-1-ref.html | image comparison, max difference: 255, number of differing pixels: 946

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c058fde9c435
Make thin scrollbars on Windows have a reasonable minimum size. r=tnikkel,layout-reviewers

Comment 22

[Iulian Moraru]

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

Comment 23

[Monica Chiorean]

Hello Emilio,
I tried to reproduce the issue on Win10, Mac10.13 and Ubuntu 20.04 but I see not difference between latest Nightly build and old one. Is there any way I can reproduce it in order to confirm the fix? On Ubuntu 20.04 using FF build 109.0a1(20221206034609) I enable Natural Scrolling and used your test link but I see no issue.
Thank you very much.

Comment 24

[Emilio Cobos Álvarez (:emilio)]

You need to be on Windows 10 (or tweak a bunch of settings). It's not about the scrolling speed but the load time. On the test case attached, the load time should be much slower before the fix.

Comment 25

[Monica Chiorean]

I checked again and on Win10 using 108.0 it takes longer to load compared to latest 110.0b9. Marking issue as verified. Thank you for your help.