Bug 233403

Summary: Clarify behavior of ScrollAnimator::scroll()
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: ScrollingAssignee: Simon Fraser (smfr) <simon.fraser>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, changseok, clord, cmarcelo, esprehn+autocc, ews-watchlist, fred.wang, glenn, kangil.han, kondapallykalyan, mifenton, mmaxfield, mrobinson, pdr, sam, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch sam: review+

Description Simon Fraser (smfr) 2021-11-20 16:44:38 PST
Clarify behavior of ScrollAnimator::scroll()
Comment 1 Simon Fraser (smfr) 2021-11-20 16:44:55 PST
Created attachment 444910 [details]
Patch
Comment 2 Simon Fraser (smfr) 2021-11-20 21:53:24 PST
Created attachment 444915 [details]
Patch
Comment 3 Sam Weinig 2021-11-21 10:33:34 PST
Comment on attachment 444915 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=444915&action=review

> Source/WebCore/platform/ScrollTypes.h:174
> +inline ScrollEventAxis axisFromDirection(ScrollDirection direction)

You could make this constexpr.

> Source/WebCore/platform/ScrollTypes.h:194
> +inline void setValueForAxis(FloatSize& size, ScrollEventAxis axis, float value)

I think this reference parameter makes this more confusing than necessary, and probably isn't a performance win over just returning a new FloatSize.

An alternative that might make sense would be making a subclass or wrapper class of FloatSize called something like ScrollDelta that has this function.

> Source/WebCore/platform/ScrollTypes.h:211
> +inline void setValueForAxis(FloatPoint& point, ScrollEventAxis axis, float value)

Same here as setValueForAxis.
Comment 4 Chris Lord 2021-11-22 02:46:29 PST
Comment on attachment 444915 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=444915&action=review

Drive-by from a non-reviewer that has some stake in this part of the code - looks good to me, just some small bits and bobs I think might be worth addressing.

> Source/WebCore/dom/Element.cpp:-1124
>      ScrollDirection direction = ScrollDown;
> -    if (units < 0) {
> +    if (units < 0)
>          direction = ScrollUp;
> -        units = -units;
> -    }

Maybe it's a style thing, but could this not just be condensed to a one-line `ScrollDirection direction = (units < 0) ? ScrollUp : ScrollDown;` now? I think it'd read nicer, though would understand opposition to a ternary.

> Source/WebCore/dom/Element.h:178
> +    // These are only used by WebKitLegacy DOM API.

Great to have this comment here, I wonder if it'd be nice to add even more separation somehow, either via an interface (LegacyScrolling or something) or via the use of a friend class and making these private.

> Source/WebCore/page/FrameView.cpp:3839
> +    if (granularity != ScrollGranularity::Page || axis == ScrollEventAxis::Horizontal)

If this function does nothing when not vertical, paged scrolling, would it make more sense to name this function something different and adjust the call-site instead? I suppose that's a bigger change, but it feels weird to me to have a whole function that takes two parameters whether to decide to do anything at all.

> Source/WebCore/platform/ScrollAnimator.cpp:74
> +        behavior.remove(ScrollBehavior::RespectScrollSnap);

If this function is no longer re-entrant, should this flag still be removed? It might actually be useful later on to determine whether the scroll position may have been adjusted(?)

> Source/WebCore/platform/ScrollTypes.h:182
> +    return ScrollEventAxis::Vertical;

I guess it would be nice to have an ASSERT_NOT_REACHED() before this.

> Source/WebCore/platform/ScrollTypes.h:191
> +    return 0;

Same here re assert.

> Source/WebCore/platform/ScrollableArea.h:229
> +        return nullptr;

Again, I think it would be nice to assert here.
Comment 5 Simon Fraser (smfr) 2021-11-22 12:03:25 PST
Sorry Chris, I committed before I saw your comments. I'll address your comments in a followup.
Comment 6 Simon Fraser (smfr) 2021-11-22 13:30:33 PST
Comments addressed in https://trac.webkit.org/changeset/286119/webkit.
Comment 7 Radar WebKit Bug Importer 2021-11-22 13:31:25 PST
<rdar://problem/85683219>