Title: [240298] trunk/Source/WebKit
Revision
240298
Author
an...@apple.com
Date
2019-01-22 14:31:36 -0800 (Tue, 22 Jan 2019)

Log Message

[iOS] Flash when swiping back to Google search result page
https://bugs.webkit.org/show_bug.cgi?id=193668
<rdar://problem/47071684>

Reviewed by Simon Fraser.

If the google page is scrolled, there is sometimes a short flash.

When restoring the page state we also restore exposedContentRect which is used to determine
which part of the page to create layers for. Scroll position is restored by the UI process
later so we rely on this to get the right layers for the initial view update.

A viewport configuration update may sometimes trample over the restored exposedContentRect,
moving it to top left. In this case the initial layer tree unfreeze commit may not have
layers to cover the actual visible view position.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didCommitLoad):
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::restorePageState):

Set a bit to indicate we have already restored the exposedContentRect.

(WebKit::WebPage::viewportConfigurationChanged):

Only reset exposedContentRect if wasn't already set by restorePageState.

Modified Paths

Diff

Modified: trunk/Source/WebKit/ChangeLog (240297 => 240298)


--- trunk/Source/WebKit/ChangeLog	2019-01-22 22:10:51 UTC (rev 240297)
+++ trunk/Source/WebKit/ChangeLog	2019-01-22 22:31:36 UTC (rev 240298)
@@ -1,3 +1,33 @@
+2019-01-22  Antti Koivisto  <an...@apple.com>
+
+        [iOS] Flash when swiping back to Google search result page
+        https://bugs.webkit.org/show_bug.cgi?id=193668
+        <rdar://problem/47071684>
+
+        Reviewed by Simon Fraser.
+
+        If the google page is scrolled, there is sometimes a short flash.
+
+        When restoring the page state we also restore exposedContentRect which is used to determine
+        which part of the page to create layers for. Scroll position is restored by the UI process
+        later so we rely on this to get the right layers for the initial view update.
+
+        A viewport configuration update may sometimes trample over the restored exposedContentRect,
+        moving it to top left. In this case the initial layer tree unfreeze commit may not have
+        layers to cover the actual visible view position.
+
+        * WebProcess/WebPage/WebPage.cpp:
+        (WebKit::WebPage::didCommitLoad):
+        * WebProcess/WebPage/WebPage.h:
+        * WebProcess/WebPage/ios/WebPageIOS.mm:
+        (WebKit::WebPage::restorePageState):
+
+        Set a bit to indicate we have already restored the exposedContentRect.
+
+        (WebKit::WebPage::viewportConfigurationChanged):
+
+        Only reset exposedContentRect if wasn't already set by restorePageState.
+
 2019-01-22  Alex Christensen  <achristen...@webkit.org>
 
         Fix more builds.

Modified: trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp (240297 => 240298)


--- trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp	2019-01-22 22:10:51 UTC (rev 240297)
+++ trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp	2019-01-22 22:31:36 UTC (rev 240298)
@@ -5604,6 +5604,7 @@
     }
 #if PLATFORM(IOS_FAMILY)
     m_hasReceivedVisibleContentRectsAfterDidCommitLoad = false;
+    m_hasRestoredExposedContentRectAfterDidCommitLoad = false;
     m_scaleWasSetByUIProcess = false;
     m_userHasChangedPageScaleFactor = false;
     m_estimatedLatency = Seconds(1.0 / 60);

Modified: trunk/Source/WebKit/WebProcess/WebPage/WebPage.h (240297 => 240298)


--- trunk/Source/WebKit/WebProcess/WebPage/WebPage.h	2019-01-22 22:10:51 UTC (rev 240297)
+++ trunk/Source/WebKit/WebProcess/WebPage/WebPage.h	2019-01-22 22:31:36 UTC (rev 240298)
@@ -1710,7 +1710,9 @@
     RefPtr<WebCore::SecurityOrigin> m_potentialTapSecurityOrigin;
 
     WebCore::ViewportConfiguration m_viewportConfiguration;
+
     bool m_hasReceivedVisibleContentRectsAfterDidCommitLoad { false };
+    bool m_hasRestoredExposedContentRectAfterDidCommitLoad { false };
     bool m_scaleWasSetByUIProcess { false };
     bool m_userHasChangedPageScaleFactor { false };
     bool m_hasStablePageScaleFactor { true };

Modified: trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm (240297 => 240298)


--- trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm	2019-01-22 22:10:51 UTC (rev 240297)
+++ trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm	2019-01-22 22:31:36 UTC (rev 240298)
@@ -346,6 +346,7 @@
         Optional<FloatPoint> scrollPosition;
         if (historyItem.shouldRestoreScrollPosition()) {
             m_drawingArea->setExposedContentRect(historyItem.exposedContentRect());
+            m_hasRestoredExposedContentRectAfterDidCommitLoad = true;
             scrollPosition = FloatPoint(historyItem.scrollPosition());
         }
         send(Messages::WebPageProxy::RestorePageState(scrollPosition, frameView.scrollOrigin(), historyItem.obscuredInsets(), boundedScale));
@@ -2840,7 +2841,8 @@
 
         // FIXME: We could send down the obscured margins to find a better exposed rect and unobscured rect.
         // It is not a big deal at the moment because the tile coverage will always extend past the obscured bottom inset.
-        m_drawingArea->setExposedContentRect(FloatRect(scrollPosition, minimumLayoutSizeInDocumentCoordinates));
+        if (!m_hasRestoredExposedContentRectAfterDidCommitLoad)
+            m_drawingArea->setExposedContentRect(FloatRect(scrollPosition, minimumLayoutSizeInDocumentCoordinates));
     }
     scalePage(scale, scrollPosition);
     
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to