Title: [259271] branches/safari-610.1.7-branch
Revision
259271
Author
alanc...@apple.com
Date
2020-03-30 19:09:24 -0700 (Mon, 30 Mar 2020)

Log Message

Cherry-pick r258804. rdar://problem/61082982

    [iPadOS] Yahoo! search results are sometimes zoomed in a little
    https://bugs.webkit.org/show_bug.cgi?id=209356
    <rdar://problem/60563952>

    Reviewed by Tim Horton.

    Source/WebKit:

    When the web content process uses `WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport
    configuration change) on iOS, it's possible for this new scale to be replaced by a previous scale when
    dispatching the next visible content rect update. Consider the following scenario:

    1. A remote layer tree transaction is sent to the UI process containing scale `a`.
    2. `WebPage::scalePage` is called with a scale `b`.
    3. A visible content rect update with scale `a` is scheduled, sent to the web process and dispatched.
    4. The page scale reverts to `a`.

    This bug exercises the above scenario: the Yahoo search results page specifies a responsive viewport
    (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after
    the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after
    a remote layer tree transaction with the old scale but before the next visible content rect update containing
    that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This
    same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale
    after the viewport configuration change may be overridden by an incoming visible content rect update.

    To fix this, we add a mechanism to detect when the page scale has been changed by the web process (e.g. after a
    viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a
    visible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit
    identifier when we changed the page scale, don't set the page scale factor using this incoming scale; instead,
    wait for the next visible content rect update (which will contain the new scale).

    Fixes an existing flaky test: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html

    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::close):
    (WebKit::WebPage::scalePage):
    (WebKit::WebPage::platformDidScalePage):

    Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS version.

    (WebKit::WebPage::didCommitLoad):
    (WebKit::WebPage::didFinishDocumentLoad):
    (WebKit::WebPage::didFinishLoad):

    Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to fit content
    timer with a call to `shrinkToFitContent` instead.

    * WebProcess/WebPage/WebPage.h:

    Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the
    page scale via the web process. This is set in `platformDidScalePage` below.

    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::dynamicViewportSizeUpdate):
    (WebKit::WebPage::shrinkToFitContent):

    Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport
    actually changed.

    (WebKit::WebPage::updateVisibleContentRects):

    Ignore the incoming page scale when updating visible content rects if it:
    1. Is the same as the last page scale we sent via layer tree commit.
    2. After sending the above scale, we've since adjusted the page scale such that it is no longer the same.

    (WebKit::WebPage::platformDidScalePage):

    Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.

    (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.
    (WebKit::WebPage::shrinkToFitContentTimerFired): Deleted.

    Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`
    directly. This was a source of flakiness when trying to reproduce the bug, and doesn't seem to serve any
    purpose since we shrink-to-fit after dispatching the "DOMContentLoaded" and "load" events anyways.

    (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.

    LayoutTests:

    Remove failing expectations for fast/viewport/ios/device-width-viewport-after-changing-view-scale.html.

    * platform/ios-wk2/TestExpectations:

    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258804 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Modified Paths

Diff

Modified: branches/safari-610.1.7-branch/LayoutTests/ChangeLog (259270 => 259271)


--- branches/safari-610.1.7-branch/LayoutTests/ChangeLog	2020-03-31 02:09:21 UTC (rev 259270)
+++ branches/safari-610.1.7-branch/LayoutTests/ChangeLog	2020-03-31 02:09:24 UTC (rev 259271)
@@ -1,5 +1,107 @@
 2020-03-30  Alan Coon  <alanc...@apple.com>
 
+        Cherry-pick r258804. rdar://problem/61082982
+
+    [iPadOS] Yahoo! search results are sometimes zoomed in a little
+    https://bugs.webkit.org/show_bug.cgi?id=209356
+    <rdar://problem/60563952>
+    
+    Reviewed by Tim Horton.
+    
+    Source/WebKit:
+    
+    When the web content process uses `WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport
+    configuration change) on iOS, it's possible for this new scale to be replaced by a previous scale when
+    dispatching the next visible content rect update. Consider the following scenario:
+    
+    1. A remote layer tree transaction is sent to the UI process containing scale `a`.
+    2. `WebPage::scalePage` is called with a scale `b`.
+    3. A visible content rect update with scale `a` is scheduled, sent to the web process and dispatched.
+    4. The page scale reverts to `a`.
+    
+    This bug exercises the above scenario: the Yahoo search results page specifies a responsive viewport
+    (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after
+    the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after
+    a remote layer tree transaction with the old scale but before the next visible content rect update containing
+    that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This
+    same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale
+    after the viewport configuration change may be overridden by an incoming visible content rect update.
+    
+    To fix this, we add a mechanism to detect when the page scale has been changed by the web process (e.g. after a
+    viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a
+    visible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit
+    identifier when we changed the page scale, don't set the page scale factor using this incoming scale; instead,
+    wait for the next visible content rect update (which will contain the new scale).
+    
+    Fixes an existing flaky test: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html
+    
+    * WebProcess/WebPage/WebPage.cpp:
+    (WebKit::WebPage::close):
+    (WebKit::WebPage::scalePage):
+    (WebKit::WebPage::platformDidScalePage):
+    
+    Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS version.
+    
+    (WebKit::WebPage::didCommitLoad):
+    (WebKit::WebPage::didFinishDocumentLoad):
+    (WebKit::WebPage::didFinishLoad):
+    
+    Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to fit content
+    timer with a call to `shrinkToFitContent` instead.
+    
+    * WebProcess/WebPage/WebPage.h:
+    
+    Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the
+    page scale via the web process. This is set in `platformDidScalePage` below.
+    
+    * WebProcess/WebPage/ios/WebPageIOS.mm:
+    (WebKit::WebPage::dynamicViewportSizeUpdate):
+    (WebKit::WebPage::shrinkToFitContent):
+    
+    Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport
+    actually changed.
+    
+    (WebKit::WebPage::updateVisibleContentRects):
+    
+    Ignore the incoming page scale when updating visible content rects if it:
+    1. Is the same as the last page scale we sent via layer tree commit.
+    2. After sending the above scale, we've since adjusted the page scale such that it is no longer the same.
+    
+    (WebKit::WebPage::platformDidScalePage):
+    
+    Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.
+    
+    (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.
+    (WebKit::WebPage::shrinkToFitContentTimerFired): Deleted.
+    
+    Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`
+    directly. This was a source of flakiness when trying to reproduce the bug, and doesn't seem to serve any
+    purpose since we shrink-to-fit after dispatching the "DOMContentLoaded" and "load" events anyways.
+    
+    (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.
+    
+    LayoutTests:
+    
+    Remove failing expectations for fast/viewport/ios/device-width-viewport-after-changing-view-scale.html.
+    
+    * platform/ios-wk2/TestExpectations:
+    
+    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258804 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+    2020-03-20  Wenson Hsieh  <wenson_hs...@apple.com>
+
+            [iPadOS] Yahoo! search results are sometimes zoomed in a little
+            https://bugs.webkit.org/show_bug.cgi?id=209356
+            <rdar://problem/60563952>
+
+            Reviewed by Tim Horton.
+
+            Remove failing expectations for fast/viewport/ios/device-width-viewport-after-changing-view-scale.html.
+
+            * platform/ios-wk2/TestExpectations:
+
+2020-03-30  Alan Coon  <alanc...@apple.com>
+
         Cherry-pick r258282. rdar://problem/61082987
 
     icloud.com Notes text in titles and headings is distorted

Modified: branches/safari-610.1.7-branch/LayoutTests/platform/ios-wk2/TestExpectations (259270 => 259271)


--- branches/safari-610.1.7-branch/LayoutTests/platform/ios-wk2/TestExpectations	2020-03-31 02:09:21 UTC (rev 259270)
+++ branches/safari-610.1.7-branch/LayoutTests/platform/ios-wk2/TestExpectations	2020-03-31 02:09:24 UTC (rev 259271)
@@ -1282,7 +1282,6 @@
 
 webkit.org/b/194826 [ Debug ] http/tests/resourceLoadStatistics/do-not-block-top-level-navigation-redirect.html [ Pass Timeout ]
 
-webkit.org/b/195341 fast/viewport/ios/device-width-viewport-after-changing-view-scale.html [ Pass Failure ]
 webkit.org/b/195341 compositing/ios/overflow-scroll-update-overlap.html [ ImageOnlyFailure ]
 
 webkit.org/b/196013 fast/scrolling/rtl-scrollbars-sticky-overflow-scroll-2.html [ ImageOnlyFailure ]

Modified: branches/safari-610.1.7-branch/Source/WebKit/ChangeLog (259270 => 259271)


--- branches/safari-610.1.7-branch/Source/WebKit/ChangeLog	2020-03-31 02:09:21 UTC (rev 259270)
+++ branches/safari-610.1.7-branch/Source/WebKit/ChangeLog	2020-03-31 02:09:24 UTC (rev 259271)
@@ -1,5 +1,173 @@
 2020-03-30  Alan Coon  <alanc...@apple.com>
 
+        Cherry-pick r258804. rdar://problem/61082982
+
+    [iPadOS] Yahoo! search results are sometimes zoomed in a little
+    https://bugs.webkit.org/show_bug.cgi?id=209356
+    <rdar://problem/60563952>
+    
+    Reviewed by Tim Horton.
+    
+    Source/WebKit:
+    
+    When the web content process uses `WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport
+    configuration change) on iOS, it's possible for this new scale to be replaced by a previous scale when
+    dispatching the next visible content rect update. Consider the following scenario:
+    
+    1. A remote layer tree transaction is sent to the UI process containing scale `a`.
+    2. `WebPage::scalePage` is called with a scale `b`.
+    3. A visible content rect update with scale `a` is scheduled, sent to the web process and dispatched.
+    4. The page scale reverts to `a`.
+    
+    This bug exercises the above scenario: the Yahoo search results page specifies a responsive viewport
+    (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after
+    the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after
+    a remote layer tree transaction with the old scale but before the next visible content rect update containing
+    that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This
+    same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale
+    after the viewport configuration change may be overridden by an incoming visible content rect update.
+    
+    To fix this, we add a mechanism to detect when the page scale has been changed by the web process (e.g. after a
+    viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a
+    visible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit
+    identifier when we changed the page scale, don't set the page scale factor using this incoming scale; instead,
+    wait for the next visible content rect update (which will contain the new scale).
+    
+    Fixes an existing flaky test: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html
+    
+    * WebProcess/WebPage/WebPage.cpp:
+    (WebKit::WebPage::close):
+    (WebKit::WebPage::scalePage):
+    (WebKit::WebPage::platformDidScalePage):
+    
+    Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS version.
+    
+    (WebKit::WebPage::didCommitLoad):
+    (WebKit::WebPage::didFinishDocumentLoad):
+    (WebKit::WebPage::didFinishLoad):
+    
+    Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to fit content
+    timer with a call to `shrinkToFitContent` instead.
+    
+    * WebProcess/WebPage/WebPage.h:
+    
+    Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the
+    page scale via the web process. This is set in `platformDidScalePage` below.
+    
+    * WebProcess/WebPage/ios/WebPageIOS.mm:
+    (WebKit::WebPage::dynamicViewportSizeUpdate):
+    (WebKit::WebPage::shrinkToFitContent):
+    
+    Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport
+    actually changed.
+    
+    (WebKit::WebPage::updateVisibleContentRects):
+    
+    Ignore the incoming page scale when updating visible content rects if it:
+    1. Is the same as the last page scale we sent via layer tree commit.
+    2. After sending the above scale, we've since adjusted the page scale such that it is no longer the same.
+    
+    (WebKit::WebPage::platformDidScalePage):
+    
+    Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.
+    
+    (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.
+    (WebKit::WebPage::shrinkToFitContentTimerFired): Deleted.
+    
+    Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`
+    directly. This was a source of flakiness when trying to reproduce the bug, and doesn't seem to serve any
+    purpose since we shrink-to-fit after dispatching the "DOMContentLoaded" and "load" events anyways.
+    
+    (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.
+    
+    LayoutTests:
+    
+    Remove failing expectations for fast/viewport/ios/device-width-viewport-after-changing-view-scale.html.
+    
+    * platform/ios-wk2/TestExpectations:
+    
+    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258804 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+    2020-03-20  Wenson Hsieh  <wenson_hs...@apple.com>
+
+            [iPadOS] Yahoo! search results are sometimes zoomed in a little
+            https://bugs.webkit.org/show_bug.cgi?id=209356
+            <rdar://problem/60563952>
+
+            Reviewed by Tim Horton.
+
+            When the web content process uses `WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport
+            configuration change) on iOS, it's possible for this new scale to be replaced by a previous scale when
+            dispatching the next visible content rect update. Consider the following scenario:
+
+            1. A remote layer tree transaction is sent to the UI process containing scale `a`.
+            2. `WebPage::scalePage` is called with a scale `b`.
+            3. A visible content rect update with scale `a` is scheduled, sent to the web process and dispatched.
+            4. The page scale reverts to `a`.
+
+            This bug exercises the above scenario: the Yahoo search results page specifies a responsive viewport
+            (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after
+            the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after
+            a remote layer tree transaction with the old scale but before the next visible content rect update containing
+            that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This
+            same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale
+            after the viewport configuration change may be overridden by an incoming visible content rect update.
+
+            To fix this, we add a mechanism to detect when the page scale has been changed by the web process (e.g. after a
+            viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a
+            visible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit
+            identifier when we changed the page scale, don't set the page scale factor using this incoming scale; instead,
+            wait for the next visible content rect update (which will contain the new scale).
+
+            Fixes an existing flaky test: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html
+
+            * WebProcess/WebPage/WebPage.cpp:
+            (WebKit::WebPage::close):
+            (WebKit::WebPage::scalePage):
+            (WebKit::WebPage::platformDidScalePage):
+
+            Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS version.
+
+            (WebKit::WebPage::didCommitLoad):
+            (WebKit::WebPage::didFinishDocumentLoad):
+            (WebKit::WebPage::didFinishLoad):
+
+            Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to fit content
+            timer with a call to `shrinkToFitContent` instead.
+
+            * WebProcess/WebPage/WebPage.h:
+
+            Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the
+            page scale via the web process. This is set in `platformDidScalePage` below.
+
+            * WebProcess/WebPage/ios/WebPageIOS.mm:
+            (WebKit::WebPage::dynamicViewportSizeUpdate):
+            (WebKit::WebPage::shrinkToFitContent):
+
+            Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport
+            actually changed.
+
+            (WebKit::WebPage::updateVisibleContentRects):
+
+            Ignore the incoming page scale when updating visible content rects if it:
+            1. Is the same as the last page scale we sent via layer tree commit.
+            2. After sending the above scale, we've since adjusted the page scale such that it is no longer the same.
+
+            (WebKit::WebPage::platformDidScalePage):
+
+            Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.
+
+            (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.
+            (WebKit::WebPage::shrinkToFitContentTimerFired): Deleted.
+
+            Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`
+            directly. This was a source of flakiness when trying to reproduce the bug, and doesn't seem to serve any
+            purpose since we shrink-to-fit after dispatching the "DOMContentLoaded" and "load" events anyways.
+
+            (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.
+
+2020-03-30  Alan Coon  <alanc...@apple.com>
+
         Cherry-pick r258659. rdar://problem/61083009
 
     REGRESSION (r257214): Targeted preview animates to the wrong place when dropping in editable content

Modified: branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/WebPage.cpp (259270 => 259271)


--- branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/WebPage.cpp	2020-03-31 02:09:21 UTC (rev 259270)
+++ branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/WebPage.cpp	2020-03-31 02:09:24 UTC (rev 259271)
@@ -454,9 +454,6 @@
     , m_hostFileDescriptor(WTFMove(parameters.hostFileDescriptor))
 #endif
     , m_webPageProxyIdentifier(parameters.webPageProxyIdentifier)
-#if ENABLE(VIEWPORT_RESIZING)
-    , m_shrinkToFitContentTimer(*this, &WebPage::shrinkToFitContentTimerFired, 0_s)
-#endif
 #if ENABLE(TEXT_AUTOSIZING)
     , m_textAutoSizingAdjustmentTimer(*this, &WebPage::textAutoSizingAdjustmentTimerFired)
 #endif
@@ -1457,10 +1454,6 @@
     m_determinePrimarySnapshottedPlugInTimer.stop();
 #endif
 
-#if ENABLE(VIEWPORT_RESIZING)
-    m_shrinkToFitContentTimer.stop();
-#endif
-
 #if ENABLE(TEXT_AUTOSIZING)
     m_textAutoSizingAdjustmentTimer.stop();
 #endif
@@ -2072,8 +2065,17 @@
 #endif
 
     send(Messages::WebPageProxy::PageScaleFactorDidChange(scale));
+    platformDidScalePage();
 }
 
+#if !PLATFORM(IOS_FAMILY)
+
+void WebPage::platformDidScalePage()
+{
+}
+
+#endif
+
 void WebPage::scalePageInViewCoordinates(double scale, IntPoint centerInViewCoordinates)
 {
     double totalScale = scale * viewScaleFactor();
@@ -5915,6 +5917,7 @@
     m_userHasChangedPageScaleFactor = false;
     m_estimatedLatency = Seconds(1.0 / 60);
     m_shouldRevealCurrentSelectionAfterInsertion = true;
+    m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage = WTF::nullopt;
 
 #if ENABLE(IOS_TOUCH_EVENTS)
     WebProcess::singleton().eventDispatcher().clearQueuedTouchEventsForPage(*this);
@@ -5941,10 +5944,6 @@
         viewportConfigurationChanged();
 #endif // ENABLE(META_VIEWPORT)
 
-#if ENABLE(VIEWPORT_RESIZING)
-    m_shrinkToFitContentTimer.stop();
-#endif
-
 #if ENABLE(TEXT_AUTOSIZING)
     m_textAutoSizingAdjustmentTimer.stop();
 #endif
@@ -5970,7 +5969,7 @@
         return;
 
 #if ENABLE(VIEWPORT_RESIZING)
-    scheduleShrinkToFitContent();
+    shrinkToFitContent(ZoomToInitialScale::Yes);
 #endif
 }
 
@@ -5985,12 +5984,10 @@
     m_readyToFindPrimarySnapshottedPlugin = true;
     LOG(Plugins, "Primary Plug-In Detection: triggering detection from didFinishLoad (marking as ready to detect).");
     m_determinePrimarySnapshottedPlugInTimer.startOneShot(0_s);
-#else
-    UNUSED_PARAM(frame);
 #endif
 
 #if ENABLE(VIEWPORT_RESIZING)
-    scheduleShrinkToFitContent();
+    shrinkToFitContent(ZoomToInitialScale::Yes);
 #endif
 }
 

Modified: branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/WebPage.h (259270 => 259271)


--- branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/WebPage.h	2020-03-31 02:09:21 UTC (rev 259270)
+++ branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/WebPage.h	2020-03-31 02:09:24 UTC (rev 259271)
@@ -1366,9 +1366,7 @@
 #endif
 
 #if ENABLE(VIEWPORT_RESIZING)
-    void scheduleShrinkToFitContent();
-    void shrinkToFitContentTimerFired();
-    bool immediatelyShrinkToFitContent();
+    void shrinkToFitContent(ZoomToInitialScale = ZoomToInitialScale::No);
 #endif
 
 #if PLATFORM(IOS_FAMILY) && ENABLE(DATA_INTERACTION)
@@ -1718,6 +1716,8 @@
     void sendMessageToWebExtensionWithReply(UserMessage&&, CompletionHandler<void(UserMessage&&)>&&);
 #endif
 
+    void platformDidScalePage();
+
     WebCore::PageIdentifier m_identifier;
 
     std::unique_ptr<WebCore::Page> m_page;
@@ -1991,6 +1991,7 @@
     TransactionID m_lastTransactionIDWithScaleChange;
 
     CompletionHandler<void(InteractionInformationAtPosition&&)> m_pendingSynchronousPositionInformationReply;
+    Optional<std::pair<TransactionID, double>> m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage;
 #endif
 
     WebCore::Timer m_layerVolatilityTimer;
@@ -2064,9 +2065,6 @@
 #endif
     WebPageProxyIdentifier m_webPageProxyIdentifier;
     WebCore::IntSize m_lastSentIntrinsicContentSize;
-#if ENABLE(VIEWPORT_RESIZING)
-    WebCore::DeferrableOneShotTimer m_shrinkToFitContentTimer;
-#endif
 #if HAVE(VISIBILITY_PROPAGATION_VIEW)
     std::unique_ptr<LayerHostingContext> m_contextForVisibilityPropagation;
 #endif

Modified: branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm (259270 => 259271)


--- branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm	2020-03-31 02:09:21 UTC (rev 259270)
+++ branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm	2020-03-31 02:09:24 UTC (rev 259271)
@@ -3441,8 +3441,7 @@
     m_page->updateRendering();
 
 #if ENABLE(VIEWPORT_RESIZING)
-    if (immediatelyShrinkToFitContent())
-        viewportConfigurationChanged();
+    shrinkToFitContent();
 #endif
 
     m_drawingArea->scheduleRenderingUpdate();
@@ -3527,48 +3526,34 @@
 
 #if ENABLE(VIEWPORT_RESIZING)
 
-void WebPage::scheduleShrinkToFitContent()
+void WebPage::shrinkToFitContent(ZoomToInitialScale zoomToInitialScale)
 {
     if (m_isClosed)
         return;
 
-    m_shrinkToFitContentTimer.restart();
-}
-
-void WebPage::shrinkToFitContentTimerFired()
-{
-    if (immediatelyShrinkToFitContent())
-        viewportConfigurationChanged(ZoomToInitialScale::Yes);
-}
-
-bool WebPage::immediatelyShrinkToFitContent()
-{
-    if (m_isClosed)
-        return false;
-
     if (!m_page->settings().allowViewportShrinkToFitContent())
-        return false;
+        return;
 
     if (m_useTestingViewportConfiguration)
-        return false;
+        return;
 
     if (!shouldIgnoreMetaViewport())
-        return false;
+        return;
 
     if (!m_viewportConfiguration.viewportArguments().shrinkToFit)
-        return false;
+        return;
 
     if (m_viewportConfiguration.canIgnoreScalingConstraints())
-        return false;
+        return;
 
     auto mainFrame = makeRefPtr(m_mainFrame->coreFrame());
     if (!mainFrame)
-        return false;
+        return;
 
     auto view = makeRefPtr(mainFrame->view());
     auto mainDocument = makeRefPtr(mainFrame->document());
     if (!view || !mainDocument)
-        return false;
+        return;
 
     mainDocument->updateLayout();
 
@@ -3585,7 +3570,7 @@
     int originalLayoutWidth = m_viewportConfiguration.layoutWidth();
     int originalHorizontalOverflowAmount = originalContentWidth - originalViewWidth;
     if (originalHorizontalOverflowAmount <= toleratedHorizontalScrollingDistance || originalLayoutWidth >= maximumExpandedLayoutWidth || originalContentWidth <= originalViewWidth || originalContentWidth > maximumContentWidthBeforeAvoidingShrinkToFit)
-        return false;
+        return;
 
     auto changeMinimumEffectiveDeviceWidth = [this, mainDocument] (int targetLayoutWidth) -> bool {
         if (m_viewportConfiguration.setMinimumEffectiveDeviceWidth(targetLayoutWidth)) {
@@ -3605,7 +3590,7 @@
 
     // FIXME (197429): Consider additionally logging an error message to the console if a responsive meta viewport tag was used.
     RELEASE_LOG(ViewportSizing, "Shrink-to-fit: content width %d => %d; layout width %d => %d", originalContentWidth, view->contentsWidth(), originalLayoutWidth, m_viewportConfiguration.layoutWidth());
-    return true;
+    viewportConfigurationChanged(zoomToInitialScale);
 }
 
 #endif // ENABLE(VIEWPORT_RESIZING)
@@ -3816,22 +3801,38 @@
 
     IntPoint scrollPosition = roundedIntPoint(visibleContentRectUpdateInfo.unobscuredContentRect().location());
 
-    bool hasSetPageScale = false;
-    if (scaleFromUIProcess) {
-        m_scaleWasSetByUIProcess = true;
-        m_hasStablePageScaleFactor = m_isInStableState;
+    bool pageHasBeenScaledSinceLastLayerTreeCommitThatChangedPageScale = ([&] {
+        if (!m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage)
+            return false;
 
-        m_dynamicSizeUpdateHistory.clear();
+        if (areEssentiallyEqualAsFloat(scaleToUse, m_page->pageScaleFactor()))
+            return false;
 
-        m_page->setPageScaleFactor(scaleFromUIProcess.value(), scrollPosition, m_isInStableState);
-        hasSetPageScale = true;
-        send(Messages::WebPageProxy::PageScaleFactorDidChange(scaleFromUIProcess.value()));
+        auto [transactionIdBeforeScalingPage, scaleBeforeScalingPage] = *m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage;
+        if (!areEssentiallyEqualAsFloat(scaleBeforeScalingPage, scaleToUse))
+            return false;
+
+        return transactionIdBeforeScalingPage >= visibleContentRectUpdateInfo.lastLayerTreeTransactionID();
+    })();
+
+    if (!pageHasBeenScaledSinceLastLayerTreeCommitThatChangedPageScale) {
+        bool hasSetPageScale = false;
+        if (scaleFromUIProcess) {
+            m_scaleWasSetByUIProcess = true;
+            m_hasStablePageScaleFactor = m_isInStableState;
+
+            m_dynamicSizeUpdateHistory.clear();
+
+            m_page->setPageScaleFactor(scaleFromUIProcess.value(), scrollPosition, m_isInStableState);
+            hasSetPageScale = true;
+            send(Messages::WebPageProxy::PageScaleFactorDidChange(scaleFromUIProcess.value()));
+        }
+
+        if (!hasSetPageScale && m_isInStableState) {
+            m_page->setPageScaleFactor(scaleToUse, scrollPosition, true);
+            hasSetPageScale = true;
+        }
     }
-    
-    if (!hasSetPageScale && m_isInStableState) {
-        m_page->setPageScaleFactor(scaleToUse, scrollPosition, true);
-        hasSetPageScale = true;
-    }
 
     auto& frame = m_page->mainFrame();
     FrameView& frameView = *frame.view();
@@ -4248,6 +4249,12 @@
     scheduleFullEditorStateUpdate();
 }
 
+void WebPage::platformDidScalePage()
+{
+    auto transactionID = downcast<RemoteLayerTreeDrawingArea>(*m_drawingArea).lastCommittedTransactionID();
+    m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage = {{ transactionID, m_lastTransactionPageScaleFactor }};
+}
+
 #if USE(QUICK_LOOK)
 
 void WebPage::didStartLoadForQuickLookDocumentInMainFrame(const String& fileName, const String& uti)
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to