1598112 - element with position: sticky and top: 100%; makes its parent to have infinite scrollbar

Status: VERIFIED FIXED

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

Description

[Ksenia Berezina [:ksenia]]

Attachment: 44780.html

As reported in https://github.com/webcompat/web-bugs/issues/44780

STR:

1. On Firefox for Android visit https://sp.nicovideo.jp/ and try scrolling to the end of the page

Expected:
Can see the footer at the bottom of the page

Actual:
Can't reach the bottom of the page

There is a overflow-x rule on both html and body, and removing either of them fixes the issue

html, body {
    overflow-x: hidden;
}

I've also attached a reduced test case.

Comment 1

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Thanks for the reduced test case. FWIW, this can also be reproduced on desktop browsers.

The infinite scrolling doesn't look good, and it affects a real site.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Is it really unexpected? If you stick something to the viewport that's larger than the viewport, I think expanding the viewport is ~expected?

Comment 3

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Per spec 6.2. Sticky positioning

However, if sticky positioning causes an overflow: auto or overflow: scroll box to have overflow, the user agent must allow the user to access this content (at its offset position), which, through the creation of a scrolling mechanism, may affect layout.

It sounds like the sticky element should be able the enlarge the overflow area initially of the scroll container base on its 'top', 'left, etc, but it shouldn't "stick" there forever while scrolling to further enlarge the overflow area.

Comment 4

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: position-sticky-large-top.html

This bug affects ordinary overflow scroll container.

In this test, Firefox cannot scroll to the purple rectangle in case 1 and case 2, while Google Chrome can in all cases. But Chrome didn't allow a sticky element to create an overflow area as case 1 shows.

Comment 5

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: Bug 1598112 - Use scrolled frame's overflow rect as a the bounding box for position:sticky elements.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) (Traveling Nov 23 - Dec 15) from comment #3)

It sounds like the sticky element should be able the enlarge the overflow area initially of the scroll container base on its 'top', 'left, etc, but it shouldn't "stick" there forever while scrolling to further enlarge the overflow area.

This sounds related to the issue I brought up in https://github.com/w3c/csswg-drafts/issues/2794 ("Clarify whether sticky-positioned elements' residual position can cause scrollbars to remain, when a tall thing is removed")

Comment 7

[Daniel Holbert [:dholbert]]

The spec text in comment 3 is just saying that the sticky-positioned element creates scrollable overflow, I think. It's not obvious to me that that language is meant to put an additional constraint on the sticky-position of the element. (Note that the spec uses the exact same language when describing position:relative elements -- so it's not spec-text that someone crafted specially to ensure that sticky positioned elements remain scrollable.)

My gut feeling here is that we need spec clarification on this general issue of sticky-elements-beyond-the-reach-of-the-scrollport before shaking things up too much here, so I'm hesitant to take this patch unless it were clearly-correct/compatible. And I don't think it is clearly-compatible, right now, because Chrome fails the first half of the included WPT test (on my machine at least)...

Comment 8

[Daniel Holbert [:dholbert]]

(In particular, the above-linked spec issue https://github.com/w3c/csswg-drafts/issues/2794 would presumably have some bearing here, and the in-spec issues #2, 3, and 6 all kinda need to be addressed and would have some bearing on what we do here.)

Also: bug 1585254 is related & perhaps the same core issue.

I'm uneasy making this change without a coherent mental model for how this is supposed to work & what we'd like the spec to say about this.

Comment 9

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

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

My gut feeling here is that we need spec clarification on this general issue of sticky-elements-beyond-the-reach-of-the-scrollport before shaking things up too much here, so I'm hesitant to take this patch unless it were clearly-correct/compatible. And I don't think it is clearly-compatible, right now, because Chrome fails the first half of the included WPT test (on my machine at least)...

Right. The spec isn't crystal clear about how to deal with the overflow area creating by the sticky elements. I think what Google Chrome does is simply to restrict the sticky element's position to the overflow area established by other elements within the same containing block. So in effect, the sticky elements cannot enlarge the overflow area.

If we want a compatible behavior with Chrome and fix the real site issue, I think the patch can be simpler. Though we'll have to give up passing this test position-sticky-offset-overflow.html, and it may be ok since no other engines pass it.

Comment 10

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: Bug 1598112 - Use scrolled frame's overflow area as a bounding box for sticky elements.

This change effectively disallows sticky elements to enlarge overflow
area. That is, the position of an sticky element will be bounded by the
scrolled frame's border-box as well as the overflow area created by
other non-sticky elements within the same block formatting context.

This makes Firefox behave like Google Chrome.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b2e78ee1b18e
Use scrolled frame's overflow rect as a the bounding box for position:sticky elements. r=emilio

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/20898 for changes under testing/web-platform/tests

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Can't merge web-platform-tests PR due to failing upstream checks:
Github PR https://github.com/web-platform-tests/wpt/pull/20898
* Community-TC (pull_request) (https://community-tc.services.mozilla.com/tasks/groups/PMO_bCqiSLeIMxckVXx4uw)

Comment 14

[Narcis Beleuzu [:NarcisB]]

Backed out for Linting failure on position-sticky-large-top-2-ref.tentative.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/41a2a0efeb1a7f4b667e4be2154a6b6949532add
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=282181682&repo=autoland&lineNumber=270

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c2b76b215034
Use scrolled frame's overflow rect as a the bounding box for position:sticky elements. r=emilio

Comment 17

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 18

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 19

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/c2b76b215034

Comment 20

[Diana Rus]

Hi, from mobile side the issue is fixed, the user can reach at the bottom of the page, the footer is visible, checked with Sony Xperia Z5 (Android 7.0.0), Samsung Galaxy S8+ (Android 8.0.0) and Google Pixel 3a (Android 9) on Firefox Preview Nightly 200113 (Build #20130606) and GV: 74.0a1-20200110095023.
Test Data:

• checked with link: https://sp.nicovideo.jp/
• with attachment: https://bugzilla.mozilla.org/attachment.cgi?id=9110356
• with attachment: https://bugzilla.mozilla.org/attachment.cgi?id=9110645

Comment 21

[Cristian Fogel [:cfogel]]

Confirmed issue with 72.0a1 (2019-11-20) on Windows 10.
Fix verified with 73.0b6 on Windows 10, macOS 10.15, Ubuntu 18.04.

Possible issue uncovered while verification on Windows 10 still, noted on bug 1609915.