haikuwebkit/Source/WebCore/page/ViewportConfiguration.h

214 lines
9.2 KiB
C
Raw Permalink Normal View History

[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
/*
* Copyright (C) 2005-2014 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY APPLE INC. AND ITS CONTRIBUTORS ``AS IS''
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR ITS CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGE.
*/
#pragma once
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
[Extra zoom mode] Google search results are excessively zoomed in https://bugs.webkit.org/show_bug.cgi?id=185347 <rdar://problem/39999778> Reviewed by Tim Horton. Source/WebCore: It turns out that basing minimum layout size and shrink-to-fit behaviors off of the `shrink-to-fit` viewport argument poses compatibility risks with web pages that already specify `shrink-to-fit` to opt out of default viewport shrinking behaviors in 1/3 multitasking mode on iPad. One way to resolve this is to introduce a new viewport meta content attribute to disable viewport heuristics in extra zoom mode. However, combined shrink-to-fit and minimum device width behaviors are difficult to describe using a single backwards-compatible viewport meta content attribute, and the need to suppress the default behavior of `shrink-to-fit=no` if such an attribute is not disabled further muddles our viewport story. After some internal deliberation, we’ve decided to experiment with a new meta tag named "disabled-adaptations". The content of this meta tag is a comma-separated list of adaptation names; if an adaptation name matches a known adaptation type (for instance, extra zoom mode), we disable the class of behaviors used to adapt web content. The first and only known adaptation type is extra zoom mode, which affects `shrink-to-fit` and layout size adjustments. See per-method changes below for more details. Test: fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * dom/Document.cpp: (WebCore::Document::processDisabledAdaptations): * dom/Document.h: (WebCore::Document::disabledAdaptations const): Add disabled adaptations to Document. Changes to disabled adaptations are not propagated if the parsed disabled adaptation types don't change; upon changing adaptation types, notify the client to adjust for the new disabled adaptations (currently, this only affects the viewport configuration). * dom/ViewportArguments.h: * html/HTMLMetaElement.cpp: (WebCore::HTMLMetaElement::process): * html/parser/HTMLPreloadScanner.cpp: (WebCore::TokenPreloadScanner::StartTagScanner::StartTagScanner): (WebCore::TokenPreloadScanner::StartTagScanner::processAttributes): (WebCore::TokenPreloadScanner::StartTagScanner::processAttribute): * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Restore the set of disabled adaptations when restoring a page from the cache. * page/Chrome.cpp: (WebCore::Chrome::dispatchDisabledAdaptationsDidChange const): * page/Chrome.h: * page/ChromeClient.h: Add plumbing for changes to the set of disabled adaptations. * page/DisabledAdaptations.cpp: Added. (WebCore::extraZoomModeAdaptationName): * page/DisabledAdaptations.h: Added. Introduce a header containing a new enum for the extra zoom mode adaptation, as well as a helper function to return the extra zoom mode adaptation name. * page/Page.cpp: (WebCore::Page::disabledAdaptations const): Returns the mainframe's set of adaptations to disable. * page/Page.h: * page/RemoteFrame.h: * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setDisabledAdaptationsMetaTagEnabled): (WebCore::RuntimeEnabledFeatures::disabledAdaptationsMetaTagEnabled const): Add a new runtime feature to gate handling the "disabled-adaptations" meta tag. * page/ViewportConfiguration.cpp: (WebCore::shouldOverrideShrinkToFitArgument): (WebCore::needsUpdateAfterChangingDisabledAdaptations): (WebCore::ViewportConfiguration::setDisabledAdaptations): (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthAndShrinkToFit const): Consult whether or not extra zoom mode adaptations are disabled, instead of the shrink-to-fit attribute value. (WebCore::ViewportConfiguration::updateConfiguration): * page/ViewportConfiguration.h: Add an OptionSet of disabled adaptation types to ViewportConfiguration. Updates to the adaptation type are propagated to the ViewportConfiguration from Document, through the ChromeClient and the client layer (refer to changes in WebKit). Once the OptionSet is changed, we recompute the viewport configuration only if needed by the platform. (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::disabledAdaptations const): * page/WindowFeatures.cpp: (WebCore::parseDisabledAdaptations): * page/WindowFeatures.h: Add a new helper to parse the meta content of a "disabled-adaptations" tag as an OptionSet of disabled adaptation types. The string is parsed by first splitting on the comma character, and then iterating over lower case, whitespace-stripped tokens to look for known adaptation names. So far, only extra zoom mode is supported. * testing/Internals.cpp: (WebCore::Internals::extraZoomModeAdaptationName const): * testing/Internals.h: * testing/Internals.idl: Expose the extra zoom mode adaptation name to the DOM, only when running layout tests. Source/WebKit: Adds a new experimental feature for the "disabled-adaptations" meta tag, and adds plumbing in WebKit to propagate disabled adaptation changes to the ViewportConfiguration. The experimental feature is on by default in extra zoom mode. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::dispatchDisabledAdaptationsDidChange const): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::disabledAdaptationsDidChange): * WebProcess/WebPage/WebPage.h: Source/WebKitLegacy/ios: Adds a WebKitLegacy method stub for disabled adaptation plumbing. * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::dispatchDisabledAdaptationsDidChange const): LayoutTests: Refactor an existing layout test to exercise disabled adaptations in extra zoom mode. * fast/viewport/extrazoom/viewport-change-min-device-width.html: Removed. * fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html: Added. Canonical link: https://commits.webkit.org/201100@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231779 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-15 01:07:36 +00:00
#include "DisabledAdaptations.h"
[iOS][WK2] Fix a few mistakes affecting the initial layout and the initial unobscured rect https://bugs.webkit.org/show_bug.cgi?id=132093 Source/WebCore: Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-04-23 Reviewed by Tim Horton. Change the minimum layout size to float point values to account for size defined on retina displays. The minimum layout size supports half-pixels, the value is rounded later when computing the layout size in document coordinates. * WebCore.exp.in: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::ViewportConfiguration): Setting the initial content size is incorrect. The layout size computation already take into account empty size for the first layout. Setting the content size upfront make the first computation incorrect when the viewport arguments specify the initial scale. (WebCore::ViewportConfiguration::setMinimumLayoutSize): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::minimumLayoutSize): Source/WebKit2: <rdar://problem/16703237> Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-04-23 Reviewed by Tim Horton. The user of WKWebView can setup a size on device pixels, which can add half a point to the minimum layout size. By rounding this up before applying the page scale, we ended up with rounding errors on the layout size and the transitory unobscured content rect. This patch fixes changes the minimal layout size to float point values to reduce the rounding problems. * UIProcess/API/Cocoa/WKWebView.mm: (setViewportConfigurationMinimumLayoutSize): (-[WKWebView _setMinimumLayoutSizeOverrideForMinimalUI:]): (-[WKWebView _beginAnimatedResizeWithUpdates:]): * UIProcess/WebPageProxy.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::dynamicViewportSizeUpdate): (WebKit::WebPageProxy::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPageProxy::setMinimumLayoutSizeForMinimalUI): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): Defaulting the content size to the minimum layout size only works if the initial-scale is 1. ViewportConfiguration knows exactly what to do before the first layout. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPage::setMinimumLayoutSizeForMinimalUI): (WebKit::WebPage::dynamicViewportSizeUpdate): A few fixes here: -setZoomedOutPageScaleFactor() was incorrectly using the initial scale. 99% of the time, initial scale and minimum scale are equal, but the page can specify something different with the viewport meta tag. -Use floating point for manipulating the minimum layout sizes, then round the value. -minimumLayoutSizeInDocumentCoordinate was scaled the wrong way around. (WebKit::WebPage::viewportConfigurationChanged): Canonical link: https://commits.webkit.org/150150@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@167735 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-04-24 02:13:06 +00:00
#include "FloatSize.h"
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
#include "IntSize.h"
#include "ViewportArguments.h"
#include <wtf/Noncopyable.h>
[Extra zoom mode] Google search results are excessively zoomed in https://bugs.webkit.org/show_bug.cgi?id=185347 <rdar://problem/39999778> Reviewed by Tim Horton. Source/WebCore: It turns out that basing minimum layout size and shrink-to-fit behaviors off of the `shrink-to-fit` viewport argument poses compatibility risks with web pages that already specify `shrink-to-fit` to opt out of default viewport shrinking behaviors in 1/3 multitasking mode on iPad. One way to resolve this is to introduce a new viewport meta content attribute to disable viewport heuristics in extra zoom mode. However, combined shrink-to-fit and minimum device width behaviors are difficult to describe using a single backwards-compatible viewport meta content attribute, and the need to suppress the default behavior of `shrink-to-fit=no` if such an attribute is not disabled further muddles our viewport story. After some internal deliberation, we’ve decided to experiment with a new meta tag named "disabled-adaptations". The content of this meta tag is a comma-separated list of adaptation names; if an adaptation name matches a known adaptation type (for instance, extra zoom mode), we disable the class of behaviors used to adapt web content. The first and only known adaptation type is extra zoom mode, which affects `shrink-to-fit` and layout size adjustments. See per-method changes below for more details. Test: fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * dom/Document.cpp: (WebCore::Document::processDisabledAdaptations): * dom/Document.h: (WebCore::Document::disabledAdaptations const): Add disabled adaptations to Document. Changes to disabled adaptations are not propagated if the parsed disabled adaptation types don't change; upon changing adaptation types, notify the client to adjust for the new disabled adaptations (currently, this only affects the viewport configuration). * dom/ViewportArguments.h: * html/HTMLMetaElement.cpp: (WebCore::HTMLMetaElement::process): * html/parser/HTMLPreloadScanner.cpp: (WebCore::TokenPreloadScanner::StartTagScanner::StartTagScanner): (WebCore::TokenPreloadScanner::StartTagScanner::processAttributes): (WebCore::TokenPreloadScanner::StartTagScanner::processAttribute): * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Restore the set of disabled adaptations when restoring a page from the cache. * page/Chrome.cpp: (WebCore::Chrome::dispatchDisabledAdaptationsDidChange const): * page/Chrome.h: * page/ChromeClient.h: Add plumbing for changes to the set of disabled adaptations. * page/DisabledAdaptations.cpp: Added. (WebCore::extraZoomModeAdaptationName): * page/DisabledAdaptations.h: Added. Introduce a header containing a new enum for the extra zoom mode adaptation, as well as a helper function to return the extra zoom mode adaptation name. * page/Page.cpp: (WebCore::Page::disabledAdaptations const): Returns the mainframe's set of adaptations to disable. * page/Page.h: * page/RemoteFrame.h: * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setDisabledAdaptationsMetaTagEnabled): (WebCore::RuntimeEnabledFeatures::disabledAdaptationsMetaTagEnabled const): Add a new runtime feature to gate handling the "disabled-adaptations" meta tag. * page/ViewportConfiguration.cpp: (WebCore::shouldOverrideShrinkToFitArgument): (WebCore::needsUpdateAfterChangingDisabledAdaptations): (WebCore::ViewportConfiguration::setDisabledAdaptations): (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthAndShrinkToFit const): Consult whether or not extra zoom mode adaptations are disabled, instead of the shrink-to-fit attribute value. (WebCore::ViewportConfiguration::updateConfiguration): * page/ViewportConfiguration.h: Add an OptionSet of disabled adaptation types to ViewportConfiguration. Updates to the adaptation type are propagated to the ViewportConfiguration from Document, through the ChromeClient and the client layer (refer to changes in WebKit). Once the OptionSet is changed, we recompute the viewport configuration only if needed by the platform. (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::disabledAdaptations const): * page/WindowFeatures.cpp: (WebCore::parseDisabledAdaptations): * page/WindowFeatures.h: Add a new helper to parse the meta content of a "disabled-adaptations" tag as an OptionSet of disabled adaptation types. The string is parsed by first splitting on the comma character, and then iterating over lower case, whitespace-stripped tokens to look for known adaptation names. So far, only extra zoom mode is supported. * testing/Internals.cpp: (WebCore::Internals::extraZoomModeAdaptationName const): * testing/Internals.h: * testing/Internals.idl: Expose the extra zoom mode adaptation name to the DOM, only when running layout tests. Source/WebKit: Adds a new experimental feature for the "disabled-adaptations" meta tag, and adds plumbing in WebKit to propagate disabled adaptation changes to the ViewportConfiguration. The experimental feature is on by default in extra zoom mode. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::dispatchDisabledAdaptationsDidChange const): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::disabledAdaptationsDidChange): * WebProcess/WebPage/WebPage.h: Source/WebKitLegacy/ios: Adds a WebKitLegacy method stub for disabled adaptation plumbing. * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::dispatchDisabledAdaptationsDidChange const): LayoutTests: Refactor an existing layout test to exercise disabled adaptations in extra zoom mode. * fast/viewport/extrazoom/viewport-change-min-device-width.html: Removed. * fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html: Added. Canonical link: https://commits.webkit.org/201100@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231779 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-15 01:07:36 +00:00
#include <wtf/OptionSet.h>
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
[WTF] Move TextStream into WTF https://bugs.webkit.org/show_bug.cgi?id=175211 Reviewed by Myles C. Maxfield. Source/WebCore: No new tests. No change in behavior. * CMakeLists.txt: * WebCore.xcodeproj/project.pbxproj: * dom/ComposedTreeIterator.cpp: * dom/Position.cpp: * dom/Position.h: * dom/Range.cpp: (WebCore::operator<<): * dom/Range.h: * dom/ViewportArguments.cpp: * dom/ViewportArguments.h: * editing/VisiblePosition.cpp: * editing/VisiblePosition.h: * editing/VisibleSelection.cpp: * editing/VisibleSelection.h: * html/HTMLVideoElement.cpp: * html/canvas/CanvasRenderingContext2D.cpp: * page/FrameView.cpp: * page/ViewportConfiguration.cpp: * page/ViewportConfiguration.h: * page/WheelEventDeltaFilter.cpp: * page/animation/CSSPropertyAnimation.cpp: * page/scrolling/AsyncScrollingCoordinator.cpp: * page/scrolling/ScrollingConstraints.cpp: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.cpp: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.cpp: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.cpp: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.cpp: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.cpp: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.cpp: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.cpp: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingTree.cpp: * page/scrolling/ScrollingTreeFrameScrollingNode.cpp: * page/scrolling/ScrollingTreeFrameScrollingNode.h: * page/scrolling/ScrollingTreeNode.cpp: * page/scrolling/ScrollingTreeNode.h: * page/scrolling/ScrollingTreeScrollingNode.cpp: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFixedNode.mm: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm: * page/scrolling/mac/ScrollingTreeStickyNode.h: * page/scrolling/mac/ScrollingTreeStickyNode.mm: * platform/CalculationValue.cpp: * platform/CalculationValue.h: * platform/LayoutUnit.cpp: * platform/LayoutUnit.h: * platform/Length.cpp: * platform/Length.h: * platform/LengthBox.cpp: * platform/LengthBox.h: * platform/LengthPoint.cpp: * platform/LengthPoint.h: * platform/LengthSize.cpp: * platform/LengthSize.h: * platform/LogMacros.h: * platform/ScrollView.cpp: * platform/ScrollableArea.cpp: * platform/animation/TimingFunction.cpp: * platform/animation/TimingFunction.h: * platform/graphics/BitmapImage.cpp: * platform/graphics/BitmapImage.h: * platform/graphics/Color.cpp: * platform/graphics/Color.h: * platform/graphics/CrossfadeGeneratedImage.cpp: * platform/graphics/CrossfadeGeneratedImage.h: * platform/graphics/FloatPoint.cpp: * platform/graphics/FloatPoint.h: * platform/graphics/FloatPoint3D.cpp: * platform/graphics/FloatPoint3D.h: * platform/graphics/FloatRect.cpp: * platform/graphics/FloatRect.h: * platform/graphics/FloatRoundedRect.cpp: * platform/graphics/FloatRoundedRect.h: * platform/graphics/FloatSize.cpp: * platform/graphics/FloatSize.h: * platform/graphics/FontTaggedSettings.cpp: * platform/graphics/FontTaggedSettings.h: * platform/graphics/GradientImage.cpp: (WebCore::GradientImage::dump const): * platform/graphics/GradientImage.h: * platform/graphics/GraphicsContext.cpp: * platform/graphics/GraphicsContext.h: * platform/graphics/GraphicsLayer.cpp: * platform/graphics/GraphicsLayer.h: (WebCore::GraphicsLayer::dumpAdditionalProperties const): * platform/graphics/GraphicsTypes.cpp: * platform/graphics/GraphicsTypes.h: * platform/graphics/Image.cpp: * platform/graphics/Image.h: * platform/graphics/ImageSource.h: * platform/graphics/IntPoint.cpp: * platform/graphics/IntPoint.h: * platform/graphics/IntRect.cpp: * platform/graphics/IntRect.h: * platform/graphics/IntSize.cpp: * platform/graphics/IntSize.h: * platform/graphics/LayoutPoint.cpp: * platform/graphics/LayoutPoint.h: * platform/graphics/LayoutRect.cpp: * platform/graphics/LayoutRect.h: * platform/graphics/LayoutSize.cpp: * platform/graphics/LayoutSize.h: * platform/graphics/NamedImageGeneratedImage.cpp: * platform/graphics/NamedImageGeneratedImage.h: * platform/graphics/Path.cpp: * platform/graphics/Path.h: * platform/graphics/ca/GraphicsLayerCA.cpp: * platform/graphics/ca/GraphicsLayerCA.h: * platform/graphics/ca/PlatformCAAnimation.cpp: * platform/graphics/ca/PlatformCAAnimation.h: * platform/graphics/ca/PlatformCALayer.cpp: * platform/graphics/ca/PlatformCALayer.h: * platform/graphics/ca/TileController.cpp: * platform/graphics/ca/TileGrid.cpp: * platform/graphics/cg/GraphicsContextCG.cpp: * platform/graphics/cg/PDFDocumentImage.cpp: * platform/graphics/cg/PDFDocumentImage.h: * platform/graphics/cocoa/IOSurface.h: * platform/graphics/cocoa/IOSurface.mm: * platform/graphics/displaylists/DisplayList.cpp: (WebCore::DisplayList::DisplayList::description const): * platform/graphics/displaylists/DisplayList.h: * platform/graphics/displaylists/DisplayListItems.cpp: * platform/graphics/displaylists/DisplayListItems.h: * platform/graphics/displaylists/DisplayListRecorder.cpp: * platform/graphics/displaylists/DisplayListReplayer.cpp: * platform/graphics/filters/DistantLightSource.cpp: * platform/graphics/filters/DistantLightSource.h: * platform/graphics/filters/FEBlend.cpp: * platform/graphics/filters/FEBlend.h: * platform/graphics/filters/FEColorMatrix.cpp: * platform/graphics/filters/FEColorMatrix.h: * platform/graphics/filters/FEComponentTransfer.cpp: * platform/graphics/filters/FEComponentTransfer.h: * platform/graphics/filters/FEComposite.cpp: * platform/graphics/filters/FEComposite.h: * platform/graphics/filters/FEConvolveMatrix.cpp: * platform/graphics/filters/FEConvolveMatrix.h: * platform/graphics/filters/FEDiffuseLighting.cpp: * platform/graphics/filters/FEDiffuseLighting.h: * platform/graphics/filters/FEDisplacementMap.cpp: * platform/graphics/filters/FEDisplacementMap.h: * platform/graphics/filters/FEDropShadow.cpp: * platform/graphics/filters/FEDropShadow.h: * platform/graphics/filters/FEFlood.cpp: * platform/graphics/filters/FEFlood.h: * platform/graphics/filters/FEGaussianBlur.cpp: * platform/graphics/filters/FEGaussianBlur.h: * platform/graphics/filters/FEMerge.cpp: * platform/graphics/filters/FEMerge.h: * platform/graphics/filters/FEMorphology.cpp: * platform/graphics/filters/FEMorphology.h: * platform/graphics/filters/FEOffset.cpp: * platform/graphics/filters/FEOffset.h: * platform/graphics/filters/FESpecularLighting.cpp: * platform/graphics/filters/FESpecularLighting.h: * platform/graphics/filters/FETile.cpp: * platform/graphics/filters/FETile.h: * platform/graphics/filters/FETurbulence.cpp: * platform/graphics/filters/FETurbulence.h: * platform/graphics/filters/FilterEffect.cpp: * platform/graphics/filters/FilterEffect.h: * platform/graphics/filters/FilterOperation.cpp: * platform/graphics/filters/FilterOperation.h: * platform/graphics/filters/FilterOperations.cpp: * platform/graphics/filters/FilterOperations.h: * platform/graphics/filters/LightSource.h: * platform/graphics/filters/PointLightSource.cpp: * platform/graphics/filters/PointLightSource.h: * platform/graphics/filters/SourceAlpha.cpp: * platform/graphics/filters/SourceAlpha.h: * platform/graphics/filters/SourceGraphic.cpp: * platform/graphics/filters/SourceGraphic.h: * platform/graphics/filters/SpotLightSource.cpp: * platform/graphics/filters/SpotLightSource.h: * platform/graphics/transforms/AffineTransform.cpp: * platform/graphics/transforms/AffineTransform.h: * platform/graphics/transforms/IdentityTransformOperation.h: * platform/graphics/transforms/Matrix3DTransformOperation.cpp: * platform/graphics/transforms/Matrix3DTransformOperation.h: * platform/graphics/transforms/MatrixTransformOperation.cpp: * platform/graphics/transforms/MatrixTransformOperation.h: * platform/graphics/transforms/PerspectiveTransformOperation.cpp: * platform/graphics/transforms/PerspectiveTransformOperation.h: * platform/graphics/transforms/RotateTransformOperation.cpp: * platform/graphics/transforms/RotateTransformOperation.h: * platform/graphics/transforms/ScaleTransformOperation.cpp: * platform/graphics/transforms/ScaleTransformOperation.h: * platform/graphics/transforms/SkewTransformOperation.cpp: * platform/graphics/transforms/SkewTransformOperation.h: * platform/graphics/transforms/TransformOperation.cpp: * platform/graphics/transforms/TransformOperation.h: * platform/graphics/transforms/TransformOperations.cpp: * platform/graphics/transforms/TransformOperations.h: * platform/graphics/transforms/TransformationMatrix.cpp: * platform/graphics/transforms/TransformationMatrix.h: * platform/graphics/transforms/TranslateTransformOperation.cpp: * platform/graphics/transforms/TranslateTransformOperation.h: * platform/ios/SelectionRect.cpp: (WebCore::operator<<): * platform/ios/SelectionRect.h: * platform/mac/ScrollAnimatorMac.mm: * platform/text/TextAllInOne.cpp: * rendering/InlineBox.cpp: * rendering/InlineBox.h: * rendering/InlineFlowBox.cpp: (WebCore::InlineFlowBox::outputLineTreeAndMark const): * rendering/InlineFlowBox.h: * rendering/InlineTextBox.cpp: * rendering/InlineTextBox.h: * rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::outputLineTreeAndMark const): * rendering/RenderBlockFlow.h: * rendering/RenderLayer.cpp: * rendering/RenderLayerCompositor.cpp: * rendering/RenderObject.cpp: * rendering/RenderObject.h: * rendering/RenderTreeAsText.cpp: * rendering/RenderTreeAsText.h: * rendering/ScrollAlignment.cpp: * rendering/ScrollAlignment.h: * rendering/SimpleLineLayoutCoverage.cpp: * rendering/SimpleLineLayoutFunctions.cpp: * rendering/SimpleLineLayoutFunctions.h: * rendering/style/FillLayer.cpp: * rendering/style/FillLayer.h: * rendering/style/NinePieceImage.cpp: * rendering/style/NinePieceImage.h: * rendering/style/RenderStyleConstants.cpp: * rendering/style/RenderStyleConstants.h: * rendering/svg/SVGRenderTreeAsText.cpp: (WebCore::operator<<): * rendering/svg/SVGRenderTreeAsText.h: (WebCore::operator<<): * svg/SVGLengthValue.cpp: * svg/SVGLengthValue.h: * svg/graphics/SVGImage.cpp: * svg/graphics/SVGImage.h: * svg/graphics/filters/SVGFEImage.cpp: * svg/graphics/filters/SVGFEImage.h: Source/WebKit: * Shared/Scrolling/RemoteScrollingCoordinatorTransaction.cpp: * Shared/VisibleContentRectUpdateInfo.cpp: * Shared/VisibleContentRectUpdateInfo.h: * Shared/mac/RemoteLayerTreeTransaction.mm: * UIProcess/API/Cocoa/WKWebView.mm: * UIProcess/ios/WKContentView.mm: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (WebKit::operator<<): * UIProcess/ios/WebPageProxyIOS.mm: * WebProcess/WebPage/ios/WebPageIOS.mm: * WebProcess/WebPage/mac/PlatformCAAnimationRemote.h: * WebProcess/WebPage/mac/PlatformCAAnimationRemote.mm: Source/WTF: * WTF.xcodeproj/project.pbxproj: * wtf/CMakeLists.txt: * wtf/text/TextStream.cpp: Renamed from Source/WebCore/platform/text/TextStream.cpp. (WTF::TextStream::writeIndent): * wtf/text/TextStream.h: Renamed from Source/WebCore/platform/text/TextStream.h. (WTF::TextStream::FormatNumberRespectingIntegers::FormatNumberRespectingIntegers): Tools: * TestWebKitAPI/Tests/WebCore/CalculationValue.cpp: Canonical link: https://commits.webkit.org/192121@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@220503 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-08-10 01:15:14 +00:00
namespace WTF {
class TextStream;
}
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
namespace WebCore {
class ViewportConfiguration {
WTF_MAKE_NONCOPYABLE(ViewportConfiguration); WTF_MAKE_FAST_ALLOCATED;
public:
// FIXME: unify with ViewportArguments.
struct Parameters {
Expose viewport-fit instead of clip-to-safe-area https://bugs.webkit.org/show_bug.cgi?id=171503 <rdar://problem/31918249> Reviewed by Simon Fraser. Tests: fast/viewport/ios/viewport-fit-auto.html fast/viewport/ios/viewport-fit-contain.html fast/viewport/ios/viewport-fit-cover.html * dom/ConstantPropertyMap.cpp: (WebCore::ConstantPropertyMap::buildValues): (WebCore::ConstantPropertyMap::updateConstantsForUnobscuredSafeAreaInsets): (WebCore::ConstantPropertyMap::didChangeSafeAreaInsets): (WebCore::ConstantPropertyMap::updateConstantsForObscuredInsets): Deleted. (WebCore::ConstantPropertyMap::didChangeObscuredInsets): Deleted. * dom/ConstantPropertyMap.h: Retrieve the safe area insets from page, instead of assuming that we should just expose the entire obscured inset. Also, do some renames. * dom/ViewportArguments.cpp: (WebCore::ViewportArguments::resolve): (WebCore::parseViewportFitValue): (WebCore::setViewportFeature): * dom/ViewportArguments.h: (WebCore::ViewportArguments::operator==): * page/ChromeClient.h: * page/FrameView.cpp: (WebCore::FrameView::enableSpeculativeTilingIfNeeded): (WebCore::FrameView::calculateExtendedBackgroundMode): (WebCore::FrameView::setClipToSafeArea): Deleted. * page/FrameView.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::operator<<): (WebCore::ViewportConfiguration::description): (WebCore::ViewportConfiguration::dump): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::avoidsUnsafeArea): (WebCore::ViewportConfiguration::Parameters::Parameters): (WebCore::ViewportConfiguration::clipToSafeArea): Deleted. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateRootContentLayerClipping): * rendering/RenderObject.cpp: (WebCore::RenderObject::repaintUsingContainer): Un-do changes to support clip-to-safe-area, and instead implement a new viewport-fit argument in the viewport meta tag, which takes "auto", "contain", and "cover". "auto" and "contain" cause web content to lay out excluding the safe area inset from the layout size, while "cover" causes web content to expand into the unsafe area. * page/Page.cpp: (WebCore::Page::setUnobscuredSafeAreaInsets): (WebCore::Page::setObscuredInsets): Deleted. * page/Page.h: (WebCore::Page::setObscuredInsets): (WebCore::Page::unobscuredSafeAreaInsets): Keep safe area and obscured insets separately. * Shared/VisibleContentRectUpdateInfo.cpp: (WebKit::VisibleContentRectUpdateInfo::encode): (WebKit::VisibleContentRectUpdateInfo::decode): (WebKit::operator<<): * Shared/VisibleContentRectUpdateInfo.h: (WebKit::VisibleContentRectUpdateInfo::VisibleContentRectUpdateInfo): (WebKit::VisibleContentRectUpdateInfo::unobscuredSafeAreaInsets): (WebKit::operator==): Plumb the safe area insets down from the UI process to the Web Content process inside the visible content rect update, alongside the obscured insets. * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::avoidsUnsafeArea): (WebKit::RemoteLayerTreeTransaction::setAvoidsUnsafeArea): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): (WebKit::RemoteLayerTreeTransaction::description): * UIProcess/PageClient.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didChangeAvoidsUnsafeArea): (WebKit::PageClientImpl::didChangeClipToSafeArea): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didCommitLayerTree): * UIProcess/mac/PageClientImpl.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::didChangeClipToSafeArea): Deleted. * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::willCommitLayerTree): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportConfigurationChanged): (WebKit::WebPage::updateVisibleContentRects): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::setAvoidsUnsafeArea): (WebKit::WebPageProxy::setClipToSafeArea): Deleted. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::avoidsUnsafeArea): (WebKit::WebPageProxy::clipToSafeArea): Deleted. * UIProcess/WebPageProxy.messages.in: Plumb the effective value of viewport-fit (whether or not to avoid the safe area for layout purposes) from the Web Content process to the UI process inside the layer tree transaction. Also, remove clip-to-safe-area plumbing. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): (-[WKWebView _computedContentInset]): (-[WKWebView _computedUnobscuredSafeAreaInset]): (-[WKWebView _updateVisibleContentRects]): (-[WKWebView _updateScrollViewInsetAdjustmentBehavior]): (-[WKWebView _safeAreaShouldAffectObscuredInsets]): (-[WKWebView _unobscuredSafeAreaInsets]): (-[WKWebView _setUnobscuredSafeAreaInsets:]): (-[WKWebView _contentMayDrawInObscuredInsets]): Deleted. * UIProcess/API/Cocoa/WKWebViewInternal.h: * UIProcess/API/Cocoa/WKWebViewPrivate.h: Make use of the effective value of viewport-fit to decide whether to take the safe area into account when computing the obscured insets, and expose this to clients (in the case that they need to know because they push their own obscured insets down). Also expose a safe area inset setter for that case as well. * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView updateFixedClippingView:]): (-[WKContentView didUpdateVisibleRect:unobscuredRect:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): Remove a piece of the clip-to-safe-area implementation, and plumb safe area insets into the visible content rect update info. * UIProcess/ios/WKScrollView.h: * UIProcess/ios/WKScrollView.mm: (-[WKScrollView initWithFrame:]): (-[WKScrollView _contentInsetAdjustmentBehaviorWasExternallyOverridden]): (-[WKScrollView _setContentInsetAdjustmentBehavior:]): (-[WKScrollView _setContentInsetAdjustmentBehaviorInternal:]): Keep track of whether the client has ever touched the content inset adjustment behavior; if they have, we won't manage it ourselves. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/cocoa/TestRunnerWKWebView.h: * WebKitTestRunner/cocoa/TestRunnerWKWebView.mm: (-[TestRunnerWKWebView setOverrideSafeAreaInsets:]): (-[TestRunnerWKWebView _safeAreaInsetsForFrame:inSuperview:]): * WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformResetStateToConsistentValues): * WebKitTestRunner/ios/UIKitSPI.h: * WebKitTestRunner/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. Expose a safe area inset setter instead of obscured insets. * TestExpectations: * fast/css/variables/constants/ios/safe-area-inset-set-expected.html: * fast/css/variables/constants/ios/safe-area-inset-set.html: * fast/viewport/ios/viewport-fit-auto-expected.txt: Added. * fast/viewport/ios/viewport-fit-auto.html: Added. * fast/viewport/ios/viewport-fit-contain-expected.txt: Added. * fast/viewport/ios/viewport-fit-contain.html: Added. * fast/viewport/ios/viewport-fit-cover-expected.txt: Added. * fast/viewport/ios/viewport-fit-cover.html: Added. * tiled-drawing/ios/viewport-clip-to-safe-area-no-gets-margin-tiles-expected.txt: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-no-gets-margin-tiles.html: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-yes-gets-no-margin-tiles-expected.txt: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-yes-gets-no-margin-tiles.html: Removed. Remove clip-to-safe-area tests and add some viewport-fit tests. Also, adjust safe-area-inset-set to use the new UIScriptController setSafeAreaInset method. Canonical link: https://commits.webkit.org/188434@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216047 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-02 00:08:23 +00:00
double width { 0 };
double height { 0 };
double initialScale { 0 };
[iOS] Allow SPI clients to lay out at arbitrarily scaled sizes and scale to fit the view https://bugs.webkit.org/show_bug.cgi?id=190504 <rdar://problem/45117760> Reviewed by Tim Horton. Source/WebCore: Add support in ViewportConfiguration for applying a layout size scale factor to the viewport. See below for more details. Tests: fast/viewport/ios/constant-width-viewport-after-changing-view-scale.html fast/viewport/ios/device-width-viewport-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setViewLayoutSize): The viewport's layout size may now be changed alongside the layout size scale factor. If either of these two variables change, we recompute our minimum layout size and viewport configuration parameters. (WebCore::ViewportConfiguration::shouldIgnoreHorizontalScalingConstraints const): (WebCore::ViewportConfiguration::nativeWebpageParameters): (WebCore::ViewportConfiguration::testingParameters): (WebCore::ViewportConfiguration::updateConfiguration): Multiply the minimum scale, initial scale, and maximum scale by the layout size scale factor. This allows us to keep the document well-proportioned within the viewport, while still laying out at a different layout size. (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Compute the minimum layout size by scaling the default layout size derived from our view's size. (WebCore::ViewportConfiguration::layoutWidth const): (WebCore::ViewportConfiguration::layoutHeight const): * page/ViewportConfiguration.h: Maintain the original initial scale, unaffected by the layout size scale factor. This is used when computing layout width and height to prevent scaling by the layout size scale factor twice when computing layout sizes. (WebCore::ViewportConfiguration::description const): Include the layout size scale factor in ViewportConfiguration's description string. (WebCore::ViewportConfiguration::Parameters::operator== const): (WebCore::operator<<): Source/WebKit: Add support for _setViewScale: and _viewScale on iOS. While similar in concept to macOS, changing this property on iOS uses viewport configurations to change the minimum layout size of the document and apply view scaling. Setting the view scale on iOS to a value `s` multiplies the minimium layout size by a factor `1 / s`, but also multiplies the initial, minimum and maximum scales by a factor of `s`. The net effect of applying this scale causes the page to lay out at a larger width and shrink (or a smaller width and expand) to fit the viewport. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Send `viewportConfigurationLayoutSizeScaleFactor` alongside `viewportConfigurationViewLayoutSize`. (-[WKWebView _dispatchSetViewLayoutSize:]): (-[WKWebView _viewScale]): (-[WKWebView _setViewScale:]): Provide a different implementation of `_setViewScale:` on iOS, by scaling the effective minimum layout size. (See above for more detail). * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add missing API availability annotations for the _viewScale property. * UIProcess/API/mac/WKView.mm: (-[WKView _setViewScale:]): * UIProcess/Cocoa/WebViewImpl.mm: Both -[WKView _setViewScale:] and -[WKWebView _setViewScale:] throw Objective C exceptions upon receiving a bad argument (e.g. scale <= 0). However, logic for throwing this exception is specific to iOS in WKWebView, and handled in WebViewImpl on macOS. To make this less confusing, move the exception throwing code out of !PLATFORM(MAC) in WKWebView, and move the path for raising this exception in WKView on macOS from WebViewImpl to WKView. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::layoutSizeScaleFactor const): Tie the notion of "view scale" on iOS to `layoutSizeScaleFactor`. As its name suggests, this is a scale factor by which we transform the layout size. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): * WebProcess/WebPage/WebPage.cpp: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Plumb the layout size scale factor over to the web process, along with the layout size. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Tools: Teach UIScriptController to set WKWebView's view scale via a new `setViewScale` method, supported in WebKit2 on macOS and iOS. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setViewScale): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::setViewScale): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setViewScale): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: Added. Add a new file for UIScriptController methods on Cocoa platforms. (WTR::UIScriptController::setViewScale): * WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj: * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::cocoaResetStateToConsistentValues): Ensure that _viewScale is reset to 1 after running a layout test. LayoutTests: Add two new layout tests on iOS that change WKWebView's view scale, and measure the resulting window sizes and lengths of viewport units. * fast/viewport/ios/constant-width-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/constant-width-viewport-after-changing-view-scale.html: Added. Add a test page with a viewport meta tag that has a constant width and an explicit initial scale of 0.5. * fast/viewport/ios/device-width-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/device-width-viewport-after-changing-view-scale.html: Added. Add a test page with a viewport meta tag at device-width, with initial scale 1. * resources/ui-helper.js: (window.UIHelper.setViewScale): Add a convenience function that wraps a UI script invocation of `setViewScale` in a promise. (window.UIHelper): Canonical link: https://commits.webkit.org/205461@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237087 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-10-12 23:13:37 +00:00
double initialScaleIgnoringLayoutScaleFactor { 0 };
Expose viewport-fit instead of clip-to-safe-area https://bugs.webkit.org/show_bug.cgi?id=171503 <rdar://problem/31918249> Reviewed by Simon Fraser. Tests: fast/viewport/ios/viewport-fit-auto.html fast/viewport/ios/viewport-fit-contain.html fast/viewport/ios/viewport-fit-cover.html * dom/ConstantPropertyMap.cpp: (WebCore::ConstantPropertyMap::buildValues): (WebCore::ConstantPropertyMap::updateConstantsForUnobscuredSafeAreaInsets): (WebCore::ConstantPropertyMap::didChangeSafeAreaInsets): (WebCore::ConstantPropertyMap::updateConstantsForObscuredInsets): Deleted. (WebCore::ConstantPropertyMap::didChangeObscuredInsets): Deleted. * dom/ConstantPropertyMap.h: Retrieve the safe area insets from page, instead of assuming that we should just expose the entire obscured inset. Also, do some renames. * dom/ViewportArguments.cpp: (WebCore::ViewportArguments::resolve): (WebCore::parseViewportFitValue): (WebCore::setViewportFeature): * dom/ViewportArguments.h: (WebCore::ViewportArguments::operator==): * page/ChromeClient.h: * page/FrameView.cpp: (WebCore::FrameView::enableSpeculativeTilingIfNeeded): (WebCore::FrameView::calculateExtendedBackgroundMode): (WebCore::FrameView::setClipToSafeArea): Deleted. * page/FrameView.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::operator<<): (WebCore::ViewportConfiguration::description): (WebCore::ViewportConfiguration::dump): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::avoidsUnsafeArea): (WebCore::ViewportConfiguration::Parameters::Parameters): (WebCore::ViewportConfiguration::clipToSafeArea): Deleted. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateRootContentLayerClipping): * rendering/RenderObject.cpp: (WebCore::RenderObject::repaintUsingContainer): Un-do changes to support clip-to-safe-area, and instead implement a new viewport-fit argument in the viewport meta tag, which takes "auto", "contain", and "cover". "auto" and "contain" cause web content to lay out excluding the safe area inset from the layout size, while "cover" causes web content to expand into the unsafe area. * page/Page.cpp: (WebCore::Page::setUnobscuredSafeAreaInsets): (WebCore::Page::setObscuredInsets): Deleted. * page/Page.h: (WebCore::Page::setObscuredInsets): (WebCore::Page::unobscuredSafeAreaInsets): Keep safe area and obscured insets separately. * Shared/VisibleContentRectUpdateInfo.cpp: (WebKit::VisibleContentRectUpdateInfo::encode): (WebKit::VisibleContentRectUpdateInfo::decode): (WebKit::operator<<): * Shared/VisibleContentRectUpdateInfo.h: (WebKit::VisibleContentRectUpdateInfo::VisibleContentRectUpdateInfo): (WebKit::VisibleContentRectUpdateInfo::unobscuredSafeAreaInsets): (WebKit::operator==): Plumb the safe area insets down from the UI process to the Web Content process inside the visible content rect update, alongside the obscured insets. * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::avoidsUnsafeArea): (WebKit::RemoteLayerTreeTransaction::setAvoidsUnsafeArea): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): (WebKit::RemoteLayerTreeTransaction::description): * UIProcess/PageClient.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didChangeAvoidsUnsafeArea): (WebKit::PageClientImpl::didChangeClipToSafeArea): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didCommitLayerTree): * UIProcess/mac/PageClientImpl.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::didChangeClipToSafeArea): Deleted. * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::willCommitLayerTree): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportConfigurationChanged): (WebKit::WebPage::updateVisibleContentRects): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::setAvoidsUnsafeArea): (WebKit::WebPageProxy::setClipToSafeArea): Deleted. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::avoidsUnsafeArea): (WebKit::WebPageProxy::clipToSafeArea): Deleted. * UIProcess/WebPageProxy.messages.in: Plumb the effective value of viewport-fit (whether or not to avoid the safe area for layout purposes) from the Web Content process to the UI process inside the layer tree transaction. Also, remove clip-to-safe-area plumbing. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): (-[WKWebView _computedContentInset]): (-[WKWebView _computedUnobscuredSafeAreaInset]): (-[WKWebView _updateVisibleContentRects]): (-[WKWebView _updateScrollViewInsetAdjustmentBehavior]): (-[WKWebView _safeAreaShouldAffectObscuredInsets]): (-[WKWebView _unobscuredSafeAreaInsets]): (-[WKWebView _setUnobscuredSafeAreaInsets:]): (-[WKWebView _contentMayDrawInObscuredInsets]): Deleted. * UIProcess/API/Cocoa/WKWebViewInternal.h: * UIProcess/API/Cocoa/WKWebViewPrivate.h: Make use of the effective value of viewport-fit to decide whether to take the safe area into account when computing the obscured insets, and expose this to clients (in the case that they need to know because they push their own obscured insets down). Also expose a safe area inset setter for that case as well. * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView updateFixedClippingView:]): (-[WKContentView didUpdateVisibleRect:unobscuredRect:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): Remove a piece of the clip-to-safe-area implementation, and plumb safe area insets into the visible content rect update info. * UIProcess/ios/WKScrollView.h: * UIProcess/ios/WKScrollView.mm: (-[WKScrollView initWithFrame:]): (-[WKScrollView _contentInsetAdjustmentBehaviorWasExternallyOverridden]): (-[WKScrollView _setContentInsetAdjustmentBehavior:]): (-[WKScrollView _setContentInsetAdjustmentBehaviorInternal:]): Keep track of whether the client has ever touched the content inset adjustment behavior; if they have, we won't manage it ourselves. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/cocoa/TestRunnerWKWebView.h: * WebKitTestRunner/cocoa/TestRunnerWKWebView.mm: (-[TestRunnerWKWebView setOverrideSafeAreaInsets:]): (-[TestRunnerWKWebView _safeAreaInsetsForFrame:inSuperview:]): * WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformResetStateToConsistentValues): * WebKitTestRunner/ios/UIKitSPI.h: * WebKitTestRunner/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. Expose a safe area inset setter instead of obscured insets. * TestExpectations: * fast/css/variables/constants/ios/safe-area-inset-set-expected.html: * fast/css/variables/constants/ios/safe-area-inset-set.html: * fast/viewport/ios/viewport-fit-auto-expected.txt: Added. * fast/viewport/ios/viewport-fit-auto.html: Added. * fast/viewport/ios/viewport-fit-contain-expected.txt: Added. * fast/viewport/ios/viewport-fit-contain.html: Added. * fast/viewport/ios/viewport-fit-cover-expected.txt: Added. * fast/viewport/ios/viewport-fit-cover.html: Added. * tiled-drawing/ios/viewport-clip-to-safe-area-no-gets-margin-tiles-expected.txt: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-no-gets-margin-tiles.html: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-yes-gets-no-margin-tiles-expected.txt: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-yes-gets-no-margin-tiles.html: Removed. Remove clip-to-safe-area tests and add some viewport-fit tests. Also, adjust safe-area-inset-set to use the new UIScriptController setSafeAreaInset method. Canonical link: https://commits.webkit.org/188434@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216047 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-02 00:08:23 +00:00
double minimumScale { 0 };
double maximumScale { 0 };
bool allowsUserScaling { false };
bool allowsShrinkToFit { false };
bool avoidsUnsafeArea { true };
bool widthIsSet { false };
bool heightIsSet { false };
bool initialScaleIsSet { false };
bool operator==(const Parameters& other) const
{
return width == other.width && height == other.height
[iOS] Allow SPI clients to lay out at arbitrarily scaled sizes and scale to fit the view https://bugs.webkit.org/show_bug.cgi?id=190504 <rdar://problem/45117760> Reviewed by Tim Horton. Source/WebCore: Add support in ViewportConfiguration for applying a layout size scale factor to the viewport. See below for more details. Tests: fast/viewport/ios/constant-width-viewport-after-changing-view-scale.html fast/viewport/ios/device-width-viewport-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setViewLayoutSize): The viewport's layout size may now be changed alongside the layout size scale factor. If either of these two variables change, we recompute our minimum layout size and viewport configuration parameters. (WebCore::ViewportConfiguration::shouldIgnoreHorizontalScalingConstraints const): (WebCore::ViewportConfiguration::nativeWebpageParameters): (WebCore::ViewportConfiguration::testingParameters): (WebCore::ViewportConfiguration::updateConfiguration): Multiply the minimum scale, initial scale, and maximum scale by the layout size scale factor. This allows us to keep the document well-proportioned within the viewport, while still laying out at a different layout size. (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Compute the minimum layout size by scaling the default layout size derived from our view's size. (WebCore::ViewportConfiguration::layoutWidth const): (WebCore::ViewportConfiguration::layoutHeight const): * page/ViewportConfiguration.h: Maintain the original initial scale, unaffected by the layout size scale factor. This is used when computing layout width and height to prevent scaling by the layout size scale factor twice when computing layout sizes. (WebCore::ViewportConfiguration::description const): Include the layout size scale factor in ViewportConfiguration's description string. (WebCore::ViewportConfiguration::Parameters::operator== const): (WebCore::operator<<): Source/WebKit: Add support for _setViewScale: and _viewScale on iOS. While similar in concept to macOS, changing this property on iOS uses viewport configurations to change the minimum layout size of the document and apply view scaling. Setting the view scale on iOS to a value `s` multiplies the minimium layout size by a factor `1 / s`, but also multiplies the initial, minimum and maximum scales by a factor of `s`. The net effect of applying this scale causes the page to lay out at a larger width and shrink (or a smaller width and expand) to fit the viewport. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Send `viewportConfigurationLayoutSizeScaleFactor` alongside `viewportConfigurationViewLayoutSize`. (-[WKWebView _dispatchSetViewLayoutSize:]): (-[WKWebView _viewScale]): (-[WKWebView _setViewScale:]): Provide a different implementation of `_setViewScale:` on iOS, by scaling the effective minimum layout size. (See above for more detail). * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add missing API availability annotations for the _viewScale property. * UIProcess/API/mac/WKView.mm: (-[WKView _setViewScale:]): * UIProcess/Cocoa/WebViewImpl.mm: Both -[WKView _setViewScale:] and -[WKWebView _setViewScale:] throw Objective C exceptions upon receiving a bad argument (e.g. scale <= 0). However, logic for throwing this exception is specific to iOS in WKWebView, and handled in WebViewImpl on macOS. To make this less confusing, move the exception throwing code out of !PLATFORM(MAC) in WKWebView, and move the path for raising this exception in WKView on macOS from WebViewImpl to WKView. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::layoutSizeScaleFactor const): Tie the notion of "view scale" on iOS to `layoutSizeScaleFactor`. As its name suggests, this is a scale factor by which we transform the layout size. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): * WebProcess/WebPage/WebPage.cpp: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Plumb the layout size scale factor over to the web process, along with the layout size. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Tools: Teach UIScriptController to set WKWebView's view scale via a new `setViewScale` method, supported in WebKit2 on macOS and iOS. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setViewScale): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::setViewScale): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setViewScale): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: Added. Add a new file for UIScriptController methods on Cocoa platforms. (WTR::UIScriptController::setViewScale): * WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj: * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::cocoaResetStateToConsistentValues): Ensure that _viewScale is reset to 1 after running a layout test. LayoutTests: Add two new layout tests on iOS that change WKWebView's view scale, and measure the resulting window sizes and lengths of viewport units. * fast/viewport/ios/constant-width-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/constant-width-viewport-after-changing-view-scale.html: Added. Add a test page with a viewport meta tag that has a constant width and an explicit initial scale of 0.5. * fast/viewport/ios/device-width-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/device-width-viewport-after-changing-view-scale.html: Added. Add a test page with a viewport meta tag at device-width, with initial scale 1. * resources/ui-helper.js: (window.UIHelper.setViewScale): Add a convenience function that wraps a UI script invocation of `setViewScale` in a promise. (window.UIHelper): Canonical link: https://commits.webkit.org/205461@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237087 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-10-12 23:13:37 +00:00
&& initialScale == other.initialScale && initialScaleIgnoringLayoutScaleFactor == other.initialScaleIgnoringLayoutScaleFactor && minimumScale == other.minimumScale && maximumScale == other.maximumScale
&& allowsUserScaling == other.allowsUserScaling && allowsShrinkToFit == other.allowsShrinkToFit && avoidsUnsafeArea == other.avoidsUnsafeArea
&& widthIsSet == other.widthIsSet && heightIsSet == other.heightIsSet && initialScaleIsSet == other.initialScaleIsSet;
}
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
};
More WEBCORE_EXPORT macros! https://bugs.webkit.org/show_bug.cgi?id=136146 Reviewed by Benjamin Poulain. * Modules/geolocation/GeolocationClient.h: * Modules/mediastream/UserMediaClient.h: * Modules/mediastream/UserMediaRequest.h: * Modules/notifications/NotificationClient.h: * Modules/speech/SpeechSynthesis.h: * bindings/generic/RuntimeEnabledFeatures.h: * bindings/js/DOMWrapperWorld.h: * bindings/js/GCController.h: * bindings/js/IDBBindingUtilities.h: * bindings/js/JSDOMBinding.h: * bindings/js/JSNodeCustom.h: * bindings/js/JSNodeListCustom.h: * bindings/js/JSPluginElementFunctions.h: * bindings/js/ScriptController.h: * bindings/js/SerializedScriptValue.h: * crypto/SerializedCryptoKeyWrap.h: * css/LengthFunctions.h: * css/StyleProperties.h: * css/StyleSheetContents.h: * dom/DeviceOrientationClient.h: * dom/Range.h: * dom/ScriptExecutionContext.h: * dom/StyledElement.h: * dom/TreeScope.h: * dom/UIEventWithKeyState.h: * dom/UserGestureIndicator.h: * dom/UserTypingGestureIndicator.h: * dom/ViewportArguments.h: * editing/SmartReplace.h: * editing/TextIterator.h: * editing/VisiblePosition.h: * editing/VisibleSelection.h: * editing/VisibleUnits.h: * editing/cocoa/HTMLConverter.h: * editing/htmlediting.h: * editing/mac/TextAlternativeWithRange.h: * editing/mac/TextUndoInsertionMarkupMac.h: * editing/markup.h: * history/HistoryItem.cpp: * history/PageCache.h: * html/TimeRanges.h: * html/parser/HTMLParserIdioms.h: * inspector/InstrumentingAgents.h: * loader/FrameLoader.h: * loader/ResourceBuffer.h: * loader/ResourceLoadScheduler.h: * loader/ResourceLoader.h: (WebCore::ResourceLoader::originalRequest): * loader/SubframeLoader.h: * loader/SubresourceLoader.h: * loader/TextResourceDecoder.h: * loader/appcache/ApplicationCacheStorage.h: * loader/cache/MemoryCache.h: * loader/icon/IconDatabaseBase.h: * loader/ios/DiskImageCacheIOS.h: * page/Chrome.h: * page/SecurityOrigin.h: * page/SecurityPolicy.h: * page/Settings.h: * page/UserContentController.h: * page/UserContentURLPattern.h: * page/UserMessageHandlerDescriptor.h: * page/ViewportConfiguration.h: * page/VisitedLinkStore.h: * page/WheelEventDeltaTracker.h: * page/cocoa/UserAgent.h: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingStateTree.h: * page/scrolling/ScrollingThread.h: * page/scrolling/ScrollingTree.h: * page/scrolling/ScrollingTreeOverflowScrollingNode.h: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/ios/ScrollingTreeFrameScrollingNodeIOS.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeStickyNode.h: * platform/Cursor.h: * platform/DragImage.h: * platform/FileSystem.h: * platform/Language.h: * platform/LinkHash.h: * platform/LocalizedStrings.h: * platform/Logging.h: * platform/MemoryPressureHandler.h: * platform/NotImplemented.h: * platform/PlatformStrategies.h: * platform/PublicSuffix.h: * platform/RuntimeApplicationChecks.h: * platform/RuntimeApplicationChecksIOS.h: * platform/SchemeRegistry.h: * platform/ScrollView.h: * platform/ScrollableArea.h: * platform/Scrollbar.h: * platform/ScrollbarTheme.h: * platform/SharedBuffer.h: * platform/ThreadCheck.h: * platform/ThreadGlobalData.h: * platform/Timer.h: * platform/URL.h: * platform/UUID.h: * platform/UserActivity.h: * platform/Widget.h: * platform/cf/CFURLExtras.h: * platform/cf/RunLoopObserver.h: * platform/cocoa/SystemVersion.h: * platform/graphics/Color.h: * platform/graphics/FloatRect.h: * platform/graphics/FontCache.h: * platform/graphics/GeometryUtilities.h: * platform/graphics/GraphicsContext.h: * platform/graphics/IntRect.h: * platform/graphics/LayoutRect.h: * platform/graphics/StringTruncator.h: * platform/graphics/TextRun.h: * platform/graphics/ca/TileController.h: * platform/graphics/ca/mac/PlatformCAAnimationMac.h: * platform/graphics/cg/GraphicsContextCG.h: * platform/graphics/mac/ColorMac.h: * platform/graphics/transforms/TransformationMatrix.h: * platform/ios/FileSystemIOS.h: * platform/ios/PlatformEventFactoryIOS.h: * platform/ios/SelectionRect.h: * platform/ios/SystemMemory.h: * platform/ios/TileControllerMemoryHandlerIOS.h: * platform/ios/WebVideoFullscreenInterfaceAVKit.h: * platform/mac/PlatformEventFactoryMac.h: * platform/mac/ScrollbarThemeMac.h: * platform/mac/WebCoreNSURLExtras.h: * platform/mac/WebNSAttributedStringExtras.h: * platform/network/BlobRegistry.h: * platform/network/CookieStorage.h: * platform/network/DNS.h: * platform/network/NetworkStateNotifier.h: * platform/network/PlatformCookieJar.h: * platform/network/ProxyServer.h: * platform/network/ResourceErrorBase.h: * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.h: * platform/network/ResourceRequestBase.h: * platform/network/ResourceResponseBase.h: * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceError.h: * platform/network/cf/ResourceRequest.h: * platform/network/cf/ResourceResponse.h: * platform/network/ios/QuickLook.h: * platform/network/mac/AuthenticationMac.h: * platform/sql/SQLiteDatabase.cpp: * platform/text/LocaleToScriptMapping.h: * platform/text/TextBreakIterator.h: * platform/text/TextEncoding.h: (WebCore::TextEncoding::decode): * platform/text/TextEncodingRegistry.h: * platform/text/TextStream.h: * rendering/RenderBlock.h: * rendering/RenderBox.h: * rendering/RenderEmbeddedObject.h: * rendering/RenderLayer.h: * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.h: * rendering/RenderListItem.h: * rendering/RenderObject.h: * rendering/RenderText.h: * rendering/RenderTextControl.h: * rendering/RenderThemeIOS.h: * rendering/RenderTreeAsText.h: * rendering/RenderView.h: * rendering/RenderWidget.h: * rendering/ScrollBehavior.cpp: * rendering/break_lines.cpp: * rendering/style/RenderStyle.h: * replay/UserInputBridge.h: * storage/StorageEventDispatcher.h: * storage/StorageMap.h: * storage/StorageStrategy.h: * storage/StorageTracker.h: * testing/Internals.h: * workers/WorkerThread.h: Added more WEBCORE_EXPORT macros where needed. Canonical link: https://commits.webkit.org/153984@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@172849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-08-22 04:21:18 +00:00
WEBCORE_EXPORT ViewportConfiguration();
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
const Parameters& defaultConfiguration() const { return m_defaultConfiguration; }
More WEBCORE_EXPORT macros! https://bugs.webkit.org/show_bug.cgi?id=136146 Reviewed by Benjamin Poulain. * Modules/geolocation/GeolocationClient.h: * Modules/mediastream/UserMediaClient.h: * Modules/mediastream/UserMediaRequest.h: * Modules/notifications/NotificationClient.h: * Modules/speech/SpeechSynthesis.h: * bindings/generic/RuntimeEnabledFeatures.h: * bindings/js/DOMWrapperWorld.h: * bindings/js/GCController.h: * bindings/js/IDBBindingUtilities.h: * bindings/js/JSDOMBinding.h: * bindings/js/JSNodeCustom.h: * bindings/js/JSNodeListCustom.h: * bindings/js/JSPluginElementFunctions.h: * bindings/js/ScriptController.h: * bindings/js/SerializedScriptValue.h: * crypto/SerializedCryptoKeyWrap.h: * css/LengthFunctions.h: * css/StyleProperties.h: * css/StyleSheetContents.h: * dom/DeviceOrientationClient.h: * dom/Range.h: * dom/ScriptExecutionContext.h: * dom/StyledElement.h: * dom/TreeScope.h: * dom/UIEventWithKeyState.h: * dom/UserGestureIndicator.h: * dom/UserTypingGestureIndicator.h: * dom/ViewportArguments.h: * editing/SmartReplace.h: * editing/TextIterator.h: * editing/VisiblePosition.h: * editing/VisibleSelection.h: * editing/VisibleUnits.h: * editing/cocoa/HTMLConverter.h: * editing/htmlediting.h: * editing/mac/TextAlternativeWithRange.h: * editing/mac/TextUndoInsertionMarkupMac.h: * editing/markup.h: * history/HistoryItem.cpp: * history/PageCache.h: * html/TimeRanges.h: * html/parser/HTMLParserIdioms.h: * inspector/InstrumentingAgents.h: * loader/FrameLoader.h: * loader/ResourceBuffer.h: * loader/ResourceLoadScheduler.h: * loader/ResourceLoader.h: (WebCore::ResourceLoader::originalRequest): * loader/SubframeLoader.h: * loader/SubresourceLoader.h: * loader/TextResourceDecoder.h: * loader/appcache/ApplicationCacheStorage.h: * loader/cache/MemoryCache.h: * loader/icon/IconDatabaseBase.h: * loader/ios/DiskImageCacheIOS.h: * page/Chrome.h: * page/SecurityOrigin.h: * page/SecurityPolicy.h: * page/Settings.h: * page/UserContentController.h: * page/UserContentURLPattern.h: * page/UserMessageHandlerDescriptor.h: * page/ViewportConfiguration.h: * page/VisitedLinkStore.h: * page/WheelEventDeltaTracker.h: * page/cocoa/UserAgent.h: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingStateTree.h: * page/scrolling/ScrollingThread.h: * page/scrolling/ScrollingTree.h: * page/scrolling/ScrollingTreeOverflowScrollingNode.h: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/ios/ScrollingTreeFrameScrollingNodeIOS.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeStickyNode.h: * platform/Cursor.h: * platform/DragImage.h: * platform/FileSystem.h: * platform/Language.h: * platform/LinkHash.h: * platform/LocalizedStrings.h: * platform/Logging.h: * platform/MemoryPressureHandler.h: * platform/NotImplemented.h: * platform/PlatformStrategies.h: * platform/PublicSuffix.h: * platform/RuntimeApplicationChecks.h: * platform/RuntimeApplicationChecksIOS.h: * platform/SchemeRegistry.h: * platform/ScrollView.h: * platform/ScrollableArea.h: * platform/Scrollbar.h: * platform/ScrollbarTheme.h: * platform/SharedBuffer.h: * platform/ThreadCheck.h: * platform/ThreadGlobalData.h: * platform/Timer.h: * platform/URL.h: * platform/UUID.h: * platform/UserActivity.h: * platform/Widget.h: * platform/cf/CFURLExtras.h: * platform/cf/RunLoopObserver.h: * platform/cocoa/SystemVersion.h: * platform/graphics/Color.h: * platform/graphics/FloatRect.h: * platform/graphics/FontCache.h: * platform/graphics/GeometryUtilities.h: * platform/graphics/GraphicsContext.h: * platform/graphics/IntRect.h: * platform/graphics/LayoutRect.h: * platform/graphics/StringTruncator.h: * platform/graphics/TextRun.h: * platform/graphics/ca/TileController.h: * platform/graphics/ca/mac/PlatformCAAnimationMac.h: * platform/graphics/cg/GraphicsContextCG.h: * platform/graphics/mac/ColorMac.h: * platform/graphics/transforms/TransformationMatrix.h: * platform/ios/FileSystemIOS.h: * platform/ios/PlatformEventFactoryIOS.h: * platform/ios/SelectionRect.h: * platform/ios/SystemMemory.h: * platform/ios/TileControllerMemoryHandlerIOS.h: * platform/ios/WebVideoFullscreenInterfaceAVKit.h: * platform/mac/PlatformEventFactoryMac.h: * platform/mac/ScrollbarThemeMac.h: * platform/mac/WebCoreNSURLExtras.h: * platform/mac/WebNSAttributedStringExtras.h: * platform/network/BlobRegistry.h: * platform/network/CookieStorage.h: * platform/network/DNS.h: * platform/network/NetworkStateNotifier.h: * platform/network/PlatformCookieJar.h: * platform/network/ProxyServer.h: * platform/network/ResourceErrorBase.h: * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.h: * platform/network/ResourceRequestBase.h: * platform/network/ResourceResponseBase.h: * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceError.h: * platform/network/cf/ResourceRequest.h: * platform/network/cf/ResourceResponse.h: * platform/network/ios/QuickLook.h: * platform/network/mac/AuthenticationMac.h: * platform/sql/SQLiteDatabase.cpp: * platform/text/LocaleToScriptMapping.h: * platform/text/TextBreakIterator.h: * platform/text/TextEncoding.h: (WebCore::TextEncoding::decode): * platform/text/TextEncodingRegistry.h: * platform/text/TextStream.h: * rendering/RenderBlock.h: * rendering/RenderBox.h: * rendering/RenderEmbeddedObject.h: * rendering/RenderLayer.h: * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.h: * rendering/RenderListItem.h: * rendering/RenderObject.h: * rendering/RenderText.h: * rendering/RenderTextControl.h: * rendering/RenderThemeIOS.h: * rendering/RenderTreeAsText.h: * rendering/RenderView.h: * rendering/RenderWidget.h: * rendering/ScrollBehavior.cpp: * rendering/break_lines.cpp: * rendering/style/RenderStyle.h: * replay/UserInputBridge.h: * storage/StorageEventDispatcher.h: * storage/StorageMap.h: * storage/StorageStrategy.h: * storage/StorageTracker.h: * testing/Internals.h: * workers/WorkerThread.h: Added more WEBCORE_EXPORT macros where needed. Canonical link: https://commits.webkit.org/153984@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@172849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-08-22 04:21:18 +00:00
WEBCORE_EXPORT void setDefaultConfiguration(const Parameters&);
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
const IntSize& contentsSize() const { return m_contentSize; }
WEBCORE_EXPORT bool setContentsSize(const IntSize&);
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
[Extra zoom mode] Google search results are excessively zoomed in https://bugs.webkit.org/show_bug.cgi?id=185347 <rdar://problem/39999778> Reviewed by Tim Horton. Source/WebCore: It turns out that basing minimum layout size and shrink-to-fit behaviors off of the `shrink-to-fit` viewport argument poses compatibility risks with web pages that already specify `shrink-to-fit` to opt out of default viewport shrinking behaviors in 1/3 multitasking mode on iPad. One way to resolve this is to introduce a new viewport meta content attribute to disable viewport heuristics in extra zoom mode. However, combined shrink-to-fit and minimum device width behaviors are difficult to describe using a single backwards-compatible viewport meta content attribute, and the need to suppress the default behavior of `shrink-to-fit=no` if such an attribute is not disabled further muddles our viewport story. After some internal deliberation, we’ve decided to experiment with a new meta tag named "disabled-adaptations". The content of this meta tag is a comma-separated list of adaptation names; if an adaptation name matches a known adaptation type (for instance, extra zoom mode), we disable the class of behaviors used to adapt web content. The first and only known adaptation type is extra zoom mode, which affects `shrink-to-fit` and layout size adjustments. See per-method changes below for more details. Test: fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * dom/Document.cpp: (WebCore::Document::processDisabledAdaptations): * dom/Document.h: (WebCore::Document::disabledAdaptations const): Add disabled adaptations to Document. Changes to disabled adaptations are not propagated if the parsed disabled adaptation types don't change; upon changing adaptation types, notify the client to adjust for the new disabled adaptations (currently, this only affects the viewport configuration). * dom/ViewportArguments.h: * html/HTMLMetaElement.cpp: (WebCore::HTMLMetaElement::process): * html/parser/HTMLPreloadScanner.cpp: (WebCore::TokenPreloadScanner::StartTagScanner::StartTagScanner): (WebCore::TokenPreloadScanner::StartTagScanner::processAttributes): (WebCore::TokenPreloadScanner::StartTagScanner::processAttribute): * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Restore the set of disabled adaptations when restoring a page from the cache. * page/Chrome.cpp: (WebCore::Chrome::dispatchDisabledAdaptationsDidChange const): * page/Chrome.h: * page/ChromeClient.h: Add plumbing for changes to the set of disabled adaptations. * page/DisabledAdaptations.cpp: Added. (WebCore::extraZoomModeAdaptationName): * page/DisabledAdaptations.h: Added. Introduce a header containing a new enum for the extra zoom mode adaptation, as well as a helper function to return the extra zoom mode adaptation name. * page/Page.cpp: (WebCore::Page::disabledAdaptations const): Returns the mainframe's set of adaptations to disable. * page/Page.h: * page/RemoteFrame.h: * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setDisabledAdaptationsMetaTagEnabled): (WebCore::RuntimeEnabledFeatures::disabledAdaptationsMetaTagEnabled const): Add a new runtime feature to gate handling the "disabled-adaptations" meta tag. * page/ViewportConfiguration.cpp: (WebCore::shouldOverrideShrinkToFitArgument): (WebCore::needsUpdateAfterChangingDisabledAdaptations): (WebCore::ViewportConfiguration::setDisabledAdaptations): (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthAndShrinkToFit const): Consult whether or not extra zoom mode adaptations are disabled, instead of the shrink-to-fit attribute value. (WebCore::ViewportConfiguration::updateConfiguration): * page/ViewportConfiguration.h: Add an OptionSet of disabled adaptation types to ViewportConfiguration. Updates to the adaptation type are propagated to the ViewportConfiguration from Document, through the ChromeClient and the client layer (refer to changes in WebKit). Once the OptionSet is changed, we recompute the viewport configuration only if needed by the platform. (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::disabledAdaptations const): * page/WindowFeatures.cpp: (WebCore::parseDisabledAdaptations): * page/WindowFeatures.h: Add a new helper to parse the meta content of a "disabled-adaptations" tag as an OptionSet of disabled adaptation types. The string is parsed by first splitting on the comma character, and then iterating over lower case, whitespace-stripped tokens to look for known adaptation names. So far, only extra zoom mode is supported. * testing/Internals.cpp: (WebCore::Internals::extraZoomModeAdaptationName const): * testing/Internals.h: * testing/Internals.idl: Expose the extra zoom mode adaptation name to the DOM, only when running layout tests. Source/WebKit: Adds a new experimental feature for the "disabled-adaptations" meta tag, and adds plumbing in WebKit to propagate disabled adaptation changes to the ViewportConfiguration. The experimental feature is on by default in extra zoom mode. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::dispatchDisabledAdaptationsDidChange const): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::disabledAdaptationsDidChange): * WebProcess/WebPage/WebPage.h: Source/WebKitLegacy/ios: Adds a WebKitLegacy method stub for disabled adaptation plumbing. * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::dispatchDisabledAdaptationsDidChange const): LayoutTests: Refactor an existing layout test to exercise disabled adaptations in extra zoom mode. * fast/viewport/extrazoom/viewport-change-min-device-width.html: Removed. * fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html: Added. Canonical link: https://commits.webkit.org/201100@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231779 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-15 01:07:36 +00:00
const FloatSize& viewLayoutSize() const { return m_viewLayoutSize; }
[Extra zoom mode] Add a mechanism to zoom to fixed scales when double tapping in extra zoom mode https://bugs.webkit.org/show_bug.cgi?id=184435 <rdar://problem/38726260> Reviewed by Dean Jackson. Source/WebCore: Expose the size of the platform view. By default, in extra zoom mode, this *not* the same as the minimum layout size, since we lay out at a large width and then shrink down to real device dimensions when computing the initial scale (see r229063). ViewGestureGeometryCollector uses this in the process of computing a target zoom scale when double tapping. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::viewSize const): Source/WebKit: Adds support for an alternate codepath when computing a zoom rect when double tapping that doesn't take the hit- tested node into account, and instead cycles the zoom scale between 2 fixed values (in addition to the initial scale). In the next patch, these fixed scales will be determined by computing zoom scales needed to make most of the text on the page legible (i.e. the first text legibility zoom scale), and another to make all of the text on the page legible, with the exception of outliers (this is the second text legibility zoom scale). See comments below for more detail. * UIProcess/Cocoa/ViewGestureController.h: * UIProcess/Cocoa/ViewGestureController.messages.in: * UIProcess/ios/SmartMagnificationController.h: * UIProcess/ios/SmartMagnificationController.messages.in: * UIProcess/ios/SmartMagnificationController.mm: (WebKit::SmartMagnificationController::didCollectGeometryForSmartMagnificationGesture): * UIProcess/mac/ViewGestureControllerMac.mm: (WebKit::ViewGestureController::didCollectGeometryForSmartMagnificationGesture): * WebProcess/WebPage/ViewGestureGeometryCollector.cpp: (WebKit::ViewGestureGeometryCollector::dispatchDidCollectGeometryForSmartMagnificationGesture): Rename the boolean `isReplacedElement` argument to `fitEntireRect` instead. The UI process only uses this on iOS to determine whether or not to fit the entire element rect to the viewport and add padding. This patch renames this variable because we are not zooming to a replaced element in the case where text legibility on the page (rather than element geometry) is being used to figure out the zoom scale, but we still want to fit the entire target rect to the viewport. (WebKit::ViewGestureGeometryCollector::collectGeometryForSmartMagnificationGesture): If text legiblity zoom scaling is preferred, then compute first and second-level text legibility zoom scales to zoom to upon double tap (where the second zoom scale is greater than the first). To choose a target zoom scale, choose the lowest target zoom scale that is at least a small amount less than the current scale. If neither of the two scales fulfill this description, then zoom back out to the initial scale. This has the effect of consistently cycling between all three zoom scales as the user double taps. (WebKit::ViewGestureGeometryCollector::computeTextLegibilityScales): Introduce a new helper method that computes and caches target scales to zoom to when double tapping to zoom. If a cached pair of target scales is already present, it skips this computation and immediately returns it. (WebKit::ViewGestureGeometryCollector::computeZoomInformationForNode): (WebKit::ViewGestureGeometryCollector::computeMinimumAndMaximumViewportScales const): Factor out logic to compute min and max zoom scales into a separate helper, and call it from both computeZoomInformationForNode and computeTextLegibilityScales. (WebKit::ViewGestureGeometryCollector::mainFrameDidLayout): Invalidate cached text legibility scales when layout is triggered. * WebProcess/WebPage/ViewGestureGeometryCollector.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::mainFrameDidLayout): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::viewportConfiguration const): Expose WebPage's ViewportConfiguration as a const reference. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformPrefersTextLegibilityBasedZoomScaling const): Adds a platform hook for opting into text-legibility-based zoom scaling instead of regular hit-testing-based zoom scaling heuristics. Canonical link: https://commits.webkit.org/200031@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230506 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-11 01:02:53 +00:00
[iOS][WK2] Fix a few mistakes affecting the initial layout and the initial unobscured rect https://bugs.webkit.org/show_bug.cgi?id=132093 Source/WebCore: Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-04-23 Reviewed by Tim Horton. Change the minimum layout size to float point values to account for size defined on retina displays. The minimum layout size supports half-pixels, the value is rounded later when computing the layout size in document coordinates. * WebCore.exp.in: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::ViewportConfiguration): Setting the initial content size is incorrect. The layout size computation already take into account empty size for the first layout. Setting the content size upfront make the first computation incorrect when the viewport arguments specify the initial scale. (WebCore::ViewportConfiguration::setMinimumLayoutSize): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::minimumLayoutSize): Source/WebKit2: <rdar://problem/16703237> Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-04-23 Reviewed by Tim Horton. The user of WKWebView can setup a size on device pixels, which can add half a point to the minimum layout size. By rounding this up before applying the page scale, we ended up with rounding errors on the layout size and the transitory unobscured content rect. This patch fixes changes the minimal layout size to float point values to reduce the rounding problems. * UIProcess/API/Cocoa/WKWebView.mm: (setViewportConfigurationMinimumLayoutSize): (-[WKWebView _setMinimumLayoutSizeOverrideForMinimalUI:]): (-[WKWebView _beginAnimatedResizeWithUpdates:]): * UIProcess/WebPageProxy.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::dynamicViewportSizeUpdate): (WebKit::WebPageProxy::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPageProxy::setMinimumLayoutSizeForMinimalUI): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): Defaulting the content size to the minimum layout size only works if the initial-scale is 1. ViewportConfiguration knows exactly what to do before the first layout. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPage::setMinimumLayoutSizeForMinimalUI): (WebKit::WebPage::dynamicViewportSizeUpdate): A few fixes here: -setZoomedOutPageScaleFactor() was incorrectly using the initial scale. 99% of the time, initial scale and minimum scale are equal, but the page can specify something different with the viewport meta tag. -Use floating point for manipulating the minimum layout sizes, then round the value. -minimumLayoutSizeInDocumentCoordinate was scaled the wrong way around. (WebKit::WebPage::viewportConfigurationChanged): Canonical link: https://commits.webkit.org/150150@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@167735 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-04-24 02:13:06 +00:00
const FloatSize& minimumLayoutSize() const { return m_minimumLayoutSize; }
Remove WTF::Optional synonym for std::optional, using that class template directly instead https://bugs.webkit.org/show_bug.cgi?id=226433 Reviewed by Chris Dumez. Source/JavaScriptCore: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload): Use auto instead of Optional<>. Also use * instead of value() and nest the definition of the local inside an if statement in the case where it's an optional. * inspector/scripts/tests/expected/*: Regenerated these results. Source/WebCore: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. Source/WebCore/PAL: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. Source/WebDriver: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. Source/WebKit: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. * Scripts/webkit/tests: Regenerated expected results, by running the command "python Scripts/webkit/messages_unittest.py -r". (How am I supposed to know to do that?) Source/WebKitLegacy/ios: * WebCoreSupport/WebChromeClientIOS.h: Let the do-webcore-rename script rename Optional<> to std::optional<>. Source/WebKitLegacy/mac: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. Source/WebKitLegacy/win: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. Source/WTF: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. * wtf/Optional.h: Remove WTF::Optional. Tools: * <many files>: Let the do-webcore-rename script rename Optional<> to std::optional<>. Canonical link: https://commits.webkit.org/238290@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@278253 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2021-05-30 16:11:40 +00:00
WEBCORE_EXPORT bool setViewLayoutSize(const FloatSize&, std::optional<double>&& scaleFactor = std::nullopt, std::optional<double>&& effectiveWidth = std::nullopt);
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
[Extra zoom mode] Google search results are excessively zoomed in https://bugs.webkit.org/show_bug.cgi?id=185347 <rdar://problem/39999778> Reviewed by Tim Horton. Source/WebCore: It turns out that basing minimum layout size and shrink-to-fit behaviors off of the `shrink-to-fit` viewport argument poses compatibility risks with web pages that already specify `shrink-to-fit` to opt out of default viewport shrinking behaviors in 1/3 multitasking mode on iPad. One way to resolve this is to introduce a new viewport meta content attribute to disable viewport heuristics in extra zoom mode. However, combined shrink-to-fit and minimum device width behaviors are difficult to describe using a single backwards-compatible viewport meta content attribute, and the need to suppress the default behavior of `shrink-to-fit=no` if such an attribute is not disabled further muddles our viewport story. After some internal deliberation, we’ve decided to experiment with a new meta tag named "disabled-adaptations". The content of this meta tag is a comma-separated list of adaptation names; if an adaptation name matches a known adaptation type (for instance, extra zoom mode), we disable the class of behaviors used to adapt web content. The first and only known adaptation type is extra zoom mode, which affects `shrink-to-fit` and layout size adjustments. See per-method changes below for more details. Test: fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * dom/Document.cpp: (WebCore::Document::processDisabledAdaptations): * dom/Document.h: (WebCore::Document::disabledAdaptations const): Add disabled adaptations to Document. Changes to disabled adaptations are not propagated if the parsed disabled adaptation types don't change; upon changing adaptation types, notify the client to adjust for the new disabled adaptations (currently, this only affects the viewport configuration). * dom/ViewportArguments.h: * html/HTMLMetaElement.cpp: (WebCore::HTMLMetaElement::process): * html/parser/HTMLPreloadScanner.cpp: (WebCore::TokenPreloadScanner::StartTagScanner::StartTagScanner): (WebCore::TokenPreloadScanner::StartTagScanner::processAttributes): (WebCore::TokenPreloadScanner::StartTagScanner::processAttribute): * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Restore the set of disabled adaptations when restoring a page from the cache. * page/Chrome.cpp: (WebCore::Chrome::dispatchDisabledAdaptationsDidChange const): * page/Chrome.h: * page/ChromeClient.h: Add plumbing for changes to the set of disabled adaptations. * page/DisabledAdaptations.cpp: Added. (WebCore::extraZoomModeAdaptationName): * page/DisabledAdaptations.h: Added. Introduce a header containing a new enum for the extra zoom mode adaptation, as well as a helper function to return the extra zoom mode adaptation name. * page/Page.cpp: (WebCore::Page::disabledAdaptations const): Returns the mainframe's set of adaptations to disable. * page/Page.h: * page/RemoteFrame.h: * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setDisabledAdaptationsMetaTagEnabled): (WebCore::RuntimeEnabledFeatures::disabledAdaptationsMetaTagEnabled const): Add a new runtime feature to gate handling the "disabled-adaptations" meta tag. * page/ViewportConfiguration.cpp: (WebCore::shouldOverrideShrinkToFitArgument): (WebCore::needsUpdateAfterChangingDisabledAdaptations): (WebCore::ViewportConfiguration::setDisabledAdaptations): (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthAndShrinkToFit const): Consult whether or not extra zoom mode adaptations are disabled, instead of the shrink-to-fit attribute value. (WebCore::ViewportConfiguration::updateConfiguration): * page/ViewportConfiguration.h: Add an OptionSet of disabled adaptation types to ViewportConfiguration. Updates to the adaptation type are propagated to the ViewportConfiguration from Document, through the ChromeClient and the client layer (refer to changes in WebKit). Once the OptionSet is changed, we recompute the viewport configuration only if needed by the platform. (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::disabledAdaptations const): * page/WindowFeatures.cpp: (WebCore::parseDisabledAdaptations): * page/WindowFeatures.h: Add a new helper to parse the meta content of a "disabled-adaptations" tag as an OptionSet of disabled adaptation types. The string is parsed by first splitting on the comma character, and then iterating over lower case, whitespace-stripped tokens to look for known adaptation names. So far, only extra zoom mode is supported. * testing/Internals.cpp: (WebCore::Internals::extraZoomModeAdaptationName const): * testing/Internals.h: * testing/Internals.idl: Expose the extra zoom mode adaptation name to the DOM, only when running layout tests. Source/WebKit: Adds a new experimental feature for the "disabled-adaptations" meta tag, and adds plumbing in WebKit to propagate disabled adaptation changes to the ViewportConfiguration. The experimental feature is on by default in extra zoom mode. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::dispatchDisabledAdaptationsDidChange const): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::disabledAdaptationsDidChange): * WebProcess/WebPage/WebPage.h: Source/WebKitLegacy/ios: Adds a WebKitLegacy method stub for disabled adaptation plumbing. * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::dispatchDisabledAdaptationsDidChange const): LayoutTests: Refactor an existing layout test to exercise disabled adaptations in extra zoom mode. * fast/viewport/extrazoom/viewport-change-min-device-width.html: Removed. * fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html: Added. Canonical link: https://commits.webkit.org/201100@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231779 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-15 01:07:36 +00:00
const OptionSet<DisabledAdaptations>& disabledAdaptations() const { return m_disabledAdaptations; }
WEBCORE_EXPORT bool setDisabledAdaptations(const OptionSet<DisabledAdaptations>&);
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
const ViewportArguments& viewportArguments() const { return m_viewportArguments; }
WEBCORE_EXPORT bool setViewportArguments(const ViewportArguments&);
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
WEBCORE_EXPORT bool setCanIgnoreScalingConstraints(bool);
[iOS] Add a version of viewport shrink-to-fit heuristics that preserves page layout https://bugs.webkit.org/show_bug.cgi?id=197342 <rdar://problem/50063091> Reviewed by Tim Horton. Source/WebCore: Adds support for a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. See WebKit ChangeLog for more details. Tests: fast/viewport/ios/shrink-to-fit-content-constant-width.html fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html fast/viewport/ios/shrink-to-fit-content-no-viewport.html fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setIsKnownToLayOutWiderThanViewport): (WebCore::ViewportConfiguration::description const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::canIgnoreScalingConstraints const): (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add several new getters and setters in ViewportConfiguration. (WebCore::ViewportConfiguration::isKnownToLayOutWiderThanViewport const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): Importantly, only allow ignoring the minimum effective device width in webpages with responsive viewports, if they also have *not* laid out wider than the viewport. (WebCore::ViewportConfiguration::setForceAlwaysUserScalable): Source/WebKit: This patch introduces a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. This is similar to existing shrink-to-fit behaviors used for viewport sizing in multitasking mode, except that it not only scales the view, but additionally expands the layout size, such that the overall layout of the page is preserved. In fact, the reason we ended up reverting the existing flavor of shrink-to-fit in all cases except for multitasking was that page layout was not preserved, which caused elements that poke out of the viewport to make the rest of the page look out of proportion — see <rdar://problem/23818102> and related radars. Covered by 5 new layout tests, and by adjusting a couple of existing layout tests. See comments below for more details. * Platform/Logging.h: Add a new ViewportSizing logging channel. This will only log on pages that overflow the viewport and shrink to fit as a result. * Shared/WebPreferences.yaml: Turn IgnoreViewportScalingConstraints off by default. This preference currently controls whether we allow shrink-to-fit behaviors, and is only used by Safari when it is in multitasking mode. The value of this preference is currenly *on* by default, and is turned off almost immediately during every page load after the first visible content rect update, wherein visibleContentRectUpdateInfo.allowShrinkToFit() is false. However, this sometimes causes a brief jitter during page load; to fix this, make the default value for IgnoreViewportScalingConstraints false, and change the logic in WebPage::updateVisibleContentRects to setCanIgnoreScalingConstraints to true if either the IgnoreViewportScalingConstraints preference (not only affected by an internal debug switch) is true, or WKWebView SPI is used to enable the behavior. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): (WebKit::WebFrameLoaderClient::dispatchDidFinishLoad): Add a new hook for WebFrameLoaderClient to call into WebPage when document load finishes. Also, tweak dispatchDidFinishLoad to take a WebFrame& instead of a WebFrame* in a drive-by fix (the frame is assumed to be non-null anyways). * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::didFinishDocumentLoad): (WebKit::WebPage::didFinishLoad): When finishing document load or finishing the overall load, kick off the shrink-to-fit timer; when committing a load, cancel the timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Don't allow the minimum effective device width from the client to stomp over any minimum effective device width set as a result of the new shrink-to-fit heuristic; on some pages that load quickly, this can result in a race where the minimum effective device width (i.e. a value that lower-bounds the minimum layout width) is first set by the shrink-to-fit heuristic, and then set to an incorrect value by the client. In the near future, web view SPI used to set the minimum effective device width should actually be removed altogether, since the new shrink-to-fit heuristic supersedes any need for the client to fiddle with the minimum effective device width. (WebKit::WebPage::dynamicViewportSizeUpdate): When performing a dynamic viewport size update, additionally re-run the shrink-to-fit heuristic. This allows the minimum layout size of the viewport to be updated, if necessary. An example of where this matters is when a web page is *below* a tablet/desktop layout breakpoint in portrait device orientation, but then exceeds this layout breakpoint in landscape orientation. In this scenario, rotating the device should swap between these two page layouts. (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::scheduleShrinkToFitContent): (WebKit::WebPage::shrinkToFitContentTimerFired): (WebKit::WebPage::immediatelyShrinkToFitContent): Leverage the existing capability for a viewport to have a "minimum effective device width" to grant the viewport a larger layout size than it would normally have, and then scale down to fit within the bounds of the view. One challenge with this overall approach is that laying out at a larger width may cause the page to lay out even wider in response, which may actually worsen horizontal scrolling. To mitigate this, we only attempt to lay out at the current content width once; if laying out at this width reduced the amount of horizontal scrolling by any amount, then proceed with this layout width; otherwise, revert to the previous layout width. (WebKit::WebPage::shouldIgnoreMetaViewport const): Pull some common logic out into a readonly getter. (WebKit::WebPage::updateVisibleContentRects): See the comment below WebPreferences.yaml, above. LayoutTests: Introduces new layout tests, and adjusts some existing tests. See comments below. * fast/viewport/ios/shrink-to-fit-content-constant-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-constant-width.html: Added. Add a new layout test to exercise the scenario where a constant width viewport narrower than the view is used. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html: Added. Add a new layout test to exercise the scenario where a responsive website that lays out larger than the view width ends up with even more horizontal scrolling when laying out at the initial content width. In this scenario, we shouldn't try to expand the viewport to try and encompass the content width, since that would only induce even worse horizontal scrolling. * fast/viewport/ios/shrink-to-fit-content-no-viewport-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-no-viewport.html: Added. Add a new layout test for the case where there is no viewport, but content lays out wider than the view. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html: Added. Add a new layout test for the case where the page has opted for a responsive viewport (device-width, initial scale 1), but has laid out wider than the viewport anyways. In this case, we want to shrink the contents down to fit inside the view. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html: Added. Add a new layout test to exercise the case where, during page load, content width temporarily increases, and then decreases such that it once again fits within the viewport. In this case, we don't want to expand the viewport to be as wide as the large temporary width of the page. * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden.html: * fast/viewport/ios/width-is-device-width-overflowing-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing.html: Tweak these 2 existing layout tests to include "shrink-to-fit=no", to prevent the new heuristics from shrinking the page to fit on device classes that use native viewports by default. * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-expected.txt: Canonical link: https://commits.webkit.org/211651@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-01 21:08:38 +00:00
constexpr bool canIgnoreScalingConstraints() const { return m_canIgnoreScalingConstraints; }
[iPadOS] Wikipedia articles lay out incorrectly in 1/3 multitasking window https://bugs.webkit.org/show_bug.cgi?id=210501 <rdar://problem/54856323> Reviewed by Tim Horton. Source/WebCore: In a 1/3 multitasking window, Safari currently uses the `-[WKWebView _allowsViewportShrinkToFit]` SPI to force pages to shrink down by fitting the content width to the view width. This legacy method of shrinking to fit involves laying the page out at the normal view width (320px in 1/3 multitasking), and then scaling the page down such that any amount of horizontal overflow fits within the view. In iOS 13, a new style of shrinking to fit was introduced in support of two new features: page zoom controls (accessible via the page formatting menu), and on-by-default page scaling when loading desktop sites on certain models of iPad where the page width is less than cutoffs of 1112px (in landscape) and 1024px (in portrait). This new method of shrinking to fit involves laying out at a larger width (computed from a combination of the minimum effective device width and layout size scale factor), and scaling to fit the effective layout size scale factor instead of the entire contents of the page. This means that while we may still get horizontal scrolling after shrinking to fit, the overall layout of the page is preserved. Currently, in 1/3 multitasking, Safari still relies on the former to scale pages down to fit, which means that Wikipedia articles (among other websites) do not lay out sensibly. Moreover, even if Safari adopted the second mechanism for shrinking to fit, layout issues would still exist (albeit to a lesser degree), since we'd still attempt to shrink the content width down to fit due to the fact that the desktop version of Wikipedia doesn't have a meta viewport. While we wouldn't get a broken layout, we'd still have a blank column running down the right side of the page, which is less than ideal. It's clear that in this case, attempting to shrink page content down to fit the view is suboptimal (at best, it leads to a large portion of the page being blank; at worst, it completely breaks page layout). To address this bug for now, add a parallel minimumEffectiveDeviceWidth value that takes effect when ignoring scaling constraints (i.e. when we're in a multitasking window), and scale the page down to fit this value instead of fitting the full content width when computing initial scale in `ViewportConfiguration::initialScaleFromSize`. Maintaining this value separately from m_minimumEffectiveDeviceWidth makes it much easier to ensure that the effects of this change are only ever active when the quirk is applied, and also when the view is embedded in a multitasking window. * page/Quirks.cpp: (WebCore::Quirks::shouldLayOutAtMinimumWindowWidthWhenIgnoringScalingConstraints const): Introduce a quirk to fix layout issues in multitasking mode on the desktop version of Wikipedia. * page/Quirks.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints): * page/ViewportConfiguration.h: Add a minimum effective device width value that only takes effect when ignoring scaling constraints, and update `shouldIgnoreMinimumEffectiveDeviceWidth()` and `minimumEffectiveDeviceWidth()` to not always return `true` and `0` (respectively) when ignoring scaling constraints, if m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints is set. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldShrinkToFitMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints const): Source/WebKit: Apply the viewport quirk if needed; see WebCore/ChangeLog for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateVisibleContentRects): Canonical link: https://commits.webkit.org/223384@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260090 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-14 19:15:45 +00:00
WEBCORE_EXPORT bool setMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints(double);
[iOS] Add a version of viewport shrink-to-fit heuristics that preserves page layout https://bugs.webkit.org/show_bug.cgi?id=197342 <rdar://problem/50063091> Reviewed by Tim Horton. Source/WebCore: Adds support for a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. See WebKit ChangeLog for more details. Tests: fast/viewport/ios/shrink-to-fit-content-constant-width.html fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html fast/viewport/ios/shrink-to-fit-content-no-viewport.html fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setIsKnownToLayOutWiderThanViewport): (WebCore::ViewportConfiguration::description const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::canIgnoreScalingConstraints const): (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add several new getters and setters in ViewportConfiguration. (WebCore::ViewportConfiguration::isKnownToLayOutWiderThanViewport const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): Importantly, only allow ignoring the minimum effective device width in webpages with responsive viewports, if they also have *not* laid out wider than the viewport. (WebCore::ViewportConfiguration::setForceAlwaysUserScalable): Source/WebKit: This patch introduces a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. This is similar to existing shrink-to-fit behaviors used for viewport sizing in multitasking mode, except that it not only scales the view, but additionally expands the layout size, such that the overall layout of the page is preserved. In fact, the reason we ended up reverting the existing flavor of shrink-to-fit in all cases except for multitasking was that page layout was not preserved, which caused elements that poke out of the viewport to make the rest of the page look out of proportion — see <rdar://problem/23818102> and related radars. Covered by 5 new layout tests, and by adjusting a couple of existing layout tests. See comments below for more details. * Platform/Logging.h: Add a new ViewportSizing logging channel. This will only log on pages that overflow the viewport and shrink to fit as a result. * Shared/WebPreferences.yaml: Turn IgnoreViewportScalingConstraints off by default. This preference currently controls whether we allow shrink-to-fit behaviors, and is only used by Safari when it is in multitasking mode. The value of this preference is currenly *on* by default, and is turned off almost immediately during every page load after the first visible content rect update, wherein visibleContentRectUpdateInfo.allowShrinkToFit() is false. However, this sometimes causes a brief jitter during page load; to fix this, make the default value for IgnoreViewportScalingConstraints false, and change the logic in WebPage::updateVisibleContentRects to setCanIgnoreScalingConstraints to true if either the IgnoreViewportScalingConstraints preference (not only affected by an internal debug switch) is true, or WKWebView SPI is used to enable the behavior. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): (WebKit::WebFrameLoaderClient::dispatchDidFinishLoad): Add a new hook for WebFrameLoaderClient to call into WebPage when document load finishes. Also, tweak dispatchDidFinishLoad to take a WebFrame& instead of a WebFrame* in a drive-by fix (the frame is assumed to be non-null anyways). * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::didFinishDocumentLoad): (WebKit::WebPage::didFinishLoad): When finishing document load or finishing the overall load, kick off the shrink-to-fit timer; when committing a load, cancel the timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Don't allow the minimum effective device width from the client to stomp over any minimum effective device width set as a result of the new shrink-to-fit heuristic; on some pages that load quickly, this can result in a race where the minimum effective device width (i.e. a value that lower-bounds the minimum layout width) is first set by the shrink-to-fit heuristic, and then set to an incorrect value by the client. In the near future, web view SPI used to set the minimum effective device width should actually be removed altogether, since the new shrink-to-fit heuristic supersedes any need for the client to fiddle with the minimum effective device width. (WebKit::WebPage::dynamicViewportSizeUpdate): When performing a dynamic viewport size update, additionally re-run the shrink-to-fit heuristic. This allows the minimum layout size of the viewport to be updated, if necessary. An example of where this matters is when a web page is *below* a tablet/desktop layout breakpoint in portrait device orientation, but then exceeds this layout breakpoint in landscape orientation. In this scenario, rotating the device should swap between these two page layouts. (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::scheduleShrinkToFitContent): (WebKit::WebPage::shrinkToFitContentTimerFired): (WebKit::WebPage::immediatelyShrinkToFitContent): Leverage the existing capability for a viewport to have a "minimum effective device width" to grant the viewport a larger layout size than it would normally have, and then scale down to fit within the bounds of the view. One challenge with this overall approach is that laying out at a larger width may cause the page to lay out even wider in response, which may actually worsen horizontal scrolling. To mitigate this, we only attempt to lay out at the current content width once; if laying out at this width reduced the amount of horizontal scrolling by any amount, then proceed with this layout width; otherwise, revert to the previous layout width. (WebKit::WebPage::shouldIgnoreMetaViewport const): Pull some common logic out into a readonly getter. (WebKit::WebPage::updateVisibleContentRects): See the comment below WebPreferences.yaml, above. LayoutTests: Introduces new layout tests, and adjusts some existing tests. See comments below. * fast/viewport/ios/shrink-to-fit-content-constant-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-constant-width.html: Added. Add a new layout test to exercise the scenario where a constant width viewport narrower than the view is used. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html: Added. Add a new layout test to exercise the scenario where a responsive website that lays out larger than the view width ends up with even more horizontal scrolling when laying out at the initial content width. In this scenario, we shouldn't try to expand the viewport to try and encompass the content width, since that would only induce even worse horizontal scrolling. * fast/viewport/ios/shrink-to-fit-content-no-viewport-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-no-viewport.html: Added. Add a new layout test for the case where there is no viewport, but content lays out wider than the view. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html: Added. Add a new layout test for the case where the page has opted for a responsive viewport (device-width, initial scale 1), but has laid out wider than the viewport anyways. In this case, we want to shrink the contents down to fit inside the view. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html: Added. Add a new layout test to exercise the case where, during page load, content width temporarily increases, and then decreases such that it once again fits within the viewport. In this case, we don't want to expand the viewport to be as wide as the large temporary width of the page. * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden.html: * fast/viewport/ios/width-is-device-width-overflowing-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing.html: Tweak these 2 existing layout tests to include "shrink-to-fit=no", to prevent the new heuristics from shrinking the page to fit on device classes that use native viewports by default. * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-expected.txt: Canonical link: https://commits.webkit.org/211651@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-01 21:08:38 +00:00
WEBCORE_EXPORT bool setMinimumEffectiveDeviceWidth(double);
constexpr double minimumEffectiveDeviceWidth() const
{
if (shouldIgnoreMinimumEffectiveDeviceWidth())
return 0;
[iPadOS] Wikipedia articles lay out incorrectly in 1/3 multitasking window https://bugs.webkit.org/show_bug.cgi?id=210501 <rdar://problem/54856323> Reviewed by Tim Horton. Source/WebCore: In a 1/3 multitasking window, Safari currently uses the `-[WKWebView _allowsViewportShrinkToFit]` SPI to force pages to shrink down by fitting the content width to the view width. This legacy method of shrinking to fit involves laying the page out at the normal view width (320px in 1/3 multitasking), and then scaling the page down such that any amount of horizontal overflow fits within the view. In iOS 13, a new style of shrinking to fit was introduced in support of two new features: page zoom controls (accessible via the page formatting menu), and on-by-default page scaling when loading desktop sites on certain models of iPad where the page width is less than cutoffs of 1112px (in landscape) and 1024px (in portrait). This new method of shrinking to fit involves laying out at a larger width (computed from a combination of the minimum effective device width and layout size scale factor), and scaling to fit the effective layout size scale factor instead of the entire contents of the page. This means that while we may still get horizontal scrolling after shrinking to fit, the overall layout of the page is preserved. Currently, in 1/3 multitasking, Safari still relies on the former to scale pages down to fit, which means that Wikipedia articles (among other websites) do not lay out sensibly. Moreover, even if Safari adopted the second mechanism for shrinking to fit, layout issues would still exist (albeit to a lesser degree), since we'd still attempt to shrink the content width down to fit due to the fact that the desktop version of Wikipedia doesn't have a meta viewport. While we wouldn't get a broken layout, we'd still have a blank column running down the right side of the page, which is less than ideal. It's clear that in this case, attempting to shrink page content down to fit the view is suboptimal (at best, it leads to a large portion of the page being blank; at worst, it completely breaks page layout). To address this bug for now, add a parallel minimumEffectiveDeviceWidth value that takes effect when ignoring scaling constraints (i.e. when we're in a multitasking window), and scale the page down to fit this value instead of fitting the full content width when computing initial scale in `ViewportConfiguration::initialScaleFromSize`. Maintaining this value separately from m_minimumEffectiveDeviceWidth makes it much easier to ensure that the effects of this change are only ever active when the quirk is applied, and also when the view is embedded in a multitasking window. * page/Quirks.cpp: (WebCore::Quirks::shouldLayOutAtMinimumWindowWidthWhenIgnoringScalingConstraints const): Introduce a quirk to fix layout issues in multitasking mode on the desktop version of Wikipedia. * page/Quirks.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints): * page/ViewportConfiguration.h: Add a minimum effective device width value that only takes effect when ignoring scaling constraints, and update `shouldIgnoreMinimumEffectiveDeviceWidth()` and `minimumEffectiveDeviceWidth()` to not always return `true` and `0` (respectively) when ignoring scaling constraints, if m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints is set. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldShrinkToFitMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints const): Source/WebKit: Apply the viewport quirk if needed; see WebCore/ChangeLog for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateVisibleContentRects): Canonical link: https://commits.webkit.org/223384@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260090 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-14 19:15:45 +00:00
return m_canIgnoreScalingConstraints ? m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints : m_minimumEffectiveDeviceWidth;
[iOS] Add a version of viewport shrink-to-fit heuristics that preserves page layout https://bugs.webkit.org/show_bug.cgi?id=197342 <rdar://problem/50063091> Reviewed by Tim Horton. Source/WebCore: Adds support for a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. See WebKit ChangeLog for more details. Tests: fast/viewport/ios/shrink-to-fit-content-constant-width.html fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html fast/viewport/ios/shrink-to-fit-content-no-viewport.html fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setIsKnownToLayOutWiderThanViewport): (WebCore::ViewportConfiguration::description const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::canIgnoreScalingConstraints const): (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add several new getters and setters in ViewportConfiguration. (WebCore::ViewportConfiguration::isKnownToLayOutWiderThanViewport const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): Importantly, only allow ignoring the minimum effective device width in webpages with responsive viewports, if they also have *not* laid out wider than the viewport. (WebCore::ViewportConfiguration::setForceAlwaysUserScalable): Source/WebKit: This patch introduces a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. This is similar to existing shrink-to-fit behaviors used for viewport sizing in multitasking mode, except that it not only scales the view, but additionally expands the layout size, such that the overall layout of the page is preserved. In fact, the reason we ended up reverting the existing flavor of shrink-to-fit in all cases except for multitasking was that page layout was not preserved, which caused elements that poke out of the viewport to make the rest of the page look out of proportion — see <rdar://problem/23818102> and related radars. Covered by 5 new layout tests, and by adjusting a couple of existing layout tests. See comments below for more details. * Platform/Logging.h: Add a new ViewportSizing logging channel. This will only log on pages that overflow the viewport and shrink to fit as a result. * Shared/WebPreferences.yaml: Turn IgnoreViewportScalingConstraints off by default. This preference currently controls whether we allow shrink-to-fit behaviors, and is only used by Safari when it is in multitasking mode. The value of this preference is currenly *on* by default, and is turned off almost immediately during every page load after the first visible content rect update, wherein visibleContentRectUpdateInfo.allowShrinkToFit() is false. However, this sometimes causes a brief jitter during page load; to fix this, make the default value for IgnoreViewportScalingConstraints false, and change the logic in WebPage::updateVisibleContentRects to setCanIgnoreScalingConstraints to true if either the IgnoreViewportScalingConstraints preference (not only affected by an internal debug switch) is true, or WKWebView SPI is used to enable the behavior. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): (WebKit::WebFrameLoaderClient::dispatchDidFinishLoad): Add a new hook for WebFrameLoaderClient to call into WebPage when document load finishes. Also, tweak dispatchDidFinishLoad to take a WebFrame& instead of a WebFrame* in a drive-by fix (the frame is assumed to be non-null anyways). * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::didFinishDocumentLoad): (WebKit::WebPage::didFinishLoad): When finishing document load or finishing the overall load, kick off the shrink-to-fit timer; when committing a load, cancel the timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Don't allow the minimum effective device width from the client to stomp over any minimum effective device width set as a result of the new shrink-to-fit heuristic; on some pages that load quickly, this can result in a race where the minimum effective device width (i.e. a value that lower-bounds the minimum layout width) is first set by the shrink-to-fit heuristic, and then set to an incorrect value by the client. In the near future, web view SPI used to set the minimum effective device width should actually be removed altogether, since the new shrink-to-fit heuristic supersedes any need for the client to fiddle with the minimum effective device width. (WebKit::WebPage::dynamicViewportSizeUpdate): When performing a dynamic viewport size update, additionally re-run the shrink-to-fit heuristic. This allows the minimum layout size of the viewport to be updated, if necessary. An example of where this matters is when a web page is *below* a tablet/desktop layout breakpoint in portrait device orientation, but then exceeds this layout breakpoint in landscape orientation. In this scenario, rotating the device should swap between these two page layouts. (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::scheduleShrinkToFitContent): (WebKit::WebPage::shrinkToFitContentTimerFired): (WebKit::WebPage::immediatelyShrinkToFitContent): Leverage the existing capability for a viewport to have a "minimum effective device width" to grant the viewport a larger layout size than it would normally have, and then scale down to fit within the bounds of the view. One challenge with this overall approach is that laying out at a larger width may cause the page to lay out even wider in response, which may actually worsen horizontal scrolling. To mitigate this, we only attempt to lay out at the current content width once; if laying out at this width reduced the amount of horizontal scrolling by any amount, then proceed with this layout width; otherwise, revert to the previous layout width. (WebKit::WebPage::shouldIgnoreMetaViewport const): Pull some common logic out into a readonly getter. (WebKit::WebPage::updateVisibleContentRects): See the comment below WebPreferences.yaml, above. LayoutTests: Introduces new layout tests, and adjusts some existing tests. See comments below. * fast/viewport/ios/shrink-to-fit-content-constant-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-constant-width.html: Added. Add a new layout test to exercise the scenario where a constant width viewport narrower than the view is used. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html: Added. Add a new layout test to exercise the scenario where a responsive website that lays out larger than the view width ends up with even more horizontal scrolling when laying out at the initial content width. In this scenario, we shouldn't try to expand the viewport to try and encompass the content width, since that would only induce even worse horizontal scrolling. * fast/viewport/ios/shrink-to-fit-content-no-viewport-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-no-viewport.html: Added. Add a new layout test for the case where there is no viewport, but content lays out wider than the view. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html: Added. Add a new layout test for the case where the page has opted for a responsive viewport (device-width, initial scale 1), but has laid out wider than the viewport anyways. In this case, we want to shrink the contents down to fit inside the view. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html: Added. Add a new layout test to exercise the case where, during page load, content width temporarily increases, and then decreases such that it once again fits within the viewport. In this case, we don't want to expand the viewport to be as wide as the large temporary width of the page. * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden.html: * fast/viewport/ios/width-is-device-width-overflowing-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing.html: Tweak these 2 existing layout tests to include "shrink-to-fit=no", to prevent the new heuristics from shrinking the page to fit on device classes that use native viewports by default. * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-expected.txt: Canonical link: https://commits.webkit.org/211651@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-01 21:08:38 +00:00
}
constexpr bool isKnownToLayOutWiderThanViewport() const { return m_isKnownToLayOutWiderThanViewport; }
WEBCORE_EXPORT bool setIsKnownToLayOutWiderThanViewport(bool value);
constexpr bool shouldIgnoreMinimumEffectiveDeviceWidth() const
{
[iPadOS] Wikipedia articles lay out incorrectly in 1/3 multitasking window https://bugs.webkit.org/show_bug.cgi?id=210501 <rdar://problem/54856323> Reviewed by Tim Horton. Source/WebCore: In a 1/3 multitasking window, Safari currently uses the `-[WKWebView _allowsViewportShrinkToFit]` SPI to force pages to shrink down by fitting the content width to the view width. This legacy method of shrinking to fit involves laying the page out at the normal view width (320px in 1/3 multitasking), and then scaling the page down such that any amount of horizontal overflow fits within the view. In iOS 13, a new style of shrinking to fit was introduced in support of two new features: page zoom controls (accessible via the page formatting menu), and on-by-default page scaling when loading desktop sites on certain models of iPad where the page width is less than cutoffs of 1112px (in landscape) and 1024px (in portrait). This new method of shrinking to fit involves laying out at a larger width (computed from a combination of the minimum effective device width and layout size scale factor), and scaling to fit the effective layout size scale factor instead of the entire contents of the page. This means that while we may still get horizontal scrolling after shrinking to fit, the overall layout of the page is preserved. Currently, in 1/3 multitasking, Safari still relies on the former to scale pages down to fit, which means that Wikipedia articles (among other websites) do not lay out sensibly. Moreover, even if Safari adopted the second mechanism for shrinking to fit, layout issues would still exist (albeit to a lesser degree), since we'd still attempt to shrink the content width down to fit due to the fact that the desktop version of Wikipedia doesn't have a meta viewport. While we wouldn't get a broken layout, we'd still have a blank column running down the right side of the page, which is less than ideal. It's clear that in this case, attempting to shrink page content down to fit the view is suboptimal (at best, it leads to a large portion of the page being blank; at worst, it completely breaks page layout). To address this bug for now, add a parallel minimumEffectiveDeviceWidth value that takes effect when ignoring scaling constraints (i.e. when we're in a multitasking window), and scale the page down to fit this value instead of fitting the full content width when computing initial scale in `ViewportConfiguration::initialScaleFromSize`. Maintaining this value separately from m_minimumEffectiveDeviceWidth makes it much easier to ensure that the effects of this change are only ever active when the quirk is applied, and also when the view is embedded in a multitasking window. * page/Quirks.cpp: (WebCore::Quirks::shouldLayOutAtMinimumWindowWidthWhenIgnoringScalingConstraints const): Introduce a quirk to fix layout issues in multitasking mode on the desktop version of Wikipedia. * page/Quirks.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints): * page/ViewportConfiguration.h: Add a minimum effective device width value that only takes effect when ignoring scaling constraints, and update `shouldIgnoreMinimumEffectiveDeviceWidth()` and `minimumEffectiveDeviceWidth()` to not always return `true` and `0` (respectively) when ignoring scaling constraints, if m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints is set. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldShrinkToFitMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints const): Source/WebKit: Apply the viewport quirk if needed; see WebCore/ChangeLog for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateVisibleContentRects): Canonical link: https://commits.webkit.org/223384@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260090 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-14 19:15:45 +00:00
if (shouldShrinkToFitMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints())
return false;
[iOS] Add a version of viewport shrink-to-fit heuristics that preserves page layout https://bugs.webkit.org/show_bug.cgi?id=197342 <rdar://problem/50063091> Reviewed by Tim Horton. Source/WebCore: Adds support for a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. See WebKit ChangeLog for more details. Tests: fast/viewport/ios/shrink-to-fit-content-constant-width.html fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html fast/viewport/ios/shrink-to-fit-content-no-viewport.html fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setIsKnownToLayOutWiderThanViewport): (WebCore::ViewportConfiguration::description const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::canIgnoreScalingConstraints const): (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add several new getters and setters in ViewportConfiguration. (WebCore::ViewportConfiguration::isKnownToLayOutWiderThanViewport const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): Importantly, only allow ignoring the minimum effective device width in webpages with responsive viewports, if they also have *not* laid out wider than the viewport. (WebCore::ViewportConfiguration::setForceAlwaysUserScalable): Source/WebKit: This patch introduces a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. This is similar to existing shrink-to-fit behaviors used for viewport sizing in multitasking mode, except that it not only scales the view, but additionally expands the layout size, such that the overall layout of the page is preserved. In fact, the reason we ended up reverting the existing flavor of shrink-to-fit in all cases except for multitasking was that page layout was not preserved, which caused elements that poke out of the viewport to make the rest of the page look out of proportion — see <rdar://problem/23818102> and related radars. Covered by 5 new layout tests, and by adjusting a couple of existing layout tests. See comments below for more details. * Platform/Logging.h: Add a new ViewportSizing logging channel. This will only log on pages that overflow the viewport and shrink to fit as a result. * Shared/WebPreferences.yaml: Turn IgnoreViewportScalingConstraints off by default. This preference currently controls whether we allow shrink-to-fit behaviors, and is only used by Safari when it is in multitasking mode. The value of this preference is currenly *on* by default, and is turned off almost immediately during every page load after the first visible content rect update, wherein visibleContentRectUpdateInfo.allowShrinkToFit() is false. However, this sometimes causes a brief jitter during page load; to fix this, make the default value for IgnoreViewportScalingConstraints false, and change the logic in WebPage::updateVisibleContentRects to setCanIgnoreScalingConstraints to true if either the IgnoreViewportScalingConstraints preference (not only affected by an internal debug switch) is true, or WKWebView SPI is used to enable the behavior. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): (WebKit::WebFrameLoaderClient::dispatchDidFinishLoad): Add a new hook for WebFrameLoaderClient to call into WebPage when document load finishes. Also, tweak dispatchDidFinishLoad to take a WebFrame& instead of a WebFrame* in a drive-by fix (the frame is assumed to be non-null anyways). * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::didFinishDocumentLoad): (WebKit::WebPage::didFinishLoad): When finishing document load or finishing the overall load, kick off the shrink-to-fit timer; when committing a load, cancel the timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Don't allow the minimum effective device width from the client to stomp over any minimum effective device width set as a result of the new shrink-to-fit heuristic; on some pages that load quickly, this can result in a race where the minimum effective device width (i.e. a value that lower-bounds the minimum layout width) is first set by the shrink-to-fit heuristic, and then set to an incorrect value by the client. In the near future, web view SPI used to set the minimum effective device width should actually be removed altogether, since the new shrink-to-fit heuristic supersedes any need for the client to fiddle with the minimum effective device width. (WebKit::WebPage::dynamicViewportSizeUpdate): When performing a dynamic viewport size update, additionally re-run the shrink-to-fit heuristic. This allows the minimum layout size of the viewport to be updated, if necessary. An example of where this matters is when a web page is *below* a tablet/desktop layout breakpoint in portrait device orientation, but then exceeds this layout breakpoint in landscape orientation. In this scenario, rotating the device should swap between these two page layouts. (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::scheduleShrinkToFitContent): (WebKit::WebPage::shrinkToFitContentTimerFired): (WebKit::WebPage::immediatelyShrinkToFitContent): Leverage the existing capability for a viewport to have a "minimum effective device width" to grant the viewport a larger layout size than it would normally have, and then scale down to fit within the bounds of the view. One challenge with this overall approach is that laying out at a larger width may cause the page to lay out even wider in response, which may actually worsen horizontal scrolling. To mitigate this, we only attempt to lay out at the current content width once; if laying out at this width reduced the amount of horizontal scrolling by any amount, then proceed with this layout width; otherwise, revert to the previous layout width. (WebKit::WebPage::shouldIgnoreMetaViewport const): Pull some common logic out into a readonly getter. (WebKit::WebPage::updateVisibleContentRects): See the comment below WebPreferences.yaml, above. LayoutTests: Introduces new layout tests, and adjusts some existing tests. See comments below. * fast/viewport/ios/shrink-to-fit-content-constant-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-constant-width.html: Added. Add a new layout test to exercise the scenario where a constant width viewport narrower than the view is used. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html: Added. Add a new layout test to exercise the scenario where a responsive website that lays out larger than the view width ends up with even more horizontal scrolling when laying out at the initial content width. In this scenario, we shouldn't try to expand the viewport to try and encompass the content width, since that would only induce even worse horizontal scrolling. * fast/viewport/ios/shrink-to-fit-content-no-viewport-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-no-viewport.html: Added. Add a new layout test for the case where there is no viewport, but content lays out wider than the view. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html: Added. Add a new layout test for the case where the page has opted for a responsive viewport (device-width, initial scale 1), but has laid out wider than the viewport anyways. In this case, we want to shrink the contents down to fit inside the view. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html: Added. Add a new layout test to exercise the case where, during page load, content width temporarily increases, and then decreases such that it once again fits within the viewport. In this case, we don't want to expand the viewport to be as wide as the large temporary width of the page. * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden.html: * fast/viewport/ios/width-is-device-width-overflowing-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing.html: Tweak these 2 existing layout tests to include "shrink-to-fit=no", to prevent the new heuristics from shrinking the page to fit on device classes that use native viewports by default. * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-expected.txt: Canonical link: https://commits.webkit.org/211651@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-01 21:08:38 +00:00
if (m_canIgnoreScalingConstraints)
return true;
if (m_viewportArguments == ViewportArguments())
return false;
if ((m_viewportArguments.zoom == 1. || m_viewportArguments.width == ViewportArguments::ValueDeviceWidth) && !m_isKnownToLayOutWiderThanViewport)
return true;
return false;
}
[iPadOS] Wikipedia articles lay out incorrectly in 1/3 multitasking window https://bugs.webkit.org/show_bug.cgi?id=210501 <rdar://problem/54856323> Reviewed by Tim Horton. Source/WebCore: In a 1/3 multitasking window, Safari currently uses the `-[WKWebView _allowsViewportShrinkToFit]` SPI to force pages to shrink down by fitting the content width to the view width. This legacy method of shrinking to fit involves laying the page out at the normal view width (320px in 1/3 multitasking), and then scaling the page down such that any amount of horizontal overflow fits within the view. In iOS 13, a new style of shrinking to fit was introduced in support of two new features: page zoom controls (accessible via the page formatting menu), and on-by-default page scaling when loading desktop sites on certain models of iPad where the page width is less than cutoffs of 1112px (in landscape) and 1024px (in portrait). This new method of shrinking to fit involves laying out at a larger width (computed from a combination of the minimum effective device width and layout size scale factor), and scaling to fit the effective layout size scale factor instead of the entire contents of the page. This means that while we may still get horizontal scrolling after shrinking to fit, the overall layout of the page is preserved. Currently, in 1/3 multitasking, Safari still relies on the former to scale pages down to fit, which means that Wikipedia articles (among other websites) do not lay out sensibly. Moreover, even if Safari adopted the second mechanism for shrinking to fit, layout issues would still exist (albeit to a lesser degree), since we'd still attempt to shrink the content width down to fit due to the fact that the desktop version of Wikipedia doesn't have a meta viewport. While we wouldn't get a broken layout, we'd still have a blank column running down the right side of the page, which is less than ideal. It's clear that in this case, attempting to shrink page content down to fit the view is suboptimal (at best, it leads to a large portion of the page being blank; at worst, it completely breaks page layout). To address this bug for now, add a parallel minimumEffectiveDeviceWidth value that takes effect when ignoring scaling constraints (i.e. when we're in a multitasking window), and scale the page down to fit this value instead of fitting the full content width when computing initial scale in `ViewportConfiguration::initialScaleFromSize`. Maintaining this value separately from m_minimumEffectiveDeviceWidth makes it much easier to ensure that the effects of this change are only ever active when the quirk is applied, and also when the view is embedded in a multitasking window. * page/Quirks.cpp: (WebCore::Quirks::shouldLayOutAtMinimumWindowWidthWhenIgnoringScalingConstraints const): Introduce a quirk to fix layout issues in multitasking mode on the desktop version of Wikipedia. * page/Quirks.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints): * page/ViewportConfiguration.h: Add a minimum effective device width value that only takes effect when ignoring scaling constraints, and update `shouldIgnoreMinimumEffectiveDeviceWidth()` and `minimumEffectiveDeviceWidth()` to not always return `true` and `0` (respectively) when ignoring scaling constraints, if m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints is set. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldShrinkToFitMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints const): Source/WebKit: Apply the viewport quirk if needed; see WebCore/ChangeLog for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateVisibleContentRects): Canonical link: https://commits.webkit.org/223384@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260090 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-14 19:15:45 +00:00
constexpr bool shouldShrinkToFitMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints() const
{
return m_canIgnoreScalingConstraints && m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints;
}
[iOS] Add a version of viewport shrink-to-fit heuristics that preserves page layout https://bugs.webkit.org/show_bug.cgi?id=197342 <rdar://problem/50063091> Reviewed by Tim Horton. Source/WebCore: Adds support for a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. See WebKit ChangeLog for more details. Tests: fast/viewport/ios/shrink-to-fit-content-constant-width.html fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html fast/viewport/ios/shrink-to-fit-content-no-viewport.html fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setIsKnownToLayOutWiderThanViewport): (WebCore::ViewportConfiguration::description const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::canIgnoreScalingConstraints const): (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add several new getters and setters in ViewportConfiguration. (WebCore::ViewportConfiguration::isKnownToLayOutWiderThanViewport const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): Importantly, only allow ignoring the minimum effective device width in webpages with responsive viewports, if they also have *not* laid out wider than the viewport. (WebCore::ViewportConfiguration::setForceAlwaysUserScalable): Source/WebKit: This patch introduces a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. This is similar to existing shrink-to-fit behaviors used for viewport sizing in multitasking mode, except that it not only scales the view, but additionally expands the layout size, such that the overall layout of the page is preserved. In fact, the reason we ended up reverting the existing flavor of shrink-to-fit in all cases except for multitasking was that page layout was not preserved, which caused elements that poke out of the viewport to make the rest of the page look out of proportion — see <rdar://problem/23818102> and related radars. Covered by 5 new layout tests, and by adjusting a couple of existing layout tests. See comments below for more details. * Platform/Logging.h: Add a new ViewportSizing logging channel. This will only log on pages that overflow the viewport and shrink to fit as a result. * Shared/WebPreferences.yaml: Turn IgnoreViewportScalingConstraints off by default. This preference currently controls whether we allow shrink-to-fit behaviors, and is only used by Safari when it is in multitasking mode. The value of this preference is currenly *on* by default, and is turned off almost immediately during every page load after the first visible content rect update, wherein visibleContentRectUpdateInfo.allowShrinkToFit() is false. However, this sometimes causes a brief jitter during page load; to fix this, make the default value for IgnoreViewportScalingConstraints false, and change the logic in WebPage::updateVisibleContentRects to setCanIgnoreScalingConstraints to true if either the IgnoreViewportScalingConstraints preference (not only affected by an internal debug switch) is true, or WKWebView SPI is used to enable the behavior. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): (WebKit::WebFrameLoaderClient::dispatchDidFinishLoad): Add a new hook for WebFrameLoaderClient to call into WebPage when document load finishes. Also, tweak dispatchDidFinishLoad to take a WebFrame& instead of a WebFrame* in a drive-by fix (the frame is assumed to be non-null anyways). * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::didFinishDocumentLoad): (WebKit::WebPage::didFinishLoad): When finishing document load or finishing the overall load, kick off the shrink-to-fit timer; when committing a load, cancel the timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Don't allow the minimum effective device width from the client to stomp over any minimum effective device width set as a result of the new shrink-to-fit heuristic; on some pages that load quickly, this can result in a race where the minimum effective device width (i.e. a value that lower-bounds the minimum layout width) is first set by the shrink-to-fit heuristic, and then set to an incorrect value by the client. In the near future, web view SPI used to set the minimum effective device width should actually be removed altogether, since the new shrink-to-fit heuristic supersedes any need for the client to fiddle with the minimum effective device width. (WebKit::WebPage::dynamicViewportSizeUpdate): When performing a dynamic viewport size update, additionally re-run the shrink-to-fit heuristic. This allows the minimum layout size of the viewport to be updated, if necessary. An example of where this matters is when a web page is *below* a tablet/desktop layout breakpoint in portrait device orientation, but then exceeds this layout breakpoint in landscape orientation. In this scenario, rotating the device should swap between these two page layouts. (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::scheduleShrinkToFitContent): (WebKit::WebPage::shrinkToFitContentTimerFired): (WebKit::WebPage::immediatelyShrinkToFitContent): Leverage the existing capability for a viewport to have a "minimum effective device width" to grant the viewport a larger layout size than it would normally have, and then scale down to fit within the bounds of the view. One challenge with this overall approach is that laying out at a larger width may cause the page to lay out even wider in response, which may actually worsen horizontal scrolling. To mitigate this, we only attempt to lay out at the current content width once; if laying out at this width reduced the amount of horizontal scrolling by any amount, then proceed with this layout width; otherwise, revert to the previous layout width. (WebKit::WebPage::shouldIgnoreMetaViewport const): Pull some common logic out into a readonly getter. (WebKit::WebPage::updateVisibleContentRects): See the comment below WebPreferences.yaml, above. LayoutTests: Introduces new layout tests, and adjusts some existing tests. See comments below. * fast/viewport/ios/shrink-to-fit-content-constant-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-constant-width.html: Added. Add a new layout test to exercise the scenario where a constant width viewport narrower than the view is used. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html: Added. Add a new layout test to exercise the scenario where a responsive website that lays out larger than the view width ends up with even more horizontal scrolling when laying out at the initial content width. In this scenario, we shouldn't try to expand the viewport to try and encompass the content width, since that would only induce even worse horizontal scrolling. * fast/viewport/ios/shrink-to-fit-content-no-viewport-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-no-viewport.html: Added. Add a new layout test for the case where there is no viewport, but content lays out wider than the view. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html: Added. Add a new layout test for the case where the page has opted for a responsive viewport (device-width, initial scale 1), but has laid out wider than the viewport anyways. In this case, we want to shrink the contents down to fit inside the view. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html: Added. Add a new layout test to exercise the case where, during page load, content width temporarily increases, and then decreases such that it once again fits within the viewport. In this case, we don't want to expand the viewport to be as wide as the large temporary width of the page. * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden.html: * fast/viewport/ios/width-is-device-width-overflowing-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing.html: Tweak these 2 existing layout tests to include "shrink-to-fit=no", to prevent the new heuristics from shrinking the page to fit on device classes that use native viewports by default. * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-expected.txt: Canonical link: https://commits.webkit.org/211651@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-01 21:08:38 +00:00
void setForceAlwaysUserScalable(bool forceAlwaysUserScalable) { m_forceAlwaysUserScalable = forceAlwaysUserScalable; }
Changing view scale should zoom to initial scale if the page is already at initial scale https://bugs.webkit.org/show_bug.cgi?id=190570 <rdar://problem/45261877> Reviewed by Tim Horton. Source/WebCore: Add a getter for ViewportConfiguration's layout size scale factor. See Source/WebKit/ChangeLog for more details. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::layoutSizeScaleFactor const): Source/WebKit: r237087 added support for changing the view scale on iOS, by making it possible to let the minimum layout size be a factor of the view size; this allows internal clients to change page zoom levels on iOS. Currently, changing the page zoom level automatically zooms to the new initial scale only if the user has not manually scaled the page before, even if the page is already at initial scale (e.g. after the user double taps to zoom on a small element, and double taps again to zoom back out to initial scale). This patch makes some minor adjustments to automatically zoom to the new initial scale after changing the view scale, as long as the page was at initial scale when changing zoom levels. Test: fast/viewport/ios/initial-scale-after-changing-view-scale.html * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::areEssentiallyEqualAsFloat): Move this function further up in the file, so that we can use it in `setViewportConfigurationViewLayoutSize`. (WebKit::WebPage::setViewportConfigurationViewLayoutSize): If the page is near initial scale and the zoom level changes, zoom to the new initial scale. (WebKit::WebPage::viewportConfigurationChanged): Make this take a new enum argument that determines whether we want to zoom to initial scale as a result of the viewport configuration change (`No` by default). LayoutTests: * fast/viewport/ios/initial-scale-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/initial-scale-after-changing-view-scale.html: Added. Add a new layout test to verify that: 1. Changing view scale before the page scale factor is changed by the user zooms to the new initial scale. 2. Changing view scale after the user changes the page scale to something different than initial scale does not cause the page to zoom to the new initial scale. 3. Changing view scale after the user changes the page scale factor back to initial scale causes the page to zoom to the new initial scale. * resources/basic-gestures.js: Make a small tweak in `doubleTapToZoomAtPoint` to ensure that both single taps as well as zooming are complete before invoking UIScriptController completion. (return.new.Promise): Canonical link: https://commits.webkit.org/205501@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237127 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-10-15 17:36:31 +00:00
double layoutSizeScaleFactor() const { return m_layoutSizeScaleFactor; }
More WEBCORE_EXPORT macros! https://bugs.webkit.org/show_bug.cgi?id=136146 Reviewed by Benjamin Poulain. * Modules/geolocation/GeolocationClient.h: * Modules/mediastream/UserMediaClient.h: * Modules/mediastream/UserMediaRequest.h: * Modules/notifications/NotificationClient.h: * Modules/speech/SpeechSynthesis.h: * bindings/generic/RuntimeEnabledFeatures.h: * bindings/js/DOMWrapperWorld.h: * bindings/js/GCController.h: * bindings/js/IDBBindingUtilities.h: * bindings/js/JSDOMBinding.h: * bindings/js/JSNodeCustom.h: * bindings/js/JSNodeListCustom.h: * bindings/js/JSPluginElementFunctions.h: * bindings/js/ScriptController.h: * bindings/js/SerializedScriptValue.h: * crypto/SerializedCryptoKeyWrap.h: * css/LengthFunctions.h: * css/StyleProperties.h: * css/StyleSheetContents.h: * dom/DeviceOrientationClient.h: * dom/Range.h: * dom/ScriptExecutionContext.h: * dom/StyledElement.h: * dom/TreeScope.h: * dom/UIEventWithKeyState.h: * dom/UserGestureIndicator.h: * dom/UserTypingGestureIndicator.h: * dom/ViewportArguments.h: * editing/SmartReplace.h: * editing/TextIterator.h: * editing/VisiblePosition.h: * editing/VisibleSelection.h: * editing/VisibleUnits.h: * editing/cocoa/HTMLConverter.h: * editing/htmlediting.h: * editing/mac/TextAlternativeWithRange.h: * editing/mac/TextUndoInsertionMarkupMac.h: * editing/markup.h: * history/HistoryItem.cpp: * history/PageCache.h: * html/TimeRanges.h: * html/parser/HTMLParserIdioms.h: * inspector/InstrumentingAgents.h: * loader/FrameLoader.h: * loader/ResourceBuffer.h: * loader/ResourceLoadScheduler.h: * loader/ResourceLoader.h: (WebCore::ResourceLoader::originalRequest): * loader/SubframeLoader.h: * loader/SubresourceLoader.h: * loader/TextResourceDecoder.h: * loader/appcache/ApplicationCacheStorage.h: * loader/cache/MemoryCache.h: * loader/icon/IconDatabaseBase.h: * loader/ios/DiskImageCacheIOS.h: * page/Chrome.h: * page/SecurityOrigin.h: * page/SecurityPolicy.h: * page/Settings.h: * page/UserContentController.h: * page/UserContentURLPattern.h: * page/UserMessageHandlerDescriptor.h: * page/ViewportConfiguration.h: * page/VisitedLinkStore.h: * page/WheelEventDeltaTracker.h: * page/cocoa/UserAgent.h: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingStateTree.h: * page/scrolling/ScrollingThread.h: * page/scrolling/ScrollingTree.h: * page/scrolling/ScrollingTreeOverflowScrollingNode.h: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/ios/ScrollingTreeFrameScrollingNodeIOS.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeStickyNode.h: * platform/Cursor.h: * platform/DragImage.h: * platform/FileSystem.h: * platform/Language.h: * platform/LinkHash.h: * platform/LocalizedStrings.h: * platform/Logging.h: * platform/MemoryPressureHandler.h: * platform/NotImplemented.h: * platform/PlatformStrategies.h: * platform/PublicSuffix.h: * platform/RuntimeApplicationChecks.h: * platform/RuntimeApplicationChecksIOS.h: * platform/SchemeRegistry.h: * platform/ScrollView.h: * platform/ScrollableArea.h: * platform/Scrollbar.h: * platform/ScrollbarTheme.h: * platform/SharedBuffer.h: * platform/ThreadCheck.h: * platform/ThreadGlobalData.h: * platform/Timer.h: * platform/URL.h: * platform/UUID.h: * platform/UserActivity.h: * platform/Widget.h: * platform/cf/CFURLExtras.h: * platform/cf/RunLoopObserver.h: * platform/cocoa/SystemVersion.h: * platform/graphics/Color.h: * platform/graphics/FloatRect.h: * platform/graphics/FontCache.h: * platform/graphics/GeometryUtilities.h: * platform/graphics/GraphicsContext.h: * platform/graphics/IntRect.h: * platform/graphics/LayoutRect.h: * platform/graphics/StringTruncator.h: * platform/graphics/TextRun.h: * platform/graphics/ca/TileController.h: * platform/graphics/ca/mac/PlatformCAAnimationMac.h: * platform/graphics/cg/GraphicsContextCG.h: * platform/graphics/mac/ColorMac.h: * platform/graphics/transforms/TransformationMatrix.h: * platform/ios/FileSystemIOS.h: * platform/ios/PlatformEventFactoryIOS.h: * platform/ios/SelectionRect.h: * platform/ios/SystemMemory.h: * platform/ios/TileControllerMemoryHandlerIOS.h: * platform/ios/WebVideoFullscreenInterfaceAVKit.h: * platform/mac/PlatformEventFactoryMac.h: * platform/mac/ScrollbarThemeMac.h: * platform/mac/WebCoreNSURLExtras.h: * platform/mac/WebNSAttributedStringExtras.h: * platform/network/BlobRegistry.h: * platform/network/CookieStorage.h: * platform/network/DNS.h: * platform/network/NetworkStateNotifier.h: * platform/network/PlatformCookieJar.h: * platform/network/ProxyServer.h: * platform/network/ResourceErrorBase.h: * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.h: * platform/network/ResourceRequestBase.h: * platform/network/ResourceResponseBase.h: * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceError.h: * platform/network/cf/ResourceRequest.h: * platform/network/cf/ResourceResponse.h: * platform/network/ios/QuickLook.h: * platform/network/mac/AuthenticationMac.h: * platform/sql/SQLiteDatabase.cpp: * platform/text/LocaleToScriptMapping.h: * platform/text/TextBreakIterator.h: * platform/text/TextEncoding.h: (WebCore::TextEncoding::decode): * platform/text/TextEncodingRegistry.h: * platform/text/TextStream.h: * rendering/RenderBlock.h: * rendering/RenderBox.h: * rendering/RenderEmbeddedObject.h: * rendering/RenderLayer.h: * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.h: * rendering/RenderListItem.h: * rendering/RenderObject.h: * rendering/RenderText.h: * rendering/RenderTextControl.h: * rendering/RenderThemeIOS.h: * rendering/RenderTreeAsText.h: * rendering/RenderView.h: * rendering/RenderWidget.h: * rendering/ScrollBehavior.cpp: * rendering/break_lines.cpp: * rendering/style/RenderStyle.h: * replay/UserInputBridge.h: * storage/StorageEventDispatcher.h: * storage/StorageMap.h: * storage/StorageStrategy.h: * storage/StorageTracker.h: * testing/Internals.h: * workers/WorkerThread.h: Added more WEBCORE_EXPORT macros where needed. Canonical link: https://commits.webkit.org/153984@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@172849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-08-22 04:21:18 +00:00
WEBCORE_EXPORT IntSize layoutSize() const;
[iOS] Add a version of viewport shrink-to-fit heuristics that preserves page layout https://bugs.webkit.org/show_bug.cgi?id=197342 <rdar://problem/50063091> Reviewed by Tim Horton. Source/WebCore: Adds support for a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. See WebKit ChangeLog for more details. Tests: fast/viewport/ios/shrink-to-fit-content-constant-width.html fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html fast/viewport/ios/shrink-to-fit-content-no-viewport.html fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setIsKnownToLayOutWiderThanViewport): (WebCore::ViewportConfiguration::description const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::canIgnoreScalingConstraints const): (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add several new getters and setters in ViewportConfiguration. (WebCore::ViewportConfiguration::isKnownToLayOutWiderThanViewport const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): Importantly, only allow ignoring the minimum effective device width in webpages with responsive viewports, if they also have *not* laid out wider than the viewport. (WebCore::ViewportConfiguration::setForceAlwaysUserScalable): Source/WebKit: This patch introduces a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. This is similar to existing shrink-to-fit behaviors used for viewport sizing in multitasking mode, except that it not only scales the view, but additionally expands the layout size, such that the overall layout of the page is preserved. In fact, the reason we ended up reverting the existing flavor of shrink-to-fit in all cases except for multitasking was that page layout was not preserved, which caused elements that poke out of the viewport to make the rest of the page look out of proportion — see <rdar://problem/23818102> and related radars. Covered by 5 new layout tests, and by adjusting a couple of existing layout tests. See comments below for more details. * Platform/Logging.h: Add a new ViewportSizing logging channel. This will only log on pages that overflow the viewport and shrink to fit as a result. * Shared/WebPreferences.yaml: Turn IgnoreViewportScalingConstraints off by default. This preference currently controls whether we allow shrink-to-fit behaviors, and is only used by Safari when it is in multitasking mode. The value of this preference is currenly *on* by default, and is turned off almost immediately during every page load after the first visible content rect update, wherein visibleContentRectUpdateInfo.allowShrinkToFit() is false. However, this sometimes causes a brief jitter during page load; to fix this, make the default value for IgnoreViewportScalingConstraints false, and change the logic in WebPage::updateVisibleContentRects to setCanIgnoreScalingConstraints to true if either the IgnoreViewportScalingConstraints preference (not only affected by an internal debug switch) is true, or WKWebView SPI is used to enable the behavior. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): (WebKit::WebFrameLoaderClient::dispatchDidFinishLoad): Add a new hook for WebFrameLoaderClient to call into WebPage when document load finishes. Also, tweak dispatchDidFinishLoad to take a WebFrame& instead of a WebFrame* in a drive-by fix (the frame is assumed to be non-null anyways). * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::didFinishDocumentLoad): (WebKit::WebPage::didFinishLoad): When finishing document load or finishing the overall load, kick off the shrink-to-fit timer; when committing a load, cancel the timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Don't allow the minimum effective device width from the client to stomp over any minimum effective device width set as a result of the new shrink-to-fit heuristic; on some pages that load quickly, this can result in a race where the minimum effective device width (i.e. a value that lower-bounds the minimum layout width) is first set by the shrink-to-fit heuristic, and then set to an incorrect value by the client. In the near future, web view SPI used to set the minimum effective device width should actually be removed altogether, since the new shrink-to-fit heuristic supersedes any need for the client to fiddle with the minimum effective device width. (WebKit::WebPage::dynamicViewportSizeUpdate): When performing a dynamic viewport size update, additionally re-run the shrink-to-fit heuristic. This allows the minimum layout size of the viewport to be updated, if necessary. An example of where this matters is when a web page is *below* a tablet/desktop layout breakpoint in portrait device orientation, but then exceeds this layout breakpoint in landscape orientation. In this scenario, rotating the device should swap between these two page layouts. (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::scheduleShrinkToFitContent): (WebKit::WebPage::shrinkToFitContentTimerFired): (WebKit::WebPage::immediatelyShrinkToFitContent): Leverage the existing capability for a viewport to have a "minimum effective device width" to grant the viewport a larger layout size than it would normally have, and then scale down to fit within the bounds of the view. One challenge with this overall approach is that laying out at a larger width may cause the page to lay out even wider in response, which may actually worsen horizontal scrolling. To mitigate this, we only attempt to lay out at the current content width once; if laying out at this width reduced the amount of horizontal scrolling by any amount, then proceed with this layout width; otherwise, revert to the previous layout width. (WebKit::WebPage::shouldIgnoreMetaViewport const): Pull some common logic out into a readonly getter. (WebKit::WebPage::updateVisibleContentRects): See the comment below WebPreferences.yaml, above. LayoutTests: Introduces new layout tests, and adjusts some existing tests. See comments below. * fast/viewport/ios/shrink-to-fit-content-constant-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-constant-width.html: Added. Add a new layout test to exercise the scenario where a constant width viewport narrower than the view is used. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html: Added. Add a new layout test to exercise the scenario where a responsive website that lays out larger than the view width ends up with even more horizontal scrolling when laying out at the initial content width. In this scenario, we shouldn't try to expand the viewport to try and encompass the content width, since that would only induce even worse horizontal scrolling. * fast/viewport/ios/shrink-to-fit-content-no-viewport-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-no-viewport.html: Added. Add a new layout test for the case where there is no viewport, but content lays out wider than the view. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html: Added. Add a new layout test for the case where the page has opted for a responsive viewport (device-width, initial scale 1), but has laid out wider than the viewport anyways. In this case, we want to shrink the contents down to fit inside the view. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html: Added. Add a new layout test to exercise the case where, during page load, content width temporarily increases, and then decreases such that it once again fits within the viewport. In this case, we don't want to expand the viewport to be as wide as the large temporary width of the page. * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden.html: * fast/viewport/ios/width-is-device-width-overflowing-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing.html: Tweak these 2 existing layout tests to include "shrink-to-fit=no", to prevent the new heuristics from shrinking the page to fit on device classes that use native viewports by default. * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-expected.txt: Canonical link: https://commits.webkit.org/211651@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-01 21:08:38 +00:00
WEBCORE_EXPORT int layoutWidth() const;
WEBCORE_EXPORT int layoutHeight() const;
More WEBCORE_EXPORT macros! https://bugs.webkit.org/show_bug.cgi?id=136146 Reviewed by Benjamin Poulain. * Modules/geolocation/GeolocationClient.h: * Modules/mediastream/UserMediaClient.h: * Modules/mediastream/UserMediaRequest.h: * Modules/notifications/NotificationClient.h: * Modules/speech/SpeechSynthesis.h: * bindings/generic/RuntimeEnabledFeatures.h: * bindings/js/DOMWrapperWorld.h: * bindings/js/GCController.h: * bindings/js/IDBBindingUtilities.h: * bindings/js/JSDOMBinding.h: * bindings/js/JSNodeCustom.h: * bindings/js/JSNodeListCustom.h: * bindings/js/JSPluginElementFunctions.h: * bindings/js/ScriptController.h: * bindings/js/SerializedScriptValue.h: * crypto/SerializedCryptoKeyWrap.h: * css/LengthFunctions.h: * css/StyleProperties.h: * css/StyleSheetContents.h: * dom/DeviceOrientationClient.h: * dom/Range.h: * dom/ScriptExecutionContext.h: * dom/StyledElement.h: * dom/TreeScope.h: * dom/UIEventWithKeyState.h: * dom/UserGestureIndicator.h: * dom/UserTypingGestureIndicator.h: * dom/ViewportArguments.h: * editing/SmartReplace.h: * editing/TextIterator.h: * editing/VisiblePosition.h: * editing/VisibleSelection.h: * editing/VisibleUnits.h: * editing/cocoa/HTMLConverter.h: * editing/htmlediting.h: * editing/mac/TextAlternativeWithRange.h: * editing/mac/TextUndoInsertionMarkupMac.h: * editing/markup.h: * history/HistoryItem.cpp: * history/PageCache.h: * html/TimeRanges.h: * html/parser/HTMLParserIdioms.h: * inspector/InstrumentingAgents.h: * loader/FrameLoader.h: * loader/ResourceBuffer.h: * loader/ResourceLoadScheduler.h: * loader/ResourceLoader.h: (WebCore::ResourceLoader::originalRequest): * loader/SubframeLoader.h: * loader/SubresourceLoader.h: * loader/TextResourceDecoder.h: * loader/appcache/ApplicationCacheStorage.h: * loader/cache/MemoryCache.h: * loader/icon/IconDatabaseBase.h: * loader/ios/DiskImageCacheIOS.h: * page/Chrome.h: * page/SecurityOrigin.h: * page/SecurityPolicy.h: * page/Settings.h: * page/UserContentController.h: * page/UserContentURLPattern.h: * page/UserMessageHandlerDescriptor.h: * page/ViewportConfiguration.h: * page/VisitedLinkStore.h: * page/WheelEventDeltaTracker.h: * page/cocoa/UserAgent.h: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingStateTree.h: * page/scrolling/ScrollingThread.h: * page/scrolling/ScrollingTree.h: * page/scrolling/ScrollingTreeOverflowScrollingNode.h: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/ios/ScrollingTreeFrameScrollingNodeIOS.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeStickyNode.h: * platform/Cursor.h: * platform/DragImage.h: * platform/FileSystem.h: * platform/Language.h: * platform/LinkHash.h: * platform/LocalizedStrings.h: * platform/Logging.h: * platform/MemoryPressureHandler.h: * platform/NotImplemented.h: * platform/PlatformStrategies.h: * platform/PublicSuffix.h: * platform/RuntimeApplicationChecks.h: * platform/RuntimeApplicationChecksIOS.h: * platform/SchemeRegistry.h: * platform/ScrollView.h: * platform/ScrollableArea.h: * platform/Scrollbar.h: * platform/ScrollbarTheme.h: * platform/SharedBuffer.h: * platform/ThreadCheck.h: * platform/ThreadGlobalData.h: * platform/Timer.h: * platform/URL.h: * platform/UUID.h: * platform/UserActivity.h: * platform/Widget.h: * platform/cf/CFURLExtras.h: * platform/cf/RunLoopObserver.h: * platform/cocoa/SystemVersion.h: * platform/graphics/Color.h: * platform/graphics/FloatRect.h: * platform/graphics/FontCache.h: * platform/graphics/GeometryUtilities.h: * platform/graphics/GraphicsContext.h: * platform/graphics/IntRect.h: * platform/graphics/LayoutRect.h: * platform/graphics/StringTruncator.h: * platform/graphics/TextRun.h: * platform/graphics/ca/TileController.h: * platform/graphics/ca/mac/PlatformCAAnimationMac.h: * platform/graphics/cg/GraphicsContextCG.h: * platform/graphics/mac/ColorMac.h: * platform/graphics/transforms/TransformationMatrix.h: * platform/ios/FileSystemIOS.h: * platform/ios/PlatformEventFactoryIOS.h: * platform/ios/SelectionRect.h: * platform/ios/SystemMemory.h: * platform/ios/TileControllerMemoryHandlerIOS.h: * platform/ios/WebVideoFullscreenInterfaceAVKit.h: * platform/mac/PlatformEventFactoryMac.h: * platform/mac/ScrollbarThemeMac.h: * platform/mac/WebCoreNSURLExtras.h: * platform/mac/WebNSAttributedStringExtras.h: * platform/network/BlobRegistry.h: * platform/network/CookieStorage.h: * platform/network/DNS.h: * platform/network/NetworkStateNotifier.h: * platform/network/PlatformCookieJar.h: * platform/network/ProxyServer.h: * platform/network/ResourceErrorBase.h: * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.h: * platform/network/ResourceRequestBase.h: * platform/network/ResourceResponseBase.h: * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceError.h: * platform/network/cf/ResourceRequest.h: * platform/network/cf/ResourceResponse.h: * platform/network/ios/QuickLook.h: * platform/network/mac/AuthenticationMac.h: * platform/sql/SQLiteDatabase.cpp: * platform/text/LocaleToScriptMapping.h: * platform/text/TextBreakIterator.h: * platform/text/TextEncoding.h: (WebCore::TextEncoding::decode): * platform/text/TextEncodingRegistry.h: * platform/text/TextStream.h: * rendering/RenderBlock.h: * rendering/RenderBox.h: * rendering/RenderEmbeddedObject.h: * rendering/RenderLayer.h: * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.h: * rendering/RenderListItem.h: * rendering/RenderObject.h: * rendering/RenderText.h: * rendering/RenderTextControl.h: * rendering/RenderThemeIOS.h: * rendering/RenderTreeAsText.h: * rendering/RenderView.h: * rendering/RenderWidget.h: * rendering/ScrollBehavior.cpp: * rendering/break_lines.cpp: * rendering/style/RenderStyle.h: * replay/UserInputBridge.h: * storage/StorageEventDispatcher.h: * storage/StorageMap.h: * storage/StorageStrategy.h: * storage/StorageTracker.h: * testing/Internals.h: * workers/WorkerThread.h: Added more WEBCORE_EXPORT macros where needed. Canonical link: https://commits.webkit.org/153984@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@172849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-08-22 04:21:18 +00:00
WEBCORE_EXPORT double initialScale() const;
WEBCORE_EXPORT double initialScaleIgnoringContentSize() const;
More WEBCORE_EXPORT macros! https://bugs.webkit.org/show_bug.cgi?id=136146 Reviewed by Benjamin Poulain. * Modules/geolocation/GeolocationClient.h: * Modules/mediastream/UserMediaClient.h: * Modules/mediastream/UserMediaRequest.h: * Modules/notifications/NotificationClient.h: * Modules/speech/SpeechSynthesis.h: * bindings/generic/RuntimeEnabledFeatures.h: * bindings/js/DOMWrapperWorld.h: * bindings/js/GCController.h: * bindings/js/IDBBindingUtilities.h: * bindings/js/JSDOMBinding.h: * bindings/js/JSNodeCustom.h: * bindings/js/JSNodeListCustom.h: * bindings/js/JSPluginElementFunctions.h: * bindings/js/ScriptController.h: * bindings/js/SerializedScriptValue.h: * crypto/SerializedCryptoKeyWrap.h: * css/LengthFunctions.h: * css/StyleProperties.h: * css/StyleSheetContents.h: * dom/DeviceOrientationClient.h: * dom/Range.h: * dom/ScriptExecutionContext.h: * dom/StyledElement.h: * dom/TreeScope.h: * dom/UIEventWithKeyState.h: * dom/UserGestureIndicator.h: * dom/UserTypingGestureIndicator.h: * dom/ViewportArguments.h: * editing/SmartReplace.h: * editing/TextIterator.h: * editing/VisiblePosition.h: * editing/VisibleSelection.h: * editing/VisibleUnits.h: * editing/cocoa/HTMLConverter.h: * editing/htmlediting.h: * editing/mac/TextAlternativeWithRange.h: * editing/mac/TextUndoInsertionMarkupMac.h: * editing/markup.h: * history/HistoryItem.cpp: * history/PageCache.h: * html/TimeRanges.h: * html/parser/HTMLParserIdioms.h: * inspector/InstrumentingAgents.h: * loader/FrameLoader.h: * loader/ResourceBuffer.h: * loader/ResourceLoadScheduler.h: * loader/ResourceLoader.h: (WebCore::ResourceLoader::originalRequest): * loader/SubframeLoader.h: * loader/SubresourceLoader.h: * loader/TextResourceDecoder.h: * loader/appcache/ApplicationCacheStorage.h: * loader/cache/MemoryCache.h: * loader/icon/IconDatabaseBase.h: * loader/ios/DiskImageCacheIOS.h: * page/Chrome.h: * page/SecurityOrigin.h: * page/SecurityPolicy.h: * page/Settings.h: * page/UserContentController.h: * page/UserContentURLPattern.h: * page/UserMessageHandlerDescriptor.h: * page/ViewportConfiguration.h: * page/VisitedLinkStore.h: * page/WheelEventDeltaTracker.h: * page/cocoa/UserAgent.h: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingStateTree.h: * page/scrolling/ScrollingThread.h: * page/scrolling/ScrollingTree.h: * page/scrolling/ScrollingTreeOverflowScrollingNode.h: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/ios/ScrollingTreeFrameScrollingNodeIOS.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeStickyNode.h: * platform/Cursor.h: * platform/DragImage.h: * platform/FileSystem.h: * platform/Language.h: * platform/LinkHash.h: * platform/LocalizedStrings.h: * platform/Logging.h: * platform/MemoryPressureHandler.h: * platform/NotImplemented.h: * platform/PlatformStrategies.h: * platform/PublicSuffix.h: * platform/RuntimeApplicationChecks.h: * platform/RuntimeApplicationChecksIOS.h: * platform/SchemeRegistry.h: * platform/ScrollView.h: * platform/ScrollableArea.h: * platform/Scrollbar.h: * platform/ScrollbarTheme.h: * platform/SharedBuffer.h: * platform/ThreadCheck.h: * platform/ThreadGlobalData.h: * platform/Timer.h: * platform/URL.h: * platform/UUID.h: * platform/UserActivity.h: * platform/Widget.h: * platform/cf/CFURLExtras.h: * platform/cf/RunLoopObserver.h: * platform/cocoa/SystemVersion.h: * platform/graphics/Color.h: * platform/graphics/FloatRect.h: * platform/graphics/FontCache.h: * platform/graphics/GeometryUtilities.h: * platform/graphics/GraphicsContext.h: * platform/graphics/IntRect.h: * platform/graphics/LayoutRect.h: * platform/graphics/StringTruncator.h: * platform/graphics/TextRun.h: * platform/graphics/ca/TileController.h: * platform/graphics/ca/mac/PlatformCAAnimationMac.h: * platform/graphics/cg/GraphicsContextCG.h: * platform/graphics/mac/ColorMac.h: * platform/graphics/transforms/TransformationMatrix.h: * platform/ios/FileSystemIOS.h: * platform/ios/PlatformEventFactoryIOS.h: * platform/ios/SelectionRect.h: * platform/ios/SystemMemory.h: * platform/ios/TileControllerMemoryHandlerIOS.h: * platform/ios/WebVideoFullscreenInterfaceAVKit.h: * platform/mac/PlatformEventFactoryMac.h: * platform/mac/ScrollbarThemeMac.h: * platform/mac/WebCoreNSURLExtras.h: * platform/mac/WebNSAttributedStringExtras.h: * platform/network/BlobRegistry.h: * platform/network/CookieStorage.h: * platform/network/DNS.h: * platform/network/NetworkStateNotifier.h: * platform/network/PlatformCookieJar.h: * platform/network/ProxyServer.h: * platform/network/ResourceErrorBase.h: * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.h: * platform/network/ResourceRequestBase.h: * platform/network/ResourceResponseBase.h: * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceError.h: * platform/network/cf/ResourceRequest.h: * platform/network/cf/ResourceResponse.h: * platform/network/ios/QuickLook.h: * platform/network/mac/AuthenticationMac.h: * platform/sql/SQLiteDatabase.cpp: * platform/text/LocaleToScriptMapping.h: * platform/text/TextBreakIterator.h: * platform/text/TextEncoding.h: (WebCore::TextEncoding::decode): * platform/text/TextEncodingRegistry.h: * platform/text/TextStream.h: * rendering/RenderBlock.h: * rendering/RenderBox.h: * rendering/RenderEmbeddedObject.h: * rendering/RenderLayer.h: * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.h: * rendering/RenderListItem.h: * rendering/RenderObject.h: * rendering/RenderText.h: * rendering/RenderTextControl.h: * rendering/RenderThemeIOS.h: * rendering/RenderTreeAsText.h: * rendering/RenderView.h: * rendering/RenderWidget.h: * rendering/ScrollBehavior.cpp: * rendering/break_lines.cpp: * rendering/style/RenderStyle.h: * replay/UserInputBridge.h: * storage/StorageEventDispatcher.h: * storage/StorageMap.h: * storage/StorageStrategy.h: * storage/StorageTracker.h: * testing/Internals.h: * workers/WorkerThread.h: Added more WEBCORE_EXPORT macros where needed. Canonical link: https://commits.webkit.org/153984@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@172849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-08-22 04:21:18 +00:00
WEBCORE_EXPORT double minimumScale() const;
[iOS] Changing view scale sometimes does not zoom the page to the new initial scale when the page is zoomed in when ignoring meta viewport https://bugs.webkit.org/show_bug.cgi?id=191226 <rdar://problem/45781765> Reviewed by Tim Horton. Source/WebCore: When `_setViewScale:` SPI is used to adjust the layout scale factor of the page, we multiply minimum, initial and maximum scales by the given layout scale factor to adjust for a larger or smaller minimum layout size. However, in the case where the layout size scale factor is greater than 1 and we're also forcing the viewport to be scalable, we override the default minimum scale with 1 (i.e. `forceAlwaysUserScalableMinimumScale`). This means that the might be off by a small margin due to rounding error when computing the content width and view width (see: r237743). This means that in the case where (1) the viewport is forced to be user-scalable, and (2) we're ignoring meta viewport parameters, and (3) `_viewScale` exceeds 1, we may end up computing a slightly different minimum scale than the default minimum scale multiplied by the layout size scale factor; subsequently, the page scale factor will be slightly different from initial scale, such that we'll no longer zoom to the new initial scale when changing view scale. This patch adjusts `forceAlwaysUserScalableMinimumScale` and `forceAlwaysUserScalableMaximumScale` to take the current layout scale factor into account when computing min and max scales when the viewport is forced to be always scalable. Test: fast/viewport/ios/minimum-scale-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::minimumScale const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::maximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMaximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMinimumScale const): Turn these from constant values to const functions on ViewportConfiguration, which factor in the current viewport layout size scale factor. Tools: Add a missing check for `shouldIgnoreMetaViewport` when comparing TestOptions, to ensure that "ignore meta viewport" state doesn't unexpectedly persist after running a layout test that ignores meta viewport. * WebKitTestRunner/TestOptions.h: (WTR::TestOptions::hasSameInitializationOptions const): LayoutTests: Add a new layout test that sets the view scale to several values greater than or equal to 1 and verifies that the minimum scale and resulting scroll view scale are exactly the same as the view scale, when (1) the "ignores meta viewport" preference is enabled, and (2) the viewport is forced to be always scalable. * fast/viewport/ios/minimum-scale-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/minimum-scale-after-changing-view-scale.html: Added. Canonical link: https://commits.webkit.org/206072@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237818 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-05 19:12:38 +00:00
double maximumScale() const { return m_forceAlwaysUserScalable ? forceAlwaysUserScalableMaximumScale() : m_configuration.maximumScale; }
AX: iOS: Tapping <input> in Safari zooms in a bit when page has max scale = 1 https://bugs.webkit.org/show_bug.cgi?id=162471 Reviewed by Simon Fraser. Source/WebCore: If the author has defined a maximum scale, we should honor that when keyboard focus moves to a text field, instead of using the forceAlwaysUserScalableMaximumScale. Tests: fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale.html fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-user-scalable-no.html fast/forms/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::ViewportConfiguration::allowsUserScalingIgnoringAlwaysScalable): (WebCore::ViewportConfiguration::allowsUserScalingIgnoringForceAlwaysScaling): Deleted. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::maximumScaleIgnoringAlwaysScalable): (WebCore::ViewportConfiguration::maximumScale): Deleted. Source/WebKit2: * Shared/AssistedNodeInformation.cpp: (WebKit::AssistedNodeInformation::encode): (WebKit::AssistedNodeInformation::decode): * Shared/AssistedNodeInformation.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _displayFormNodeInputView]): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::maximumPageScaleFactorIgnoringAlwaysScalable): (WebKit::WebPage::getAssistedNodeInformation): LayoutTests: Moved focus input related tests to the right place. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale-expected.txt: Added. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale.html: Added. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-user-scalable-no-expected.txt: Added. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-user-scalable-no.html: Added. * fast/forms/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale-expected.txt: Added. * fast/forms/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale.html: Added. * fast/viewport/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale-expected.txt: Removed. * fast/viewport/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale.html: Removed. * fast/viewport/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale-expected.txt: Removed. * fast/viewport/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale.html: Removed. Canonical link: https://commits.webkit.org/180704@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@206626 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-09-30 00:38:18 +00:00
double maximumScaleIgnoringAlwaysScalable() const { return m_configuration.maximumScale; }
WEBCORE_EXPORT bool allowsUserScaling() const;
AX: iOS: Tapping <input> in Safari zooms in a bit when page has max scale = 1 https://bugs.webkit.org/show_bug.cgi?id=162471 Reviewed by Simon Fraser. Source/WebCore: If the author has defined a maximum scale, we should honor that when keyboard focus moves to a text field, instead of using the forceAlwaysUserScalableMaximumScale. Tests: fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale.html fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-user-scalable-no.html fast/forms/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::ViewportConfiguration::allowsUserScalingIgnoringAlwaysScalable): (WebCore::ViewportConfiguration::allowsUserScalingIgnoringForceAlwaysScaling): Deleted. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::maximumScaleIgnoringAlwaysScalable): (WebCore::ViewportConfiguration::maximumScale): Deleted. Source/WebKit2: * Shared/AssistedNodeInformation.cpp: (WebKit::AssistedNodeInformation::encode): (WebKit::AssistedNodeInformation::decode): * Shared/AssistedNodeInformation.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _displayFormNodeInputView]): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::maximumPageScaleFactorIgnoringAlwaysScalable): (WebKit::WebPage::getAssistedNodeInformation): LayoutTests: Moved focus input related tests to the right place. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale-expected.txt: Added. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale.html: Added. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-user-scalable-no-expected.txt: Added. * fast/forms/ios/user-scalable-does-not-scale-for-keyboard-focus-with-user-scalable-no.html: Added. * fast/forms/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale-expected.txt: Added. * fast/forms/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale.html: Added. * fast/viewport/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale-expected.txt: Removed. * fast/viewport/ios/user-scalable-does-not-scale-for-keyboard-focus-with-author-defined-scale.html: Removed. * fast/viewport/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale-expected.txt: Removed. * fast/viewport/ios/user-scalable-scales-for-keyboard-focus-with-no-author-defined-scale.html: Removed. Canonical link: https://commits.webkit.org/180704@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@206626 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-09-30 00:38:18 +00:00
WEBCORE_EXPORT bool allowsUserScalingIgnoringAlwaysScalable() const;
Expose viewport-fit instead of clip-to-safe-area https://bugs.webkit.org/show_bug.cgi?id=171503 <rdar://problem/31918249> Reviewed by Simon Fraser. Tests: fast/viewport/ios/viewport-fit-auto.html fast/viewport/ios/viewport-fit-contain.html fast/viewport/ios/viewport-fit-cover.html * dom/ConstantPropertyMap.cpp: (WebCore::ConstantPropertyMap::buildValues): (WebCore::ConstantPropertyMap::updateConstantsForUnobscuredSafeAreaInsets): (WebCore::ConstantPropertyMap::didChangeSafeAreaInsets): (WebCore::ConstantPropertyMap::updateConstantsForObscuredInsets): Deleted. (WebCore::ConstantPropertyMap::didChangeObscuredInsets): Deleted. * dom/ConstantPropertyMap.h: Retrieve the safe area insets from page, instead of assuming that we should just expose the entire obscured inset. Also, do some renames. * dom/ViewportArguments.cpp: (WebCore::ViewportArguments::resolve): (WebCore::parseViewportFitValue): (WebCore::setViewportFeature): * dom/ViewportArguments.h: (WebCore::ViewportArguments::operator==): * page/ChromeClient.h: * page/FrameView.cpp: (WebCore::FrameView::enableSpeculativeTilingIfNeeded): (WebCore::FrameView::calculateExtendedBackgroundMode): (WebCore::FrameView::setClipToSafeArea): Deleted. * page/FrameView.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::operator<<): (WebCore::ViewportConfiguration::description): (WebCore::ViewportConfiguration::dump): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::avoidsUnsafeArea): (WebCore::ViewportConfiguration::Parameters::Parameters): (WebCore::ViewportConfiguration::clipToSafeArea): Deleted. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateRootContentLayerClipping): * rendering/RenderObject.cpp: (WebCore::RenderObject::repaintUsingContainer): Un-do changes to support clip-to-safe-area, and instead implement a new viewport-fit argument in the viewport meta tag, which takes "auto", "contain", and "cover". "auto" and "contain" cause web content to lay out excluding the safe area inset from the layout size, while "cover" causes web content to expand into the unsafe area. * page/Page.cpp: (WebCore::Page::setUnobscuredSafeAreaInsets): (WebCore::Page::setObscuredInsets): Deleted. * page/Page.h: (WebCore::Page::setObscuredInsets): (WebCore::Page::unobscuredSafeAreaInsets): Keep safe area and obscured insets separately. * Shared/VisibleContentRectUpdateInfo.cpp: (WebKit::VisibleContentRectUpdateInfo::encode): (WebKit::VisibleContentRectUpdateInfo::decode): (WebKit::operator<<): * Shared/VisibleContentRectUpdateInfo.h: (WebKit::VisibleContentRectUpdateInfo::VisibleContentRectUpdateInfo): (WebKit::VisibleContentRectUpdateInfo::unobscuredSafeAreaInsets): (WebKit::operator==): Plumb the safe area insets down from the UI process to the Web Content process inside the visible content rect update, alongside the obscured insets. * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::avoidsUnsafeArea): (WebKit::RemoteLayerTreeTransaction::setAvoidsUnsafeArea): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): (WebKit::RemoteLayerTreeTransaction::description): * UIProcess/PageClient.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didChangeAvoidsUnsafeArea): (WebKit::PageClientImpl::didChangeClipToSafeArea): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didCommitLayerTree): * UIProcess/mac/PageClientImpl.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::didChangeClipToSafeArea): Deleted. * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::willCommitLayerTree): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportConfigurationChanged): (WebKit::WebPage::updateVisibleContentRects): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::setAvoidsUnsafeArea): (WebKit::WebPageProxy::setClipToSafeArea): Deleted. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::avoidsUnsafeArea): (WebKit::WebPageProxy::clipToSafeArea): Deleted. * UIProcess/WebPageProxy.messages.in: Plumb the effective value of viewport-fit (whether or not to avoid the safe area for layout purposes) from the Web Content process to the UI process inside the layer tree transaction. Also, remove clip-to-safe-area plumbing. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): (-[WKWebView _computedContentInset]): (-[WKWebView _computedUnobscuredSafeAreaInset]): (-[WKWebView _updateVisibleContentRects]): (-[WKWebView _updateScrollViewInsetAdjustmentBehavior]): (-[WKWebView _safeAreaShouldAffectObscuredInsets]): (-[WKWebView _unobscuredSafeAreaInsets]): (-[WKWebView _setUnobscuredSafeAreaInsets:]): (-[WKWebView _contentMayDrawInObscuredInsets]): Deleted. * UIProcess/API/Cocoa/WKWebViewInternal.h: * UIProcess/API/Cocoa/WKWebViewPrivate.h: Make use of the effective value of viewport-fit to decide whether to take the safe area into account when computing the obscured insets, and expose this to clients (in the case that they need to know because they push their own obscured insets down). Also expose a safe area inset setter for that case as well. * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView updateFixedClippingView:]): (-[WKContentView didUpdateVisibleRect:unobscuredRect:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): Remove a piece of the clip-to-safe-area implementation, and plumb safe area insets into the visible content rect update info. * UIProcess/ios/WKScrollView.h: * UIProcess/ios/WKScrollView.mm: (-[WKScrollView initWithFrame:]): (-[WKScrollView _contentInsetAdjustmentBehaviorWasExternallyOverridden]): (-[WKScrollView _setContentInsetAdjustmentBehavior:]): (-[WKScrollView _setContentInsetAdjustmentBehaviorInternal:]): Keep track of whether the client has ever touched the content inset adjustment behavior; if they have, we won't manage it ourselves. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/cocoa/TestRunnerWKWebView.h: * WebKitTestRunner/cocoa/TestRunnerWKWebView.mm: (-[TestRunnerWKWebView setOverrideSafeAreaInsets:]): (-[TestRunnerWKWebView _safeAreaInsetsForFrame:inSuperview:]): * WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformResetStateToConsistentValues): * WebKitTestRunner/ios/UIKitSPI.h: * WebKitTestRunner/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setSafeAreaInsets): (WTR::UIScriptController::setObscuredInsets): Deleted. Expose a safe area inset setter instead of obscured insets. * TestExpectations: * fast/css/variables/constants/ios/safe-area-inset-set-expected.html: * fast/css/variables/constants/ios/safe-area-inset-set.html: * fast/viewport/ios/viewport-fit-auto-expected.txt: Added. * fast/viewport/ios/viewport-fit-auto.html: Added. * fast/viewport/ios/viewport-fit-contain-expected.txt: Added. * fast/viewport/ios/viewport-fit-contain.html: Added. * fast/viewport/ios/viewport-fit-cover-expected.txt: Added. * fast/viewport/ios/viewport-fit-cover.html: Added. * tiled-drawing/ios/viewport-clip-to-safe-area-no-gets-margin-tiles-expected.txt: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-no-gets-margin-tiles.html: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-yes-gets-no-margin-tiles-expected.txt: Removed. * tiled-drawing/ios/viewport-clip-to-safe-area-yes-gets-no-margin-tiles.html: Removed. Remove clip-to-safe-area tests and add some viewport-fit tests. Also, adjust safe-area-inset-set to use the new UIScriptController setSafeAreaInset method. Canonical link: https://commits.webkit.org/188434@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216047 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-02 00:08:23 +00:00
bool avoidsUnsafeArea() const { return m_configuration.avoidsUnsafeArea; }
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
Allow override of viewport configuration. https://bugs.webkit.org/show_bug.cgi?id=188772. <rdar://problem/43538892>. Patch by James Savage <james.savage@apple.com> on 2018-09-26 Reviewed by Simon Fraser. Source/WebCore: * page/Settings.yaml: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::nativeWebpageParameters): Provide a viewport configuration similar to width=device-width, with initial scale set to 1. * page/ViewportConfiguration.h: Source/WebKit: * Shared/WebPreferences.yaml: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences _setShouldIgnoreMetaViewport:]): (-[WKPreferences _shouldIgnoreMetaViewport]): * UIProcess/API/Cocoa/WKPreferencesPrivate.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::viewportPropertiesDidChange): If we are ignoring the <meta> viewport, short circuit calling setViewportArguments() and do not do any updates. (WebKit::WebPage::didCommitLoad): Ditto. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetViewportDefaultConfiguration): Select the default configuration based on UIProcess setting. Tools: * WebKitTestRunner/TestController.cpp: (WTR::updateTestOptionsFromTestHeader): Parse new test option key from comments. * WebKitTestRunner/TestOptions.h: * WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformConfigureViewForTest): Handle new test option by modifying the web view's preferences accordingly. LayoutTests: Add test proving that a document without a meta viewport specifying width=device-width still gets a layout when this setting is enabled. I also added a baseline case to prove that without this setting we do not layout at device width. * fast/viewport/ios/ipad/empty-viewport-expected.txt: Added. * fast/viewport/ios/ipad/empty-viewport.html: Added. * fast/viewport/ios/ipad/meta-viewport-disabled-expected.txt: Added. * fast/viewport/ios/ipad/meta-viewport-disabled.html: Added. Canonical link: https://commits.webkit.org/204971@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@236530 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-09-26 22:31:18 +00:00
// Matches a width=device-width, initial-scale=1 viewport.
scalableNativeWebpageParameters() is not preserved on new page navigation. https://bugs.webkit.org/show_bug.cgi?id=194892 <rdar://problem/47538280> Source/WebCore: If a page's current default viewport configuration is scalableNativeWebpageParameters due to the fact that m_canIgnoreScalingConstraints is true, loading a new page should preserve this configuration until we derive the right values from viewport meta-tag. Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2019-02-25 Reviewed by Wenson Hsieh. Test: fast/viewport/ios/viewport-shrink-to-fit-on-new-navigation.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::canOverrideConfigurationParameters const): Use fixedNativeWebpageParameters(). (WebCore::ViewportConfiguration::updateDefaultConfiguration): Use nativeWebpageParameters. (WebCore::ViewportConfiguration::nativeWebpageParameters): Return the appropriate default configuration based on m_canIgnoreScalingConstraints and shouldIgnoreMinimumEffectiveDeviceWidth(). (WebCore::ViewportConfiguration::fixedNativeWebpageParameters): Renamed from nativeWebpageParameters() (WebCore::ViewportConfiguration::scalableNativeWebpageParameters): Use fixedNativeWebpageParameters. * page/ViewportConfiguration.h: Make nativeWebpageParameters() an instance method and change the old static method to fixedNativeWebpageParameters which better reflects the actual behavior. Source/WebKit: If a page's current default viewport configuration is scalableNativeWebpageParameters due to the fact that m_canIgnoreScalingConstraints is true, loading a new page should preserve this configuration until we derive the right values from viewport meta-tag. Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2019-02-25 Reviewed by Wenson Hsieh. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetViewportDefaultConfiguration): Use nativeWebpageParameters() instance method to get the appropriate default configuration. Tools: Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2019-02-25 Reviewed by Wenson Hsieh. Allow UIScriptController to set WKWebView's _allowsViewportShrinkToFit property with a new `setAllowsViewportShrinkToFit` method. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setAllowsViewportShrinkToFit): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::allowsViewportShrinkToFit): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setAllowsViewportShrinkToFit): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: (WTR::UIScriptController::setAllowsViewportShrinkToFit): LayoutTests: Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2019-02-25 Reviewed by Wenson Hsieh. * fast/viewport/ios/resources/go-back.html: Added. * fast/viewport/ios/viewport-shrink-to-fit-on-new-navigation-expected.txt: Added. * fast/viewport/ios/viewport-shrink-to-fit-on-new-navigation.html: Added. * fast/viewport/ios/minimum-scale-after-changing-view-scale.html: When shouldIgnoreMetaViewport setting is on, for pages don't have viewport meta-tag, the default configuration is now changed to scalableNativeWebpageParameters(). The original test was under the assumption that the default configuration is always fixedNativeWebpageParameters(). To keep the test still valid, add a viewport meta-tag to it. * resources/ui-helper.js: (window.UIHelper.setAllowsViewportShrinkToFit): Canonical link: https://commits.webkit.org/209392@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242069 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-02-26 04:37:59 +00:00
WEBCORE_EXPORT Parameters nativeWebpageParameters();
static Parameters nativeWebpageParametersWithoutShrinkToFit();
static Parameters nativeWebpageParametersWithShrinkToFit();
More WEBCORE_EXPORT macros! https://bugs.webkit.org/show_bug.cgi?id=136146 Reviewed by Benjamin Poulain. * Modules/geolocation/GeolocationClient.h: * Modules/mediastream/UserMediaClient.h: * Modules/mediastream/UserMediaRequest.h: * Modules/notifications/NotificationClient.h: * Modules/speech/SpeechSynthesis.h: * bindings/generic/RuntimeEnabledFeatures.h: * bindings/js/DOMWrapperWorld.h: * bindings/js/GCController.h: * bindings/js/IDBBindingUtilities.h: * bindings/js/JSDOMBinding.h: * bindings/js/JSNodeCustom.h: * bindings/js/JSNodeListCustom.h: * bindings/js/JSPluginElementFunctions.h: * bindings/js/ScriptController.h: * bindings/js/SerializedScriptValue.h: * crypto/SerializedCryptoKeyWrap.h: * css/LengthFunctions.h: * css/StyleProperties.h: * css/StyleSheetContents.h: * dom/DeviceOrientationClient.h: * dom/Range.h: * dom/ScriptExecutionContext.h: * dom/StyledElement.h: * dom/TreeScope.h: * dom/UIEventWithKeyState.h: * dom/UserGestureIndicator.h: * dom/UserTypingGestureIndicator.h: * dom/ViewportArguments.h: * editing/SmartReplace.h: * editing/TextIterator.h: * editing/VisiblePosition.h: * editing/VisibleSelection.h: * editing/VisibleUnits.h: * editing/cocoa/HTMLConverter.h: * editing/htmlediting.h: * editing/mac/TextAlternativeWithRange.h: * editing/mac/TextUndoInsertionMarkupMac.h: * editing/markup.h: * history/HistoryItem.cpp: * history/PageCache.h: * html/TimeRanges.h: * html/parser/HTMLParserIdioms.h: * inspector/InstrumentingAgents.h: * loader/FrameLoader.h: * loader/ResourceBuffer.h: * loader/ResourceLoadScheduler.h: * loader/ResourceLoader.h: (WebCore::ResourceLoader::originalRequest): * loader/SubframeLoader.h: * loader/SubresourceLoader.h: * loader/TextResourceDecoder.h: * loader/appcache/ApplicationCacheStorage.h: * loader/cache/MemoryCache.h: * loader/icon/IconDatabaseBase.h: * loader/ios/DiskImageCacheIOS.h: * page/Chrome.h: * page/SecurityOrigin.h: * page/SecurityPolicy.h: * page/Settings.h: * page/UserContentController.h: * page/UserContentURLPattern.h: * page/UserMessageHandlerDescriptor.h: * page/ViewportConfiguration.h: * page/VisitedLinkStore.h: * page/WheelEventDeltaTracker.h: * page/cocoa/UserAgent.h: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingStateTree.h: * page/scrolling/ScrollingThread.h: * page/scrolling/ScrollingTree.h: * page/scrolling/ScrollingTreeOverflowScrollingNode.h: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/ios/ScrollingTreeFrameScrollingNodeIOS.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeStickyNode.h: * platform/Cursor.h: * platform/DragImage.h: * platform/FileSystem.h: * platform/Language.h: * platform/LinkHash.h: * platform/LocalizedStrings.h: * platform/Logging.h: * platform/MemoryPressureHandler.h: * platform/NotImplemented.h: * platform/PlatformStrategies.h: * platform/PublicSuffix.h: * platform/RuntimeApplicationChecks.h: * platform/RuntimeApplicationChecksIOS.h: * platform/SchemeRegistry.h: * platform/ScrollView.h: * platform/ScrollableArea.h: * platform/Scrollbar.h: * platform/ScrollbarTheme.h: * platform/SharedBuffer.h: * platform/ThreadCheck.h: * platform/ThreadGlobalData.h: * platform/Timer.h: * platform/URL.h: * platform/UUID.h: * platform/UserActivity.h: * platform/Widget.h: * platform/cf/CFURLExtras.h: * platform/cf/RunLoopObserver.h: * platform/cocoa/SystemVersion.h: * platform/graphics/Color.h: * platform/graphics/FloatRect.h: * platform/graphics/FontCache.h: * platform/graphics/GeometryUtilities.h: * platform/graphics/GraphicsContext.h: * platform/graphics/IntRect.h: * platform/graphics/LayoutRect.h: * platform/graphics/StringTruncator.h: * platform/graphics/TextRun.h: * platform/graphics/ca/TileController.h: * platform/graphics/ca/mac/PlatformCAAnimationMac.h: * platform/graphics/cg/GraphicsContextCG.h: * platform/graphics/mac/ColorMac.h: * platform/graphics/transforms/TransformationMatrix.h: * platform/ios/FileSystemIOS.h: * platform/ios/PlatformEventFactoryIOS.h: * platform/ios/SelectionRect.h: * platform/ios/SystemMemory.h: * platform/ios/TileControllerMemoryHandlerIOS.h: * platform/ios/WebVideoFullscreenInterfaceAVKit.h: * platform/mac/PlatformEventFactoryMac.h: * platform/mac/ScrollbarThemeMac.h: * platform/mac/WebCoreNSURLExtras.h: * platform/mac/WebNSAttributedStringExtras.h: * platform/network/BlobRegistry.h: * platform/network/CookieStorage.h: * platform/network/DNS.h: * platform/network/NetworkStateNotifier.h: * platform/network/PlatformCookieJar.h: * platform/network/ProxyServer.h: * platform/network/ResourceErrorBase.h: * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.h: * platform/network/ResourceRequestBase.h: * platform/network/ResourceResponseBase.h: * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceError.h: * platform/network/cf/ResourceRequest.h: * platform/network/cf/ResourceResponse.h: * platform/network/ios/QuickLook.h: * platform/network/mac/AuthenticationMac.h: * platform/sql/SQLiteDatabase.cpp: * platform/text/LocaleToScriptMapping.h: * platform/text/TextBreakIterator.h: * platform/text/TextEncoding.h: (WebCore::TextEncoding::decode): * platform/text/TextEncodingRegistry.h: * platform/text/TextStream.h: * rendering/RenderBlock.h: * rendering/RenderBox.h: * rendering/RenderEmbeddedObject.h: * rendering/RenderLayer.h: * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.h: * rendering/RenderListItem.h: * rendering/RenderObject.h: * rendering/RenderText.h: * rendering/RenderTextControl.h: * rendering/RenderThemeIOS.h: * rendering/RenderTreeAsText.h: * rendering/RenderView.h: * rendering/RenderWidget.h: * rendering/ScrollBehavior.cpp: * rendering/break_lines.cpp: * rendering/style/RenderStyle.h: * replay/UserInputBridge.h: * storage/StorageEventDispatcher.h: * storage/StorageMap.h: * storage/StorageStrategy.h: * storage/StorageTracker.h: * testing/Internals.h: * workers/WorkerThread.h: Added more WEBCORE_EXPORT macros where needed. Canonical link: https://commits.webkit.org/153984@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@172849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-08-22 04:21:18 +00:00
WEBCORE_EXPORT static Parameters webpageParameters();
WEBCORE_EXPORT static Parameters textDocumentParameters();
WEBCORE_EXPORT static Parameters imageDocumentParameters();
WEBCORE_EXPORT static Parameters xhtmlMobileParameters();
WEBCORE_EXPORT static Parameters testingParameters();
PerformanceTests: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * JetStream2/wasm/HashSet.cpp: * StitchMarker/wtf/Assertions.h: * StitchMarker/wtf/DateMath.cpp: (WTF::initializeDates): * StitchMarker/wtf/HashTable.h: * StitchMarker/wtf/Hasher.h: (WTF::StringHasher::addCharacters): * StitchMarker/wtf/NeverDestroyed.h: (WTF::LazyNeverDestroyed::construct): * StitchMarker/wtf/StackBounds.h: (WTF::StackBounds::checkConsistency const): * StitchMarker/wtf/ValueCheck.h: * StitchMarker/wtf/Vector.h: (WTF::minCapacity>::checkConsistency): * StitchMarker/wtf/text/AtomicStringImpl.cpp: * StitchMarker/wtf/text/AtomicStringImpl.h: * StitchMarker/wtf/text/StringCommon.h: (WTF::hasPrefixWithLettersIgnoringASCIICaseCommon): * StitchMarker/wtf/text/StringImpl.h: * StitchMarker/wtf/text/SymbolImpl.h: * StitchMarker/wtf/text/UniquedStringImpl.h: Source/JavaScriptCore: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * API/tests/testapi.c: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::replaceWithLoad): (JSC::ARM64Assembler::replaceWithAddressComputation): * assembler/AssemblerBuffer.h: (JSC::AssemblerBuffer::LocalWriter::LocalWriter): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * assembler/ProbeStack.cpp: (JSC::Probe::Stack::Stack): * assembler/ProbeStack.h: * b3/B3FoldPathConstants.cpp: * b3/B3LowerToAir.cpp: * b3/B3MemoryValue.cpp: (JSC::B3::MemoryValue::MemoryValue): * b3/B3Opcode.cpp: * b3/B3Type.h: * b3/B3TypeMap.h: * b3/B3Width.h: * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration): (JSC::B3::Air::GenerateAndAllocateRegisters::generate): * b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirArg.cpp: * b3/air/AirArg.h: * b3/air/AirCode.h: * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::emitShuffle): * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createExecutable): * bytecode/AccessCase.cpp: * bytecode/AccessCase.h: * bytecode/CallVariant.cpp: (JSC::variantListWithVariant): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndex): * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::dump const): * bytecode/StructureStubInfo.cpp: * bytecode/StructureStubInfo.h: * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallResolveNode::emitBytecode): * bytecompiler/RegisterID.h: (JSC::RegisterID::RegisterID): (JSC::RegisterID::setIndex): * debugger/Debugger.cpp: (JSC::Debugger::removeBreakpoint): * debugger/DebuggerEvalEnabler.h: (JSC::DebuggerEvalEnabler::DebuggerEvalEnabler): (JSC::DebuggerEvalEnabler::~DebuggerEvalEnabler): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransitions): * dfg/DFGAbstractValue.cpp: * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::merge): (JSC::DFG::AbstractValue::checkConsistency const): (JSC::DFG::AbstractValue::assertIsRegistered const): * dfg/DFGArithMode.h: (JSC::DFG::doesOverflow): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::BasicBlock): * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::didLink): * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::performBlockCFA): * dfg/DFGCommon.h: (JSC::DFG::validationEnabled): * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::finalizeCatchEntrypoints): * dfg/DFGDesiredWatchpoints.h: * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGEdge.h: (JSC::DFG::Edge::makeWord): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::finalizeOSREntrypoints): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::assertClear): * dfg/DFGSlowPathGenerator.h: (JSC::DFG::SlowPathGenerator::generate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse): (JSC::DFG::SpeculativeJIT::emitAllocateButterfly): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): (JSC::DFG::SpeculativeJIT::compileMakeRope): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateCell): * dfg/DFGStructureAbstractValue.cpp: * dfg/DFGStructureAbstractValue.h: (JSC::DFG::StructureAbstractValue::assertIsRegistered const): * dfg/DFGVarargsForwardingPhase.cpp: * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::callPreflight): (JSC::FTL::DFG::LowerDFGToB3::callCheck): (JSC::FTL::DFG::LowerDFGToB3::crash): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * heap/BlockDirectory.cpp: (JSC::BlockDirectory::assertNoUnswept): * heap/GCSegmentedArray.h: (JSC::GCArraySegment::GCArraySegment): * heap/GCSegmentedArrayInlines.h: (JSC::GCSegmentedArray<T>::clear): (JSC::GCSegmentedArray<T>::expand): (JSC::GCSegmentedArray<T>::validatePrevious): * heap/HandleSet.cpp: * heap/HandleSet.h: * heap/Heap.cpp: (JSC::Heap::updateAllocationLimits): * heap/Heap.h: * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: (JSC::MarkedBlock::assertValidCell const): (JSC::MarkedBlock::assertMarksNotStale): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::beginMarking): (JSC::MarkedSpace::endMarking): (JSC::MarkedSpace::assertNoUnswept): * heap/PreciseAllocation.cpp: * heap/PreciseAllocation.h: (JSC::PreciseAllocation::assertValidCell const): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::SlotVisitor): (JSC::SlotVisitor::appendJSCellOrAuxiliary): * heap/SlotVisitor.h: * inspector/InspectorProtocolTypes.h: (Inspector::Protocol::BindingTraits<JSON::ArrayOf<T>>::assertValueHasExpectedType): * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration): (CppProtocolTypesImplementationGenerator): (CppProtocolTypesImplementationGenerator._generate_assertion_for_enum): * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * interpreter/FrameTracers.h: (JSC::JITOperationPrologueCallFrameTracer::JITOperationPrologueCallFrameTracer): * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): * interpreter/Interpreter.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::prepareCallOperation): * jit/BinarySwitch.cpp: (JSC::BinarySwitch::BinarySwitch): * jit/CCallHelpers.h: (JSC::CCallHelpers::setupStubArgs): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::emitDeltaCheck): (JSC::CallFrameShuffler::prepareAny): * jit/JIT.cpp: (JSC::JIT::assertStackPointerOffset): (JSC::JIT::compileWithoutLinking): * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_loop_hint): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_from_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_from_scope): * jit/Repatch.cpp: (JSC::linkPolymorphicCall): * jit/ThunkGenerators.cpp: (JSC::emitPointerValidation): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntOfflineAsmConfig.h: * parser/Lexer.cpp: * parser/Lexer.h: (JSC::isSafeBuiltinIdentifier): (JSC::Lexer<T>::lexExpectIdentifier): * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck): (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck): * runtime/Butterfly.h: (JSC::ContiguousData::ContiguousData): (JSC::ContiguousData::Data::Data): * runtime/HashMapImpl.h: (JSC::HashMapImpl::checkConsistency const): (JSC::HashMapImpl::assertBufferIsEmpty const): * runtime/JSCellInlines.h: (JSC::JSCell::methodTable const): * runtime/JSFunction.cpp: * runtime/JSFunction.h: (JSC::JSFunction::assertTypeInfoFlagInvariants): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): (JSC::JSFinalObject::visitChildren): * runtime/JSObjectInlines.h: (JSC::JSObject::validatePutOwnDataProperty): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::assertVariableIsInThisObject): * runtime/LiteralParser.cpp: (JSC::LiteralParser<CharType>::Lexer::lex): * runtime/LiteralParser.h: * runtime/Operations.h: (JSC::scribbleFreeCells): * runtime/OptionsList.h: * runtime/VM.cpp: (JSC::VM::computeCanUseJIT): * runtime/VM.h: (JSC::VM::canUseJIT): * runtime/VarOffset.h: (JSC::VarOffset::checkSanity const): * runtime/WeakMapImpl.h: (JSC::WeakMapImpl::checkConsistency const): (JSC::WeakMapImpl::assertBufferIsEmpty const): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::validateInst): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::validationFail const): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::checkConsistency): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast): * wasm/WasmSectionParser.h: * wasm/WasmSections.h: * wasm/WasmSignatureInlines.h: (JSC::Wasm::SignatureInformation::get): * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::previousInstanceOffset const): Source/WebCore: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * Modules/fetch/FetchBodySource.cpp: (WebCore::FetchBodySource::close): * Modules/fetch/FetchBodySource.h: * Modules/webdatabase/DatabaseDetails.h: (WebCore::DatabaseDetails::DatabaseDetails): (WebCore::DatabaseDetails::operator=): * Modules/webdatabase/DatabaseTask.cpp: (WebCore::DatabaseTask::performTask): * Modules/webdatabase/DatabaseTask.h: * Modules/webdatabase/DatabaseThread.cpp: (WebCore::DatabaseThread::terminationRequested const): * Modules/webgpu/WHLSL/AST/WHLSLAddressSpace.h: (WebCore::WHLSL::AST::TypeAnnotation::TypeAnnotation): * Modules/webgpu/WHLSL/WHLSLHighZombieFinder.cpp: (WebCore::WHLSL::findHighZombies): * Modules/webgpu/WHLSL/WHLSLInferTypes.cpp: (WebCore::WHLSL::matches): * Modules/webgpu/WHLSL/WHLSLLiteralTypeChecker.cpp: (WebCore::WHLSL::checkLiteralTypes): * Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.cpp: (WebCore::WHLSL::FindAllTypes::appendNamedType): * bindings/js/JSCallbackData.h: * bindings/js/JSLazyEventListener.cpp: * bindings/js/JSLazyEventListener.h: * contentextensions/ContentExtensionCompiler.cpp: (WebCore::ContentExtensions::compileRuleList): * css/CSSCalculationValue.cpp: (WebCore::CSSCalcOperationNode::primitiveType const): * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): * css/CSSPrimitiveValue.cpp: * css/CSSSelector.cpp: (WebCore::CSSSelector::selectorText const): * css/CSSStyleSheet.cpp: * dom/ActiveDOMObject.cpp: (WebCore::ActiveDOMObject::suspendIfNeeded): (WebCore::ActiveDOMObject::assertSuspendIfNeededWasCalled const): * dom/ActiveDOMObject.h: * dom/ContainerNode.cpp: * dom/ContainerNodeAlgorithms.cpp: * dom/ContainerNodeAlgorithms.h: * dom/CustomElementReactionQueue.cpp: * dom/CustomElementReactionQueue.h: (WebCore::CustomElementReactionDisallowedScope::CustomElementReactionDisallowedScope): (WebCore::CustomElementReactionDisallowedScope::~CustomElementReactionDisallowedScope): * dom/Document.cpp: (WebCore::Document::hitTest): * dom/Document.h: (WebCore::Document::decrementReferencingNodeCount): * dom/Element.cpp: (WebCore::Element::addShadowRoot): (WebCore::Element::getURLAttribute const): (WebCore::Element::getNonEmptyURLAttribute const): * dom/Element.h: * dom/ElementAndTextDescendantIterator.h: (WebCore::ElementAndTextDescendantIterator::ElementAndTextDescendantIterator): (WebCore::ElementAndTextDescendantIterator::dropAssertions): (WebCore::ElementAndTextDescendantIterator::popAncestorSiblingStack): (WebCore::ElementAndTextDescendantIterator::traverseNextSibling): (WebCore::ElementAndTextDescendantIterator::traversePreviousSibling): * dom/ElementDescendantIterator.h: (WebCore::ElementDescendantIterator::ElementDescendantIterator): (WebCore::ElementDescendantIterator::dropAssertions): (WebCore::ElementDescendantIterator::operator++): (WebCore::ElementDescendantIterator::operator--): (WebCore::ElementDescendantConstIterator::ElementDescendantConstIterator): (WebCore::ElementDescendantConstIterator::dropAssertions): (WebCore::ElementDescendantConstIterator::operator++): * dom/ElementIterator.h: (WebCore::ElementIterator<ElementType>::ElementIterator): (WebCore::ElementIterator<ElementType>::traverseNext): (WebCore::ElementIterator<ElementType>::traversePrevious): (WebCore::ElementIterator<ElementType>::traverseNextSibling): (WebCore::ElementIterator<ElementType>::traversePreviousSibling): (WebCore::ElementIterator<ElementType>::traverseNextSkippingChildren): (WebCore::ElementIterator<ElementType>::dropAssertions): (WebCore::ElementIterator<ElementType>::traverseAncestor): (WebCore::ElementConstIterator<ElementType>::ElementConstIterator): (WebCore::ElementConstIterator<ElementType>::traverseNext): (WebCore::ElementConstIterator<ElementType>::traversePrevious): (WebCore::ElementConstIterator<ElementType>::traverseNextSibling): (WebCore::ElementConstIterator<ElementType>::traversePreviousSibling): (WebCore::ElementConstIterator<ElementType>::traverseNextSkippingChildren): (WebCore::ElementConstIterator<ElementType>::traverseAncestor): (WebCore::ElementConstIterator<ElementType>::dropAssertions): * dom/EventContext.cpp: * dom/EventContext.h: * dom/EventListener.h: * dom/EventPath.cpp: * dom/EventSender.h: * dom/EventTarget.cpp: (WebCore::EventTarget::addEventListener): (WebCore::EventTarget::setAttributeEventListener): (WebCore::EventTarget::innerInvokeEventListeners): * dom/Node.cpp: (WebCore::Node::~Node): (WebCore::Node::moveNodeToNewDocument): (WebCore::Node::removedLastRef): * dom/Node.h: (WebCore::Node::deref const): * dom/ScriptDisallowedScope.h: (WebCore::ScriptDisallowedScope::InMainThread::isEventDispatchAllowedInSubtree): * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::~ScriptExecutionContext): * dom/ScriptExecutionContext.h: * dom/SelectorQuery.cpp: (WebCore::SelectorDataList::execute const): * dom/SlotAssignment.cpp: (WebCore::SlotAssignment::addSlotElementByName): (WebCore::SlotAssignment::removeSlotElementByName): (WebCore::SlotAssignment::resolveSlotsAfterSlotMutation): (WebCore::SlotAssignment::findFirstSlotElement): * dom/SlotAssignment.h: * dom/TreeScopeOrderedMap.cpp: (WebCore::TreeScopeOrderedMap::add): (WebCore::TreeScopeOrderedMap::get const): * dom/TreeScopeOrderedMap.h: * fileapi/Blob.cpp: * fileapi/Blob.h: * history/BackForwardCache.cpp: (WebCore::BackForwardCache::removeAllItemsForPage): * history/BackForwardCache.h: * html/CanvasBase.cpp: (WebCore::CanvasBase::notifyObserversCanvasDestroyed): * html/CanvasBase.h: * html/HTMLCollection.h: (WebCore::CollectionNamedElementCache::didPopulate): * html/HTMLSelectElement.cpp: (WebCore:: const): * html/HTMLTableRowsCollection.cpp: (WebCore::assertRowIsInTable): * html/HTMLTextFormControlElement.cpp: (WebCore::HTMLTextFormControlElement::indexForPosition const): * html/canvas/CanvasRenderingContext2DBase.cpp: (WebCore::CanvasRenderingContext2DBase::~CanvasRenderingContext2DBase): * html/parser/HTMLParserScheduler.cpp: (WebCore::HTMLParserScheduler::HTMLParserScheduler): (WebCore::HTMLParserScheduler::suspend): (WebCore::HTMLParserScheduler::resume): * html/parser/HTMLParserScheduler.h: * html/parser/HTMLToken.h: (WebCore::HTMLToken::beginStartTag): (WebCore::HTMLToken::beginEndTag): (WebCore::HTMLToken::endAttribute): * html/parser/HTMLTreeBuilder.cpp: (WebCore::HTMLTreeBuilder::HTMLTreeBuilder): (WebCore::HTMLTreeBuilder::constructTree): * html/parser/HTMLTreeBuilder.h: (WebCore::HTMLTreeBuilder::~HTMLTreeBuilder): * layout/FormattingContext.cpp: (WebCore::Layout::FormattingContext::geometryForBox const): * layout/blockformatting/BlockFormattingContext.cpp: (WebCore::Layout::BlockFormattingContext::computeEstimatedVerticalPosition): * layout/blockformatting/BlockFormattingContext.h: * layout/displaytree/DisplayBox.cpp: (WebCore::Display::Box::Box): * layout/displaytree/DisplayBox.h: (WebCore::Display::Box::setTopLeft): (WebCore::Display::Box::setTop): (WebCore::Display::Box::setLeft): (WebCore::Display::Box::setContentBoxHeight): (WebCore::Display::Box::setContentBoxWidth): (WebCore::Display::Box::setHorizontalMargin): (WebCore::Display::Box::setVerticalMargin): (WebCore::Display::Box::setHorizontalComputedMargin): (WebCore::Display::Box::setBorder): (WebCore::Display::Box::setPadding): * layout/displaytree/DisplayInlineRect.h: (WebCore::Display::InlineRect::InlineRect): (WebCore::Display::InlineRect::setTopLeft): (WebCore::Display::InlineRect::setTop): (WebCore::Display::InlineRect::setBottom): (WebCore::Display::InlineRect::setLeft): (WebCore::Display::InlineRect::setWidth): (WebCore::Display::InlineRect::setHeight): * layout/displaytree/DisplayLineBox.h: (WebCore::Display::LineBox::LineBox): (WebCore::Display::LineBox::setBaselineOffsetIfGreater): (WebCore::Display::LineBox::resetBaseline): (WebCore::Display::LineBox::Baseline::Baseline): (WebCore::Display::LineBox::Baseline::setAscent): (WebCore::Display::LineBox::Baseline::setDescent): (WebCore::Display::LineBox::Baseline::reset): * layout/displaytree/DisplayRect.h: (WebCore::Display::Rect::Rect): (WebCore::Display::Rect::setTopLeft): (WebCore::Display::Rect::setTop): (WebCore::Display::Rect::setLeft): (WebCore::Display::Rect::setWidth): (WebCore::Display::Rect::setHeight): (WebCore::Display::Rect::setSize): (WebCore::Display::Rect::clone const): * layout/floats/FloatingContext.cpp: * layout/inlineformatting/InlineLineBuilder.cpp: (WebCore::Layout::LineBuilder::CollapsibleContent::collapse): * layout/tableformatting/TableGrid.cpp: (WebCore::Layout::TableGrid::Column::setWidthConstraints): (WebCore::Layout::TableGrid::Column::setLogicalWidth): (WebCore::Layout::TableGrid::Column::setLogicalLeft): * layout/tableformatting/TableGrid.h: * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::continueAfterContentPolicy): (WebCore::DocumentLoader::attachToFrame): (WebCore::DocumentLoader::detachFromFrame): (WebCore::DocumentLoader::addSubresourceLoader): * loader/DocumentLoader.h: * loader/ImageLoader.cpp: * loader/cache/CachedResource.h: * loader/cache/MemoryCache.cpp: (WebCore::MemoryCache::lruListFor): (WebCore::MemoryCache::removeFromLRUList): * page/FrameView.cpp: (WebCore::FrameView::updateLayoutAndStyleIfNeededRecursive): * page/FrameViewLayoutContext.cpp: * page/FrameViewLayoutContext.h: * page/Page.cpp: * page/Page.h: * page/ViewportConfiguration.cpp: * page/ViewportConfiguration.h: * page/mac/EventHandlerMac.mm: (WebCore::CurrentEventScope::CurrentEventScope): * platform/DateComponents.cpp: (WebCore::DateComponents::toStringForTime const): * platform/ScrollableArea.cpp: * platform/SharedBuffer.cpp: (WebCore::SharedBuffer::combineIntoOneSegment const): * platform/SharedBuffer.h: * platform/Supplementable.h: * platform/Timer.cpp: (WebCore::TimerBase::checkHeapIndex const): (WebCore::TimerBase::updateHeapIfNeeded): * platform/graphics/BitmapImage.cpp: * platform/graphics/BitmapImage.h: * platform/graphics/Image.h: * platform/graphics/ShadowBlur.cpp: (WebCore::ScratchBuffer::ScratchBuffer): (WebCore::ScratchBuffer::getScratchBuffer): (WebCore::ScratchBuffer::scheduleScratchBufferPurge): * platform/graphics/ca/win/CACFLayerTreeHost.cpp: (WebCore::CACFLayerTreeHost::setWindow): * platform/graphics/ca/win/CACFLayerTreeHost.h: * platform/graphics/cg/ImageBufferDataCG.cpp: (WebCore::ImageBufferData::putData): * platform/graphics/cocoa/FontCacheCoreText.cpp: * platform/graphics/gstreamer/GstAllocatorFastMalloc.cpp: (gstAllocatorFastMallocFree): * platform/graphics/nicosia/cairo/NicosiaPaintingContextCairo.cpp: (Nicosia::PaintingContextCairo::ForPainting::ForPainting): * platform/graphics/nicosia/texmap/NicosiaBackingStoreTextureMapperImpl.cpp: (Nicosia::BackingStoreTextureMapperImpl::createTile): * platform/graphics/nicosia/texmap/NicosiaContentLayerTextureMapperImpl.cpp: (Nicosia::ContentLayerTextureMapperImpl::~ContentLayerTextureMapperImpl): * platform/graphics/win/GradientDirect2D.cpp: (WebCore::Gradient::fill): * platform/graphics/win/ImageBufferDataDirect2D.cpp: (WebCore::ImageBufferData::putData): * platform/graphics/win/PathDirect2D.cpp: (WebCore::Path::appendGeometry): (WebCore::Path::Path): (WebCore::Path::operator=): (WebCore::Path::strokeContains const): (WebCore::Path::transform): * platform/graphics/win/PlatformContextDirect2D.cpp: (WebCore::PlatformContextDirect2D::setTags): * platform/mediastream/MediaStreamTrackPrivate.h: * platform/mediastream/RealtimeOutgoingAudioSource.cpp: (WebCore::RealtimeOutgoingAudioSource::~RealtimeOutgoingAudioSource): * platform/mediastream/RealtimeOutgoingVideoSource.cpp: (WebCore::RealtimeOutgoingVideoSource::~RealtimeOutgoingVideoSource): * platform/network/HTTPParsers.cpp: (WebCore::isCrossOriginSafeHeader): * platform/sql/SQLiteDatabase.cpp: * platform/sql/SQLiteDatabase.h: * platform/sql/SQLiteStatement.cpp: (WebCore::SQLiteStatement::SQLiteStatement): (WebCore::SQLiteStatement::prepare): (WebCore::SQLiteStatement::finalize): * platform/sql/SQLiteStatement.h: * platform/win/COMPtr.h: * rendering/ComplexLineLayout.cpp: (WebCore::ComplexLineLayout::removeInlineBox const): * rendering/FloatingObjects.cpp: (WebCore::FloatingObject::FloatingObject): (WebCore::FloatingObjects::addPlacedObject): (WebCore::FloatingObjects::removePlacedObject): * rendering/FloatingObjects.h: * rendering/GridTrackSizingAlgorithm.cpp: * rendering/GridTrackSizingAlgorithm.h: * rendering/LayoutDisallowedScope.cpp: * rendering/LayoutDisallowedScope.h: * rendering/RenderBlock.cpp: * rendering/RenderBlock.h: * rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::layoutBlockChild): (WebCore::RenderBlockFlow::removeFloatingObject): (WebCore::RenderBlockFlow::ensureLineBoxes): * rendering/RenderBoxModelObject.cpp: * rendering/RenderDeprecatedFlexibleBox.cpp: (WebCore::RenderDeprecatedFlexibleBox::layoutBlock): * rendering/RenderElement.cpp: * rendering/RenderGeometryMap.cpp: (WebCore::RenderGeometryMap::mapToContainer const): * rendering/RenderGrid.cpp: (WebCore::RenderGrid::placeItemsOnGrid const): (WebCore::RenderGrid::baselinePosition const): * rendering/RenderInline.cpp: (WebCore::RenderInline::willBeDestroyed): * rendering/RenderLayer.cpp: (WebCore::ClipRectsCache::ClipRectsCache): (WebCore::RenderLayer::RenderLayer): (WebCore::RenderLayer::paintList): (WebCore::RenderLayer::hitTestLayer): (WebCore::RenderLayer::updateClipRects): (WebCore::RenderLayer::calculateClipRects const): * rendering/RenderLayer.h: * rendering/RenderLayerBacking.cpp: (WebCore::traverseVisibleNonCompositedDescendantLayers): * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::computeCompositingRequirements): (WebCore::RenderLayerCompositor::traverseUnchangedSubtree): (WebCore::RenderLayerCompositor::updateBackingAndHierarchy): (WebCore::RenderLayerCompositor::addDescendantsToOverlapMapRecursive const): (WebCore::RenderLayerCompositor::recursiveRepaintLayer): (WebCore::RenderLayerCompositor::layerHas3DContent const): * rendering/RenderLayoutState.cpp: (WebCore::RenderLayoutState::RenderLayoutState): (WebCore::RenderLayoutState::computeOffsets): (WebCore::RenderLayoutState::addLayoutDelta): * rendering/RenderLayoutState.h: (WebCore::RenderLayoutState::RenderLayoutState): * rendering/RenderObject.cpp: (WebCore::RenderObject::RenderObject): (WebCore::RenderObject::~RenderObject): (WebCore::RenderObject::clearNeedsLayout): * rendering/RenderObject.h: * rendering/RenderQuote.cpp: (WebCore::quotesForLanguage): * rendering/RenderTableCell.h: * rendering/RenderTableSection.cpp: (WebCore::RenderTableSection::computeOverflowFromCells): * rendering/RenderTextLineBoxes.cpp: (WebCore::RenderTextLineBoxes::checkConsistency const): * rendering/RenderTextLineBoxes.h: * rendering/line/BreakingContext.h: (WebCore::tryHyphenating): * rendering/style/GridArea.h: (WebCore::GridSpan::GridSpan): * rendering/style/RenderStyle.cpp: (WebCore::RenderStyle::~RenderStyle): * rendering/style/RenderStyle.h: * rendering/updating/RenderTreeBuilderRuby.cpp: (WebCore::RenderTreeBuilder::Ruby::detach): * rendering/updating/RenderTreePosition.cpp: (WebCore::RenderTreePosition::computeNextSibling): * rendering/updating/RenderTreePosition.h: * svg/SVGToOTFFontConversion.cpp: (WebCore::SVGToOTFFontConverter::Placeholder::Placeholder): (WebCore::SVGToOTFFontConverter::Placeholder::populate): (WebCore::SVGToOTFFontConverter::appendCFFTable): (WebCore::SVGToOTFFontConverter::firstGlyph const): (WebCore::SVGToOTFFontConverter::appendKERNTable): * svg/SVGTransformDistance.cpp: (WebCore::SVGTransformDistance::SVGTransformDistance): (WebCore::SVGTransformDistance::scaledDistance const): (WebCore::SVGTransformDistance::addSVGTransforms): (WebCore::SVGTransformDistance::addToSVGTransform const): (WebCore::SVGTransformDistance::distance const): * svg/graphics/SVGImage.cpp: (WebCore::SVGImage::nativeImage): * testing/InternalSettings.cpp: * workers/service/ServiceWorkerJob.h: * worklets/PaintWorkletGlobalScope.h: (WebCore::PaintWorkletGlobalScope::~PaintWorkletGlobalScope): * xml/XPathStep.cpp: Source/WebKit: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::invalidateAndCancel): * NetworkProcess/NetworkSession.h: * NetworkProcess/cache/NetworkCacheStorage.cpp: (WebKit::NetworkCache::Storage::setCapacity): * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (toNSURLSessionResponseDisposition): (WebKit::NetworkSessionCocoa::NetworkSessionCocoa): * Platform/IPC/Connection.cpp: (IPC::Connection::waitForMessage): * Platform/IPC/MessageReceiver.h: (IPC::MessageReceiver::willBeAddedToMessageReceiverMap): (IPC::MessageReceiver::willBeRemovedFromMessageReceiverMap): * Platform/IPC/cocoa/ConnectionCocoa.mm: (IPC::readFromMachPort): * Platform/mac/MachUtilities.cpp: (setMachExceptionPort): * Shared/API/APIClient.h: (API::Client::Client): * Shared/API/Cocoa/WKRemoteObjectCoder.mm: * Shared/Cocoa/ArgumentCodersCocoa.h: * Shared/SharedStringHashTableReadOnly.cpp: * UIProcess/BackingStore.cpp: (WebKit::BackingStore::incorporateUpdate): * UIProcess/GenericCallback.h: * UIProcess/Launcher/mac/ProcessLauncherMac.mm: (WebKit::ProcessLauncher::launchProcess): * UIProcess/PageLoadState.h: (WebKit::PageLoadState::Transaction::Token::Token): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::~WebPageProxy): * WebProcess/Network/WebResourceLoader.cpp: (WebKit::WebResourceLoader::didReceiveResponse): * WebProcess/Network/WebResourceLoader.h: * WebProcess/Plugins/Netscape/NetscapePluginStream.cpp: (WebKit::NetscapePluginStream::NetscapePluginStream): (WebKit::NetscapePluginStream::notifyAndDestroyStream): * WebProcess/Plugins/Netscape/NetscapePluginStream.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::runModal): * WebProcess/WebProcess.cpp: (WebKit::checkDocumentsCaptureStateConsistency): * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::updateProcessName): Source/WebKitLegacy: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * Storage/StorageAreaImpl.cpp: (WebKit::StorageAreaImpl::StorageAreaImpl): (WebKit::StorageAreaImpl::close): * Storage/StorageAreaImpl.h: Source/WebKitLegacy/mac: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * History/WebHistory.mm: (-[WebHistoryPrivate removeItemForURLString:]): * WebView/WebFrame.mm: Source/WebKitLegacy/win: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * WebKitQuartzCoreAdditions/CAD3DRenderer.cpp: (WKQCA::CAD3DRenderer::swapChain): (WKQCA::CAD3DRenderer::initialize): * WebKitQuartzCoreAdditions/CAD3DRenderer.h: * WebView.cpp: (WebView::Release): * WebView.h: Source/WTF: Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. This patch did the following changes: 1. Replaced ASSERT_DISABLED with ASSERT_ENABLED. This change does away with the need for the double negative !ASSERT_DISABLED test that is commonly used all over the code, thereby improving code readability. In Assertions.h, there is also BACKTRACE_DISABLED, ASSERT_MSG_DISABLED, ASSERT_ARG_DISABLED, FATAL_DISABLED, ERROR_DISABLED, LOG_DISABLED, and RELEASE_LOG_DISABLED. We should replace those with ..._ENABLED equivalents as well. We'll do that in another patch. For now, they are left as is to minimize the size of this patch. See https://bugs.webkit.org/show_bug.cgi?id=205780. 2. Fixed some code was guarded with "#ifndef NDEBUG" that should actually be guarded by "#if ASSERT_ENABLED" instead. 3. In cases where the change is minimal, we move some code around so that we can test for "#if ASSERT_ENABLED" instead of "#if !ASSERT_ENABLED". * wtf/Assertions.h: * wtf/AutomaticThread.cpp: (WTF::AutomaticThread::start): * wtf/BitVector.h: * wtf/BlockObjCExceptions.mm: (ReportBlockedObjCException): * wtf/BloomFilter.h: * wtf/CallbackAggregator.h: (WTF::CallbackAggregator::CallbackAggregator): * wtf/CheckedArithmetic.h: (WTF::observesOverflow<AssertNoOverflow>): * wtf/CheckedBoolean.h: (CheckedBoolean::CheckedBoolean): (CheckedBoolean::operator bool): * wtf/CompletionHandler.h: (WTF::CompletionHandler<Out): * wtf/DateMath.cpp: (WTF::initializeDates): * wtf/Gigacage.cpp: (Gigacage::tryAllocateZeroedVirtualPages): * wtf/HashTable.h: (WTF::KeyTraits>::checkKey): (WTF::KeyTraits>::checkTableConsistencyExceptSize const): * wtf/LoggerHelper.h: * wtf/NaturalLoops.h: (WTF::NaturalLoops::headerOf const): * wtf/NeverDestroyed.h: (WTF::LazyNeverDestroyed::construct): * wtf/OptionSet.h: (WTF::OptionSet::OptionSet): * wtf/Platform.h: * wtf/PtrTag.h: * wtf/RefCounted.h: (WTF::RefCountedBase::disableThreadingChecks): (WTF::RefCountedBase::enableThreadingChecksGlobally): (WTF::RefCountedBase::RefCountedBase): (WTF::RefCountedBase::applyRefDerefThreadingCheck const): * wtf/SingleRootGraph.h: (WTF::SingleRootGraph::assertIsConsistent const): * wtf/SizeLimits.cpp: * wtf/StackBounds.h: (WTF::StackBounds::checkConsistency const): * wtf/URLParser.cpp: (WTF::URLParser::URLParser): (WTF::URLParser::domainToASCII): * wtf/ValueCheck.h: * wtf/Vector.h: (WTF::Malloc>::checkConsistency): * wtf/WeakHashSet.h: * wtf/WeakPtr.h: (WTF::WeakPtrImpl::WeakPtrImpl): (WTF::WeakPtrFactory::WeakPtrFactory): * wtf/text/AtomStringImpl.cpp: * wtf/text/AtomStringImpl.h: * wtf/text/StringBuilder.cpp: (WTF::StringBuilder::reifyString const): * wtf/text/StringBuilder.h: * wtf/text/StringCommon.h: (WTF::hasPrefixWithLettersIgnoringASCIICaseCommon): * wtf/text/StringHasher.h: (WTF::StringHasher::addCharacters): * wtf/text/StringImpl.h: * wtf/text/SymbolImpl.h: * wtf/text/UniquedStringImpl.h: Tools: Remove WebsiteDataStore::setServiceWorkerRegistrationDirectory https://bugs.webkit.org/show_bug.cgi?id=205754 Patch by Alex Christensen <achristensen@webkit.org> on 2020-01-06 Reviewed by Youenn Fablet. * TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm: * WebKitTestRunner/TestController.cpp: (WTR::TestController::websiteDataStore): (WTR::TestController::platformAdjustContext): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::initializeWebViewConfiguration): Canonical link: https://commits.webkit.org/218957@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@254087 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-01-06 22:24:50 +00:00
#if !LOG_DISABLED
Add a log channel for viewports https://bugs.webkit.org/show_bug.cgi?id=180295 Reviewed by Zalan Bujtas. Add a "Viewports" log channel to log viewport scaling information, and enhance the WebKit "VisibleRects" channel to log additional data for the same reason. Source/WebCore: * dom/Document.cpp: (WebCore::Document::processViewport): * loader/FrameLoader.cpp: (WebCore::FrameLoader::finishedParsing): (WebCore::FrameLoader::completed): * page/FrameView.cpp: (WebCore::FrameView::resetScrollbarsAndClearContentsSize): (WebCore::FrameView::scrollToAnchor): (WebCore::FrameView::maintainScrollPositionAtAnchor): (WebCore::FrameView::setScrollPosition): (WebCore::FrameView::autoSizeIfEnabled): (WebCore::FrameView::setWasScrolledByUser): * page/LayoutContext.cpp: (WebCore::LayoutContext::layout): * page/Page.cpp: (WebCore::Page::setPageScaleFactor): * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::operator<<): (WebCore::ViewportConfiguration::description const): (WebCore::ViewportConfiguration::dump const): * page/ViewportConfiguration.h: * platform/Logging.h: * platform/ScrollView.cpp: (WebCore::ScrollView::setFixedLayoutSize): Source/WebKit: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _didCommitLayerTree:]): (-[WKWebView _dynamicViewportUpdateChangedTargetToScale:position:nextValidLayerTreeTransactionID:]): (-[WKWebView _dispatchSetMinimumLayoutSize:]): (-[WKWebView _endAnimatedResize]): (-[WKWebView _resizeWhileHidingContentWithUpdates:]): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setFixedLayoutSize): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::scaleAfterViewportWidthChange): (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::viewportConfigurationChanged): (WebKit::WebPage::updateVisibleContentRects): Canonical link: https://commits.webkit.org/196293@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@225449 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-12-02 17:55:24 +00:00
String description() const;
[iOS WK2] Font size increases on some pages after navigating then going back https://bugs.webkit.org/show_bug.cgi?id=157441 rdar://problem/22873240 Reviewed by Darin Adler. Source/WebCore: Sometimes I want to dump ViewportConfigurations from WebKit2 so export dump(). Test: fast/text-autosizing/ios/text-autosizing-after-back.html * page/ViewportConfiguration.h: Source/WebKit2: There's an ordering dependency between setting the viewport configuration and doing layouts when going back to a page from the page cache that is incorrectly handled. In FrameLoader::commitProvisionalLoad(), CachedPage::restore() triggers a layout under updateContentsSize(), but this happens before dispatchDidCommitLoad() which updates the viewport arguments via ViewportConfiguration::setViewportArguments(). This issue is not addressed by the current commit. But a second problem is: if the inputs to text autosizing change, we need to invalidate the autosizing state. The relevant input here is the fixed layout width (which is determined from the viewport configuration). The current code invalidated text autosizing when m_viewportConfiguration.minimumLayoutSize() changed, but the correct behavior is to invalidate based on fixed layout size changing. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::sendViewportAttributesChanged): (WebKit::WebPage::setFixedLayoutSize): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetTextAutosizing): (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::viewportConfigurationChanged): (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): Deleted. (WebKit::WebPage::resetTextAutosizingBeforeLayoutIfNeeded): Deleted. LayoutTests: * fast/text-autosizing/ios/text-autosizing-after-back-expected.html: Added. * fast/text-autosizing/ios/text-autosizing-after-back.html: Added. Canonical link: https://commits.webkit.org/175619@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@200588 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-05-09 20:22:47 +00:00
WEBCORE_EXPORT void dump() const;
#endif
Add a mechanism to opt-out of the automatic scaling applied to not-really-responsive sites https://bugs.webkit.org/show_bug.cgi?id=144760 Reviewed by Darin Adler. Add a new viewport property, shrink-to-fit, which can be used to disable the automatic scaling introduced in r181400. This provides sites with a way to tell WebKit that they're really sure they want to be laid out at window-width/height, even if they fail to fit within that size. * dom/ViewportArguments.cpp: (WebCore::ViewportArguments::resolve): (WebCore::findBooleanValue): (WebCore::setViewportFeature): * dom/ViewportArguments.h: (WebCore::ViewportArguments::ViewportArguments): (WebCore::ViewportArguments::operator==): * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::shouldIgnoreHorizontalScalingConstraints): (WebCore::ViewportConfiguration::shouldIgnoreVerticalScalingConstraints): (WebCore::ViewportConfiguration::webpageParameters): (WebCore::ViewportConfiguration::textDocumentParameters): (WebCore::ViewportConfiguration::imageDocumentParameters): (WebCore::ViewportConfiguration::testingParameters): (WebCore::booleanViewportArgumentIsSet): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfigurationTextStream::operator<<): (WebCore::viewportArgumentUserZoomIsSet): Deleted. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::Parameters::Parameters): Plumb the shrink-to-fit viewport property through. If shrink-to-fit is set to yes, or not set, we behave as usual; if it is set to no, we will bail from shouldIgnore[Horizontal|Vertical]ScalingConstraints, effectively disabling the automatic scaling introduced in r181400. Canonical link: https://commits.webkit.org/163231@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@184654 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-05-20 20:42:49 +00:00
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
private:
void updateConfiguration();
double viewportArgumentsLength(double length) const;
double initialScaleFromSize(double width, double height, bool shouldIgnoreScalingConstraints) const;
Sites that use a device-width viewport but don't have enough height to fill the view are scaled up https://bugs.webkit.org/show_bug.cgi?id=142664 <rdar://problem/18859470> Reviewed by Benjamin Poulain. * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::shouldIgnoreHorizontalScalingConstraints): (WebCore::ViewportConfiguration::shouldIgnoreVerticalScalingConstraints): (WebCore::ViewportConfiguration::shouldIgnoreScalingConstraints): Split shouldIgnoreScalingConstraints into one for each dimension. (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): Don't force the initial and minimum scales to cover the whole view if the page claims to want to lay out to device width but then lays out too big. This will allow pages that misbehave in this way to scale down further than they previously could, but will result in a region of empty background color being exposed at the initial/minimum scale. (WebCore::ViewportConfiguration::description): Update the logging to show each dimension separately. * page/ViewportConfiguration.h: * UIProcess/ios/WKScrollView.mm: (-[WKScrollView _rubberBandOffsetForOffset:maxOffset:minOffset:range:outside:]): Now that the WKContentView can (without pinching) be smaller than the unobscured region of the WKWebView, we need to take that into account when deciding where to retarget scrolling. Canonical link: https://commits.webkit.org/160692@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@181488 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-03-13 21:07:06 +00:00
[Extra zoom mode] Google search results are excessively zoomed in https://bugs.webkit.org/show_bug.cgi?id=185347 <rdar://problem/39999778> Reviewed by Tim Horton. Source/WebCore: It turns out that basing minimum layout size and shrink-to-fit behaviors off of the `shrink-to-fit` viewport argument poses compatibility risks with web pages that already specify `shrink-to-fit` to opt out of default viewport shrinking behaviors in 1/3 multitasking mode on iPad. One way to resolve this is to introduce a new viewport meta content attribute to disable viewport heuristics in extra zoom mode. However, combined shrink-to-fit and minimum device width behaviors are difficult to describe using a single backwards-compatible viewport meta content attribute, and the need to suppress the default behavior of `shrink-to-fit=no` if such an attribute is not disabled further muddles our viewport story. After some internal deliberation, we’ve decided to experiment with a new meta tag named "disabled-adaptations". The content of this meta tag is a comma-separated list of adaptation names; if an adaptation name matches a known adaptation type (for instance, extra zoom mode), we disable the class of behaviors used to adapt web content. The first and only known adaptation type is extra zoom mode, which affects `shrink-to-fit` and layout size adjustments. See per-method changes below for more details. Test: fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * dom/Document.cpp: (WebCore::Document::processDisabledAdaptations): * dom/Document.h: (WebCore::Document::disabledAdaptations const): Add disabled adaptations to Document. Changes to disabled adaptations are not propagated if the parsed disabled adaptation types don't change; upon changing adaptation types, notify the client to adjust for the new disabled adaptations (currently, this only affects the viewport configuration). * dom/ViewportArguments.h: * html/HTMLMetaElement.cpp: (WebCore::HTMLMetaElement::process): * html/parser/HTMLPreloadScanner.cpp: (WebCore::TokenPreloadScanner::StartTagScanner::StartTagScanner): (WebCore::TokenPreloadScanner::StartTagScanner::processAttributes): (WebCore::TokenPreloadScanner::StartTagScanner::processAttribute): * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Restore the set of disabled adaptations when restoring a page from the cache. * page/Chrome.cpp: (WebCore::Chrome::dispatchDisabledAdaptationsDidChange const): * page/Chrome.h: * page/ChromeClient.h: Add plumbing for changes to the set of disabled adaptations. * page/DisabledAdaptations.cpp: Added. (WebCore::extraZoomModeAdaptationName): * page/DisabledAdaptations.h: Added. Introduce a header containing a new enum for the extra zoom mode adaptation, as well as a helper function to return the extra zoom mode adaptation name. * page/Page.cpp: (WebCore::Page::disabledAdaptations const): Returns the mainframe's set of adaptations to disable. * page/Page.h: * page/RemoteFrame.h: * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setDisabledAdaptationsMetaTagEnabled): (WebCore::RuntimeEnabledFeatures::disabledAdaptationsMetaTagEnabled const): Add a new runtime feature to gate handling the "disabled-adaptations" meta tag. * page/ViewportConfiguration.cpp: (WebCore::shouldOverrideShrinkToFitArgument): (WebCore::needsUpdateAfterChangingDisabledAdaptations): (WebCore::ViewportConfiguration::setDisabledAdaptations): (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthAndShrinkToFit const): Consult whether or not extra zoom mode adaptations are disabled, instead of the shrink-to-fit attribute value. (WebCore::ViewportConfiguration::updateConfiguration): * page/ViewportConfiguration.h: Add an OptionSet of disabled adaptation types to ViewportConfiguration. Updates to the adaptation type are propagated to the ViewportConfiguration from Document, through the ChromeClient and the client layer (refer to changes in WebKit). Once the OptionSet is changed, we recompute the viewport configuration only if needed by the platform. (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::disabledAdaptations const): * page/WindowFeatures.cpp: (WebCore::parseDisabledAdaptations): * page/WindowFeatures.h: Add a new helper to parse the meta content of a "disabled-adaptations" tag as an OptionSet of disabled adaptation types. The string is parsed by first splitting on the comma character, and then iterating over lower case, whitespace-stripped tokens to look for known adaptation names. So far, only extra zoom mode is supported. * testing/Internals.cpp: (WebCore::Internals::extraZoomModeAdaptationName const): * testing/Internals.h: * testing/Internals.idl: Expose the extra zoom mode adaptation name to the DOM, only when running layout tests. Source/WebKit: Adds a new experimental feature for the "disabled-adaptations" meta tag, and adds plumbing in WebKit to propagate disabled adaptation changes to the ViewportConfiguration. The experimental feature is on by default in extra zoom mode. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::dispatchDisabledAdaptationsDidChange const): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::disabledAdaptationsDidChange): * WebProcess/WebPage/WebPage.h: Source/WebKitLegacy/ios: Adds a WebKitLegacy method stub for disabled adaptation plumbing. * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::dispatchDisabledAdaptationsDidChange const): LayoutTests: Refactor an existing layout test to exercise disabled adaptations in extra zoom mode. * fast/viewport/extrazoom/viewport-change-min-device-width.html: Removed. * fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html: Added. Canonical link: https://commits.webkit.org/201100@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231779 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-15 01:07:36 +00:00
bool shouldOverrideDeviceWidthAndShrinkToFit() const;
[Extra zoom mode] 100vw is roughly half of the viewport width in extra zoom mode https://bugs.webkit.org/show_bug.cgi?id=184871 <rdar://problem/39477595> Reviewed by Andy Estes. Source/WebCore: Currently, when computing CSS viewport units, we use ViewportConfiguration::initialScaleIgnoringContentSize(). This method computes an initial scale from the layout width and height without relying on any information derived from the current content size. This is done to ensure that the content size and viewport dimensions for CSS viewport units should not be simultaneously dependent on each other. Since shrink-to-fit heuristics depend on content size, we currently assume that shrink-to-fit is disabled when computing initialScaleIgnoringContentSize, by always passing in `false` for `shouldIgnoreScalingConstraints`. However, in extra zoom mode, the opposite is true: since we force both `m_canIgnoreScalingConstraints` and `m_forceHorizontalShrinkToFit` to be `true` in this mode, we will always try to shrink-to-fit regardless of content size. Because of this shrink-to-fit disparity between `initialScale` and `initialScaleIgnoringContentSize`, viewport units in extra zoom mode are currently computed assuming an initial scale set by the page, whereas the real viewport is scaled to fit, which causes any lengths computed in terms of vw and vh to be incorrect. To fix this, we introduce a version of shouldIgnoreScalingConstraints() that returns `true` iff scaling constraints are always ignored, regardless of content size. We then use this in initialScaleIgnoringContentSize, instead of always passing in `false` for `shouldIgnoreScalingConstraints`. Test: fast/css/extrazoom/viewport-units-shrink-to-fit.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::shouldIgnoreScalingConstraintsRegardlessOfContentSize const): (WebCore::ViewportConfiguration::initialScaleIgnoringContentSize const): * page/ViewportConfiguration.h: LayoutTests: Add a new layout test to verify that shrink-to-fit works as intended in extra zoom mode: 1. The large element should cause the entire viewport to shrink down to fit. 2. Removing the large element should adjust the viewport, such that the smaller element now fits the entire viewport. 3. The smaller element (at 100vw and 100vh) should be the same size as the window. * TestExpectations: * fast/css/extrazoom/viewport-units-shrink-to-fit-expected.txt: Added. * fast/css/extrazoom/viewport-units-shrink-to-fit.html: Added. Canonical link: https://commits.webkit.org/200392@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230916 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-23 19:40:26 +00:00
bool shouldIgnoreScalingConstraintsRegardlessOfContentSize() const;
Make it possible to zoom on pages that claim to lay out to device size and then fail to do so https://bugs.webkit.org/show_bug.cgi?id=142549 Reviewed by Simon Fraser. * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::ViewportConfiguration): Rename m_ignoreScalingConstraints to m_canIgnoreScalingConstraints, because it being true does not guarantee that we will ignore scaling constraints, but it being false does guarantee that we won't. (WebCore::ViewportConfiguration::shouldIgnoreScalingConstraints): Ignore scaling constraints if the page: a) claimed to want to lay out to device-width and then laid out too wide b) claimed to want to lay out to device-height and then laid out too tall c) claimed to want to lay out with initialScale=1 and then laid out too wide (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::allowsUserScaling): Call shouldIgnoreScalingConstraints() instead of looking at the local, so we can have some more logic here (as above). (WebCore::ViewportConfiguration::description): Dump whether we're ignoring scaling constraints. (WebCore::ViewportConfiguration::dump): Use WTFLogAlways so that the output goes to various other logging mechanisms instead of just stderr. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::setCanIgnoreScalingConstraints): (WebCore::ViewportConfiguration::setIgnoreScalingConstraints): Deleted. * Shared/WebPreferencesDefinitions.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::updatePreferences): Flip the pref on by default. Canonical link: https://commits.webkit.org/160621@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@181400 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-03-11 19:16:20 +00:00
bool shouldIgnoreScalingConstraints() const;
Sites that use a device-width viewport but don't have enough height to fill the view are scaled up https://bugs.webkit.org/show_bug.cgi?id=142664 <rdar://problem/18859470> Reviewed by Benjamin Poulain. * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::shouldIgnoreHorizontalScalingConstraints): (WebCore::ViewportConfiguration::shouldIgnoreVerticalScalingConstraints): (WebCore::ViewportConfiguration::shouldIgnoreScalingConstraints): Split shouldIgnoreScalingConstraints into one for each dimension. (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): Don't force the initial and minimum scales to cover the whole view if the page claims to want to lay out to device width but then lays out too big. This will allow pages that misbehave in this way to scale down further than they previously could, but will result in a region of empty background color being exposed at the initial/minimum scale. (WebCore::ViewportConfiguration::description): Update the logging to show each dimension separately. * page/ViewportConfiguration.h: * UIProcess/ios/WKScrollView.mm: (-[WKScrollView _rubberBandOffsetForOffset:maxOffset:minOffset:range:outside:]): Now that the WKContentView can (without pinching) be smaller than the unobscured region of the WKWebView, we need to take that into account when deciding where to retarget scrolling. Canonical link: https://commits.webkit.org/160692@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@181488 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-03-13 21:07:06 +00:00
bool shouldIgnoreVerticalScalingConstraints() const;
bool shouldIgnoreHorizontalScalingConstraints() const;
We should ignore minimumEffectiveDeviceWidth if the page specifies device-width in viewport meta-tag. https://bugs.webkit.org/show_bug.cgi?id=192377 <rdar://problem/46364206> Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2018-12-06 Reviewed by Tim Horton. Source/WebCore: If the page specifies width=device-width or initial-scale=1 in the viewport meta tag, we should use the native device width and ignore the minimum effective device width in ViewportConfiguration. The patch also introduces scalableNativeWebpageParameters() which uses the device width as default and also allows the page to shrink-to-fit. If a page doesn't have viewport meta tag, or if the width argument isn't device-width and the initial scale isn't 1, we will use scalableNativeWebpageParameters() as the default configuration. Tests: fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width.html fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::updateDefaultConfiguration): pick the default configuration based on the page's viewport arguments. Also, we will always fall back to scalableNativeWebpageParameters() if we can ignore scaling constraints. (WebCore::ViewportConfiguration::setViewportArguments): When page sends us new ViewportArguments, pick up the correponsding default configuration before updating the configuration. (WebCore::ViewportConfiguration::setCanIgnoreScalingConstraints): When m_canIgnoreScalingConstraints is changed, try to pick up the correponsding default configuration. (WebCore::ViewportConfiguration::scalableNativeWebpageParameters): Add a new default set of viewport Parameters this is very close to nativeWebpageParameters() excpet that it allows shrink to fit and its minimum scale is 0.25. We will use this Parameters for pages that doesn't have viewport meta tag; or the width is not device-width and initial scale is not 1. (WebCore::ViewportConfiguration::updateConfiguration): If the page's viewport argument doesn't override the default width, use the m_minimumLayoutSize.width(). * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): A helper method to tell if we should avoid using minimum effective device width. (WebCore::ViewportConfiguration::canOverrideConfigurationParameters const): If we are using a default configuration that is neither nativeWebpageParameters() nor scalableNativeWebpageParameters(), don't override it. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add a helper method to return minimum effective device width based on shouldIgnoreMinimumEffectiveDeviceWidth(). (WebCore::ViewportConfiguration::effectiveLayoutSizeScaleFactor const): Use minimumEffectiveDeviceWidth(). Source/WebKit: Since we are using page's viewport arguments to decide the default viewport parameters and whether we can use mininum effective device width, we should always call setViewportArguments() regardless of shouldIgnoreMetaViewport settings. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::viewportPropertiesDidChange): Always call setViewportArguments(). (WebKit::WebPage::didCommitLoad): Ditto. LayoutTests: * fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width-expected.txt: Added. * fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width.html: Added. * fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta-expected.txt: Added. * fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta.html: Added. Canonical link: https://commits.webkit.org/207070@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238946 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-12-07 01:35:25 +00:00
void updateDefaultConfiguration();
bool canOverrideConfigurationParameters() const;
[iPadOS] Unable to increase zoom level on Google using the Aa menu https://bugs.webkit.org/show_bug.cgi?id=200453 <rdar://problem/52278579> Reviewed by Tim Horton. Source/WebCore: Makes a couple of minor adjustments to how layout size scale factor is handled in ViewportConfiguration, to address some scenarios in which adjusting WKWebView's _viewScale does not have any apparent effect on the page. See changes below for more detail. Tests: fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): When the page is either zoomed in or zoomed out using _viewScale, let the specified initial scale take precedence over the scale computed by fitting the content width to the view width, or the scale computed by fitting the content height to the view height. This avoids a scenario in which nothing happens when increasing view scale in a responsively designed web page that has a fixed minimum width. Before this change, when computing the initial scale at a view scale that would not allow the entire content width of the page to fit within the viewport, the new initial scale would remain unchanged if the initial scale in the meta viewport is not also set to 1, because a new initial scale would be computed in ViewportConfiguration::initialScaleFromSize to accomodate for the entire content width. Our new behavior allows us to zoom into the page, even if doing so would cause horizontal scrolling. (WebCore::ViewportConfiguration::updateConfiguration): When the page is either zoomed in or zoomed out using _viewScale and the default viewport configuration has a fixed width (e.g. on iPhone), then adjust the width of the default viewport configuration to account for the _viewScale. For example, the default width of a viewport-less web page is 980px on iPhone; at a view scale of 2, this would become 490px instead, and at 0.5 view scale, it would become 1960px. This ensures that on iPhone, for web pages without a meta viewport, changing the view scale still changes the layout and initial scale of the web page. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::layoutSizeIsExplicitlyScaled const): LayoutTests: Adds a couple of layout tests (with device-specific expectations) to verify that the two scenarios targeted by this change are fixed. * fast/viewport/ios/non-responsive-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html: Added. Verifies that, for a page with no viewport meta tag (where we fall back to a fixed 980px viewport on iPhone), changing view scale still changes page scale and window size. * fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html: Added. Verifies that, for a page with a responsive meta viewport tag containing a fixed-width element that forces a minimum width for the page, setting the view scale such that the page scrolls horizontally (2.5) doesn't result in the initial scale being adjusted back to the maximum scale that would accomodate the full contents of the page (2). * platform/ipad/fast/viewport/ios/non-responsive-viewport-after-changing-view-scale-expected.txt: Added. * platform/ipad/fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale-expected.txt: Added. Canonical link: https://commits.webkit.org/214230@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248292 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-08-06 14:49:25 +00:00
constexpr bool layoutSizeIsExplicitlyScaled() const
{
return m_layoutSizeScaleFactor != 1;
}
[iOS] Changing view scale sometimes does not zoom the page to the new initial scale when the page is zoomed in when ignoring meta viewport https://bugs.webkit.org/show_bug.cgi?id=191226 <rdar://problem/45781765> Reviewed by Tim Horton. Source/WebCore: When `_setViewScale:` SPI is used to adjust the layout scale factor of the page, we multiply minimum, initial and maximum scales by the given layout scale factor to adjust for a larger or smaller minimum layout size. However, in the case where the layout size scale factor is greater than 1 and we're also forcing the viewport to be scalable, we override the default minimum scale with 1 (i.e. `forceAlwaysUserScalableMinimumScale`). This means that the might be off by a small margin due to rounding error when computing the content width and view width (see: r237743). This means that in the case where (1) the viewport is forced to be user-scalable, and (2) we're ignoring meta viewport parameters, and (3) `_viewScale` exceeds 1, we may end up computing a slightly different minimum scale than the default minimum scale multiplied by the layout size scale factor; subsequently, the page scale factor will be slightly different from initial scale, such that we'll no longer zoom to the new initial scale when changing view scale. This patch adjusts `forceAlwaysUserScalableMinimumScale` and `forceAlwaysUserScalableMaximumScale` to take the current layout scale factor into account when computing min and max scales when the viewport is forced to be always scalable. Test: fast/viewport/ios/minimum-scale-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::minimumScale const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::maximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMaximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMinimumScale const): Turn these from constant values to const functions on ViewportConfiguration, which factor in the current viewport layout size scale factor. Tools: Add a missing check for `shouldIgnoreMetaViewport` when comparing TestOptions, to ensure that "ignore meta viewport" state doesn't unexpectedly persist after running a layout test that ignores meta viewport. * WebKitTestRunner/TestOptions.h: (WTR::TestOptions::hasSameInitializationOptions const): LayoutTests: Add a new layout test that sets the view scale to several values greater than or equal to 1 and verifies that the minimum scale and resulting scroll view scale are exactly the same as the view scale, when (1) the "ignores meta viewport" preference is enabled, and (2) the viewport is forced to be always scalable. * fast/viewport/ios/minimum-scale-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/minimum-scale-after-changing-view-scale.html: Added. Canonical link: https://commits.webkit.org/206072@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237818 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-05 19:12:38 +00:00
constexpr double forceAlwaysUserScalableMaximumScale() const
{
const double forceAlwaysUserScalableMaximumScaleIgnoringLayoutScaleFactor = 5;
Allow WebKit clients to specify a minimum effective width for layout. https://bugs.webkit.org/show_bug.cgi?id=191499 <rdar://problem/45362678> Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2018-11-28 Reviewed by Wenson Hsieh. Source/WebCore: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. Tests: fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setViewLayoutSize): Add a new argument effectiveWidth. (WebCore::ViewportConfiguration::nativeWebpageParameters): Make sure minimumScale for nativeWebpageParameters is small enough so that it won't clamp out the initial scale. If content is wider than the viewport, this ensures we can still zoom out the page. (WebCore::ViewportConfiguration::updateConfiguration): update _minimumEffectiveDeviceWidth and apply that to the layout size scale computation. (WebCore::ViewportConfiguration::effectiveLayoutSizeScaleFactor): A helper method to return the effective layout scale factor which is also effected by _minimumEffectiveDeviceWidth. (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Update m_minimumLayoutSize based on effectiveLayoutSizeScaleFactor(). (WebCore::ViewportConfiguration::description const): Also dump m_minimumEffectiveDeviceWidth. * page/ViewportConfiguration.h: Add a member variable m_minimumEffectiveDeviceWidth. Source/WebKit: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. * UIProcess/API/Cocoa/WKWebView.mm: Add an iVar _minimumEffectiveDeviceWidth. (-[WKWebView _dispatchSetViewLayoutSize:]): Call the new setViewportConfigurationViewLayoutSize method. (-[WKWebView _setViewScale:]): Ditto. (-[WKWebView _setMinimumEffectiveWidth:]): The setter for _minimumEffectiveDeviceWidth. (-[WKWebView _minimumEffectiveWidth]): Getter for _minimumEffectiveDeviceWidth * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add a property _minimumEffectiveDeviceWidth to WKWebView. * UIProcess/WebPageProxy.h: Change setViewportConfigurationViewLayoutSize to take another argument minimumEffectiveDeviceWidth. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): Also send effectiveWidth to WebContent process. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): Set the initial effective width to 0 when creating a web page, this tells ViewportConfiguration to ignore the minimum effective width value. * WebProcess/WebPage/WebPage.h: Change setViewportConfigurationViewLayoutSize to take another argument effectiveWidth. * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Also pass effectiveWidth value to ViewportConfiguration. Tools: Allow UIScriptController to set WKWebView's minimum effective width with a new `setMinimumEffectiveWidth` method. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::setViewScale): (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::cocoaResetStateToConsistentValues): LayoutTests: Add two new tests. The first test verifies if we ignore meta viewport, setting a different effective width value will change the layout width of the page. The second test verifies if we don't ignore meta viewport, we will always respect that (980pt) and setting a different effective width value won't change the layout width. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html: Added. * resources/ui-helper.js: (window.UIHelper.setMinimumEffectiveWidth): Add a helper method to set the minimum effective width from a test. (window.UIHelper): Canonical link: https://commits.webkit.org/206776@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238623 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-28 18:50:23 +00:00
return forceAlwaysUserScalableMaximumScaleIgnoringLayoutScaleFactor * effectiveLayoutSizeScaleFactor();
[iOS] Changing view scale sometimes does not zoom the page to the new initial scale when the page is zoomed in when ignoring meta viewport https://bugs.webkit.org/show_bug.cgi?id=191226 <rdar://problem/45781765> Reviewed by Tim Horton. Source/WebCore: When `_setViewScale:` SPI is used to adjust the layout scale factor of the page, we multiply minimum, initial and maximum scales by the given layout scale factor to adjust for a larger or smaller minimum layout size. However, in the case where the layout size scale factor is greater than 1 and we're also forcing the viewport to be scalable, we override the default minimum scale with 1 (i.e. `forceAlwaysUserScalableMinimumScale`). This means that the might be off by a small margin due to rounding error when computing the content width and view width (see: r237743). This means that in the case where (1) the viewport is forced to be user-scalable, and (2) we're ignoring meta viewport parameters, and (3) `_viewScale` exceeds 1, we may end up computing a slightly different minimum scale than the default minimum scale multiplied by the layout size scale factor; subsequently, the page scale factor will be slightly different from initial scale, such that we'll no longer zoom to the new initial scale when changing view scale. This patch adjusts `forceAlwaysUserScalableMinimumScale` and `forceAlwaysUserScalableMaximumScale` to take the current layout scale factor into account when computing min and max scales when the viewport is forced to be always scalable. Test: fast/viewport/ios/minimum-scale-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::minimumScale const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::maximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMaximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMinimumScale const): Turn these from constant values to const functions on ViewportConfiguration, which factor in the current viewport layout size scale factor. Tools: Add a missing check for `shouldIgnoreMetaViewport` when comparing TestOptions, to ensure that "ignore meta viewport" state doesn't unexpectedly persist after running a layout test that ignores meta viewport. * WebKitTestRunner/TestOptions.h: (WTR::TestOptions::hasSameInitializationOptions const): LayoutTests: Add a new layout test that sets the view scale to several values greater than or equal to 1 and verifies that the minimum scale and resulting scroll view scale are exactly the same as the view scale, when (1) the "ignores meta viewport" preference is enabled, and (2) the viewport is forced to be always scalable. * fast/viewport/ios/minimum-scale-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/minimum-scale-after-changing-view-scale.html: Added. Canonical link: https://commits.webkit.org/206072@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237818 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-05 19:12:38 +00:00
}
constexpr double forceAlwaysUserScalableMinimumScale() const
{
const double forceAlwaysUserScalableMinimumScaleIgnoringLayoutScaleFactor = 1;
Allow WebKit clients to specify a minimum effective width for layout. https://bugs.webkit.org/show_bug.cgi?id=191499 <rdar://problem/45362678> Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2018-11-28 Reviewed by Wenson Hsieh. Source/WebCore: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. Tests: fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setViewLayoutSize): Add a new argument effectiveWidth. (WebCore::ViewportConfiguration::nativeWebpageParameters): Make sure minimumScale for nativeWebpageParameters is small enough so that it won't clamp out the initial scale. If content is wider than the viewport, this ensures we can still zoom out the page. (WebCore::ViewportConfiguration::updateConfiguration): update _minimumEffectiveDeviceWidth and apply that to the layout size scale computation. (WebCore::ViewportConfiguration::effectiveLayoutSizeScaleFactor): A helper method to return the effective layout scale factor which is also effected by _minimumEffectiveDeviceWidth. (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Update m_minimumLayoutSize based on effectiveLayoutSizeScaleFactor(). (WebCore::ViewportConfiguration::description const): Also dump m_minimumEffectiveDeviceWidth. * page/ViewportConfiguration.h: Add a member variable m_minimumEffectiveDeviceWidth. Source/WebKit: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. * UIProcess/API/Cocoa/WKWebView.mm: Add an iVar _minimumEffectiveDeviceWidth. (-[WKWebView _dispatchSetViewLayoutSize:]): Call the new setViewportConfigurationViewLayoutSize method. (-[WKWebView _setViewScale:]): Ditto. (-[WKWebView _setMinimumEffectiveWidth:]): The setter for _minimumEffectiveDeviceWidth. (-[WKWebView _minimumEffectiveWidth]): Getter for _minimumEffectiveDeviceWidth * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add a property _minimumEffectiveDeviceWidth to WKWebView. * UIProcess/WebPageProxy.h: Change setViewportConfigurationViewLayoutSize to take another argument minimumEffectiveDeviceWidth. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): Also send effectiveWidth to WebContent process. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): Set the initial effective width to 0 when creating a web page, this tells ViewportConfiguration to ignore the minimum effective width value. * WebProcess/WebPage/WebPage.h: Change setViewportConfigurationViewLayoutSize to take another argument effectiveWidth. * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Also pass effectiveWidth value to ViewportConfiguration. Tools: Allow UIScriptController to set WKWebView's minimum effective width with a new `setMinimumEffectiveWidth` method. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::setViewScale): (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::cocoaResetStateToConsistentValues): LayoutTests: Add two new tests. The first test verifies if we ignore meta viewport, setting a different effective width value will change the layout width of the page. The second test verifies if we don't ignore meta viewport, we will always respect that (980pt) and setting a different effective width value won't change the layout width. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html: Added. * resources/ui-helper.js: (window.UIHelper.setMinimumEffectiveWidth): Add a helper method to set the minimum effective width from a test. (window.UIHelper): Canonical link: https://commits.webkit.org/206776@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238623 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-28 18:50:23 +00:00
return forceAlwaysUserScalableMinimumScaleIgnoringLayoutScaleFactor * effectiveLayoutSizeScaleFactor();
}
constexpr double effectiveLayoutSizeScaleFactor() const
{
We should ignore minimumEffectiveDeviceWidth if the page specifies device-width in viewport meta-tag. https://bugs.webkit.org/show_bug.cgi?id=192377 <rdar://problem/46364206> Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2018-12-06 Reviewed by Tim Horton. Source/WebCore: If the page specifies width=device-width or initial-scale=1 in the viewport meta tag, we should use the native device width and ignore the minimum effective device width in ViewportConfiguration. The patch also introduces scalableNativeWebpageParameters() which uses the device width as default and also allows the page to shrink-to-fit. If a page doesn't have viewport meta tag, or if the width argument isn't device-width and the initial scale isn't 1, we will use scalableNativeWebpageParameters() as the default configuration. Tests: fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width.html fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::updateDefaultConfiguration): pick the default configuration based on the page's viewport arguments. Also, we will always fall back to scalableNativeWebpageParameters() if we can ignore scaling constraints. (WebCore::ViewportConfiguration::setViewportArguments): When page sends us new ViewportArguments, pick up the correponsding default configuration before updating the configuration. (WebCore::ViewportConfiguration::setCanIgnoreScalingConstraints): When m_canIgnoreScalingConstraints is changed, try to pick up the correponsding default configuration. (WebCore::ViewportConfiguration::scalableNativeWebpageParameters): Add a new default set of viewport Parameters this is very close to nativeWebpageParameters() excpet that it allows shrink to fit and its minimum scale is 0.25. We will use this Parameters for pages that doesn't have viewport meta tag; or the width is not device-width and initial scale is not 1. (WebCore::ViewportConfiguration::updateConfiguration): If the page's viewport argument doesn't override the default width, use the m_minimumLayoutSize.width(). * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): A helper method to tell if we should avoid using minimum effective device width. (WebCore::ViewportConfiguration::canOverrideConfigurationParameters const): If we are using a default configuration that is neither nativeWebpageParameters() nor scalableNativeWebpageParameters(), don't override it. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add a helper method to return minimum effective device width based on shouldIgnoreMinimumEffectiveDeviceWidth(). (WebCore::ViewportConfiguration::effectiveLayoutSizeScaleFactor const): Use minimumEffectiveDeviceWidth(). Source/WebKit: Since we are using page's viewport arguments to decide the default viewport parameters and whether we can use mininum effective device width, we should always call setViewportArguments() regardless of shouldIgnoreMetaViewport settings. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::viewportPropertiesDidChange): Always call setViewportArguments(). (WebKit::WebPage::didCommitLoad): Ditto. LayoutTests: * fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width-expected.txt: Added. * fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width.html: Added. * fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta-expected.txt: Added. * fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta.html: Added. Canonical link: https://commits.webkit.org/207070@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238946 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-12-07 01:35:25 +00:00
if (!m_viewLayoutSize.width() || !minimumEffectiveDeviceWidth())
Allow WebKit clients to specify a minimum effective width for layout. https://bugs.webkit.org/show_bug.cgi?id=191499 <rdar://problem/45362678> Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2018-11-28 Reviewed by Wenson Hsieh. Source/WebCore: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. Tests: fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setViewLayoutSize): Add a new argument effectiveWidth. (WebCore::ViewportConfiguration::nativeWebpageParameters): Make sure minimumScale for nativeWebpageParameters is small enough so that it won't clamp out the initial scale. If content is wider than the viewport, this ensures we can still zoom out the page. (WebCore::ViewportConfiguration::updateConfiguration): update _minimumEffectiveDeviceWidth and apply that to the layout size scale computation. (WebCore::ViewportConfiguration::effectiveLayoutSizeScaleFactor): A helper method to return the effective layout scale factor which is also effected by _minimumEffectiveDeviceWidth. (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Update m_minimumLayoutSize based on effectiveLayoutSizeScaleFactor(). (WebCore::ViewportConfiguration::description const): Also dump m_minimumEffectiveDeviceWidth. * page/ViewportConfiguration.h: Add a member variable m_minimumEffectiveDeviceWidth. Source/WebKit: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. * UIProcess/API/Cocoa/WKWebView.mm: Add an iVar _minimumEffectiveDeviceWidth. (-[WKWebView _dispatchSetViewLayoutSize:]): Call the new setViewportConfigurationViewLayoutSize method. (-[WKWebView _setViewScale:]): Ditto. (-[WKWebView _setMinimumEffectiveWidth:]): The setter for _minimumEffectiveDeviceWidth. (-[WKWebView _minimumEffectiveWidth]): Getter for _minimumEffectiveDeviceWidth * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add a property _minimumEffectiveDeviceWidth to WKWebView. * UIProcess/WebPageProxy.h: Change setViewportConfigurationViewLayoutSize to take another argument minimumEffectiveDeviceWidth. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): Also send effectiveWidth to WebContent process. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): Set the initial effective width to 0 when creating a web page, this tells ViewportConfiguration to ignore the minimum effective width value. * WebProcess/WebPage/WebPage.h: Change setViewportConfigurationViewLayoutSize to take another argument effectiveWidth. * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Also pass effectiveWidth value to ViewportConfiguration. Tools: Allow UIScriptController to set WKWebView's minimum effective width with a new `setMinimumEffectiveWidth` method. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::setViewScale): (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::cocoaResetStateToConsistentValues): LayoutTests: Add two new tests. The first test verifies if we ignore meta viewport, setting a different effective width value will change the layout width of the page. The second test verifies if we don't ignore meta viewport, we will always respect that (980pt) and setting a different effective width value won't change the layout width. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html: Added. * resources/ui-helper.js: (window.UIHelper.setMinimumEffectiveWidth): Add a helper method to set the minimum effective width from a test. (window.UIHelper): Canonical link: https://commits.webkit.org/206776@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238623 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-28 18:50:23 +00:00
return m_layoutSizeScaleFactor;
We should ignore minimumEffectiveDeviceWidth if the page specifies device-width in viewport meta-tag. https://bugs.webkit.org/show_bug.cgi?id=192377 <rdar://problem/46364206> Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2018-12-06 Reviewed by Tim Horton. Source/WebCore: If the page specifies width=device-width or initial-scale=1 in the viewport meta tag, we should use the native device width and ignore the minimum effective device width in ViewportConfiguration. The patch also introduces scalableNativeWebpageParameters() which uses the device width as default and also allows the page to shrink-to-fit. If a page doesn't have viewport meta tag, or if the width argument isn't device-width and the initial scale isn't 1, we will use scalableNativeWebpageParameters() as the default configuration. Tests: fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width.html fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::updateDefaultConfiguration): pick the default configuration based on the page's viewport arguments. Also, we will always fall back to scalableNativeWebpageParameters() if we can ignore scaling constraints. (WebCore::ViewportConfiguration::setViewportArguments): When page sends us new ViewportArguments, pick up the correponsding default configuration before updating the configuration. (WebCore::ViewportConfiguration::setCanIgnoreScalingConstraints): When m_canIgnoreScalingConstraints is changed, try to pick up the correponsding default configuration. (WebCore::ViewportConfiguration::scalableNativeWebpageParameters): Add a new default set of viewport Parameters this is very close to nativeWebpageParameters() excpet that it allows shrink to fit and its minimum scale is 0.25. We will use this Parameters for pages that doesn't have viewport meta tag; or the width is not device-width and initial scale is not 1. (WebCore::ViewportConfiguration::updateConfiguration): If the page's viewport argument doesn't override the default width, use the m_minimumLayoutSize.width(). * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): A helper method to tell if we should avoid using minimum effective device width. (WebCore::ViewportConfiguration::canOverrideConfigurationParameters const): If we are using a default configuration that is neither nativeWebpageParameters() nor scalableNativeWebpageParameters(), don't override it. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add a helper method to return minimum effective device width based on shouldIgnoreMinimumEffectiveDeviceWidth(). (WebCore::ViewportConfiguration::effectiveLayoutSizeScaleFactor const): Use minimumEffectiveDeviceWidth(). Source/WebKit: Since we are using page's viewport arguments to decide the default viewport parameters and whether we can use mininum effective device width, we should always call setViewportArguments() regardless of shouldIgnoreMetaViewport settings. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::viewportPropertiesDidChange): Always call setViewportArguments(). (WebKit::WebPage::didCommitLoad): Ditto. LayoutTests: * fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width-expected.txt: Added. * fast/viewport/ios/ignore-minimum-device-width-for-page-with-viewport-device-width.html: Added. * fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta-expected.txt: Added. * fast/viewport/ios/use-minimum-device-width-for-page-without-viewport-meta.html: Added. Canonical link: https://commits.webkit.org/207070@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238946 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-12-07 01:35:25 +00:00
return m_layoutSizeScaleFactor * m_viewLayoutSize.width() / std::max<double>(minimumEffectiveDeviceWidth(), m_viewLayoutSize.width());
[iOS] Changing view scale sometimes does not zoom the page to the new initial scale when the page is zoomed in when ignoring meta viewport https://bugs.webkit.org/show_bug.cgi?id=191226 <rdar://problem/45781765> Reviewed by Tim Horton. Source/WebCore: When `_setViewScale:` SPI is used to adjust the layout scale factor of the page, we multiply minimum, initial and maximum scales by the given layout scale factor to adjust for a larger or smaller minimum layout size. However, in the case where the layout size scale factor is greater than 1 and we're also forcing the viewport to be scalable, we override the default minimum scale with 1 (i.e. `forceAlwaysUserScalableMinimumScale`). This means that the might be off by a small margin due to rounding error when computing the content width and view width (see: r237743). This means that in the case where (1) the viewport is forced to be user-scalable, and (2) we're ignoring meta viewport parameters, and (3) `_viewScale` exceeds 1, we may end up computing a slightly different minimum scale than the default minimum scale multiplied by the layout size scale factor; subsequently, the page scale factor will be slightly different from initial scale, such that we'll no longer zoom to the new initial scale when changing view scale. This patch adjusts `forceAlwaysUserScalableMinimumScale` and `forceAlwaysUserScalableMaximumScale` to take the current layout scale factor into account when computing min and max scales when the viewport is forced to be always scalable. Test: fast/viewport/ios/minimum-scale-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::minimumScale const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::maximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMaximumScale const): (WebCore::ViewportConfiguration::forceAlwaysUserScalableMinimumScale const): Turn these from constant values to const functions on ViewportConfiguration, which factor in the current viewport layout size scale factor. Tools: Add a missing check for `shouldIgnoreMetaViewport` when comparing TestOptions, to ensure that "ignore meta viewport" state doesn't unexpectedly persist after running a layout test that ignores meta viewport. * WebKitTestRunner/TestOptions.h: (WTR::TestOptions::hasSameInitializationOptions const): LayoutTests: Add a new layout test that sets the view scale to several values greater than or equal to 1 and verifies that the minimum scale and resulting scroll view scale are exactly the same as the view scale, when (1) the "ignores meta viewport" preference is enabled, and (2) the viewport is forced to be always scalable. * fast/viewport/ios/minimum-scale-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/minimum-scale-after-changing-view-scale.html: Added. Canonical link: https://commits.webkit.org/206072@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237818 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-05 19:12:38 +00:00
}
[Extra zoom mode] Add a mechanism to override default viewport behaviors in extra zoom mode https://bugs.webkit.org/show_bug.cgi?id=185050 <rdar://problem/39624038> Reviewed by Tim Horton. Source/WebCore: Currently, in extra zoom mode, there's no way for web pages to opt out of the default viewport behaviors (namely, laying out at a larger width and shrinking to fit) when the web view is very tall and narrow. This patch adds a new experimental viewport attribute, "min-device-width", that can be used to prevent WebKit from automatically clamping the web view width to a greater value for the device width in this scenario. Note that after this patch, logic that plumbs a minimumLayoutSize from WKWebView to the viewport configuration will need to be renamed to reflect that this size is no longer the minimum layout size, but rather, the view size that is used for viewport device dimensions by default. This refactoring will be done in a followup part. See per-method comments below for more detail. Test: fast/viewport/extrazoom/viewport-change-min-device-width.html * dom/ViewportArguments.cpp: (WebCore::setViewportFeature): (WebCore::operator<<): * dom/ViewportArguments.h: Removes `m_forceHorizontalShrinkToFit` (more detail below). * page/ViewportConfiguration.cpp: (WebCore::computedMinDeviceWidth): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setMinimumLayoutSize): Instead of directly setting the minimum layout size, setMinimumLayoutSize now first sets the view size (i.e. the size we use for `device-width` in the viewport meta tag), and then updates the minimum layout size. (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthWithMinDeviceWidth const): Replaces `m_forceHorizontalShrinkToFit`. Whether or not we shrink to fit is now determined by whether the min-device-width attribute is actively clamping the width of the view. (WebCore::ViewportConfiguration::shouldIgnoreHorizontalScalingConstraints const): (WebCore::ViewportConfiguration::shouldIgnoreScalingConstraintsRegardlessOfContentSize const): (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Computes and sets the minimum layout size using the view size, taking the minimum device width into account if needed. (WebCore::ViewportConfiguration::description const): (WebCore::ViewportConfiguration::setForceHorizontalShrinkToFit): Deleted. * page/ViewportConfiguration.h: Source/WebKit: Remove the forceHorizontalViewportShrinkToFit and minimumAllowedLayoutWidth SPI hooks from WebKit, and additionally remove all logic for plumbing viewSize to WebCore. See WebCore/ChangeLog for more information. * Shared/VisibleContentRectUpdateInfo.cpp: (WebKit::VisibleContentRectUpdateInfo::encode const): (WebKit::VisibleContentRectUpdateInfo::decode): (WebKit::operator<<): * Shared/VisibleContentRectUpdateInfo.h: (WebKit::VisibleContentRectUpdateInfo::VisibleContentRectUpdateInfo): (WebKit::VisibleContentRectUpdateInfo::allowShrinkToFit const): (WebKit::operator==): (WebKit::VisibleContentRectUpdateInfo::forceHorizontalShrinkToFit const): Deleted. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): (-[WKWebView activeMinimumLayoutSize:]): (-[WKWebView _dispatchSetMinimumLayoutSize:]): (-[WKWebView _frameOrBoundsChanged]): (-[WKWebView _setMinimumLayoutSizeOverride:]): (-[WKWebView _beginAnimatedResizeWithUpdates:]): (-[WKWebView _endAnimatedResize]): (-[WKWebView _minimumAllowedLayoutWidth]): Deleted. (-[WKWebView _setMinimumAllowedLayoutWidth:]): Deleted. (-[WKWebView activeMinimumLayoutSizes:]): Deleted. (-[WKWebView _dispatchSetMinimumLayoutSize:viewSize:]): Deleted. (-[WKWebView _setForceHorizontalViewportShrinkToFit:]): Deleted. (-[WKWebView _forceHorizontalViewportShrinkToFit]): Deleted. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView didUpdateVisibleRect:unobscuredRect:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::dynamicViewportSizeUpdate): (WebKit::WebPageProxy::setViewportConfigurationMinimumLayoutSize): * WebProcess/WebPage/WebPage.cpp: (WebKit::m_credentialsMessenger): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::updateVisibleContentRects): Tools: Remove a test that's no longer useful, now that the SPI it was testing is gone. This functionality is now tested by the layout test added in this patch. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/ios/ViewportSizingTests.mm: Removed. LayoutTests: Add a new layout test to check that: • By default (with no `min-device-width` override), shrink-to-fit and expanded minimum layout sizes takes effect. • `min-device-width` can be used to bail out of shrink-to-fit and viewport behaviors. • A large `min-device-width` can be used to make extra zoom mode viewport heuristics even more aggressive. * TestExpectations: * fast/viewport/extrazoom/viewport-change-min-device-width.html: Added. * resources/ui-helper.js: (window.UIHelper.zoomScale): (window.UIHelper): Canonical link: https://commits.webkit.org/200561@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231095 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-27 15:35:50 +00:00
void updateMinimumLayoutSize();
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
Parameters m_configuration;
Parameters m_defaultConfiguration;
IntSize m_contentSize;
[iOS][WK2] Fix a few mistakes affecting the initial layout and the initial unobscured rect https://bugs.webkit.org/show_bug.cgi?id=132093 Source/WebCore: Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-04-23 Reviewed by Tim Horton. Change the minimum layout size to float point values to account for size defined on retina displays. The minimum layout size supports half-pixels, the value is rounded later when computing the layout size in document coordinates. * WebCore.exp.in: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::ViewportConfiguration): Setting the initial content size is incorrect. The layout size computation already take into account empty size for the first layout. Setting the content size upfront make the first computation incorrect when the viewport arguments specify the initial scale. (WebCore::ViewportConfiguration::setMinimumLayoutSize): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::minimumLayoutSize): Source/WebKit2: <rdar://problem/16703237> Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-04-23 Reviewed by Tim Horton. The user of WKWebView can setup a size on device pixels, which can add half a point to the minimum layout size. By rounding this up before applying the page scale, we ended up with rounding errors on the layout size and the transitory unobscured content rect. This patch fixes changes the minimal layout size to float point values to reduce the rounding problems. * UIProcess/API/Cocoa/WKWebView.mm: (setViewportConfigurationMinimumLayoutSize): (-[WKWebView _setMinimumLayoutSizeOverrideForMinimalUI:]): (-[WKWebView _beginAnimatedResizeWithUpdates:]): * UIProcess/WebPageProxy.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::dynamicViewportSizeUpdate): (WebKit::WebPageProxy::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPageProxy::setMinimumLayoutSizeForMinimalUI): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): Defaulting the content size to the minimum layout size only works if the initial-scale is 1. ViewportConfiguration knows exactly what to do before the first layout. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPage::setMinimumLayoutSizeForMinimalUI): (WebKit::WebPage::dynamicViewportSizeUpdate): A few fixes here: -setZoomedOutPageScaleFactor() was incorrectly using the initial scale. 99% of the time, initial scale and minimum scale are equal, but the page can specify something different with the viewport meta tag. -Use floating point for manipulating the minimum layout sizes, then round the value. -minimumLayoutSizeInDocumentCoordinate was scaled the wrong way around. (WebKit::WebPage::viewportConfigurationChanged): Canonical link: https://commits.webkit.org/150150@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@167735 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-04-24 02:13:06 +00:00
FloatSize m_minimumLayoutSize;
Rename minimumLayoutSize to viewLayoutSize https://bugs.webkit.org/show_bug.cgi?id=185050 <rdar://problem/39624038> Reviewed by Tim Horton. Source/WebCore: See WebKit/ChangeLog for more information. No change in behavior. * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setViewLayoutSize): Remove a FIXME comment that is addressed by this refactoring. (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthWithMinDeviceWidth const): (WebCore::ViewportConfiguration::initialScaleFromSize const): (WebCore::ViewportConfiguration::minimumScale const): (WebCore::ViewportConfiguration::updateMinimumLayoutSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): Deleted. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::viewSize const): Deleted. Source/WebKit: Renames minimumLayoutSize to viewLayoutSize, since the minimum layout size in ViewportConfiguration is now different from the minimum layout size that is currently pushed down from the UI process (e.g. WKWebView SPI) in the case where `min-device-width` is used to override the minimum layout size. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _processDidExit]): (-[WKWebView activeViewLayoutSize:]): (-[WKWebView _dispatchSetViewLayoutSize:]): (-[WKWebView _frameOrBoundsChanged]): (-[WKWebView _minimumLayoutSizeOverride]): (-[WKWebView _setViewLayoutSizeOverride:]): (-[WKWebView _beginAnimatedResizeWithUpdates:]): (-[WKWebView _endAnimatedResize]): (-[WKWebView _overrideLayoutParametersWithMinimumLayoutSize:maximumUnobscuredSizeOverride:]): (-[WKWebView _clearOverrideLayoutParameters]): (-[WKWebView _minimumLayoutWidth]): (-[WKWebView _setMinimumLayoutWidth:]): (-[WKWebView activeMinimumLayoutSize:]): Deleted. (-[WKWebView _dispatchSetMinimumLayoutSize:]): Deleted. (-[WKWebView _setMinimumLayoutSizeOverride:]): Deleted. (-[WKWebView _overrideLayoutParametersWithMinimumLayoutSize:minimumLayoutSizeForMinimalUI:maximumUnobscuredSizeOverride:]): Deleted. Remove unused SPI that has been deprecated since iOS 9, has a simple drop-in replacement, and no longer has any internal clients. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::setMinimumSizeForAutoLayout): (WebKit::WebViewImpl::minimumSizeForAutoLayout const): (WebKit::WebViewImpl::setIntrinsicContentSize): * UIProcess/DrawingAreaProxy.h: (WebKit::DrawingAreaProxy::viewLayoutSizeDidChange): (WebKit::DrawingAreaProxy::minimumLayoutSizeDidChange): Deleted. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): (WebKit::WebPageProxy::setViewLayoutSize): (WebKit::WebPageProxy::setMinimumLayoutSize): Deleted. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::viewLayoutSize const): (WebKit::WebPageProxy::minimumLayoutSize const): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::dynamicViewportSizeUpdate): (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): (WebKit::WebPageProxy::setViewportConfigurationMinimumLayoutSize): Deleted. * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.h: * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm: (WebKit::TiledCoreAnimationDrawingAreaProxy::viewLayoutSizeDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::didUpdateGeometry): (WebKit::TiledCoreAnimationDrawingAreaProxy::intrinsicContentSizeDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::willSendUpdateGeometry): (WebKit::TiledCoreAnimationDrawingAreaProxy::minimumLayoutSizeDidChange): Deleted. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::transitionToCommittedForNewPage): * WebProcess/WebPage/ViewGestureGeometryCollector.cpp: (WebKit::ViewGestureGeometryCollector::collectGeometryForSmartMagnificationGesture): * WebProcess/WebPage/WebPage.cpp: (WebKit::m_credentialsMessenger): (WebKit::WebPage::setViewLayoutSize): (WebKit::WebPage::setMinimumLayoutSize): Deleted. * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::viewLayoutSize const): (WebKit::WebPage::minimumLayoutSize const): Deleted. * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): Deleted. * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::updateIntrinsicContentSizeIfNeeded): (WebKit::TiledCoreAnimationDrawingArea::updateGeometry): Canonical link: https://commits.webkit.org/200563@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231097 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-27 16:07:19 +00:00
FloatSize m_viewLayoutSize;
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
ViewportArguments m_viewportArguments;
[Extra zoom mode] Google search results are excessively zoomed in https://bugs.webkit.org/show_bug.cgi?id=185347 <rdar://problem/39999778> Reviewed by Tim Horton. Source/WebCore: It turns out that basing minimum layout size and shrink-to-fit behaviors off of the `shrink-to-fit` viewport argument poses compatibility risks with web pages that already specify `shrink-to-fit` to opt out of default viewport shrinking behaviors in 1/3 multitasking mode on iPad. One way to resolve this is to introduce a new viewport meta content attribute to disable viewport heuristics in extra zoom mode. However, combined shrink-to-fit and minimum device width behaviors are difficult to describe using a single backwards-compatible viewport meta content attribute, and the need to suppress the default behavior of `shrink-to-fit=no` if such an attribute is not disabled further muddles our viewport story. After some internal deliberation, we’ve decided to experiment with a new meta tag named "disabled-adaptations". The content of this meta tag is a comma-separated list of adaptation names; if an adaptation name matches a known adaptation type (for instance, extra zoom mode), we disable the class of behaviors used to adapt web content. The first and only known adaptation type is extra zoom mode, which affects `shrink-to-fit` and layout size adjustments. See per-method changes below for more details. Test: fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * dom/Document.cpp: (WebCore::Document::processDisabledAdaptations): * dom/Document.h: (WebCore::Document::disabledAdaptations const): Add disabled adaptations to Document. Changes to disabled adaptations are not propagated if the parsed disabled adaptation types don't change; upon changing adaptation types, notify the client to adjust for the new disabled adaptations (currently, this only affects the viewport configuration). * dom/ViewportArguments.h: * html/HTMLMetaElement.cpp: (WebCore::HTMLMetaElement::process): * html/parser/HTMLPreloadScanner.cpp: (WebCore::TokenPreloadScanner::StartTagScanner::StartTagScanner): (WebCore::TokenPreloadScanner::StartTagScanner::processAttributes): (WebCore::TokenPreloadScanner::StartTagScanner::processAttribute): * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Restore the set of disabled adaptations when restoring a page from the cache. * page/Chrome.cpp: (WebCore::Chrome::dispatchDisabledAdaptationsDidChange const): * page/Chrome.h: * page/ChromeClient.h: Add plumbing for changes to the set of disabled adaptations. * page/DisabledAdaptations.cpp: Added. (WebCore::extraZoomModeAdaptationName): * page/DisabledAdaptations.h: Added. Introduce a header containing a new enum for the extra zoom mode adaptation, as well as a helper function to return the extra zoom mode adaptation name. * page/Page.cpp: (WebCore::Page::disabledAdaptations const): Returns the mainframe's set of adaptations to disable. * page/Page.h: * page/RemoteFrame.h: * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setDisabledAdaptationsMetaTagEnabled): (WebCore::RuntimeEnabledFeatures::disabledAdaptationsMetaTagEnabled const): Add a new runtime feature to gate handling the "disabled-adaptations" meta tag. * page/ViewportConfiguration.cpp: (WebCore::shouldOverrideShrinkToFitArgument): (WebCore::needsUpdateAfterChangingDisabledAdaptations): (WebCore::ViewportConfiguration::setDisabledAdaptations): (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthAndShrinkToFit const): Consult whether or not extra zoom mode adaptations are disabled, instead of the shrink-to-fit attribute value. (WebCore::ViewportConfiguration::updateConfiguration): * page/ViewportConfiguration.h: Add an OptionSet of disabled adaptation types to ViewportConfiguration. Updates to the adaptation type are propagated to the ViewportConfiguration from Document, through the ChromeClient and the client layer (refer to changes in WebKit). Once the OptionSet is changed, we recompute the viewport configuration only if needed by the platform. (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::disabledAdaptations const): * page/WindowFeatures.cpp: (WebCore::parseDisabledAdaptations): * page/WindowFeatures.h: Add a new helper to parse the meta content of a "disabled-adaptations" tag as an OptionSet of disabled adaptation types. The string is parsed by first splitting on the comma character, and then iterating over lower case, whitespace-stripped tokens to look for known adaptation names. So far, only extra zoom mode is supported. * testing/Internals.cpp: (WebCore::Internals::extraZoomModeAdaptationName const): * testing/Internals.h: * testing/Internals.idl: Expose the extra zoom mode adaptation name to the DOM, only when running layout tests. Source/WebKit: Adds a new experimental feature for the "disabled-adaptations" meta tag, and adds plumbing in WebKit to propagate disabled adaptation changes to the ViewportConfiguration. The experimental feature is on by default in extra zoom mode. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::dispatchDisabledAdaptationsDidChange const): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::disabledAdaptationsDidChange): * WebProcess/WebPage/WebPage.h: Source/WebKitLegacy/ios: Adds a WebKitLegacy method stub for disabled adaptation plumbing. * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::dispatchDisabledAdaptationsDidChange const): LayoutTests: Refactor an existing layout test to exercise disabled adaptations in extra zoom mode. * fast/viewport/extrazoom/viewport-change-min-device-width.html: Removed. * fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html: Added. Canonical link: https://commits.webkit.org/201100@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231779 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-15 01:07:36 +00:00
OptionSet<DisabledAdaptations> m_disabledAdaptations;
[iOS] Allow SPI clients to lay out at arbitrarily scaled sizes and scale to fit the view https://bugs.webkit.org/show_bug.cgi?id=190504 <rdar://problem/45117760> Reviewed by Tim Horton. Source/WebCore: Add support in ViewportConfiguration for applying a layout size scale factor to the viewport. See below for more details. Tests: fast/viewport/ios/constant-width-viewport-after-changing-view-scale.html fast/viewport/ios/device-width-viewport-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setViewLayoutSize): The viewport's layout size may now be changed alongside the layout size scale factor. If either of these two variables change, we recompute our minimum layout size and viewport configuration parameters. (WebCore::ViewportConfiguration::shouldIgnoreHorizontalScalingConstraints const): (WebCore::ViewportConfiguration::nativeWebpageParameters): (WebCore::ViewportConfiguration::testingParameters): (WebCore::ViewportConfiguration::updateConfiguration): Multiply the minimum scale, initial scale, and maximum scale by the layout size scale factor. This allows us to keep the document well-proportioned within the viewport, while still laying out at a different layout size. (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Compute the minimum layout size by scaling the default layout size derived from our view's size. (WebCore::ViewportConfiguration::layoutWidth const): (WebCore::ViewportConfiguration::layoutHeight const): * page/ViewportConfiguration.h: Maintain the original initial scale, unaffected by the layout size scale factor. This is used when computing layout width and height to prevent scaling by the layout size scale factor twice when computing layout sizes. (WebCore::ViewportConfiguration::description const): Include the layout size scale factor in ViewportConfiguration's description string. (WebCore::ViewportConfiguration::Parameters::operator== const): (WebCore::operator<<): Source/WebKit: Add support for _setViewScale: and _viewScale on iOS. While similar in concept to macOS, changing this property on iOS uses viewport configurations to change the minimum layout size of the document and apply view scaling. Setting the view scale on iOS to a value `s` multiplies the minimium layout size by a factor `1 / s`, but also multiplies the initial, minimum and maximum scales by a factor of `s`. The net effect of applying this scale causes the page to lay out at a larger width and shrink (or a smaller width and expand) to fit the viewport. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Send `viewportConfigurationLayoutSizeScaleFactor` alongside `viewportConfigurationViewLayoutSize`. (-[WKWebView _dispatchSetViewLayoutSize:]): (-[WKWebView _viewScale]): (-[WKWebView _setViewScale:]): Provide a different implementation of `_setViewScale:` on iOS, by scaling the effective minimum layout size. (See above for more detail). * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add missing API availability annotations for the _viewScale property. * UIProcess/API/mac/WKView.mm: (-[WKView _setViewScale:]): * UIProcess/Cocoa/WebViewImpl.mm: Both -[WKView _setViewScale:] and -[WKWebView _setViewScale:] throw Objective C exceptions upon receiving a bad argument (e.g. scale <= 0). However, logic for throwing this exception is specific to iOS in WKWebView, and handled in WebViewImpl on macOS. To make this less confusing, move the exception throwing code out of !PLATFORM(MAC) in WKWebView, and move the path for raising this exception in WKView on macOS from WebViewImpl to WKView. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::layoutSizeScaleFactor const): Tie the notion of "view scale" on iOS to `layoutSizeScaleFactor`. As its name suggests, this is a scale factor by which we transform the layout size. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): * WebProcess/WebPage/WebPage.cpp: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Plumb the layout size scale factor over to the web process, along with the layout size. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Tools: Teach UIScriptController to set WKWebView's view scale via a new `setViewScale` method, supported in WebKit2 on macOS and iOS. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setViewScale): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::setViewScale): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setViewScale): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: Added. Add a new file for UIScriptController methods on Cocoa platforms. (WTR::UIScriptController::setViewScale): * WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj: * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::cocoaResetStateToConsistentValues): Ensure that _viewScale is reset to 1 after running a layout test. LayoutTests: Add two new layout tests on iOS that change WKWebView's view scale, and measure the resulting window sizes and lengths of viewport units. * fast/viewport/ios/constant-width-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/constant-width-viewport-after-changing-view-scale.html: Added. Add a test page with a viewport meta tag that has a constant width and an explicit initial scale of 0.5. * fast/viewport/ios/device-width-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/device-width-viewport-after-changing-view-scale.html: Added. Add a test page with a viewport meta tag at device-width, with initial scale 1. * resources/ui-helper.js: (window.UIHelper.setViewScale): Add a convenience function that wraps a UI script invocation of `setViewScale` in a promise. (window.UIHelper): Canonical link: https://commits.webkit.org/205461@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237087 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-10-12 23:13:37 +00:00
double m_layoutSizeScaleFactor { 1 };
Allow WebKit clients to specify a minimum effective width for layout. https://bugs.webkit.org/show_bug.cgi?id=191499 <rdar://problem/45362678> Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2018-11-28 Reviewed by Wenson Hsieh. Source/WebCore: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. Tests: fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setViewLayoutSize): Add a new argument effectiveWidth. (WebCore::ViewportConfiguration::nativeWebpageParameters): Make sure minimumScale for nativeWebpageParameters is small enough so that it won't clamp out the initial scale. If content is wider than the viewport, this ensures we can still zoom out the page. (WebCore::ViewportConfiguration::updateConfiguration): update _minimumEffectiveDeviceWidth and apply that to the layout size scale computation. (WebCore::ViewportConfiguration::effectiveLayoutSizeScaleFactor): A helper method to return the effective layout scale factor which is also effected by _minimumEffectiveDeviceWidth. (WebCore::ViewportConfiguration::updateMinimumLayoutSize): Update m_minimumLayoutSize based on effectiveLayoutSizeScaleFactor(). (WebCore::ViewportConfiguration::description const): Also dump m_minimumEffectiveDeviceWidth. * page/ViewportConfiguration.h: Add a member variable m_minimumEffectiveDeviceWidth. Source/WebKit: If we ignore the meta viewport (_shouldIgnoreMetaViewport is true), the default layout width will be device width. For clients that wish to lay out the content with a different width value, we would need to add a way to specify the effective width for layout. * UIProcess/API/Cocoa/WKWebView.mm: Add an iVar _minimumEffectiveDeviceWidth. (-[WKWebView _dispatchSetViewLayoutSize:]): Call the new setViewportConfigurationViewLayoutSize method. (-[WKWebView _setViewScale:]): Ditto. (-[WKWebView _setMinimumEffectiveWidth:]): The setter for _minimumEffectiveDeviceWidth. (-[WKWebView _minimumEffectiveWidth]): Getter for _minimumEffectiveDeviceWidth * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add a property _minimumEffectiveDeviceWidth to WKWebView. * UIProcess/WebPageProxy.h: Change setViewportConfigurationViewLayoutSize to take another argument minimumEffectiveDeviceWidth. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize): Also send effectiveWidth to WebContent process. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): Set the initial effective width to 0 when creating a web page, this tells ViewportConfiguration to ignore the minimum effective width value. * WebProcess/WebPage/WebPage.h: Change setViewportConfigurationViewLayoutSize to take another argument effectiveWidth. * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Also pass effectiveWidth value to ViewportConfiguration. Tools: Allow UIScriptController to set WKWebView's minimum effective width with a new `setMinimumEffectiveWidth` method. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * DumpRenderTree/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::setViewScale): (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setMinimumEffectiveWidth): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/UIScriptControllerCocoa.mm: (WTR::UIScriptController::setMinimumEffectiveWidth): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::cocoaResetStateToConsistentValues): LayoutTests: Add two new tests. The first test verifies if we ignore meta viewport, setting a different effective width value will change the layout width of the page. The second test verifies if we don't ignore meta viewport, we will always respect that (980pt) and setting a different effective width value won't change the layout width. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-overriden-by-minimum-effective-width-if-ignore-meta-viewport.html: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport-expected.txt: Added. * fast/viewport/ios/ipad/viewport-unchanged-by-minimum-effective-width-if-not-ignore-meta-viewport.html: Added. * resources/ui-helper.js: (window.UIHelper.setMinimumEffectiveWidth): Add a helper method to set the minimum effective width from a test. (window.UIHelper): Canonical link: https://commits.webkit.org/206776@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238623 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-28 18:50:23 +00:00
double m_minimumEffectiveDeviceWidth { 0 };
[iPadOS] Wikipedia articles lay out incorrectly in 1/3 multitasking window https://bugs.webkit.org/show_bug.cgi?id=210501 <rdar://problem/54856323> Reviewed by Tim Horton. Source/WebCore: In a 1/3 multitasking window, Safari currently uses the `-[WKWebView _allowsViewportShrinkToFit]` SPI to force pages to shrink down by fitting the content width to the view width. This legacy method of shrinking to fit involves laying the page out at the normal view width (320px in 1/3 multitasking), and then scaling the page down such that any amount of horizontal overflow fits within the view. In iOS 13, a new style of shrinking to fit was introduced in support of two new features: page zoom controls (accessible via the page formatting menu), and on-by-default page scaling when loading desktop sites on certain models of iPad where the page width is less than cutoffs of 1112px (in landscape) and 1024px (in portrait). This new method of shrinking to fit involves laying out at a larger width (computed from a combination of the minimum effective device width and layout size scale factor), and scaling to fit the effective layout size scale factor instead of the entire contents of the page. This means that while we may still get horizontal scrolling after shrinking to fit, the overall layout of the page is preserved. Currently, in 1/3 multitasking, Safari still relies on the former to scale pages down to fit, which means that Wikipedia articles (among other websites) do not lay out sensibly. Moreover, even if Safari adopted the second mechanism for shrinking to fit, layout issues would still exist (albeit to a lesser degree), since we'd still attempt to shrink the content width down to fit due to the fact that the desktop version of Wikipedia doesn't have a meta viewport. While we wouldn't get a broken layout, we'd still have a blank column running down the right side of the page, which is less than ideal. It's clear that in this case, attempting to shrink page content down to fit the view is suboptimal (at best, it leads to a large portion of the page being blank; at worst, it completely breaks page layout). To address this bug for now, add a parallel minimumEffectiveDeviceWidth value that takes effect when ignoring scaling constraints (i.e. when we're in a multitasking window), and scale the page down to fit this value instead of fitting the full content width when computing initial scale in `ViewportConfiguration::initialScaleFromSize`. Maintaining this value separately from m_minimumEffectiveDeviceWidth makes it much easier to ensure that the effects of this change are only ever active when the quirk is applied, and also when the view is embedded in a multitasking window. * page/Quirks.cpp: (WebCore::Quirks::shouldLayOutAtMinimumWindowWidthWhenIgnoringScalingConstraints const): Introduce a quirk to fix layout issues in multitasking mode on the desktop version of Wikipedia. * page/Quirks.h: * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints): * page/ViewportConfiguration.h: Add a minimum effective device width value that only takes effect when ignoring scaling constraints, and update `shouldIgnoreMinimumEffectiveDeviceWidth()` and `minimumEffectiveDeviceWidth()` to not always return `true` and `0` (respectively) when ignoring scaling constraints, if m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints is set. (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): (WebCore::ViewportConfiguration::shouldShrinkToFitMinimumEffectiveDeviceWidthWhenIgnoringScalingConstraints const): Source/WebKit: Apply the viewport quirk if needed; see WebCore/ChangeLog for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateVisibleContentRects): Canonical link: https://commits.webkit.org/223384@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260090 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-14 19:15:45 +00:00
double m_minimumEffectiveDeviceWidthWhenIgnoringScalingConstraints { 0 };
Make it possible to zoom on pages that claim to lay out to device size and then fail to do so https://bugs.webkit.org/show_bug.cgi?id=142549 Reviewed by Simon Fraser. * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::ViewportConfiguration): Rename m_ignoreScalingConstraints to m_canIgnoreScalingConstraints, because it being true does not guarantee that we will ignore scaling constraints, but it being false does guarantee that we won't. (WebCore::ViewportConfiguration::shouldIgnoreScalingConstraints): Ignore scaling constraints if the page: a) claimed to want to lay out to device-width and then laid out too wide b) claimed to want to lay out to device-height and then laid out too tall c) claimed to want to lay out with initialScale=1 and then laid out too wide (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::allowsUserScaling): Call shouldIgnoreScalingConstraints() instead of looking at the local, so we can have some more logic here (as above). (WebCore::ViewportConfiguration::description): Dump whether we're ignoring scaling constraints. (WebCore::ViewportConfiguration::dump): Use WTFLogAlways so that the output goes to various other logging mechanisms instead of just stderr. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::setCanIgnoreScalingConstraints): (WebCore::ViewportConfiguration::setIgnoreScalingConstraints): Deleted. * Shared/WebPreferencesDefinitions.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::updatePreferences): Flip the pref on by default. Canonical link: https://commits.webkit.org/160621@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@181400 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-03-11 19:16:20 +00:00
bool m_canIgnoreScalingConstraints;
bool m_forceAlwaysUserScalable;
[iOS] Add a version of viewport shrink-to-fit heuristics that preserves page layout https://bugs.webkit.org/show_bug.cgi?id=197342 <rdar://problem/50063091> Reviewed by Tim Horton. Source/WebCore: Adds support for a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. See WebKit ChangeLog for more details. Tests: fast/viewport/ios/shrink-to-fit-content-constant-width.html fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html fast/viewport/ios/shrink-to-fit-content-no-viewport.html fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setMinimumEffectiveDeviceWidth): (WebCore::ViewportConfiguration::setIsKnownToLayOutWiderThanViewport): (WebCore::ViewportConfiguration::description const): * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::canIgnoreScalingConstraints const): (WebCore::ViewportConfiguration::minimumEffectiveDeviceWidth const): Add several new getters and setters in ViewportConfiguration. (WebCore::ViewportConfiguration::isKnownToLayOutWiderThanViewport const): (WebCore::ViewportConfiguration::shouldIgnoreMinimumEffectiveDeviceWidth const): Importantly, only allow ignoring the minimum effective device width in webpages with responsive viewports, if they also have *not* laid out wider than the viewport. (WebCore::ViewportConfiguration::setForceAlwaysUserScalable): Source/WebKit: This patch introduces a new shrink-to-fit heuristic that attempts to lay out the contents of the page at a larger width in order to shrink content to fit the viewport. This is similar to existing shrink-to-fit behaviors used for viewport sizing in multitasking mode, except that it not only scales the view, but additionally expands the layout size, such that the overall layout of the page is preserved. In fact, the reason we ended up reverting the existing flavor of shrink-to-fit in all cases except for multitasking was that page layout was not preserved, which caused elements that poke out of the viewport to make the rest of the page look out of proportion — see <rdar://problem/23818102> and related radars. Covered by 5 new layout tests, and by adjusting a couple of existing layout tests. See comments below for more details. * Platform/Logging.h: Add a new ViewportSizing logging channel. This will only log on pages that overflow the viewport and shrink to fit as a result. * Shared/WebPreferences.yaml: Turn IgnoreViewportScalingConstraints off by default. This preference currently controls whether we allow shrink-to-fit behaviors, and is only used by Safari when it is in multitasking mode. The value of this preference is currenly *on* by default, and is turned off almost immediately during every page load after the first visible content rect update, wherein visibleContentRectUpdateInfo.allowShrinkToFit() is false. However, this sometimes causes a brief jitter during page load; to fix this, make the default value for IgnoreViewportScalingConstraints false, and change the logic in WebPage::updateVisibleContentRects to setCanIgnoreScalingConstraints to true if either the IgnoreViewportScalingConstraints preference (not only affected by an internal debug switch) is true, or WKWebView SPI is used to enable the behavior. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): (WebKit::WebFrameLoaderClient::dispatchDidFinishLoad): Add a new hook for WebFrameLoaderClient to call into WebPage when document load finishes. Also, tweak dispatchDidFinishLoad to take a WebFrame& instead of a WebFrame* in a drive-by fix (the frame is assumed to be non-null anyways). * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::didFinishDocumentLoad): (WebKit::WebPage::didFinishLoad): When finishing document load or finishing the overall load, kick off the shrink-to-fit timer; when committing a load, cancel the timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): Don't allow the minimum effective device width from the client to stomp over any minimum effective device width set as a result of the new shrink-to-fit heuristic; on some pages that load quickly, this can result in a race where the minimum effective device width (i.e. a value that lower-bounds the minimum layout width) is first set by the shrink-to-fit heuristic, and then set to an incorrect value by the client. In the near future, web view SPI used to set the minimum effective device width should actually be removed altogether, since the new shrink-to-fit heuristic supersedes any need for the client to fiddle with the minimum effective device width. (WebKit::WebPage::dynamicViewportSizeUpdate): When performing a dynamic viewport size update, additionally re-run the shrink-to-fit heuristic. This allows the minimum layout size of the viewport to be updated, if necessary. An example of where this matters is when a web page is *below* a tablet/desktop layout breakpoint in portrait device orientation, but then exceeds this layout breakpoint in landscape orientation. In this scenario, rotating the device should swap between these two page layouts. (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::scheduleShrinkToFitContent): (WebKit::WebPage::shrinkToFitContentTimerFired): (WebKit::WebPage::immediatelyShrinkToFitContent): Leverage the existing capability for a viewport to have a "minimum effective device width" to grant the viewport a larger layout size than it would normally have, and then scale down to fit within the bounds of the view. One challenge with this overall approach is that laying out at a larger width may cause the page to lay out even wider in response, which may actually worsen horizontal scrolling. To mitigate this, we only attempt to lay out at the current content width once; if laying out at this width reduced the amount of horizontal scrolling by any amount, then proceed with this layout width; otherwise, revert to the previous layout width. (WebKit::WebPage::shouldIgnoreMetaViewport const): Pull some common logic out into a readonly getter. (WebKit::WebPage::updateVisibleContentRects): See the comment below WebPreferences.yaml, above. LayoutTests: Introduces new layout tests, and adjusts some existing tests. See comments below. * fast/viewport/ios/shrink-to-fit-content-constant-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-constant-width.html: Added. Add a new layout test to exercise the scenario where a constant width viewport narrower than the view is used. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-large-width-breakpoint.html: Added. Add a new layout test to exercise the scenario where a responsive website that lays out larger than the view width ends up with even more horizontal scrolling when laying out at the initial content width. In this scenario, we shouldn't try to expand the viewport to try and encompass the content width, since that would only induce even worse horizontal scrolling. * fast/viewport/ios/shrink-to-fit-content-no-viewport-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-no-viewport.html: Added. Add a new layout test for the case where there is no viewport, but content lays out wider than the view. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-responsive-viewport-with-horizontal-overflow.html: Added. Add a new layout test for the case where the page has opted for a responsive viewport (device-width, initial scale 1), but has laid out wider than the viewport anyways. In this case, we want to shrink the contents down to fit inside the view. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-content-temporary-overflow.html: Added. Add a new layout test to exercise the case where, during page load, content width temporarily increases, and then decreases such that it once again fits within the viewport. In this case, we don't want to expand the viewport to be as wide as the large temporary width of the page. * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden.html: * fast/viewport/ios/width-is-device-width-overflowing-expected.txt: * fast/viewport/ios/width-is-device-width-overflowing.html: Tweak these 2 existing layout tests to include "shrink-to-fit=no", to prevent the new heuristics from shrinking the page to fit on device classes that use native viewports by default. * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-expected.txt: * platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-expected.txt: Canonical link: https://commits.webkit.org/211651@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244849 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-01 21:08:38 +00:00
bool m_isKnownToLayOutWiderThanViewport { false };
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
};
[WTF] Move TextStream into WTF https://bugs.webkit.org/show_bug.cgi?id=175211 Reviewed by Myles C. Maxfield. Source/WebCore: No new tests. No change in behavior. * CMakeLists.txt: * WebCore.xcodeproj/project.pbxproj: * dom/ComposedTreeIterator.cpp: * dom/Position.cpp: * dom/Position.h: * dom/Range.cpp: (WebCore::operator<<): * dom/Range.h: * dom/ViewportArguments.cpp: * dom/ViewportArguments.h: * editing/VisiblePosition.cpp: * editing/VisiblePosition.h: * editing/VisibleSelection.cpp: * editing/VisibleSelection.h: * html/HTMLVideoElement.cpp: * html/canvas/CanvasRenderingContext2D.cpp: * page/FrameView.cpp: * page/ViewportConfiguration.cpp: * page/ViewportConfiguration.h: * page/WheelEventDeltaFilter.cpp: * page/animation/CSSPropertyAnimation.cpp: * page/scrolling/AsyncScrollingCoordinator.cpp: * page/scrolling/ScrollingConstraints.cpp: * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.cpp: * page/scrolling/ScrollingCoordinator.h: * page/scrolling/ScrollingStateFixedNode.cpp: * page/scrolling/ScrollingStateFixedNode.h: * page/scrolling/ScrollingStateFrameScrollingNode.cpp: * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingStateNode.cpp: * page/scrolling/ScrollingStateNode.h: * page/scrolling/ScrollingStateOverflowScrollingNode.cpp: * page/scrolling/ScrollingStateOverflowScrollingNode.h: * page/scrolling/ScrollingStateScrollingNode.cpp: * page/scrolling/ScrollingStateScrollingNode.h: * page/scrolling/ScrollingStateStickyNode.cpp: * page/scrolling/ScrollingStateStickyNode.h: * page/scrolling/ScrollingTree.cpp: * page/scrolling/ScrollingTreeFrameScrollingNode.cpp: * page/scrolling/ScrollingTreeFrameScrollingNode.h: * page/scrolling/ScrollingTreeNode.cpp: * page/scrolling/ScrollingTreeNode.h: * page/scrolling/ScrollingTreeScrollingNode.cpp: * page/scrolling/ScrollingTreeScrollingNode.h: * page/scrolling/mac/ScrollingTreeFixedNode.h: * page/scrolling/mac/ScrollingTreeFixedNode.mm: * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm: * page/scrolling/mac/ScrollingTreeStickyNode.h: * page/scrolling/mac/ScrollingTreeStickyNode.mm: * platform/CalculationValue.cpp: * platform/CalculationValue.h: * platform/LayoutUnit.cpp: * platform/LayoutUnit.h: * platform/Length.cpp: * platform/Length.h: * platform/LengthBox.cpp: * platform/LengthBox.h: * platform/LengthPoint.cpp: * platform/LengthPoint.h: * platform/LengthSize.cpp: * platform/LengthSize.h: * platform/LogMacros.h: * platform/ScrollView.cpp: * platform/ScrollableArea.cpp: * platform/animation/TimingFunction.cpp: * platform/animation/TimingFunction.h: * platform/graphics/BitmapImage.cpp: * platform/graphics/BitmapImage.h: * platform/graphics/Color.cpp: * platform/graphics/Color.h: * platform/graphics/CrossfadeGeneratedImage.cpp: * platform/graphics/CrossfadeGeneratedImage.h: * platform/graphics/FloatPoint.cpp: * platform/graphics/FloatPoint.h: * platform/graphics/FloatPoint3D.cpp: * platform/graphics/FloatPoint3D.h: * platform/graphics/FloatRect.cpp: * platform/graphics/FloatRect.h: * platform/graphics/FloatRoundedRect.cpp: * platform/graphics/FloatRoundedRect.h: * platform/graphics/FloatSize.cpp: * platform/graphics/FloatSize.h: * platform/graphics/FontTaggedSettings.cpp: * platform/graphics/FontTaggedSettings.h: * platform/graphics/GradientImage.cpp: (WebCore::GradientImage::dump const): * platform/graphics/GradientImage.h: * platform/graphics/GraphicsContext.cpp: * platform/graphics/GraphicsContext.h: * platform/graphics/GraphicsLayer.cpp: * platform/graphics/GraphicsLayer.h: (WebCore::GraphicsLayer::dumpAdditionalProperties const): * platform/graphics/GraphicsTypes.cpp: * platform/graphics/GraphicsTypes.h: * platform/graphics/Image.cpp: * platform/graphics/Image.h: * platform/graphics/ImageSource.h: * platform/graphics/IntPoint.cpp: * platform/graphics/IntPoint.h: * platform/graphics/IntRect.cpp: * platform/graphics/IntRect.h: * platform/graphics/IntSize.cpp: * platform/graphics/IntSize.h: * platform/graphics/LayoutPoint.cpp: * platform/graphics/LayoutPoint.h: * platform/graphics/LayoutRect.cpp: * platform/graphics/LayoutRect.h: * platform/graphics/LayoutSize.cpp: * platform/graphics/LayoutSize.h: * platform/graphics/NamedImageGeneratedImage.cpp: * platform/graphics/NamedImageGeneratedImage.h: * platform/graphics/Path.cpp: * platform/graphics/Path.h: * platform/graphics/ca/GraphicsLayerCA.cpp: * platform/graphics/ca/GraphicsLayerCA.h: * platform/graphics/ca/PlatformCAAnimation.cpp: * platform/graphics/ca/PlatformCAAnimation.h: * platform/graphics/ca/PlatformCALayer.cpp: * platform/graphics/ca/PlatformCALayer.h: * platform/graphics/ca/TileController.cpp: * platform/graphics/ca/TileGrid.cpp: * platform/graphics/cg/GraphicsContextCG.cpp: * platform/graphics/cg/PDFDocumentImage.cpp: * platform/graphics/cg/PDFDocumentImage.h: * platform/graphics/cocoa/IOSurface.h: * platform/graphics/cocoa/IOSurface.mm: * platform/graphics/displaylists/DisplayList.cpp: (WebCore::DisplayList::DisplayList::description const): * platform/graphics/displaylists/DisplayList.h: * platform/graphics/displaylists/DisplayListItems.cpp: * platform/graphics/displaylists/DisplayListItems.h: * platform/graphics/displaylists/DisplayListRecorder.cpp: * platform/graphics/displaylists/DisplayListReplayer.cpp: * platform/graphics/filters/DistantLightSource.cpp: * platform/graphics/filters/DistantLightSource.h: * platform/graphics/filters/FEBlend.cpp: * platform/graphics/filters/FEBlend.h: * platform/graphics/filters/FEColorMatrix.cpp: * platform/graphics/filters/FEColorMatrix.h: * platform/graphics/filters/FEComponentTransfer.cpp: * platform/graphics/filters/FEComponentTransfer.h: * platform/graphics/filters/FEComposite.cpp: * platform/graphics/filters/FEComposite.h: * platform/graphics/filters/FEConvolveMatrix.cpp: * platform/graphics/filters/FEConvolveMatrix.h: * platform/graphics/filters/FEDiffuseLighting.cpp: * platform/graphics/filters/FEDiffuseLighting.h: * platform/graphics/filters/FEDisplacementMap.cpp: * platform/graphics/filters/FEDisplacementMap.h: * platform/graphics/filters/FEDropShadow.cpp: * platform/graphics/filters/FEDropShadow.h: * platform/graphics/filters/FEFlood.cpp: * platform/graphics/filters/FEFlood.h: * platform/graphics/filters/FEGaussianBlur.cpp: * platform/graphics/filters/FEGaussianBlur.h: * platform/graphics/filters/FEMerge.cpp: * platform/graphics/filters/FEMerge.h: * platform/graphics/filters/FEMorphology.cpp: * platform/graphics/filters/FEMorphology.h: * platform/graphics/filters/FEOffset.cpp: * platform/graphics/filters/FEOffset.h: * platform/graphics/filters/FESpecularLighting.cpp: * platform/graphics/filters/FESpecularLighting.h: * platform/graphics/filters/FETile.cpp: * platform/graphics/filters/FETile.h: * platform/graphics/filters/FETurbulence.cpp: * platform/graphics/filters/FETurbulence.h: * platform/graphics/filters/FilterEffect.cpp: * platform/graphics/filters/FilterEffect.h: * platform/graphics/filters/FilterOperation.cpp: * platform/graphics/filters/FilterOperation.h: * platform/graphics/filters/FilterOperations.cpp: * platform/graphics/filters/FilterOperations.h: * platform/graphics/filters/LightSource.h: * platform/graphics/filters/PointLightSource.cpp: * platform/graphics/filters/PointLightSource.h: * platform/graphics/filters/SourceAlpha.cpp: * platform/graphics/filters/SourceAlpha.h: * platform/graphics/filters/SourceGraphic.cpp: * platform/graphics/filters/SourceGraphic.h: * platform/graphics/filters/SpotLightSource.cpp: * platform/graphics/filters/SpotLightSource.h: * platform/graphics/transforms/AffineTransform.cpp: * platform/graphics/transforms/AffineTransform.h: * platform/graphics/transforms/IdentityTransformOperation.h: * platform/graphics/transforms/Matrix3DTransformOperation.cpp: * platform/graphics/transforms/Matrix3DTransformOperation.h: * platform/graphics/transforms/MatrixTransformOperation.cpp: * platform/graphics/transforms/MatrixTransformOperation.h: * platform/graphics/transforms/PerspectiveTransformOperation.cpp: * platform/graphics/transforms/PerspectiveTransformOperation.h: * platform/graphics/transforms/RotateTransformOperation.cpp: * platform/graphics/transforms/RotateTransformOperation.h: * platform/graphics/transforms/ScaleTransformOperation.cpp: * platform/graphics/transforms/ScaleTransformOperation.h: * platform/graphics/transforms/SkewTransformOperation.cpp: * platform/graphics/transforms/SkewTransformOperation.h: * platform/graphics/transforms/TransformOperation.cpp: * platform/graphics/transforms/TransformOperation.h: * platform/graphics/transforms/TransformOperations.cpp: * platform/graphics/transforms/TransformOperations.h: * platform/graphics/transforms/TransformationMatrix.cpp: * platform/graphics/transforms/TransformationMatrix.h: * platform/graphics/transforms/TranslateTransformOperation.cpp: * platform/graphics/transforms/TranslateTransformOperation.h: * platform/ios/SelectionRect.cpp: (WebCore::operator<<): * platform/ios/SelectionRect.h: * platform/mac/ScrollAnimatorMac.mm: * platform/text/TextAllInOne.cpp: * rendering/InlineBox.cpp: * rendering/InlineBox.h: * rendering/InlineFlowBox.cpp: (WebCore::InlineFlowBox::outputLineTreeAndMark const): * rendering/InlineFlowBox.h: * rendering/InlineTextBox.cpp: * rendering/InlineTextBox.h: * rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::outputLineTreeAndMark const): * rendering/RenderBlockFlow.h: * rendering/RenderLayer.cpp: * rendering/RenderLayerCompositor.cpp: * rendering/RenderObject.cpp: * rendering/RenderObject.h: * rendering/RenderTreeAsText.cpp: * rendering/RenderTreeAsText.h: * rendering/ScrollAlignment.cpp: * rendering/ScrollAlignment.h: * rendering/SimpleLineLayoutCoverage.cpp: * rendering/SimpleLineLayoutFunctions.cpp: * rendering/SimpleLineLayoutFunctions.h: * rendering/style/FillLayer.cpp: * rendering/style/FillLayer.h: * rendering/style/NinePieceImage.cpp: * rendering/style/NinePieceImage.h: * rendering/style/RenderStyleConstants.cpp: * rendering/style/RenderStyleConstants.h: * rendering/svg/SVGRenderTreeAsText.cpp: (WebCore::operator<<): * rendering/svg/SVGRenderTreeAsText.h: (WebCore::operator<<): * svg/SVGLengthValue.cpp: * svg/SVGLengthValue.h: * svg/graphics/SVGImage.cpp: * svg/graphics/SVGImage.h: * svg/graphics/filters/SVGFEImage.cpp: * svg/graphics/filters/SVGFEImage.h: Source/WebKit: * Shared/Scrolling/RemoteScrollingCoordinatorTransaction.cpp: * Shared/VisibleContentRectUpdateInfo.cpp: * Shared/VisibleContentRectUpdateInfo.h: * Shared/mac/RemoteLayerTreeTransaction.mm: * UIProcess/API/Cocoa/WKWebView.mm: * UIProcess/ios/WKContentView.mm: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (WebKit::operator<<): * UIProcess/ios/WebPageProxyIOS.mm: * WebProcess/WebPage/ios/WebPageIOS.mm: * WebProcess/WebPage/mac/PlatformCAAnimationRemote.h: * WebProcess/WebPage/mac/PlatformCAAnimationRemote.mm: Source/WTF: * WTF.xcodeproj/project.pbxproj: * wtf/CMakeLists.txt: * wtf/text/TextStream.cpp: Renamed from Source/WebCore/platform/text/TextStream.cpp. (WTF::TextStream::writeIndent): * wtf/text/TextStream.h: Renamed from Source/WebCore/platform/text/TextStream.h. (WTF::TextStream::FormatNumberRespectingIntegers::FormatNumberRespectingIntegers): Tools: * TestWebKitAPI/Tests/WebCore/CalculationValue.cpp: Canonical link: https://commits.webkit.org/192121@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@220503 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-08-10 01:15:14 +00:00
WTF::TextStream& operator<<(WTF::TextStream&, const ViewportConfiguration::Parameters&);
Add a log channel for viewports https://bugs.webkit.org/show_bug.cgi?id=180295 Reviewed by Zalan Bujtas. Add a "Viewports" log channel to log viewport scaling information, and enhance the WebKit "VisibleRects" channel to log additional data for the same reason. Source/WebCore: * dom/Document.cpp: (WebCore::Document::processViewport): * loader/FrameLoader.cpp: (WebCore::FrameLoader::finishedParsing): (WebCore::FrameLoader::completed): * page/FrameView.cpp: (WebCore::FrameView::resetScrollbarsAndClearContentsSize): (WebCore::FrameView::scrollToAnchor): (WebCore::FrameView::maintainScrollPositionAtAnchor): (WebCore::FrameView::setScrollPosition): (WebCore::FrameView::autoSizeIfEnabled): (WebCore::FrameView::setWasScrolledByUser): * page/LayoutContext.cpp: (WebCore::LayoutContext::layout): * page/Page.cpp: (WebCore::Page::setPageScaleFactor): * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::operator<<): (WebCore::ViewportConfiguration::description const): (WebCore::ViewportConfiguration::dump const): * page/ViewportConfiguration.h: * platform/Logging.h: * platform/ScrollView.cpp: (WebCore::ScrollView::setFixedLayoutSize): Source/WebKit: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _didCommitLayerTree:]): (-[WKWebView _dynamicViewportUpdateChangedTargetToScale:position:nextValidLayerTreeTransactionID:]): (-[WKWebView _dispatchSetMinimumLayoutSize:]): (-[WKWebView _endAnimatedResize]): (-[WKWebView _resizeWhileHidingContentWithUpdates:]): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setFixedLayoutSize): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::scaleAfterViewportWidthChange): (WebKit::WebPage::setViewportConfigurationMinimumLayoutSize): (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::viewportConfigurationChanged): (WebKit::WebPage::updateVisibleContentRects): Canonical link: https://commits.webkit.org/196293@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@225449 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-12-02 17:55:24 +00:00
WTF::TextStream& operator<<(WTF::TextStream&, const ViewportConfiguration&);
Enhance TextStream for logging, remove subclasses, log more things https://bugs.webkit.org/show_bug.cgi?id=150269 Reviewed by Zalan Bujtas. Remove the various TextStream subclasses that only existed to support indenting, and output additional types. Add output for more WebCore and WebKit2 types, and just use TextStream everywhere. TextStream is enhance to support grouping (open paren and intent), with a stack-based class to open/end a group. Remove some SVG-specific duplicate output functions. Outdent namespace contents of GraphicsTypes.h. Source/WebCore: * CMakeLists.txt: * WebCore.xcodeproj/project.pbxproj: * dom/ViewportArguments.cpp: (WebCore::operator<<): * dom/ViewportArguments.h: * page/ViewportConfiguration.cpp: (WebCore::operator<<): (WebCore::ViewportConfiguration::description): (WebCore::ViewportConfigurationTextStream::ViewportConfigurationTextStream): Deleted. (WebCore::ViewportConfigurationTextStream::increaseIndent): Deleted. (WebCore::ViewportConfigurationTextStream::decreaseIndent): Deleted. (WebCore::dumpProperty): Deleted. (WebCore::ViewportConfigurationTextStream::writeIndent): Deleted. (WebCore::ViewportConfigurationTextStream::operator<<): Deleted. * page/ViewportConfiguration.h: * page/scrolling/ScrollingConstraints.cpp: (WebCore::operator<<): * page/scrolling/ScrollingConstraints.h: * page/scrolling/ScrollingCoordinator.cpp: (WebCore::operator<<): * page/scrolling/ScrollingCoordinator.h: * platform/animation/TimingFunction.cpp: Added. (WebCore::operator<<): * platform/animation/TimingFunction.h: * platform/graphics/Color.cpp: (WebCore::operator<<): * platform/graphics/Color.h: * platform/graphics/FloatPoint3D.cpp: (WebCore::operator<<): * platform/graphics/FloatPoint3D.h: * platform/graphics/FloatRoundedRect.cpp: (WebCore::operator<<): * platform/graphics/FloatRoundedRect.h: * platform/graphics/GraphicsLayer.cpp: (WebCore::operator<<): * platform/graphics/GraphicsLayer.h: * platform/graphics/GraphicsTypes.cpp: (WebCore::operator<<): * platform/graphics/GraphicsTypes.h: * platform/graphics/ca/PlatformCAAnimation.cpp: Added. (WebCore::operator<<): * platform/graphics/ca/PlatformCAAnimation.h: * platform/graphics/ca/PlatformCALayer.cpp: (WebCore::operator<<): * platform/graphics/ca/PlatformCALayer.h: * platform/graphics/filters/FilterOperation.cpp: (WebCore::operator<<): * platform/graphics/filters/FilterOperation.h: * platform/graphics/filters/FilterOperations.cpp: (WebCore::operator<<): * platform/graphics/filters/FilterOperations.h: * platform/graphics/filters/PointLightSource.cpp: (WebCore::operator<<): Deleted. * platform/graphics/filters/SpotLightSource.cpp: (WebCore::operator<<): Deleted. * platform/graphics/transforms/AffineTransform.cpp: (WebCore::operator<<): * platform/graphics/transforms/AffineTransform.h: * platform/graphics/transforms/TransformationMatrix.cpp: (WebCore::operator<<): * platform/graphics/transforms/TransformationMatrix.h: * platform/text/TextStream.cpp: (WebCore::TextStream::startGroup): (WebCore::TextStream::endGroup): (WebCore::TextStream::nextLine): (WebCore::TextStream::writeIndent): * platform/text/TextStream.h: (WebCore::TextStream::operator<<): (WebCore::TextStream::dumpProperty): (WebCore::TextStream::increaseIndent): (WebCore::TextStream::decreaseIndent): (WebCore::TextStream::GroupScope::GroupScope): (WebCore::TextStream::GroupScope::~GroupScope): * rendering/svg/SVGRenderTreeAsText.cpp: (WebCore::operator<<): Deleted. * rendering/svg/SVGRenderTreeAsText.h: Source/WebKit2: * Shared/Scrolling/RemoteScrollingCoordinatorTransaction.cpp: (WebKit::dump): (WebKit::recursiveDumpNodes): (WebKit::RemoteScrollingCoordinatorTransaction::description): (WebKit::RemoteScrollingTreeTextStream::RemoteScrollingTreeTextStream): Deleted. (WebKit::RemoteScrollingTreeTextStream::increaseIndent): Deleted. (WebKit::RemoteScrollingTreeTextStream::decreaseIndent): Deleted. (WebKit::RemoteScrollingTreeTextStream::writeIndent): Deleted. (WebKit::dumpProperty): Deleted. (WebKit::RemoteScrollingTreeTextStream::operator<<): Deleted. (WebKit::RemoteScrollingTreeTextStream::dump): Deleted. (WebKit::RemoteScrollingTreeTextStream::recursiveDumpNodes): Deleted. * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::operator<<): (WebKit::dumpChangedLayers): (WebKit::RemoteLayerTreeTransaction::description): (WebKit::RemoteLayerTreeTextStream::RemoteLayerTreeTextStream): Deleted. (WebKit::RemoteLayerTreeTextStream::increaseIndent): Deleted. (WebKit::RemoteLayerTreeTextStream::decreaseIndent): Deleted. (WebKit::dumpProperty): Deleted. (WebKit::RemoteLayerTreeTextStream::operator<<): Deleted. (WebKit::RemoteLayerTreeTextStream::writeIndent): Deleted. * WebProcess/WebPage/mac/PlatformCAAnimationRemote.h: * WebProcess/WebPage/mac/PlatformCAAnimationRemote.mm: (WebKit::operator<<): Canonical link: https://commits.webkit.org/168413@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@191243 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-17 18:34:19 +00:00
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited https://bugs.webkit.org/show_bug.cgi?id=127886 Reviewed by Simon Fraser. Source/WebCore: The updates of the views on the UIProcess side was completely disconnected from the tiles updates from the DrawingArea. There is a non-negligible time between the size/scale update and the new tiles coming, which causes visual glitches. There are three main cases where the tiles and content would be out of sync with the UIViews: -When loading a new page with different content width of a different viewport. -When a page changes its viewport. -When the viewport-constrainted viewport size changes. To fix the issue, WKView is modified to maintain the old state of WKContentView and UIScrollView until the new tiles are available. Geometry/scale update are split in two phases: 1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates its layout accordingly. At this point, the UIViews are unchanged and are left with the old parameters. 2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy. At that point, WKContentView and its UIScrollView are updated to match the committed size and scale for the page. * WebCore.exp.in: * WebCore.xcodeproj/project.pbxproj: * page/ViewportConfiguration.cpp: Added. (WebCore::constraintsAreAllRelative): (WebCore::ViewportConfiguration::ViewportConfiguration): (WebCore::ViewportConfiguration::setDefaultConfiguration): (WebCore::ViewportConfiguration::setContentsSize): (WebCore::ViewportConfiguration::setMinimumLayoutSize): (WebCore::ViewportConfiguration::setViewportArguments): (WebCore::ViewportConfiguration::layoutSize): (WebCore::ViewportConfiguration::initialScale): (WebCore::ViewportConfiguration::minimumScale): (WebCore::ViewportConfiguration::maximumScale): (WebCore::ViewportConfiguration::allowsUserScaling): (WebCore::viewportArgumentValueIsValid): (WebCore::applyViewportArgument): (WebCore::ViewportConfiguration::updateConfiguration): (WebCore::ViewportConfiguration::layoutWidth): (WebCore::ViewportConfiguration::layoutHeight): * page/ViewportConfiguration.h: Added. (WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration): (WebCore::ViewportConfiguration::defaultConfiguration): (WebCore::ViewportConfiguration::contentsSize): (WebCore::ViewportConfiguration::minimumLayoutSize): (WebCore::ViewportConfiguration::viewportArguments): Source/WebKit2: * Shared/mac/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize): (WebKit::RemoteLayerTreeTransaction::pageScaleFactor): (WebKit::RemoteLayerTreeTransaction::setPageScaleFactor): (WebKit::RemoteLayerTreeTransaction::minimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor): (WebKit::RemoteLayerTreeTransaction::maximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor): (WebKit::RemoteLayerTreeTransaction::allowsUserScaling): (WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling): * Shared/mac/RemoteLayerTreeTransaction.mm: (WebKit::RemoteLayerTreeTransaction::encode): (WebKit::RemoteLayerTreeTransaction::decode): * UIProcess/API/ios/PageClientImplIOS.h: * UIProcess/API/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didCommitLayerTree): * UIProcess/API/ios/WKContentView.h: * UIProcess/API/ios/WKContentView.mm: (-[WKContentView setMinimumLayoutSize:]): (-[WKContentView willStartUserTriggeredZoom]): (-[WKContentView _didCommitLayerTree:WebKit::]): * UIProcess/API/ios/WKContentViewInternal.h: * UIProcess/API/ios/WKViewIOS.mm: (-[WKView contentViewDidCommitLoadForMainFrame:]): (-[WKView contentView:didCommitLayerTree:WebKit::]): (-[WKView scrollViewWillBeginZooming:withView:]): (-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]): (-[WKView _frameOrBoundsChanged]): (-[WKView minimumLayoutSizeOverride]): (-[WKView setMinimumLayoutSizeOverride:]): * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize): (WebKit::WebPageProxy::didCommitLayerTree): (WebKit::WebPageProxy::willStartUserTriggeredZooming): * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::contentsSizeChanged): (WebKit::WebChromeClient::dispatchViewportPropertiesDidChange): * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::didReceiveMobileDocType): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): (WebKit::WebPage::mainFrameDidLayout): (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::viewportPropertiesDidChange): (WebKit::WebPage::minimumPageScaleFactor): (WebKit::WebPage::maximumPageScaleFactor): (WebKit::WebPage::allowsUserScaling): (WebKit::WebPage::setVirtualViewportMinimumLayoutSize): (WebKit::WebPage::virtualViewportChanged): (WebKit::WebPage::willStartUserTriggeredZooming): * WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::flushLayers): Canonical link: https://commits.webkit.org/146300@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-02-06 06:45:41 +00:00
} // namespace WebCore