1820266 - Firefox disagrees with other browsers on whether relative positioned descendants contribute scrollable overflow for their "normal" position

Status: NEW

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

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 [non interoperable]: limited-height body, tall relpos elem w/ huge negative position

STR:

1. Load attached testcase.

ACTUAL RESULTS:
Firefox shows a vertical scrollbar.

EXPECTED RESULTS (from other browsers):
No vertical scrollbar.

Also, if I check document.documentElement.scrollHeight, Firefox gives me 4035, whereas Chrome gives me max(viewport-height, 224). (where 224px = 200 + 22px + 28px + 2*2px, for the body height plus body-border plus default body-margin plus html border)

We seem to be getting 4035 by contributing the static position of the relatively-positioned box to the scrollable overflow, whereas other browsers don't contribute it in this case, for some reason...

This behavioral difference is part of the reason for our WPT test-failure in bug 1820265 -- specifically, issue "B" there. The testcase seems to expect the Chromium/WebKit behavior.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 [interoperable]: same as testcase 1, but with the tall thing being abpsos

As shown here: if I make the tall thing position:absolute, then Firefox stops showing a scrollbar (and we agree with other browsers).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: [mostly interoperable] same as testcase 1, but with the scrollport being established by a div instead of the root

Here's a testcase exercising the original situation but now with a scrollable div instead of the top-level scrollport.

In this case, all browsers show a vertical scrollbar on the div (consistent with the way that Firefox renders testcase 1).

Chrome additionally shows a horizontal scrollbar on the div in this testcase, for some reason, though Firefox and WebKit do not.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 4: [non interoperable] same as testcase 1, but with scrollport being established by a div, and with a tiny wrapper around the tall thing

Here's a testcase that's a further iteration, building on the modification in testcase 3. I think this gets to the heart of the behavior difference.

Here, I've got a scrollable div (playing the part of the root scrollport in the original testcase), and I've got a small fixed-size wrapper element inside of it (playing the part of the body in the original testcase). We get a scrollbar, but other browsers do not. The extremely-tall relatively-positioned descendant apparently still generates scrollable overflow for its "normal" position, in Firefox.

(This testcase might superficially seem the same as testcase 3, but the difference is that testcase 3, the scrollable div's anonymous scrolled-frame has to wrap the size of its child, which in that case is the extremely large relatively-positioned thing. In this case, I'm preventing that shrinkwrapping from influencing the results, by hiding the tall thing in a fixed-size wrapper.)

Comment 4

[Daniel Holbert [:dholbert]]

I tested testcases 1 and 4 (the ones most directly focused on the interop issue here) in the oldest browser versions that BrowserStack has available on Windows 11.

Chrome 37 agrees with current Chrome 112dev.
Firefox 32 agrees with current Firefox 112 Nightly.

So: this behavior difference goes back quite a long way.

Comment 5

[cathiechen]

In [1], the scrollable overflow area seems not include the original border box.

[1] https://drafts.csswg.org/css-overflow-3/#scrollable-overflow-region

Comment 6

[cathiechen]

Attachment: testcase 5: the margin version of testcase 4

Regarding the margin areas, it seems Firefox also disagrees with other browsers. I.e. Firefox includes the margin areas in the scrollable overflow area, while others don't. Testcase 5 is the margin version of testcase 4.

In the code, I prototyped to stop calling ConsiderBlockEndEdgeOfChildren() in nsBlockFrame::ComputeOverflowAreas(). It could make the behavior consistent to other browser in both relative positioned offset areas and margin areas. It also breaks several test cases in the WPT test, mostly are about position: relative and margin. Not sure if we should make this change, it seems to affect a lot.