A resolution was made for csswg-drafts/#129.

[css-overflow-3] Clarify padding in overflow content

• RESOLVED: Always require inline-end padding to be added against the inline-end alignment edge for block/flow layout when it’s a scroll container, thus matching the tests.

Discussion.

A test for this behavior (in which we fail some subtests) is here:
https://wpt.fyi/results/css/css-overflow/scrollable-overflow-padding.html

This test will eventually live in our tree as well as a WPT test, though it doesn't look like we've merged it over yet. But when we do, it will be at
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-overflow/scrollable-overflow-padding.html

I think this will basically fix bug 1700858, which we can maybe consider to be a metabug at this point.

[clarifying bug-summary to be less vague & to sum up what I think the Chromium behavior basically is, which the CSSWG resolved to adopt]

A scrollable element's overflow area:

• Includes direct childrens' margin rect
  • Zero area rects are included
  • In-flow positioned rects are included and padding inflated
  • Out-of-flow positioned rects are included but not padding inflated
• Includes overflow (border rect) of direct children, but not padding inflated

As discussed on slack: here's a testcase that I think is currently broken by the attached patch (we fail to scroll far enough to show a find-in-page match), but it works properly if we revert the PresShell.cpp changes.

(It's using the overflow-clip-box property, which isn't user-exposed by default, so likely nobody would notice -- but ideally we should avoid needlessly/accidentally breaking it.)

Backed out for causing multiple failures

Backout link

Push with failures

Failure log 1 // Failure log 2 // Failure log 3 // Failure log 4

(In reply to Norisz Fay [:noriszfay] from comment #12)

Failure log 1

These are unexpected-passes, hooray!

Failure log 2

These are near misses (e.g. "expected 270 bug got 271"), on Android in scrollable-overflow-padding.html, which is a test whose failure-annotation is being removed in this bug's patch.

Would be interesting to investigate but probably not too important; likely just a rounding bug, possibly just due to the viewport-zoom factor that this tests ends up running at (and maybe a test bug). I'd suggest just annotating as expected-fail-on-Android for now (or leaving the existing annotations in-place). Possibly related to bug 1851066 (and bug 1802466 comment 17) in terms of root-cause there. Anyway, we can probably just add (or leave-in-place) whatever annotations are needed for this failure there, in an Android-specific way.

Failure log 3

Similar issue here -- this bug's patch is changing the expectation of this test test_bug375003-2.html, and it seems the new behavior is off-by-1 from our expected size, on Android (presumably due to the zoom factor). We could paper over that by making the test use either 260 or 259 depending on whether var isAndroid = navigator.appVersion.includes("Android"); is true?

FWIW, adding meta viewport for the two unexpected failures make them pass, so your hunch seems correct.

I spun out tickets to perhaps address this more globally: Bug 1930227 for WPT, Bug 1930223 for mochitests

https://hg.mozilla.org/mozilla-central/rev/117987129d8e

https://hg.mozilla.org/mozilla-central/rev/9001fe238088

(In reply to agoloman from comment #17)

https://hg.mozilla.org/mozilla-central/rev/117987129d8e

Perfherder has detected a browsertime performance change from push 117987129d8ea7663303a76773b50410d13438bf.

Improvements:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run these tests on try with ./mach try perf --alert 42607

For more information on performance sheriffing please see our FAQ.

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Is that perf change expected?

It's plausible at least, since Windows is the only platform without overlay scrollbars by default nowadays.

Might be worth confirming tho

I looked a little into why this made sp3 faster but don't have a satisfying explanation yet. What's clear is that the speedup is from spending less time building display lists. Specifically, I think it's the sidebar of the Complex-DOM layout that's affected; focusing that part of the call tree (before, after) shows a 7x reduction.
This must mean that the built display list is smaller. But I don't understand why. Is the difference in whether we give the sidebar a display port? How would this change have caused that?

Looking at the Svelte-Complex DOM, the 20241101 and 20241119 profiles

mozilla::nsDisplayList::DeleteAll takes signifcantly less time, so either we are deleting a smaller display list, or we are deleting it less often (retaining it is successful more often).

mozilla::DisplayPortUtils::MaybeCreateDisplayPortInFirstScrollFrameEncountered takes significantly less time (153 vs 22), so either we are calling it less, or each call is taking less time. A call could take less time if it finds a frame that has non-zero scroll range earlier in its tree walk.

I think bug 1931791 is responsible for about 100ms of the difference.

I compared a build before/after this bug. The sidebar gets a displayport from MaybeCreateDisplayPortInFirstScrollFrameEncountered in both cases (at least when I stepped into the test until the main content was drawn). And I checked the displayport rect, it was the same size before/after.

Maybe we are invalidating a scrollbar less often? That forces a full display list rebuild.

(In reply to Timothy Nikkel (:tnikkel) from comment #28)

Maybe we are invalidating a scrollbar less often? That forces a full display list rebuild.

I'd buy this explanation. Makes me wonder if we can make it so that other parts of sp3 also invalidate the scrollbar less often. Or maybe it's better to spend our time looking for improvements that don't rely on RDL.

(In reply to Timothy Nikkel (:tnikkel) from comment #28)

I compared a build before/after this bug. The sidebar gets a displayport from MaybeCreateDisplayPortInFirstScrollFrameEncountered in both cases (at least when I stepped into the test until the main content was drawn). And I checked the displayport rect, it was the same size before/after.

This information was wrong. I wasn't thinking and was testing on a mac with disappearing scroll bars. Testing on Windows with classic scrollbars we do not give the sidebar a display port (not sure why yet). That definitely seems like a bug though.

(In reply to Timothy Nikkel (:tnikkel) from comment #30)

This information was wrong. I wasn't thinking and was testing on a mac with disappearing scroll bars. Testing on Windows with classic scrollbars we do not give the sidebar a display port (not sure why yet). That definitely seems like a bug though.

There is a random visibility: hidden text control that is scrollable now that gets the display port. Filed bug 1932840 for this.

Requesting backout of this patch (And the 1st regression fix attempt, bug 1931466).
This needs some more work - (+ tests).

(After some discussion regarding review in bug 1932800, I think we have a low-risk path to close out the regressions)