[webkit-changes] [WebKit/WebKit] 2aa252: Accessing null RemoteScrollingCoordinatorProxy in ...

[Abrar Rahman Protyasha]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2aa252bfd9f1edb9b20d8c4ec897890fd284a036
      https://github.com/WebKit/WebKit/commit/2aa252bfd9f1edb9b20d8c4ec897890fd284a036
  Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
  Date:   2023-04-07 (Fri, 07 Apr 2023)

  Changed paths:
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

  Log Message:
  -----------
  Accessing null RemoteScrollingCoordinatorProxy in [WKWebViewIOS _didFinishScrolling]
https://bugs.webkit.org/show_bug.cgi?id=255162
rdar://106894608

Reviewed by Wenson Hsieh.

We're seeing null derefs of a `RemoteScrollingCoordinatorProxy` at
[WKWebViewIOS _didFinishScrolling] in situations where a web view is
closed out during a scroll operation.

This regression surfaced from https://commits.webkit.org/260975@main
because it (correctly) changed the relative order of destruction between
the `DrawingAreaProxy` and the `RemoteScrollingCoordinatorProxy` (and
the `RemoteScrollingTree` it encompasses), which meant that there could
be situations where closing or switching out a web view in the middle of
a scroll operation would lead to a null deref of the
`RemoteScrollingCoordinatorProxy` held by the `WebPageProxy`.

In this patch, we add a null check on the
`RemoteScrollingCoordinatorProxy` instance held by `WebPageProxy` in two
different places:

- In `_didFinishScrolling`. This is OK to do because the web view has
  closed out by this point anyway (and `RemoteScrollingTree` instance
  has been destructed), so the `setRootNodeIsInUserScroll` method call
  would be a no-op anyway.
- In `scrollViewWillBeginDragging`. This is OK for much the same reason.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView scrollViewWillBeginDragging:]):
(-[WKWebView _didFinishScrolling:]):

Canonical link: https://commits.webkit.org/262748@main