Bug 244232 - overscroll-behavior: none doesn't prevent overscroll when page is too small to scroll
Summary: overscroll-behavior: none doesn't prevent overscroll when page is too small t...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Scrolling (show other bugs)
Version: Other
Hardware: All All
: P2 Normal
Assignee: Nikos Mouchtaris
URL:
Keywords: BrowserCompat, InRadar
Depends on:
Blocks:
 
Reported: 2022-08-22 19:13 PDT by Kurt Revis
Modified: 2023-01-23 11:18 PST (History)
4 users (show)

See Also:


Attachments
Test case (1.16 KB, text/html)
2022-08-22 19:15 PDT, Kurt Revis
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Revis 2022-08-22 19:13:48 PDT
When a document has overscroll-behavior: none, but the page's height is too small to be scrollable, the page can still be overscrolled using a touch (iOS) or trackpad scroll (iOS, Mac).

Steps:
1. Load attached html file in Safari Technical Preview 151 on macOS 12, or Safari on iOS/iPadOS 16 beta, or Safari in macOS 13 beta
2. On Mac, scroll up and down using two-finger scroll gesture on trackpad.
3. On iPhone, scroll up and down with touch.
4. On iPad, scroll up and down with touch, or with two-finger scroll gesture on trackpad, or with mouse wheel.

Expected: Since the html and body elements have `overscroll-behavior: none`, overscroll aka "bouncing" should not happen.
Actual: Overscroll aka "bouncing" does happen. If you click on the element that increases the body height, so scrolling is possible, then overscroll stops working.

Notes:

Both Chrome and Firefox behave as expected. (Chrome 104.0.5112.101 and Firefox 103.0.2 on macOS 12.5.1.)

The Overscroll Behavior spec says, about overscroll-behavior: none, that "this element must also not perform local boundary default actions such as showing any overscroll affordances". 
https://drafts.csswg.org/css-overscroll/#valdef-overscroll-behavior-none

Also, "If a scroll container has no potential to scroll, because it does not overflow in the direction of the scroll, the element is always considered to be at the scroll boundary."
https://drafts.csswg.org/css-overscroll/#scroll-boundary

Nothing in the spec appears to say that the overscroll-behavior should be ignored in this case. 

There's an existing bug with a similar complaint:  https://bugs.webkit.org/show_bug.cgi?id=243452
but this case is simpler, with no nested scroll views, just a simple document.
Comment 1 Kurt Revis 2022-08-22 19:15:13 PDT
Created attachment 461811 [details]
Test case
Comment 2 Kurt Revis 2022-08-22 19:19:52 PDT
I'm suspicious of this code in WebCore/page/FrameView.cpp:

OverscrollBehavior FrameView::verticalOverscrollBehavior()  const
{
    auto* document = frame().document();
    auto scrollingObject = document && document->documentElement() ? document->documentElement()->renderer() : nullptr;
    if (scrollingObject && renderView() && renderView()->canBeScrolledAndHasScrollableArea())
        return scrollingObject->style().overscrollBehaviorY();
    return OverscrollBehavior::Auto;
}

When renderView()->canBeScrolledAndHasScrollableArea() is false, we ignore the style and return Auto instead. What is that check trying to accomplish?
Comment 3 Radar WebKit Bug Importer 2022-08-23 00:10:32 PDT
<rdar://problem/99018981>
Comment 4 Nikos Mouchtaris 2023-01-19 16:40:42 PST
Pull request: https://github.com/WebKit/WebKit/pull/8859
Comment 5 EWS 2023-01-23 11:18:29 PST
Committed 259227@main (487c9dfe271c): <https://commits.webkit.org/259227@main>

Reviewed commits have been landed. Closing PR #8859 and removing active labels.