Closed Bug 1377072 Opened 7 years ago Closed 3 years ago

`display: flex` causes the `position: sticky` does not work

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
99 Branch
Project Flags:
Webcompat Priority P2
Tracking Flags:
Tracking Status
firefox57 --- wontfix
firefox99 --- fixed

People

(Reporter: 709922234, Assigned: TYLin)

References

(Depends on 1 open bug, Blocks 2 open bugs,
URL
)

Details

(Keywords: testcase)

Attachments

(7 files)

Firefox
10.31 KB, image/png
Details
Chrome
7.74 KB, image/png
Details
testcase 1
554 bytes, text/html
Details
sticky positioned flex element that's stuck doesn't contribute to overflow with "in flow" geometry
1.12 KB, text/html
Details
Video of https://bugzilla.mozilla.org/attachment.cgi?id=9074885
1.26 MB, video/quicktime
Details
Bug 1377072 - Include child frame's overflow area locating at its normal position into parent's overflow.
48 bytes, text/x-phabricator-request
Details | Review
Bug 1377072 - Minor cleanup related to overflow areas.
48 bytes, text/x-phabricator-request
Details | Review
Attached image Firefox —
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.21 Safari/537.36 Steps to reproduce: 1. open https://codepen.io/mantou132/pen/PjELqL 2. scroll to bottom Actual results: `Link` background is orange Expected results: `Link` background is white
Component: Untriaged → General
Attached image Chrome —
(In reply to :Gijs from comment #2) > That said, I also don't see the <h1> getting height, > and I see the same behaviour in Chrome anyway. I don't know exactly what's going on here, but I do see different behavior in Firefox vs. Chrome here (Chrome matches the reporter's screenshot, when scrolled all the way down). Further-reduced testcase coming up.
Flags: needinfo?(709922234)
Attached file testcase 1 —
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dholbert)
Priority: -- → P3
Still hoping to circle back to this, but it's not gonna make it for 57 -- setting status accordingly.
status-firefox57: --- → wontfix
See Also: → 1553434

(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.

Flags: needinfo?(svoisen)

Redirecting ni to dholbert.

Flags: needinfo?(svoisen)

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!

Flags: needinfo?(dholbert)
See Also: → 1585254
Webcompat Priority: --- → P2
See Also: → https://github.com/webcompat/web-bugs/issues/98606
See Also: → 1488080

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.)

Assignee: nobody → aethanyc
Status: NEW → ASSIGNED

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

Pushed by aethanyc@gmail.com: https://hg.mozilla.org/integration/autoland/rev/159e0423f987 Include child frame's overflow area locating at its normal position into parent's overflow. r=dholbert https://hg.mozilla.org/integration/autoland/rev/bc83efda9211 Minor cleanup related to overflow areas. r=dholbert
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/33074 for changes under testing/web-platform/tests

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

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox99: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch
Upstream PR merged by moz-wptsync-bot
See Also: 1585254 →
See Also: 1488080 →
Regressions: 1769060
Depends on: 1769060
No longer regressions: 1769060
See Also: → 1800939
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: