[webkit-changes] [WebKit/WebKit] 2bafc1: iOS 17: History back sometimes scrolls to top of t...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2bafc1bcaa71b44ba5bfbab41068b030034044dd
      https://github.com/WebKit/WebKit/commit/2bafc1bcaa71b44ba5bfbab41068b030034044dd
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    M Source/WebCore/dom/Document.cpp
    M Source/WebCore/loader/HistoryController.cpp
    M Source/WebCore/platform/ScrollView.cpp
    M Source/WebCore/platform/ScrollView.h
    M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
    M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
    M Tools/TestWebKitAPI/Tests/ios/ScrollViewInsetTests.mm
    A Tools/TestWebKitAPI/ios/scrollable-page.html

  Log Message:
  -----------
  iOS 17: History back sometimes scrolls to top of the page (with app banner)
https://bugs.webkit.org/show_bug.cgi?id=231563
rdar://117107620

Reviewed by Tim Horton.

Sometimes, navigating back to a page on iOS would fail to restore the scroll position to the correct
location. This happened when `WebPage::restorePageState()` hit the second mismatched
`minimumLayoutSizeInScrollViewCoordinates` clause, which made use of
`historyItem.unobscuredContentRect()`. This could happen when MobileSafari app banners were hidden
or shown. `historyItem.unobscuredContentRect()` had the wrong value in this case, containing a rect
that had a 0,0 location which triggered a scroll back to the top.

`historyItem.unobscuredContentRect()` was wrong because it was set in
`HistoryController::saveScrollPositionAndViewStateToItem()` which runs after we've reset the content
size in preparation for the navigation; note that this function uses
`frameView->cachedScrollPosition()`. So the fix is to cache `unobscuredContentRect()` and
`exposedContentRect()` in the same way.

This is messy; ScrollView shouldn't be in the business of storing caches related to page navigation,
but fixing that is out of scope for this change.

The API test navigates and goes back with a view size change, which triggers the bug.

Also add some release logging to help diagnose scroll restoration bugs.

* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setBackForwardCacheState):
* Source/WebCore/loader/HistoryController.cpp:
(WebCore::FrameLoader::HistoryController::saveScrollPositionAndViewStateToItem):
* Source/WebCore/platform/ScrollView.cpp:
(WebCore::ScrollView::cacheCurrentScrollState):
* Source/WebCore/platform/ScrollView.h:
(WebCore::ScrollView::cachedUnobscuredContentRect const):
(WebCore::ScrollView::cachedExposedContentRect const):
(WebCore::ScrollView::cacheCurrentScrollPosition): Deleted.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/ios/ScrollViewInsetTests.mm:
(TestWebKitAPI::TEST):
* Tools/TestWebKitAPI/ios/scrollable-page.html: Added.

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