[Webkit-unassigned] [Bug 198217] iOS: REGRESSION(async scroll): Caret doesn't scroll when scrolling textarea

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=198217

--- Comment #3 from Wenson Hsieh <wenson_hsieh at apple.com> ---
I looked into this and made some observations:

1.  How did it work in iOS 12?

Selection would not update during async scrolling; after scrolling ends, the
selection rect would then appear in the right place. In iOS 12, we get a
bunch of calls to AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll
with the scrollingLayerPositionAction being Sync. Then, at the end, we get
one with Set instead. This call with ScrollingLayerPositionAction::Set at
the end allows us to update the selection to the final state.

What is responsible for scheduling the final scroll position update using
ScrollingLayerPositionAction::Set?

    ↪ AsyncScrollingCoordinator::scheduleUpdateScrollPositionAfterAsyncScroll
      …
    ↪ RemoteScrollingCoordinatorProxy::scrollingTreeNodeDidScroll
    ↪ ScrollingTree::scrollPositionChangedViaDelegatedScrolling
    ↪ -[WKScrollingNodeScrollViewDelegate scrollViewDidEndDecelerating:]

...in the case where the scrolling gesture ends with momentum; otherwise,
the last update is triggered via -[WKScrollingNodeScrollViewDelegate
scrollViewDidEndDragging:willDecelerate:]. In both cases, the important bit
is that the _inUserInteraction flag is set to NO, which causes us to use
ScrollingLayerPositionAction::Set instead of ScrollingLayerPositionAction::Sync.

2.  What happens in iOS 13?

During async scrolling, we only get ScrollingLayerPositionAction::Sync.
There is no Set action at the end, so we never try to send the final editor
state update after async scrolling. This is due to two reasons:

a.  When scrolling ends, we no longer push a scrolling update through
    RemoteScrollingCoordinatorProxy, since
    ScrollingTreeScrollingNode::wasScrolledByDelegatedScrolling now bails if
    the scroll position was unchanged (that is, the check for
    scrollPositionChanged).

b.  Even if we did push a scrolling update after scrolling ends, we no
    longer use ScrollingLayerPositionAction::Set if we're not in user
    interaction (that is, if userInteraction is false in
    ScrollingTreeScrollingNodeDelegateIOS::scrollViewDidScroll), so we would
    not end up scheduling an editor state update in the web process anyways.

Tweaking the code to avoid these two conditions seems to "fix" this bug (at
least, by making it behave like it does in iOS 12 and prior).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190630/00f2673a/attachment-0001.html>