1437761 - position:sticky inside partially-offscreen position:fixed container has a different behavior in Chrome/Edge vs Firefox

Status: NEW

(Core :: Layout, defect, P3)

Description

[Karl Dubost💡 :karlcow]

This is  a spin-off of https://webcompat.com/issues/15386

It's a test case report and I think would be better here than on webcompat.com.
The behavior is between Chrome/Edge and Firefox is indeed different.


=====
Open https://codepen.io/Onset/pen/ddpoRO in Firefox and see that the green box on the right is not attached to top border of viewport.

I've tested the latest Chrome and Edge too. Both have the green box positioned as expected. I believe it has something to do with usage of `position: sticky` inside element with `position: fixed`.

https://webcompat.com/uploads/2018/2/6fca4d25-2317-4e3f-88c7-ce4f438afef0.jpg
=====

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from reporter's codepen)

For archival purposes & more lightweight viewing, here's a static HTML version of the codepen.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced)

Here's a reduced testcase.

Basically, the issue here is that the fixed-position div is positioned with its top *offscreen* (at -190px in my example).  In Chrome, its position:sticky child ends up being shifted down to be inside the viewport. In Firefox, it does not.

(If I adjust this testcase locally to replace "position:fixed" with "position:absolute" on the container, then the Firefox rendering changes to match Chrome.  So this issue is specific to "position:fixed" containers for "position:sticky" children.)

Comment 3

[jklintestam]

I think this is a pretty substantial bug to sticky in Firefox.
Another way to illustrate the issue is to set a negative top value on the fixed container:
instead of acting like position fixed and stick to its specified position, it acts like position absolute and follows the parent container, ignoring the specified position of the sticky element.

Comment 4

[jklintestam]

(In reply to jklintestam from comment #3)

Clarification:
instead of acting like position fixed and stick to its specified position, the sticky element acts like position absolute and follows the parent container, ignoring the specified position of said sticky element.

Comment 5

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 6

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 7

[Ksenia Berezina [:ksenia]]

This is another possibly related bug. Here is a link to a codepen.

Comment 9

[Dennis Schubert [:denschub]]

Testcase still reproduces, but the sites no longer show this issue. P3 for now.

Comment 10

[focusvisiblewebkitbugzilla]

(In reply to Dennis Schubert [:denschub] from comment #9)

Testcase still reproduces, but the sites no longer show this issue. P3 for now.

Hi, what do you mean by "the sites no longer show this issue"? We have an issue in our production site — only on Firefox — where opening a modal sets position:fixed (necessary to prevent scrolling on iOS) and an offset top position. As a result, all sticky elements such as our header and map "disappear". Is there any way the priority can be revisited?

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to focusvisiblewebkitbugzilla from comment #10)

Hi, what do you mean by "the sites no longer show this issue"

I think Dennis was referring to one or more specific site where this had been causing trouble in the wild, which apparently have changed to no longer trip over this bug. (Likely distinct from the site that you develop where you're encountering this.)

Thanks for letting us know that your site is affected by this; I can add it to a list of bugs to revisit/investigate. Would it be possible to share a link to an affected page on your site, so that we can confirm that the eventual fix does indeed address the issue that you're running into?

Comment 12

[Daniel Holbert [:dholbert]]

A sort of shot in the dark diagnosis: I suspect the underlying issue here is that the fixed-position thing escapes the root scroller at some level; and so, when the sticky-positioned box looks for a scrollable ancestor, it doesn't find anything, so it doesn't think it needs to adjust its position. (This matters because sticky positioning is defined as being relative to the "nearest ancestor scroll container’s scrollport".)

We probably should treat the root viewport frame as if it were a scroll container, for the purpose of this nearest ancestor scroll container search. It looks like we already do this when it has overflow:clip which makes it not-a-scrollport. It would make sense for consistency for that same behavior to happen for fixed-position children (regardless of overflow), as well.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (no issues, just for comparison)

illustrating my last comment slightly: here's a testcase where we match Chromium and WebKit, comparing overflow:clip on the root element vs. on an element vs. overflow:scroll on an element.

• The leftmost area is testing overflow:clip on the root element and how it interacts with sticky -- there's a sticky-positioned box whose static position is offscreen, via its abspos parent with a negative top value; but it in fact, the sticky box remains onscreen. Apparently sticky positioning causes it to remain onscreen (despite it sort-of not having any ancestor scroll container); the viewport does successfully contain it here despite not forming a scroll container.

• The center area has overflow:clip on a black-bordered container div. In this case, that div does not form a scrollport and so the sticky-positioned thing doesn't get contained by it.

• The rightmost area is the same but now with overflow:scroll, which does indeed form a scrollport and hence does contain the sticky-positioned thing.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #14)

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

(No need to close here. The needinfo in question was from comment 11, asking for the URL of an affected site that the user mentioned. Anyway, we still have testcases that reproduce the bug & make it actionable, once someone can start working on this.)