(In reply to Daniel Holbert [:dholbert] from comment #5)

I believe this is a legitimate bug, and I think basic problem is that we're
not creating scrollable overflow on the flex container, for the
sticky-positioned element's "normal" (not-sticky-adjusted) position.

Yep, in testcase 1 (https://bugzilla.mozilla.org/attachment.cgi?id=8882197), toggle off the height: 50px declaration on the flex container, allowing its height to expand to its content, and see the expected behavior return.

Hey [:dholbert]

Was about to file a separate ticket for this case, but I think the underlying issue is the same here, can you concur?

Left scroller uses display:flex, right scroller is just display:block. Both have sticky pos element visually "lifted" up from overflowing. In gecko, the left scroller has no overflow/scrolling, while blink/webkit allow overflow/scrolling. Right side behaves the same across browsers.

Redirecting ni to dholbert.

I suspect that's a version of the same bug, yes. If it turns out not to be, we can spin off a bug as-needed when this bug is fixed. Thanks!

Hi,

As I flagged in 1585254, I also encountered a problem that I think is related to this.
When using a sticky position inside of a flexbox, a div partially hidden behind a sticky div is scrollable in all browsers other than Firefox.

Here's a codepen that reproduces the issue: https://codepen.io/ricvolpe/pen/poddVzm

Actual results:
Content div scrolls until item six is behind footnote, making it invisible

Expected results:
Content div scrolls until item six is above footnote, making it visible

When a position:sticky element "sticks" in the scroll container's scrollport, we
compute its containing block's overflow areas by including its overflow areas
located at its relative position. This makes the element's normal position
unreachable because its overflow areas located at its "normal position" might
not be within its containing block's overflow areas. Block frame doesn't have
this problem because nsLineBox always includes the element's normal position
rect in its own rect.

Therefore, when including a sticky child frame's overflow area into its parent's
overflow area, the overflow areas located at its normal position should be
included as well. This behavior is consistent with a relatively positioned child
frame. (A position:relative frame's normal position is always reachable when
scrolling, at least in both axes that grow positively.)

None of these changes should change the behavior.

• In ConsiderChildOverflow(), replace the legacy term "visual" overflow.

• GetOverflowAreasRelativeToSelf(), ScrollableOverflowRectRelativeToSelf(),
  InkOverflowRectRelativeToSelf() can really be terser.

• Replace mRect.TopLeft() with Position(), and nsRect(nsPoint(0, 0), GetSize()) with GetRectRelativeToSelf(), making them shorter and clearer.

• Move GetOverflowRect() to private section because it's an implementation
  detail of InkOverflowRect() and ScrollableOverflowRect().

Depends on D140373

https://hg.mozilla.org/mozilla-central/rev/159e0423f987
https://hg.mozilla.org/mozilla-central/rev/bc83efda9211