2019-08-11 Babak Shafiei Apply patch. rdar://problem/54139834 2019-08-11 Maciej Stachowiak Branch build fix for r248463 * page/Quirks.cpp: #include DOMTokenList.h, since it's now needed (and apparently was added by something else on mainline. 2019-08-10 Babak Shafiei Cherry-pick r248502. rdar://problem/54130678 Disable ContentChangeObserver TouchEvent adjustment on youtube.com on iOS in mobile browsing mode https://bugs.webkit.org/show_bug.cgi?id=200609 Reviewed by Maciej Stachowiak. Source/WebCore: When watching a youtube video on iOS with "Autoplay" switched to off, upon finishing the video all clicks anywhere on the page are effectively ignored. Disabling ContentChangeObserver's TouchEvent adjustment fixes this bug. I verified this manually. This switch was introduced in r242621, and it disables part of a new feature, so there is low risk of fallout. * loader/DocumentLoader.h: (WebCore::DocumentLoader::setAllowContentChangeObserverQuirk): (WebCore::DocumentLoader::allowContentChangeObserverQuirk const): * page/Quirks.cpp: (WebCore::Quirks::shouldDisableContentChangeObserverTouchEventAdjustment const): * page/Quirks.h: * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::touchEventDidStart): Source/WebKit: * Shared/WebsitePoliciesData.cpp: (WebKit::WebsitePoliciesData::encode const): (WebKit::WebsitePoliciesData::decode): (WebKit::WebsitePoliciesData::applyToDocumentLoader): * Shared/WebsitePoliciesData.h: * UIProcess/API/APIWebsitePolicies.cpp: (API::WebsitePolicies::copy const): (API::WebsitePolicies::data): * UIProcess/API/APIWebsitePolicies.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248502 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Alex Christensen Disable ContentChangeObserver TouchEvent adjustment on youtube.com on iOS in mobile browsing mode https://bugs.webkit.org/show_bug.cgi?id=200609 Reviewed by Maciej Stachowiak. When watching a youtube video on iOS with "Autoplay" switched to off, upon finishing the video all clicks anywhere on the page are effectively ignored. Disabling ContentChangeObserver's TouchEvent adjustment fixes this bug. I verified this manually. This switch was introduced in r242621, and it disables part of a new feature, so there is low risk of fallout. * loader/DocumentLoader.h: (WebCore::DocumentLoader::setAllowContentChangeObserverQuirk): (WebCore::DocumentLoader::allowContentChangeObserverQuirk const): * page/Quirks.cpp: (WebCore::Quirks::shouldDisableContentChangeObserverTouchEventAdjustment const): * page/Quirks.h: * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::touchEventDidStart): 2019-08-10 Babak Shafiei Cherry-pick r248501. rdar://problem/54130617 [iOS] Add a quirk for gmail.com messages on iPhone iOS13 https://bugs.webkit.org/show_bug.cgi?id=200605 Patch by Said Abou-Hallawa on 2019-08-10 Reviewed by Maciej Stachowiak. Source/WebCore: Add a quirk which sets the user agent for gmail.com messages on iPhone OS 13 to be iPhone OS 12. This is a workaround for a gmail.com bug till it is fixed. * page/Quirks.cpp: (WebCore::Quirks::shouldAvoidUsingIOS13ForGmail const): * page/Quirks.h: * platform/UserAgent.h: * platform/ios/UserAgentIOS.mm: (WebCore::osNameForUserAgent): (WebCore::standardUserAgentWithApplicationName): * platform/mac/UserAgentMac.mm: (WebCore::standardUserAgentWithApplicationName): Source/WebKit: Use WebPage::platformUserAgent() to add the gmail.com quirk. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformUserAgent const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248501 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Said Abou-Hallawa [iOS] Add a quirk for gmail.com messages on iPhone iOS13 https://bugs.webkit.org/show_bug.cgi?id=200605 Reviewed by Maciej Stachowiak. Add a quirk which sets the user agent for gmail.com messages on iPhone OS 13 to be iPhone OS 12. This is a workaround for a gmail.com bug till it is fixed. * page/Quirks.cpp: (WebCore::Quirks::shouldAvoidUsingIOS13ForGmail const): * page/Quirks.h: * platform/UserAgent.h: * platform/ios/UserAgentIOS.mm: (WebCore::osNameForUserAgent): (WebCore::standardUserAgentWithApplicationName): * platform/mac/UserAgentMac.mm: (WebCore::standardUserAgentWithApplicationName): 2019-08-10 Babak Shafiei Cherry-pick r248494. rdar://problem/54171879 Universal XSS in JSObject::putInlineSlow and JSValue::putToPrimitive https://bugs.webkit.org/show_bug.cgi?id=199864 Reviewed by Saam Barati. Source/JavaScriptCore: Our JSObject::put implementation is not correct in term of the spec. Our [[Put]] implementation is something like this. JSObject::put(object): if (can-do-fast-path(object)) return fast-path(object); // slow-path do { object-put-check-and-setter-calls(object); // (1) object = object->prototype; } while (is-object(object)); return do-put(object); Since JSObject::put is registered in the methodTable, the derived classes can override it. Some of classes are adding extra checks to this put. Derived::put(object): if (do-extra-check(object)) fail return JSObject::put(object) The problem is that Derived::put is only called when the |this| object is the Derived class. When traversing [[Prototype]] in JSObject::put, at (1), we do not perform the extra checks added in Derived::put even if `object` is Derived one. This means that we skip the check. Currently, JSObject::put and WebCore checking mechanism are broken. JSObject::put should call getOwnPropertySlot at (1) to perform the additional checks. This behavior is matching against the spec. However, currently, our JSObject::getOwnPropertySlot does not propagate setter information. This is required to cache cacheable [[Put]] at (1) for CustomValue, CustomAccessor, and Accessors. We also need to reconsider how to integrate static property setters to this mechanism. So, basically, this involves large refactoring to renew our JSObject::put and JSObject::getOwnPropertySlot. To work-around for now, we add a new TypeInfo flag, HasPutPropertySecurityCheck . And adding this flag to DOM objects that implements the addition checks. We also add doPutPropertySecurityCheck method hook to perform the check in JSObject. When we found this flag at (1), we perform doPutPropertySecurityCheck to properly perform the checks. Since our JSObject::put code is old and it does not match against the spec now, we should refactor it largely. This is tracked separately in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=200562 * runtime/ClassInfo.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCell.cpp: (JSC::JSCell::doPutPropertySecurityCheck): * runtime/JSCell.h: * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::getOwnPropertyDescriptor): * runtime/JSObject.h: (JSC::JSObject::doPutPropertySecurityCheck): * runtime/JSTypeInfo.h: (JSC::TypeInfo::hasPutPropertySecurityCheck const): Source/WebCore: Test: http/tests/security/cross-frame-access-object-put-optimization.html * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::doPutPropertySecurityCheck): * bindings/js/JSLocationCustom.cpp: (WebCore::JSLocation::doPutPropertySecurityCheck): * bindings/scripts/CodeGeneratorJS.pm: (GenerateHeader): * bindings/scripts/test/JS/JSTestActiveDOMObject.h: LayoutTests: * http/tests/security/cross-frame-access-object-put-optimization-expected.txt: Added. * http/tests/security/cross-frame-access-object-put-optimization.html: Added. * http/tests/security/resources/cross-frame-iframe-for-object-put-optimization-test.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248494 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Yusuke Suzuki Universal XSS in JSObject::putInlineSlow and JSValue::putToPrimitive https://bugs.webkit.org/show_bug.cgi?id=199864 Reviewed by Saam Barati. Test: http/tests/security/cross-frame-access-object-put-optimization.html * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::doPutPropertySecurityCheck): * bindings/js/JSLocationCustom.cpp: (WebCore::JSLocation::doPutPropertySecurityCheck): * bindings/scripts/CodeGeneratorJS.pm: (GenerateHeader): * bindings/scripts/test/JS/JSTestActiveDOMObject.h: 2019-08-10 Babak Shafiei Cherry-pick r248491. rdar://problem/54130644 Don't allow cross-origin iframes to autofocus https://bugs.webkit.org/show_bug.cgi?id=200515 Reviewed by Ryosuke Niwa. Source/WebCore: According to Step 6 in the WhatWG Spec (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofocusing-a-form-control:-the-autofocus-attribute), the 'autofocus' attribute shouldn't work for cross-origin iframes. This change is based on the Blink change (patch by ): Also disallow cross-origin iframes from focusing programmatically without ever having had any user interaction. * dom/Element.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::Element::focus): * html/HTMLFormControlElement.cpp: Check if the focus is moving to an invalid frame. (WebCore::shouldAutofocus): * page/DOMWindow.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::DOMWindow::focus): Tools: Make WebKit.FocusedFrameAfterCrash use same-origin iframes instead of cross-origin iframes, since it depends on focusing one of the frames. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKit/ReloadPageAfterCrash.cpp: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKit/many-same-origin-iframes.html: Added. LayoutTests: Add test coverage, and simulate user interaction in existing tests that require focusing a cross-origin frame. * http/tests/security/clipboard/resources/copy-html.html: * http/tests/security/clipboard/resources/copy-mso-list.html: * http/tests/security/clipboard/resources/copy-url.html: * http/wpt/html/interaction/focus/no-cross-origin-element-focus-expected.txt: Added. * http/wpt/html/interaction/focus/no-cross-origin-element-focus.html: Added. * http/wpt/html/interaction/focus/no-cross-origin-window-focus-expected.txt: Added. * http/wpt/html/interaction/focus/no-cross-origin-window-focus.html: Added. * http/wpt/html/interaction/focus/resources/child-focus-element.html: Added. * http/wpt/html/interaction/focus/resources/child-focus-window.html: Added. * http/wpt/html/semantics/forms/autofocus/no-cross-origin-autofocus.sub-expected.txt: Added. * http/wpt/html/semantics/forms/autofocus/no-cross-origin-autofocus.sub.html: Added. * http/wpt/html/semantics/forms/autofocus/resources/child-autofocus.html: Added. * http/wpt/webauthn/resources/last-layer-frame.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248491 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Ali Juma Don't allow cross-origin iframes to autofocus https://bugs.webkit.org/show_bug.cgi?id=200515 Reviewed by Ryosuke Niwa. According to Step 6 in the WhatWG Spec (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofocusing-a-form-control:-the-autofocus-attribute), the 'autofocus' attribute shouldn't work for cross-origin iframes. This change is based on the Blink change (patch by ): Also disallow cross-origin iframes from focusing programmatically without ever having had any user interaction. * dom/Element.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::Element::focus): * html/HTMLFormControlElement.cpp: Check if the focus is moving to an invalid frame. (WebCore::shouldAutofocus): * page/DOMWindow.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::DOMWindow::focus): 2019-08-10 Babak Shafiei Cherry-pick r248471. rdar://problem/54130628 Disable CSSOM View Scrolling API for IMDb iOS app https://bugs.webkit.org/show_bug.cgi?id=200586 Patch by Alex Christensen on 2019-08-09 Reviewed by Simon Fraser. Source/WebCore: They are calling scrollHeight on the HTML element and it is running new code introduced in r235806 Disable this new feature until they update their app to use the iOS13 SDK. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isIMDb): Source/WebKit: Change the CSSOMViewScrollingAPIEnabled default value to be off for the IMDb app's WKWebViews. I manually verified this is effective in those WKWebViews but no other WKWebViews and that it fixes the radar. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.cpp: (WebKit::defaultCSSOMViewScrollingAPIEnabled): * Shared/WebPreferencesDefaultValues.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248471 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Alex Christensen Disable CSSOM View Scrolling API for IMDb iOS app https://bugs.webkit.org/show_bug.cgi?id=200586 Reviewed by Simon Fraser. They are calling scrollHeight on the HTML element and it is running new code introduced in r235806 Disable this new feature until they update their app to use the iOS13 SDK. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isIMDb): 2019-08-10 Babak Shafiei Cherry-pick r248463. rdar://problem/54139834 REGRESSION (iOS 13): united.com web forms do not respond to taps https://bugs.webkit.org/show_bug.cgi?id=200531 Reviewed by Antti Koivisto and Wenson Hsieh. The bug is caused by the content change observer detecting “Site Feedback” link at the bottom of the page (https://www.united.com/ual/en/US/account/enroll/default) constantly getting re-generated in every frame via requestAnimationFrame when the page is opened with iPhone UA string. Note that the content re-generation can be reproduced even in Chrome if iPhone UA string is used. Ignore this constant content change in ContentChangeObserver as a site specific quirk. In the future, we should make ContentChangeObserver observe the final location of each element being observed so that we can ignore content that like this which is placed outside the viewport, and/or far away from where the user tapped. * page/Quirks.cpp: (WebCore::Quirks::shouldIgnoreContentChange const): Added. * page/Quirks.h: * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::shouldObserveVisibilityChangeForElement): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248463 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Ryosuke Niwa REGRESSION (iOS 13): united.com web forms do not respond to taps https://bugs.webkit.org/show_bug.cgi?id=200531 Reviewed by Antti Koivisto and Wenson Hsieh. The bug is caused by the content change observer detecting “Site Feedback” link at the bottom of the page (https://www.united.com/ual/en/US/account/enroll/default) constantly getting re-generated in every frame via requestAnimationFrame when the page is opened with iPhone UA string. Note that the content re-generation can be reproduced even in Chrome if iPhone UA string is used. Ignore this constant content change in ContentChangeObserver as a site specific quirk. In the future, we should make ContentChangeObserver observe the final location of each element being observed so that we can ignore content that like this which is placed outside the viewport, and/or far away from where the user tapped. * page/Quirks.cpp: (WebCore::Quirks::shouldIgnoreContentChange const): Added. * page/Quirks.h: * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::shouldObserveVisibilityChangeForElement): 2019-08-09 Kocsen Chung Cherry-pick r248447. rdar://problem/54109873 Add to InteractionInformationAtPosition information about whether the element is in a subscrollable region https://bugs.webkit.org/show_bug.cgi?id=200374 rdar://problem/54095519 Reviewed by Tim Horton. Source/WebCore: Add to InteractionInformationAtPosition a ScrollingNodeID which represents the enclosing scrolling node that affects the targeted element's position. We use this to find a UIScrollView in the UI process. The entrypoint to finding the enclosing scrolling node is ScrollingCoordinator::scrollableContainerNodeID(), which calls RenderLayerCompositor::asyncScrollableContainerNodeID() to look for a scrolling ancestor in the current frame, and then looks for an enclosing scrollable frame, or a scrolling ancestor in the enclosing frame. There's a bit of subtlety in RenderLayerCompositor::asyncScrollableContainerNodeID() because if you're asking for the node that scrolls the renderer, if the renderer itself has a layer and is scrollable, you want its enclosing scroller. * page/scrolling/AsyncScrollingCoordinator.cpp: (WebCore::AsyncScrollingCoordinator::scrollableContainerNodeID const): * page/scrolling/AsyncScrollingCoordinator.h: * page/scrolling/ScrollingCoordinator.cpp: (WebCore::scrollableContainerNodeID const): * page/scrolling/ScrollingCoordinator.h: * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::asyncScrollableContainerNodeID): * rendering/RenderLayerCompositor.h: Source/WebKit: Add InteractionInformationAtPosition.containerScrollingNodeID and initialize it in elementPositionInformation() by asking the scrolling coordinator. Also add a way to get from a ScrollingNodeID to a UIScrollView to RemoteScrollingCoordinatorProxy, which gets the scrolling node and asks the delegate for the UIView. * Shared/ios/InteractionInformationAtPosition.h: * Shared/ios/InteractionInformationAtPosition.mm: (WebKit::InteractionInformationAtPosition::encode const): (WebKit::InteractionInformationAtPosition::decode): * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h: * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm: (WebKit::RemoteScrollingCoordinatorProxy::scrollViewForScrollingNodeID const): * UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.h: * UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.mm: (WebKit::ScrollingTreeOverflowScrollingNodeIOS::scrollView const): * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::elementPositionInformation): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248447 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Kocsen Chung Cherry-pick r248438. rdar://problem/54093226 [iOS] Position image information should respect the image orientation https://bugs.webkit.org/show_bug.cgi?id=200487 Patch by Said Abou-Hallawa on 2019-08-08 Reviewed by Simon Fraser. Source/WebCore: Re-factor CachedImage::imageSizeForRenderer() into another overriding function which does not scale the imageSize. Therefore the new function returns FloatSize while the original function returns LayoutSize. * loader/cache/CachedImage.cpp: (WebCore::CachedImage::imageSizeForRenderer const): * loader/cache/CachedImage.h: * rendering/RenderElement.h: Source/WebKit: imagePositionInformation() should respect the image orientation when drawing an Image to a ShareableBitmap context. boundsPositionInformation() already takes care of the image orientation because it gets RenderImage::enclosingBoundingBox(). * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::imagePositionInformation): Tools: Add an API test to verify the position image information is drawn rotated because of respecting its image orientation. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/WKRequestActivatedElementInfo.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/exif-orientation-8-llo.jpg: Added. * TestWebKitAPI/Tests/WebKitCocoa/img-with-rotated-image.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248438 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Said Abou-Hallawa [iOS] Position image information should respect the image orientation https://bugs.webkit.org/show_bug.cgi?id=200487 Reviewed by Simon Fraser. Re-factor CachedImage::imageSizeForRenderer() into another overriding function which does not scale the imageSize. Therefore the new function returns FloatSize while the original function returns LayoutSize. * loader/cache/CachedImage.cpp: (WebCore::CachedImage::imageSizeForRenderer const): * loader/cache/CachedImage.h: * rendering/RenderElement.h: 2019-08-08 Alan Coon Cherry-pick r248410. rdar://problem/54084738 Do not allow navigations of frames about to get replaced by the result of evaluating javascript: URLs and https://bugs.webkit.org/show_bug.cgi?id=198786 Reviewed by Geoff Garen. Source/WebCore: Covered by API Test Add a "willReplaceWithResultOfExecutingJavascriptURL" flag which is respected inside FrameLoader::isNavigationAllowed * bindings/js/ScriptController.cpp: (WebCore::ScriptController::executeIfJavaScriptURL): * bindings/js/ScriptController.h: (WebCore::ScriptController::willReplaceWithResultOfExecutingJavascriptURL const): * loader/FrameLoader.cpp: (WebCore::FrameLoader::isNavigationAllowed const): Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/mac/JavascriptURLNavigation.mm: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248410 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Brady Eidson Do not allow navigations of frames about to get replaced by the result of evaluating javascript: URLs and https://bugs.webkit.org/show_bug.cgi?id=198786 Reviewed by Geoff Garen. Covered by API Test Add a "willReplaceWithResultOfExecutingJavascriptURL" flag which is respected inside FrameLoader::isNavigationAllowed * bindings/js/ScriptController.cpp: (WebCore::ScriptController::executeIfJavaScriptURL): * bindings/js/ScriptController.h: (WebCore::ScriptController::willReplaceWithResultOfExecutingJavascriptURL const): * loader/FrameLoader.cpp: (WebCore::FrameLoader::isNavigationAllowed const): 2019-08-07 Kocsen Chung Revert r248173. rdar://problem/54036774 2019-08-07 Kocsen Chung Cherry-pick r248368. rdar://problem/54037160 Extra space inserted at start of line when inserting a newline in Mail compose https://bugs.webkit.org/show_bug.cgi?id=200490 Reviewed by Antti Koivisto. Source/WebCore: This started happening after r244494, which deferred editor state computation until the next layer tree flush when changing selection. After inserting a paragraph, the act of computing an editor state ensured that the text node containing the caret drops out of simple line layout, while grabbing the characters near the selection (i.e., calling charactersAroundPosition). This meant that when we subsequently ask positionAfterSplit whether it isRenderedCharacter() at the end of the command, we are guaranteed to have line boxes, so we get a meaningful answer and avoid inserting an extra non-breaking space. However, after r244494, we defer the editor state computation until the end of the edit command; this means that we may not have line boxes for positionAfterSplit's text node renderer, due to remaining in simple line layout. In turn, this means that we end up hitting the assertion in containsRenderedCharacterOffset in debug builds; on release builds, we simply return false from containsRenderedCharacterOffset, which causes us to insert an extra space. To fix this, we educate RenderText::containsRenderedCharacterOffset about simple line layout. Test: editing/inserting/insert-paragraph-in-designmode-document.html * rendering/RenderText.cpp: (WebCore::RenderText::containsRenderedCharacterOffset const): (WebCore::RenderText::containsCaretOffset const): Changed to use SimpleLineLayout::containsOffset. * rendering/SimpleLineLayoutFunctions.h: (WebCore::SimpleLineLayout::containsOffset): I first contrasted the behavior of RenderTextLineBoxes::containsOffset in the cases where the OffsetType is CaretOffset or CharacterOffset, and found that the only interesting differences were: 1. The caret offset type case has special handling for line breaks. 2. Both offset types have handling for reversed text. 3. The end offset of a line box contains a caret offset, but not a character offset. For the purposes of OffsetType CharacterOffset, (1) is irrelevant; furthermore, (2) is already not handled by logic in containsCaretOffset(). Thus, the only major difference in the CharacterOffset case should be (3), which we handle by only allowing the case where the given offset is equal to the very end of a text run for caret offsets, and not character offsets. (WebCore::SimpleLineLayout::containsCaretOffset): Deleted. Renamed to just containsOffset. LayoutTests: Add a new test to verify that inserting a newline in the middle of text in a document with designMode "on" doesn't insert an extra space at the beginning of the newly inserted line. * editing/inserting/insert-paragraph-in-designmode-document-expected.txt: Added. * editing/inserting/insert-paragraph-in-designmode-document.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248368 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-07 Wenson Hsieh Extra space inserted at start of line when inserting a newline in Mail compose https://bugs.webkit.org/show_bug.cgi?id=200490 Reviewed by Antti Koivisto. This started happening after r244494, which deferred editor state computation until the next layer tree flush when changing selection. After inserting a paragraph, the act of computing an editor state ensured that the text node containing the caret drops out of simple line layout, while grabbing the characters near the selection (i.e., calling charactersAroundPosition). This meant that when we subsequently ask positionAfterSplit whether it isRenderedCharacter() at the end of the command, we are guaranteed to have line boxes, so we get a meaningful answer and avoid inserting an extra non-breaking space. However, after r244494, we defer the editor state computation until the end of the edit command; this means that we may not have line boxes for positionAfterSplit's text node renderer, due to remaining in simple line layout. In turn, this means that we end up hitting the assertion in containsRenderedCharacterOffset in debug builds; on release builds, we simply return false from containsRenderedCharacterOffset, which causes us to insert an extra space. To fix this, we educate RenderText::containsRenderedCharacterOffset about simple line layout. Test: editing/inserting/insert-paragraph-in-designmode-document.html * rendering/RenderText.cpp: (WebCore::RenderText::containsRenderedCharacterOffset const): (WebCore::RenderText::containsCaretOffset const): Changed to use SimpleLineLayout::containsOffset. * rendering/SimpleLineLayoutFunctions.h: (WebCore::SimpleLineLayout::containsOffset): I first contrasted the behavior of RenderTextLineBoxes::containsOffset in the cases where the OffsetType is CaretOffset or CharacterOffset, and found that the only interesting differences were: 1. The caret offset type case has special handling for line breaks. 2. Both offset types have handling for reversed text. 3. The end offset of a line box contains a caret offset, but not a character offset. For the purposes of OffsetType CharacterOffset, (1) is irrelevant; furthermore, (2) is already not handled by logic in containsCaretOffset(). Thus, the only major difference in the CharacterOffset case should be (3), which we handle by only allowing the case where the given offset is equal to the very end of a text run for caret offsets, and not character offsets. (WebCore::SimpleLineLayout::containsCaretOffset): Deleted. Renamed to just containsOffset. 2019-08-07 Kocsen Chung Cherry-pick r248173. rdar://problem/54036774 Harden NodeRareData::m_connectedFrameCount https://bugs.webkit.org/show_bug.cgi?id=200300 Reviewed by Geoffrey Garen. Use unsinged integer type in NodeRareData::m_connectedFrameCount since it's padded anyway. * dom/Node.cpp: (WebCore::Node::decrementConnectedSubframeCount): Check that hasRareNode() is true in release builds. * dom/NodeRareData.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248173 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Ryosuke Niwa Harden NodeRareData::m_connectedFrameCount https://bugs.webkit.org/show_bug.cgi?id=200300 Reviewed by Geoffrey Garen. Use unsinged integer type in NodeRareData::m_connectedFrameCount since it's padded anyway. * dom/Node.cpp: (WebCore::Node::decrementConnectedSubframeCount): Check that hasRareNode() is true in release builds. * dom/NodeRareData.h: 2019-08-06 Kocsen Chung Cherry-pick r248037. rdar://problem/54018119 AX: Re-enable accessibility/set-selected-text-range-after-newline.html test. https://bugs.webkit.org/show_bug.cgi?id=199431 Patch by Andres Gonzalez on 2019-07-31 Reviewed by Chris Fleizach. Source/WebCore: - Re-enabled LayoutTests/accessibility/set-selected-text-range-after-newline.html. - Put back workaround in visiblePositionForIndexUsingCharacterIterator that is needed for several accessibility issues. - This workaround was rolled back because it was thought the cause of: https://bugs.webkit.org/show_bug.cgi?id=199434 It turned out that the actual cause of that hang was unrelated and was fixed in: https://bugs.webkit.org/show_bug.cgi?id=199845 * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): LayoutTests: * TestExpectations: * accessibility/ios-simulator/set-selected-text-range-after-newline.html: Removed because it was the same as the one in the parent accessibility directory, so enabling it for iOS in ios-wk2/TestExpectations. * platform/ios-wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248037 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Andres Gonzalez AX: Re-enable accessibility/set-selected-text-range-after-newline.html test. https://bugs.webkit.org/show_bug.cgi?id=199431 Reviewed by Chris Fleizach. - Re-enabled LayoutTests/accessibility/set-selected-text-range-after-newline.html. - Put back workaround in visiblePositionForIndexUsingCharacterIterator that is needed for several accessibility issues. - This workaround was rolled back because it was thought the cause of: https://bugs.webkit.org/show_bug.cgi?id=199434 It turned out that the actual cause of that hang was unrelated and was fixed in: https://bugs.webkit.org/show_bug.cgi?id=199845 * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): 2019-08-06 Kocsen Chung Cherry-pick r248265. rdar://problem/54017843 Ping loads should not prevent page caching https://bugs.webkit.org/show_bug.cgi?id=200418 Reviewed by Darin Adler. Source/WebCore: We normally prevent page caching if there were any pending subresource loads when navigating, to avoid caching partial / broken content. However, this should not apply to Ping / Beacon loads since those do not impact page rendering and can outlive the page. Tests: http/tests/navigation/page-cache-pending-ping-load-cross-origin.html http/tests/navigation/page-cache-pending-ping-load-same-origin.html * history/PageCache.cpp: (WebCore::PageCache::addIfCacheable): After we've fired the 'pagehide' event in each frame, stop all the loads again. This is needed since pages are allowed to start ping / beacon loads in their 'pagehide' handlers. If we do not stop those loads, then the next call to canCachePage() would fail because the DocumentLoader is still loading. Note that we're not actually preventing these ping loads from hitting the server since we never cancel page loads and those can outlive their page. * loader/DocumentLoader.cpp: (WebCore::shouldPendingCachedResourceLoadPreventPageCache): (WebCore::areAllLoadersPageCacheAcceptable): Make sure that Ping / Beacon / Prefetches / Icon loads do not prevent page caching. (WebCore::DocumentLoader::addSubresourceLoader): Tweak assertion that was incorrect since we actually allow ping / beacon loads when the document is about to enter PageCache (while firing pagehide event). Tools: Add TestOption to enable PageCache at UIProcess-level so that we can test page caching when navigating cross-origin with PSON enabled. * WebKitTestRunner/TestController.cpp: (WTR::TestController::resetPreferencesToConsistentValues): (WTR::updateTestOptionsFromTestHeader): * WebKitTestRunner/TestOptions.h: (WTR::TestOptions::hasSameInitializationOptions const): LayoutTests: Add layout test coverage. * http/tests/navigation/page-cache-pending-ping-load-cross-origin-expected.txt: Added. * http/tests/navigation/page-cache-pending-ping-load-cross-origin.html: Added. * http/tests/navigation/page-cache-pending-ping-load-same-origin-expected.txt: Added. * http/tests/navigation/page-cache-pending-ping-load-same-origin.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248265 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-04 Chris Dumez Ping loads should not prevent page caching https://bugs.webkit.org/show_bug.cgi?id=200418 Reviewed by Darin Adler. 2019-08-08 Simon Fraser Add to InteractionInformationAtPosition information about whether the element is in a subscrollable region https://bugs.webkit.org/show_bug.cgi?id=200374 rdar://problem/54095519 Reviewed by Tim Horton. Add to InteractionInformationAtPosition a ScrollingNodeID which represents the enclosing scrolling node that affects the targeted element's position. We use this to find a UIScrollView in the UI process. The entrypoint to finding the enclosing scrolling node is ScrollingCoordinator::scrollableContainerNodeID(), which calls RenderLayerCompositor::asyncScrollableContainerNodeID() to look for a scrolling ancestor in the current frame, and then looks for an enclosing scrollable frame, or a scrolling ancestor in the enclosing frame. There's a bit of subtlety in RenderLayerCompositor::asyncScrollableContainerNodeID() because if you're asking for the node that scrolls the renderer, if the renderer itself has a layer and is scrollable, you want its enclosing scroller. * page/scrolling/AsyncScrollingCoordinator.cpp: (WebCore::AsyncScrollingCoordinator::scrollableContainerNodeID const): * page/scrolling/AsyncScrollingCoordinator.h: * page/scrolling/ScrollingCoordinator.cpp: (WebCore::scrollableContainerNodeID const): * page/scrolling/ScrollingCoordinator.h: * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::asyncScrollableContainerNodeID): * rendering/RenderLayerCompositor.h: We normally prevent page caching if there were any pending subresource loads when navigating, to avoid caching partial / broken content. However, this should not apply to Ping / Beacon loads since those do not impact page rendering and can outlive the page. Tests: http/tests/navigation/page-cache-pending-ping-load-cross-origin.html http/tests/navigation/page-cache-pending-ping-load-same-origin.html * history/PageCache.cpp: (WebCore::PageCache::addIfCacheable): After we've fired the 'pagehide' event in each frame, stop all the loads again. This is needed since pages are allowed to start ping / beacon loads in their 'pagehide' handlers. If we do not stop those loads, then the next call to canCachePage() would fail because the DocumentLoader is still loading. Note that we're not actually preventing these ping loads from hitting the server since we never cancel page loads and those can outlive their page. * loader/DocumentLoader.cpp: (WebCore::shouldPendingCachedResourceLoadPreventPageCache): (WebCore::areAllLoadersPageCacheAcceptable): Make sure that Ping / Beacon / Prefetches / Icon loads do not prevent page caching. (WebCore::DocumentLoader::addSubresourceLoader): Tweak assertion that was incorrect since we actually allow ping / beacon loads when the document is about to enter PageCache (while firing pagehide event). 2019-08-06 Kocsen Chung Cherry-pick r248148. rdar://problem/54017841 Pages using MessagePorts should be PageCacheable https://bugs.webkit.org/show_bug.cgi?id=200366 Reviewed by Geoffrey Garen. Source/WebCore: Allow a page to enter PageCache, even if it has MessagePorts (potentially with pending messages). If there are pending messages on the MessagePorts when entering PageCache, those will get dispatched upon restoring from PageCache. Test: fast/history/page-cache-MessagePort-pending-message.html * dom/MessagePort.cpp: (WebCore::MessagePort::messageAvailable): (WebCore::MessagePort::dispatchMessages): Do not dispatch messages while in PageCache. (WebCore::MessagePort::canSuspendForDocumentSuspension const): Allow pages with MessagePort objects to enter PageCache. * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::resumeActiveDOMObjects): Make sure pending messages on MessagePorts get dispatched asynchronously after restoring from PageCache. * loader/DocumentLoader.cpp: (WebCore::areAllLoadersPageCacheAcceptable): Make sure only CachedResources that are still loading upon load cancelation prevent entering PageCache. LayoutTests: Add layout test coverage. * fast/history/page-cache-MessagePort-pending-message-expected.txt: Added. * fast/history/page-cache-MessagePort-pending-message.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248148 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-01 Chris Dumez Pages using MessagePorts should be PageCacheable https://bugs.webkit.org/show_bug.cgi?id=200366 Reviewed by Geoffrey Garen. Allow a page to enter PageCache, even if it has MessagePorts (potentially with pending messages). If there are pending messages on the MessagePorts when entering PageCache, those will get dispatched upon restoring from PageCache. Test: fast/history/page-cache-MessagePort-pending-message.html * dom/MessagePort.cpp: (WebCore::MessagePort::messageAvailable): (WebCore::MessagePort::dispatchMessages): Do not dispatch messages while in PageCache. (WebCore::MessagePort::canSuspendForDocumentSuspension const): Allow pages with MessagePort objects to enter PageCache. * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::resumeActiveDOMObjects): Make sure pending messages on MessagePorts get dispatched asynchronously after restoring from PageCache. * loader/DocumentLoader.cpp: (WebCore::areAllLoadersPageCacheAcceptable): Make sure only CachedResources that are still loading upon load cancelation prevent entering PageCache. 2019-08-06 Kocsen Chung Cherry-pick r248028. rdar://problem/54017896 ASSERTion failure under takeSnapshot after r247846 * page/TextIndicator.cpp: (WebCore::takeSnapshots): We now sometimes inflate the scale factor; allow this. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248028 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-30 Tim Horton ASSERTion failure under takeSnapshot after r247846 * page/TextIndicator.cpp: (WebCore::takeSnapshots): We now sometimes inflate the scale factor; allow this. 2019-08-06 Kocsen Chung Cherry-pick r248018. rdar://problem/54017893 REGRESSION(r241288): Text on Yahoo Japan mobile looks too bold https://bugs.webkit.org/show_bug.cgi?id=200065 Reviewed by Simon Fraser. Source/WebCore: Before r241288, we were mapping Japanese sans-serif to Hiragino Kaku Gothic ProN, which has a 300 weight and a 600 weight. However, we can't use that font because it's user-installed, so in r241288 we switched to using Hiragino Sans, which has a 300 weight, a 600 weight, and an 800 weight. According to the CSS font selection algorithm, sites that request a weight of 700 would get the 800 weight instead of the 600 weight, which caused the text to look too heavy. Therefore, the apparent visual change is from a weight change from 600 to 800. In general, this is working as intended. However, text on Yahoo Japan looks too heavy in weight 800. Instead, this patch adds a quirk specific to Yahoo Japan that overwrites any font requests to give them a weight of 600 instead of 700. This way, the lighter font will be used. No new tests because quirks cannot be tested. * css/CSSFontSelector.cpp: (WebCore::resolveGenericFamily): (WebCore::CSSFontSelector::fontRangesForFamily): * page/Quirks.cpp: (WebCore::Quirks::shouldLightenJapaneseBoldSansSerif const): * page/Quirks.h: Source/WTF: * wtf/Platform.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248018 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-30 Myles C. Maxfield REGRESSION(r241288): Text on Yahoo Japan mobile looks too bold https://bugs.webkit.org/show_bug.cgi?id=200065 Reviewed by Simon Fraser. Before r241288, we were mapping Japanese sans-serif to Hiragino Kaku Gothic ProN, which has a 300 weight and a 600 weight. However, we can't use that font because it's user-installed, so in r241288 we switched to using Hiragino Sans, which has a 300 weight, a 600 weight, and an 800 weight. According to the CSS font selection algorithm, sites that request a weight of 700 would get the 800 weight instead of the 600 weight, which caused the text to look too heavy. Therefore, the apparent visual change is from a weight change from 600 to 800. In general, this is working as intended. However, text on Yahoo Japan looks too heavy in weight 800. Instead, this patch adds a quirk specific to Yahoo Japan that overwrites any font requests to give them a weight of 600 instead of 700. This way, the lighter font will be used. No new tests because quirks cannot be tested. * css/CSSFontSelector.cpp: (WebCore::resolveGenericFamily): (WebCore::CSSFontSelector::fontRangesForFamily): * page/Quirks.cpp: (WebCore::Quirks::shouldLightenJapaneseBoldSansSerif const): * page/Quirks.h: 2019-08-06 Kocsen Chung Cherry-pick r247846. rdar://problem/54017896 Subpixel fringes around TextIndicator snapshots at non-integral scale factors https://bugs.webkit.org/show_bug.cgi?id=200145 Reviewed by Simon Fraser. * page/FrameSnapshotting.cpp: (WebCore::snapshotFrameRectWithClip): * page/FrameSnapshotting.h: * page/TextIndicator.cpp: (WebCore::snapshotOptionsForTextIndicatorOptions): Round the scale factor up, and snappily enclose the clip rects. TextIndicator doesn't require the use of the precise scale factor that the page is painted at, but we want it to be sharp, so we overshoot! git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247846 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Tim Horton Subpixel fringes around TextIndicator snapshots at non-integral scale factors https://bugs.webkit.org/show_bug.cgi?id=200145 Reviewed by Simon Fraser. * page/FrameSnapshotting.cpp: (WebCore::snapshotFrameRectWithClip): * page/FrameSnapshotting.h: * page/TextIndicator.cpp: (WebCore::snapshotOptionsForTextIndicatorOptions): Round the scale factor up, and snappily enclose the clip rects. TextIndicator doesn't require the use of the precise scale factor that the page is painted at, but we want it to be sharp, so we overshoot! 2019-08-06 Kocsen Chung Cherry-pick r247822. rdar://problem/54017886 Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts https://bugs.webkit.org/show_bug.cgi?id=200107 Reviewed by Geoffrey Garen. Source/WebCore: Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Test: fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html * page/ChromeClient.h: * testing/Internals.cpp: (WebCore::Internals::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendSyncMessage): * Platform/IPC/Connection.h: Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag to allow processing incoming sync messages while sending a particular sync IPC. This is the default behavior in all processes except in the WebContent process, where we try to avoid re-entering to prevent bugs. This flag allows the WebContent process to change its default behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits performance to re-renter. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::didReceiveSyncMessage): (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/Network/NetworkProcessProxy.h: * UIProcess/Network/NetworkProcessProxy.messages.in: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/WebPage.messages.in: SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag. * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs since they are triggered by JS and we return to JS right after. This should avoid UIProcess hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself stuck on the sync IPC to show a JS alert. LayoutTests: Add layout test coverage for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Without the flag on the sendSync from the WebContent process of the NetworkConnectionToWebProcess::TestProcessIncomingSyncMessagesWhenWaitingForSyncReply IPC, the test would hang. This is because the WebContent process sends a sync IPC to the network process, which in turns sends one to the UIProcess, which itself sends one back to the WebContent process. This would attempt to re-enter the WebContent process which is currently sending a sync IPC, which is not allowed by default. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt: Added. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247822 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Chris Dumez Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts https://bugs.webkit.org/show_bug.cgi?id=200107 Reviewed by Geoffrey Garen. Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Test: fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html * page/ChromeClient.h: * testing/Internals.cpp: (WebCore::Internals::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * testing/Internals.h: * testing/Internals.idl: 2019-08-06 Kocsen Chung Cherry-pick r247792. rdar://problem/54017900 Daring Fireball long press highlights are unnecessarily inflated due to false illegibility https://bugs.webkit.org/show_bug.cgi?id=200064 Reviewed by Geoff Garen. Source/WebCore: If we consider text illegible on the given estimated background color, we bail from doing a tightly fitted selection-only TextIndicator and instead just paint the page without modification into the indicator, causing ugly overlap and an excessively inflated indicator. Change the mechanism we use to determine illegibility to be based on a standard, instead of a constant chosen by hand 13 years ago. Test: fast/text-indicator/text-indicator-with-low-contrast-text.html * platform/graphics/ColorUtilities.cpp: (WebCore::luminance): Fix a typo. (WebCore::contrastRatio): Add a function that computes the contrast ratio given two colors using the formula from WCAG. * platform/graphics/ColorUtilities.h: * rendering/TextPaintStyle.cpp: (WebCore::textColorIsLegibleAgainstBackgroundColor): Make use of WCAG's minimum legible contrast ratio instead of an arbitrary color difference cutoff for determining whether we consider text legible. It seems sensible and also considers the text on DF readable (which it seems to be to me!). * testing/Internals.cpp: (WebCore::Internals::TextIndicatorInfo::TextIndicatorInfo): * testing/Internals.h: * testing/Internals.idl: Expose all of the text rects to Internals, not just the bounding rect. Expose some more TextIndicator options to Internals so that we can turn on the legibility mechanism. LayoutTests: * fast/text-indicator/text-indicator-with-low-contrast-text-expected.txt: Added. * fast/text-indicator/text-indicator-with-low-contrast-text.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247792 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Tim Horton Daring Fireball long press highlights are unnecessarily inflated due to false illegibility https://bugs.webkit.org/show_bug.cgi?id=200064 Reviewed by Geoff Garen. If we consider text illegible on the given estimated background color, we bail from doing a tightly fitted selection-only TextIndicator and instead just paint the page without modification into the indicator, causing ugly overlap and an excessively inflated indicator. Change the mechanism we use to determine illegibility to be based on a standard, instead of a constant chosen by hand 13 years ago. Test: fast/text-indicator/text-indicator-with-low-contrast-text.html * platform/graphics/ColorUtilities.cpp: (WebCore::luminance): Fix a typo. (WebCore::contrastRatio): Add a function that computes the contrast ratio given two colors using the formula from WCAG. * platform/graphics/ColorUtilities.h: * rendering/TextPaintStyle.cpp: (WebCore::textColorIsLegibleAgainstBackgroundColor): Make use of WCAG's minimum legible contrast ratio instead of an arbitrary color difference cutoff for determining whether we consider text legible. It seems sensible and also considers the text on DF readable (which it seems to be to me!). * testing/Internals.cpp: (WebCore::Internals::TextIndicatorInfo::TextIndicatorInfo): * testing/Internals.h: * testing/Internals.idl: Expose all of the text rects to Internals, not just the bounding rect. Expose some more TextIndicator options to Internals so that we can turn on the legibility mechanism. 2019-08-06 Kocsen Chung Cherry-pick r247756. rdar://problem/54017897 Long press hint has half blue shape in Feedly.com https://bugs.webkit.org/show_bug.cgi?id=200053 Reviewed by Simon Fraser. No new tests, because TextIndicator snapshots are not yet testable. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintForegroundForFragments): Paint ChildBlockBackgrounds when painting selection AND backgrounds; only exclude it when doing a selection-only paint. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247756 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Tim Horton Long press hint has half blue shape in Feedly.com https://bugs.webkit.org/show_bug.cgi?id=200053 Reviewed by Simon Fraser. No new tests, because TextIndicator snapshots are not yet testable. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintForegroundForFragments): Paint ChildBlockBackgrounds when painting selection AND backgrounds; only exclude it when doing a selection-only paint. 2019-08-06 Kocsen Chung Cherry-pick r247730. rdar://problem/54017873 Long press hint of AirPods buy buttons are tall and narrow during animation https://bugs.webkit.org/show_bug.cgi?id=200036 Reviewed by Wenson Hsieh. Source/WebCore: New test: fast/text-indicator/text-indicator-with-tiny-child.html * dom/Range.cpp: (WebCore::Range::borderAndTextRects const): * dom/Range.h: Add a BoundingRectBehavior that ignores 1x1 and smaller rects. * page/TextIndicator.cpp: (WebCore::absoluteBoundingRectForRange): Enable IgnoreTinyRects. LayoutTests: * fast/text-indicator/text-indicator-with-tiny-child-expected.txt: Added. * fast/text-indicator/text-indicator-with-tiny-child.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247730 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Tim Horton Long press hint of AirPods buy buttons are tall and narrow during animation https://bugs.webkit.org/show_bug.cgi?id=200036 Reviewed by Wenson Hsieh. New test: fast/text-indicator/text-indicator-with-tiny-child.html * dom/Range.cpp: (WebCore::Range::borderAndTextRects const): * dom/Range.h: Add a BoundingRectBehavior that ignores 1x1 and smaller rects. * page/TextIndicator.cpp: (WebCore::absoluteBoundingRectForRange): Enable IgnoreTinyRects. 2019-08-06 Kocsen Chung Cherry-pick r247720. rdar://problem/54017869 WebKit should strip away system font names from the pasted content https://bugs.webkit.org/show_bug.cgi?id=199975 Reviewed by Darin Adler. Source/WebCore: Cocoa HTML Writer sometimes generate system font names such as ".AppleSystemUIFont", ".SFUI-Regular", and ".SF UI Mono". We need to strip away these font names upon paste to avoid these font names falling back to Times New Roman. Added the code to strip these font names away in EditingStyle::mergeStyleFromRulesForSerialization, which is used by StylizedMarkupAccumulator to generate HTML during copy. This works because WebContentReader::readWebArchive invokes sanitizeMarkupWithArchive which inserts the pasteboard content into a temporary document then re-serializes back to HTML using StylizedMarkupAccumulator before the actual pasting happens. This approach has a few benefits over stripping away these font names in ReplaceSelectionCommand: 1. It would only affect clients that opts-in to copy & paste sanitization. e.g. it won't affect legacy WebKit clients and those that opt out of pasteboard content sanitization. 2. It preserves font names such as ".SF Blah" that a website may insert as some kind of house keeping purposes if ever. While we don't have any evidence that there is any such a website but it's a real risk nonetheless. The copy side fix would only affect cross-site and cross-app pasting, which is rare and less likely to affect real user scenarios. 3. It avoids exposing bogus .Apple* or .SF* font names to websites that directly use event.clipboardData.getData. Indeed stripping away bogus markup like this is one of the key features / benefit of using copy & paste sanitization. Test: editing/pasteboard/paste-cocoa-writer-markup-with-system-fonts.html * editing/EditingStyle.cpp: (WebCore::usesForbiddenSystemFontAsOnlyFontFamilyName): Added. (WebCore::EditingStyle::mergeStyleFromRulesForSerialization): Added the code to remove font-family property when needed. * platform/graphics/FontCache.h: * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::isSystemFont): Moved. (WebCore::FontCache::isSystemFontForbiddenForEditing): Added. * platform/graphics/freetype/FontCacheFreeType.cpp: (WebCore::FontCache::isSystemFontForbiddenForEditing): Added. Always returns false. * platform/graphics/win/FontCacheWin.cpp: (WebCore::FontCache::isSystemFontForbiddenForEditing): Ditto. Tools: Added a test to strip away system font names such as ".AppleSystemUIFont", ".SFUI-Regular", and ".SF UI Mono". * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm: * TestWebKitAPI/Tests/WebKitCocoa/cocoa-writer-markup-with-system-fonts.html: Added. LayoutTests: Added a test for ClipboardData.getData returning the original markup and execCommand('insertHTML', ~) not stripping away system font names. * editing/pasteboard/paste-cocoa-writer-markup-with-system-fonts-expected.txt: Added. * editing/pasteboard/paste-cocoa-writer-markup-with-system-fonts.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247720 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Ryosuke Niwa WebKit should strip away system font names from the pasted content https://bugs.webkit.org/show_bug.cgi?id=199975 Reviewed by Darin Adler. Cocoa HTML Writer sometimes generate system font names such as ".AppleSystemUIFont", ".SFUI-Regular", and ".SF UI Mono". We need to strip away these font names upon paste to avoid these font names falling back to Times New Roman. Added the code to strip these font names away in EditingStyle::mergeStyleFromRulesForSerialization, which is used by StylizedMarkupAccumulator to generate HTML during copy. This works because WebContentReader::readWebArchive invokes sanitizeMarkupWithArchive which inserts the pasteboard content into a temporary document then re-serializes back to HTML using StylizedMarkupAccumulator before the actual pasting happens. This approach has a few benefits over stripping away these font names in ReplaceSelectionCommand: 1. It would only affect clients that opts-in to copy & paste sanitization. e.g. it won't affect legacy WebKit clients and those that opt out of pasteboard content sanitization. 2. It preserves font names such as ".SF Blah" that a website may insert as some kind of house keeping purposes if ever. While we don't have any evidence that there is any such a website but it's a real risk nonetheless. The copy side fix would only affect cross-site and cross-app pasting, which is rare and less likely to affect real user scenarios. 3. It avoids exposing bogus .Apple* or .SF* font names to websites that directly use event.clipboardData.getData. Indeed stripping away bogus markup like this is one of the key features / benefit of using copy & paste sanitization. Test: editing/pasteboard/paste-cocoa-writer-markup-with-system-fonts.html * editing/EditingStyle.cpp: (WebCore::usesForbiddenSystemFontAsOnlyFontFamilyName): Added. (WebCore::EditingStyle::mergeStyleFromRulesForSerialization): Added the code to remove font-family property when needed. * platform/graphics/FontCache.h: * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::isSystemFont): Moved. (WebCore::FontCache::isSystemFontForbiddenForEditing): Added. * platform/graphics/freetype/FontCacheFreeType.cpp: (WebCore::FontCache::isSystemFontForbiddenForEditing): Added. Always returns false. * platform/graphics/win/FontCacheWin.cpp: (WebCore::FontCache::isSystemFontForbiddenForEditing): Ditto. 2019-08-06 Kocsen Chung Cherry-pick r247837. rdar://problem/53973599 Add helper for ignoring deprecated implementation warnings https://bugs.webkit.org/show_bug.cgi?id=200135 Reviewed by Wenson Hsieh. Add ALLOW_DEPRECATED_IMPLEMENTATIONS_BEGIN/END macro which is IGNORE_WARNINGS_BEGIN("deprecated-implementations") Source/WebCore: * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]): (-[WebAccessibilityObjectWrapper accessibilityIsAttributeSettable:]): (-[WebAccessibilityObjectWrapper accessibilityPerformAction:]): (-[WebAccessibilityObjectWrapper accessibilitySetValue:forAttribute:]): (-[WebAccessibilityObjectWrapper accessibilityActionDescription:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper IGNORE_WARNINGS_END]): Deleted. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (-[WebAVStreamDataParserListener streamDataParserWillProvideContentKeyRequestInitializationData:forTrackID:]): (-[WebAVStreamDataParserListener streamDataParser:didProvideContentKeyRequestInitializationData:forTrackID:]): * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveAuthenticationChallenge:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]): Source/WebKit: * UIProcess/API/Cocoa/LegacyBundleForClass.mm: * UIProcess/API/Cocoa/WKBrowsingContextController.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKBrowsingContextGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKConnection.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKPreviewElementInfo.mm: * UIProcess/API/Cocoa/WKProcessGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKTypeRefWrapper.mm: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebView draggedImage:endedAt:operation:]): (-[WKWebView accessibilityAttributeValue:]): (-[WKWebView accessibilityAttributeValue:forParameter:]): (-[WKWebView namesOfPromisedFilesDroppedAtDestination:]): (-[WKWebView IGNORE_WARNINGS_END]): Deleted. * UIProcess/API/Cocoa/WKWebViewConfiguration.mm: (-[WKWebViewConfiguration ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebViewConfiguration _setWebsiteDataStore:]): (-[WKWebViewConfiguration IGNORE_WARNINGS_END]): Deleted. * UIProcess/API/Cocoa/_WKWebsiteDataStore.mm: * UIProcess/API/mac/WKView.mm: (-[WKView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKView draggedImage:endedAt:operation:]): (-[WKView accessibilityAttributeValue:]): (-[WKView accessibilityAttributeValue:forParameter:]): (-[WKView namesOfPromisedFilesDroppedAtDestination:]): (-[WKView IGNORE_WARNINGS_END]): Deleted. * UIProcess/WKImagePreviewViewController.mm: (-[WKImagePreviewViewController ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKImagePreviewViewController IGNORE_WARNINGS_END]): Deleted. * UIProcess/ios/forms/WKAirPlayRoutePicker.mm: (-[WKAirPlayRoutePicker popoverControllerDidDismissPopover:]): * UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel popoverControllerDidDismissPopover:]): * UIProcess/ios/forms/WKFormPopover.mm: (-[WKRotatingPopover popoverControllerDidDismissPopover:]): * WebProcess/Plugins/PDF/PDFPlugin.mm: (-[WKPDFPluginAccessibilityObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:forParameter:]): (-[WKPDFPluginAccessibilityObject accessibilityPerformAction:]): (-[WKPDFPluginAccessibilityObject accessibilityIsAttributeSettable:]): (-[WKPDFPluginAccessibilityObject accessibilitySetValue:forAttribute:]): (-[WKPDFPluginAccessibilityObject IGNORE_WARNINGS_END]): Deleted. * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm: (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKAccessibilityWebPageObject accessibilityIsAttributeSettable:]): (-[WKAccessibilityWebPageObject accessibilitySetValue:forAttribute:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:forParameter:]): (-[WKAccessibilityWebPageObject IGNORE_WARNINGS_END]): Deleted. Source/WebKitLegacy/mac: * Misc/WebDownload.mm: (-[WebDownload initWithRequest:delegate:]): * Misc/WebIconDatabase.mm: * Plugins/WebBaseNetscapePluginView.mm: (-[WebBaseNetscapePluginView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebBaseNetscapePluginView IGNORE_WARNINGS_END]): Deleted. * WebView/WebDynamicScrollBarsView.mm: (-[WebDynamicScrollBarsView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebDynamicScrollBarsView IGNORE_WARNINGS_END]): Deleted. * WebView/WebHTMLView.mm: (-[WebHTMLView draggingSourceOperationMaskForLocal:]): (-[WebHTMLView draggedImage:endedAt:operation:]): (-[WebHTMLView namesOfPromisedFilesDroppedAtDestination:]): (-[WebHTMLView accessibilityAttributeValue:]): (-[WebHTMLView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebHTMLView characterIndexForPoint:]): (-[WebHTMLView firstRectForCharacterRange:]): (-[WebHTMLView attributedSubstringFromRange:]): (-[WebHTMLView setMarkedText:selectedRange:]): (-[WebHTMLView doCommandBySelector:]): (-[WebHTMLView insertText:]): (-[WebHTMLView IGNORE_WARNINGS_END]): Deleted. Source/WTF: * wtf/Compiler.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247837 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Dean Jackson Add helper for ignoring deprecated implementation warnings https://bugs.webkit.org/show_bug.cgi?id=200135 Reviewed by Wenson Hsieh. Add ALLOW_DEPRECATED_IMPLEMENTATIONS_BEGIN/END macro which is IGNORE_WARNINGS_BEGIN("deprecated-implementations") * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]): (-[WebAccessibilityObjectWrapper accessibilityIsAttributeSettable:]): (-[WebAccessibilityObjectWrapper accessibilityPerformAction:]): (-[WebAccessibilityObjectWrapper accessibilitySetValue:forAttribute:]): (-[WebAccessibilityObjectWrapper accessibilityActionDescription:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper IGNORE_WARNINGS_END]): Deleted. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (-[WebAVStreamDataParserListener streamDataParserWillProvideContentKeyRequestInitializationData:forTrackID:]): (-[WebAVStreamDataParserListener streamDataParser:didProvideContentKeyRequestInitializationData:forTrackID:]): * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveAuthenticationChallenge:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]): 2019-08-01 Kocsen Chung Cherry-pick r248095. rdar://problem/53820663 REGRESSION (r240942): first visually non-empty layout milestone is not reached in media documents until after the video finishes loading https://bugs.webkit.org/show_bug.cgi?id=200293 Reviewed by Alex Christensen. Source/WebCore: r240942 changed FrameView::qualifiesAsVisuallyNonEmpty() to consider only documents in the Interactive or Complete ready states as "finished parsing". Documents considered finished parsing can qualify as visually non-empty even without exceeding the visual character or pixel thresholds, but documents considered not finished must first exceed one of these thresholds in order to qualify as visually non-empty. HTMLDocuments are placed in the Interactive ready state by their HTMLDocumentParsers. However, HTMLDocument subclasses like ImageDocument and MediaDocument use their own custom parsers that never set the Interactive ready state on their documents; these documents go from Loading directly to Complete. In order for these HTMLDocument subclasses to be considered visually non-empty before they finish loading they must render something that exceeds the visual character or pixel thresholds. For image documents, rendering the image is usually enough to cross the threshold, but for media documents the visual pixel threshold was never crossed because videos did not contribute to the visually non-empty pixel count. As a result, media documents are not considered visually non-empty until the main resource finishes loading. On iOS this means that the layer tree remains frozen until this point, even though the media might have started autoplaying with audio long before it finished loading. Fix this by teaching RenderVideo to contribute the video player's size to FrameView's visually non-empty pixel count once the video player has loaded enough data to determine its intrinsic size. Videos that render more than 1024 pixels will qualify a media document as visually non-empty even when it is still loading its main resource. Added a new API test. * rendering/RenderImage.cpp: (WebCore::RenderImage::imageChanged): (WebCore::RenderImage::incrementVisuallyNonEmptyPixelCountIfNeeded): * rendering/RenderImage.h: * rendering/RenderVideo.cpp: (WebCore::RenderVideo::updateIntrinsicSize): Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/FirstVisuallyNonEmptyMilestone.mm: Renamed from Tools/TestWebKitAPI/Tests/WebKit/FirstVisuallyNonEmptyMilestoneWithDeferredScript.mm. (-[FirstPaintMessageHandler userContentController:didReceiveScriptMessage:]): (-[RenderingProgressNavigationDelegate _webView:renderingProgressDidChange:]): (-[RenderingProgressNavigationDelegate webView:didFinishNavigation:]): (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248095 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Andy Estes REGRESSION (r240942): first visually non-empty layout milestone is not reached in media documents until after the video finishes loading https://bugs.webkit.org/show_bug.cgi?id=200293 Reviewed by Alex Christensen. r240942 changed FrameView::qualifiesAsVisuallyNonEmpty() to consider only documents in the Interactive or Complete ready states as "finished parsing". Documents considered finished parsing can qualify as visually non-empty even without exceeding the visual character or pixel thresholds, but documents considered not finished must first exceed one of these thresholds in order to qualify as visually non-empty. HTMLDocuments are placed in the Interactive ready state by their HTMLDocumentParsers. However, HTMLDocument subclasses like ImageDocument and MediaDocument use their own custom parsers that never set the Interactive ready state on their documents; these documents go from Loading directly to Complete. In order for these HTMLDocument subclasses to be considered visually non-empty before they finish loading they must render something that exceeds the visual character or pixel thresholds. For image documents, rendering the image is usually enough to cross the threshold, but for media documents the visual pixel threshold was never crossed because videos did not contribute to the visually non-empty pixel count. As a result, media documents are not considered visually non-empty until the main resource finishes loading. On iOS this means that the layer tree remains frozen until this point, even though the media might have started autoplaying with audio long before it finished loading. Fix this by teaching RenderVideo to contribute the video player's size to FrameView's visually non-empty pixel count once the video player has loaded enough data to determine its intrinsic size. Videos that render more than 1024 pixels will qualify a media document as visually non-empty even when it is still loading its main resource. Added a new API test. * rendering/RenderImage.cpp: (WebCore::RenderImage::imageChanged): (WebCore::RenderImage::incrementVisuallyNonEmptyPixelCountIfNeeded): * rendering/RenderImage.h: * rendering/RenderVideo.cpp: (WebCore::RenderVideo::updateIntrinsicSize): 2019-07-29 Alan Coon Cherry-pick r247880. rdar://problem/53647904 Do not fire readystatechange events at documents about to get replaced by javascript URLs. and https://bugs.webkit.org/show_bug.cgi?id=198786 Reviewed by Ryosuke Niwa. Source/WebCore: Test: http/tests/dom/ready-state-on-javascript-replace.html We were firing too many readystatechange events, more than other browsers. Our behavior on this test with this patch now matches Chrome. (There was even an ancient FIXME alluding to this referencing a spec issue, and that issues has long been resolvedv) * loader/FrameLoader.cpp: (WebCore::FrameLoader::stopLoading): LayoutTests: * http/tests/dom/ready-state-on-javascript-replace-expected.txt: Added. * http/tests/dom/ready-state-on-javascript-replace.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247880 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-26 Brady Eidson Do not fire readystatechange events at documents about to get replaced by javascript URLs. and https://bugs.webkit.org/show_bug.cgi?id=198786 Reviewed by Ryosuke Niwa. Test: http/tests/dom/ready-state-on-javascript-replace.html We were firing too many readystatechange events, more than other browsers. Our behavior on this test with this patch now matches Chrome. (There was even an ancient FIXME alluding to this referencing a spec issue, and that issues has long been resolvedv) * loader/FrameLoader.cpp: (WebCore::FrameLoader::stopLoading): 2019-07-26 Babak Shafiei Cherry-pick r247755. rdar://problem/53575424 AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak https://bugs.webkit.org/show_bug.cgi?id=199988 Reviewed by Per Arne Vollan. Source/WebCore: Implement the reset state to cancel current speech jobs. * Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::startSpeakingImmediately): (WebCore::SpeechSynthesis::cancel): * platform/PlatformSpeechSynthesizer.h: * platform/ios/PlatformSpeechSynthesizerIOS.mm: (WebCore::PlatformSpeechSynthesizer::resetState): * platform/mac/PlatformSpeechSynthesizerMac.mm: (WebCore::PlatformSpeechSynthesizer::resetState): Source/WebKit: Improvements to WebSpeechSynthesis to avoid crashing and improve correctness. - Reset and cancel speech jobs on page close or reload (otherwise the synthesizer keeps talking after your page is gone) - Have a separate speech finish callback mechanism, use the start speaking callback when the synthesizer tells us. - Move an assert on utterance state to only apply when we use the in process synthesizer. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::didStartSpeaking): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::resetSpeechSynthesizer): (WebKit::WebPageProxy::speechSynthesisSetFinishedCallback): (WebKit::WebPageProxy::speechSynthesisSpeak): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp: (WebKit::WebSpeechSynthesisClient::speak): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247755 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Chris Fleizach AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak https://bugs.webkit.org/show_bug.cgi?id=199988 Reviewed by Per Arne Vollan. Implement the reset state to cancel current speech jobs. * Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::startSpeakingImmediately): (WebCore::SpeechSynthesis::cancel): * platform/PlatformSpeechSynthesizer.h: * platform/ios/PlatformSpeechSynthesizerIOS.mm: (WebCore::PlatformSpeechSynthesizer::resetState): * platform/mac/PlatformSpeechSynthesizerMac.mm: (WebCore::PlatformSpeechSynthesizer::resetState): 2019-07-26 Babak Shafiei Cherry-pick r247734. rdar://problem/53575398 Fix crashes in ScrollingStateNode::insertChild() https://bugs.webkit.org/show_bug.cgi?id=200023 rdar://problem/53265378 Reviewed by Darin Adler. Crash data suggest that ScrollingStateNode::insertChild() can be passed an index that is larger than the size of the vector, causing crashes. Fix defensively by falling back to append() if the passed index is equal to or larger than the size of the children vector. * page/scrolling/ScrollingStateNode.cpp: (WebCore::ScrollingStateNode::insertChild): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247734 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Simon Fraser Fix crashes in ScrollingStateNode::insertChild() https://bugs.webkit.org/show_bug.cgi?id=200023 rdar://problem/53265378 Reviewed by Darin Adler. Crash data suggest that ScrollingStateNode::insertChild() can be passed an index that is larger than the size of the vector, causing crashes. Fix defensively by falling back to append() if the passed index is equal to or larger than the size of the children vector. * page/scrolling/ScrollingStateNode.cpp: (WebCore::ScrollingStateNode::insertChild): 2019-07-26 Babak Shafiei Cherry-pick r247702. rdar://problem/53575418 [iOS] [WK1] UIWebView always jumps to the top left corner when scrolling to reveal the selection https://bugs.webkit.org/show_bug.cgi?id=200013 Reviewed by Simon Fraser. Source/WebCore: After , we no longer attempt to scroll to reveal the text selection in UIWebView after changing the selection, due to how we use the legacy document view rect in legacy WebKit when computing the visual viewport. This causes the viewRect in RenderLayer::scrollRectToVisible to be the same size as the content size, which then causes us to always scroll to the origin when revealing the selection. To make selection revealing work again in legacy WebKit, conditionally restore the old behavior of using the unobscured content rect as the view rect, only in the case where scrolling is delegated and the platform widget is present. Test: WebKitLegacy.ScrollToRevealSelection * page/FrameView.cpp: (WebCore::FrameView::viewRectExpandedByContentInsets const): (WebCore::FrameView::visualViewportRectExpandedByContentInsets const): Deleted. Additionally rename visualViewportRectExpandedByContentInsets to viewRectExpandedByContentInsets, to reflect the fact that this may either be the visual viewport rect or unobscured content rect. * page/FrameView.h: * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible): Tools: Add a new API test to verify that inserting text in UIWebView causes the document to scroll. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitLegacy/ios/ScrollToRevealSelection.mm: Added. (-[LegacyLoadingDelegate webViewDidFinishLoad:]): (-[LegacyLoadingDelegate waitForDidFinishLoad]): * TestWebKitAPI/ios/UIKitSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247702 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Wenson Hsieh [iOS] [WK1] UIWebView always jumps to the top left corner when scrolling to reveal the selection https://bugs.webkit.org/show_bug.cgi?id=200013 Reviewed by Simon Fraser. After , we no longer attempt to scroll to reveal the text selection in UIWebView after changing the selection, due to how we use the legacy document view rect in legacy WebKit when computing the visual viewport. This causes the viewRect in RenderLayer::scrollRectToVisible to be the same size as the content size, which then causes us to always scroll to the origin when revealing the selection. To make selection revealing work again in legacy WebKit, conditionally restore the old behavior of using the unobscured content rect as the view rect, only in the case where scrolling is delegated and the platform widget is present. Test: WebKitLegacy.ScrollToRevealSelection * page/FrameView.cpp: (WebCore::FrameView::viewRectExpandedByContentInsets const): (WebCore::FrameView::visualViewportRectExpandedByContentInsets const): Deleted. Additionally rename visualViewportRectExpandedByContentInsets to viewRectExpandedByContentInsets, to reflect the fact that this may either be the visual viewport rect or unobscured content rect. * page/FrameView.h: * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible): 2019-07-25 Alan Coon Cherry-pick r247620. rdar://problem/53519933 Crash under WebPage::boundaryEventOccurred https://bugs.webkit.org/show_bug.cgi?id=199907 Reviewed by Chris Fleizach. Add null pointer checks. No new tests, since I have not been able to reproduce this in a test. * Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::didStartSpeaking): (WebCore::SpeechSynthesis::didFinishSpeaking): (WebCore::SpeechSynthesis::didPauseSpeaking): (WebCore::SpeechSynthesis::didResumeSpeaking): (WebCore::SpeechSynthesis::speakingErrorOccurred): (WebCore::SpeechSynthesis::boundaryEventOccurred): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247620 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-18 Per Arne Vollan Crash under WebPage::boundaryEventOccurred https://bugs.webkit.org/show_bug.cgi?id=199907 Reviewed by Chris Fleizach. Add null pointer checks. No new tests, since I have not been able to reproduce this in a test. * Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::didStartSpeaking): (WebCore::SpeechSynthesis::didFinishSpeaking): (WebCore::SpeechSynthesis::didPauseSpeaking): (WebCore::SpeechSynthesis::didResumeSpeaking): (WebCore::SpeechSynthesis::speakingErrorOccurred): (WebCore::SpeechSynthesis::boundaryEventOccurred): 2019-07-24 Alan Coon Cherry-pick r247746. rdar://problem/53483298 [iOS] Tapping the search field on a search results page on zillow.com shows and immediately dismisses the keyboard https://bugs.webkit.org/show_bug.cgi?id=200044 Reviewed by Wenson Hsieh. Source/WebCore: 1. The keyboard gets dismissed as the result of scroll event. 2. The (horizontal)scroll event is initiated by WebKit as we try to re-center the content. 3. The content gets off-centered as the result of the newly constructed drop-down menu which slightly sticks out of the document to the right (layout overflows). It works with shipping version of iOS because _zoomToFocusRect operates on stale viewport information (see r244494 for the progression). This patch applies a site specific quirk to restore shipping behavior. * page/Quirks.cpp: (WebCore::Quirks::shouldAvoidScrollingWhenFocusedContentIsVisible const): * page/Quirks.h: Source/WebKit: * Shared/FocusedElementInformation.cpp: (WebKit::FocusedElementInformation::encode const): (WebKit::FocusedElementInformation::decode): * Shared/FocusedElementInformation.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidBlur]): (-[WKContentView _shouldAvoidScrollingWhenFocusedContentIsVisible]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getFocusedElementInformation): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247746 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Zalan Bujtas [iOS] Tapping the search field on a search results page on zillow.com shows and immediately dismisses the keyboard https://bugs.webkit.org/show_bug.cgi?id=200044 Reviewed by Wenson Hsieh. 1. The keyboard gets dismissed as the result of scroll event. 2. The (horizontal)scroll event is initiated by WebKit as we try to re-center the content. 3. The content gets off-centered as the result of the newly constructed drop-down menu which slightly sticks out of the document to the right (layout overflows). It works with shipping version of iOS because _zoomToFocusRect operates on stale viewport information (see r244494 for the progression). This patch applies a site specific quirk to restore shipping behavior. * page/Quirks.cpp: (WebCore::Quirks::shouldAvoidScrollingWhenFocusedContentIsVisible const): * page/Quirks.h: 2019-07-24 Alan Coon Cherry-pick r247674. rdar://problem/53483295 [iOS] Fast and complex text codepaths disagree about how to lay out bopomofo with tone marks https://bugs.webkit.org/show_bug.cgi?id=199912 Reviewed by Simon Fraser. Source/WebCore: This is because CoreText has special composition rules for CJK languages, which we don't have in our simple text codepath. Rather than implementing the composition rules in WebKit, we can simply disable them in CoreText. Test: fast/text/international/system-language/composition.html * platform/graphics/mac/SimpleFontDataCoreText.cpp: (WebCore::Font::getCFStringAttributes const): Source/WebCore/PAL: * pal/spi/cocoa/CoreTextSPI.h: LayoutTests: * css3/font-feature-font-face-local-expected.html: * css3/font-feature-font-face-local.html: * editing/mac/selection/word-thai-expected.txt: * editing/mac/selection/word-thai.html: * fast/text/international/system-language/composition-expected.txt: Added. * fast/text/international/system-language/composition.html: Added. * platform/ios/fast/text/crash-complex-text-surrogate-expected.txt: * svg/custom/glyph-selection-arabic-forms-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247674 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-21 Myles C. Maxfield [iOS] Fast and complex text codepaths disagree about how to lay out bopomofo with tone marks https://bugs.webkit.org/show_bug.cgi?id=199912 Reviewed by Simon Fraser. This is because CoreText has special composition rules for CJK languages, which we don't have in our simple text codepath. Rather than implementing the composition rules in WebKit, we can simply disable them in CoreText. Test: fast/text/international/system-language/composition.html * platform/graphics/mac/SimpleFontDataCoreText.cpp: (WebCore::Font::getCFStringAttributes const): 2019-07-24 Alan Coon Cherry-pick r247671. rdar://problem/53501841 Add accessibilityInsertText for text insertion in edit fields. https://bugs.webkit.org/show_bug.cgi?id=199973 Patch by Andres Gonzalez on 2019-07-20 Reviewed by Chris Fleizach. Source/WebCore: Tests: accessibility/insert-newline.html accessibility/ios-simulator/insert-newline.html Accessibility clients like VoiceOver and Voice Control were entering text in text fields by replacing the entire content of the field (SetValue) and then setting the insertion point to the appropriate offset (SetSelectedTextRange). accessibilityInsertText gives a simpler interface to clients to insert text at the insertion point location. In addition, this provides a workaround for the issue encountered with the previous method when inserting a linebreak. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::insertText): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityInsertText:]): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityInsertText:]): Tools: Glue code to run new LayoutTests. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp: (WTR::AccessibilityUIElement::insertText): * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::insertText): * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::insertText): * WebKitTestRunner/InjectedBundle/win/AccessibilityUIElementWin.cpp: (WTR::AccessibilityUIElement::insertText): LayoutTests: Tests for inserting a newline in the middle of a text line and checking that the insertion point and text ranges are correct. * accessibility/insert-newline-expected.txt: Added. * accessibility/insert-newline.html: Added. * accessibility/ios-simulator/insert-newline-expected.txt: Added. * accessibility/ios-simulator/insert-newline.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247671 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-20 Andres Gonzalez Add accessibilityInsertText for text insertion in edit fields. https://bugs.webkit.org/show_bug.cgi?id=199973 Reviewed by Chris Fleizach. Tests: accessibility/insert-newline.html accessibility/ios-simulator/insert-newline.html Accessibility clients like VoiceOver and Voice Control were entering text in text fields by replacing the entire content of the field (SetValue) and then setting the insertion point to the appropriate offset (SetSelectedTextRange). accessibilityInsertText gives a simpler interface to clients to insert text at the insertion point location. In addition, this provides a workaround for the issue encountered with the previous method when inserting a linebreak. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::insertText): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityInsertText:]): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityInsertText:]): 2019-07-24 Alan Coon Apply patch. rdar://problem/53457282 Disable ENABLE_LAYOUT_FORMATTING_CONTEXT https://bugs.webkit.org/show_bug.cgi?id=200038 Reviewed by Zalan Bujtas. This feature is not complete. It is enabled for the trunk, but needs to be disabled in branches for shipping products. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: No new tests -- this change does not add any new functionality. * Configurations/FeatureDefines.xcconfig: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: 2019-07-23 Keith Rollin Disable ENABLE_LAYOUT_FORMATTING_CONTEXT https://bugs.webkit.org/show_bug.cgi?id=200038 Reviewed by Zalan Bujtas. This feature is not complete. It is enabled for the trunk, but needs to be disabled in branches for shipping products. No new tests -- this change does not add any new functionality. * Configurations/FeatureDefines.xcconfig: 2019-07-23 Kocsen Chung Cherry-pick r247701. rdar://problem/53449750 Correct web audio-related crash in seed reports https://bugs.webkit.org/show_bug.cgi?id=200009 Reviewed by Per Arne Vollan. Source/WebCore: Update the 'createMix' method to do proper return value checking so that we can clear the result of MTAudioProcessingTapCreate if the create operation failed. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::createMix): Source/WebKit: Revise the iOS sandbox to allow the WebContent process to communicate with the 'com.apple.coremedia.audioprocessingtap.xpc' service, which is needed by some types of WebAudio. * WebProcess/com.apple.WebKit.WebContent.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247701 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Brent Fulgham Correct web audio-related crash in seed reports https://bugs.webkit.org/show_bug.cgi?id=200009 Reviewed by Per Arne Vollan. Update the 'createMix' method to do proper return value checking so that we can clear the result of MTAudioProcessingTapCreate if the create operation failed. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::createMix): 2019-07-23 Kocsen Chung Cherry-pick r247652. rdar://problem/53449720 Add a menu item to toggle between showing and hiding link previews https://bugs.webkit.org/show_bug.cgi?id=199940 Reviewed by Beth Dakin. Source/WebCore: New strings for Show/Hide Link Previews. * en.lproj/Localizable.strings: Source/WebKit: Add a new _WKElementAction that toggles the display of link previews in context menus, and add it to the default set of actions we provide for links. When a UIAction is created from this new _WKElementAction type, it can be identified by WKElementActionTypeToggleShowLinkPreviewsIdentifier. This allows us to check a UIMenu provided by a delegate to make sure that they have provided the toggle menu item. If they haven't, we add it back. The preference for showing links is moved from kCFPreferencesAnyApplication to standard user defaults, so that it can be set no matter what the hosting application is. * UIProcess/API/Cocoa/_WKElementAction.h: New action type. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction _elementActionWithType:customTitle:assistant:]): (+[_WKElementAction imageForElementActionType:]): Use eye.fill for now. I'll need to check with HI to see if there is a more appropriate glyph. (elementActionTypeToUIActionIdentifier): (uiActionIdentifierToElementActionType): * UIProcess/ios/WKActionSheetAssistant.mm: Add the toggle action to the default set. (-[WKActionSheetAssistant defaultActionsForLinkSheet:]): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _registerPreview]): No need to listen for CFPreferences notifications any more. (-[WKContentView _unregisterPreview]): (menuWithShowLinkPreviewAction): New method that adds the UIAction for toggling previews to a UIMenu if necessary. (-[WKContentView assignLegacyDataForContextMenuInteraction]): (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]): (-[WKContentView _showLinkPreviewsPreferenceChanged:]): Deleted. (titleForMenu): Deleted. URL text previews will be provided separately. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247652 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Dean Jackson Add a menu item to toggle between showing and hiding link previews https://bugs.webkit.org/show_bug.cgi?id=199940 Reviewed by Beth Dakin. New strings for Show/Hide Link Previews. * en.lproj/Localizable.strings: 2019-07-23 Kocsen Chung Cherry-pick r247650. rdar://problem/53449733 Links stop working after long-pressing a link (WK1) https://bugs.webkit.org/show_bug.cgi?id=199952 Patch by Antoine Quint on 2019-07-19 Reviewed by Wenson Hsieh. Source/WebCore: Test: fast/events/touch/ios/click-after-long-press.html When EventHandler::tryToBeginDragAtPoint() is called, we must reset m_mousePressed to false so that WebChromeClientIOS::observedContentChange() is called by EventHandler::mousePressed() when we would process the next tap after a drag interaction. * page/ios/EventHandlerIOS.mm: (WebCore::EventHandler::tryToBeginDragAtPoint): LayoutTests: * fast/events/touch/ios/click-after-long-press-expected.txt: Added. * fast/events/touch/ios/click-after-long-press.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247650 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Antoine Quint Links stop working after long-pressing a link (WK1) https://bugs.webkit.org/show_bug.cgi?id=199952 Reviewed by Wenson Hsieh. Test: fast/events/touch/ios/click-after-long-press.html When EventHandler::tryToBeginDragAtPoint() is called, we must reset m_mousePressed to false so that WebChromeClientIOS::observedContentChange() is called by EventHandler::mousePressed() when we would process the next tap after a drag interaction. * page/ios/EventHandlerIOS.mm: (WebCore::EventHandler::tryToBeginDragAtPoint): 2019-07-18 Alan Coon Cherry-pick r247568. rdar://problem/53279098 REGRESSION: Panning on an Amazon product image scrolls the page on iPadOS https://bugs.webkit.org/show_bug.cgi?id=199905 Reviewed by Dean Jackson. Amazon product pages include images that the user can touch and pan to show zoomed details in a side image. This currently works on iPadOS thanks to the dispatch of simulated "mousemove" events on the product image, but the site doesn't call preventDefault() when handling those events as it wasn't necessary for macOS. We add a new quirk that will indicate that a given element is such a product image. * page/Quirks.cpp: (WebCore::Quirks::isAmazon const): (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): (WebCore::Quirks::shouldDispatchedSimulatedMouseEventsAssumeDefaultPrevented const): (WebCore::Quirks::simulatedMouseEventTypeForTarget const): * page/Quirks.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247568 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-18 Antoine Quint REGRESSION: Panning on an Amazon product image scrolls the page on iPadOS https://bugs.webkit.org/show_bug.cgi?id=199905 Reviewed by Dean Jackson. Amazon product pages include images that the user can touch and pan to show zoomed details in a side image. This currently works on iPadOS thanks to the dispatch of simulated "mousemove" events on the product image, but the site doesn't call preventDefault() when handling those events as it wasn't necessary for macOS. We add a new quirk that will indicate that a given element is such a product image. * page/Quirks.cpp: (WebCore::Quirks::isAmazon const): (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): (WebCore::Quirks::shouldDispatchedSimulatedMouseEventsAssumeDefaultPrevented const): (WebCore::Quirks::simulatedMouseEventTypeForTarget const): * page/Quirks.h: 2019-07-18 Alan Coon Cherry-pick r247566. rdar://problem/53279081 Make sure to set kCTFontFallbackOptionAttribute to kCTFontFallbackOptionSystem for system fonts https://bugs.webkit.org/show_bug.cgi?id=199769 Reviewed by Myles C. Maxfield. Source/WebCore: When getting a system font, set the appropriate attribute so that it does not fallback to a user initiated font. Add an ASSERT that checks that the font in use is not a user font if policy is to not use user installed fonts. Tests: fast/text/user-installed-fonts/extended-character-with-user-font.html fast/text/user-installed-fonts/extended-character.html * platform/graphics/Font.h: * platform/graphics/FontCascadeFonts.cpp: (WebCore::FontCascadeFonts::glyphDataForSystemFallback): * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::preparePlatformFont): (WebCore::FontDatabase::singletonAllowingUserInstalledFonts): (WebCore::FontDatabase::singletonDisallowingUserInstalledFonts): (WebCore::addAttributesForInstalledFonts): (WebCore::addAttributesForWebFonts): (WebCore::installedFontMandatoryAttributes): * platform/graphics/mac/SimpleFontDataCoreText.cpp: (WebCore::Font::isUserInstalledFont const): Source/WTF: * wtf/Platform.h: Tools: Add a font containing one extended character not found in system fonts. * WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj: * WebKitTestRunner/fonts/FakeHelvetica-SingleExtendedCharacter.ttf: Added. LayoutTests: Tests require WTR and recent MacOS, hence why they are disabled elsewhere. * TestExpectations: * platform/mac-wk2/TestExpectations: * fast/text/user-installed-fonts/extended-character-expected.html: Added. * fast/text/user-installed-fonts/extended-character-with-user-font-expected-mismatch.html: Added. * fast/text/user-installed-fonts/extended-character-with-user-font.html: Added. * fast/text/user-installed-fonts/extended-character.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247566 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-18 Youenn Fablet Make sure to set kCTFontFallbackOptionAttribute to kCTFontFallbackOptionSystem for system fonts https://bugs.webkit.org/show_bug.cgi?id=199769 Reviewed by Myles C. Maxfield. When getting a system font, set the appropriate attribute so that it does not fallback to a user initiated font. Add an ASSERT that checks that the font in use is not a user font if policy is to not use user installed fonts. Tests: fast/text/user-installed-fonts/extended-character-with-user-font.html fast/text/user-installed-fonts/extended-character.html * platform/graphics/Font.h: * platform/graphics/FontCascadeFonts.cpp: (WebCore::FontCascadeFonts::glyphDataForSystemFallback): * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::preparePlatformFont): (WebCore::FontDatabase::singletonAllowingUserInstalledFonts): (WebCore::FontDatabase::singletonDisallowingUserInstalledFonts): (WebCore::addAttributesForInstalledFonts): (WebCore::addAttributesForWebFonts): (WebCore::installedFontMandatoryAttributes): * platform/graphics/mac/SimpleFontDataCoreText.cpp: (WebCore::Font::isUserInstalledFont const): 2019-07-18 Alan Coon Cherry-pick r247562. rdar://problem/53279086 [LFC][IFC] InlineFormattingContext::LineLayout::placeInlineItems is getting too complex. https://bugs.webkit.org/show_bug.cgi?id=199898 Reviewed by Antti Koivisto. It's time to restructure LineLayout::placeInlineItems to be able to expand it further. Introduce the LineLayout class. This class is responsible to place the inline items on the current line. (Rename InlineFormattingContext::lineLayout -> InlineFormattingContext::InlineLayout and use Line::InitialConstraints in LineInput) * layout/inlineformatting/InlineFormattingContext.cpp: (WebCore::Layout::InlineFormattingContext::layout const): (WebCore::Layout::InlineFormattingContext::computeIntrinsicWidthConstraints const): * layout/inlineformatting/InlineFormattingContext.h: (WebCore::Layout::InlineFormattingContext::LineLayout::layoutState const): Deleted. * layout/inlineformatting/InlineFormattingContextLineLayout.cpp: (WebCore::Layout::inlineItemWidth): (WebCore::Layout::LineLayout::layoutState const): (WebCore::Layout::LineLayout::UncommittedContent::runs): (WebCore::Layout::LineLayout::UncommittedContent::isEmpty const): (WebCore::Layout::LineLayout::UncommittedContent::size const): (WebCore::Layout::LineLayout::UncommittedContent::width const): (WebCore::Layout::LineLayout::UncommittedContent::add): (WebCore::Layout::LineLayout::UncommittedContent::reset): (WebCore::Layout::LineLayout::LineLayout): (WebCore::Layout::LineLayout::commitPendingContent): (WebCore::Layout::LineLayout::close): (WebCore::Layout::LineLayout::layout): (WebCore::Layout::LineInput::LineInput): (WebCore::Layout::InlineFormattingContext::InlineLayout::InlineLayout): (WebCore::Layout::InlineFormattingContext::InlineLayout::layout const): (WebCore::Layout::InlineFormattingContext::InlineLayout::computedIntrinsicWidth const): (WebCore::Layout::InlineFormattingContext::InlineLayout::createDisplayRuns const): (WebCore::Layout::InlineFormattingContext::InlineLayout::alignRuns const): (WebCore::Layout::UncommittedContent::runs): Deleted. (WebCore::Layout::UncommittedContent::isEmpty const): Deleted. (WebCore::Layout::UncommittedContent::size const): Deleted. (WebCore::Layout::UncommittedContent::width const): Deleted. (WebCore::Layout::UncommittedContent::add): Deleted. (WebCore::Layout::UncommittedContent::reset): Deleted. (WebCore::Layout::LineInput::HorizontalConstraint::HorizontalConstraint): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::LineLayout): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::placeInlineItems const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::layout const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::computedIntrinsicWidth const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::createDisplayRuns const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::alignRuns const): Deleted. * layout/inlineformatting/InlineLine.cpp: (WebCore::Layout::Line::Line): * layout/inlineformatting/InlineLine.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247562 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-18 Zalan Bujtas [LFC][IFC] InlineFormattingContext::LineLayout::placeInlineItems is getting too complex. https://bugs.webkit.org/show_bug.cgi?id=199898 Reviewed by Antti Koivisto. It's time to restructure LineLayout::placeInlineItems to be able to expand it further. Introduce the LineLayout class. This class is responsible to place the inline items on the current line. (Rename InlineFormattingContext::lineLayout -> InlineFormattingContext::InlineLayout and use Line::InitialConstraints in LineInput) * layout/inlineformatting/InlineFormattingContext.cpp: (WebCore::Layout::InlineFormattingContext::layout const): (WebCore::Layout::InlineFormattingContext::computeIntrinsicWidthConstraints const): * layout/inlineformatting/InlineFormattingContext.h: (WebCore::Layout::InlineFormattingContext::LineLayout::layoutState const): Deleted. * layout/inlineformatting/InlineFormattingContextLineLayout.cpp: (WebCore::Layout::inlineItemWidth): (WebCore::Layout::LineLayout::layoutState const): (WebCore::Layout::LineLayout::UncommittedContent::runs): (WebCore::Layout::LineLayout::UncommittedContent::isEmpty const): (WebCore::Layout::LineLayout::UncommittedContent::size const): (WebCore::Layout::LineLayout::UncommittedContent::width const): (WebCore::Layout::LineLayout::UncommittedContent::add): (WebCore::Layout::LineLayout::UncommittedContent::reset): (WebCore::Layout::LineLayout::LineLayout): (WebCore::Layout::LineLayout::commitPendingContent): (WebCore::Layout::LineLayout::close): (WebCore::Layout::LineLayout::layout): (WebCore::Layout::LineInput::LineInput): (WebCore::Layout::InlineFormattingContext::InlineLayout::InlineLayout): (WebCore::Layout::InlineFormattingContext::InlineLayout::layout const): (WebCore::Layout::InlineFormattingContext::InlineLayout::computedIntrinsicWidth const): (WebCore::Layout::InlineFormattingContext::InlineLayout::createDisplayRuns const): (WebCore::Layout::InlineFormattingContext::InlineLayout::alignRuns const): (WebCore::Layout::UncommittedContent::runs): Deleted. (WebCore::Layout::UncommittedContent::isEmpty const): Deleted. (WebCore::Layout::UncommittedContent::size const): Deleted. (WebCore::Layout::UncommittedContent::width const): Deleted. (WebCore::Layout::UncommittedContent::add): Deleted. (WebCore::Layout::UncommittedContent::reset): Deleted. (WebCore::Layout::LineInput::HorizontalConstraint::HorizontalConstraint): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::LineLayout): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::placeInlineItems const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::layout const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::computedIntrinsicWidth const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::createDisplayRuns const): Deleted. (WebCore::Layout::InlineFormattingContext::LineLayout::alignRuns const): Deleted. * layout/inlineformatting/InlineLine.cpp: (WebCore::Layout::Line::Line): * layout/inlineformatting/InlineLine.h: 2019-07-18 Alan Coon Revert r247531. rdar://problem/53229712 2019-07-18 Kocsen Chung Cherry-pick r247555. rdar://problem/53254411 Prewarm local storage in the NetworkProcess to reduce WebContent process hangs https://bugs.webkit.org/show_bug.cgi?id=199879 Reviewed by Ryosuke Niwa. Source/WebCore: When JS accesses window.localStorage for the first time, we end up doing a synchronous IPC to the network process to pull in all items in the local storage for the origin. If the network process does not have this data in memory, it has to read it from a database on disk, which may take a significant amount of time and hang the WebContent process during this time. To alleviate this problem, this patch introduces prewarming on the local storage in the network process when loading a given origin in the WebContent process. This way, in most cases, when the JS accesses window.localStorage for the first time, the synchronous IPC to the network process returns much faster (measured 50-100ms for a very large database, down from 250-300ms), as it only needs to IPC the data over, without the need to fetch it from disk. As a safety net to avoid excessive prewarming, we currently prewarm at most 5 security origins per page load. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::commitData): * page/DOMWindow.cpp: (WebCore::DOMWindow::prewarmLocalStorageIfNecessary): * page/DOMWindow.h: * page/Frame.cpp: (WebCore::Frame::didPrewarmLocalStorage): (WebCore::Frame::mayPrewarmLocalStorage const): * page/Frame.h: * storage/Storage.cpp: (WebCore::Storage::prewarm): * storage/Storage.h: * storage/StorageArea.h: (WebCore::StorageArea::prewarm): Source/WebKit: * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::prewarm): (WebKit::StorageManager::getValues): * NetworkProcess/WebStorage/StorageManager.h: * NetworkProcess/WebStorage/StorageManager.messages.in: * WebProcess/WebStorage/StorageAreaImpl.cpp: (WebKit::StorageAreaImpl::prewarm): * WebProcess/WebStorage/StorageAreaImpl.h: * WebProcess/WebStorage/StorageAreaMap.cpp: (WebKit::StorageAreaMap::loadValuesIfNeeded): (WebKit::StorageAreaMap::prewarm): * WebProcess/WebStorage/StorageAreaMap.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247555 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Chris Dumez Prewarm local storage in the NetworkProcess to reduce WebContent process hangs https://bugs.webkit.org/show_bug.cgi?id=199879 Reviewed by Ryosuke Niwa. When JS accesses window.localStorage for the first time, we end up doing a synchronous IPC to the network process to pull in all items in the local storage for the origin. If the network process does not have this data in memory, it has to read it from a database on disk, which may take a significant amount of time and hang the WebContent process during this time. To alleviate this problem, this patch introduces prewarming on the local storage in the network process when loading a given origin in the WebContent process. This way, in most cases, when the JS accesses window.localStorage for the first time, the synchronous IPC to the network process returns much faster (measured 50-100ms for a very large database, down from 250-300ms), as it only needs to IPC the data over, without the need to fetch it from disk. As a safety net to avoid excessive prewarming, we currently prewarm at most 5 security origins per page load. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::commitData): * page/DOMWindow.cpp: (WebCore::DOMWindow::prewarmLocalStorageIfNecessary): * page/DOMWindow.h: * page/Frame.cpp: (WebCore::Frame::didPrewarmLocalStorage): (WebCore::Frame::mayPrewarmLocalStorage const): * page/Frame.h: * storage/Storage.cpp: (WebCore::Storage::prewarm): * storage/Storage.h: * storage/StorageArea.h: (WebCore::StorageArea::prewarm): 2019-07-17 Kocsen Chung Cherry-pick r247544. rdar://problem/53230040 Unable to bring up custom media controls on iOS for video.sina.cn https://bugs.webkit.org/show_bug.cgi?id=199889 Reviewed by Dean Jackson. Source/WebCore: Videos on video.sina.cn by default have the "controls" attribute and are set not to autoplay. This means that the original state of the media controls are set to show the built-in media controls and also show the prominent play button to begin playback. The display of the play button also requires a tap gesture recognizer, which calls preventDefault() when the "touchend" is received to prevent double-tap-to-zoom, but also has the side-effect of preventing a "click" event from being dispatched for a tap. The video.sina.cn code would eventually remove the "controls" attribute, which would make the built-in media controls not visible, but still participate in hit-testing because we keep the shadow DOM around in order to potentially show the Airplay or picture-in-picture placards. Additionally, we wouldn't disable the tap gesture recognizer when the "controls" attribute was removed. We now ensure that both gesture recognizers used by iOS inline media controls are only enabled when media controls are visible. Test: media/modern-media-controls/media-controller/ios/media-controller-allows-click-over-video-with-no-controls.html * Modules/modern-media-controls/controls/ios-inline-media-controls.js: (IOSInlineMediaControls.prototype.set showsStartButton): (IOSInlineMediaControls.prototype.get visible): (IOSInlineMediaControls.prototype.set visible): (IOSInlineMediaControls.prototype._updateGestureRecognizers): (IOSInlineMediaControls.prototype._tapGestureRecognizerStateDidChange): (IOSInlineMediaControls.prototype._pinchGestureRecognizerStateDidChange): LayoutTests: This test replicates the scenario found on video.sina.cn that caused the issue: a