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.
|
|
|
|
*/
|
|
|
|
|
2016-10-31 22:07:53 +00:00
|
|
|
#pragma once
|
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"
|
2014-04-24 02:13:06 +00:00
|
|
|
#include "FloatSize.h"
|
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>
|
2014-02-06 06:45:41 +00:00
|
|
|
|
2017-08-10 01:15:14 +00:00
|
|
|
namespace WTF {
|
|
|
|
class TextStream;
|
|
|
|
}
|
|
|
|
|
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 };
|
2017-12-02 03:19:16 +00:00
|
|
|
|
|
|
|
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
|
2017-12-02 03:19:16 +00:00
|
|
|
&& allowsUserScaling == other.allowsUserScaling && allowsShrinkToFit == other.allowsShrinkToFit && avoidsUnsafeArea == other.avoidsUnsafeArea
|
|
|
|
&& widthIsSet == other.widthIsSet && heightIsSet == other.heightIsSet && initialScaleIsSet == other.initialScaleIsSet;
|
|
|
|
}
|
2014-02-06 06:45:41 +00:00
|
|
|
};
|
|
|
|
|
2014-08-22 04:21:18 +00:00
|
|
|
WEBCORE_EXPORT ViewportConfiguration();
|
2014-02-06 06:45:41 +00:00
|
|
|
|
|
|
|
const Parameters& defaultConfiguration() const { return m_defaultConfiguration; }
|
2014-08-22 04:21:18 +00:00
|
|
|
WEBCORE_EXPORT void setDefaultConfiguration(const Parameters&);
|
2014-02-06 06:45:41 +00:00
|
|
|
|
|
|
|
const IntSize& contentsSize() const { return m_contentSize; }
|
2015-12-17 03:48:34 +00:00
|
|
|
WEBCORE_EXPORT bool setContentsSize(const IntSize&);
|
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
|
|
|
|
2014-04-24 02:13:06 +00:00
|
|
|
const FloatSize& minimumLayoutSize() const { return m_minimumLayoutSize; }
|
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);
|
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>&);
|
|
|
|
|
2014-02-06 06:45:41 +00:00
|
|
|
const ViewportArguments& viewportArguments() const { return m_viewportArguments; }
|
2015-12-17 03:48:34 +00:00
|
|
|
WEBCORE_EXPORT bool setViewportArguments(const ViewportArguments&);
|
2014-02-06 06:45:41 +00:00
|
|
|
|
2015-12-17 03:48:34 +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;
|
|
|
|
}
|
2014-12-10 23:42:51 +00:00
|
|
|
|
[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; }
|
2018-10-15 17:36:31 +00:00
|
|
|
double layoutSizeScaleFactor() const { return m_layoutSizeScaleFactor; }
|
|
|
|
|
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;
|
2019-05-04 02:25:03 +00:00
|
|
|
WEBCORE_EXPORT int layoutHeight() const;
|
2014-08-22 04:21:18 +00:00
|
|
|
WEBCORE_EXPORT double initialScale() const;
|
2015-05-21 00:52:33 +00:00
|
|
|
WEBCORE_EXPORT double initialScaleIgnoringContentSize() const;
|
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; }
|
2016-09-30 00:38:18 +00:00
|
|
|
double maximumScaleIgnoringAlwaysScalable() const { return m_configuration.maximumScale; }
|
2014-12-10 23:42:51 +00:00
|
|
|
WEBCORE_EXPORT bool allowsUserScaling() const;
|
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; }
|
2014-02-06 06:45:41 +00:00
|
|
|
|
2018-09-26 22:31:18 +00:00
|
|
|
// Matches a width=device-width, initial-scale=1 viewport.
|
2019-02-26 04:37:59 +00:00
|
|
|
WEBCORE_EXPORT Parameters nativeWebpageParameters();
|
|
|
|
static Parameters nativeWebpageParametersWithoutShrinkToFit();
|
|
|
|
static Parameters nativeWebpageParametersWithShrinkToFit();
|
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();
|
2014-05-13 00:13:58 +00:00
|
|
|
|
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
|
2017-12-02 17:55:24 +00:00
|
|
|
String description() const;
|
2016-05-09 20:22:47 +00:00
|
|
|
WEBCORE_EXPORT void dump() const;
|
2014-05-13 00:13:58 +00:00
|
|
|
#endif
|
2015-05-20 20:42:49 +00:00
|
|
|
|
2014-02-06 06:45:41 +00:00
|
|
|
private:
|
|
|
|
void updateConfiguration();
|
2014-10-07 20:52:26 +00:00
|
|
|
double viewportArgumentsLength(double length) const;
|
2015-05-21 00:52:33 +00:00
|
|
|
double initialScaleFromSize(double width, double height, bool shouldIgnoreScalingConstraints) const;
|
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;
|
2015-03-11 19:16:20 +00:00
|
|
|
bool shouldIgnoreScalingConstraints() const;
|
2015-03-13 21:07:06 +00:00
|
|
|
bool shouldIgnoreVerticalScalingConstraints() const;
|
|
|
|
bool shouldIgnoreHorizontalScalingConstraints() const;
|
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;
|
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;
|
2018-11-28 18:50:23 +00:00
|
|
|
return forceAlwaysUserScalableMinimumScaleIgnoringLayoutScaleFactor * effectiveLayoutSizeScaleFactor();
|
|
|
|
}
|
|
|
|
|
|
|
|
constexpr double effectiveLayoutSizeScaleFactor() const
|
|
|
|
{
|
2018-12-07 01:35:25 +00:00
|
|
|
if (!m_viewLayoutSize.width() || !minimumEffectiveDeviceWidth())
|
2018-11-28 18:50:23 +00:00
|
|
|
return m_layoutSizeScaleFactor;
|
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();
|
|
|
|
|
2014-02-06 06:45:41 +00:00
|
|
|
Parameters m_configuration;
|
|
|
|
Parameters m_defaultConfiguration;
|
|
|
|
IntSize m_contentSize;
|
2014-04-24 02:13:06 +00:00
|
|
|
FloatSize m_minimumLayoutSize;
|
2018-04-27 16:07:19 +00:00
|
|
|
FloatSize m_viewLayoutSize;
|
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;
|
2014-12-10 23:42:51 +00:00
|
|
|
|
[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 };
|
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 };
|
2015-03-11 19:16:20 +00:00
|
|
|
bool m_canIgnoreScalingConstraints;
|
2015-03-26 00:03:44 +00:00
|
|
|
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 };
|
2014-02-06 06:45:41 +00:00
|
|
|
};
|
|
|
|
|
2017-08-10 01:15:14 +00:00
|
|
|
WTF::TextStream& operator<<(WTF::TextStream&, const ViewportConfiguration::Parameters&);
|
2017-12-02 17:55:24 +00:00
|
|
|
WTF::TextStream& operator<<(WTF::TextStream&, const ViewportConfiguration&);
|
2015-10-17 18:34:19 +00:00
|
|
|
|
2014-02-06 06:45:41 +00:00
|
|
|
} // namespace WebCore
|