1773121 - Relatively Positioned Element Should Not Decrease the Scroll Area of Its Container

Status: RESOLVED DUPLICATE of bug 1772593

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

Description

[David Shin[:dshin] (PTO Til 24th)]

Attachment: testcase 1

As per the standard: "The box is laid out as for static, then offset from the resulting position. This offsetting is a purely visual effect, and does not affect the size or position of any other box, except insofar as it increases the scrollable overflow area of its ancestors."

STR: Load test case

Expected Behaviour:

1. First div's scrollbar width is 200px
2. Second div's scrollbar width is 300px
3. Third div's scrollbar width is 200px

Actual behaviour: First and second divs behaves as expected, but the third scrollbar does not appear

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Huh, I would've expected this to take care of it: https://searchfox.org/mozilla-central/rev/0e3d9bfae6fdaa6cb29cbce3f25471d5708aedc3/layout/generic/nsIFrame.cpp#7686

Comment 2

[David Shin[:dshin] (PTO Til 24th)]

Tracking calls to that function down, looks like the behaviour is more correct if I trigger UnionChildOverflow (Which calls down to GetActualAndNormalOverflowAreasRelativeToParent) by turning the relevant pref on and applying overflow-clip-box: content-box.
But this feels like we're calculating the overflow area all over again - should we not be returning the correct overflow area (e.g. what GetActualAndNormalOverflowAreasRelativeToParent returns) in the first place at the end of reflow?

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to David Shin[:dshin] from comment #2)

should we not be returning the correct overflow area (e.g. what GetActualAndNormalOverflowAreasRelativeToParent returns) in the first place at the end of reflow?

I think you're right, yeah; we should probably be incorporating the actual-and-normal-position-based overflow areas there.

Comment 4

[David Shin[:dshin] (PTO Til 24th)]

Attachment: Bug 1773121 - If an element is relatively positioned, report overflow area that is a union of relative and static position. r=#layout-reviewers

With this, a relatively positioned element e.g. being offset to the left
should not decrease the scrollport size. For this, overflow area calculation
for relatively positioned elements must behave like
nsIFrame::GetActualAndNormalOverflowAreasRelativeToParent. We aren't
using the function directly since it's meant to be called post-reflow, and
we want to report it correctly during reflow in the first place.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d6ee5bae41b8
If an element is relatively positioned, report overflow area that is a union of relative and static position. r=dholbert

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34450 for changes under testing/web-platform/tests

Comment 7

[Atila Butkovits]

Backed out for causing Wr failures.

Backout link: https://hg.mozilla.org/integration/autoland/rev/82bdd9ac89e3935aaabd32354622f07d9b8ff97f

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=eOV58FLpRPatYpbwWuP2kg.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=d6ee5bae41b8d871d65ad69d76c7598bf94ac06e

Failure log:
https://treeherder.mozilla.org/logviewer?job_id=381444944&repo=autoland&lineNumber=1716
https://treeherder.mozilla.org/logviewer?job_id=381445395&repo=autoland&lineNumber=4273

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a testcase (using essentially the third piece of the original testcase, and a variant of that piece with a wrapper div).

There are two scrollable areas in the testcase.

• Firefox Nightly shows no scrollbars at all.
• Chrome shows scrollbars on the first part but not the second part.
• Firefox with the attached patch shows scrollbars on both.

The second part is sort of like the failing WPT test where we end up creating scrollbars unnecessarily for a relative-positioned grandchild of the scrollable element, whose static position would overflow but its actual (positioned) position does not:
https://wpt.live/css/CSS2/linebox/empty-inline-002.xht

I think the crux here is that we only want to do this for the "in-flow children" -- e.g. the "in-flow bounds" that we need to consider for bug 1768921 should probably include the normal position of relatively-positioned children.

Comment 10

[Daniel Holbert [:dholbert]]

Per bug 1772593 comment 14, I think a proper fix for that bug over there would also fix this bug here (make us agree with Chrome on testcase 1 and testcase 2 here).

So I think maybe we should just dupe this and proceed to fix bug 1772593?

Comment 11

[David Shin[:dshin] (PTO Til 24th)]

Ok - agreed.