- 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)