Bug 239605

Summary:

Focusing scroll container before scrolling breaks smooth scrolling

Product:

WebKit

Reporter:

Liam DeBeasi <ldebeasi>

Component:

Scrolling

Assignee:

Simon Fraser (smfr) <simon.fraser>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cdumez, cmarcelo, esprehn+autocc, ews-watchlist, kangil.han, rniwa, simon.fraser, webkit-bug-importer, wenson_hsieh

Priority:

Keywords:

InRadar

Version:

Safari 15

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Code reproduction	none
Patch	none
Patch	none
Patch	ews-feeder: commit-queue-

Liam DeBeasi

Reported 2022-04-21 07:37:12 PDT

Created attachment 458061 [details] Code reproduction Focusing a scroll container before performing a smooth scroll operation causes smooth scrolling to not work. Non-smooth scrolling works as expected. Steps to reproduce: 1. Open attached code reproduction on an iOS device that supports smooth scrolling. 2. Tap the "Smooth scroll to end" button. Observe that the container does not scroll to the end. 3. Tap the "Non Smooth scroll to end" button. Observe that the container scrolls to the end. Expected Behavior: I would expect that the container scrolls regardless of smooth scroll status. Actual Behavior: The scroll container does not scroll if smooth scrolling is enabled. Other Information: - This works as expected on Chrome and Firefox. - Disabling CSSOM View Smooth Scrolling in Settings > Safari > Experimental Features resolves the issue. - Wrapping the scroll operation in a requestAnimationFrame fixes the issue.

Attachments
Code reproduction (1.24 KB, text/html) 2022-04-21 07:37 PDT, Liam DeBeasi	no flags	Details
Patch (9.49 KB, patch) 2022-04-21 21:37 PDT, Simon Fraser (smfr)	no flags	Details Formatted Diff Diff
Patch (9.45 KB, patch) 2022-04-21 21:39 PDT, Simon Fraser (smfr)	no flags	Details Formatted Diff Diff
Patch (10.25 KB, patch) 2022-04-22 09:52 PDT, Simon Fraser (smfr)	ews-feeder: commit-queue-	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Ryan Haddad

Comment 1 2022-04-21 17:14:59 PDT

rdar://92105675

Simon Fraser (smfr)

Comment 2 2022-04-21 20:28:13 PDT

Also reproduces on macOS.

Simon Fraser (smfr)

Comment 3 2022-04-21 20:34:53 PDT

The focus call is triggering a call to stopAsyncAnimatedScroll: WebPageProxy 6 activityStateDidChange - mayHaveChanged active window WebPageProxy 6 dispatchActivityStateChange - potentiallyChangedActivityStateFlags active window WebPageProxy 6 dispatchActivityStateChange: state changed from active window, focused, visible, visible or occluded, in-window to focused, visible, visible or occluded, in-window WebPage 7 setActivityState to focused, visible, visible or occluded, in-window RenderLayer 0x59b04d540 584x250 stopAsyncAnimatedScroll

Simon Fraser (smfr)

Comment 4 2022-04-21 20:40:36 PDT

That might be a red herring, or only happen the first time. On every subsequent button click, there's no activity state change, but the animated scroll is getting cancelled because FrameView::scrollToFocusedElementInternal() runs on a timer.

Simon Fraser (smfr)

Comment 5 2022-04-21 21:37:32 PDT

Created attachment 458112 [details] Patch

Simon Fraser (smfr)

Comment 6 2022-04-21 21:39:58 PDT

Created attachment 458113 [details] Patch

Simon Fraser (smfr)

Comment 7 2022-04-22 09:52:17 PDT

Created attachment 458155 [details] Patch

EWS

Comment 8 2022-04-22 15:53:35 PDT

Committed r293260 (249904@main): <https://commits.webkit.org/249904@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 458155 [details].

Liam DeBeasi

Comment 9 2022-04-25 06:34:31 PDT

Thank you for the fix!

Note You need to log in before you can comment on or make changes to this bug.