Bug 240744 – WebKit doesn't create scrollable overflow (doesn't show scrollbar) for legitimately overflowing content that's off the left side of a zero-size position:sticky parent

• Component: Layout and Rendering
• Status: RESOLVED WONTFIX

[Daniel Holbert]

Created attachment 459630 [details]
testcase

STR:
1. Load attached testcase.

EXPECTED RESULTS:
There should be a functional scrollbar inside the black-bordered area, and it should let you scroll to the purple bottom-border.

ACTUAL RESULTS:
The scrollbar tracks are disabled, as if there were no scrollable overflow (but in fact there is!)


Firefox 100 gives EXPECTED RESULTS.
Safari 15.4 and Chrome 103 give ACTUAL RESULTS (Chrome bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=1327794 )

(Note, this was initially reported as a Firefox bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1769060 ; the reporter there has a custom-scrollbar implementation which happens to depend on this bug. It worked in Firefox as well for a while because of another related Firefox bug, but it "broke" in Firefox when we fixed that bug. Really, the new rendering in Firefox is correct, and the component is inadvertently depending on this WebKit/Blink bug.)

[Daniel Holbert]

Created attachment 459631 [details]
reference case

Here's a reference case, where I've made two 1px adjustments (shifting #sticky 1px to the left, and reducing the negative-magnitude of margin-left on #sticky-inner by 1px, so that it's not quite fully off the left side of its parent).

As noted in the Chromium bug report, it seems Blink and WebKit are disregarding scrollable-overflow contributions from the innermost element, if that element is fully pushed off the left side of its parent, **despite the fact that it's still inside the scrollport.**

[Radar WebKit Bug Importer]

<rdar://problem/94057999>

[Ahmad Saleem]

After going through Chrome comment, it seems that Mozilla need to fix the bug on their end rather than Webkit & Chrome.

Marking this as "RESOLVED WONTFIX". Thanks!