2019-11-18 Kocsen Chung Apply patch. rdar://problem/57283187 2019-11-18 John Wilander Check if ITP is on before applying third-party cookie blocking https://bugs.webkit.org/show_bug.cgi?id=204109 Reviewed by Chris Dumez and Alexey Proskuryakov. This change makes sure WebCore::NetworkStorageSession knows whether ITP is on or off and checks that first thing in WebCore::NetworkStorageSession::shouldBlockCookies(). This check was never needed before since if ITP was off, there would be no classified domains and thus the function would always return false. However, https://trac.webkit.org/changeset/251353/webkit introduced full third-party cookie blocking for websites without user interaction and that rule is checked before checking domain classification. The effect was unconditional third-party cookie blocking if ITP is off. This changes fixes that bug. Note that this patch is branch-specific and expected to not apply to trunk. Test: http/tests/resourceLoadStatistics/no-third-party-cookie-blocking-when-itp-is-off.html * platform/network/NetworkStorageSession.cpp: (WebCore::NetworkStorageSession::shouldBlockThirdPartyCookies const): (WebCore::NetworkStorageSession::shouldBlockCookies const): Now checks whether ITP is on or off. * platform/network/NetworkStorageSession.h: (WebCore::NetworkStorageSession::setResourceLoadStatisticsEnabled): 2019-11-10 Kocsen Chung Cherry-pick r252297. rdar://problem/57040122 [WebAuthn] Add quirk needed to support legacy Google NFC Titan security keys https://bugs.webkit.org/show_bug.cgi?id=204024 Reviewed by Brent Fulgham. Source/WebCore: Covered by manual tests. * Modules/webauthn/fido/FidoConstants.h: Source/WebKit: Some legacy U2F keys such as Google T1 Titan don't understand the FIDO applet command. Instead, they are configured to only have the FIDO applet. Therefore, when the above command fails, we use U2F_VERSION command to double check if the connected tag can actually speak U2F, indicating we are interacting with one of these legacy keys. * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm: (WebKit::fido::compareVersion): (WebKit::fido::trySelectFidoApplet): (WebKit::NfcConnection::transact const): (WebKit::NfcConnection::didDetectTags): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@252297 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-11-08 Jiewen Tan [WebAuthn] Add quirk needed to support legacy Google NFC Titan security keys https://bugs.webkit.org/show_bug.cgi?id=204024 Reviewed by Brent Fulgham. Covered by manual tests. * Modules/webauthn/fido/FidoConstants.h: 2019-11-04 Alan Coon Cherry-pick r251957. rdar://problem/56887511 SVG pair properties must be detached from their owner before it's deleted https://bugs.webkit.org/show_bug.cgi?id=203545 Reviewed by Simon Fraser. Source/WebCore: SVGAnimatedPropertyPairAccessor needs to override its detach() method so each of its pair properties detaches itself from the owner. SVGPointerMemberAccessor does the same thing but for a single property which covers all the list properties as well. Test: svg/custom/pair-properties-detach.html * svg/properties/SVGAnimatedPropertyPairAccessor.h: LayoutTests: * svg/custom/pair-properties-detach-expected.txt: Added. * svg/custom/pair-properties-detach.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251957 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-11-01 Said Abou-Hallawa SVG pair properties must be detached from their owner before it's deleted https://bugs.webkit.org/show_bug.cgi?id=203545 Reviewed by Simon Fraser. SVGAnimatedPropertyPairAccessor needs to override its detach() method so each of its pair properties detaches itself from the owner. SVGPointerMemberAccessor does the same thing but for a single property which covers all the list properties as well. Test: svg/custom/pair-properties-detach.html * svg/properties/SVGAnimatedPropertyPairAccessor.h: 2019-11-04 Kocsen Chung Cherry-pick r248552. rdar://problem/56868427 Replace multiparameter overloads of append() in StringBuilder as a first step toward standardizinging on the flexibleAppend() implementation https://bugs.webkit.org/show_bug.cgi?id=200614 Reviewed by Darin Adler. Renames StringBuilder::append(const LChar*, unsigned), StringBuilder::append(const UChar*, unsigned) and StringBuilder::append(const char*, unsigned) to StringBuilder::appendCharacters(...). Renames StringBuilder::append(const String& string, unsigned offset, unsigned length) to StringBuilder::appendSubstring(...). Source/JavaScriptCore: * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * runtime/ConfigFile.cpp: (JSC::ConfigFile::parse): * runtime/LiteralParser.cpp: (JSC::LiteralParser::Lexer::lexStringSlow): * tools/FunctionOverrides.cpp: (JSC::parseClause): Update for renames. Source/WebCore: * dom/Range.cpp: (WebCore::Range::toString const): * editing/Editing.cpp: (WebCore::stringWithRebalancedWhitespace): * editing/MarkupAccumulator.cpp: (WebCore::appendCharactersReplacingEntitiesInternal): * editing/TextIterator.cpp: (WebCore::TextIteratorCopyableText::appendToStringBuilder const): * html/HTMLTextFormControlElement.cpp: (WebCore::HTMLTextFormControlElement::valueWithHardLineBreaks const): * html/parser/HTMLTokenizer.cpp: (WebCore::HTMLTokenizer::bufferedCharacters const): * platform/graphics/avfoundation/InbandTextTrackPrivateAVF.cpp: (WebCore::InbandTextTrackPrivateAVF::processNativeSamples): * platform/text/SegmentedString.cpp: (WebCore::SegmentedString::Substring::appendTo const): * platform/text/TextCodecICU.cpp: (WebCore::TextCodecICU::decode): * xml/XSLTProcessorLibxslt.cpp: (WebCore::writeToStringBuilder): Update for renames. Source/WebKit: * Shared/mac/AuxiliaryProcessMac.mm: (WebKit::setAndSerializeSandboxParameters): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::didReceiveInvalidMessage): Update for renames. Source/WTF: * wtf/HexNumber.h: (WTF::appendUnsignedAsHexFixedSize): Add overload that explicitly takes a StringBuilder to work around rename from append to appendCharacters. * wtf/text/StringBuilder.cpp: (WTF::StringBuilder::appendCharacters): (WTF::StringBuilder::append): * wtf/text/StringBuilder.h: (WTF::StringBuilder::appendCharacters): (WTF::StringBuilder::append): (WTF::StringBuilder::appendSubstring): (WTF::StringBuilder::appendLiteral): (WTF::IntegerToStringConversionTrait::flush): Update for renames. Tools: * TestWebKitAPI/Tests/WTF/StringBuilder.cpp: (TestWebKitAPI::TEST): Update for renames. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248552 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-12 Sam Weinig Replace multiparameter overloads of append() in StringBuilder as a first step toward standardizinging on the flexibleAppend() implementation https://bugs.webkit.org/show_bug.cgi?id=200614 Reviewed by Darin Adler. Renames StringBuilder::append(const LChar*, unsigned), StringBuilder::append(const UChar*, unsigned) and StringBuilder::append(const char*, unsigned) to StringBuilder::appendCharacters(...). Renames StringBuilder::append(const String& string, unsigned offset, unsigned length) to StringBuilder::appendSubstring(...). * dom/Range.cpp: (WebCore::Range::toString const): * editing/Editing.cpp: (WebCore::stringWithRebalancedWhitespace): * editing/MarkupAccumulator.cpp: (WebCore::appendCharactersReplacingEntitiesInternal): * editing/TextIterator.cpp: (WebCore::TextIteratorCopyableText::appendToStringBuilder const): * html/HTMLTextFormControlElement.cpp: (WebCore::HTMLTextFormControlElement::valueWithHardLineBreaks const): * html/parser/HTMLTokenizer.cpp: (WebCore::HTMLTokenizer::bufferedCharacters const): * platform/graphics/avfoundation/InbandTextTrackPrivateAVF.cpp: (WebCore::InbandTextTrackPrivateAVF::processNativeSamples): * platform/text/SegmentedString.cpp: (WebCore::SegmentedString::Substring::appendTo const): * platform/text/TextCodecICU.cpp: (WebCore::TextCodecICU::decode): * xml/XSLTProcessorLibxslt.cpp: (WebCore::writeToStringBuilder): Update for renames. 2019-11-04 Alan Coon Cherry-pick r251827. rdar://problem/56868427 Add fullscreen style quirk for reddit.com https://bugs.webkit.org/show_bug.cgi?id=203635 Reviewed by Eric Carlson. Reddit.com expects the UA stylesheet to give the fullscreen element a "width:100%; height:100%;" style. * css/CSSDefaultStyleSheets.cpp: (WebCore::CSSDefaultStyleSheets::ensureDefaultStyleSheetsForElement): * page/Quirks.cpp: (WebCore::Quirks::needsFullWidthHeightFullscreenStyleQuirk const): * page/Quirks.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251827 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-30 Jer Noble Add fullscreen style quirk for reddit.com https://bugs.webkit.org/show_bug.cgi?id=203635 Reviewed by Eric Carlson. Reddit.com expects the UA stylesheet to give the fullscreen element a "width:100%; height:100%;" style. * css/CSSDefaultStyleSheets.cpp: (WebCore::CSSDefaultStyleSheets::ensureDefaultStyleSheetsForElement): * page/Quirks.cpp: (WebCore::Quirks::needsFullWidthHeightFullscreenStyleQuirk const): * page/Quirks.h: 2019-10-29 Alan Coon Cherry-pick r251500. rdar://problem/56579657 [WebAuthn] Warn users when multiple NFC tags present https://bugs.webkit.org/show_bug.cgi?id=200932 Reviewed by Brent Fulgham. Source/WebCore: Covered by new tests in existing test file. * testing/MockWebAuthenticationConfiguration.h: (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::decode): * testing/MockWebAuthenticationConfiguration.idl: Adds a new test option. Source/WebKit: This patch utilizes -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] to inform clients about multiple physical tags are presenting such that clients can instruct users to select only one of them physically. Given a physical tag could have multiple different interfaces, which NearField will treat them into different NFTags, the tagID is then used to identify if there are actually multiple physical tags. This patch also adds the ability to restart polling of a partiuclar NFReaderSession to NfcConnection and the ability to restart the whole session to NfcService. The former is used to recover from errors in the discovery stages, and the latter is used to recover from errors returned from authenticators in the request stages. For the latter, given NfcConnection is not awared of the syntax of FIDO2/U2F protocol, and CtapAuthenticator/U2fAuthenticator are not awared the transport of the underneath driver. A generic restartDiscovery process is added to each service and it is up to the actual service to implement the actual process such that AuthenticatorManager can arbitrarily call it after exceptions are returned to restart the whole NFC session. To achieve restartDiscovery, NfcConnection is made RefCounted as well such that both the NfcService and the CtapNfcDriver could hold it at the same time. CtapNfcDriver uses the connection to complete requests as before while NfcService has the new capability to use it to stop the current session when restartDiscovery kicks off. * Platform/spi/Cocoa/NearFieldSPI.h: * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::serviceStatusUpdated): (WebKit::AuthenticatorManager::respondReceived): (WebKit::AuthenticatorManager::restartDiscovery): * UIProcess/WebAuthentication/AuthenticatorManager.h: * UIProcess/WebAuthentication/AuthenticatorTransportService.cpp: (WebKit::AuthenticatorTransportService::startDiscovery): (WebKit::AuthenticatorTransportService::restartDiscovery): * UIProcess/WebAuthentication/AuthenticatorTransportService.h: (WebKit::AuthenticatorTransportService::restartDiscoveryInternal): * UIProcess/WebAuthentication/Cocoa/NfcConnection.h: * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm: (WebKit::NfcConnection::create): (WebKit::NfcConnection::NfcConnection): (WebKit::NfcConnection::~NfcConnection): (WebKit::NfcConnection::stop const): (WebKit::NfcConnection::didDetectTags): (WebKit::NfcConnection::restartPolling): (WebKit::NfcConnection::startPolling): (WebKit::NfcConnection::didDetectTags const): Deleted. * UIProcess/WebAuthentication/Cocoa/NfcService.h: * UIProcess/WebAuthentication/Cocoa/NfcService.mm: (WebKit::NfcService::NfcService): (WebKit::NfcService::didConnectTag): (WebKit::NfcService::didDetectMultipleTags const): (WebKit::NfcService::setConnection): (WebKit::NfcService::restartDiscoveryInternal): (WebKit::NfcService::platformStartDiscovery): (WebKit::NfcService::setDriver): Deleted. * UIProcess/WebAuthentication/Mock/MockNfcService.h: * UIProcess/WebAuthentication/Mock/MockNfcService.mm: (-[WKMockNFTag tagID]): (-[WKMockNFTag initWithNFTag:]): (-[WKMockNFTag dealloc]): (-[WKMockNFTag initWithType:]): (-[WKMockNFTag initWithType:tagID:]): (WebKit::MockNfcService::receiveStopPolling): (WebKit::MockNfcService::receiveStartPolling): (WebKit::MockNfcService::platformStartDiscovery): (WebKit::MockNfcService::detectTags): (WebKit::MockNfcService::detectTags const): Deleted. * UIProcess/WebAuthentication/fido/CtapNfcDriver.cpp: (WebKit::CtapNfcDriver::CtapNfcDriver): * UIProcess/WebAuthentication/fido/CtapNfcDriver.h: * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp: Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: (-[TestWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:]): (TestWebKitAPI::TEST): Adds a new test for -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:]. * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion-nfc-multiple-tags.html: Added. LayoutTests: * http/wpt/webauthn/public-key-credential-create-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-nfc.https.html: Adds new tests for multiple physical tags and service restart. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251500 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-21 Jiewen Tan [WebAuthn] Warn users when multiple NFC tags present https://bugs.webkit.org/show_bug.cgi?id=200932 Reviewed by Brent Fulgham. Covered by new tests in existing test file. * testing/MockWebAuthenticationConfiguration.h: (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::decode): * testing/MockWebAuthenticationConfiguration.idl: Adds a new test option. 2019-10-29 Alan Coon Cherry-pick r251489. rdar://problem/56579665 [WebAuthn] Supply FrameInfo in -[WKUIDelegatePrivate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:] https://bugs.webkit.org/show_bug.cgi?id=202563 Reviewed by Brent Fulgham. Source/WebCore: Covered by new test contents within existing tests. * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::create const): (WebCore::AuthenticatorCoordinator::discoverFromExternalSource const): * Modules/webauthn/AuthenticatorCoordinatorClient.h: Source/WebKit: This patch makes WKFrameInfo available to clients via the above SPI. To do so, SecuirtyOrigin of the caller document is passed from WebContent Process. * UIProcess/API/APIUIClient.h: (API::UIClient::runWebAuthenticationPanel): * UIProcess/API/C/WKPage.cpp: (WKPageSetPageUIClient): * UIProcess/Cocoa/UIDelegate.h: * UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::UIClient::runWebAuthenticationPanel): * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::runPanel): * UIProcess/WebAuthentication/WebAuthenticationRequestData.h: * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp: (WebKit::WebAuthenticatorCoordinatorProxy::makeCredential): (WebKit::WebAuthenticatorCoordinatorProxy::getAssertion): (WebKit::WebAuthenticatorCoordinatorProxy::handleRequest): * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h: * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.messages.in: * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp: (WebKit::WebAuthenticatorCoordinator::makeCredential): (WebKit::WebAuthenticatorCoordinator::getAssertion): * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h: Tools: Adds new test contents into existing tests. * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: (-[TestWebAuthenticationPanelUIDelegate init]): (-[TestWebAuthenticationPanelUIDelegate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]): (-[TestWebAuthenticationPanelUIDelegate frame]): (TestWebKitAPI::TEST): LayoutTests: * http/wpt/webauthn/public-key-credential-get-success-hid.https.html: Imporves the flakiness. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251489 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-22 Jiewen Tan [WebAuthn] Supply FrameInfo in -[WKUIDelegatePrivate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:] https://bugs.webkit.org/show_bug.cgi?id=202563 Reviewed by Brent Fulgham. Covered by new test contents within existing tests. * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::create const): (WebCore::AuthenticatorCoordinator::discoverFromExternalSource const): * Modules/webauthn/AuthenticatorCoordinatorClient.h: 2019-10-29 Alan Coon Cherry-pick r251295. rdar://problem/56579665 [WebAuthn] Implement AuthenticatorCancel https://bugs.webkit.org/show_bug.cgi?id=191523 Reviewed by Brent Fulgham. Source/WebCore: Covered by new tests in existing test files. * Modules/credentialmanagement/CredentialsContainer.cpp: (WebCore::CredentialsContainer::get): (WebCore::CredentialsContainer::isCreate): * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::create const): (WebCore::AuthenticatorCoordinator::discoverFromExternalSource const): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.cpp: Removed. * Modules/webauthn/AuthenticatorCoordinatorClient.h: * Modules/webauthn/PublicKeyCredential.cpp: (WebCore::PublicKeyCredential::tryCreate): * Modules/webauthn/PublicKeyCredential.h: * Modules/webauthn/PublicKeyCredentialData.h: * Modules/webauthn/fido/DeviceRequestConverter.h: * Modules/webauthn/fido/FidoHidMessage.cpp: (fido::FidoHidMessage::FidoHidMessage): * Modules/webauthn/fido/FidoHidPacket.cpp: (fido::FidoHidInitPacket::getSerializedData const): (fido::FidoHidContinuationPacket::getSerializedData const): * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * testing/MockWebAuthenticationConfiguration.h: (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::decode): * testing/MockWebAuthenticationConfiguration.idl: Adds a new option to test AuthenticatorCancel. Source/WebKit: This patch implement two ways to cancel a pending WebAuthn ceremony: 1) Via navigation activities. Activities include i) main frame navigation, ii) main frame reload, iii) main frame destruction, iv) sub frame navigation, and v) sub frame destruction. All the above activities will cancel any pending WebAuthn ceremony that is associated with the frame. To prove the association, a GlobalFrameIdentifier is bridged into WebAuthenticationRequestData. Navigation cancel is done in WebPageProxy::didStartProvisionalLoadForFrameShared, and destruction cancel is done in WebProcessProxy::didDestroyFrame and WebPageProxy::resetState. 2) Via UI. This path is simply bridged -[_WKWebAuthenticationPanel cancel] into AuthenticatorManager. Noted, this patch follows the spec to wait until time out to notify RPs. References: i) Step 20 of https://www.w3.org/TR/webauthn/#createCredential, ii) Step 18 of https://www.w3.org/TR/webauthn/#getAssertion As for what the cancel actually does, it: 1) stops any HID/NFC scanning; 2) sends CTAPHID_CANCEL to any HID authenticators that have been added. Reference: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#usb-hid-cancel Sending CTAPHID_CANCEL, however, is not trivial. An abstract class FidoAuthenticator is crafted to do this labor for both CtapAuthenticator and U2fAuthenticator during the time of destructions. Noted: The CtapHidDriver is the only CtapDriver implements the cancel method. Since the message is sent during state reset, lifecycle of the HidConenction and HidService which manage the underlying IOHIDDeviceRef is very hard to hold. This is required for the regular async sender. Therefore, HidConnection::sendSync is crafted to send the message synchronously to get rid of the tediousness of managing those lifecycles. P.S. Vector::grow doesn't initialize POD types. Therefore, this patch also appends it with memset for FidoHidPacket. P.S.S. This patch also simplifies AuthenticatorCoordinatorClient by: i) moving code from AuthenticatorCoordinatorClient to WebAuthenticatorCoordinatorClient, and ii) using sendWithAsyncReply. The latter allows us to get rid of the complex mechanism of ensuring the right reply is returned. * DerivedSources.make: * Sources.txt: * UIProcess/API/APIWebAuthenticationPanel.cpp: (API::WebAuthenticationPanel::create): (API::WebAuthenticationPanel::WebAuthenticationPanel): (API::WebAuthenticationPanel::cancel const): * UIProcess/API/APIWebAuthenticationPanel.h: * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm: (-[_WKWebAuthenticationPanel cancel]): * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::cancelRequest): (WebKit::AuthenticatorManager::clearState): (WebKit::AuthenticatorManager::runPanel): (WebKit::AuthenticatorManager::resetState): * UIProcess/WebAuthentication/AuthenticatorManager.h: * UIProcess/WebAuthentication/Cocoa/HidConnection.h: (WebKit::HidConnection::isInitialized const): (WebKit::HidConnection::setIsInitialized): * UIProcess/WebAuthentication/Cocoa/HidConnection.mm: (WebKit::HidConnection::~HidConnection): (WebKit::HidConnection::initialize): (WebKit::HidConnection::terminate): (WebKit::HidConnection::sendSync): (WebKit::HidConnection::send): (WebKit::HidConnection::registerDataReceivedCallback): * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::initialize): (WebKit::MockHidConnection::terminate): (WebKit::MockHidConnection::sendSync): (WebKit::MockHidConnection::send): (WebKit::MockHidConnection::feedReports): * UIProcess/WebAuthentication/Mock/MockHidConnection.h: * UIProcess/WebAuthentication/WebAuthenticationRequestData.h: * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp: (WebKit::WebAuthenticatorCoordinatorProxy::makeCredential): (WebKit::WebAuthenticatorCoordinatorProxy::getAssertion): (WebKit::WebAuthenticatorCoordinatorProxy::handleRequest): (WebKit::WebAuthenticatorCoordinatorProxy::isUserVerifyingPlatformAuthenticatorAvailable): (WebKit::WebAuthenticatorCoordinatorProxy::requestReply): Deleted. * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h: * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.messages.in: * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp: (WebKit::CtapAuthenticator::CtapAuthenticator): (WebKit::CtapAuthenticator::makeCredential): (WebKit::CtapAuthenticator::getAssertion): (WebKit::CtapAuthenticator::tryDowngrade): * UIProcess/WebAuthentication/fido/CtapAuthenticator.h: * UIProcess/WebAuthentication/fido/CtapDriver.h: (WebKit::CtapDriver::cancel): * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp: (WebKit::CtapHidDriver::Worker::write): (WebKit::CtapHidDriver::Worker::read): (WebKit::CtapHidDriver::Worker::returnMessage): (WebKit::CtapHidDriver::Worker::reset): (WebKit::CtapHidDriver::Worker::cancel): (WebKit::CtapHidDriver::continueAfterChannelAllocated): (WebKit::CtapHidDriver::continueAfterResponseReceived): (WebKit::CtapHidDriver::returnResponse): (WebKit::CtapHidDriver::reset): (WebKit::CtapHidDriver::cancel): * UIProcess/WebAuthentication/fido/CtapHidDriver.h: * UIProcess/WebAuthentication/fido/FidoAuthenticator.cpp: Copied from Source/WebKit/UIProcess/API/APIWebAuthenticationPanel.cpp. (WebKit::FidoAuthenticator::FidoAuthenticator): (WebKit::FidoAuthenticator::~FidoAuthenticator): (WebKit::FidoAuthenticator::driver const): (WebKit::FidoAuthenticator::releaseDriver): * UIProcess/WebAuthentication/fido/FidoAuthenticator.h: Copied from Source/WebKit/UIProcess/API/APIWebAuthenticationPanel.cpp. * UIProcess/WebAuthentication/fido/FidoService.cpp: (WebKit::FidoService::continueAfterGetInfo): * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp: (WebKit::U2fAuthenticator::U2fAuthenticator): (WebKit::U2fAuthenticator::issueCommand): * UIProcess/WebAuthentication/fido/U2fAuthenticator.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::resetState): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::didDestroyFrame): * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp: (WebKit::WebAuthenticatorCoordinator::WebAuthenticatorCoordinator): (WebKit::WebAuthenticatorCoordinator::makeCredential): (WebKit::WebAuthenticatorCoordinator::getAssertion): (WebKit::WebAuthenticatorCoordinator::isUserVerifyingPlatformAuthenticatorAvailable): (WebKit::WebAuthenticatorCoordinator::~WebAuthenticatorCoordinator): Deleted. * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h: * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.messages.in: Removed. * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::fromCoreFrame): * WebProcess/WebPage/WebFrame.h: Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebCore/FidoHidMessageTest.cpp: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: (-[TestWebAuthenticationPanelUIDelegate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion-hid-cancel.html: Copied from Tools/TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion-hid.html. * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion-hid.html: * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion-nfc.html: * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion.html: LayoutTests: Modified one of the error message that is no longer emitted. * http/wpt/webauthn/public-key-credential-create-failure.https.html: * http/wpt/webauthn/public-key-credential-create-success-hid.https.html: * http/wpt/webauthn/public-key-credential-get-failure.https.html: * http/wpt/webauthn/public-key-credential-get-success-hid.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251295 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-18 Jiewen Tan [WebAuthn] Implement AuthenticatorCancel https://bugs.webkit.org/show_bug.cgi?id=191523 Reviewed by Brent Fulgham. Covered by new tests in existing test files. * Modules/credentialmanagement/CredentialsContainer.cpp: (WebCore::CredentialsContainer::get): (WebCore::CredentialsContainer::isCreate): * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::create const): (WebCore::AuthenticatorCoordinator::discoverFromExternalSource const): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.cpp: Removed. * Modules/webauthn/AuthenticatorCoordinatorClient.h: * Modules/webauthn/PublicKeyCredential.cpp: (WebCore::PublicKeyCredential::tryCreate): * Modules/webauthn/PublicKeyCredential.h: * Modules/webauthn/PublicKeyCredentialData.h: * Modules/webauthn/fido/DeviceRequestConverter.h: * Modules/webauthn/fido/FidoHidMessage.cpp: (fido::FidoHidMessage::FidoHidMessage): * Modules/webauthn/fido/FidoHidPacket.cpp: (fido::FidoHidInitPacket::getSerializedData const): (fido::FidoHidContinuationPacket::getSerializedData const): * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * testing/MockWebAuthenticationConfiguration.h: (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::decode): * testing/MockWebAuthenticationConfiguration.idl: Adds a new option to test AuthenticatorCancel. 2019-10-29 Alan Coon Cherry-pick r250940. rdar://problem/56598350 [WebAuthn] Move the mock testing entrance to Internals https://bugs.webkit.org/show_bug.cgi?id=202560 Reviewed by Chris Dumez. Source/WebCore: This patch moves TestRunner.setWebAuthenticationMockConfiguration to Internals.setMockWebAuthenticationConfiguration and removes the old entrance. The purpose of this patch is to allow API tests to use the same mock infrastructure that is used by layout tests. No new tests, covered by updates on existing tests. * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * Modules/webauthn/PublicKeyCredentialCreationOptions.h: * WebCore.xcodeproj/project.pbxproj: * page/ChromeClient.h: (WebCore::ChromeClient::setMockWebAuthenticationConfiguration): * testing/Internals.cpp: (WebCore::Internals::setMockWebAuthenticationConfiguration): * testing/Internals.h: * testing/Internals.idl: * testing/MockWebAuthenticationConfiguration.h: Added. (WebCore::MockWebAuthenticationConfiguration::LocalConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::LocalConfiguration::decode): (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::decode): (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::decode): (WebCore::MockWebAuthenticationConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::decode): * testing/MockWebAuthenticationConfiguration.idl: Added. Source/WebKit: * UIProcess/API/C/WKWebsiteDataStoreRef.cpp: (WKWebsiteDataStoreSetWebAuthenticationMockConfiguration): Deleted. * UIProcess/API/C/WKWebsiteDataStoreRef.h: * UIProcess/WebAuthentication/AuthenticatorTransportService.cpp: (WebKit::AuthenticatorTransportService::createMock): * UIProcess/WebAuthentication/AuthenticatorTransportService.h: * UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp: (WebKit::MockAuthenticatorManager::MockAuthenticatorManager): * UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.h: * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::send): (WebKit::MockHidConnection::registerDataReceivedCallbackInternal): (WebKit::MockHidConnection::parseRequest): (WebKit::MockHidConnection::feedReports): (WebKit::MockHidConnection::shouldContinueFeedReports): * UIProcess/WebAuthentication/Mock/MockHidConnection.h: * UIProcess/WebAuthentication/Mock/MockHidService.cpp: (WebKit::MockHidService::MockHidService): * UIProcess/WebAuthentication/Mock/MockHidService.h: * UIProcess/WebAuthentication/Mock/MockLocalConnection.h: * UIProcess/WebAuthentication/Mock/MockLocalConnection.mm: (WebKit::MockLocalConnection::MockLocalConnection): * UIProcess/WebAuthentication/Mock/MockLocalService.h: * UIProcess/WebAuthentication/Mock/MockLocalService.mm: (WebKit::MockLocalService::MockLocalService): * UIProcess/WebAuthentication/Mock/MockNfcService.h: * UIProcess/WebAuthentication/Mock/MockNfcService.mm: (WebKit::MockNfcService::MockNfcService): (WebKit::MockNfcService::platformStartDiscovery): (WebKit::MockNfcService::detectTags const): * UIProcess/WebAuthentication/Mock/MockWebAuthenticationConfiguration.h: Removed. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::setMockWebAuthenticationConfiguration): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/WebsiteData/WebsiteDataStore.h: * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::setMockWebAuthenticationConfiguration): * WebProcess/WebCoreSupport/WebChromeClient.h: Tools: * WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl: * WebKitTestRunner/InjectedBundle/TestRunner.cpp: (WTR::TestRunner::setWebAuthenticationMockConfiguration): Deleted. * WebKitTestRunner/InjectedBundle/TestRunner.h: * WebKitTestRunner/TestController.cpp: (WTR::TestController::setWebAuthenticationMockConfiguration): Deleted. * WebKitTestRunner/TestController.h: * WebKitTestRunner/TestInvocation.cpp: (WTR::TestInvocation::didReceiveSynchronousMessageFromInjectedBundle): LayoutTests: * http/wpt/webauthn/ctap-hid-failure.https.html: * http/wpt/webauthn/ctap-hid-success.https.html: * http/wpt/webauthn/ctap-nfc-failure.https.html: * http/wpt/webauthn/idl.https.html: * http/wpt/webauthn/public-key-credential-create-failure-hid-silent.https.html: * http/wpt/webauthn/public-key-credential-create-failure-hid.https.html: * http/wpt/webauthn/public-key-credential-create-failure-local-silent.https.html: * http/wpt/webauthn/public-key-credential-create-failure-local.https.html: * http/wpt/webauthn/public-key-credential-create-failure-nfc.https.html: * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https.html: * http/wpt/webauthn/public-key-credential-create-failure-u2f.https.html: * http/wpt/webauthn/public-key-credential-create-failure.https.html: * http/wpt/webauthn/public-key-credential-create-success-hid.https.html: * http/wpt/webauthn/public-key-credential-create-success-local.https.html: * http/wpt/webauthn/public-key-credential-create-success-nfc.https.html: * http/wpt/webauthn/public-key-credential-create-success-u2f.https.html: * http/wpt/webauthn/public-key-credential-get-failure-hid-silent.https.html: * http/wpt/webauthn/public-key-credential-get-failure-hid.https.html: * http/wpt/webauthn/public-key-credential-get-failure-local-silent.https.html: * http/wpt/webauthn/public-key-credential-get-failure-local.https.html: * http/wpt/webauthn/public-key-credential-get-failure-nfc.https.html: * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https.html: * http/wpt/webauthn/public-key-credential-get-failure-u2f.https.html: * http/wpt/webauthn/public-key-credential-get-failure.https.html: * http/wpt/webauthn/public-key-credential-get-success-hid.https.html: * http/wpt/webauthn/public-key-credential-get-success-local.https.html: * http/wpt/webauthn/public-key-credential-get-success-nfc.https.html: * http/wpt/webauthn/public-key-credential-get-success-u2f.https.html: * http/wpt/webauthn/resources/public-key-credential-ip-address.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250940 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-09 Jiewen Tan [WebAuthn] Move the mock testing entrance to Internals https://bugs.webkit.org/show_bug.cgi?id=202560 Reviewed by Chris Dumez. This patch moves TestRunner.setWebAuthenticationMockConfiguration to Internals.setMockWebAuthenticationConfiguration and removes the old entrance. The purpose of this patch is to allow API tests to use the same mock infrastructure that is used by layout tests. No new tests, covered by updates on existing tests. * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * Modules/webauthn/PublicKeyCredentialCreationOptions.h: * WebCore.xcodeproj/project.pbxproj: * page/ChromeClient.h: (WebCore::ChromeClient::setMockWebAuthenticationConfiguration): * testing/Internals.cpp: (WebCore::Internals::setMockWebAuthenticationConfiguration): * testing/Internals.h: * testing/Internals.idl: * testing/MockWebAuthenticationConfiguration.h: Added. (WebCore::MockWebAuthenticationConfiguration::LocalConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::LocalConfiguration::decode): (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::HidConfiguration::decode): (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::NfcConfiguration::decode): (WebCore::MockWebAuthenticationConfiguration::encode const): (WebCore::MockWebAuthenticationConfiguration::decode): * testing/MockWebAuthenticationConfiguration.idl: Added. 2019-10-28 Alan Coon Cherry-pick r251603. rdar://problem/56670801 Introduce AudioTrackPrivateMediaStreamCocoa::clear() https://bugs.webkit.org/show_bug.cgi?id=203369 Reviewed by Jer Noble. Introduce the clear method to make sure the AudioTrackPrivteMediaStreamCocoa is in a clean state. This will help further simplifications. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::~MediaPlayerPrivateMediaStreamAVFObjC): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::updateTracks): * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.cpp: (WebCore::AudioTrackPrivateMediaStreamCocoa::~AudioTrackPrivateMediaStreamCocoa): (WebCore::AudioTrackPrivateMediaStreamCocoa::clear): * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251603 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-25 youenn fablet Introduce AudioTrackPrivateMediaStreamCocoa::clear() https://bugs.webkit.org/show_bug.cgi?id=203369 Reviewed by Jer Noble. Introduce the clear method to make sure the AudioTrackPrivteMediaStreamCocoa is in a clean state. This will help further simplifications. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::~MediaPlayerPrivateMediaStreamAVFObjC): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::updateTracks): * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.cpp: (WebCore::AudioTrackPrivateMediaStreamCocoa::~AudioTrackPrivateMediaStreamCocoa): (WebCore::AudioTrackPrivateMediaStreamCocoa::clear): * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.h: 2019-10-24 Kocsen Chung Cherry-pick r250863. rdar://problem/56579654 Copying white text from dark mode WebKit apps and pasting in a light mode app results in white (invisible) text. https://bugs.webkit.org/show_bug.cgi?id=202662 rdar://problem/48677354 Reviewed by Megan Gardner. Source/WebCore: Covered by new API tests. HTMLConverter needs to strip white text colors when the document is in dark mode, like it does for black in light mode. * editing/cocoa/HTMLConverter.mm: (normalizedColor): Handle dark mode and ignore white. (HTMLConverterCaches::colorPropertyValueForNode): Pass element to normalizedColor. Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/CopyRTF.mm: Added. (readRTFDataFromPasteboard): (copyAttributedStringFromHTML): (checkColor): (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250863 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-08 Timothy Hatcher Copying white text from dark mode WebKit apps and pasting in a light mode app results in white (invisible) text. https://bugs.webkit.org/show_bug.cgi?id=202662 rdar://problem/48677354 Reviewed by Megan Gardner. Covered by new API tests. HTMLConverter needs to strip white text colors when the document is in dark mode, like it does for black in light mode. * editing/cocoa/HTMLConverter.mm: (normalizedColor): Handle dark mode and ignore white. (HTMLConverterCaches::colorPropertyValueForNode): Pass element to normalizedColor. 2019-10-21 Dean Jackson Cherry-pick r251390. rdar://56579651 2019-10-21 Dean Jackson Dispatch AR event on the originating anchor element https://bugs.webkit.org/show_bug.cgi?id=203198 Reviewed by Simon Fraser. Expose an ElementContext on the SystemPreviewInfo, so that when something happens in the AR QuickLook an event can be fired on the originating element. * dom/Document.cpp: (WebCore::Document::dispatchSystemPreviewActionEvent): Make sure we dispatch only to the HTMLAnchorElement. * dom/Document.h: * html/HTMLAnchorElement.cpp: (WebCore::HTMLAnchorElement::handleClick): * loader/FrameLoaderTypes.h: (WebCore::SystemPreviewInfo::encode const): (WebCore::SystemPreviewInfo::decode): * testing/Internals.cpp: (WebCore::Internals::elementIdentifier const): * testing/Internals.h: * testing/Internals.idl: 2019-10-21 Dean Jackson Cherry-pick r251388. rdar://56579651 Move ElementContext from WebKit to WebCore https://bugs.webkit.org/show_bug.cgi?id=203210 Reviewed by Simon Fraser. * WebCore.xcodeproj/project.pbxproj: 2019-10-20 Babak Shafiei Cherry-pick r251188. rdar://problem/56340816 WebAudioSourceProviderAVFObjC::provideInput should set its WebAudioBufferList parameters correctly https://bugs.webkit.org/show_bug.cgi?id=202930 Reviewed by Eric Carlson. Source/WebCore: There is a time where the bus channel number and audio source channel numbers may be different. In case the bus channel number is less than the audio source channel number, initialization of the WebAudioBufferList might not be fully done. In that case, output silence and return early. Reduce the number of frames to process based on the number of frames the output audio bus plans to process. Partially covered by new API test (this a race so we cannot reproduce the crash easily). * Modules/webaudio/MediaStreamAudioSourceNode.cpp: (WebCore::MediaStreamAudioSourceNode::process): Make sure to process the number of frames the output bus expect. * platform/mediastream/mac/WebAudioSourceProviderAVFObjC.mm: (WebCore::WebAudioSourceProviderAVFObjC::provideInput): Tools: Add a test that has an audio track that goes from 1 to 2 channels while being piped to a WebAudio pipeline. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKit/GetUserMedia.mm: (-[GUMMessageHandler userContentController:didReceiveScriptMessage:]): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKit/getUserMedia-webaudio.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251188 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-16 Youenn Fablet WebAudioSourceProviderAVFObjC::provideInput should set its WebAudioBufferList parameters correctly https://bugs.webkit.org/show_bug.cgi?id=202930 Reviewed by Eric Carlson. There is a time where the bus channel number and audio source channel numbers may be different. In case the bus channel number is less than the audio source channel number, initialization of the WebAudioBufferList might not be fully done. In that case, output silence and return early. Reduce the number of frames to process based on the number of frames the output audio bus plans to process. Partially covered by new API test (this a race so we cannot reproduce the crash easily). * Modules/webaudio/MediaStreamAudioSourceNode.cpp: (WebCore::MediaStreamAudioSourceNode::process): Make sure to process the number of frames the output bus expect. * platform/mediastream/mac/WebAudioSourceProviderAVFObjC.mm: (WebCore::WebAudioSourceProviderAVFObjC::provideInput): 2019-10-20 Babak Shafiei Apply patch. rdar://problem/56427498 2019-10-20 John Wilander Cherry-pick r251213. rdar://problem/56262708 Resource Load Statistics: Block all third-party cookies on websites without prior user interaction https://bugs.webkit.org/show_bug.cgi?id=203017 Reviewed by Alex Christensen. NetworkStorageSession::shouldBlockCookies() now checks if the first-party website has received user interaction and if not, blocks all third-party cookies, regardless of the status of those third-party domains (prevalent or not). Test: http/tests/resourceLoadStatistics/third-party-cookie-blocking-on-sites-without-user-interaction.html * page/Settings.yaml: * platform/network/NetworkStorageSession.cpp: (WebCore::NetworkStorageSession::hasHadUserInteractionAsFirstParty const): (WebCore::NetworkStorageSession::shouldBlockCookies const): (WebCore::NetworkStorageSession::setDomainsWithUserInteractionAsFirstParty): * platform/network/NetworkStorageSession.h: (WebCore::NetworkStorageSession::setIsThirdPartyCookieBlockingOnSitesWithoutUserInteractionEnabled): 2019-10-17 Alan Coon Cherry-pick r250589. rdar://problem/55927251 Storage Access API: document.hasStorageAccess() should return true when the cookie policy allows access https://bugs.webkit.org/show_bug.cgi?id=202435 Reviewed by Brent Fulgham. Source/WebCore: WebKit's Storage Access API implementation has so far only looked at whether ITP is blocking cookie access or not. However, the default cookie policy is still in effect underneath ITP. document.hasStorageAccess() should return true if the third-party: a) is not classified by ITP, and b) has cookies which implies it can use cookies as third-party according to the default cookie policy. Tests: http/tests/storageAccess/has-storage-access-false-by-default-ephemeral.html http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-ephemeral.html http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies.html * platform/network/NetworkStorageSession.h: * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::hasCookies const): * platform/network/curl/NetworkStorageSessionCurl.cpp: (WebCore::NetworkStorageSession::hasCookies const): Not yet implemented. Always says false. * platform/network/soup/NetworkStorageSessionSoup.cpp: (WebCore::NetworkStorageSession::hasCookies const): Not yet implemented. Always says false. Source/WebKit: WebKit's Storage Access API implementation has so far only looked at whether ITP is blocking cookie access or not. However, the default cookie policy is still in effect underneath ITP. document.hasStorageAccess() should return true if the third-party: a) is not classified by ITP, and b) has cookies which implies it can use cookies as third-party according to the default cookie policy. * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::hasStorageAccess): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::hasCookies): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h: * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::hasStorageAccess): * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::registrableDomainsWithWebsiteData): Tools: This change makes sure topPrivatelyControlledDomain() correctly handles domains with leading dots, as often used in cookie domains. * TestWebKitAPI/Tests/WebCore/PublicSuffix.cpp: (TestWebKitAPI::TEST_F): LayoutTests: WebKit's Storage Access API implementation has so far only looked at whether ITP is blocking cookie access or not. However, the default cookie policy is still in effect underneath ITP. document.hasStorageAccess() should return true if the third-party: a) is not classified by ITP, and b) has cookies which implies it can use cookies as third-party according to the default cookie policy. * http/tests/storageAccess/has-storage-access-false-by-default-ephemeral-expected.txt: Added. * http/tests/storageAccess/has-storage-access-false-by-default-ephemeral.html: Copied from LayoutTests/http/tests/storageAccess/has-storage-access-true-if-feature-off.html. * http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-ephemeral-expected.txt: Added. * http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-ephemeral.html: Copied from LayoutTests/http/tests/storageAccess/has-storage-access-true-if-feature-off.html. * http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-expected.txt: Added. * http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies.html: Renamed from LayoutTests/http/tests/storageAccess/has-storage-access-true-if-feature-off.html. * platform/ios/TestExpectations: * platform/mac-wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250589 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-01 John Wilander Storage Access API: document.hasStorageAccess() should return true when the cookie policy allows access https://bugs.webkit.org/show_bug.cgi?id=202435 Reviewed by Brent Fulgham. WebKit's Storage Access API implementation has so far only looked at whether ITP is blocking cookie access or not. However, the default cookie policy is still in effect underneath ITP. document.hasStorageAccess() should return true if the third-party: a) is not classified by ITP, and b) has cookies which implies it can use cookies as third-party according to the default cookie policy. Tests: http/tests/storageAccess/has-storage-access-false-by-default-ephemeral.html http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-ephemeral.html http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies.html * platform/network/NetworkStorageSession.h: * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::hasCookies const): * platform/network/curl/NetworkStorageSessionCurl.cpp: (WebCore::NetworkStorageSession::hasCookies const): Not yet implemented. Always says false. * platform/network/soup/NetworkStorageSessionSoup.cpp: (WebCore::NetworkStorageSession::hasCookies const): Not yet implemented. Always says false. 2019-10-15 Kocsen Chung Cherry-pick r250887. rdar://problem/56061121 Partially undo r250811 https://bugs.webkit.org/show_bug.cgi?id=202715 Reviewed by Chris Dumez. Source/WebCore: This patch changes the SerializedScriptValue to always wrap CryptoKey objects again. CryptoKey objects could belong to an array or another object. In those cases, IDBObjectStore cannot set the flag for the embedded Cryptokey objects. Neither can postMessage to unset the flag. Therefore, there is no way to separate the serialization process into two and this patch restores the old behaviour. However, the hardening part of r250811 is kept and therefore the crash should still be prevented. No new test, updated existing test * Modules/indexeddb/IDBObjectStore.cpp: (WebCore::IDBObjectStore::putOrAdd): (WebCore::JSC::setIsWrappingRequiredForCryptoKey): Deleted. * bindings/js/SerializedScriptValue.cpp: (WebCore::CloneSerializer::dumpIfTerminal): (WebCore::CloneDeserializer::readTerminal): * crypto/CryptoKey.h: (WebCore::CryptoKey::allows const): (WebCore::CryptoKey::isWrappingRequired const): Deleted. (WebCore::CryptoKey::setIsWrappingRequired): Deleted. (): Deleted. * dom/ScriptExecutionContext.h: Tools: * TestWebKitAPI/Tests/WebKit/navigation-client-default-crypto.html: Modified to crash if SerializedScriptValue doesn't wrap CryptoKey objects. LayoutTests: Some rebaselines. * crypto/workers/subtle/ec-postMessage-worker-expected.txt: * crypto/workers/subtle/hrsa-postMessage-worker-expected.txt: * crypto/workers/subtle/rsa-postMessage-worker-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250887 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-08 Jiewen Tan Partially undo r250811 https://bugs.webkit.org/show_bug.cgi?id=202715 Reviewed by Chris Dumez. This patch changes the SerializedScriptValue to always wrap CryptoKey objects again. CryptoKey objects could belong to an array or another object. In those cases, IDBObjectStore cannot set the flag for the embedded Cryptokey objects. Neither can postMessage to unset the flag. Therefore, there is no way to separate the serialization process into two and this patch restores the old behaviour. However, the hardening part of r250811 is kept and therefore the crash should still be prevented. No new test, updated existing test * Modules/indexeddb/IDBObjectStore.cpp: (WebCore::IDBObjectStore::putOrAdd): (WebCore::JSC::setIsWrappingRequiredForCryptoKey): Deleted. * bindings/js/SerializedScriptValue.cpp: (WebCore::CloneSerializer::dumpIfTerminal): (WebCore::CloneDeserializer::readTerminal): * crypto/CryptoKey.h: (WebCore::CryptoKey::allows const): (WebCore::CryptoKey::isWrappingRequired const): Deleted. (WebCore::CryptoKey::setIsWrappingRequired): Deleted. (): Deleted. * dom/ScriptExecutionContext.h: 2019-10-15 Kocsen Chung Cherry-pick r250929. rdar://problem/56280990 RunResolver::rangeForRendererWithOffsets should check for range end https://bugs.webkit.org/show_bug.cgi?id=202761 Reviewed by Antti Koivisto. Source/WebCore: This patch ensures that when rangeForRenderer comes back with a collapsed run (empty range), rangeForRendererWithOffsets returns an empty range as well. Test: fast/text/simple-line-layout-range-check-end.html * rendering/SimpleLineLayoutResolver.cpp: (WebCore::SimpleLineLayout::RunResolver::rangeForRendererWithOffsets const): LayoutTests: * fast/text/simple-line-layout-range-check-end-expected.txt: Added. * fast/text/simple-line-layout-range-check-end.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250929 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-09 Zalan Bujtas RunResolver::rangeForRendererWithOffsets should check for range end https://bugs.webkit.org/show_bug.cgi?id=202761 Reviewed by Antti Koivisto. This patch ensures that when rangeForRenderer comes back with a collapsed run (empty range), rangeForRendererWithOffsets returns an empty range as well. Test: fast/text/simple-line-layout-range-check-end.html * rendering/SimpleLineLayoutResolver.cpp: (WebCore::SimpleLineLayout::RunResolver::rangeForRendererWithOffsets const): 2019-10-15 Kocsen Chung Cherry-pick r250811. rdar://problem/56061121 Only wrapping CryptoKeys for IDB during serialization https://bugs.webkit.org/show_bug.cgi?id=202500 Reviewed by Chris Dumez. Source/WebCore: Wrapping CryptoKeys during IDB serialization is a legacy request from Netflix when WebKit was an early adopter. It is not necessary for other kinds of serialization. However, given existing keys stored in users' idb are wrapped, the wrapping/unwrapping mechanism cannot be easily discarded. Therefore, this patch restricts the wrapping/unwrapping mechanism to idb only. To do so, a isWrappingRequired flag is added to CryptoKey such that whenever idb sees a CryptoKey, it can set it. SerializedScriptValue will then only wrap a CryptoKey when this flag is set. Otherwise, a new tag UnwrappedCryptoKeyTag is used to store unwrapped CryptoKeys in order to keep the old CryptoKeyTag binaries intact. For deserialization, each type will be deserialized differently. Besides the above, this patch also hardens WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey for any potential racy issues. CryptoBooleanContainer is introduced to capture boolean in the lambda. workerGlobalScope is replaced with workerMessagingProxy. Now, every variables captured in the lambdas should be either a copy or a thread safe ref of the original object. Test: crypto/workers/subtle/aes-indexeddb.html * Modules/indexeddb/IDBObjectStore.cpp: (WebCore::JSC::setIsWrappingRequiredForCryptoKey): (WebCore::IDBObjectStore::putOrAdd): * bindings/js/SerializedScriptValue.cpp: (WebCore::CloneSerializer::dumpIfTerminal): (WebCore::CloneDeserializer::readTerminal): * crypto/CryptoKey.h: (WebCore::CryptoKey::isWrappingRequired const): (WebCore::CryptoKey::setIsWrappingRequired): * dom/ScriptExecutionContext.h: * workers/WorkerGlobalScope.cpp: (WebCore::CryptoBooleanContainer::create): (WebCore::CryptoBooleanContainer::boolean const): (WebCore::CryptoBooleanContainer::setBoolean): (WebCore::WorkerGlobalScope::wrapCryptoKey): (WebCore::WorkerGlobalScope::unwrapCryptoKey): * workers/WorkerGlobalScope.h: * workers/WorkerLoaderProxy.h: (WebCore::WorkerLoaderProxy::isWorkerMessagingProxy const): * workers/WorkerMessagingProxy.h: (isType): Tools: Modifies IndexedDB.StructuredCloneBackwardCompatibility test to include CryptoKeys. * TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.mm: (-[StructuredCloneBackwardCompatibilityNavigationDelegate _webCryptoMasterKeyForWebView:]): (TEST): * TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.sqlite3: * TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.sqlite3-shm: * TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.sqlite3-wal: * TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibilityRead.html: * TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibilityWrite.html: LayoutTests: Adds a new test aes-indexeddb.html to do idb in workers and makes other tests more deterministic. * crypto/workers/subtle/aes-indexeddb-expected.txt: Added. * crypto/workers/subtle/aes-indexeddb.html: Added. * crypto/workers/subtle/ec-postMessage-worker-expected.txt: * crypto/workers/subtle/ec-postMessage-worker.html: * crypto/workers/subtle/hrsa-postMessage-worker-expected.txt: * crypto/workers/subtle/hrsa-postMessage-worker.html: * crypto/workers/subtle/resources/aes-indexeddb.js: Added. * crypto/workers/subtle/rsa-postMessage-worker-expected.txt: * crypto/workers/subtle/rsa-postMessage-worker.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250811 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-07 Jiewen Tan Only wrapping CryptoKeys for IDB during serialization https://bugs.webkit.org/show_bug.cgi?id=202500 Reviewed by Chris Dumez. Wrapping CryptoKeys during IDB serialization is a legacy request from Netflix when WebKit was an early adopter. It is not necessary for other kinds of serialization. However, given existing keys stored in users' idb are wrapped, the wrapping/unwrapping mechanism cannot be easily discarded. Therefore, this patch restricts the wrapping/unwrapping mechanism to idb only. To do so, a isWrappingRequired flag is added to CryptoKey such that whenever idb sees a CryptoKey, it can set it. SerializedScriptValue will then only wrap a CryptoKey when this flag is set. Otherwise, a new tag UnwrappedCryptoKeyTag is used to store unwrapped CryptoKeys in order to keep the old CryptoKeyTag binaries intact. For deserialization, each type will be deserialized differently. Besides the above, this patch also hardens WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey for any potential racy issues. CryptoBooleanContainer is introduced to capture boolean in the lambda. workerGlobalScope is replaced with workerMessagingProxy. Now, every variables captured in the lambdas should be either a copy or a thread safe ref of the original object. Test: crypto/workers/subtle/aes-indexeddb.html * Modules/indexeddb/IDBObjectStore.cpp: (WebCore::JSC::setIsWrappingRequiredForCryptoKey): (WebCore::IDBObjectStore::putOrAdd): * bindings/js/SerializedScriptValue.cpp: (WebCore::CloneSerializer::dumpIfTerminal): (WebCore::CloneDeserializer::readTerminal): * crypto/CryptoKey.h: (WebCore::CryptoKey::isWrappingRequired const): (WebCore::CryptoKey::setIsWrappingRequired): * dom/ScriptExecutionContext.h: * workers/WorkerGlobalScope.cpp: (WebCore::CryptoBooleanContainer::create): (WebCore::CryptoBooleanContainer::boolean const): (WebCore::CryptoBooleanContainer::setBoolean): (WebCore::WorkerGlobalScope::wrapCryptoKey): (WebCore::WorkerGlobalScope::unwrapCryptoKey): * workers/WorkerGlobalScope.h: * workers/WorkerLoaderProxy.h: (WebCore::WorkerLoaderProxy::isWorkerMessagingProxy const): * workers/WorkerMessagingProxy.h: (isType): 2019-10-15 Kocsen Chung Cherry-pick r250716. rdar://problem/56280993 AppleTV named as XSS-payloads trigger when AirPlay is used https://bugs.webkit.org/show_bug.cgi?id=202534 Reviewed by Eric Carlson. Ensure we escape an AirPlay's device name before inserting its name into the DOM. * Modules/modern-media-controls/media/placard-support.js: (PlacardSupport.prototype._updateAirPlayPlacard): (PlacardSupport): (escapeHTML): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250716 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-03 Antoine Quint AppleTV named as XSS-payloads trigger when AirPlay is used https://bugs.webkit.org/show_bug.cgi?id=202534 Reviewed by Eric Carlson. Ensure we escape an AirPlay's device name before inserting its name into the DOM. * Modules/modern-media-controls/media/placard-support.js: (PlacardSupport.prototype._updateAirPlayPlacard): (PlacardSupport): (escapeHTML): 2019-10-15 Kocsen Chung Cherry-pick r250694. rdar://problem/56061131 [iOS] WebContent process can be interrupted during suspension; loses "Now Playing" status https://bugs.webkit.org/show_bug.cgi?id=202537 Reviewed by Eric Carlson. Always deactivate the AVAudioSession when the last playing PlatformAudioSession ends playback and the application is in the background. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::removeSession): (WebCore::PlatformMediaSessionManager::processWillSuspend): (WebCore::PlatformMediaSessionManager::maybeDeactivateAudioSession): * platform/audio/PlatformMediaSessionManager.h: (WebCore::PlatformMediaSessionManager::isApplicationInBackground const): * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::sessionWillEndPlayback): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250694 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-03 Jer Noble [iOS] WebContent process can be interrupted during suspension; loses "Now Playing" status https://bugs.webkit.org/show_bug.cgi?id=202537 Reviewed by Eric Carlson. Always deactivate the AVAudioSession when the last playing PlatformAudioSession ends playback and the application is in the background. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::removeSession): (WebCore::PlatformMediaSessionManager::processWillSuspend): (WebCore::PlatformMediaSessionManager::maybeDeactivateAudioSession): * platform/audio/PlatformMediaSessionManager.h: (WebCore::PlatformMediaSessionManager::isApplicationInBackground const): * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::sessionWillEndPlayback): 2019-10-15 Kocsen Chung Cherry-pick r250642. rdar://problem/56280704 [iOS] When hit testing for a context menu interaction, do not consider whether the element is contenteditable https://bugs.webkit.org/show_bug.cgi?id=202498 Reviewed by Tim Horton. Source/WebCore: When the user selects a context menu action, WebKit performs a hit test in order to find the acted-on element on the page. This is separate from the hit test performed to generate the context menu's targeted preview. Since an arbitrary amount of time can elapse between preview generation and action selection, this second hit-tests might return a different element. One case where we know a different element can be returned is in apps that dynamically enable and disable editing. If editing is disabled when the first hit test occurs but is enabled when the second one occurs, different elements will be returned due to Frame::qualifyingNodeAtViewportLocation preferring to return the root editable element when the approximate node is contenteditable. While the appropriate long-term fix is to only hit-test once and use that element for both preview generation and action selection, this patch implements a short-term fix to address the specific problem in rdar://problem/54723131 by disabling the contenteditable behavior described above for context menu interaction hit testing. The long-term fix is tracked by . * page/Frame.h: * page/ios/FrameIOS.mm: (WebCore::Frame::qualifyingNodeAtViewportLocation): (WebCore::Frame::approximateNodeAtViewportLocationLegacy): (WebCore::ancestorRespondingToClickEventsNodeQualifier): (WebCore::Frame::nodeRespondingToClickEvents): (WebCore::Frame::nodeRespondingToDoubleClickEvent): (WebCore::Frame::nodeRespondingToInteraction): (WebCore::Frame::nodeRespondingToScrollWheelEvents): Source/WebKit: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::startInteractionWithElementAtPosition): Changed to call WebCore::Frame::nodeRespondingToInteraction. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250642 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-02 Andy Estes [iOS] When hit testing for a context menu interaction, do not consider whether the element is contenteditable https://bugs.webkit.org/show_bug.cgi?id=202498 Reviewed by Tim Horton. When the user selects a context menu action, WebKit performs a hit test in order to find the acted-on element on the page. This is separate from the hit test performed to generate the context menu's targeted preview. Since an arbitrary amount of time can elapse between preview generation and action selection, this second hit-tests might return a different element. One case where we know a different element can be returned is in apps that dynamically enable and disable editing. If editing is disabled when the first hit test occurs but is enabled when the second one occurs, different elements will be returned due to Frame::qualifyingNodeAtViewportLocation preferring to return the root editable element when the approximate node is contenteditable. While the appropriate long-term fix is to only hit-test once and use that element for both preview generation and action selection, this patch implements a short-term fix to address the specific problem in rdar://problem/54723131 by disabling the contenteditable behavior described above for context menu interaction hit testing. The long-term fix is tracked by . * page/Frame.h: * page/ios/FrameIOS.mm: (WebCore::Frame::qualifyingNodeAtViewportLocation): (WebCore::Frame::approximateNodeAtViewportLocationLegacy): (WebCore::ancestorRespondingToClickEventsNodeQualifier): (WebCore::Frame::nodeRespondingToClickEvents): (WebCore::Frame::nodeRespondingToDoubleClickEvent): (WebCore::Frame::nodeRespondingToInteraction): (WebCore::Frame::nodeRespondingToScrollWheelEvents): 2019-10-15 Kocsen Chung Cherry-pick r249517. rdar://problem/56000099 Mail appears to be double inverting code copied from Notes, Xcode, or Terminal. https://bugs.webkit.org/show_bug.cgi?id=201368 rdar://problem/40529867 Reviewed by Ryosuke Niwa. Source/WebCore: Dark mode content that is pasted should have the inline styles inverse color transformed by the color filter to match the color filtered document contents. Layout Test: editing/pasteboard/paste-dark-mode-color-filtered.html API Tests: PasteHTML.TransformColorsOfDarkContent, PasteHTML.DoesNotTransformColorsOfLightContent, PasteRTFD.TransformColorsOfDarkContent, PasteRTFD.DoesNotTransformColorsOfLightContent * editing/EditingStyle.cpp: (WebCore::EditingStyle::inverseTransformColorIfNeeded): Added caret-color to the transformed properties. * editing/ReplaceSelectionCommand.cpp: (WebCore::fragmentNeedsColorTransformed): Added. (WebCore::ReplaceSelectionCommand::inverseTransformColor): Added. (WebCore::ReplaceSelectionCommand::doApply): Call fragmentNeedsColorTransformed() and inverseTransformColor(). * editing/ReplaceSelectionCommand.h: Tools: Added Tests: PasteHTML.TransformColorsOfDarkContent, PasteHTML.DoesNotTransformColorsOfLightContent, PasteRTFD.TransformColorsOfDarkContent, PasteRTFD.DoesNotTransformColorsOfLightContent * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm: (createWebViewWithCustomPasteboardDataSetting): Added argument to enable color filter. * TestWebKitAPI/Tests/WebKitCocoa/PasteRTFD.mm: (createWebViewWithCustomPasteboardDataEnabled): Added argument to enable color filter. * TestWebKitAPI/Tests/WebKitCocoa/rich-color-filtered.html: Added. * TestWebKitAPI/cocoa/TestWKWebView.h: * TestWebKitAPI/cocoa/TestWKWebView.mm: (-[TestWKWebView forceDarkMode]): LayoutTests: * TestExpectations: * editing/pasteboard/paste-dark-mode-color-filtered-expected.txt: Added. * editing/pasteboard/paste-dark-mode-color-filtered.html: Added. * platform/ios-12/TestExpectations: * platform/ios/TestExpectations: * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249517 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-04 Timothy Hatcher Mail appears to be double inverting code copied from Notes, Xcode, or Terminal. https://bugs.webkit.org/show_bug.cgi?id=201368 rdar://problem/40529867 Reviewed by Ryosuke Niwa. Dark mode content that is pasted should have the inline styles inverse color transformed by the color filter to match the color filtered document contents. Layout Test: editing/pasteboard/paste-dark-mode-color-filtered.html API Tests: PasteHTML.TransformColorsOfDarkContent, PasteHTML.DoesNotTransformColorsOfLightContent, PasteRTFD.TransformColorsOfDarkContent, PasteRTFD.DoesNotTransformColorsOfLightContent * editing/EditingStyle.cpp: (WebCore::EditingStyle::inverseTransformColorIfNeeded): Added caret-color to the transformed properties. * editing/ReplaceSelectionCommand.cpp: (WebCore::fragmentNeedsColorTransformed): Added. (WebCore::ReplaceSelectionCommand::inverseTransformColor): Added. (WebCore::ReplaceSelectionCommand::doApply): Call fragmentNeedsColorTransformed() and inverseTransformColor(). * editing/ReplaceSelectionCommand.h: 2019-10-04 Kocsen Chung Cherry-pick r249436. rdar://problem/55989217 [WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService https://bugs.webkit.org/show_bug.cgi?id=201369 Reviewed by Brent Fulgham. Source/WebCore: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isSafariViewService): Adds a way to detect SafariViewService. Source/WebKit: Communications to security keys require entitlements, which are not guaranteed to be present in third party WKWebView clients. Therefore, only enable WebAuthn by default for MobileSafari and SafariViewService. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.cpp: (WebKit::defaultWebAuthenticationEnabled): * Shared/WebPreferencesDefaultValues.h: LayoutTests: * http/wpt/webauthn/public-key-credential-get-success-nfc.https.html: Imporves the test a bit. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249436 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-03 Jiewen Tan [WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService https://bugs.webkit.org/show_bug.cgi?id=201369 Reviewed by Brent Fulgham. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isSafariViewService): Adds a way to detect SafariViewService. 2019-10-03 Alan Coon Cherry-pick r250659. rdar://problem/55954229 Support googleLegacyAppidSupport extension https://bugs.webkit.org/show_bug.cgi?id=202427 Reviewed by Brent Fulgham. Source/WebCore: This patch adds support for googleLegacyAppidSupport extension, when set: 1) user agent should only use the U2F transport protocol, 2) should only communicate with roaming authenticators, and 3) should use a hard-coded appID of https://www.gstatic.com/securitykey/origins.json. To be noticed as the name implies, this extension is exclusively for RP ID = google.com. Implementation wise, all operations are captured in methods with name processGoogleLegacyAppIdSupportExtension. 1) AuthenticatorCoordinator takes care of setting the value. 2) U2fCommandConstructor takes care of hard coding the AppID. 3) AuthenticatorManager takes care of removing AuthenticatorTransport::Internal from TransportSet, so startDiscovery will not poke platform authenticators. 4) CtapAuthenticator takes care of downgrading to U2fAuthenticator. 5) U2fAuthenticator takes care of setting the AppID in the response. Partially covered by new test cases in existing tests, and remaining will be covered by manual tests. * Modules/webauthn/AuthenticationExtensionsClientInputs.h: (WebCore::AuthenticationExtensionsClientInputs::encode const): (WebCore::AuthenticationExtensionsClientInputs::decode): * Modules/webauthn/AuthenticationExtensionsClientInputs.idl: * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinatorInternal::processGoogleLegacyAppIdSupportExtension): (WebCore::AuthenticatorCoordinator::create const): * Modules/webauthn/PublicKeyCredentialCreationOptions.h: (WebCore::PublicKeyCredentialCreationOptions::encode const): (WebCore::PublicKeyCredentialCreationOptions::decode): * Modules/webauthn/fido/U2fCommandConstructor.cpp: (fido::convertToU2fRegisterCommand): (fido::processGoogleLegacyAppIdSupportExtension): * Modules/webauthn/fido/U2fCommandConstructor.h: Source/WebKit: * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManagerInternal::collectTransports): (WebKit::AuthenticatorManagerInternal::processGoogleLegacyAppIdSupportExtension): (WebKit::AuthenticatorManager::handleRequest): * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp: (WebKit::CtapAuthenticator::makeCredential): (WebKit::CtapAuthenticator::processGoogleLegacyAppIdSupportExtension): * UIProcess/WebAuthentication/fido/CtapAuthenticator.h: * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp: (WebKit::U2fAuthenticator::continueRegisterCommandAfterResponseReceived): Tools: Adds an API test for googleLegacyAppidSupport extension. * TestWebKitAPI/Tests/WebCore/FidoTestData.h: * TestWebKitAPI/Tests/WebCore/U2fCommandConstructorTest.cpp: (TestWebKitAPI::constructMakeCredentialRequest): (TestWebKitAPI::constructMakeCredentialRequestWithGoogleLegacyAppidSupport): (TestWebKitAPI::TEST): LayoutTests: Add tests to confirm the googleLegacyAppidSupport extension is ignored for RP ID != google.com. * http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-hid.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250659 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-10-03 Jiewen Tan Support googleLegacyAppidSupport extension https://bugs.webkit.org/show_bug.cgi?id=202427 Reviewed by Brent Fulgham. This patch adds support for googleLegacyAppidSupport extension, when set: 1) user agent should only use the U2F transport protocol, 2) should only communicate with roaming authenticators, and 3) should use a hard-coded appID of https://www.gstatic.com/securitykey/origins.json. To be noticed as the name implies, this extension is exclusively for RP ID = google.com. Implementation wise, all operations are captured in methods with name processGoogleLegacyAppIdSupportExtension. 1) AuthenticatorCoordinator takes care of setting the value. 2) U2fCommandConstructor takes care of hard coding the AppID. 3) AuthenticatorManager takes care of removing AuthenticatorTransport::Internal from TransportSet, so startDiscovery will not poke platform authenticators. 4) CtapAuthenticator takes care of downgrading to U2fAuthenticator. 5) U2fAuthenticator takes care of setting the AppID in the response. Partially covered by new test cases in existing tests, and remaining will be covered by manual tests. * Modules/webauthn/AuthenticationExtensionsClientInputs.h: (WebCore::AuthenticationExtensionsClientInputs::encode const): (WebCore::AuthenticationExtensionsClientInputs::decode): * Modules/webauthn/AuthenticationExtensionsClientInputs.idl: * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinatorInternal::processGoogleLegacyAppIdSupportExtension): (WebCore::AuthenticatorCoordinator::create const): * Modules/webauthn/PublicKeyCredentialCreationOptions.h: (WebCore::PublicKeyCredentialCreationOptions::encode const): (WebCore::PublicKeyCredentialCreationOptions::decode): * Modules/webauthn/fido/U2fCommandConstructor.cpp: (fido::convertToU2fRegisterCommand): (fido::processGoogleLegacyAppIdSupportExtension): * Modules/webauthn/fido/U2fCommandConstructor.h: 2019-10-03 Alan Coon Cherry-pick r249949. rdar://problem/55964883 [WebAuthn] Use WebPreferences instead of RuntimeEnabledFeatures in UIProcess https://bugs.webkit.org/show_bug.cgi?id=198176 Reviewed by Youenn Fablet. Source/WebCore: No changes of behavior. * Modules/webauthn/PublicKeyCredential.cpp: (WebCore::PublicKeyCredential::isUserVerifyingPlatformAuthenticatorAvailable): Resolves the promise with false immediately when the feature flag is false. Source/WebKit: This patch does the following two things: 1) It merges WebAuthenticationRequestData::creationOptions and requestOptions into a variant, and therefore merges code paths that involve WebAuthenticationRequestData. 2) It teaches WebAuthenticationRequestData to store a WebPreferences such that AuthenticatorManager could utilize runtime feature flags to turn features on or off. * UIProcess/WebAuthentication/Authenticator.cpp: (WebKit::Authenticator::handleRequest): * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::handleRequest): (WebKit::AuthenticatorManager::clearState): (WebKit::AuthenticatorManager::authenticatorAdded): (WebKit::AuthenticatorManager::startDiscovery): (WebKit::AuthenticatorManager::makeCredential): Deleted. (WebKit::AuthenticatorManager::getAssertion): Deleted. * UIProcess/WebAuthentication/AuthenticatorManager.h: * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm: (WebKit::LocalAuthenticator::makeCredential): (WebKit::LocalAuthenticator::continueMakeCredentialAfterUserConsented): (WebKit::LocalAuthenticator::continueMakeCredentialAfterAttested): (WebKit::LocalAuthenticator::getAssertion): (WebKit::LocalAuthenticator::continueGetAssertionAfterUserConsented): * UIProcess/WebAuthentication/Cocoa/LocalService.mm: (WebKit::LocalService::isAvailable): Don't check RuntimeEnabledFeatures given it is for WebCore. * UIProcess/WebAuthentication/WebAuthenticationRequestData.h: (): Deleted. * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp: (WebKit::WebAuthenticatorCoordinatorProxy::makeCredential): (WebKit::WebAuthenticatorCoordinatorProxy::getAssertion): (WebKit::WebAuthenticatorCoordinatorProxy::handleRequest): * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h: * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp: (WebKit::CtapAuthenticator::makeCredential): (WebKit::CtapAuthenticator::continueMakeCredentialAfterResponseReceived const): (WebKit::CtapAuthenticator::getAssertion): * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp: (WebKit::U2fAuthenticator::makeCredential): (WebKit::U2fAuthenticator::checkExcludeList): (WebKit::U2fAuthenticator::issueRegisterCommand): (WebKit::U2fAuthenticator::getAssertion): (WebKit::U2fAuthenticator::issueSignCommand): (WebKit::U2fAuthenticator::continueRegisterCommandAfterResponseReceived): (WebKit::U2fAuthenticator::continueSignCommandAfterResponseReceived): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249949 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-17 Jiewen Tan [WebAuthn] Use WebPreferences instead of RuntimeEnabledFeatures in UIProcess https://bugs.webkit.org/show_bug.cgi?id=198176 Reviewed by Youenn Fablet. No changes of behavior. * Modules/webauthn/PublicKeyCredential.cpp: (WebCore::PublicKeyCredential::isUserVerifyingPlatformAuthenticatorAvailable): Resolves the promise with false immediately when the feature flag is false. 2019-10-03 Kocsen Chung Cherry-pick r249059. rdar://problem/55927255 [WebAuthn] Support NFC authenticators for iOS https://bugs.webkit.org/show_bug.cgi?id=188624 Reviewed by Chris Dumez. Source/WebCore: Tests: http/wpt/webauthn/ctap-nfc-failure.https.html http/wpt/webauthn/public-key-credential-create-failure-nfc.https.html http/wpt/webauthn/public-key-credential-create-success-nfc.https.html http/wpt/webauthn/public-key-credential-get-failure-nfc.https.html http/wpt/webauthn/public-key-credential-get-success-nfc.https.html * Modules/webauthn/apdu/ApduResponse.h: Adds a new method to support moving m_data. * Modules/webauthn/fido/FidoConstants.h: Adds constants for NFC applet selection. Source/WebKit: This patch implements support for NFC authenticators including both FIDO2 and U2F ones. It utilizes a private framework called NearField instead of CoreNFC to be able to supply a custom UI later if necessary. The patch follows almost the same flow as previous HID and Local authenticator support. 1) Discovery is via NfcService which will invoke NFHardwareManager to start a generic NFC reader session. 2) Once a reader session is established, a NfcConnection is created to start the polling and register the WKNFReaderSessionDelegate to wait for 'didDetectTags'. 3) When tags are detected, NfcConnection will determine if it meets our requriements: { type, connectability, fido applet availability }. The first tag that meets all requirement will then be returned for WebAuthn operations. 4) The first WebAuthn operation is to send authenticatorGetInfo command to determine the supported protocol, and then initialize corresponding authenticators. Noted, the sending/receiving of this command is now abstracted into FidoService which will be shared across HidService and NfcService. 5) From then, the actual WebAuthn request, either makeCredential or getAssertion will be sent. For testing, this patch follows the same flow as well. 1) MockNfcService overrides NfcService to mock the behavior of NFC Tags discovery. 2) The same class also swizzles methods from NFReaderSession to mock tag connection and communication. * Platform/spi/Cocoa/NearFieldSPI.h: Added. * Sources.txt: * SourcesCocoa.txt: * UIProcess/API/C/WKWebsiteDataStoreRef.cpp: (WKWebsiteDataStoreSetWebAuthenticationMockConfiguration): * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManagerInternal::collectTransports): * UIProcess/WebAuthentication/AuthenticatorTransportService.cpp: (WebKit::AuthenticatorTransportService::create): (WebKit::AuthenticatorTransportService::createMock): * UIProcess/WebAuthentication/Cocoa/HidService.h: * UIProcess/WebAuthentication/Cocoa/HidService.mm: (WebKit::HidService::HidService): (WebKit::HidService::deviceAdded): (WebKit::HidService::continueAddDeviceAfterGetInfo): Deleted. * UIProcess/WebAuthentication/Cocoa/NearFieldSoftLink.h: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/Cocoa/NearFieldSoftLink.mm: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/Cocoa/NfcConnection.h: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm: Added. (WebKit::fido::compareVersion): (WebKit::NfcConnection::NfcConnection): (WebKit::NfcConnection::~NfcConnection): (WebKit::NfcConnection::transact const): (WebKit::NfcConnection::didDetectTags const): * UIProcess/WebAuthentication/Cocoa/NfcService.h: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/Cocoa/NfcService.mm: Added. (WebKit::NfcService::NfcService): (WebKit::NfcService::~NfcService): (WebKit::NfcService::didConnectTag): (WebKit::NfcService::startDiscoveryInternal): (WebKit::NfcService::platformStartDiscovery): * UIProcess/WebAuthentication/Cocoa/WKNFReaderSessionDelegate.h: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/Cocoa/WKNFReaderSessionDelegate.mm: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. (-[WKNFReaderSessionDelegate initWithConnection:]): (-[WKNFReaderSessionDelegate readerSession:didDetectTags:]): * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::send): (WebKit::MockHidConnection::registerDataReceivedCallbackInternal): (WebKit::MockHidConnection::parseRequest): (WebKit::MockHidConnection::feedReports): (WebKit::MockHidConnection::shouldContinueFeedReports): * UIProcess/WebAuthentication/Mock/MockNfcService.h: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/Mock/MockNfcService.mm: Added. (-[WKMockNFTag type]): (-[WKMockNFTag initWithNFTag:]): (-[WKMockNFTag description]): (-[WKMockNFTag isEqualToNFTag:]): (-[WKMockNFTag initWithType:]): (WebKit::MockNfcService::MockNfcService): (WebKit::MockNfcService::transceive): (WebKit::MockNfcService::platformStartDiscovery): (WebKit::MockNfcService::detectTags const): * UIProcess/WebAuthentication/Mock/MockWebAuthenticationConfiguration.h: * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp: * UIProcess/WebAuthentication/fido/CtapAuthenticator.h: * UIProcess/WebAuthentication/fido/CtapNfcDriver.cpp: Added. (WebKit::CtapNfcDriver::CtapNfcDriver): (WebKit::CtapNfcDriver::transact): (WebKit::CtapNfcDriver::respondAsync const): * UIProcess/WebAuthentication/fido/CtapNfcDriver.h: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/fido/FidoService.cpp: Added. (WebKit::FidoService::FidoService): (WebKit::FidoService::getInfo): (WebKit::FidoService::continueAfterGetInfo): * UIProcess/WebAuthentication/fido/FidoService.h: Copied from Source/WebKit/UIProcess/WebAuthentication/Cocoa/HidService.h. * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp: * UIProcess/WebAuthentication/fido/U2fAuthenticator.h: * UIProcess/ios/WebPageProxyIOS.mm: * WebKit.xcodeproj/project.pbxproj: Source/WTF: * wtf/Platform.h: Add a feature flag for NearField. Tools: * WebKitTestRunner/InjectedBundle/TestRunner.cpp: (WTR::TestRunner::setWebAuthenticationMockConfiguration): Setup NFC mock testing configuration. LayoutTests: * http/wpt/webauthn/ctap-nfc-failure.https-expected.txt: Added. * http/wpt/webauthn/ctap-nfc-failure.https.html: Added. * http/wpt/webauthn/public-key-credential-create-failure-nfc.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-failure-nfc.https.html: Added. * http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-hid.https.html: This patch replaces the "local" keyword with "hid". * http/wpt/webauthn/public-key-credential-create-success-nfc.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-success-nfc.https.html: Added. * http/wpt/webauthn/public-key-credential-get-failure-nfc.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-failure-nfc.https.html: Added. * http/wpt/webauthn/public-key-credential-get-success-nfc.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-success-nfc.https.html: Added. * http/wpt/webauthn/resources/util.js: * platform/ios-simulator-wk2/TestExpectations: Skip NFC tests for simulators. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249059 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-20 Jiewen Tan [WebAuthn] Support NFC authenticators for iOS https://bugs.webkit.org/show_bug.cgi?id=188624 Reviewed by Chris Dumez. Tests: http/wpt/webauthn/ctap-nfc-failure.https.html http/wpt/webauthn/public-key-credential-create-failure-nfc.https.html http/wpt/webauthn/public-key-credential-create-success-nfc.https.html http/wpt/webauthn/public-key-credential-get-failure-nfc.https.html http/wpt/webauthn/public-key-credential-get-success-nfc.https.html * Modules/webauthn/apdu/ApduResponse.h: Adds a new method to support moving m_data. * Modules/webauthn/fido/FidoConstants.h: Adds constants for NFC applet selection. 2019-10-02 Alan Coon Cherry-pick r250238. rdar://problem/55927247 REGRESSION (r249855): Remove debug logging from WebCore::RenderImage::paintIntoRect() Reviewed by Zalan Bujtas. * rendering/RenderImage.cpp: (WebCore::RenderImage::paintIntoRect): Remove debug logging statements. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250238 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-23 David Kilzer REGRESSION (r249855): Remove debug logging from WebCore::RenderImage::paintIntoRect() Reviewed by Zalan Bujtas. * rendering/RenderImage.cpp: (WebCore::RenderImage::paintIntoRect): Remove debug logging statements. 2019-10-02 Alan Coon Cherry-pick r249855. rdar://problem/55927247 Provide a prototype for AR QuickLook to trigger processing in the originating page https://bugs.webkit.org/show_bug.cgi?id=201371 Reviewed by Simon Fraser. Source/WebCore: * dom/Document.cpp: (WebCore::Document::dispatchSystemPreviewActionEvent): Create and dispatch a MessageEvent. * dom/Document.h: * html/HTMLAnchorElement.cpp: Send along the page and frame identifiers for this object to ensure that any reply goes to the correct place. (WebCore::HTMLAnchorElement::handleClick): * loader/FrameLoadRequest.h: Use the new SystemPreviewInfo type. (WebCore::FrameLoadRequest::isSystemPreview const): (WebCore::FrameLoadRequest::systemPreviewInfo const): (WebCore::FrameLoadRequest::systemPreviewRect const): Deleted. * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): * loader/FrameLoaderTypes.h: Provide encoders for the type. (WebCore::SystemPreviewInfo::encode const): (WebCore::SystemPreviewInfo::decode): * platform/network/ResourceRequestBase.cpp: Use the new type. (WebCore::ResourceRequestBase::isSystemPreview const): (WebCore::ResourceRequestBase::systemPreviewInfo const): (WebCore::ResourceRequestBase::setSystemPreviewInfo): (WebCore::ResourceRequestBase::setSystemPreview): Deleted. (WebCore::ResourceRequestBase::systemPreviewRect const): Deleted. (WebCore::ResourceRequestBase::setSystemPreviewRect): Deleted. * platform/network/ResourceRequestBase.h: * testing/Internals.cpp: Expose the frame and page identifiers to testing. (WebCore::Internals::frameIdentifier const): (WebCore::Internals::pageIdentifier const): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: Provide a way for a Web page to know if an action in the AR scene was performed, if and only if the system AR library calls a delegate with particular parameters. Post a message to the originating frame so the page can detect the action. * Scripts/webkit/messages.py: Include the right header for SystemPreviewInfo. * Shared/WebCoreArgumentCoders.cpp: Use SystemPreviewInfo. (IPC::ArgumentCoder::encode): (IPC::ArgumentCoder::decode): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _triggerSystemPreviewActionOnFrame:page:]): New helper/test function to trigger the system preview action. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/Cocoa/DownloadClient.mm: Use new type. (WebKit::DownloadClient::didStart): * UIProcess/Cocoa/SystemPreviewControllerCocoa.mm: Implement the delegate so that we can detect an action. When it happens, tell the WebPageProxy to send a message. * UIProcess/Downloads/DownloadProxy.h: Use SystemPreviewInfo type. (WebKit::DownloadProxy::systemPreviewDownloadInfo const): (WebKit::DownloadProxy::systemPreviewDownloadRect const): Deleted. * UIProcess/SystemPreviewController.h: (WebKit::SystemPreviewController::previewInfo const): * UIProcess/WebPageProxy.cpp: Send it over to the Web Process. (WebKit::WebPageProxy::systemPreviewActionTriggered const): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: Check the destination still exists, and then talk to the Document. (WebKit::WebPage::systemPreviewActionTriggered): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Tools: * TestWebKitAPI/Tools/TestWebKitAPI/Tests/WebKitCocoa/SystemPreview.mm: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/system-preview-trigger.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249855 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-11 Dean Jackson Provide a prototype for AR QuickLook to trigger processing in the originating page https://bugs.webkit.org/show_bug.cgi?id=201371 Reviewed by Simon Fraser. * dom/Document.cpp: (WebCore::Document::dispatchSystemPreviewActionEvent): Create and dispatch a MessageEvent. * dom/Document.h: * html/HTMLAnchorElement.cpp: Send along the page and frame identifiers for this object to ensure that any reply goes to the correct place. (WebCore::HTMLAnchorElement::handleClick): * loader/FrameLoadRequest.h: Use the new SystemPreviewInfo type. (WebCore::FrameLoadRequest::isSystemPreview const): (WebCore::FrameLoadRequest::systemPreviewInfo const): (WebCore::FrameLoadRequest::systemPreviewRect const): Deleted. * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): * loader/FrameLoaderTypes.h: Provide encoders for the type. (WebCore::SystemPreviewInfo::encode const): (WebCore::SystemPreviewInfo::decode): * platform/network/ResourceRequestBase.cpp: Use the new type. (WebCore::ResourceRequestBase::isSystemPreview const): (WebCore::ResourceRequestBase::systemPreviewInfo const): (WebCore::ResourceRequestBase::setSystemPreviewInfo): (WebCore::ResourceRequestBase::setSystemPreview): Deleted. (WebCore::ResourceRequestBase::systemPreviewRect const): Deleted. (WebCore::ResourceRequestBase::setSystemPreviewRect): Deleted. * platform/network/ResourceRequestBase.h: * testing/Internals.cpp: Expose the frame and page identifiers to testing. (WebCore::Internals::frameIdentifier const): (WebCore::Internals::pageIdentifier const): * testing/Internals.h: * testing/Internals.idl: 2019-10-01 Alan Coon Cherry-pick r250528. rdar://problem/55876838 Refine restrictions for X-Temp-Tablet HTTP header experiment https://bugs.webkit.org/show_bug.cgi?id=202367 Reviewed by Geoffrey Garen. Refine restrictions for X-Temp-Tablet HTTP header experiment: 1. Only send the header if the embedding application is MobileSafari. 2. Only send the header if the first party is google.com 3. Only send the header if the current date is before 2/1/2020 4. Send the header even if using an ephemeral session * loader/cache/CachedResourceLoader.cpp: (WebCore::isXTempTabletHeaderExperimentOver): (WebCore::CachedResourceLoader::CachedResourceLoader): (WebCore::isGoogleSearch): (WebCore::CachedResourceLoader::shouldSendXTempTabletHeader const): (WebCore::CachedResourceLoader::requestResource): * loader/cache/CachedResourceLoader.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250528 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-30 Chris Dumez Refine restrictions for X-Temp-Tablet HTTP header experiment https://bugs.webkit.org/show_bug.cgi?id=202367 Reviewed by Geoffrey Garen. Refine restrictions for X-Temp-Tablet HTTP header experiment: 1. Only send the header if the embedding application is MobileSafari. 2. Only send the header if the first party is google.com 3. Only send the header if the current date is before 2/1/2020 4. Send the header even if using an ephemeral session * loader/cache/CachedResourceLoader.cpp: (WebCore::isXTempTabletHeaderExperimentOver): (WebCore::CachedResourceLoader::CachedResourceLoader): (WebCore::isGoogleSearch): (WebCore::CachedResourceLoader::shouldSendXTempTabletHeader const): (WebCore::CachedResourceLoader::requestResource): * loader/cache/CachedResourceLoader.h: 2019-09-30 Kocsen Chung Cherry-pick r250483. rdar://problem/55825351 [Experiment][iOS] Add temporary HTTP header to distinguish iPads for requests to Google https://bugs.webkit.org/show_bug.cgi?id=202335 Reviewed by Maciej Stachowiak. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::requestResource): * platform/network/HTTPHeaderNames.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250483 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-28 Chris Dumez [Experiment][iOS] Add temporary HTTP header to distinguish iPads for requests to Google https://bugs.webkit.org/show_bug.cgi?id=202335 Reviewed by Maciej Stachowiak. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::requestResource): * platform/network/HTTPHeaderNames.in: 2019-09-30 Kocsen Chung Cherry-pick r250488. rdar://problem/55826334 Crash when removing the target element while animating its attributes https://bugs.webkit.org/show_bug.cgi?id=202247 Reviewed by Darin Adler. Source/WebCore: If SMIL is animating a CSS attribute, there is a chance the animation is ended while it is being started or progressed. For that reason, the member SVGAnimateElementBase::m_animator has to be made RefPtr and it has to be be protected in resetAnimatedType() and calculateAnimatedValue(). While SMILTimeContainer::updateAnimations() is calling progress() for the scheduled animation elements, SMILTimeContainer::unschedule() might get called if processing an animation causes events to be dispatched. For that reason we need to copy the scheduled animations Vector before processing them so we avoid changing the Vector while looping through its items. Remove the guard SMILTimeContainer::m_preventScheduledAnimationsChanges which was added in r129670 for debugging purposes. In some situations, the scheduled animations map could be modified out from under some of the functions of SMILTimeContainer. Test: svg/animations/animate-and-remove-target-element.html * svg/SVGAnimateElementBase.cpp: (WebCore::SVGAnimateElementBase::resetAnimatedType): (WebCore::SVGAnimateElementBase::calculateAnimatedValue): * svg/SVGAnimateElementBase.h: * svg/SVGElement.cpp: (WebCore::SVGElement::createAnimator): * svg/SVGElement.h: * svg/animation/SMILTimeContainer.cpp: (WebCore::SMILTimeContainer::schedule): (WebCore::SMILTimeContainer::unschedule): (WebCore::SMILTimeContainer::setElapsed): (WebCore::SMILTimeContainer::sortByPriority): (WebCore::SMILTimeContainer::processAnimations): (WebCore::SMILTimeContainer::processScheduledAnimations): (WebCore::SMILTimeContainer::updateAnimations): (WebCore::SMILTimeContainer::~SMILTimeContainer): Deleted. * svg/animation/SMILTimeContainer.h: * svg/animation/SVGSMILElement.cpp: (WebCore::SVGSMILElement::calculateNextProgressTime const): * svg/properties/SVGAnimatedPropertyAccessorImpl.h: * svg/properties/SVGAnimatedPropertyAnimatorImpl.h: * svg/properties/SVGAnimatedPropertyPairAccessorImpl.h: * svg/properties/SVGAnimatedPropertyPairAnimator.h: * svg/properties/SVGAnimatedPropertyPairAnimatorImpl.h: * svg/properties/SVGAttributeAnimator.h: * svg/properties/SVGMemberAccessor.h: (WebCore::SVGMemberAccessor::createAnimator const): * svg/properties/SVGPrimitivePropertyAnimator.h: (WebCore::SVGPrimitivePropertyAnimator::create): * svg/properties/SVGPropertyAnimatorFactory.h: (WebCore::SVGPropertyAnimatorFactory::createAnimator): * svg/properties/SVGPropertyOwnerRegistry.h: * svg/properties/SVGPropertyRegistry.h: * svg/properties/SVGValuePropertyAnimatorImpl.h: * svg/properties/SVGValuePropertyListAnimatorImpl.h: LayoutTests: * svg/animations/animate-and-remove-target-element-expected.txt: Added. * svg/animations/animate-and-remove-target-element.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250488 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-28 Said Abou-Hallawa Crash when removing the target element while animating its attributes https://bugs.webkit.org/show_bug.cgi?id=202247 Reviewed by Darin Adler. If SMIL is animating a CSS attribute, there is a chance the animation is ended while it is being started or progressed. For that reason, the member SVGAnimateElementBase::m_animator has to be made RefPtr and it has to be be protected in resetAnimatedType() and calculateAnimatedValue(). While SMILTimeContainer::updateAnimations() is calling progress() for the scheduled animation elements, SMILTimeContainer::unschedule() might get called if processing an animation causes events to be dispatched. For that reason we need to copy the scheduled animations Vector before processing them so we avoid changing the Vector while looping through its items. Remove the guard SMILTimeContainer::m_preventScheduledAnimationsChanges which was added in r129670 for debugging purposes. In some situations, the scheduled animations map could be modified out from under some of the functions of SMILTimeContainer. Test: svg/animations/animate-and-remove-target-element.html * svg/SVGAnimateElementBase.cpp: (WebCore::SVGAnimateElementBase::resetAnimatedType): (WebCore::SVGAnimateElementBase::calculateAnimatedValue): * svg/SVGAnimateElementBase.h: * svg/SVGElement.cpp: (WebCore::SVGElement::createAnimator): * svg/SVGElement.h: * svg/animation/SMILTimeContainer.cpp: (WebCore::SMILTimeContainer::schedule): (WebCore::SMILTimeContainer::unschedule): (WebCore::SMILTimeContainer::setElapsed): (WebCore::SMILTimeContainer::sortByPriority): (WebCore::SMILTimeContainer::processAnimations): (WebCore::SMILTimeContainer::processScheduledAnimations): (WebCore::SMILTimeContainer::updateAnimations): (WebCore::SMILTimeContainer::~SMILTimeContainer): Deleted. * svg/animation/SMILTimeContainer.h: * svg/animation/SVGSMILElement.cpp: (WebCore::SVGSMILElement::calculateNextProgressTime const): * svg/properties/SVGAnimatedPropertyAccessorImpl.h: * svg/properties/SVGAnimatedPropertyAnimatorImpl.h: * svg/properties/SVGAnimatedPropertyPairAccessorImpl.h: * svg/properties/SVGAnimatedPropertyPairAnimator.h: * svg/properties/SVGAnimatedPropertyPairAnimatorImpl.h: * svg/properties/SVGAttributeAnimator.h: * svg/properties/SVGMemberAccessor.h: (WebCore::SVGMemberAccessor::createAnimator const): * svg/properties/SVGPrimitivePropertyAnimator.h: (WebCore::SVGPrimitivePropertyAnimator::create): * svg/properties/SVGPropertyAnimatorFactory.h: (WebCore::SVGPropertyAnimatorFactory::createAnimator): * svg/properties/SVGPropertyOwnerRegistry.h: * svg/properties/SVGPropertyRegistry.h: * svg/properties/SVGValuePropertyAnimatorImpl.h: * svg/properties/SVGValuePropertyListAnimatorImpl.h: 2019-09-30 Kocsen Chung Cherry-pick r249822. rdar://problem/55826334 SVGLengthValue should use two enums for 'type' and 'mode' instead of one unsigned for 'units' https://bugs.webkit.org/show_bug.cgi?id=201663 Patch by Said Abou-Hallawa on 2019-09-12 Reviewed by Simon Fraser, Nikolas Zimmermann. SVGLengthValue had one unsigned to store SVGLengthMode and SVGLengthType. It used to allocate the least significant 4 bits of this unsigned to the SVGLengthMode while it leaves the rest for SVGLengthType. This will not be needed if SVGLengthMode and SVGLengthType are made of size uint_8. Also in this patch: -- SVGLengthNegativeValuesMode is made enum class. -- SVGLengthValue::blend() is moved to SVGLengthValue.cpp so we do not need to include SVGLengthContext.h in SVGLengthValue.h. -- SVGLengthType and SVGLengthMode are moved to SVGLengthValue.h. Instead of having SVGLengthValue.h includes SVGLengthConttext.h, the opposite will happen. -- SVGAnimatedPropertyDescription.h is deleted. It should have been deleted with the SVG tear off objects removal. -- SVGPropertyTraits and SVGPropertyTraits are deleted. They should have been deleted with SVGAnimatedType removal. -- SVGLengthValue::lengthModeForAnimatedLengthAttribute() is deleted. It was only called from SVGPropertyTraits. * WebCore.xcodeproj/project.pbxproj: * css/StyleResolver.h: * page/animation/CSSPropertyAnimation.cpp: (WebCore::blendFunc): * rendering/style/SVGRenderStyle.h: (WebCore::SVGRenderStyle::initialBaselineShiftValue): (WebCore::SVGRenderStyle::initialKerning): * rendering/svg/RenderSVGEllipse.cpp: (WebCore::RenderSVGEllipse::calculateRadiiAndCenter): * rendering/svg/RenderSVGRect.cpp: (WebCore::RenderSVGRect::updateShapeFromElement): * rendering/svg/SVGPathData.cpp: (WebCore::pathFromCircleElement): (WebCore::pathFromEllipseElement): (WebCore::pathFromRectElement): * rendering/svg/SVGTextLayoutEngineBaseline.cpp: (WebCore::SVGTextLayoutEngineBaseline::calculateBaselineShift const): * rendering/svg/SVGTextLayoutEngineSpacing.cpp: (WebCore::SVGTextLayoutEngineSpacing::calculateCSSKerningAndSpacing): * svg/LinearGradientAttributes.h: (WebCore::LinearGradientAttributes::LinearGradientAttributes): * svg/RadialGradientAttributes.h: (WebCore::RadialGradientAttributes::RadialGradientAttributes): * svg/SVGAngleValue.h: (WebCore::SVGPropertyTraits::initialValue): Deleted. (WebCore::SVGPropertyTraits::toString): Deleted. * svg/SVGCircleElement.cpp: (WebCore::SVGCircleElement::parseAttribute): * svg/SVGCircleElement.h: * svg/SVGCursorElement.cpp: (WebCore::SVGCursorElement::parseAttribute): * svg/SVGCursorElement.h: * svg/SVGEllipseElement.cpp: (WebCore::SVGEllipseElement::parseAttribute): * svg/SVGEllipseElement.h: * svg/SVGFilterElement.cpp: (WebCore::SVGFilterElement::parseAttribute): * svg/SVGFilterElement.h: * svg/SVGFilterPrimitiveStandardAttributes.cpp: (WebCore::SVGFilterPrimitiveStandardAttributes::parseAttribute): * svg/SVGFilterPrimitiveStandardAttributes.h: * svg/SVGForeignObjectElement.cpp: (WebCore::SVGForeignObjectElement::parseAttribute): * svg/SVGForeignObjectElement.h: * svg/SVGImageElement.cpp: (WebCore::SVGImageElement::parseAttribute): * svg/SVGImageElement.h: * svg/SVGLength.h: (WebCore::SVGLength::unitType const): (WebCore::SVGLength::setValueForBindings): (WebCore::SVGLength::newValueSpecifiedUnits): (WebCore::SVGLength::convertToSpecifiedUnits): (WebCore::SVGLength::unitType): Deleted. * svg/SVGLengthContext.cpp: (WebCore::SVGLengthContext::valueForLength): (WebCore::SVGLengthContext::convertValueToUserUnits const): (WebCore::SVGLengthContext::convertValueFromUserUnits const): (WebCore::SVGLengthContext::convertValueFromUserUnitsToPercentage const): (WebCore::SVGLengthContext::convertValueFromPercentageToUserUnits const): * svg/SVGLengthContext.h: (): Deleted. * svg/SVGLengthList.h: (WebCore::SVGLengthList::create): * svg/SVGLengthValue.cpp: (WebCore::lengthTypeToString): (WebCore::parseLengthType): (WebCore::primitiveTypeToLengthType): (WebCore::lengthTypeToPrimitiveType): (WebCore::SVGLengthValue::SVGLengthValue): (WebCore::SVGLengthValue::construct): (WebCore::SVGLengthValue::blend): (WebCore::SVGLengthValue::fromCSSPrimitiveValue): (WebCore::SVGLengthValue::toCSSPrimitiveValue): (WebCore::SVGLengthValue::setValueAsString): (WebCore::SVGLengthValue::valueAsString const): (WebCore::SVGLengthValue::valueForBindings const): (WebCore::SVGLengthValue::setValue): (WebCore::SVGLengthValue::convertToSpecifiedUnits): (WebCore::storeUnit): Deleted. (WebCore::extractMode): Deleted. (WebCore::extractType): Deleted. (WebCore::SVGLengthValue::operator== const): Deleted. (WebCore::SVGLengthValue::operator!= const): Deleted. (WebCore::SVGLengthValue::unitType const): Deleted. (WebCore::SVGLengthValue::unitMode const): Deleted. (WebCore::SVGLengthValue::valueAsPercentage const): Deleted. (WebCore::SVGLengthValue::newValueSpecifiedUnits): Deleted. (WebCore::SVGLengthValue::lengthModeForAnimatedLengthAttribute): Deleted. * svg/SVGLengthValue.h: (WebCore::SVGLengthValue::lengthType const): (WebCore::SVGLengthValue::lengthMode const): (WebCore::SVGLengthValue::isZero const): (WebCore::SVGLengthValue::isRelative const): (WebCore::SVGLengthValue::valueAsPercentage const): (WebCore::SVGLengthValue::valueInSpecifiedUnits const): (WebCore::operator==): (WebCore::operator!=): (WebCore::SVGLengthValue::blend const): Deleted. (WebCore::SVGPropertyTraits::initialValue): Deleted. (WebCore::SVGPropertyTraits::parse): Deleted. (WebCore::SVGPropertyTraits::toString): Deleted. * svg/SVGLineElement.cpp: (WebCore::SVGLineElement::parseAttribute): * svg/SVGLineElement.h: * svg/SVGLinearGradientElement.cpp: (WebCore::SVGLinearGradientElement::parseAttribute): * svg/SVGLinearGradientElement.h: * svg/SVGMarkerElement.cpp: (WebCore::SVGMarkerElement::parseAttribute): * svg/SVGMarkerElement.h: * svg/SVGMaskElement.cpp: (WebCore::SVGMaskElement::parseAttribute): * svg/SVGMaskElement.h: * svg/SVGPatternElement.cpp: (WebCore::SVGPatternElement::parseAttribute): * svg/SVGPatternElement.h: * svg/SVGRadialGradientElement.cpp: (WebCore::SVGRadialGradientElement::parseAttribute): * svg/SVGRadialGradientElement.h: * svg/SVGRectElement.cpp: (WebCore::SVGRectElement::parseAttribute): * svg/SVGRectElement.h: * svg/SVGSVGElement.cpp: (WebCore::SVGSVGElement::parseAttribute): (WebCore::SVGSVGElement::hasIntrinsicWidth const): (WebCore::SVGSVGElement::hasIntrinsicHeight const): (WebCore::SVGSVGElement::intrinsicWidth const): (WebCore::SVGSVGElement::intrinsicHeight const): * svg/SVGSVGElement.h: * svg/SVGTextContentElement.cpp: (WebCore::SVGTextContentElement::parseAttribute): (WebCore::SVGTextContentElement::textLengthAnimated): * svg/SVGTextContentElement.h: * svg/SVGTextPathElement.cpp: (WebCore::SVGTextPathElement::parseAttribute): * svg/SVGTextPathElement.h: * svg/SVGTextPositioningElement.h: * svg/SVGUseElement.cpp: (WebCore::SVGUseElement::parseAttribute): * svg/SVGUseElement.h: * svg/properties/SVGAnimatedPropertyAccessorImpl.h: * svg/properties/SVGAnimatedPropertyDescription.h: Removed. * svg/properties/SVGAnimationAdditiveListFunctionImpl.h: (WebCore::SVGAnimationLengthListFunction::animate): * svg/properties/SVGAnimationAdditiveValueFunctionImpl.h: (WebCore::SVGAnimationLengthFunction::animate): * svg/properties/SVGValuePropertyAnimatorImpl.h: * svg/properties/SVGValuePropertyListAnimatorImpl.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249822 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-12 Said Abou-Hallawa SVGLengthValue should use two enums for 'type' and 'mode' instead of one unsigned for 'units' https://bugs.webkit.org/show_bug.cgi?id=201663 Reviewed by Simon Fraser, Nikolas Zimmermann. SVGLengthValue had one unsigned to store SVGLengthMode and SVGLengthType. It used to allocate the least significant 4 bits of this unsigned to the SVGLengthMode while it leaves the rest for SVGLengthType. This will not be needed if SVGLengthMode and SVGLengthType are made of size uint_8. Also in this patch: -- SVGLengthNegativeValuesMode is made enum class. -- SVGLengthValue::blend() is moved to SVGLengthValue.cpp so we do not need to include SVGLengthContext.h in SVGLengthValue.h. -- SVGLengthType and SVGLengthMode are moved to SVGLengthValue.h. Instead of having SVGLengthValue.h includes SVGLengthConttext.h, the opposite will happen. -- SVGAnimatedPropertyDescription.h is deleted. It should have been deleted with the SVG tear off objects removal. -- SVGPropertyTraits and SVGPropertyTraits are deleted. They should have been deleted with SVGAnimatedType removal. -- SVGLengthValue::lengthModeForAnimatedLengthAttribute() is deleted. It was only called from SVGPropertyTraits. * WebCore.xcodeproj/project.pbxproj: * css/StyleResolver.h: * page/animation/CSSPropertyAnimation.cpp: (WebCore::blendFunc): * rendering/style/SVGRenderStyle.h: (WebCore::SVGRenderStyle::initialBaselineShiftValue): (WebCore::SVGRenderStyle::initialKerning): * rendering/svg/RenderSVGEllipse.cpp: (WebCore::RenderSVGEllipse::calculateRadiiAndCenter): * rendering/svg/RenderSVGRect.cpp: (WebCore::RenderSVGRect::updateShapeFromElement): * rendering/svg/SVGPathData.cpp: (WebCore::pathFromCircleElement): (WebCore::pathFromEllipseElement): (WebCore::pathFromRectElement): * rendering/svg/SVGTextLayoutEngineBaseline.cpp: (WebCore::SVGTextLayoutEngineBaseline::calculateBaselineShift const): * rendering/svg/SVGTextLayoutEngineSpacing.cpp: (WebCore::SVGTextLayoutEngineSpacing::calculateCSSKerningAndSpacing): * svg/LinearGradientAttributes.h: (WebCore::LinearGradientAttributes::LinearGradientAttributes): * svg/RadialGradientAttributes.h: (WebCore::RadialGradientAttributes::RadialGradientAttributes): * svg/SVGAngleValue.h: (WebCore::SVGPropertyTraits::initialValue): Deleted. (WebCore::SVGPropertyTraits::toString): Deleted. * svg/SVGCircleElement.cpp: (WebCore::SVGCircleElement::parseAttribute): * svg/SVGCircleElement.h: * svg/SVGCursorElement.cpp: (WebCore::SVGCursorElement::parseAttribute): * svg/SVGCursorElement.h: * svg/SVGEllipseElement.cpp: (WebCore::SVGEllipseElement::parseAttribute): * svg/SVGEllipseElement.h: * svg/SVGFilterElement.cpp: (WebCore::SVGFilterElement::parseAttribute): * svg/SVGFilterElement.h: * svg/SVGFilterPrimitiveStandardAttributes.cpp: (WebCore::SVGFilterPrimitiveStandardAttributes::parseAttribute): * svg/SVGFilterPrimitiveStandardAttributes.h: * svg/SVGForeignObjectElement.cpp: (WebCore::SVGForeignObjectElement::parseAttribute): * svg/SVGForeignObjectElement.h: * svg/SVGImageElement.cpp: (WebCore::SVGImageElement::parseAttribute): * svg/SVGImageElement.h: * svg/SVGLength.h: (WebCore::SVGLength::unitType const): (WebCore::SVGLength::setValueForBindings): (WebCore::SVGLength::newValueSpecifiedUnits): (WebCore::SVGLength::convertToSpecifiedUnits): (WebCore::SVGLength::unitType): Deleted. * svg/SVGLengthContext.cpp: (WebCore::SVGLengthContext::valueForLength): (WebCore::SVGLengthContext::convertValueToUserUnits const): (WebCore::SVGLengthContext::convertValueFromUserUnits const): (WebCore::SVGLengthContext::convertValueFromUserUnitsToPercentage const): (WebCore::SVGLengthContext::convertValueFromPercentageToUserUnits const): * svg/SVGLengthContext.h: (): Deleted. * svg/SVGLengthList.h: (WebCore::SVGLengthList::create): * svg/SVGLengthValue.cpp: (WebCore::lengthTypeToString): (WebCore::parseLengthType): (WebCore::primitiveTypeToLengthType): (WebCore::lengthTypeToPrimitiveType): (WebCore::SVGLengthValue::SVGLengthValue): (WebCore::SVGLengthValue::construct): (WebCore::SVGLengthValue::blend): (WebCore::SVGLengthValue::fromCSSPrimitiveValue): (WebCore::SVGLengthValue::toCSSPrimitiveValue): (WebCore::SVGLengthValue::setValueAsString): (WebCore::SVGLengthValue::valueAsString const): (WebCore::SVGLengthValue::valueForBindings const): (WebCore::SVGLengthValue::setValue): (WebCore::SVGLengthValue::convertToSpecifiedUnits): (WebCore::storeUnit): Deleted. (WebCore::extractMode): Deleted. (WebCore::extractType): Deleted. (WebCore::SVGLengthValue::operator== const): Deleted. (WebCore::SVGLengthValue::operator!= const): Deleted. (WebCore::SVGLengthValue::unitType const): Deleted. (WebCore::SVGLengthValue::unitMode const): Deleted. (WebCore::SVGLengthValue::valueAsPercentage const): Deleted. (WebCore::SVGLengthValue::newValueSpecifiedUnits): Deleted. (WebCore::SVGLengthValue::lengthModeForAnimatedLengthAttribute): Deleted. * svg/SVGLengthValue.h: (WebCore::SVGLengthValue::lengthType const): (WebCore::SVGLengthValue::lengthMode const): (WebCore::SVGLengthValue::isZero const): (WebCore::SVGLengthValue::isRelative const): (WebCore::SVGLengthValue::valueAsPercentage const): (WebCore::SVGLengthValue::valueInSpecifiedUnits const): (WebCore::operator==): (WebCore::operator!=): (WebCore::SVGLengthValue::blend const): Deleted. (WebCore::SVGPropertyTraits::initialValue): Deleted. (WebCore::SVGPropertyTraits::parse): Deleted. (WebCore::SVGPropertyTraits::toString): Deleted. * svg/SVGLineElement.cpp: (WebCore::SVGLineElement::parseAttribute): * svg/SVGLineElement.h: * svg/SVGLinearGradientElement.cpp: (WebCore::SVGLinearGradientElement::parseAttribute): * svg/SVGLinearGradientElement.h: * svg/SVGMarkerElement.cpp: (WebCore::SVGMarkerElement::parseAttribute): * svg/SVGMarkerElement.h: * svg/SVGMaskElement.cpp: (WebCore::SVGMaskElement::parseAttribute): * svg/SVGMaskElement.h: * svg/SVGPatternElement.cpp: (WebCore::SVGPatternElement::parseAttribute): * svg/SVGPatternElement.h: * svg/SVGRadialGradientElement.cpp: (WebCore::SVGRadialGradientElement::parseAttribute): * svg/SVGRadialGradientElement.h: * svg/SVGRectElement.cpp: (WebCore::SVGRectElement::parseAttribute): * svg/SVGRectElement.h: * svg/SVGSVGElement.cpp: (WebCore::SVGSVGElement::parseAttribute): (WebCore::SVGSVGElement::hasIntrinsicWidth const): (WebCore::SVGSVGElement::hasIntrinsicHeight const): (WebCore::SVGSVGElement::intrinsicWidth const): (WebCore::SVGSVGElement::intrinsicHeight const): * svg/SVGSVGElement.h: * svg/SVGTextContentElement.cpp: (WebCore::SVGTextContentElement::parseAttribute): (WebCore::SVGTextContentElement::textLengthAnimated): * svg/SVGTextContentElement.h: * svg/SVGTextPathElement.cpp: (WebCore::SVGTextPathElement::parseAttribute): * svg/SVGTextPathElement.h: * svg/SVGTextPositioningElement.h: * svg/SVGUseElement.cpp: (WebCore::SVGUseElement::parseAttribute): * svg/SVGUseElement.h: * svg/properties/SVGAnimatedPropertyAccessorImpl.h: * svg/properties/SVGAnimatedPropertyDescription.h: Removed. * svg/properties/SVGAnimationAdditiveListFunctionImpl.h: (WebCore::SVGAnimationLengthListFunction::animate): * svg/properties/SVGAnimationAdditiveValueFunctionImpl.h: (WebCore::SVGAnimationLengthFunction::animate): * svg/properties/SVGValuePropertyAnimatorImpl.h: * svg/properties/SVGValuePropertyListAnimatorImpl.h: 2019-09-30 Babak Shafiei Cherry-pick r249930. rdar://problem/55826316 AX: USER: VO: Messages > Message > Shift-VO-M doesn't reveal correct actions https://bugs.webkit.org/show_bug.cgi?id=201840 Patch by Eric Liang on 2019-09-16 Reviewed by Chris Fleizach. menuForEvent: expects event-position in window's space, but we pass the position in Core's space. In this case, we need to convert core's space to window's space. Tested that existing tests passed with WK1 and WK2 * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityShowContextMenu]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249930 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-16 Eric Liang AX: USER: VO: Messages > Message > Shift-VO-M doesn't reveal correct actions https://bugs.webkit.org/show_bug.cgi?id=201840 Reviewed by Chris Fleizach. menuForEvent: expects event-position in window's space, but we pass the position in Core's space. In this case, we need to convert core's space to window's space. Tested that existing tests passed with WK1 and WK2 * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityShowContextMenu]): 2019-09-30 Babak Shafiei Cherry-pick r249077. rdar://problem/55826882 Crash under TimerBase::setNextFireTime() in the NetworkProcess https://bugs.webkit.org/show_bug.cgi?id=201097 Reviewed by Ryosuke Niwa. NetworkStateNotifier is a WebCore/platform class used by both WebKitLegacy and WebKit2 in the NetworkProcess. On iOS, the lambda in the implementation of NetworkStateNotifier::startObserving() may get called by the underlying framework on a non-main thread and we therefore want to go back to the main thread before calling NetworkStateNotifier::singleton().updateStateSoon(). This is important because updateStateSoon() will schedule a WebCore::Timer. The issue is that the code was using WebThreadRun() to go back the the main thread. While this works fine in iOS WK1, it does not do what we want in WebKit2 in the network process. Indeed, before there is no WebThread in the network process, WebThreadRun() will simply run the block on whatever thread we're one. This would lead to crashes when trying to schedule the Timer in updateStateSoon(). To address the issue, we now use callOnMainThread(). * platform/network/ios/NetworkStateNotifierIOS.mm: (WebCore::NetworkStateNotifier::startObserving): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249077 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-23 Chris Dumez Crash under TimerBase::setNextFireTime() in the NetworkProcess https://bugs.webkit.org/show_bug.cgi?id=201097 Reviewed by Ryosuke Niwa. NetworkStateNotifier is a WebCore/platform class used by both WebKitLegacy and WebKit2 in the NetworkProcess. On iOS, the lambda in the implementation of NetworkStateNotifier::startObserving() may get called by the underlying framework on a non-main thread and we therefore want to go back to the main thread before calling NetworkStateNotifier::singleton().updateStateSoon(). This is important because updateStateSoon() will schedule a WebCore::Timer. The issue is that the code was using WebThreadRun() to go back the the main thread. While this works fine in iOS WK1, it does not do what we want in WebKit2 in the network process. Indeed, before there is no WebThread in the network process, WebThreadRun() will simply run the block on whatever thread we're one. This would lead to crashes when trying to schedule the Timer in updateStateSoon(). To address the issue, we now use callOnMainThread(). * platform/network/ios/NetworkStateNotifierIOS.mm: (WebCore::NetworkStateNotifier::startObserving): 2019-09-30 Babak Shafiei Cherry-pick r248591. rdar://problem/55826878 FrameLoader::open can execute scritps via style recalc in Frame::setDocument https://bugs.webkit.org/show_bug.cgi?id=200377 Reviewed by Antti Koivisto. Source/WebCore: Fixed the bug that FrameLoader::open can execute arbitrary author scripts via post style update callbacks by adding PostResolutionCallbackDisabler, WidgetHierarchyUpdatesSuspensionScope, and NavigationDisabler to CachedFrameBase::restore and FrameLoader::open. This ensures all frames are restored from the page cache before any of them would start running scripts. Test: fast/frames/restoring-page-cache-should-not-run-scripts-via-style-update.html * history/CachedFrame.cpp: (WebCore::CachedFrameBase::restore): * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): * page/FrameViewLayoutContext.cpp: (WebCore::FrameViewLayoutContext::layout): Fixed the debug assertion. The layout of a document may be updated while we're preparing to put a page into the page cache. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateCompositingLayers): Ditto. LayoutTests: Added a regression test. * fast/frames/restoring-page-cache-should-not-run-scripts-via-style-update-expected.txt: Added. * fast/frames/restoring-page-cache-should-not-run-scripts-via-style-update.html: Added. * platform/win/TestExpectations: Skip the newly added test. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248591 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-12 Ryosuke Niwa FrameLoader::open can execute scritps via style recalc in Frame::setDocument https://bugs.webkit.org/show_bug.cgi?id=200377 Reviewed by Antti Koivisto. Fixed the bug that FrameLoader::open can execute arbitrary author scripts via post style update callbacks by adding PostResolutionCallbackDisabler, WidgetHierarchyUpdatesSuspensionScope, and NavigationDisabler to CachedFrameBase::restore and FrameLoader::open. This ensures all frames are restored from the page cache before any of them would start running scripts. Test: fast/frames/restoring-page-cache-should-not-run-scripts-via-style-update.html * history/CachedFrame.cpp: (WebCore::CachedFrameBase::restore): * loader/FrameLoader.cpp: (WebCore::FrameLoader::open): * page/FrameViewLayoutContext.cpp: (WebCore::FrameViewLayoutContext::layout): Fixed the debug assertion. The layout of a document may be updated while we're preparing to put a page into the page cache. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateCompositingLayers): Ditto. 2019-09-30 Babak Shafiei Cherry-pick r248173. rdar://problem/55826879 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-09-30 Babak Shafiei Cherry-pick r248172. rdar://problem/55826873 Document::resume should delay resetting of form control elements. https://bugs.webkit.org/show_bug.cgi?id=200376 Reviewed by Geoffrey Garen. Source/WebCore: Delay the execution of form control element resets until the next task to avoid synchronously mutating DOM during page cache restoration. Test: fast/frames/restoring-page-cache-should-not-run-scripts.html * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::resumeFromDocumentSuspension): * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::resumeFromDocumentSuspension): LayoutTests: Added a regression test. * fast/frames/restoring-page-cache-should-not-run-scripts-expected.txt: Added. * fast/frames/restoring-page-cache-should-not-run-scripts.html: Added. * platform/win/TestExpectations: Skip this test on Windows since navigating to blob fails on Windows. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248172 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Ryosuke Niwa Document::resume should delay resetting of form control elements. https://bugs.webkit.org/show_bug.cgi?id=200376 Reviewed by Geoffrey Garen. Delay the execution of form control element resets until the next task to avoid synchronously mutating DOM during page cache restoration. Test: fast/frames/restoring-page-cache-should-not-run-scripts.html * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::resumeFromDocumentSuspension): * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::resumeFromDocumentSuspension): 2019-09-30 Babak Shafiei Revert r250483. rdar://problem/55825351 2019-09-29 Alan Coon Cherry-pick r250483. rdar://problem/55825351 [Experiment][iOS] Add temporary HTTP header to distinguish iPads for requests to Google https://bugs.webkit.org/show_bug.cgi?id=202335 Reviewed by Maciej Stachowiak. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::requestResource): * platform/network/HTTPHeaderNames.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250483 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-28 Chris Dumez [Experiment][iOS] Add temporary HTTP header to distinguish iPads for requests to Google https://bugs.webkit.org/show_bug.cgi?id=202335 Reviewed by Maciej Stachowiak. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::requestResource): * platform/network/HTTPHeaderNames.in: 2019-09-29 Alan Coon Cherry-pick r250345. rdar://problem/55825352 [iPadOS] [DataActivation] Focus moves away after focusing input fields on www.att.com https://bugs.webkit.org/show_bug.cgi?id=202167 Reviewed by Tim Horton. Source/WebCore: Adds a new site-specific quirk. See WebKit ChangeLog for more details. * page/Quirks.cpp: (WebCore::Quirks::shouldUseLegacySelectPopoverDismissalBehaviorInDataActivation const): * page/Quirks.h: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isDataActivation): Source/WebKit: When using the data activation page on www.att.com, one of the sections on the page contains several select elements; in the case where the user agent: 1. contains the string "iPad", and 2. does not contain the string "Safari" ...www.att.com's data activation page will opt into a mode where it adds blur event listeners to the select elements; in this blur event listener, www.att.com proceeds to programmatically focus a non-editable div element after a 1 second timeout. The reasons for this behavior remain unclear to me, though it's worth noting that the blur event handler name is "screenReaderFocus", which suggests that this is in place to ensure compatibility with screen readers. In iOS 12, dismissing the popover would blur the focused select menu with an animation. Since the animation would take a slightly less than 1 second, www.att.com's logic would have the effect of moving focus to the div element shortly after dismissing the select menu. However, after r243808, we no longer attempt to blur the focused select element when dismissing the popover. This means that the select element is only blurred the next time the user activates another focused element, such as one of the input fields on the page, or a different select element. Consequently, the logic to move focus into a div element now occurs only after a different element has already been focused; this results in focus moving away from newly focused elements after 1 second in the case where a select element has previously focused. To mitigate this, restore iOS 12 behavior behind a site- and app-specific quirk. See comments below for more details. * Shared/FocusedElementInformation.cpp: (WebKit::FocusedElementInformation::encode const): (WebKit::FocusedElementInformation::decode): * Shared/FocusedElementInformation.h: Add a new behavioral quirk flag to FocusedElementInformation to determine whether we should use "legacy" select popover dismissal behavior (i.e. blurring the focused select element when dismissing the select popover, as well as dismissing the popover with animation). * Shared/WebPreferences.yaml: Enable site-specific quirks by default in WKWebView. With regards to this bug, this change allows for site-specific hacks (namely, legacy select popover dismissal) in DataActivation. However, this also fixes various known bugs that are otherwise addressed in Safari only, via site-specific quirks. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): For apps linked on or before iOS 13 and macOS 10.15, revert the default of value of NeedsSiteSpecificQuirks to false. This is done here instead of in a default value function in WebPreferencesDefaultValues to prevent the default values of NeedsSiteSpecificQuirks in the web process and UI process from going out of sync, since the web process is not necessarily linked against the same SDK as the application. * UIProcess/Cocoa/VersionChecks.h: Add a new DYLD version check for the first version of iOS and macOS where site-specific quirks are enabled by default. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView endEditingAndUpdateFocusAppearanceWithReason:]): (-[WKContentView _elementDidBlur]): (-[WKContentView _shouldUseLegacySelectPopoverDismissalBehavior]): We only use "legacy" select popover dismissal behavior in the case where the site-specific quirk flag is on, a select popover is used (i.e. the device is an iPad and a select element is focused), and the application bundle is "com.apple.DataActivation". * UIProcess/ios/forms/WKFormSelectPopover.mm: (-[WKSelectTableViewController shouldDismissWithAnimation]): Keyed off of _shouldUseLegacySelectPopoverDismissalBehavior. (-[WKSelectPopover controlEndEditing]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getFocusedElementInformation): Source/WTF: Declare DYLD_IOS_VERSION_13_2. * wtf/spi/darwin/dyldSPI.h: Tools: Rebaseline an API test. * TestWebKitAPI/Tests/WebKit/WKPreferences.cpp: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250345 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-25 Wenson Hsieh [iPadOS] [DataActivation] Focus moves away after focusing input fields on www.att.com https://bugs.webkit.org/show_bug.cgi?id=202167 Reviewed by Tim Horton. Adds a new site-specific quirk. See WebKit ChangeLog for more details. * page/Quirks.cpp: (WebCore::Quirks::shouldUseLegacySelectPopoverDismissalBehaviorInDataActivation const): * page/Quirks.h: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isDataActivation): 2019-09-29 Alan Coon Cherry-pick r249893. rdar://problem/55825342 Expose misspelling ranges for editable content to accessibility clients. https://bugs.webkit.org/show_bug.cgi?id=201752 Patch by Andres Gonzalez on 2019-09-16 Reviewed by Chris Fleizach. Source/WebCore: Test: accessibility/misspelling-range.html Added [WebAccessibilityObjectWrapper misspellingTextMarkerRange] and underlying AccessibilityObject implementation to expose misspellings to accessibility clients that provide an alternative user interface to spell checking. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::getMisspellingRange const): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper misspellingTextMarkerRange:direction:]): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (accessibilityMisspellingSearchCriteriaForParameterizedAttribute): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): Tools: Test code needed for LayoutTests/accessibility/misspelling-range.html. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::misspellingTextMarkerRange): (WTR::AccessibilityUIElement::indexForTextMarker): * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::misspellingSearchParameterizedAttributeForCriteria): (WTR::AccessibilityUIElement::misspellingTextMarkerRange): LayoutTests: * accessibility/misspelling-range-expected.txt: Added. * accessibility/misspelling-range.html: Added. * platform/ios-simulator/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249893 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-16 Andres Gonzalez Expose misspelling ranges for editable content to accessibility clients. https://bugs.webkit.org/show_bug.cgi?id=201752 Reviewed by Chris Fleizach. Test: accessibility/misspelling-range.html Added [WebAccessibilityObjectWrapper misspellingTextMarkerRange] and underlying AccessibilityObject implementation to expose misspellings to accessibility clients that provide an alternative user interface to spell checking. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::getMisspellingRange const): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper misspellingTextMarkerRange:direction:]): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (accessibilityMisspellingSearchCriteriaForParameterizedAttribute): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): 2019-09-27 Alan Coon Cherry-pick r250441. rdar://problem/55801089 [iOS] Vimeo fails to AirPlay in desktop mode https://bugs.webkit.org/show_bug.cgi?id=202322 Reviewed by Eric Carlson. Add a Quirk which opts Vimeo out of the preload=auto restriction, and allows their second video element containing a HLS stream to correctly start AirPlaying when the system route changes. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::finishInitialization): * page/Quirks.cpp: (WebCore::Quirks::needsPreloadAutoQuirk const): * page/Quirks.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250441 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-27 Jer Noble [iOS] Vimeo fails to AirPlay in desktop mode https://bugs.webkit.org/show_bug.cgi?id=202322 Reviewed by Eric Carlson. Add a Quirk which opts Vimeo out of the preload=auto restriction, and allows their second video element containing a HLS stream to correctly start AirPlaying when the system route changes. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::finishInitialization): * page/Quirks.cpp: (WebCore::Quirks::needsPreloadAutoQuirk const): * page/Quirks.h: 2019-09-27 Alan Coon Cherry-pick r250459. rdar://problem/55797570 [Win] Crash under FontCache::lastResortFallbackFont https://bugs.webkit.org/show_bug.cgi?id=202325 Reviewed by Brent Fulgham. As demonstrated by crash reports, there seems to be cases where we are not able to create a last resort fallback font on Windows. If all attempts to create a fallback font fail, create a font from the default UI font. No new tests. I have not been able to reproduce this issue. * platform/graphics/win/FontCacheWin.cpp: (WebCore::FontCache::lastResortFallbackFont): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250459 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-27 Per Arne Vollan [Win] Crash under FontCache::lastResortFallbackFont https://bugs.webkit.org/show_bug.cgi?id=202325 Reviewed by Brent Fulgham. As demonstrated by crash reports, there seems to be cases where we are not able to create a last resort fallback font on Windows. If all attempts to create a fallback font fail, create a font from the default UI font. No new tests. I have not been able to reproduce this issue. * platform/graphics/win/FontCacheWin.cpp: (WebCore::FontCache::lastResortFallbackFont): 2019-09-27 Alan Coon Cherry-pick r250365. rdar://problem/55770710 Update selections after scrolling for iframes and hide selections while iframes and overflow scrolls are scrolling. https://bugs.webkit.org/show_bug.cgi?id=202125 Reviewed by Tim Horton. Source/WebCore: Test: editing/selection/ios/update-selection-after-iframe-scroll.html When we end scrolling, make sure that iframes get a final update to ensure that the selection is in the correct position. Pipe that to WebKit/UIProcess via frame specific plath. * loader/EmptyClients.cpp: * page/EditorClient.h: * page/scrolling/AsyncScrollingCoordinator.cpp: (WebCore::AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll): Source/WebKit: Add additional calls into UIKit differentiate between main frame scrolling and overflow/iframe scrolling. Add piping for iframe specific scrolling. * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _willStartScrollingOrZooming]): (-[WKContentView _didEndScrollingOrZooming]): * WebProcess/WebCoreSupport/WebEditorClient.cpp: (WebKit::WebEditorClient::subFrameScrollPositionChanged): * WebProcess/WebCoreSupport/WebEditorClient.h: * WebProcess/WebCoreSupport/ios/WebEditorClientIOS.mm: (WebKit::WebEditorClient::subFrameScrollPositionChanged): Source/WebKitLegacy/mac: Filling out unused functions needed for new fix. * WebCoreSupport/WebEditorClient.h: LayoutTests: Test that an iframe selection is updated after a scroll is completed. * editing/selection/ios/update-selection-after-iframe-scroll-expected.txt: Added. * editing/selection/ios/update-selection-after-iframe-scroll.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250365 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-25 Megan Gardner Update selections after scrolling for iframes and hide selections while iframes and overflow scrolls are scrolling. https://bugs.webkit.org/show_bug.cgi?id=202125 Reviewed by Tim Horton. Test: editing/selection/ios/update-selection-after-iframe-scroll.html When we end scrolling, make sure that iframes get a final update to ensure that the selection is in the correct position. Pipe that to WebKit/UIProcess via frame specific plath. * loader/EmptyClients.cpp: * page/EditorClient.h: * page/scrolling/AsyncScrollingCoordinator.cpp: (WebCore::AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll): 2019-09-27 Alan Coon Cherry-pick r250361. rdar://problem/55770728 Page temporarily jumps to an excessively small viewport scale while loading usatoday.com https://bugs.webkit.org/show_bug.cgi?id=202224 Reviewed by Tim Horton. Source/WebCore: On some pages (e.g. usatoday.com), the content width of the page temporarily becomes very large during page load. This causes a couple of viewport scaling behaviors (notably, the existing shrink-to-fit heuristic in ViewportConfiguration::initialScaleFromSize, as well as the new iPad-specific content-aware shrink-to-fit heuristic in WebPage::immediatelyShrinkToFitContent) to cause the page to shrink down excessively in an attempt to fit all the content to the viewport. This causes a very ugly flash as the page appears zoomed out initially during page load, before zooming back in. To fix this, we add some sanity checks to these viewport scaling heuristics. In ViewportConfiguration's initialScaleFromSize method, in the codepath where an initial scale is not specified, we always scale to fit the contents of the page; instead, detect the case where the content width is enormous (with a threshold arbitrarily chosen to be 1920) and fall back to the scaling to fit the viewport's width, if such a width has been explicitly set. This ensures that we avoid excessive shrinking in the case where content is extremely wide, but also that we do scale the viewport down to fit all the content in the case where the content isn't extremely wide (e.g. on daringfireball.com). See WebKit ChangeLog for more detail. Test: fast/viewport/ios/shrink-to-fit-large-content-width.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): Source/WebKit: Tweaks the content-aware shrink-to-fit algorithm to bail in the case where the content width is extremely large, such that it bails instead of attempting to fit the entire content of the page. See WebCore ChangeLog for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::immediatelyShrinkToFitContent): LayoutTests: Adds a new layout test to verify that when the content width of the page is excessively large and an explicit viewport width is specified, we don't attempt to zoom out to fit the larger content width, and instead zoom to fit the explicit viewport width. * fast/viewport/ios/shrink-to-fit-large-content-width-expected.txt: Added. * fast/viewport/ios/shrink-to-fit-large-content-width.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250361 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-25 Wenson Hsieh Page temporarily jumps to an excessively small viewport scale while loading usatoday.com https://bugs.webkit.org/show_bug.cgi?id=202224 Reviewed by Tim Horton. On some pages (e.g. usatoday.com), the content width of the page temporarily becomes very large during page load. This causes a couple of viewport scaling behaviors (notably, the existing shrink-to-fit heuristic in ViewportConfiguration::initialScaleFromSize, as well as the new iPad-specific content-aware shrink-to-fit heuristic in WebPage::immediatelyShrinkToFitContent) to cause the page to shrink down excessively in an attempt to fit all the content to the viewport. This causes a very ugly flash as the page appears zoomed out initially during page load, before zooming back in. To fix this, we add some sanity checks to these viewport scaling heuristics. In ViewportConfiguration's initialScaleFromSize method, in the codepath where an initial scale is not specified, we always scale to fit the contents of the page; instead, detect the case where the content width is enormous (with a threshold arbitrarily chosen to be 1920) and fall back to the scaling to fit the viewport's width, if such a width has been explicitly set. This ensures that we avoid excessive shrinking in the case where content is extremely wide, but also that we do scale the viewport down to fit all the content in the case where the content isn't extremely wide (e.g. on daringfireball.com). See WebKit ChangeLog for more detail. Test: fast/viewport/ios/shrink-to-fit-large-content-width.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): 2019-09-27 Alan Coon Cherry-pick r250300. rdar://problem/55770718 Mixed content blocking is bypassed for WebSockets in Workers (159726) https://bugs.webkit.org/show_bug.cgi?id=159726 Patch by Kate Cheney on 2019-09-24 Reviewed by Brady Eidson. Source/WebCore: Tests: http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http.html http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https.html http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-https-with-embedded-http-with-embedded-https.https.html http/tests/websocket/tests/hybi/non-document-mixed-content-blocked.https.html * Modules/websockets/WebSocket.cpp: (WebCore::WebSocket::connect): * Modules/websockets/WorkerThreadableWebSocketChannel.cpp: (WebCore::WorkerThreadableWebSocketChannel::Bridge::connect): * loader/MixedContentChecker.cpp: (WebCore::MixedContentChecker::checkForMixedContentInFrameTree): * loader/MixedContentChecker.h: Patch to block insecure WebSocket URL connection attempts by Workers on secure pages. If the URL is ws, and any embedding iframe has protocol https, and the context is a Worker, the connection should be blocked. I was unable to write a test case to hit the case where a document does not have a frame and tries to communicate via a worker to connect to a WebSocket because after removing the subframe from its parent, the subframe is unable to perform a postMessage to a worker even in the same script execution to tell the worker to connect to a WebSocket. LayoutTests: Added 4 test cases and 2 html resources utilized by the tests. The cases test the following: 1. an https page with a worker trying to connect via ws: url --> fails. 2. an https page embedded in an http page trying to connect via ws :url (through a worker) --> fails. 3. an http page embedded in an https page with an http top frame trying to connect via an insecure ws url fails. 4. an https page embedded in an http page embedded in an https page trying to connect to a ws :url via a worker --> fails. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-expected.txt: Added. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http-expected.txt: Added. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http.html: Added. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https.html: Added. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-https-with-embedded-http-with-embedded-https.https-expected.txt: Added. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-https-with-embedded-http-with-embedded-https.https.html: Added. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked.https-expected.txt: Added. * http/tests/websocket/tests/hybi/non-document-mixed-content-blocked.https.html: Added. * http/tests/websocket/tests/hybi/resources/non-document-mixed-content-blocked-embedded-http.https.html: Added. * http/tests/websocket/tests/hybi/resources/non-document-mixed-content-blocked-embedding-https.js: Added. (handleConnect.self.postMessage): (handleConnect): (runTests.ws.onopen): (runTests.ws.onerror): (runTests): * http/tests/websocket/tests/hybi/resources/non-document-mixed-content-blocked.html: Added. * http/tests/websocket/tests/hybi/resources/non-document-mixed-content-blocked.js: Added. (handleConnect.self.postMessage): (handleConnect): (runTests.ws.onopen): (runTests.ws.onerror): (runTests): * http/tests/workers/service/resources/serviceworker-websocket-worker.js: (async.doTest): Updated previous test which was hitting the fix to use a wss url git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250300 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-24 Kate Cheney Mixed content blocking is bypassed for WebSockets in Workers (159726) https://bugs.webkit.org/show_bug.cgi?id=159726 Reviewed by Brady Eidson. Tests: http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http.html http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https.html http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-https-with-embedded-http-with-embedded-https.https.html http/tests/websocket/tests/hybi/non-document-mixed-content-blocked.https.html * Modules/websockets/WebSocket.cpp: (WebCore::WebSocket::connect): * Modules/websockets/WorkerThreadableWebSocketChannel.cpp: (WebCore::WorkerThreadableWebSocketChannel::Bridge::connect): * loader/MixedContentChecker.cpp: (WebCore::MixedContentChecker::checkForMixedContentInFrameTree): * loader/MixedContentChecker.h: Patch to block insecure WebSocket URL connection attempts by Workers on secure pages. If the URL is ws, and any embedding iframe has protocol https, and the context is a Worker, the connection should be blocked. I was unable to write a test case to hit the case where a document does not have a frame and tries to communicate via a worker to connect to a WebSocket because after removing the subframe from its parent, the subframe is unable to perform a postMessage to a worker even in the same script execution to tell the worker to connect to a WebSocket. 2019-09-27 Alan Coon Cherry-pick r250290. rdar://problem/55770704 AudioTrackPrivateMediaStreamCocoa does not need to manipulate the audio unit in play/pause methods https://bugs.webkit.org/show_bug.cgi?id=202097 Reviewed by Eric Carlson. Instead of manipulating the audio unit in play/pause methods, it is more convenient to do so in audioSamplesAvailable. play/pause methods only update boolean values that audioSamplesAvailable will read. In particular, m_autoPlay and m_isPlaying are no longer modified in the audio thread. Behavior was racy so difficult to reproduce. * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.cpp: (WebCore::AudioTrackPrivateMediaStreamCocoa::playInternal): (WebCore::AudioTrackPrivateMediaStreamCocoa::pause): (WebCore::AudioTrackPrivateMediaStreamCocoa::audioSamplesAvailable): * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250290 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-24 Youenn Fablet AudioTrackPrivateMediaStreamCocoa does not need to manipulate the audio unit in play/pause methods https://bugs.webkit.org/show_bug.cgi?id=202097 Reviewed by Eric Carlson. Instead of manipulating the audio unit in play/pause methods, it is more convenient to do so in audioSamplesAvailable. play/pause methods only update boolean values that audioSamplesAvailable will read. In particular, m_autoPlay and m_isPlaying are no longer modified in the audio thread. Behavior was racy so difficult to reproduce. * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.cpp: (WebCore::AudioTrackPrivateMediaStreamCocoa::playInternal): (WebCore::AudioTrackPrivateMediaStreamCocoa::pause): (WebCore::AudioTrackPrivateMediaStreamCocoa::audioSamplesAvailable): * platform/mediastream/mac/AudioTrackPrivateMediaStreamCocoa.h: 2019-09-24 Kocsen Chung Cherry-pick r250256. rdar://problem/55644660 [iOS] Drop animation when dragging images from Photos to WebKit2 Mail compose is incorrect https://bugs.webkit.org/show_bug.cgi?id=201674 Reviewed by Tim Horton. Source/WebCore: Adds new helper methods on DragController to support the new image placeholder drop codepath. See WebKit ChangeLog for more details. Tests: WKAttachmentTestsIOS.TargetedPreviewsWhenDroppingImages WKAttachmentTestsIOS.TargetedPreviewIsClippedWhenDroppingTallImage * editing/WebContentReader.h: Fix the Windows build after including WebContentReader.h in DragController.cpp. * html/HTMLImageElement.h: (WebCore::HTMLImageElement::isDroppedImagePlaceholder const): (WebCore::HTMLImageElement::setIsDroppedImagePlaceholder): Add a flag to HTMLImageElement, indicating whether it is a dropped image placeholder. If so, we have special logic to remove some temporary inline style properties from the image after it has finished loading (see finalizeDroppedImagePlaceholder). Note that this doesn't increase the size of HTMLImageElement. * page/DragController.cpp: (WebCore::DragController::dragEnded): Clean up any stale placeholders after the drag ends. (WebCore::DragController::performDragOperation): (WebCore::DragController::removeAllDroppedImagePlaceholders): Add a private helper to clean up any dropped image placeholders after failing to update dropped image placeholders for any reason. (WebCore::DragController::tryToUpdateDroppedImagePlaceholders): Invoked when performing the drag operation, after image data has been loaded; this function attempts to update the list of image placeholder elements tracked by DragController that were previously inserted using insertDroppedImagePlaceholdersAtCaret, and updates the source attribute of each element (as well as any backed attachment element, if attachment elements are enabled). It achieves this by reading the dropped data as web content, and matching up the images in the resulting fragment against the placeholder images. If each image in the fragment can correspond to exactly one placeholder, we update the source of each placeholder image, migrate attachment elements over to the placeholder images if needed, and finally discard the fragment. A return value of false indicates that this process failed, in which case we clean up the placeholders and fall back to handling the drop normally. (WebCore::DragController::insertDroppedImagePlaceholdersAtCaret): Invoked when handling the drop, before any image data has been loaded; this function takes a list of sizes representing the preferred presentation sizes of each item provider that will be loaded as an image, and uses ReplaceSelectionCommand to insert a list of (initially blank) placeholder images at the drop caret, sized accordingly to each item provider's preferredPresentationSize. To make this compatible with Mail compose (and all other known internal clients that use the _editable SPI), we additionally enforce a max-width of 100% on each image and preserve the aspect ratio of the image by adjusting the height if needed. (WebCore::DragController::finalizeDroppedImagePlaceholder): * page/DragController.h: Have DragController keep track of the list of dropped image placeholders (in DOM order), as well as the dropped image placeholder range. This information is used once item provider data arrives and the drag operation is being performed, to update the source of each dropped image placeholder. (WebCore::DragController::droppedImagePlaceholders const): (WebCore::DragController::droppedImagePlaceholderRange const): * platform/network/mac/UTIUtilities.h: Mark an existing helper function as WEBCORE_EXPORT. Source/WebKit: Our current logic for handling dropped content in editable elements on iOS works like this in the ideal case: (1) UIKit asks us for a targeted preview for each UIDragItem. We don't know (and can't determine this synchronously without blocking on the web process) so we simply retarget the preview to animate to the last known caret location. (2) Soonafter, UIKit hands us a drop preview update block, which may be used to retarget the drop preview once, as long as the drop animation is less than 90% complete. We stash these update blocks for now. (3) -dropInteraction:performDrop: is then called, and we start loading item provider data right away. (4) When the data has finished loading, we perform the drop in the web process. After any inserted images have finished loading, we take snapshots (of the dropped content as well as surrounding web content minus the dropped content), and deliver these images to the UI process via TextIndicatorData. (5) Upon receiving the TextIndicatorData sent in (4), we use the image data to create updated targeted drag previews, and use these to invoke the preview update blocks we stored earlier in (2). We also obscure the entire web view with a snapshot of the view minus any dropped content, such that the updated drop previews may animate into place without also showing the final content. (6) When the drop animation ends, we remove the unselected content snapshot view added in (5) simultaneously as the targeted previews disappear, revealing the actual dropped content on the page. The drop is now complete. However, note that the drag update block we invoke in (5) doesn't work if the drop animation is already more than 90% complete. Since the lifecycle of the drop animation is distinct from that of item provider loading, if the delay between (3) and (4) exceeds 90% of the total drop animation time, we'll fail to update the targeted previews, such that the user only sees the initial drag preview fly on top of the caret and disappear. While we typically win this race for data dragged from other WebKit apps, we almost always lose when dragging from Photos and end up with a janky drop animation. This is especially true for any images that aren't locally available, and need to be fetched from iCloud. An additional problem is that in step (5), we use the same final snapshot to update the drop preview of every item, since we don't have a snapshot for the fragment corresponding to each individual dropped item. To address these issues for Mail in the case where the user drops images with known sizes (i.e. -[NSItemProvider preferredPresentationSize] is specified), we introduce an alternate codepath for handling dropped images that performs the drop immediately upon receiving -dropInteraction:performDrop: in the UI process. Since the data has yet to arrive, we instead handle the drop by inserting placeholder image elements at the drag caret position, which initially have no source but are sized to fit their expected final image sizes. After doing so, we snapshot the page (minus the dropped content range, as usual) and deliver this snapshot to the UI process, along with the rects (in root view coordinates) of each placeholder image that was inserted. In the UI process, we then take this snapshot and obscure the content view with it, and also use each of the placeholder rects to provide an updated target for each drag preview, such that the drop previews now animate to their final locations on the page. When the data eventually arrives, we handle the drop by detecting the placeholder elements we inserted earlier, and using the dropped data to update the source attribute and attachment backing for each of these placeholder elements instead of attempting to insert new content. Note that this codepath is currently only enabled for SPI clients that set -[WKWebView _editable] to YES, since it involves us performing the editing action for the drop (thus changing the DOM) prior to the preventable drop event, and prior to us having any data at all. However, the drop event can't come before the editing action, since we need to have already loaded data from the item providers to expose it via the dataTransfer of the drop event. This contradiction means that this image placeholder hack is only for _editable SPI clients that, at the very least, will not require preventing default behavior when dropping only images with predetermined sizes. Covered by 2 new API tests. See comments below for more detail. * UIProcess/WebPageProxy.h: * UIProcess/ios/DragDropInteractionState.h: * UIProcess/ios/DragDropInteractionState.mm: (WebKit::DragDropInteractionState::setDefaultDropPreview): Add a way to keep track of default drop previews that we observed during each call to -dropInteraction:previewForDroppingItem:withDefault:. In the image placeholder drop scenario, we use these default drop previews later on to create retargeted drop previews after the placeholders have been inserted. (WebKit::DragDropInteractionState::defaultDropPreview const): (WebKit::DragDropInteractionState::deliverDelayedDropPreview): Add an alternate version of deliverDelayedDropPreview that is used when inserting image placeholders. Rather than use text indicator data of the final dropped content on the page, use the root-view-coordinate rects of each of the placeholder elements to reposition the default drop previews. There's additional logic here to handle the case where the final image is taller than the height of the unobscured content rect, in which case we clip the drop preview using UIDragPreviewParameter's visiblePath to prevent the drop preview from being shown outside of the bounds of the web view. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _deliverDelayedDropPreviewIfPossible:]): (sizesOfPlaceholderElementsToInsertWhenDroppingItems): Collects the list of expected image sizes for the dropped item providers, or an empty list in the case where any of the item providers may not be represented as inline images or do not have predetermined sizes. (-[WKContentView _handleDropByInsertingImagePlaceholders:session:]): If possible, handles the drop by inserting image placeholders instead of waiting for the data to finish loading before dropping. Returns whether or not we decided to proceed with the image placeholder drop. (-[WKContentView dropInteraction:performDrop:]): (-[WKContentView dropInteraction:item:willAnimateDropWithAnimator:]): Fixes a bug where the unselected content snapshot view could linger around on the web view forever after a drop where the data doesn't load in time for the drop to finish by keeping track of whether there is an actively animating drag item, and only applying the unselected content snapshot if so. (-[WKContentView dropInteraction:previewForDroppingItem:withDefault:]): Stash the default drop preview away here. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::insertDroppedImagePlaceholders): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::insertDroppedImagePlaceholders): See WebCore ChangeLog for more information. (WebKit::WebPage::didFinishLoadingImageForElement): If the image that finished loading is a dropped image placeholder, allow DragController to "finalize" it by stripping away some styles that were temporarily added. Tools: Add a couple of new API tests to exercise the new image placeholder drop codepath, in addition to testing infrastructure to simulate the timing of drop animation delegate calls. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm: (-[NSArray _attachmentWithName:]): (-[TestWKWebView allBoundingClientRects:]): Add some new API testing helper methods. (TestWebKitAPI::targetedImageDragPreview): (TestWebKitAPI::TEST): Add two new tests, to: (1) verify that images are dropped as attachment-backed placeholder image elements when the web view is editable and enables attachment elements, and (2) verify that when dropping an image taller than the web view, the bottom portion of the drop preview is clipped using the targeted preview parameter's visiblePath. * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: (-[NSItemProvider registerDataRepresentationForTypeIdentifier:withData:]): Deleted. * TestWebKitAPI/cocoa/DragAndDropSimulator.h: * TestWebKitAPI/cocoa/NSItemProviderAdditions.h: Added. * TestWebKitAPI/cocoa/NSItemProviderAdditions.mm: Added. Move some common helpers for registering data on a NSItemProvider to a separate file, so that it can be used in both WKAttachmentTests and DragAndDropTests. (-[NSItemProvider registerDataRepresentationForTypeIdentifier:withData:]): (-[NSItemProvider registerDataRepresentationForTypeIdentifier:withData:loadingDelay:]): * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm: (-[DragAndDropSimulator initWithWebView:]): (-[DragAndDropSimulator _concludeDropAndPerformOperationIfNecessary]): (-[DragAndDropSimulator clearExternalDragInformation]): (-[DragAndDropSimulator setExternalItemProviders:defaultDropPreviews:]): Add a new method to allow tests to specify both a list of externally dragged item providers, as well as default targeted previews for each of the corresponding items. These default previews are used when invoking the drop interaction delegate's preview generation methods. (-[DragAndDropSimulator addAnimations:]): Not implemented yet; for now, this simply asserts. (-[DragAndDropSimulator addCompletion:]): Queues a completion handler, which is invoked when the drop animation for each item completes. Depending on the value of DragAndDropSimulator's -dropAnimationTiming, this may occur either before or after handling the drop. By default, these will be invoked after the drop completes, which represents the common case where data can be loaded quickly relative to the drop animation. (-[DragAndDropSimulator _invokeDropAnimationCompletionBlocksAndConcludeDrop]): (-[DragAndDropSimulator _webView:dataInteractionOperationWasHandled:forSession:itemProviders:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250256 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-23 Wenson Hsieh [iOS] Drop animation when dragging images from Photos to WebKit2 Mail compose is incorrect https://bugs.webkit.org/show_bug.cgi?id=201674 Reviewed by Tim Horton. Adds new helper methods on DragController to support the new image placeholder drop codepath. See WebKit ChangeLog for more details. Tests: WKAttachmentTestsIOS.TargetedPreviewsWhenDroppingImages WKAttachmentTestsIOS.TargetedPreviewIsClippedWhenDroppingTallImage * editing/WebContentReader.h: Fix the Windows build after including WebContentReader.h in DragController.cpp. * html/HTMLImageElement.h: (WebCore::HTMLImageElement::isDroppedImagePlaceholder const): (WebCore::HTMLImageElement::setIsDroppedImagePlaceholder): Add a flag to HTMLImageElement, indicating whether it is a dropped image placeholder. If so, we have special logic to remove some temporary inline style properties from the image after it has finished loading (see finalizeDroppedImagePlaceholder). Note that this doesn't increase the size of HTMLImageElement. * page/DragController.cpp: (WebCore::DragController::dragEnded): Clean up any stale placeholders after the drag ends. (WebCore::DragController::performDragOperation): (WebCore::DragController::removeAllDroppedImagePlaceholders): Add a private helper to clean up any dropped image placeholders after failing to update dropped image placeholders for any reason. (WebCore::DragController::tryToUpdateDroppedImagePlaceholders): Invoked when performing the drag operation, after image data has been loaded; this function attempts to update the list of image placeholder elements tracked by DragController that were previously inserted using insertDroppedImagePlaceholdersAtCaret, and updates the source attribute of each element (as well as any backed attachment element, if attachment elements are enabled). It achieves this by reading the dropped data as web content, and matching up the images in the resulting fragment against the placeholder images. If each image in the fragment can correspond to exactly one placeholder, we update the source of each placeholder image, migrate attachment elements over to the placeholder images if needed, and finally discard the fragment. A return value of false indicates that this process failed, in which case we clean up the placeholders and fall back to handling the drop normally. (WebCore::DragController::insertDroppedImagePlaceholdersAtCaret): Invoked when handling the drop, before any image data has been loaded; this function takes a list of sizes representing the preferred presentation sizes of each item provider that will be loaded as an image, and uses ReplaceSelectionCommand to insert a list of (initially blank) placeholder images at the drop caret, sized accordingly to each item provider's preferredPresentationSize. To make this compatible with Mail compose (and all other known internal clients that use the _editable SPI), we additionally enforce a max-width of 100% on each image and preserve the aspect ratio of the image by adjusting the height if needed. (WebCore::DragController::finalizeDroppedImagePlaceholder): * page/DragController.h: Have DragController keep track of the list of dropped image placeholders (in DOM order), as well as the dropped image placeholder range. This information is used once item provider data arrives and the drag operation is being performed, to update the source of each dropped image placeholder. (WebCore::DragController::droppedImagePlaceholders const): (WebCore::DragController::droppedImagePlaceholderRange const): * platform/network/mac/UTIUtilities.h: Mark an existing helper function as WEBCORE_EXPORT. 2019-09-23 Alan Coon Cherry-pick r250255. rdar://problem/55644665 Improve CSP inheritance semantics https://bugs.webkit.org/show_bug.cgi?id=201884 Reviewed by Brent Fulgham. LayoutTests/imported/w3c: Update expected results now that we pass more sub-tests. * web-platform-tests/content-security-policy/inheritance/iframe-all-local-schemes-inherit-self.sub-expected.txt: * web-platform-tests/content-security-policy/inheritance/window-expected.txt: Source/WebCore: Update the CSP inheritance semantics to more closely match the logic in section Initialize a Document's CSP list of the CSP3 spec., . Towards this, move more of the inheritance logic out of Document::initContentSecurityPolicy() and into DocumentWriter::begin() where details about the document being replaced live. This lets us remove the need to track the previous content security policy to pass it to Document::initContentSecurityPolicy(). Moreover, DocumentWriter::begin() knows the owner document that will be replaced with the result of executing a JavaScript URL. This is needed in order to fix up inheritance of CSP for such documents. Tests: http/tests/security/contentSecurityPolicy/iframe-allowed-when-loaded-via-javascript-url.html http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url.html http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url2.html * dom/Document.cpp: (WebCore::Document::initSecurityContext): If we are inheriting the security origin from the owner document then inherit its CSP policy. We copy over both the CSP state from the owner as well as update 'self' to match the owner's origin so that CSP source expressions that include 'self' work correctly even from about:blank documents. (WebCore::Document::initContentSecurityPolicy): Move most of the logic from here into DocumentWriter::begin() to take advantage of the fact that DocumentWriter::begin() knows about the outgoing document (if there is one) as well as whether the outgoing document is being replaced with a new document that is the result of evaluating a JavaScript URL. We need do know both these things in order to inherit the correct CSP policy. This function only exists to copy some upgrade-insecure-requests state and to fix up plugin documents as we currently do. (WebCore::Document::shouldInheritContentSecurityPolicy const): Deleted. * dom/Document.h: * dom/SecurityContext.cpp: (WebCore::SecurityContext::setContentSecurityPolicy): Modified to take its param by rvalue-reference to make it less error prone to use. * dom/SecurityContext.h: Expose setContentSecurityPolicy() so that we can invoke it from DocumentWriter::begin(). * loader/DocumentWriter.cpp: (WebCore::DocumentWriter::begin): For documents being replaced with the result of a JavaScript URL (i.e. ownerDocument is non-null) inherit the CSP from the owner document. Similarly, if we have an existing document in the frame and the protocol of the new document's URL is data: or blob: then inherit the CSP from the existing page. The latter is what we currently do just moved from Document::initContentSecurityPolicy() and re-written in terms of the existingDocument instead of previousContentSecurityPolicy. Also call setInsecureNavigationRequestsToUpgrade() both when we have a non-null ownerDocument as well as when we have a non-null existingDocument. The former fixes the block-all-mixed-content feature for documents loaded via JavaScript URLs and the latter is what we do now. * loader/FrameLoader.cpp: (WebCore::FrameLoader::didBeginDocument): Remove parameter previousContentSecurityPolicy as the logic that made use of it moved to DocumentWriter::begin(). * loader/FrameLoader.h: * page/csp/ContentSecurityPolicy.h: LayoutTests: Add some more tests and update expected results of existing tests now that we pass more sub-tests. * http/tests/security/contentSecurityPolicy/iframe-allowed-when-loaded-via-javascript-url-expected.txt: Added. * http/tests/security/contentSecurityPolicy/iframe-allowed-when-loaded-via-javascript-url.html: Added. * http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url-expected.txt: Added. * http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url.html: Added. * http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url2-expected.txt: Added. * http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url2.html: Added. * http/tests/security/contentSecurityPolicy/user-style-sheet-font-crasher-expected.txt: I don't understand why there is another duplicte console log message emitted, but there are already two such messages, which is already one too many. The duplicate messages are more cosmetic than functional though there may be implications with respect to CSP reporting. Filed to track this issue. * platform/mac-wk1/http/tests/security/contentSecurityPolicy/user-style-sheet-font-crasher-expected.txt: * platform/win/http/tests/security/contentSecurityPolicy/user-style-sheet-font-crasher-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250255 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-23 Daniel Bates Improve CSP inheritance semantics https://bugs.webkit.org/show_bug.cgi?id=201884 Reviewed by Brent Fulgham. Update the CSP inheritance semantics to more closely match the logic in section Initialize a Document's CSP list of the CSP3 spec., . Towards this, move more of the inheritance logic out of Document::initContentSecurityPolicy() and into DocumentWriter::begin() where details about the document being replaced live. This lets us remove the need to track the previous content security policy to pass it to Document::initContentSecurityPolicy(). Moreover, DocumentWriter::begin() knows the owner document that will be replaced with the result of executing a JavaScript URL. This is needed in order to fix up inheritance of CSP for such documents. Tests: http/tests/security/contentSecurityPolicy/iframe-allowed-when-loaded-via-javascript-url.html http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url.html http/tests/security/contentSecurityPolicy/iframe-blocked-when-loaded-via-javascript-url2.html * dom/Document.cpp: (WebCore::Document::initSecurityContext): If we are inheriting the security origin from the owner document then inherit its CSP policy. We copy over both the CSP state from the owner as well as update 'self' to match the owner's origin so that CSP source expressions that include 'self' work correctly even from about:blank documents. (WebCore::Document::initContentSecurityPolicy): Move most of the logic from here into DocumentWriter::begin() to take advantage of the fact that DocumentWriter::begin() knows about the outgoing document (if there is one) as well as whether the outgoing document is being replaced with a new document that is the result of evaluating a JavaScript URL. We need do know both these things in order to inherit the correct CSP policy. This function only exists to copy some upgrade-insecure-requests state and to fix up plugin documents as we currently do. (WebCore::Document::shouldInheritContentSecurityPolicy const): Deleted. * dom/Document.h: * dom/SecurityContext.cpp: (WebCore::SecurityContext::setContentSecurityPolicy): Modified to take its param by rvalue-reference to make it less error prone to use. * dom/SecurityContext.h: Expose setContentSecurityPolicy() so that we can invoke it from DocumentWriter::begin(). * loader/DocumentWriter.cpp: (WebCore::DocumentWriter::begin): For documents being replaced with the result of a JavaScript URL (i.e. ownerDocument is non-null) inherit the CSP from the owner document. Similarly, if we have an existing document in the frame and the protocol of the new document's URL is data: or blob: then inherit the CSP from the existing page. The latter is what we currently do just moved from Document::initContentSecurityPolicy() and re-written in terms of the existingDocument instead of previousContentSecurityPolicy. Also call setInsecureNavigationRequestsToUpgrade() both when we have a non-null ownerDocument as well as when we have a non-null existingDocument. The former fixes the block-all-mixed-content feature for documents loaded via JavaScript URLs and the latter is what we do now. * loader/FrameLoader.cpp: (WebCore::FrameLoader::didBeginDocument): Remove parameter previousContentSecurityPolicy as the logic that made use of it moved to DocumentWriter::begin(). * loader/FrameLoader.h: * page/csp/ContentSecurityPolicy.h: 2019-09-23 Alan Coon Cherry-pick r250182. rdar://problem/55608034 releasePointerCapture() not working for implicit capture; can't opt-in to pointerenter/leave for touches https://bugs.webkit.org/show_bug.cgi?id=199803 Reviewed by Dean Jackson. Source/WebCore: In order to dispatch boundary events (pointerover/out/enter/leave) when the implicit pointer capture is released on iOS, we need to track the target of the pointer events that was dispatched last for a given pointer id. Then we compare that target with the current target when dispatching a new pointer event and determine whether we should dispatch boundary events using the exact same approach used to dispatch mouse boundary events in EventHandler::updateMouseEventTargetNode(). Tests: pointerevents/ios/boundary-events-through-hierarchy-without-pointer-capture.html pointerevents/ios/boundary-events-without-pointer-capture.html * page/PointerCaptureController.cpp: (WebCore::hierarchyHasCapturingEventListeners): (WebCore::PointerCaptureController::dispatchEventForTouchAtIndex): (WebCore::PointerCaptureController::pointerEventWillBeDispatched): (WebCore::PointerCaptureController::ensureCapturingDataForPointerEvent): (WebCore::PointerCaptureController::cancelPointer): * page/PointerCaptureController.h: LayoutTests: Add new tests that check we correctly dispatch boundary events on iOS when pointer capture is disabled. * pointerevents/ios/boundary-events-through-hierarchy-without-pointer-capture-expected.txt: Added. * pointerevents/ios/boundary-events-through-hierarchy-without-pointer-capture.html: Added. * pointerevents/ios/boundary-events-without-pointer-capture-expected.txt: Added. * pointerevents/ios/boundary-events-without-pointer-capture.html: Added. * pointerevents/utils.js: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250182 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-20 Antoine Quint releasePointerCapture() not working for implicit capture; can't opt-in to pointerenter/leave for touches https://bugs.webkit.org/show_bug.cgi?id=199803 Reviewed by Dean Jackson. In order to dispatch boundary events (pointerover/out/enter/leave) when the implicit pointer capture is released on iOS, we need to track the target of the pointer events that was dispatched last for a given pointer id. Then we compare that target with the current target when dispatching a new pointer event and determine whether we should dispatch boundary events using the exact same approach used to dispatch mouse boundary events in EventHandler::updateMouseEventTargetNode(). Tests: pointerevents/ios/boundary-events-through-hierarchy-without-pointer-capture.html pointerevents/ios/boundary-events-without-pointer-capture.html * page/PointerCaptureController.cpp: (WebCore::hierarchyHasCapturingEventListeners): (WebCore::PointerCaptureController::dispatchEventForTouchAtIndex): (WebCore::PointerCaptureController::pointerEventWillBeDispatched): (WebCore::PointerCaptureController::ensureCapturingDataForPointerEvent): (WebCore::PointerCaptureController::cancelPointer): * page/PointerCaptureController.h: 2019-09-23 Alan Coon Apply patch. rdar://problem/55608031 Clean up handling of summary items and payment method updates https://bugs.webkit.org/show_bug.cgi?id=202018 Reviewed by Tim Horton. Source/WebCore: Replaced the PaymentMethodUpdate struct with a class that knows how to convert from ApplePayPaymentMethodUpdate structs to PKPaymentRequestPaymentMethodUpdate instances. Moved some scattered-around free functions for converting payment summary items into PaymentSummaryItems{.h,Cocoa.mm}. * Modules/applepay/ApplePayPaymentMethodUpdate.h: * Modules/applepay/ApplePaySession.cpp: (WebCore::finishConverting): (WebCore::convertAndValidateTotal): (WebCore::convertAndValidate): * Modules/applepay/ApplePaySessionPaymentRequest.h: * Modules/applepay/PaymentCoordinator.h: * Modules/applepay/PaymentCoordinatorClient.h: * Modules/applepay/PaymentHeaders.h: * Modules/applepay/PaymentMethodUpdate.h: Added. * Modules/applepay/PaymentSummaryItems.h: Added. * Modules/applepay/cocoa/PaymentMethodUpdateCocoa.mm: Added. (WebCore::PaymentMethodUpdate::PaymentMethodUpdate): (WebCore::PaymentMethodUpdate::totalAndLineItems const): (WebCore::PaymentMethodUpdate::platformUpdate const): * Modules/applepay/cocoa/PaymentSummaryItemsCocoa.mm: Added. (WebCore::toDecimalNumber): (WebCore::toPKPaymentSummaryItemType): (WebCore::toPKPaymentSummaryItem): (WebCore::platformSummaryItems): * Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp: (WebCore::ApplePayPaymentHandler::paymentMethodUpdated): * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * testing/MockPaymentCoordinator.cpp: (WebCore::MockPaymentCoordinator::completePaymentMethodSelection): Source/WebKit: Now that PaymentMethodUpdate knows how to convert itself to a PKPaymentRequestPaymentMethodUpdate, PaymentAuthorizationPresenter can merely pass the converted update directly to the platform delegate rather than passing the individual components and relying on the delegate to instantiate the platform update itself. Added FIXMEs for applying a similar treatment to ShippingContactUpdate and ShippingMethodUpdate. * Platform/cocoa/PaymentAuthorizationPresenter.h: * Platform/cocoa/PaymentAuthorizationPresenter.mm: (WebKit::PaymentAuthorizationPresenter::completePaymentMethodSelection): (WebKit::PaymentAuthorizationPresenter::completeShippingContactSelection): (WebKit::PaymentAuthorizationPresenter::completeShippingMethodSelection): * Platform/cocoa/WKPaymentAuthorizationDelegate.h: * Platform/cocoa/WKPaymentAuthorizationDelegate.mm: (-[WKPaymentAuthorizationDelegate completePaymentMethodSelection:]): (-[WKPaymentAuthorizationDelegate completeShippingContactSelection:]): (-[WKPaymentAuthorizationDelegate completeShippingMethodSelection:]): (-[WKPaymentAuthorizationDelegate _didSelectPaymentMethod:completion:]): (-[WKPaymentAuthorizationDelegate _didSelectShippingContact:completion:]): (-[WKPaymentAuthorizationDelegate _didSelectShippingMethod:completion:]): (-[WKPaymentAuthorizationDelegate completeShippingContactSelection:summaryItems:shippingMethods:errors:]): Deleted. * Shared/ApplePay/WebPaymentCoordinatorProxy.h: * Shared/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.h: * Shared/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.mm: (WebKit::WebPaymentCoordinatorProxy::platformPaymentRequest): (WebKit::toPKPaymentSummaryItemType): Deleted. (WebKit::toPKPaymentSummaryItem): Deleted. (WebKit::toPKPaymentSummaryItems): Deleted. * Shared/Cocoa/WebCoreArgumentCodersCocoa.mm: (IPC::ArgumentCoder::encode): (IPC::ArgumentCoder::decode): 2019-09-19 Andy Estes [Apple Pay] Clean up handling of summary items and payment method updates https://bugs.webkit.org/show_bug.cgi?id=202018 Reviewed by Tim Horton. Replaced the PaymentMethodUpdate struct with a class that knows how to convert from ApplePayPaymentMethodUpdate structs to PKPaymentRequestPaymentMethodUpdate instances. Moved some scattered-around free functions for converting payment summary items into PaymentSummaryItems{.h,Cocoa.mm}. * Modules/applepay/ApplePayPaymentMethodUpdate.h: * Modules/applepay/ApplePaySession.cpp: (WebCore::finishConverting): (WebCore::convertAndValidateTotal): (WebCore::convertAndValidate): * Modules/applepay/ApplePaySessionPaymentRequest.h: * Modules/applepay/PaymentCoordinator.h: * Modules/applepay/PaymentCoordinatorClient.h: * Modules/applepay/PaymentHeaders.h: * Modules/applepay/PaymentMethodUpdate.h: Added. * Modules/applepay/PaymentSummaryItems.h: Added. * Modules/applepay/cocoa/PaymentMethodUpdateCocoa.mm: Added. (WebCore::PaymentMethodUpdate::PaymentMethodUpdate): (WebCore::PaymentMethodUpdate::totalAndLineItems const): (WebCore::PaymentMethodUpdate::platformUpdate const): * Modules/applepay/cocoa/PaymentSummaryItemsCocoa.mm: Added. (WebCore::toDecimalNumber): (WebCore::toPKPaymentSummaryItemType): (WebCore::toPKPaymentSummaryItem): (WebCore::platformSummaryItems): * Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp: (WebCore::ApplePayPaymentHandler::paymentMethodUpdated): * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * testing/MockPaymentCoordinator.cpp: (WebCore::MockPaymentCoordinator::completePaymentMethodSelection): 2019-09-23 Alan Coon Apply patch. rdar://problem/55608028 Tell websites why a session was cancelled https://bugs.webkit.org/show_bug.cgi?id=201912 Source/WebCore: Reviewed by Brady Eidson. Added ApplePayCancelEvent as the interface for ApplePaySession's cancel event. This event object includes a `sessionError` attribute that exposes a Web-safe version of the PassKit domain error we received from PKPaymentAuthorization(View)Controller. Currently, we report all errors with code "unknown", but more codes will be added in future patches. Test: http/tests/ssl/applepay/ApplePayCancelEvent.https.html * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * Modules/applepay/ApplePayCancelEvent.cpp: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. (WebCore::ApplePayCancelEvent::ApplePayCancelEvent): (WebCore::ApplePayCancelEvent::sessionError const): (WebCore::ApplePayCancelEvent::eventInterface const): * Modules/applepay/ApplePayCancelEvent.h: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. (WebCore::ApplePayCancelEvent::create): * Modules/applepay/ApplePayCancelEvent.idl: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/ApplePaySession.cpp: (WebCore::ApplePaySession::didCancelPaymentSession): * Modules/applepay/ApplePaySession.h: * Modules/applepay/ApplePaySessionError.h: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/ApplePaySessionError.idl: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/PaymentCoordinator.cpp: (WebCore::PaymentCoordinator::didCancelPaymentSession): * Modules/applepay/PaymentCoordinator.h: * Modules/applepay/PaymentHeaders.h: * Modules/applepay/PaymentSession.cpp: * Modules/applepay/PaymentSession.h: * Modules/applepay/PaymentSessionError.h: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/cocoa/PaymentSessionErrorCocoa.mm: Copied from Source/WebCore/Modules/applepay/PaymentSession.h. (WebCore::additionalError): (WebCore::PaymentSessionError::PaymentSessionError): (WebCore::PaymentSessionError::sessionError const): (WebCore::PaymentSessionError::platformError const): (WebCore::PaymentSessionError::unknownError const): * Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp: (WebCore::ApplePayPaymentHandler::didCancelPaymentSession): * Modules/applepay/paymentrequest/ApplePayPaymentHandler.h: * Modules/webgpu/WHLSL/WHLSLCheckTextureReferences.cpp: * Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp: * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * dom/EventNames.in: * testing/MockPaymentCoordinator.cpp: (WebCore::MockPaymentCoordinator::cancelPayment): Source/WebCore/PAL: Reviewed by Brady Eidson. Soft-linked PKPassKitErrorDomain and included PassKit headers more judiciously. * pal/cocoa/PassKitSoftLink.h: * pal/cocoa/PassKitSoftLink.mm: * pal/spi/cocoa/PassKitSPI.h: Source/WebKit: Reviewed by Brady Eidson. Remembered the error passed to -[WKPaymentAuthorizationDelegate _willFinishWithError:] and sent it to the WebContent process in Messages::WebPaymentCoordinator::DidCancelPaymentSession. * Platform/cocoa/PaymentAuthorizationPresenter.h: * Platform/cocoa/WKPaymentAuthorizationDelegate.mm: (-[WKPaymentAuthorizationDelegate _didFinish]): (-[WKPaymentAuthorizationDelegate _willFinishWithError:]): * Shared/ApplePay/WebPaymentCoordinatorProxy.cpp: (WebKit::WebPaymentCoordinatorProxy::didCancelPaymentSession): (WebKit::WebPaymentCoordinatorProxy::presenterDidFinish): * Shared/ApplePay/WebPaymentCoordinatorProxy.h: (WebKit::WebPaymentCoordinatorProxy::didCancelPaymentSession): * Shared/ApplePay/ios/WebPaymentCoordinatorProxyIOS.mm: * Shared/Cocoa/WebCoreArgumentCodersCocoa.mm: (IPC::ArgumentCoder::encode): (IPC::ArgumentCoder::decode): * Shared/WebCoreArgumentCoders.h: * WebProcess/ApplePay/WebPaymentCoordinator.cpp: (WebKit::WebPaymentCoordinator::networkProcessConnectionClosed): (WebKit::WebPaymentCoordinator::didCancelPaymentSession): * WebProcess/ApplePay/WebPaymentCoordinator.h: * WebProcess/ApplePay/WebPaymentCoordinator.messages.in: LayoutTests: Reviewed by Brady Eidson. * http/tests/ssl/applepay/ApplePayCancelEvent.https-expected.txt: Added. * http/tests/ssl/applepay/ApplePayCancelEvent.https.html: Added. 2019-09-18 Andy Estes [Apple Pay] Tell websites why a session was cancelled https://bugs.webkit.org/show_bug.cgi?id=201912 Reviewed by Brady Eidson. Added ApplePayCancelEvent as the interface for ApplePaySession's cancel event. This event object includes a `sessionError` attribute that exposes a Web-safe version of the PassKit domain error we received from PKPaymentAuthorization(View)Controller. Currently, we report all errors with code "unknown", but more codes will be added in future patches. Test: http/tests/ssl/applepay/ApplePayCancelEvent.https.html * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * Modules/applepay/ApplePayCancelEvent.cpp: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. (WebCore::ApplePayCancelEvent::ApplePayCancelEvent): (WebCore::ApplePayCancelEvent::sessionError const): (WebCore::ApplePayCancelEvent::eventInterface const): * Modules/applepay/ApplePayCancelEvent.h: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. (WebCore::ApplePayCancelEvent::create): * Modules/applepay/ApplePayCancelEvent.idl: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/ApplePaySession.cpp: (WebCore::ApplePaySession::didCancelPaymentSession): * Modules/applepay/ApplePaySession.h: * Modules/applepay/ApplePaySessionError.h: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/ApplePaySessionError.idl: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/PaymentCoordinator.cpp: (WebCore::PaymentCoordinator::didCancelPaymentSession): * Modules/applepay/PaymentCoordinator.h: * Modules/applepay/PaymentHeaders.h: * Modules/applepay/PaymentSession.cpp: * Modules/applepay/PaymentSession.h: * Modules/applepay/PaymentSessionError.h: Copied from Source/WebCore/Modules/applepay/PaymentHeaders.h. * Modules/applepay/cocoa/PaymentSessionErrorCocoa.mm: Copied from Source/WebCore/Modules/applepay/PaymentSession.h. (WebCore::additionalError): (WebCore::PaymentSessionError::PaymentSessionError): (WebCore::PaymentSessionError::sessionError const): (WebCore::PaymentSessionError::platformError const): (WebCore::PaymentSessionError::unknownError const): * Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp: (WebCore::ApplePayPaymentHandler::didCancelPaymentSession): * Modules/applepay/paymentrequest/ApplePayPaymentHandler.h: * Modules/webgpu/WHLSL/WHLSLCheckTextureReferences.cpp: * Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp: * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * dom/EventNames.in: * testing/MockPaymentCoordinator.cpp: (WebCore::MockPaymentCoordinator::cancelPayment): 2019-09-23 Alan Coon Cherry-pick r250026. rdar://problem/55608017 [Cocoa] Add a WKA extension point https://bugs.webkit.org/show_bug.cgi?id=201801 Reviewed by Alexey Proskuryakov. * Modules/applepay/ApplePayRequestBase.cpp: (WebCore::requiresSupportedNetworks): (WebCore::convertAndValidate): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250026 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-18 Andy Estes [Cocoa] Add a WKA extension point https://bugs.webkit.org/show_bug.cgi?id=201801 Reviewed by Alexey Proskuryakov. * Modules/applepay/ApplePayRequestBase.cpp: (WebCore::requiresSupportedNetworks): (WebCore::convertAndValidate): 2019-09-17 Alan Coon Cherry-pick r249954. rdar://problem/55461404 [First-letter] Use WeakPtr for the first-letter insertion point. https://bugs.webkit.org/show_bug.cgi?id=201842 Reviewed by Antti Koivisto. Source/WebCore: The about-to-be-removed first letter renderer's sibling could potentially be destroyed too as the result of the anonymous subtree collapsing logic (when the next sibling is a generated anonymous block and it is not needed anymore.) Test: fast/text/first-letter-with-columns-crash.html * rendering/updating/RenderTreeBuilderFirstLetter.cpp: (WebCore::RenderTreeBuilder::FirstLetter::updateStyle): LayoutTests: * fast/text/first-letter-with-columns-crash-expected.txt: Added. * fast/text/first-letter-with-columns-crash.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249954 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-17 Zalan Bujtas [First-letter] Use WeakPtr for the first-letter insertion point. https://bugs.webkit.org/show_bug.cgi?id=201842 Reviewed by Antti Koivisto. The about-to-be-removed first letter renderer's sibling could potentially be destroyed too as the result of the anonymous subtree collapsing logic (when the next sibling is a generated anonymous block and it is not needed anymore.) Test: fast/text/first-letter-with-columns-crash.html * rendering/updating/RenderTreeBuilderFirstLetter.cpp: (WebCore::RenderTreeBuilder::FirstLetter::updateStyle): 2019-09-17 Alan Coon Cherry-pick r249888. rdar://problem/55461403 [WebIDL] Derived dictionaries should inherit their inherited dictionaries' partials https://bugs.webkit.org/show_bug.cgi?id=201802 Reviewed by Sam Weinig. Prior to this change, a dictionary D that inherits from dictionary B would not inherit B's partial dictionaries. Fixed this by moving supplemental dependencies processing from generate-bindings.pl to CodeGenerator.pm and reusing it in GetDictionaryByType. Added new bindings tests. * bindings/scripts/CodeGenerator.pm: (new): (ProcessDocument): (ProcessSupplementalDependencies): (shouldPropertyBeExposed): (GetDictionaryByType): * bindings/scripts/generate-bindings.pl: (generateBindings): (shouldPropertyBeExposed): Deleted. * bindings/scripts/test/JS/JSTestDerivedDictionary.cpp: Added. (WebCore::convertDictionary): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestDerivedDictionary.h: Added. * bindings/scripts/test/JS/JSTestInheritedDictionary.cpp: Added. (WebCore::convertDictionary): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestInheritedDictionary.h: Added. * bindings/scripts/test/TestDerivedDictionary.idl: Added. * bindings/scripts/test/TestInheritedDictionary.idl: Added. * bindings/scripts/test/TestSupplemental.idl: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249888 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-15 Andy Estes [WebIDL] Derived dictionaries should inherit their inherited dictionaries' partials https://bugs.webkit.org/show_bug.cgi?id=201802 Reviewed by Sam Weinig. Prior to this change, a dictionary D that inherits from dictionary B would not inherit B's partial dictionaries. Fixed this by moving supplemental dependencies processing from generate-bindings.pl to CodeGenerator.pm and reusing it in GetDictionaryByType. Added new bindings tests. * bindings/scripts/CodeGenerator.pm: (new): (ProcessDocument): (ProcessSupplementalDependencies): (shouldPropertyBeExposed): (GetDictionaryByType): * bindings/scripts/generate-bindings.pl: (generateBindings): (shouldPropertyBeExposed): Deleted. * bindings/scripts/test/JS/JSTestDerivedDictionary.cpp: Added. (WebCore::convertDictionary): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestDerivedDictionary.h: Added. * bindings/scripts/test/JS/JSTestInheritedDictionary.cpp: Added. (WebCore::convertDictionary): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestInheritedDictionary.h: Added. * bindings/scripts/test/TestDerivedDictionary.idl: Added. * bindings/scripts/test/TestInheritedDictionary.idl: Added. * bindings/scripts/test/TestSupplemental.idl: 2019-09-17 Alan Coon Cherry-pick r247573. rdar://problem/55461395 [Pointer Events] The button and buttons properties are incorrect on iOS https://bugs.webkit.org/show_bug.cgi?id=199910 Reviewed by Dean Jackson. Source/WebCore: The button and buttons properties were always set to 0 on iOS. We now use the correct values such that button is always 0 except for "pointermove" where it's -1, and "buttons" is 1 as long as the pointer is in contact with the touch surface. Tests: pointerevents/ios/pointer-event-button-and-buttons-pointer-cancel.html pointerevents/ios/pointer-event-button-and-buttons.html * dom/ios/PointerEventIOS.cpp: (WebCore::buttonForType): (WebCore::buttonsForType): (WebCore::PointerEvent::PointerEvent): LayoutTests: * pointerevents/ios/pointer-event-button-and-buttons-expected.txt: Added. * pointerevents/ios/pointer-event-button-and-buttons-pointer-cancel-expected.txt: Added. * pointerevents/ios/pointer-event-button-and-buttons-pointer-cancel.html: Added. * pointerevents/ios/pointer-event-button-and-buttons.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247573 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-18 Antoine Quint [Pointer Events] The button and buttons properties are incorrect on iOS https://bugs.webkit.org/show_bug.cgi?id=199910 Reviewed by Dean Jackson. The button and buttons properties were always set to 0 on iOS. We now use the correct values such that button is always 0 except for "pointermove" where it's -1, and "buttons" is 1 as long as the pointer is in contact with the touch surface. Tests: pointerevents/ios/pointer-event-button-and-buttons-pointer-cancel.html pointerevents/ios/pointer-event-button-and-buttons.html * dom/ios/PointerEventIOS.cpp: (WebCore::buttonForType): (WebCore::buttonsForType): (WebCore::PointerEvent::PointerEvent): 2019-09-17 Alan Coon Apply patch. rdar://problem/55240888 2019-09-17 Chris Dumez Nullptr crash in Page::sessionID() via WebKit::WebFrameLoaderClient::detachedFromParent2() https://bugs.webkit.org/show_bug.cgi?id=201625 Reviewed by Ryosuke Niwa. This is based on a patch from Ryosuke Niwa. Drop setHasFrameSpecificStorageAccess() in WebCore and call it from the WebKit layer instead. * dom/DocumentStorageAccess.cpp: (WebCore::DocumentStorageAccess::requestStorageAccess): (WebCore::DocumentStorageAccess::setHasFrameSpecificStorageAccess): Deleted. * dom/DocumentStorageAccess.h: * loader/EmptyFrameLoaderClient.h: * loader/FrameLoaderClient.h: 2019-09-17 Alan Coon Revert r249748. rdar://problem/55240888 2019-09-17 Kocsen Chung Cherry-pick r249815. rdar://problem/55427483 REGRESSION (iOS 13): Top fixed element on apple.com flickers in size while pinching in https://bugs.webkit.org/show_bug.cgi?id=201668 rdar://problem/51934041 Reviewed by Frédéric Wang. Source/WebCore: When computing the new layout viewport rect in ScrollingTreeFrameScrollingNode, use "StickToDocumentBounds" mode, not "StickToViewportBounds", because otherwise we'll compute a layout viewport that has negative top/left offsets which causes fixed elements to jump outside the viewport. The only code that should be moving things outside the viewport (a temporary effect that happens when pinching) is the 'isBelowMinimumScale' path in WebPageProxy::computeCustomFixedPositionRect(). With this change ScrollingTreeFrameScrollingNode no longer needs m_behaviorForFixed; it can be removed later. Not currently testable, since it involves pinching in past minimum zoom and transients state. * page/scrolling/ScrollingTreeFrameScrollingNode.cpp: (WebCore::ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition const): Source/WebKit: The UI process can have transient state that pushes scrolling-tree-managed layers into custom locations while pinch-zooming. We have to apply this state both when the visible rects in the UI process change (existing code in -[WKContentView didUpdateVisibleRect:...]) and when we get new layers from the web process (added in RemoteLayerTreeDrawingAreaProxy::commitLayerTree() in this patch). Move some code into WebPageProxy to create functions that we can call from both places. For manual testing, visit a page with fixed banners, pinch in slightly, then pinch out and, while keeping your fingers down, move the contents around. * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * UIProcess/WebPageProxy.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView didUpdateVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::unconstrainedLayoutViewportRect const): (WebKit::WebPageProxy::adjustLayersForLayoutViewport): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249815 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-17 Kocsen Chung Cherry-pick r249813. rdar://problem/55427490 [Cocoa] Text indicator for an image link on the front page of apple.com looks wrong https://bugs.webkit.org/show_bug.cgi?id=201724 Reviewed by Tim Horton. Source/WebCore: When computing the bounds of the range (, 0) to (, 1) for a text indicator snapshot where is a link with a single non-breaking whitespace character, we currently use the text rect of the single space. This leads to a confusing text indicator, as the resulting snapshot is a tiny blank square in the top left corner of the link. This problem manifests when starting a drag or showing the system context menu on iOS, or force clicking or three-finger tapping to show a preview on macOS. To address this scenario, tweak the heuristic in the case where the text indicator option TextIndicatorOptionUseBoundingRectAndPaintAllContentForComplexRanges is specified, such that we consider a range containing only text with whitespaces to be "complex"; additionally, instead of falling back to the range's bounding rect (which in this case is still tiny), fall back to the common ancestor container's bounding rect, which encompasses not only the text inside the range but also the element containing the range (in this case, the anchor element). Test: fast/text-indicator/text-indicator-empty-link.html * page/TextIndicator.cpp: (WebCore::containsOnlyWhiteSpaceText): Add a helper to determine whether a Range is comprised only of rendered text that only contains whitespace characters. (WebCore::initializeIndicator): See ChangeLog entry above for more detail. LayoutTests: Add a new layout test to exercise this scenario. * fast/text-indicator/text-indicator-empty-link-expected.txt: Added. * fast/text-indicator/text-indicator-empty-link.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249813 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-12 Wenson Hsieh [Cocoa] Text indicator for an image link on the front page of apple.com looks wrong https://bugs.webkit.org/show_bug.cgi?id=201724 Reviewed by Tim Horton. When computing the bounds of the range (, 0) to (, 1) for a text indicator snapshot where is a link with a single non-breaking whitespace character, we currently use the text rect of the single space. This leads to a confusing text indicator, as the resulting snapshot is a tiny blank square in the top left corner of the link. This problem manifests when starting a drag or showing the system context menu on iOS, or force clicking or three-finger tapping to show a preview on macOS. To address this scenario, tweak the heuristic in the case where the text indicator option TextIndicatorOptionUseBoundingRectAndPaintAllContentForComplexRanges is specified, such that we consider a range containing only text with whitespaces to be "complex"; additionally, instead of falling back to the range's bounding rect (which in this case is still tiny), fall back to the common ancestor container's bounding rect, which encompasses not only the text inside the range but also the element containing the range (in this case, the anchor element). Test: fast/text-indicator/text-indicator-empty-link.html * page/TextIndicator.cpp: (WebCore::containsOnlyWhiteSpaceText): Add a helper to determine whether a Range is comprised only of rendered text that only contains whitespace characters. (WebCore::initializeIndicator): See ChangeLog entry above for more detail. 2019-09-17 Kocsen Chung Cherry-pick r249770. rdar://problem/55427487 REGRESSION (245006): can't scroll in "read more" view in Eventbrite app https://bugs.webkit.org/show_bug.cgi?id=201683 Reviewed by Simon Fraser. Source/WebCore: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isEventbrite): Source/WebKit: Content has 'overflow:hidden'. * UIProcess/Cocoa/VersionChecks.h: * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp: (WebKit::RemoteScrollingCoordinatorProxy::hasScrollableMainFrame const): Fix by adding an app specific LinkedOnOrAfter quirk that always allows main frame scrolling. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249770 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-11 Antti Koivisto REGRESSION (245006): can't scroll in "read more" view in Eventbrite app https://bugs.webkit.org/show_bug.cgi?id=201683 Reviewed by Simon Fraser. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isEventbrite): 2019-09-17 Kocsen Chung Cherry-pick r249762. rdar://problem/55427465 Prevent reentrancy FrameLoader::dispatchUnloadEvents() https://bugs.webkit.org/show_bug.cgi?id=200738 Reviewed by Brady Eidson. Reentrancy causes m_pageDismissalEventBeingDispatched to be incorrectly updated, so don't allow reentrancy. Since this prevents m_pageDismissalEventBeingDispatched from being reset inside a reentrant call, it can have the unintended effect of causing FrameLoader::stopAllLoaders to early-out when called from FrameLoader::detachFromParent while a frame's unload event handler calls document.open() on a parent frame and causes itself to become detached. Allowing a load to continue in a detached frame will lead to a crash. To prevent this, add a new argument to FrameLoader::stopAllLoaders that FrameLoader::detachFromParent can use to prevent an early-out. * loader/FrameLoader.cpp: (WebCore::FrameLoader::stopAllLoaders): (WebCore::FrameLoader::detachFromParent): (WebCore::FrameLoader::dispatchUnloadEvents): (WebCore::FrameLoader::dispatchBeforeUnloadEvent): Ensure that m_pageDismissalEventBeingDispatched is reset to its previous value, even if this is not None. * loader/FrameLoader.h: * loader/FrameLoaderTypes.h: Add a StopLoadingPolicy enum. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249762 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-11 Ali Juma Prevent reentrancy FrameLoader::dispatchUnloadEvents() https://bugs.webkit.org/show_bug.cgi?id=200738 Reviewed by Brady Eidson. Reentrancy causes m_pageDismissalEventBeingDispatched to be incorrectly updated, so don't allow reentrancy. Since this prevents m_pageDismissalEventBeingDispatched from being reset inside a reentrant call, it can have the unintended effect of causing FrameLoader::stopAllLoaders to early-out when called from FrameLoader::detachFromParent while a frame's unload event handler calls document.open() on a parent frame and causes itself to become detached. Allowing a load to continue in a detached frame will lead to a crash. To prevent this, add a new argument to FrameLoader::stopAllLoaders that FrameLoader::detachFromParent can use to prevent an early-out. * loader/FrameLoader.cpp: (WebCore::FrameLoader::stopAllLoaders): (WebCore::FrameLoader::detachFromParent): (WebCore::FrameLoader::dispatchUnloadEvents): (WebCore::FrameLoader::dispatchBeforeUnloadEvent): Ensure that m_pageDismissalEventBeingDispatched is reset to its previous value, even if this is not None. * loader/FrameLoader.h: * loader/FrameLoaderTypes.h: Add a StopLoadingPolicy enum. 2019-09-17 Kocsen Chung Cherry-pick r249748. rdar://problem/55240888 Nullptr crash in Page::sessionID() via WebKit::WebFrameLoaderClient::detachedFromParent2() https://bugs.webkit.org/show_bug.cgi?id=201625 Reviewed by Ryosuke Niwa. This is based on a patch from Ryosuke Niwa. Source/WebCore: Drop setHasFrameSpecificStorageAccess() in WebCore and call it from the WebKit layer instead. * dom/DocumentStorageAccess.cpp: (WebCore::DocumentStorageAccess::requestStorageAccess): (WebCore::DocumentStorageAccess::setHasFrameSpecificStorageAccess): Deleted. * dom/DocumentStorageAccess.h: * loader/EmptyFrameLoaderClient.h: * loader/FrameLoaderClient.h: Source/WebKit: The crash was caused by WebFrameLoaderClient::sessionID() calling WebPage::sessionID() without checking the nullity of WebPage::m_page which can be null. Added a null check. Because passing a wrong session to RemoveStorageAccessForFrame could result in a leak, this patch also replaces m_hasFrameSpecificStorageAccess boolean with an optioanl struct which stores session ID, frame ID, and page ID even after WebCore::Frame or WebCore::Page had been cleared or before WebFrameLoaderClient::m_frame is set. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::sessionID const): (WebKit::WebFrameLoaderClient::setHasFrameSpecificStorageAccess): (WebKit::WebFrameLoaderClient::detachedFromParent2): (WebKit::WebFrameLoaderClient::dispatchWillChangeDocument): * WebProcess/WebCoreSupport/WebFrameLoaderClient.h: * WebProcess/WebPage/WebFrame.h: (WebKit::WebFrame::frameLoaderClient const): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::requestStorageAccess): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249748 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-10 Chris Dumez Nullptr crash in Page::sessionID() via WebKit::WebFrameLoaderClient::detachedFromParent2() https://bugs.webkit.org/show_bug.cgi?id=201625 Reviewed by Ryosuke Niwa. This is based on a patch from Ryosuke Niwa. Drop setHasFrameSpecificStorageAccess() in WebCore and call it from the WebKit layer instead. * dom/DocumentStorageAccess.cpp: (WebCore::DocumentStorageAccess::requestStorageAccess): (WebCore::DocumentStorageAccess::setHasFrameSpecificStorageAccess): Deleted. * dom/DocumentStorageAccess.h: * loader/EmptyFrameLoaderClient.h: * loader/FrameLoaderClient.h: 2019-09-17 Kocsen Chung Cherry-pick r249701. rdar://problem/55291696 Tap and hold on Facebook sometimes creates a tall empty selection. https://bugs.webkit.org/show_bug.cgi?id=201618 rdar://53630145 Reviewed by Megan Gardner. Source/WebCore: API Test: SelectionTests.ByWordAtEndOfDocument * editing/VisibleUnits.cpp: (WebCore::wordRangeFromPosition): Remove special case code for the possibility of an empty paragraph and at the end of the document. This is no longer needed and was causing a large selection to be created on Facebook due to large areas of non-selectable content on the page. Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/ios/SelectionByWord.mm: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249701 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-09 Timothy Hatcher Tap and hold on Facebook sometimes creates a tall empty selection. https://bugs.webkit.org/show_bug.cgi?id=201618 rdar://53630145 Reviewed by Megan Gardner. API Test: SelectionTests.ByWordAtEndOfDocument * editing/VisibleUnits.cpp: (WebCore::wordRangeFromPosition): Remove special case code for the possibility of an empty paragraph and at the end of the document. This is no longer needed and was causing a large selection to be created on Facebook due to large areas of non-selectable content on the page. 2019-09-17 Kocsen Chung Cherry-pick r249511. rdar://problem/55291693 Cancelled transitions on Google image search leave content with opacity 0 sometimes https://bugs.webkit.org/show_bug.cgi?id=201482 rdar://problem/54921036 Reviewed by Tim Horton. Source/WebCore: If, in a single rendering update, we started an accelerated opacity transition, and then removed it, we'd still push the transition onto the CALayer with fillForwards and never remove it, so its effects would last forever. Fix by making GraphicsLayerCA::removeAnimation() remove animations from the uncomittedAnimations list as well. Also fix layer names in debug; if a layer's primaryLayerID changed, we'd fail to rename the CALayer, causing confusion when logging at layer dumps. Fix by adding the layer ID just before pushing the name to the platform layer. Some drive-by logging cleanup. Test: legacy-animation-engine/compositing/transitions/add-remove-transition.html * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::debugName const): * platform/graphics/GraphicsLayer.h: * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::setName): (WebCore::GraphicsLayerCA::debugName const): (WebCore::GraphicsLayerCA::addAnimation): (WebCore::GraphicsLayerCA::pauseAnimation): (WebCore::GraphicsLayerCA::seekAnimation): (WebCore::GraphicsLayerCA::removeAnimation): (WebCore::GraphicsLayerCA::platformCALayerAnimationStarted): (WebCore::GraphicsLayerCA::platformCALayerAnimationEnded): (WebCore::GraphicsLayerCA::updateNames): (WebCore::GraphicsLayerCA::createTransformAnimationsFromKeyframes): * platform/graphics/ca/GraphicsLayerCA.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::logLayerInfo): LayoutTests: * legacy-animation-engine/compositing/transitions/add-remove-transition-expected.html: Added. * legacy-animation-engine/compositing/transitions/add-remove-transition.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249511 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-17 Kocsen Chung Cherry-pick r249507. rdar://problem/55427491 Line artifacts in note body after viewing note with s https://bugs.webkit.org/show_bug.cgi?id=201474 Reviewed by Simon Fraser. Source/WebCore: Test: fast/attachment/attachment-border-should-stay-inside-attachment.html * rendering/RenderThemeIOS.mm: (WebCore::attachmentBorderPath): (WebCore::paintAttachmentBorder): Inset the border rect by half the width, so that doesn't paint out-of-bounds. LayoutTests: * fast/attachment/attachment-border-should-stay-inside-attachment-expected.html: Added. * fast/attachment/attachment-border-should-stay-inside-attachment.html: Added. Add a test that ensures that stays inside its bounds. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249507 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-04 Tim Horton Line artifacts in note body after viewing note with s https://bugs.webkit.org/show_bug.cgi?id=201474 Reviewed by Simon Fraser. Test: fast/attachment/attachment-border-should-stay-inside-attachment.html * rendering/RenderThemeIOS.mm: (WebCore::attachmentBorderPath): (WebCore::paintAttachmentBorder): Inset the border rect by half the width, so that doesn't paint out-of-bounds. 2019-09-17 Kocsen Chung Cherry-pick r249854. rdar://problem/55427477 Crash under WebCore::firstPositionInNode() https://bugs.webkit.org/show_bug.cgi?id=201764 Reviewed by Wenson Hsieh and Geoff Garen. Make sure to keep a Ref<> to the textNode when we call insertNodeAtTabSpanPosition() or insertNodeAt(). Test: editing/firstPositionInNode-crash.html * editing/InsertTextCommand.cpp: (WebCore::InsertTextCommand::positionInsideTextNode): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249854 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-13 Chris Dumez Crash under WebCore::firstPositionInNode() https://bugs.webkit.org/show_bug.cgi?id=201764 2019-09-11 Simon Fraser REGRESSION (iOS 13): Top fixed element on apple.com flickers in size while pinching in https://bugs.webkit.org/show_bug.cgi?id=201668 rdar://problem/51934041 Reviewed by Frédéric Wang. When computing the new layout viewport rect in ScrollingTreeFrameScrollingNode, use "StickToDocumentBounds" mode, not "StickToViewportBounds", because otherwise we'll compute a layout viewport that has negative top/left offsets which causes fixed elements to jump outside the viewport. The only code that should be moving things outside the viewport (a temporary effect that happens when pinching) is the 'isBelowMinimumScale' path in WebPageProxy::computeCustomFixedPositionRect(). With this change ScrollingTreeFrameScrollingNode no longer needs m_behaviorForFixed; it can be removed later. Not currently testable, since it involves pinching in past minimum zoom and transients state. * page/scrolling/ScrollingTreeFrameScrollingNode.cpp: (WebCore::ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition const): Reviewed by Wenson Hsieh and Geoff Garen. Make sure to keep a Ref<> to the textNode when we call insertNodeAtTabSpanPosition() or insertNodeAt(). Test: editing/firstPositionInNode-crash.html * editing/InsertTextCommand.cpp: (WebCore::InsertTextCommand::positionInsideTextNode): 2019-09-09 Ryosuke Niwa REGRESSION (iOS 13): Bulleted list copied from Notes to Mail results in Times New Roman https://bugs.webkit.org/show_bug.cgi?id=201490 Reviewed by Daniel Bates. The bug was caused by an element in the pasted content not having any explicit font name resolving to use the font-family value of `-webkit-standard`. When such an inline style is inserted into Mail's WKWebView which sets a different font family, ReplaceSelectionCommand would fail to strip away, making the pasted content using the default font family of Times New Roman. Fixed the bug by stripping away font-family set to -webkit-standard in the sanitization document since that's indicative of the pasted content not having any font family being specified. In the future, we should consider making regular copy (as opposed to the copy for sanitization) resolve generic font family names to concrete font names since different WKWebView might be using different concrete font names. Unfortuantely, such a change is quite involved and risky since various paste side code in EditingStyle that removes redundant inline styles (i.e. redundant `font-family`) need to be aware of this special font family resolution. Tests: editing/pasteboard/paste-cocoa-writer-markup-with-webkit-standard-font-family.html PasteHTML.DoesNotAddStandardFontFamily * editing/EditingStyle.cpp: (WebCore::EditingStyle::mergeInlineAndImplicitStyleOfElement): (WebCore::EditingStyle::wrappingStyleForSerialization): (WebCore::familyNameFromCSSPrimitiveValue): Added. (WebCore::loneFontFamilyName): Extracted from usesForbiddenSystemFontAsOnlyFontFamilyName. Fixed a bug that it was not handling the case when `font-family` property's value is a CSSPrimitiveValue instead of a CSSValueList. (WebCore::usesForbiddenSystemFontAsOnlyFontFamilyName): Deleted. (WebCore::EditingStyle::mergeStyleFromRulesForSerialization): Remove `font-family` property when StandardFontFamilySerializationMode::Strip is specified and its value is `-webkit-standard`. * editing/EditingStyle.h: * editing/markup.cpp: (WebCore::StyledMarkupAccumulator::StyledMarkupAccumulator): Added StandardFontFamilySerializationMode as an argument. (WebCore::StyledMarkupAccumulator::appendStartTag): (WebCore::StyledMarkupAccumulator::serializeNodes): (WebCore::serializePreservingVisualAppearanceInternal): Ditto. (WebCore::serializePreservingVisualAppearance): Use StandardFontFamilySerializationMode::Keep to preserve the pre-existing behavior. (WebCore::sanitizedMarkupForFragmentInDocument): Use StandardFontFamilySerializationMode::Strip as this is the code used by sanitization code. 2019-09-09 Kocsen Chung Cherry-pick r249605. rdar://problem/55182896 Incorrect selection rect revealed after pasting images in a contenteditable element https://bugs.webkit.org/show_bug.cgi?id=201549 Reviewed by Simon Fraser. Source/WebCore: Editor::replaceSelectionWithFragment currently scrolls to reveal the selection after inserting the given DocumentFragment. However, this scrolling occurs before any inserted images have loaded yet, which causes the wrong caret rect to be revealed, since all image elements inserted during paste will be empty. To fix this, we defer revealing the selection after inserting the fragment until after all images that have been inserted are done loading. While waiting for images to load, if any layers which may be scrolled as a result of revealing the selection are scrolled, we additionally cancel the deferred selection reveal. See comments below for more detail. Tests: editing/pasteboard/do-not-reveal-selection-after-programmatic-scroll.html editing/pasteboard/reveal-selection-after-pasting-images.html PasteImage.RevealSelectionAfterPastingImage * editing/Editing.cpp: (WebCore::visibleImageElementsInRangeWithNonLoadedImages): Add a new helper to iterate through a range and collect all image elements in that range, that contain cached images that have not finished loading yet. * editing/Editing.h: * editing/Editor.cpp: (WebCore::Editor::replaceSelectionWithFragment): Instead of always immediately revealing the selection after applying the ReplaceSelectionCommand, collect the image elements that were just inserted, and avoid immediately revealing the selection if any of these images have non-null cached images, but are not loaded yet. Instead, hold on to these images in a set, remove them once they finish loading using the new method below, and once all images are removed, reveal the selection. (WebCore::Editor::revealSelectionIfNeededAfterLoadingImageForElement): (WebCore::Editor::renderLayerDidScroll): Called whenever a scrollable RenderLayer is scrolled (or in the case of FrameView, the root layer). In the case where Editor is waiting to reveal the selection, we check to see if the scrolled layer is an ancestor of the layer enclosing the start of the selection. (WebCore::Editor::respondToChangedSelection): If the selection changes between pasting and waiting for pasted images to load, just cancel waiting to reveal the selection after pasting. * editing/Editor.h: * editing/ReplaceSelectionCommand.cpp: (WebCore::ReplaceSelectionCommand::insertedContentRange const): Add a helper method to grab the Range of content inserted after applying the command. * editing/ReplaceSelectionCommand.h: * page/FrameView.cpp: (WebCore::FrameView::scrollPositionChanged): * page/FrameView.h: * page/Page.cpp: (WebCore::Page::didFinishLoadingImageForElement): Notify Editor after an image finishes loading. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollTo): Source/WebKit: Tweak some existing logic to use the new visibleImageElementsInRangeWithNonLoadedImages helper function. See WebCore for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::didConcludeEditDrag): Tools: Add an API test to exercise the scenario where we scroll to reveal the selection after pasting an image that was directly written to the pasteboard. * TestWebKitAPI/Tests/WebKitCocoa/PasteImage.mm: LayoutTests: Add a couple of new layout tests. * editing/pasteboard/do-not-reveal-selection-after-programmatic-scroll-expected.txt: Added. * editing/pasteboard/do-not-reveal-selection-after-programmatic-scroll.html: Added. This test verifies that we don't try to scroll to reveal the caret after pasting, if the scroll position was changed before the images finished loading. * editing/pasteboard/reveal-selection-after-pasting-images-expected.txt: Added. * editing/pasteboard/reveal-selection-after-pasting-images.html: Added. * platform/ios/editing/pasteboard/reveal-selection-after-pasting-images-expected.txt: Added. This test verifies that we reveal the caret after loading multiple pasted images in a selection, and dispatch a scroll event in the process. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249605 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-06 Wenson Hsieh Incorrect selection rect revealed after pasting images in a contenteditable element https://bugs.webkit.org/show_bug.cgi?id=201549 Reviewed by Simon Fraser. Editor::replaceSelectionWithFragment currently scrolls to reveal the selection after inserting the given DocumentFragment. However, this scrolling occurs before any inserted images have loaded yet, which causes the wrong caret rect to be revealed, since all image elements inserted during paste will be empty. To fix this, we defer revealing the selection after inserting the fragment until after all images that have been inserted are done loading. While waiting for images to load, if any layers which may be scrolled as a result of revealing the selection are scrolled, we additionally cancel the deferred selection reveal. See comments below for more detail. Tests: editing/pasteboard/do-not-reveal-selection-after-programmatic-scroll.html editing/pasteboard/reveal-selection-after-pasting-images.html PasteImage.RevealSelectionAfterPastingImage * editing/Editing.cpp: (WebCore::visibleImageElementsInRangeWithNonLoadedImages): Add a new helper to iterate through a range and collect all image elements in that range, that contain cached images that have not finished loading yet. * editing/Editing.h: * editing/Editor.cpp: (WebCore::Editor::replaceSelectionWithFragment): Instead of always immediately revealing the selection after applying the ReplaceSelectionCommand, collect the image elements that were just inserted, and avoid immediately revealing the selection if any of these images have non-null cached images, but are not loaded yet. Instead, hold on to these images in a set, remove them once they finish loading using the new method below, and once all images are removed, reveal the selection. (WebCore::Editor::revealSelectionIfNeededAfterLoadingImageForElement): (WebCore::Editor::renderLayerDidScroll): Called whenever a scrollable RenderLayer is scrolled (or in the case of FrameView, the root layer). In the case where Editor is waiting to reveal the selection, we check to see if the scrolled layer is an ancestor of the layer enclosing the start of the selection. (WebCore::Editor::respondToChangedSelection): If the selection changes between pasting and waiting for pasted images to load, just cancel waiting to reveal the selection after pasting. * editing/Editor.h: * editing/ReplaceSelectionCommand.cpp: (WebCore::ReplaceSelectionCommand::insertedContentRange const): Add a helper method to grab the Range of content inserted after applying the command. * editing/ReplaceSelectionCommand.h: * page/FrameView.cpp: (WebCore::FrameView::scrollPositionChanged): * page/FrameView.h: * page/Page.cpp: (WebCore::Page::didFinishLoadingImageForElement): Notify Editor after an image finishes loading. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollTo): 2019-09-09 Kocsen Chung Cherry-pick r249581. rdar://problem/55202922 REGRESSION (iOS 13): If an overflow:hidden with a non-zero scroll position is toggled to overflow:scroll, some other scroll causes its scroll position to get reset https://bugs.webkit.org/show_bug.cgi?id=201528 rdar://problem/55044885 Reviewed by Frédéric Wang. Source/WebCore: If, when an overflow scrolling node is created, the scroller has non-zero scroll position (for example, via toggling to overflow:hidden, setting scrollTop, then toggling to overflow:scroll), then on the next update its scroll position will reset back to zero. The bug was that newly created ScrollingTreeScrollingNodes didn't set m_currentScrollPosition to the scroll position coming from the state node, so a subsequent update could cause the 0,0 currentScrollPosition to get applied. If we're making a new node, and there's no requestedScrollPosition, then initialize m_currentScrollPosition. Test: scrollingcoordinator/ios/scroller-initial-scroll-position.html * page/scrolling/ScrollingTreeScrollingNode.cpp: (WebCore::ScrollingTreeScrollingNode::commitStateBeforeChildren): (WebCore::ScrollingTreeScrollingNode::commitStateAfterChildren): * page/scrolling/ScrollingTreeScrollingNode.h: LayoutTests: * scrollingcoordinator/ios/scroller-initial-scroll-position-expected.html: Added. * scrollingcoordinator/ios/scroller-initial-scroll-position.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249581 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-09 Kocsen Chung Cherry-pick r249565. rdar://problem/55113261 AccessibilityRenderObject::setSelectedTextRange fails to set the selection passed an empty line. https://bugs.webkit.org/show_bug.cgi?id=201518 Patch by Andres Gonzalez on 2019-09-06 Reviewed by Ryosuke Niwa. Source/WebCore: Test: accessibility/set-selected-text-range-after-newline.html In the case of an empty line, the CharacterIterator range start and end were not equal, thus we were not advancing the iterator and returning the iterator range end, which is not correct. With this change we are always advancing the iterator if its text is just '\n'. This covers all the cases we fixed before plus empty lines. * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): LayoutTests: Extended this test to set the selection range passed an empty line. * accessibility/set-selected-text-range-after-newline-expected.txt: * accessibility/set-selected-text-range-after-newline.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249565 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-06 Andres Gonzalez AccessibilityRenderObject::setSelectedTextRange fails to set the selection passed an empty line. https://bugs.webkit.org/show_bug.cgi?id=201518 Reviewed by Ryosuke Niwa. Test: accessibility/set-selected-text-range-after-newline.html In the case of an empty line, the CharacterIterator range start and end were not equal, thus we were not advancing the iterator and returning the iterator range end, which is not correct. With this change we are always advancing the iterator if its text is just '\n'. This covers all the cases we fixed before plus empty lines. * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): 2019-09-09 Kocsen Chung Cherry-pick r249534. rdar://problem/55183098 AX: children cache are not re-computed if tab index is removed https://bugs.webkit.org/show_bug.cgi?id=201502 Reviewed by Zalan Bujtas. Source/WebCore: Test: accessibility/tabindex-removed.html If the tabindex changes, it can potentially affect whether an element is accessible. If we don't update the children cache information can be stale and lead to incorrect navigation with VoiceOver. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::handleAttributeChange): LayoutTests: * accessibility/tabindex-removed-expected.txt: Added. * accessibility/tabindex-removed.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249534 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-05 Chris Fleizach AX: children cache are not re-computed if tab index is removed https://bugs.webkit.org/show_bug.cgi?id=201502 Reviewed by Zalan Bujtas. Test: accessibility/tabindex-removed.html If the tabindex changes, it can potentially affect whether an element is accessible. If we don't update the children cache information can be stale and lead to incorrect navigation with VoiceOver. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::handleAttributeChange): 2019-09-09 Kocsen Chung Cherry-pick r249493. rdar://problem/55182906 [iPadOS] Unable to change sheets on Airtable.com https://bugs.webkit.org/show_bug.cgi?id=201456 Patch by Antoine Quint on 2019-09-04 Reviewed by Dean Jackson. Simulated mouse events are required to be able to manipulate cells and and columns on Airtable.com. However, dispatching a "mousedown" event on tabs allowing to pick a different sheet ends up calling preventDefault() and prevent "click" events from being dispatched, which makes it impossible to change sheet. We now limit the dispatch of simulated mouse events to the grid. * page/Quirks.cpp: (WebCore::Quirks::simulatedMouseEventTypeForTarget const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249493 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-04 Antoine Quint [iPadOS] Unable to change sheets on Airtable.com https://bugs.webkit.org/show_bug.cgi?id=201456 Reviewed by Dean Jackson. Simulated mouse events are required to be able to manipulate cells and and columns on Airtable.com. However, dispatching a "mousedown" event on tabs allowing to pick a different sheet ends up calling preventDefault() and prevent "click" events from being dispatched, which makes it impossible to change sheet. We now limit the dispatch of simulated mouse events to the grid. * page/Quirks.cpp: (WebCore::Quirks::simulatedMouseEventTypeForTarget const): 2019-09-09 Kocsen Chung Cherry-pick r248170. rdar://problem/55183128 [iOS] Directly use RealtimeMediaSourceCenter to compute the media capture state https://bugs.webkit.org/show_bug.cgi?id=200368 Unreviewed. Build fix by guarding with MEDIA_STREAM in addition to IOS. * dom/Document.cpp: (WebCore::Document::updateIsPlayingMedia): (WebCore::Document::pageMutedStateDidChange): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248170 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-04 Simon Fraser Cancelled transitions on Google image search leave content with opacity 0 sometimes https://bugs.webkit.org/show_bug.cgi?id=201482 rdar://problem/54921036 Reviewed by Tim Horton. If, in a single rendering update, we started an accelerated opacity transition, and then removed it, we'd still push the transition onto the CALayer with fillForwards and never remove it, so its effects would last forever. Fix by making GraphicsLayerCA::removeAnimation() remove animations from the uncomittedAnimations list as well. Also fix layer names in debug; if a layer's primaryLayerID changed, we'd fail to rename the CALayer, causing confusion when logging at layer dumps. Fix by adding the layer ID just before pushing the name to the platform layer. Some drive-by logging cleanup. Test: legacy-animation-engine/compositing/transitions/add-remove-transition.html * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::debugName const): * platform/graphics/GraphicsLayer.h: * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::setName): (WebCore::GraphicsLayerCA::debugName const): (WebCore::GraphicsLayerCA::addAnimation): (WebCore::GraphicsLayerCA::pauseAnimation): (WebCore::GraphicsLayerCA::seekAnimation): (WebCore::GraphicsLayerCA::removeAnimation): (WebCore::GraphicsLayerCA::platformCALayerAnimationStarted): (WebCore::GraphicsLayerCA::platformCALayerAnimationEnded): (WebCore::GraphicsLayerCA::updateNames): (WebCore::GraphicsLayerCA::createTransformAnimationsFromKeyframes): * platform/graphics/ca/GraphicsLayerCA.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::logLayerInfo): 2019-08-02 Youenn Fablet [iOS] Directly use RealtimeMediaSourceCenter to compute the media capture state https://bugs.webkit.org/show_bug.cgi?id=200368 Unreviewed. Build fix by guarding with MEDIA_STREAM in addition to IOS. * dom/Document.cpp: (WebCore::Document::updateIsPlayingMedia): (WebCore::Document::pageMutedStateDidChange): 2019-09-09 Kocsen Chung Cherry-pick r248161. rdar://problem/55183128 [iOS] Directly use RealtimeMediaSourceCenter to compute the media capture state https://bugs.webkit.org/show_bug.cgi?id=200368 Reviewed by Eric Carlson. Instead of registering a MediaStreamTrack as a media producer to compute capture state, go directly to the sources from the RealtimeMediaSourceCenter. Do the same when requested to mute capture tracks. No observable change of behavior. Covered by manual test on iOS and existing tests. * Modules/mediastream/MediaStreamTrack.cpp: (WebCore::MediaStreamTrack::MediaStreamTrack): (WebCore::MediaStreamTrack::~MediaStreamTrack): (WebCore::MediaStreamTrack::mediaState const): (WebCore::sourceCaptureState): (WebCore::MediaStreamTrack::captureState): (WebCore::MediaStreamTrack::muteCapture): * Modules/mediastream/MediaStreamTrack.h: * dom/Document.cpp: (WebCore::Document::updateIsPlayingMedia): (WebCore::Document::pageMutedStateDidChange): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248161 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Youenn Fablet [iOS] Directly use RealtimeMediaSourceCenter to compute the media capture state https://bugs.webkit.org/show_bug.cgi?id=200368 Reviewed by Eric Carlson. Instead of registering a MediaStreamTrack as a media producer to compute capture state, go directly to the sources from the RealtimeMediaSourceCenter. Do the same when requested to mute capture tracks. No observable change of behavior. Covered by manual test on iOS and existing tests. * Modules/mediastream/MediaStreamTrack.cpp: (WebCore::MediaStreamTrack::MediaStreamTrack): (WebCore::MediaStreamTrack::~MediaStreamTrack): (WebCore::MediaStreamTrack::mediaState const): (WebCore::sourceCaptureState): (WebCore::MediaStreamTrack::captureState): (WebCore::MediaStreamTrack::muteCapture): * Modules/mediastream/MediaStreamTrack.h: * dom/Document.cpp: (WebCore::Document::updateIsPlayingMedia): (WebCore::Document::pageMutedStateDidChange): 2019-09-04 Mark Lam Cherry-pick 248143. rdar://problem/55000992 2019-08-01 Mark Lam Add crash diagnostics for debugging unexpected zapped cells. https://bugs.webkit.org/show_bug.cgi?id=200149 Reviewed by Yusuke Suzuki. No new tests because this is a feature for debugging crashes. It has been tested manually by modifying the code to force a crash at the point of interest. Added some comments to document the hashes of known subspaces. * bindings/js/WebCoreJSClientData.cpp: (WebCore::JSVMClientData::JSVMClientData): 2019-09-04 Kocsen Chung Cherry-pick r249147. rdar://problem/55001178 Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state. https://bugs.webkit.org/show_bug.cgi?id=201101 Reviewed by Eric Carlson. Source/WebCore: Test: fullscreen/full-screen-request-removed-with-raf.html Add a new state variable, m_pendingFullscreenElement, to track which element is about to become the fullscreen element, so that when elements are removed or cancelFullscreen() is called, the state machine inside the fullscreen algorithm can cancel effectively. * dom/FullscreenManager.cpp: (WebCore::FullscreenManager::requestFullscreenForElement): (WebCore::FullscreenManager::cancelFullscreen): (WebCore::FullscreenManager::exitFullscreen): (WebCore::FullscreenManager::willEnterFullscreen): (WebCore::FullscreenManager::willExitFullscreen): (WebCore::FullscreenManager::didExitFullscreen): (WebCore::FullscreenManager::adjustFullscreenElementOnNodeRemoval): (WebCore::FullscreenManager::clear): (WebCore::FullscreenManager::fullscreenElementRemoved): Deleted. * dom/FullscreenManager.h: Source/WebKit: Add more state to track in which direction the animation is flowing to allow in-process animations to be cancelled more gracefully. * UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm: (-[WKFullScreenWindowController enterFullScreen]): (-[WKFullScreenWindowController beganEnterFullScreenWithInitialFrame:finalFrame:]): (-[WKFullScreenWindowController requestExitFullScreen]): (-[WKFullScreenWindowController exitFullScreen]): * WebProcess/cocoa/VideoFullscreenManager.h: (WebKit::VideoFullscreenInterfaceContext::animationState const): (WebKit::VideoFullscreenInterfaceContext::setAnimationState): (WebKit::VideoFullscreenInterfaceContext::isAnimating const): Deleted. (WebKit::VideoFullscreenInterfaceContext::setIsAnimating): Deleted. * WebProcess/cocoa/VideoFullscreenManager.mm: (WebKit::VideoFullscreenManager::enterVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::exitVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::didEnterFullscreen): (WebKit::VideoFullscreenManager::didCleanupFullscreen): LayoutTests: * fullscreen/full-screen-request-removed-with-raf-expected.txt: Added. * fullscreen/full-screen-request-removed-with-raf.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249147 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-26 Jer Noble Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state. https://bugs.webkit.org/show_bug.cgi?id=201101 Reviewed by Eric Carlson. Test: fullscreen/full-screen-request-removed-with-raf.html Add a new state variable, m_pendingFullscreenElement, to track which element is about to become the fullscreen element, so that when elements are removed or cancelFullscreen() is called, the state machine inside the fullscreen algorithm can cancel effectively. * dom/FullscreenManager.cpp: (WebCore::FullscreenManager::requestFullscreenForElement): (WebCore::FullscreenManager::cancelFullscreen): (WebCore::FullscreenManager::exitFullscreen): (WebCore::FullscreenManager::willEnterFullscreen): (WebCore::FullscreenManager::willExitFullscreen): (WebCore::FullscreenManager::didExitFullscreen): (WebCore::FullscreenManager::adjustFullscreenElementOnNodeRemoval): (WebCore::FullscreenManager::clear): (WebCore::FullscreenManager::fullscreenElementRemoved): Deleted. * dom/FullscreenManager.h: 2019-09-04 Kocsen Chung Cherry-pick r249140. rdar://problem/55001152 Image pasted from screenshot into Mail compose window via share sheet has the wrong aspect ratio https://bugs.webkit.org/show_bug.cgi?id=201171 Reviewed by Tim Horton. Augments an existing app-specific hack to include the Mail composition service, in addition to Mail. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isMailCompositionService): Add a new bundle checking method for the Mail composition service (com.apple.MailCompositionService). * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): Only plumb the preferred presentation height through to the web process if the application is neither Mail nor the Mail composition service. In the future, we should consider putting this hack behind SPI, or maybe only expose the preferred presentation width in all apps (it isn't difficult to imagine a use case where a "Mail- compose-like" web app has `img { max-width: 100%; }` in their stylesheet). git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249140 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-27 Wenson Hsieh Image pasted from screenshot into Mail compose window via share sheet has the wrong aspect ratio https://bugs.webkit.org/show_bug.cgi?id=201171 Reviewed by Tim Horton. Augments an existing app-specific hack to include the Mail composition service, in addition to Mail. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isMailCompositionService): Add a new bundle checking method for the Mail composition service (com.apple.MailCompositionService). * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): Only plumb the preferred presentation height through to the web process if the application is neither Mail nor the Mail composition service. In the future, we should consider putting this hack behind SPI, or maybe only expose the preferred presentation width in all apps (it isn't difficult to imagine a use case where a "Mail- compose-like" web app has `img { max-width: 100%; }` in their stylesheet). 2019-09-03 Kocsen Chung Cherry-pick r249339. rdar://problem/55001170 Caret does not appear in text field inside a transformed, overflow: hidden container https://bugs.webkit.org/show_bug.cgi?id=201317 Reviewed by Simon Fraser. Source/WebCore: This patch refactors the heuristic for determining whether to suppress selection gestures and UI in a way that fixes the corner case encountered in this bug. To understand why this test case fails with our existing heuristic, consider the below test case. Let's say we have an input field inside an "overflow: hidden;" container, which is positioned in such a way that it is completely clipped by its enclosing container which is also "overflow: hidden". Our existing logic would appropriately identify this as a hidden editable element. However, let's now apply a transform to the input field's closest "overflow: hidden" ancestor, such that the field is now visible. Since RenderLayer::offsetFromAncestor doesn't take transforms into account when we try to find the offset of the "overflow: hidden" layer relative to the root view, we end up passing an offsetFromRoot of (0, 100vw) to RenderLayer::calculateClipRects, which computes a background clip rect of (0, 0, 100vw, 100vh). This means that at the end of RenderLayer::calculateClipRects, we end up intersecting the background clip rect (0, 0, 100vw, 100vh) against (100vw, 0, 100vw, 100vh), which results in the empty rect, and subsequently makes us believe we're editing a hidden editable element. Instead of tacking on more logic to isTransparentOrFullyClippedRespectingParentFrames, we can fix this by using RenderObject::computeVisibleRectInContainer instead, performing a similar walk up the render tree to compute the visible rect of each focused element or subframe relative to its root. This is capable of taking transforms into account. See comments below for more details. Test: editing/selection/ios/show-selection-in-transformed-container-2.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::isTransparentRespectingParentFrames const): Split out isTransparentOrFullyClippedRespectingParentFrames into two methods: RenderLayer's isTransparentRespectingParentFrames, and RenderObject's hasNonEmptyVisibleRectRespectingParentFrames. The transparency check starts at the enclosing layer and walks up the layer tree, while the non-empty visible rect check looks for renderers that are completely empty relative to their root views. * rendering/RenderLayer.h: * rendering/RenderObject.cpp: (WebCore::RenderObject::hasNonEmptyVisibleRectRespectingParentFrames const): Rewrite logic for detecting completely clipped editable areas (that formerly lived in isTransparentOrFullyClippedRespectingParentFrames) to use computeVisibleRectInContainer instead. * rendering/RenderObject.h: Source/WebKit: Adjust isTransparentOrFullyClipped to use the new methods in RenderLayer and RenderObject. See WebCore ChangeLog for more details. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::isTransparentOrFullyClipped const): LayoutTests: Add a new layout test that covers this scenario. See WebCore ChangeLog for additional detail. * editing/selection/ios/show-selection-in-transformed-container-2-expected.txt: Added. * editing/selection/ios/show-selection-in-transformed-container-2.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249339 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-30 Wenson Hsieh Caret does not appear in text field inside a transformed, overflow: hidden container https://bugs.webkit.org/show_bug.cgi?id=201317 Reviewed by Simon Fraser. This patch refactors the heuristic for determining whether to suppress selection gestures and UI in a way that fixes the corner case encountered in this bug. To understand why this test case fails with our existing heuristic, consider the below test case. Let's say we have an input field inside an "overflow: hidden;" container, which is positioned in such a way that it is completely clipped by its enclosing container which is also "overflow: hidden". Our existing logic would appropriately identify this as a hidden editable element. However, let's now apply a transform to the input field's closest "overflow: hidden" ancestor, such that the field is now visible. Since RenderLayer::offsetFromAncestor doesn't take transforms into account when we try to find the offset of the "overflow: hidden" layer relative to the root view, we end up passing an offsetFromRoot of (0, 100vw) to RenderLayer::calculateClipRects, which computes a background clip rect of (0, 0, 100vw, 100vh). This means that at the end of RenderLayer::calculateClipRects, we end up intersecting the background clip rect (0, 0, 100vw, 100vh) against (100vw, 0, 100vw, 100vh), which results in the empty rect, and subsequently makes us believe we're editing a hidden editable element. Instead of tacking on more logic to isTransparentOrFullyClippedRespectingParentFrames, we can fix this by using RenderObject::computeVisibleRectInContainer instead, performing a similar walk up the render tree to compute the visible rect of each focused element or subframe relative to its root. This is capable of taking transforms into account. See comments below for more details. Test: editing/selection/ios/show-selection-in-transformed-container-2.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::isTransparentRespectingParentFrames const): Split out isTransparentOrFullyClippedRespectingParentFrames into two methods: RenderLayer's isTransparentRespectingParentFrames, and RenderObject's hasNonEmptyVisibleRectRespectingParentFrames. The transparency check starts at the enclosing layer and walks up the layer tree, while the non-empty visible rect check looks for renderers that are completely empty relative to their root views. * rendering/RenderLayer.h: * rendering/RenderObject.cpp: (WebCore::RenderObject::hasNonEmptyVisibleRectRespectingParentFrames const): Rewrite logic for detecting completely clipped editable areas (that formerly lived in isTransparentOrFullyClippedRespectingParentFrames) to use computeVisibleRectInContainer instead. * rendering/RenderObject.h: 2019-09-03 Kocsen Chung Cherry-pick r249115. rdar://problem/55001212 Don't compute upconverted characters twice in buildQuery() in DataDetection.mm Reviewed by Brent Fulgham. Source/WebCore: * editing/cocoa/DataDetection.mm: (WebCore::buildQuery): Extract common variables to prevent double conversion for 8-bit strings. Tools: 2019-09-06 Simon Fraser REGRESSION (iOS 13): If an overflow:hidden with a non-zero scroll position is toggled to overflow:scroll, some other scroll causes its scroll position to get reset https://bugs.webkit.org/show_bug.cgi?id=201528 rdar://problem/55044885 Reviewed by Frédéric Wang. If, when an overflow scrolling node is created, the scroller has non-zero scroll position (for example, via toggling to overflow:hidden, setting scrollTop, then toggling to overflow:scroll), then on the next update its scroll position will reset back to zero. The bug was that newly created ScrollingTreeScrollingNodes didn't set m_currentScrollPosition to the scroll position coming from the state node, so a subsequent update could cause the 0,0 currentScrollPosition to get applied. If we're making a new node, and there's no requestedScrollPosition, then initialize m_currentScrollPosition. Test: scrollingcoordinator/ios/scroller-initial-scroll-position.html * page/scrolling/ScrollingTreeScrollingNode.cpp: (WebCore::ScrollingTreeScrollingNode::commitStateBeforeChildren): (WebCore::ScrollingTreeScrollingNode::commitStateAfterChildren): * page/scrolling/ScrollingTreeScrollingNode.h: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: Add DataDetectorsTestIOS.mm to the project. * TestWebKitAPI/Tests/ios/DataDetectorsTestIOS.mm: Add a new test for Data Detectors for phone numbers. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249115 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-26 David Kilzer Don't compute upconverted characters twice in buildQuery() in DataDetection.mm Reviewed by Brent Fulgham. * editing/cocoa/DataDetection.mm: (WebCore::buildQuery): Extract common variables to prevent double conversion for 8-bit strings. 2019-09-03 Kocsen Chung Cherry-pick r249026. rdar://problem/55001375 Crash may happen when an SVG element references the root element https://bugs.webkit.org/show_bug.cgi?id=201014 Reviewed by Ryosuke Niwa. Source/WebCore: When an references an element as its target image but this element is also one of the ancestors of the , the parent should not be applied. Test: svg/filters/filter-image-ref-root.html * svg/SVGFEImageElement.cpp: (WebCore::SVGFEImageElement::build const): LayoutTests: Ensure the cyclic reference between the renderer and its ancestor root renderer is broken. * svg/filters/filter-image-ref-root-expected.txt: Added. * svg/filters/filter-image-ref-root.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249026 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-22 Said Abou-Hallawa Crash may happen when an SVG element references the root element https://bugs.webkit.org/show_bug.cgi?id=201014 Reviewed by Ryosuke Niwa. When an references an element as its target image but this element is also one of the ancestors of the , the parent should not be applied. Test: svg/filters/filter-image-ref-root.html * svg/SVGFEImageElement.cpp: (WebCore::SVGFEImageElement::build const): 2019-09-03 Kocsen Chung Cherry-pick r248692. rdar://problem/55001378 [Cocoa] Add some WKA extension points https://bugs.webkit.org/show_bug.cgi?id=200506 Reviewed by Tim Horton. Source/WebCore: * Modules/applepay/ApplePayPayment.h: * Modules/applepay/ApplePayPaymentMethod.h: * Modules/applepay/ApplePayRequestBase.cpp: (WebCore::finishConverting): (WebCore::convertAndValidate): * Modules/applepay/ApplePayRequestBase.h: * Modules/applepay/ApplePaySessionPaymentRequest.h: * Modules/applepay/PaymentCoordinatorClient.cpp: (WebCore::PaymentCoordinatorClient::supportsVersion): * Modules/applepay/cocoa/PaymentCocoa.mm: (WebCore::convert): * Modules/applepay/cocoa/PaymentMethodCocoa.mm: (WebCore::finishConverting): (WebCore::convert): Source/WebKit: * Shared/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.mm: (WebKit::finishCreating): (WebKit::WebPaymentCoordinatorProxy::platformPaymentRequest): * Shared/Cocoa/WebCoreArgumentCodersCocoa.mm: (IPC::finishDecoding): (IPC::finishEncoding): (IPC::ArgumentCoder::encode): (IPC::ArgumentCoder::decode): * Shared/WebCoreArgumentCoders.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248692 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-14 Andy Estes [Cocoa] Add some WKA extension points https://bugs.webkit.org/show_bug.cgi?id=200506 Reviewed by Tim Horton. * Modules/applepay/ApplePayPayment.h: * Modules/applepay/ApplePayPaymentMethod.h: * Modules/applepay/ApplePayRequestBase.cpp: (WebCore::finishConverting): (WebCore::convertAndValidate): * Modules/applepay/ApplePayRequestBase.h: * Modules/applepay/ApplePaySessionPaymentRequest.h: * Modules/applepay/PaymentCoordinatorClient.cpp: (WebCore::PaymentCoordinatorClient::supportsVersion): * Modules/applepay/cocoa/PaymentCocoa.mm: (WebCore::convert): * Modules/applepay/cocoa/PaymentMethodCocoa.mm: (WebCore::finishConverting): (WebCore::convert): 2019-09-03 Kocsen Chung Cherry-pick r248275. rdar://problem/55001373 [WebIDL] Support partial dictionaries and conditional dictionary members https://bugs.webkit.org/show_bug.cgi?id=200441 Reviewed by Alex Christensen. Added new bindings tests. * bindings/scripts/CodeGeneratorJS.pm: (GenerateDictionaryImplementationContent): * bindings/scripts/IDLParser.pm: (parsePartialDefinition): (parsePartialInterface): Deleted. (parsePartialDictionary): Deleted. * bindings/scripts/generate-bindings.pl: (generateBindings): * bindings/scripts/preprocess-idls.pl: (getPartialNamesFromIDL): (getPartialInterfaceNameFromIDL): Deleted. * bindings/scripts/test/JS/JSTestEventConstructor.cpp: (WebCore::convertDictionary): * bindings/scripts/test/JS/JSTestStandaloneDictionary.cpp: (WebCore::convertDictionary): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestStandaloneDictionary.h: * bindings/scripts/test/TestStandaloneDictionary.idl: * bindings/scripts/test/TestSupplemental.idl: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248275 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-05 Andy Estes [WebIDL] Support partial dictionaries and conditional dictionary members https://bugs.webkit.org/show_bug.cgi?id=200441 Reviewed by Alex Christensen. Added new bindings tests. * bindings/scripts/CodeGeneratorJS.pm: (GenerateDictionaryImplementationContent): * bindings/scripts/IDLParser.pm: (parsePartialDefinition): (parsePartialInterface): Deleted. (parsePartialDictionary): Deleted. * bindings/scripts/generate-bindings.pl: (generateBindings): * bindings/scripts/preprocess-idls.pl: (getPartialNamesFromIDL): (getPartialInterfaceNameFromIDL): Deleted. * bindings/scripts/test/JS/JSTestEventConstructor.cpp: (WebCore::convertDictionary): * bindings/scripts/test/JS/JSTestStandaloneDictionary.cpp: (WebCore::convertDictionary): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestStandaloneDictionary.h: * bindings/scripts/test/TestStandaloneDictionary.idl: * bindings/scripts/test/TestSupplemental.idl: 2019-08-28 Kocsen Chung Cherry-pick r249156. rdar://problem/54775048 Crash under WebCore::jsNotificationConstructorPermission https://bugs.webkit.org/show_bug.cgi?id=201186 Reviewed by Youenn Fablet. Source/WebCore: Update the Notification API implementation to null-check the page before using. The page becomes null when using the API in a frame that gets detached from its parent while in the middle of running script. Test: http/tests/notifications/request-in-detached-frame.html * Modules/notifications/Notification.cpp: (WebCore::Notification::permission): (WebCore::Notification::requestPermission): LayoutTests: Add layout test coverage. * http/tests/notifications/request-in-detached-frame-expected.txt: Added. * http/tests/notifications/request-in-detached-frame.html: Added. * http/tests/notifications/resources/request-in-detached-frame-subframe.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249156 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-27 Chris Dumez Crash under WebCore::jsNotificationConstructorPermission https://bugs.webkit.org/show_bug.cgi?id=201186 Reviewed by Youenn Fablet. Update the Notification API implementation to null-check the page before using. The page becomes null when using the API in a frame that gets detached from its parent while in the middle of running script. Test: http/tests/notifications/request-in-detached-frame.html * Modules/notifications/Notification.cpp: (WebCore::Notification::permission): (WebCore::Notification::requestPermission): 2019-08-28 Kocsen Chung Cherry-pick r249154. rdar://problem/54775050 Disabled devices should not be taken into account when searching for a capture device https://bugs.webkit.org/show_bug.cgi?id=201183 Reviewed by Jer Noble. Manually tested. * platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp: (WebCore::CoreAudioCaptureDeviceManager::coreAudioDeviceWithUID): We currently keep a list of devices, some of which might be disabled. We should not take into account disabled devices, only enabled devices when doing this search. * platform/mediastream/mac/CoreAudioCaptureSource.cpp: (WebCore::CoreAudioSharedUnit::setupAudioUnit): Improve logging. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249154 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-27 Youenn Fablet Disabled devices should not be taken into account when searching for a capture device https://bugs.webkit.org/show_bug.cgi?id=201183 Reviewed by Jer Noble. Manually tested. * platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp: (WebCore::CoreAudioCaptureDeviceManager::coreAudioDeviceWithUID): We currently keep a list of devices, some of which might be disabled. We should not take into account disabled devices, only enabled devices when doing this search. * platform/mediastream/mac/CoreAudioCaptureSource.cpp: (WebCore::CoreAudioSharedUnit::setupAudioUnit): Improve logging. 2019-08-27 Alan Coon Revert r249140. rdar://problem/54749102 2019-08-27 Alan Coon Revert r249147. rdar://problem/54751753 2019-08-27 Alan Coon Cherry-pick r249147. rdar://problem/54751753 Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state. https://bugs.webkit.org/show_bug.cgi?id=201101 Reviewed by Eric Carlson. Source/WebCore: Test: fullscreen/full-screen-request-removed-with-raf.html Add a new state variable, m_pendingFullscreenElement, to track which element is about to become the fullscreen element, so that when elements are removed or cancelFullscreen() is called, the state machine inside the fullscreen algorithm can cancel effectively. * dom/FullscreenManager.cpp: (WebCore::FullscreenManager::requestFullscreenForElement): (WebCore::FullscreenManager::cancelFullscreen): (WebCore::FullscreenManager::exitFullscreen): (WebCore::FullscreenManager::willEnterFullscreen): (WebCore::FullscreenManager::willExitFullscreen): (WebCore::FullscreenManager::didExitFullscreen): (WebCore::FullscreenManager::adjustFullscreenElementOnNodeRemoval): (WebCore::FullscreenManager::clear): (WebCore::FullscreenManager::fullscreenElementRemoved): Deleted. * dom/FullscreenManager.h: Source/WebKit: Add more state to track in which direction the animation is flowing to allow in-process animations to be cancelled more gracefully. * UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm: (-[WKFullScreenWindowController enterFullScreen]): (-[WKFullScreenWindowController beganEnterFullScreenWithInitialFrame:finalFrame:]): (-[WKFullScreenWindowController requestExitFullScreen]): (-[WKFullScreenWindowController exitFullScreen]): * WebProcess/cocoa/VideoFullscreenManager.h: (WebKit::VideoFullscreenInterfaceContext::animationState const): (WebKit::VideoFullscreenInterfaceContext::setAnimationState): (WebKit::VideoFullscreenInterfaceContext::isAnimating const): Deleted. (WebKit::VideoFullscreenInterfaceContext::setIsAnimating): Deleted. * WebProcess/cocoa/VideoFullscreenManager.mm: (WebKit::VideoFullscreenManager::enterVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::exitVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::didEnterFullscreen): (WebKit::VideoFullscreenManager::didCleanupFullscreen): LayoutTests: * fullscreen/full-screen-request-removed-with-raf-expected.txt: Added. * fullscreen/full-screen-request-removed-with-raf.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249147 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-26 Jer Noble Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state. https://bugs.webkit.org/show_bug.cgi?id=201101 Reviewed by Eric Carlson. Test: fullscreen/full-screen-request-removed-with-raf.html Add a new state variable, m_pendingFullscreenElement, to track which element is about to become the fullscreen element, so that when elements are removed or cancelFullscreen() is called, the state machine inside the fullscreen algorithm can cancel effectively. * dom/FullscreenManager.cpp: (WebCore::FullscreenManager::requestFullscreenForElement): (WebCore::FullscreenManager::cancelFullscreen): (WebCore::FullscreenManager::exitFullscreen): (WebCore::FullscreenManager::willEnterFullscreen): (WebCore::FullscreenManager::willExitFullscreen): (WebCore::FullscreenManager::didExitFullscreen): (WebCore::FullscreenManager::adjustFullscreenElementOnNodeRemoval): (WebCore::FullscreenManager::clear): (WebCore::FullscreenManager::fullscreenElementRemoved): Deleted. * dom/FullscreenManager.h: 2019-08-27 Alan Coon Cherry-pick r249140. rdar://problem/54749102 Image pasted from screenshot into Mail compose window via share sheet has the wrong aspect ratio https://bugs.webkit.org/show_bug.cgi?id=201171 Reviewed by Tim Horton. Augments an existing app-specific hack to include the Mail composition service, in addition to Mail. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isMailCompositionService): Add a new bundle checking method for the Mail composition service (com.apple.MailCompositionService). * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): Only plumb the preferred presentation height through to the web process if the application is neither Mail nor the Mail composition service. In the future, we should consider putting this hack behind SPI, or maybe only expose the preferred presentation width in all apps (it isn't difficult to imagine a use case where a "Mail- compose-like" web app has `img { max-width: 100%; }` in their stylesheet). git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249140 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-27 Wenson Hsieh Image pasted from screenshot into Mail compose window via share sheet has the wrong aspect ratio https://bugs.webkit.org/show_bug.cgi?id=201171 Reviewed by Tim Horton. Augments an existing app-specific hack to include the Mail composition service, in addition to Mail. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isMailCompositionService): Add a new bundle checking method for the Mail composition service (com.apple.MailCompositionService). * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): Only plumb the preferred presentation height through to the web process if the application is neither Mail nor the Mail composition service. In the future, we should consider putting this hack behind SPI, or maybe only expose the preferred presentation width in all apps (it isn't difficult to imagine a use case where a "Mail- compose-like" web app has `img { max-width: 100%; }` in their stylesheet). 2019-08-27 Alan Coon Cherry-pick r249074. rdar://problem/54735492 [iOS] [WebKit2] Tapping on the “I’m” text suggestion after typing “i’” does nothing https://bugs.webkit.org/show_bug.cgi?id=201085 Reviewed by Tim Horton. Source/WebCore: Exposes an existing quote folding function as a helper on TextIterator, and also adjusts foldQuoteMarks to take a const String& rather than a String. See WebKit ChangeLog for more details. * editing/TextIterator.cpp: (WebCore::foldQuoteMarks): (WebCore::SearchBuffer::SearchBuffer): * editing/TextIterator.h: Source/WebKit: Currently, logic in applyAutocorrectionInternal only selects the range to autocorrect if the text of the range matches the string to replace (delivered to us from UIKit). In the case of changing "I’" to "I’m", the string to replace is "I'" (with a straight quote rather than an apostrophe), even though the DOM contains an apostrophe. This is because kbd believes that the document context contains straight quotes (rather than apostrophes). For native text views, this works out because UIKit uses relative UITextPositions to determine the replacement range rather than by checking against the contents of the document. However, WKWebView does not have the ability to synchronously compute and reason about arbitrary UITextPositions relative to the selection, so we instead search for the string near the current selection when applying autocorrections. Of course, this doesn't work in this scenario because the replacement string contains a straight quote, yet the text node contains an apostrophe, so we bail and don't end up replacing any text. To address this, we repurpose TextIterator helpers currently used to allow find-in-page to match straight quotes against apostrophes; instead of matching the replacement string exactly, we instead match the quote-folded versions of these strings when finding the range to replace. Test: fast/events/ios/autocorrect-with-apostrophe.html * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applyAutocorrectionInternal): LayoutTests: Add a new layout test to verify that "I’" can be autocorrected to "I’m". * fast/events/ios/autocorrect-with-apostrophe-expected.txt: Added. * fast/events/ios/autocorrect-with-apostrophe.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249074 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-23 Wenson Hsieh [iOS] [WebKit2] Tapping on the “I’m” text suggestion after typing “i’” does nothing https://bugs.webkit.org/show_bug.cgi?id=201085 Reviewed by Tim Horton. Exposes an existing quote folding function as a helper on TextIterator, and also adjusts foldQuoteMarks to take a const String& rather than a String. See WebKit ChangeLog for more details. * editing/TextIterator.cpp: (WebCore::foldQuoteMarks): (WebCore::SearchBuffer::SearchBuffer): * editing/TextIterator.h: 2019-08-27 Alan Coon Cherry-pick r248886. rdar://problem/54365278 Source/WebCore: [Cocoa] Fix misspelling of -preventsDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. Only declare the API on platforms where that API is undefined, so as to catch this kind of misspelling at compile time. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): Source/WebCore/PAL: [Cocoa] Adopt -preventDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. * pal/spi/mac/AVFoundationSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248886 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-19 Jer Noble [Cocoa] Fix misspelling of -preventsDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. Only declare the API on platforms where that API is undefined, so as to catch this kind of misspelling at compile time. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): 2019-08-23 Kocsen Chung Cherry-pick r248969. rdar://problem/54643450 Crash under StringImpl::~StringImpl() in IDBServer::computeSpaceUsedForOrigin() https://bugs.webkit.org/show_bug.cgi?id=200989 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on IDBServer::m_databaseDirectoryPath before using it from background threads. * Modules/indexeddb/server/IDBServer.cpp: (WebCore::IDBServer::IDBServer::createBackingStore): (WebCore::IDBServer::IDBServer::performGetAllDatabaseNames): (WebCore::IDBServer::IDBServer::removeDatabasesModifiedSinceForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesModifiedSince): (WebCore::IDBServer::IDBServer::removeDatabasesWithOriginsForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesForOrigins): (WebCore::IDBServer::IDBServer::computeSpaceUsedForOrigin): (WebCore::IDBServer::IDBServer::upgradeFilesIfNecessary): * Modules/indexeddb/server/IDBServer.h: (WebCore::IDBServer::IDBServer::databaseDirectoryPath const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248969 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Chris Dumez Crash under StringImpl::~StringImpl() in IDBServer::computeSpaceUsedForOrigin() https://bugs.webkit.org/show_bug.cgi?id=200989 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on IDBServer::m_databaseDirectoryPath before using it from background threads. * Modules/indexeddb/server/IDBServer.cpp: (WebCore::IDBServer::IDBServer::createBackingStore): (WebCore::IDBServer::IDBServer::performGetAllDatabaseNames): (WebCore::IDBServer::IDBServer::removeDatabasesModifiedSinceForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesModifiedSince): (WebCore::IDBServer::IDBServer::removeDatabasesWithOriginsForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesForOrigins): (WebCore::IDBServer::IDBServer::computeSpaceUsedForOrigin): (WebCore::IDBServer::IDBServer::upgradeFilesIfNecessary): * Modules/indexeddb/server/IDBServer.h: (WebCore::IDBServer::IDBServer::databaseDirectoryPath const): 2019-08-23 Kocsen Chung Cherry-pick r248971. rdar://problem/54643440 Crash under StringImpl::endsWith() in SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade() https://bugs.webkit.org/show_bug.cgi?id=200990 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on SQLiteIDBBackingStore::m_databaseRootDirectory before using it from background threads. * Modules/indexeddb/server/SQLiteIDBBackingStore.cpp: (WebCore::IDBServer::SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade): (WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForOrigin const): (WebCore::IDBServer::SQLiteIDBBackingStore::deleteBackingStore): * Modules/indexeddb/server/SQLiteIDBBackingStore.h: (WebCore::IDBServer::SQLiteIDBBackingStore::databaseRootDirectory const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248971 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Chris Dumez Crash under StringImpl::endsWith() in SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade() https://bugs.webkit.org/show_bug.cgi?id=200990 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on SQLiteIDBBackingStore::m_databaseRootDirectory before using it from background threads. * Modules/indexeddb/server/SQLiteIDBBackingStore.cpp: (WebCore::IDBServer::SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade): (WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForOrigin const): (WebCore::IDBServer::SQLiteIDBBackingStore::deleteBackingStore): * Modules/indexeddb/server/SQLiteIDBBackingStore.h: (WebCore::IDBServer::SQLiteIDBBackingStore::databaseRootDirectory const): 2019-08-23 Kocsen Chung Cherry-pick r248967. rdar://problem/54643456 Crash under StringImpl::endsWith() in RegistrationDatabase::openSQLiteDatabase() https://bugs.webkit.org/show_bug.cgi?id=200991 Reviewed by Geoffrey Garen. Make sure we call isolatedCopy() on RegistrationDatabase::m_databaseDirectory before using it from background threads. * workers/service/server/RegistrationDatabase.cpp: (WebCore::RegistrationDatabase::openSQLiteDatabase): (WebCore::RegistrationDatabase::clearAll): * workers/service/server/RegistrationDatabase.h: (WebCore::RegistrationDatabase::databaseDirectory const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248967 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Chris Dumez Crash under StringImpl::endsWith() in RegistrationDatabase::openSQLiteDatabase() https://bugs.webkit.org/show_bug.cgi?id=200991 Reviewed by Geoffrey Garen. Make sure we call isolatedCopy() on RegistrationDatabase::m_databaseDirectory before using it from background threads. * workers/service/server/RegistrationDatabase.cpp: (WebCore::RegistrationDatabase::openSQLiteDatabase): (WebCore::RegistrationDatabase::clearAll): * workers/service/server/RegistrationDatabase.h: (WebCore::RegistrationDatabase::databaseDirectory const): 2019-08-22 Kocsen Chung Cherry-pick r249006. rdar://problem/54600921 Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com https://bugs.webkit.org/show_bug.cgi?id=201023 Reviewed by Ryosuke Niwa. Source/WebCore: Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the WebKit ChangeLog for more details. Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::calculateClipRects const): Source/WebKit: After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on Microsoft Word online. However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform input context changes when moving between the title and body fields, or when tapping to change selection. This is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more detail here). While text is never directly inserted into this hidden contenteditable, the events are observed and used to "play back" editing in the main visible content area. Thus, when moving between the title and body fields (or when changing selection within either), the only hint we get is that the hidden editable element is blurred and immediately refocused. Since we no longer send ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively changed input contexts. Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected text in the title field. To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus messages we would've sent in previous releases). * Platform/spi/ios/UIKitSPI.h: * UIProcess/PageClient.h: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus moves away from and immediately returns to a hidden editable element. * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]): Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request would've still happened anyways in the case where we would previously have sent an ElementDidFocus message. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::elementDidFocus): In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same element, we should still notify the UI process so that it can synchronize state between the application process and kbd. See above for more details. (WebKit::WebPage::elementDidBlur): (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded): LayoutTests: Add a new layout test to verify that we suppress text interactions when focusing an editable element inside an empty, borderless subframe. * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe-expected.txt: Added. * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249006 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-22 Wenson Hsieh Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com https://bugs.webkit.org/show_bug.cgi?id=201023 Reviewed by Ryosuke Niwa. Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the WebKit ChangeLog for more details. Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::calculateClipRects const): 2019-08-22 Kocsen Chung Cherry-pick r248977. rdar://problem/54599960 Do not adjust viewport if editing selection is already visible https://bugs.webkit.org/show_bug.cgi?id=200907 Reviewed by Simon Fraser. Source/WebCore: Test: fast/scrolling/ios/autoscroll-input-when-very-zoomed.html Currently due to scrolling being mostly handled by integers, we are getting issues with rounding errors when trying to adjust the viewport while editing text when we are significantly zoomed in. The real fix would be to start dealing with scrolling with floats/doubles, but until such time, we should early out of adjusting selections that we are certain are currently visible. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible): LayoutTests: * fast/scrolling/ios/autoscroll-input-when-very-zoomed-expected.txt: Added. * fast/scrolling/ios/autoscroll-input-when-very-zoomed.html: Added. * resources/ui-helper.js: (window.UIHelper.immediateZoomToScale): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248977 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Megan Gardner Do not adjust viewport if editing selection is already visible https://bugs.webkit.org/show_bug.cgi?id=200907 Reviewed by Simon Fraser. Test: fast/scrolling/ios/autoscroll-input-when-very-zoomed.html Currently due to scrolling being mostly handled by integers, we are getting issues with rounding errors when trying to adjust the viewport while editing text when we are significantly zoomed in. The real fix would be to start dealing with scrolling with floats/doubles, but until such time, we should early out of adjusting selections that we are certain are currently visible. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible): 2019-08-22 Kocsen Chung Cherry-pick r248997. rdar://problem/54579627 Unreviewed build fix; add a 'final' declaration on shouldOverridePauseDuringRouteChange(). * Modules/mediastream/MediaStream.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248997 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble Unreviewed build fix; add a 'final' declaration on shouldOverridePauseDuringRouteChange(). * Modules/mediastream/MediaStream.h: 2019-08-21 Kocsen Chung Cherry-pick r248978. rdar://problem/54579627 Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. Follow-up to r248962: When the active audio route changes, and the system instructs us to pause, only pause the currently audible sessions. * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeAudioRouteDidChange): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): (WebCore::MediaSessionManageriOS::activeRouteDidChange): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248978 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. Follow-up to r248962: When the active audio route changes, and the system instructs us to pause, only pause the currently audible sessions. * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeAudioRouteDidChange): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): (WebCore::MediaSessionManageriOS::activeRouteDidChange): Deleted. 2019-08-21 Kocsen Chung Cherry-pick r248962. rdar://problem/54579627 Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. When the system notifies us that the active audio route has changed in such a way that necessitates pausing, pause all media sessions, exempting those that are associated with WebRTC, since "pausing" an active audio conference isn't really possible. * Modules/mediastream/MediaStream.h: * platform/audio/PlatformMediaSession.cpp: (WebCore::PlatformMediaSession::shouldOverridePauseDuringRouteChange const): * platform/audio/PlatformMediaSession.h: (WebCore::PlatformMediaSessionClient::shouldOverridePauseDuringRouteChange const): * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeRouteDidChange): (-[WebMediaSessionHelper initWithCallback:]): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248962 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. When the system notifies us that the active audio route has changed in such a way that necessitates pausing, pause all media sessions, exempting those that are associated with WebRTC, since "pausing" an active audio conference isn't really possible. * Modules/mediastream/MediaStream.h: * platform/audio/PlatformMediaSession.cpp: (WebCore::PlatformMediaSession::shouldOverridePauseDuringRouteChange const): * platform/audio/PlatformMediaSession.h: (WebCore::PlatformMediaSessionClient::shouldOverridePauseDuringRouteChange const): * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeRouteDidChange): (-[WebMediaSessionHelper initWithCallback:]): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): 2019-08-21 Kocsen Chung Cherry-pick r248974. rdar://problem/54579634 [Mail] Tapping top of message scrolls back to copied text instead of top of the message https://bugs.webkit.org/show_bug.cgi?id=200999 Reviewed by Wenson Hsieh. Source/WebCore: Test: editing/selection/ios/change-selection-by-tapping-with-existing-selection.html * page/EditorClient.h: (WebCore::EditorClient::shouldAllowSingleClickToChangeSelection const): * page/EventHandler.cpp: (WebCore::EventHandler::handleMousePressEventSingleClick): Instead of encoding platform behaviors in EventHandler, defer to EditorClient. Source/WebKit: In the case where you have a WebCore selection but are not first responder, when you tap the WKWebView to become first responder, EventHandler would bail from setting the selection, assuming UIKit was going to do it. This behavior was introduced in r233311. However, since we are not first responder, UIKit does not change the selection, since it considers the view to not be editable. Fix this by letting WebCore set the selection in this case, as it used to. * WebProcess/WebCoreSupport/WebEditorClient.h: * WebProcess/WebCoreSupport/ios/WebEditorClientIOS.mm: (WebKit::WebEditorClient::shouldAllowSingleClickToChangeSelection const): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::isShowingInputViewForFocusedElement const): Copy the logic from EventHandler, with the added caveat (which fixes the aforementioned behavior) that we will allow EventHandler to change the selection if we don't have a focused node in the UIKit sense, because we know that the platform text interaction code will *not* change the selection if that is the case, so it's up to us. Source/WebKitLegacy/mac: * WebCoreSupport/WebEditorClient.h: * WebCoreSupport/WebEditorClient.mm: (WebEditorClient::shouldAllowSingleClickToChangeSelection const): Copy the existing behavior from EventHandler. We do not fix the bug in WebKitLegacy for a multitude of reasons, primarily because we do not know of any user impact. LayoutTests: * editing/selection/ios/change-selection-by-tapping-with-existing-selection-expected.txt: Added. * editing/selection/ios/change-selection-by-tapping-with-existing-selection.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248974 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Tim Horton [Mail] Tapping top of message scrolls back to copied text instead of top of the message https://bugs.webkit.org/show_bug.cgi?id=200999 Reviewed by Wenson Hsieh. Test: editing/selection/ios/change-selection-by-tapping-with-existing-selection.html * page/EditorClient.h: (WebCore::EditorClient::shouldAllowSingleClickToChangeSelection const): * page/EventHandler.cpp: (WebCore::EventHandler::handleMousePressEventSingleClick): Instead of encoding platform behaviors in EventHandler, defer to EditorClient. 2019-08-21 Kocsen Chung Cherry-pick r248952. rdar://problem/54579626 [iOS] HLS streams disappear from Now Playing when paused on the lock screen https://bugs.webkit.org/show_bug.cgi?id=200951 Reviewed by Eric Carlson. The AVPlayerItemTracks will get recreated on occasion (during seeks, and when changing buffering policy) which can result in a player which no longer reports that it has audio, which in turn results in Now Playing no longer considering the web page to be an eligable now playing application. Bridge this gap by also taking AVPlayerItem.hasEnabledAudio into account when determining whether the player has audio. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248952 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble [iOS] HLS streams disappear from Now Playing when paused on the lock screen https://bugs.webkit.org/show_bug.cgi?id=200951 Reviewed by Eric Carlson. The AVPlayerItemTracks will get recreated on occasion (during seeks, and when changing buffering policy) which can result in a player which no longer reports that it has audio, which in turn results in Now Playing no longer considering the web page to be an eligable now playing application. Bridge this gap by also taking AVPlayerItem.hasEnabledAudio into account when determining whether the player has audio. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged): 2019-08-21 Kocsen Chung Cherry-pick r248944. rdar://problem/54579628 REGRESSION: naver.com - Multiple taps are required to open email https://bugs.webkit.org/show_bug.cgi?id=200979 Patch by Antoine Quint on 2019-08-21 Reviewed by Dean Jackson. The "click" events on subjects in the message list are prevented by preventDefault() being called from a "mouseup" event listener. This shouldn't actually happen, but due to how simulated mouse events are implemented, there is no current distinction between "touchend" and "mouseup" events. It is safe however to opt mail.naver.com out of simulated mouse events altogether. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248944 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Antoine Quint REGRESSION: naver.com - Multiple taps are required to open email https://bugs.webkit.org/show_bug.cgi?id=200979 Reviewed by Dean Jackson. The "click" events on subjects in the message list are prevented by preventDefault() being called from a "mouseup" event listener. This shouldn't actually happen, but due to how simulated mouse events are implemented, there is no current distinction between "touchend" and "mouseup" events. It is safe however to opt mail.naver.com out of simulated mouse events altogether. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): 2019-08-20 Babak Shafiei Cherry-pick r248909. rdar://problem/54543354 Clicking the search icon on ae.com hangs the web content process https://bugs.webkit.org/show_bug.cgi?id=200889 Reviewed by Ryosuke Niwa. Source/WebCore: The hang occurs under FrameSelection::selectionAtSentenceStart, while computing an EditorState to send to the UI process. This act of determining whether the given positon is at the start of sentence entails moving backwards from the start of the current visible selection until the start of a paragraph or sentence is found, using VisiblePosition::previous to iterate backwards through VisiblePositions. However, on this website, VisiblePosition::previous ends up just returning the current position, and we loop infinitely as a result because we never actually move backwards. This happens because VisiblePosition::previous first uses previousVisuallyDistinctCandidate to find a candidate Position before the current position, but when the position is canonicalized to create a VisiblePosition, it is moved back to its original Position as the deep equivalent. In the attached test case (which is representative of the relevant part of the DOM on ae.com), we try to find the previous VisiblePosition from (#c, 0). The previous visually distinct candidate we initially find is (#b, 0), since: 1. The enclosing renderer is a RenderBlock with a non-zero height. 2. The enclosing renderer has no rendered children. 3. The position is at the first editing position in the node (i.e. the span element). However, when canonicalizing the position, we find that neither the upstream nor the downstream position is a candidate because both the upstream and downstream nodes end up well outside of the span (the upstream node ends up being at the start of the body element, and the downstream position ends up right before the start of #c's container). The downstream position is at the end of a text node with a leading newline, it's not a candidate because its last caret offset is less than the length of the text node. As a result, even though the given position (#b, 0) is a candidate itself, its downstream and upstream positions are not. Thus, VisiblePosition::canonicalPosition expands the scope of its candidate positions to the next closest candidate positions; the next candidate position is (#c, 0). Both of these candidates are outside of the containing block, so we (somewhat arbitrarily) break the tie by choosing the next visible position, bringing us back to (#c, 0). There are several ways to fix this, one of which involves fixing the downstream/upstream positions of (#b, 0) so that they no longer jump out of the containing block of #b and cause (#b, 0) to be an invalid visible position despite being a candidate position. This can be achieved by adjusting the heuristic in endsOfNodeAreVisuallyDistinctPositions (used when moving upstream or downstream). Currently, this helper function returns false for #b because they contain a single (non-rendered) whitespace character. Removing this extraneous whitespace character actually causes the problem to stop reproducing, since #b and #c no longer contain any child nodes. This is important because the heuristic in Position::downstream attempts to keep the downstream position within the confines of the enclosing visual boundary, which (currently) ends up being the entire body element because endsOfNodeAreVisuallyDistinctPositions returns false for #b. To avoid this scenario, we teach endsOfNodeAreVisuallyDistinctPositions to treat inline-block containers that are empty (that is, contain no rendered content) but may have children for editing in the same way as inline- block containers that don't have any children; in both scenarios, they may contain a candidate position, so we should treat the ends of the container node as being visually distinct. Doing so causes the downstream position of (#b, 0) to be kept within the immediate containing span element, which then allows (#b, 0) to be a canonical VisiblePosition. Tests: fast/events/focus-anchor-with-tabindex-hang.html editing/selection/modify-backward-inline-block-containers.html * editing/VisiblePosition.cpp: (WebCore::VisiblePosition::previous const): LayoutTests: * editing/selection/modify-backward-inline-block-containers-expected.txt: Added. * editing/selection/modify-backward-inline-block-containers.html: Added. Add a layout test to ensure that the selection may be moved through empty inline-block containers that span the width of the page. * fast/events/focus-anchor-with-tabindex-hang-expected.txt: Added. * fast/events/focus-anchor-with-tabindex-hang.html: Added. Add a layout test to ensure that clicking an empty span under a focusable anchor element moves focus to the anchor element instead of hanging the web content process or hitting a debug assertion. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248909 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-20 Wenson Hsieh Clicking the search icon on ae.com hangs the web content process https://bugs.webkit.org/show_bug.cgi?id=200889 Reviewed by Ryosuke Niwa. The hang occurs under FrameSelection::selectionAtSentenceStart, while computing an EditorState to send to the UI process. This act of determining whether the given positon is at the start of sentence entails moving backwards from the start of the current visible selection until the start of a paragraph or sentence is found, using VisiblePosition::previous to iterate backwards through VisiblePositions. However, on this website, VisiblePosition::previous ends up just returning the current position, and we loop infinitely as a result because we never actually move backwards. This happens because VisiblePosition::previous first uses previousVisuallyDistinctCandidate to find a candidate Position before the current position, but when the position is canonicalized to create a VisiblePosition, it is moved back to its original Position as the deep equivalent. In the attached test case (which is representative of the relevant part of the DOM on ae.com), we try to find the previous VisiblePosition from (#c, 0). The previous visually distinct candidate we initially find is (#b, 0), since: 1. The enclosing renderer is a RenderBlock with a non-zero height. 2. The enclosing renderer has no rendered children. 3. The position is at the first editing position in the node (i.e. the span element). However, when canonicalizing the position, we find that neither the upstream nor the downstream position is a candidate because both the upstream and downstream nodes end up well outside of the span (the upstream node ends up being at the start of the body element, and the downstream position ends up right before the start of #c's container). The downstream position is at the end of a text node with a leading newline, it's not a candidate because its last caret offset is less than the length of the text node. As a result, even though the given position (#b, 0) is a candidate itself, its downstream and upstream positions are not. Thus, VisiblePosition::canonicalPosition expands the scope of its candidate positions to the next closest candidate positions; the next candidate position is (#c, 0). Both of these candidates are outside of the containing block, so we (somewhat arbitrarily) break the tie by choosing the next visible position, bringing us back to (#c, 0). There are several ways to fix this, one of which involves fixing the downstream/upstream positions of (#b, 0) so that they no longer jump out of the containing block of #b and cause (#b, 0) to be an invalid visible position despite being a candidate position. This can be achieved by adjusting the heuristic in endsOfNodeAreVisuallyDistinctPositions (used when moving upstream or downstream). Currently, this helper function returns false for #b because they contain a single (non-rendered) whitespace character. Removing this extraneous whitespace character actually causes the problem to stop reproducing, since #b and #c no longer contain any child nodes. This is important because the heuristic in Position::downstream attempts to keep the downstream position within the confines of the enclosing visual boundary, which (currently) ends up being the entire body element because endsOfNodeAreVisuallyDistinctPositions returns false for #b. To avoid this scenario, we teach endsOfNodeAreVisuallyDistinctPositions to treat inline-block containers that are empty (that is, contain no rendered content) but may have children for editing in the same way as inline- block containers that don't have any children; in both scenarios, they may contain a candidate position, so we should treat the ends of the container node as being visually distinct. Doing so causes the downstream position of (#b, 0) to be kept within the immediate containing span element, which then allows (#b, 0) to be a canonical VisiblePosition. Tests: fast/events/focus-anchor-with-tabindex-hang.html editing/selection/modify-backward-inline-block-containers.html * editing/VisiblePosition.cpp: (WebCore::VisiblePosition::previous const): 2019-08-20 Babak Shafiei Cherry-pick r248902. rdar://problem/54543355 Unsafe usage of CookieStorageObserver from a background thread https://bugs.webkit.org/show_bug.cgi?id=200920 Reviewed by Alex Christensen. Source/WebCore: Unsafe usage of CookieStorageObserver from a background thread. CookieStorageObserver gets constructed / destructed on the main thread. However, CookieStorageObserver::cookiesDidChange() gets called on a background thread and tries to ref |this|. Even though CookieStorageObserver is ThreadSafeRefCounted, this is still unsafe because the CookieStorageObserver destructor may already be running on the main thread when CookieStorageObserver::cookiesDidChange() gets called on the background thread. * platform/network/NetworkStorageSession.h: * platform/network/cocoa/CookieStorageObserver.h: * platform/network/cocoa/CookieStorageObserver.mm: (WebCore::CookieStorageObserver::CookieStorageObserver): (WebCore::CookieStorageObserver::cookiesDidChange): (WebCore::CookieStorageObserver::create): Deleted. * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::cookieStorageObserver const): Source/WebKit: * UIProcess/API/APIHTTPCookieStore.h: * UIProcess/API/Cocoa/APIHTTPCookieStoreCocoa.mm: (API::HTTPCookieStore::startObservingChangesToDefaultUIProcessCookieStore): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248902 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-20 Chris Dumez Unsafe usage of CookieStorageObserver from a background thread https://bugs.webkit.org/show_bug.cgi?id=200920 Reviewed by Alex Christensen. Unsafe usage of CookieStorageObserver from a background thread. CookieStorageObserver gets constructed / destructed on the main thread. However, CookieStorageObserver::cookiesDidChange() gets called on a background thread and tries to ref |this|. Even though CookieStorageObserver is ThreadSafeRefCounted, this is still unsafe because the CookieStorageObserver destructor may already be running on the main thread when CookieStorageObserver::cookiesDidChange() gets called on the background thread. * platform/network/NetworkStorageSession.h: * platform/network/cocoa/CookieStorageObserver.h: * platform/network/cocoa/CookieStorageObserver.mm: (WebCore::CookieStorageObserver::CookieStorageObserver): (WebCore::CookieStorageObserver::cookiesDidChange): (WebCore::CookieStorageObserver::create): Deleted. * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::cookieStorageObserver const): 2019-08-18 Babak Shafiei Cherry-pick r248815. rdar://problem/54454993 [macOS] Emoji with variation selectors are rendered in text style, not emoji style https://bugs.webkit.org/show_bug.cgi?id=200830 Reviewed by Simon Fraser. Source/WebCore: When mapping characters to glyphs, Core Text is giving us the deleted glyph ID, which is unexpected. We were treating it as a valid glyph ID, but it rather should be treated as an invalid glyph ID. Test: fast/text/emoji-variation-selector.html * platform/graphics/mac/GlyphPageMac.cpp: (WebCore::GlyphPage::fill): LayoutTests: * fast/text/emoji-variation-selector-expected-mismatch.html: Added. * fast/text/emoji-variation-selector.html: Added. * platform/win/TestExpectations: Mark as failing on Windows, because it doesn't support variation selectors. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248815 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-16 Myles C. Maxfield [macOS] Emoji with variation selectors are rendered in text style, not emoji style https://bugs.webkit.org/show_bug.cgi?id=200830 Reviewed by Simon Fraser. When mapping characters to glyphs, Core Text is giving us the deleted glyph ID, which is unexpected. We were treating it as a valid glyph ID, but it rather should be treated as an invalid glyph ID. Test: fast/text/emoji-variation-selector.html * platform/graphics/mac/GlyphPageMac.cpp: (WebCore::GlyphPage::fill): 2019-08-18 Babak Shafiei Cherry-pick r248747. rdar://problem/54365278 [Cocoa] Adopt -preventDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248747 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-15 Jer Noble [Cocoa] Adopt -preventDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): 2019-08-18 Babak Shafiei Cherry-pick r248028. rdar://problem/54454990 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-15 Alan Coon Cherry-pick r248722. rdar://problem/54360866 Negative size box with border radius causes hang under WebCore::approximateAsRegion https://bugs.webkit.org/show_bug.cgi?id=200769 Reviewed by Alex Christensen. Source/WebCore: If a box's width or height computes negative the rounded border rect will also be negative. This caused near-infinite loop during rounded border region approximation. Test: fast/css/border-radius-negative-size.html * platform/graphics/RoundedRect.cpp: (WebCore::approximateAsRegion): Bail out if the region is empty (which includes negative sizes). For safety also limit the number of rectangles we generate for corner arc approximation. LayoutTests: * fast/css/border-radius-negative-size-expected.txt: Added. * fast/css/border-radius-negative-size.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248722 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-15 Antti Koivisto Negative size box with border radius causes hang under WebCore::approximateAsRegion https://bugs.webkit.org/show_bug.cgi?id=200769 Reviewed by Alex Christensen. If a box's width or height computes negative the rounded border rect will also be negative. This caused near-infinite loop during rounded border region approximation. Test: fast/css/border-radius-negative-size.html * platform/graphics/RoundedRect.cpp: (WebCore::approximateAsRegion): Bail out if the region is empty (which includes negative sizes). For safety also limit the number of rectangles we generate for corner arc approximation. 2019-08-15 Alan Coon Cherry-pick r248648. rdar://problem/54333931 Focus rings are black https://bugs.webkit.org/show_bug.cgi?id=200593 Patch by Daniel Bates on 2019-08-13 Reviewed by Wenson Hsieh. Work around and make focus rings a pretty blue. * rendering/RenderThemeIOS.mm: (WebCore::RenderThemeIOS::platformFocusRingColor const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248648 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Daniel Bates Focus rings are black https://bugs.webkit.org/show_bug.cgi?id=200593 Reviewed by Wenson Hsieh. Work around and make focus rings a pretty blue. * rendering/RenderThemeIOS.mm: (WebCore::RenderThemeIOS::platformFocusRingColor const): 2019-08-13 Alan Coon Cherry-pick r248604. rdar://problem/54282801 Source/WebCore: Event region collection should take clipping into account https://bugs.webkit.org/show_bug.cgi?id=200668 Reviewed by Simon Fraser. Test: pointerevents/ios/touch-action-region-clip-and-transform.html * rendering/EventRegion.cpp: (WebCore::EventRegionContext::pushClip): (WebCore::EventRegionContext::popClip): Maintain clip rect stack. (WebCore::EventRegionContext::unite): Apply both transforms and clipping. * rendering/EventRegion.h: * rendering/RenderBlock.cpp: * rendering/RenderBox.cpp: (WebCore::RenderBox::pushContentsClip): (WebCore::RenderBox::popContentsClip): Update clip for non-self-painting layers. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::clipToRect): (WebCore::RenderLayer::restoreClip): Update clip for self-painting layers. LayoutTests: Event regions collection should take clipping into account https://bugs.webkit.org/show_bug.cgi?id=200668 Reviewed by Simon Fraser. * pointerevents/ios/touch-action-region-clip-and-transform-expected.txt: Added. * pointerevents/ios/touch-action-region-clip-and-transform.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248604 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Antti Koivisto Event region collection should take clipping into account https://bugs.webkit.org/show_bug.cgi?id=200668 Reviewed by Simon Fraser. Test: pointerevents/ios/touch-action-region-clip-and-transform.html * rendering/EventRegion.cpp: (WebCore::EventRegionContext::pushClip): (WebCore::EventRegionContext::popClip): Maintain clip rect stack. (WebCore::EventRegionContext::unite): Apply both transforms and clipping. * rendering/EventRegion.h: * rendering/RenderBlock.cpp: * rendering/RenderBox.cpp: (WebCore::RenderBox::pushContentsClip): (WebCore::RenderBox::popContentsClip): Update clip for non-self-painting layers. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::clipToRect): (WebCore::RenderLayer::restoreClip): Update clip for self-painting layers. 2019-08-13 Alan Coon Cherry-pick r248597. rdar://problem/54282817 Make sure UniqueIDBDatabaseConnection unregister itself from IDBServer https://bugs.webkit.org/show_bug.cgi?id=200650 Reviewed by Youenn Fablet. We register UniqueIDBDatabaseConnection unconditionally to IDBServer but fail to unregister if UniqueIDBDatabase of UniqueIDBDatabaseConnection is gone. * Modules/indexeddb/server/UniqueIDBDatabaseConnection.cpp: (WebCore::IDBServer::UniqueIDBDatabaseConnection::UniqueIDBDatabaseConnection): (WebCore::IDBServer::UniqueIDBDatabaseConnection::~UniqueIDBDatabaseConnection): * Modules/indexeddb/server/UniqueIDBDatabaseConnection.h: (WebCore::IDBServer::UniqueIDBDatabaseConnection::server): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.cpp: (WebCore::IDBServer::UniqueIDBDatabaseTransaction::UniqueIDBDatabaseTransaction): (WebCore::IDBServer::UniqueIDBDatabaseTransaction::~UniqueIDBDatabaseTransaction): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248597 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Sihui Liu Make sure UniqueIDBDatabaseConnection unregister itself from IDBServer https://bugs.webkit.org/show_bug.cgi?id=200650 Reviewed by Youenn Fablet. We register UniqueIDBDatabaseConnection unconditionally to IDBServer but fail to unregister if UniqueIDBDatabase of UniqueIDBDatabaseConnection is gone. * Modules/indexeddb/server/UniqueIDBDatabaseConnection.cpp: (WebCore::IDBServer::UniqueIDBDatabaseConnection::UniqueIDBDatabaseConnection): (WebCore::IDBServer::UniqueIDBDatabaseConnection::~UniqueIDBDatabaseConnection): * Modules/indexeddb/server/UniqueIDBDatabaseConnection.h: (WebCore::IDBServer::UniqueIDBDatabaseConnection::server): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.cpp: (WebCore::IDBServer::UniqueIDBDatabaseTransaction::UniqueIDBDatabaseTransaction): (WebCore::IDBServer::UniqueIDBDatabaseTransaction::~UniqueIDBDatabaseTransaction): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h: 2019-08-13 Alan Coon Cherry-pick r248499. rdar://problem/54237800 Can’t sort videos on a YouTube channel page on iPad https://bugs.webkit.org/show_bug.cgi?id=200573 Reviewed by Darin Adler. Add a quirk to make touch events non-cancelable (preventDefault() does nothing). * page/Quirks.cpp: (WebCore::Quirks::shouldMakeTouchEventNonCancelableForTarget const): * page/Quirks.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248499 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Antti Koivisto Can’t sort videos on a YouTube channel page on iPad https://bugs.webkit.org/show_bug.cgi?id=200573 Reviewed by Darin Adler. Add a quirk to make touch events non-cancelable (preventDefault() does nothing). * page/Quirks.cpp: (WebCore::Quirks::shouldMakeTouchEventNonCancelableForTarget const): * page/Quirks.h: 2019-08-13 Alan Coon Cherry-pick r248513. rdar://problem/54237806 Accessibility client cannot navigate to internal links targets on iOS. https://bugs.webkit.org/show_bug.cgi?id=200559 Patch by Andres Gonzalez on 2019-08-10 Reviewed by Zalan Bujtas. Source/WebCore: The cause of the problem on iOS is that AccessibilityObject::firstAccessibleObjectFromNode used in AccessibilityRenderObject::linkedUIElements may return an object that is ignored by accessibility clients on iOS, and thus the client would not track the target of an internal link. This change ensures that accessibilityLinkedElement will return a valid accessibility element to the client, if it is exists. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::firstAccessibleObjectFromNode): (WebCore::firstAccessibleObjectFromNode): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityLinkedElement]): LayoutTests: Extneded this test to not only check that internal links expose their target, but also that the target is an accessible element. Added a second test case where the target is contained in a grouping element. * accessibility/ios-simulator/internal-link-expected.txt: * accessibility/ios-simulator/internal-link.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248513 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Andres Gonzalez Accessibility client cannot navigate to internal links targets on iOS. https://bugs.webkit.org/show_bug.cgi?id=200559 Reviewed by Zalan Bujtas. The cause of the problem on iOS is that AccessibilityObject::firstAccessibleObjectFromNode used in AccessibilityRenderObject::linkedUIElements may return an object that is ignored by accessibility clients on iOS, and thus the client would not track the target of an internal link. This change ensures that accessibilityLinkedElement will return a valid accessibility element to the client, if it is exists. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::firstAccessibleObjectFromNode): (WebCore::firstAccessibleObjectFromNode): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityLinkedElement]): 2019-08-13 Alan Coon Cherry-pick r248514. rdar://problem/54236213 REGRESSION (r245974): Missing content on habitburger.com, amazon.com https://bugs.webkit.org/show_bug.cgi?id=200618 rdar://problem/53920224 Reviewed by Zalan Bujtas. Source/WebCore: In r245974 TileController::adjustTileCoverageRect() started to intersect the coverage rect with the bounds of the layer, which is wrong because this coverage rect is passed down to descendant layers, and they may project outside the bounds of this tiled layer. This caused missing dropdowns on amazon.com, and a missing menu on habitburger.com on iPhone. The fix is to just not do the intersection with the bounds. TileGrid::getTileIndexRangeForRect() already ensures that we never make tiles outside the bounds of a TileController. Test: compositing/backing/layer-outside-tiled-parent.html * platform/graphics/ca/TileController.cpp: (WebCore::TileController::adjustTileCoverageRect): * platform/graphics/ca/TileGrid.cpp: (WebCore::TileGrid::ensureTilesForRect): LayoutTests: * compositing/backing/layer-outside-tiled-parent-expected.txt: Added. * compositing/backing/layer-outside-tiled-parent.html: Added. * platform/ios-wk2/compositing/backing/layer-outside-tiled-parent-expected.txt: Added. * tiled-drawing/tile-coverage-iframe-to-zero-coverage-expected.txt: * tiled-drawing/tiled-backing-in-window-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248514 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Simon Fraser REGRESSION (r245974): Missing content on habitburger.com, amazon.com https://bugs.webkit.org/show_bug.cgi?id=200618 rdar://problem/53920224 Reviewed by Zalan Bujtas. In r245974 TileController::adjustTileCoverageRect() started to intersect the coverage rect with the bounds of the layer, which is wrong because this coverage rect is passed down to descendant layers, and they may project outside the bounds of this tiled layer. This caused missing dropdowns on amazon.com, and a missing menu on habitburger.com on iPhone. The fix is to just not do the intersection with the bounds. TileGrid::getTileIndexRangeForRect() already ensures that we never make tiles outside the bounds of a TileController. Test: compositing/backing/layer-outside-tiled-parent.html * platform/graphics/ca/TileController.cpp: (WebCore::TileController::adjustTileCoverageRect): * platform/graphics/ca/TileGrid.cpp: (WebCore::TileGrid::ensureTilesForRect): 2019-08-13 Alan Coon Cherry-pick r248301. rdar://problem/54237793 Adopt -expectMinimumUpcomingSampleBufferPresentationTime: https://bugs.webkit.org/show_bug.cgi?id=200457 Reviewed by Eric Carlson. Source/WebCore: Test: media/media-source/media-source-minimumupcomingpresentationtime.html Adopt a new API vended by AVSampleBufferDisplayLayer, piped from SourceBuffer down through SourceBufferPrivate to SourceBufferPrivateAVFObjC. This value should be reset and updated when new samples are appended. * Modules/mediasource/SourceBuffer.cpp: (WebCore::SourceBuffer::sourceBufferPrivateDidReceiveSample): (WebCore::SourceBuffer::provideMediaData): (WebCore::SourceBuffer::updateMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::resetMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBuffer::setMaximumQueueDepthForTrackID): * Modules/mediasource/SourceBuffer.h: * platform/graphics/SourceBufferPrivate.h: (WebCore::SourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::clearMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::enqueuedSamplesForTrackID): (WebCore::SourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBufferPrivate::setMaximumQueueDepthForTrackID): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivateAVFObjC::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivateAVFObjC::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.cpp: (WebCore::MockSourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::MockSourceBufferPrivate::setMaximumQueueDepthForTrackID): (WebCore::MockSourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::MockSourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::MockSourceBufferPrivate::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.h: * testing/Internals.cpp: (WebCore::Internals::minimumUpcomingPresentationTimeForTrackID): (WebCore::Internals::setMaximumQueueDepthForTrackID): * testing/Internals.h: * testing/Internals.idl: LayoutTests: * media/media-source/media-source-minimumupcomingpresentationtime-expected.txt: Added. * media/media-source/media-source-minimumupcomingpresentationtime.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248301 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Jer Noble Adopt -expectMinimumUpcomingSampleBufferPresentationTime: https://bugs.webkit.org/show_bug.cgi?id=200457 Reviewed by Eric Carlson. Test: media/media-source/media-source-minimumupcomingpresentationtime.html Adopt a new API vended by AVSampleBufferDisplayLayer, piped from SourceBuffer down through SourceBufferPrivate to SourceBufferPrivateAVFObjC. This value should be reset and updated when new samples are appended. * Modules/mediasource/SourceBuffer.cpp: (WebCore::SourceBuffer::sourceBufferPrivateDidReceiveSample): (WebCore::SourceBuffer::provideMediaData): (WebCore::SourceBuffer::updateMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::resetMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBuffer::setMaximumQueueDepthForTrackID): * Modules/mediasource/SourceBuffer.h: * platform/graphics/SourceBufferPrivate.h: (WebCore::SourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::clearMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::enqueuedSamplesForTrackID): (WebCore::SourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBufferPrivate::setMaximumQueueDepthForTrackID): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivateAVFObjC::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivateAVFObjC::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.cpp: (WebCore::MockSourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::MockSourceBufferPrivate::setMaximumQueueDepthForTrackID): (WebCore::MockSourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::MockSourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::MockSourceBufferPrivate::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.h: * testing/Internals.cpp: (WebCore::Internals::minimumUpcomingPresentationTimeForTrackID): (WebCore::Internals::setMaximumQueueDepthForTrackID): * testing/Internals.h: * testing/Internals.idl: 2019-08-13 Alan Coon Cherry-pick r248295. rdar://problem/54237762 REGRESSION: Cannot tap on any buttons on m.naver.com home screen on iPad https://bugs.webkit.org/show_bug.cgi?id=200466 Reviewed by Zalan Bujtas. The page calls preventDefault() for a mouse event generated by a site specific quirk. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): Disable the quirk for the "m." subdomain. This is a mobile site that don't need or expect them. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248295 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Antti Koivisto REGRESSION: Cannot tap on any buttons on m.naver.com home screen on iPad https://bugs.webkit.org/show_bug.cgi?id=200466 Reviewed by Zalan Bujtas. The page calls preventDefault() for a mouse event generated by a site specific quirk. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): Disable the quirk for the "m." subdomain. This is a mobile site that don't need or expect them. 2019-08-13 Alan Coon Cherry-pick r248292. rdar://problem/54236220 [iPadOS] Unable to increase zoom level on Google using the Aa menu https://bugs.webkit.org/show_bug.cgi?id=200453 Reviewed by Tim Horton. Source/WebCore: Makes a couple of minor adjustments to how layout size scale factor is handled in ViewportConfiguration, to address some scenarios in which adjusting WKWebView's _viewScale does not have any apparent effect on the page. See changes below for more detail. Tests: fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): When the page is either zoomed in or zoomed out using _viewScale, let the specified initial scale take precedence over the scale computed by fitting the content width to the view width, or the scale computed by fitting the content height to the view height. This avoids a scenario in which nothing happens when increasing view scale in a responsively designed web page that has a fixed minimum width. Before this change, when computing the initial scale at a view scale that would not allow the entire content width of the page to fit within the viewport, the new initial scale would remain unchanged if the initial scale in the meta viewport is not also set to 1, because a new initial scale would be computed in ViewportConfiguration::initialScaleFromSize to accomodate for the entire content width. Our new behavior allows us to zoom into the page, even if doing so would cause horizontal scrolling. (WebCore::ViewportConfiguration::updateConfiguration): When the page is either zoomed in or zoomed out using _viewScale and the default viewport configuration has a fixed width (e.g. on iPhone), then adjust the width of the default viewport configuration to account for the _viewScale. For example, the default width of a viewport-less web page is 980px on iPhone; at a view scale of 2, this would become 490px instead, and at 0.5 view scale, it would become 1960px. This ensures that on iPhone, for web pages without a meta viewport, changing the view scale still changes the layout and initial scale of the web page. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::layoutSizeIsExplicitlyScaled const): LayoutTests: Adds a couple of layout tests (with device-specific expectations) to verify that the two scenarios targeted by this change are fixed. * fast/viewport/ios/non-responsive-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html: Added. Verifies that, for a page with no viewport meta tag (where we fall back to a fixed 980px viewport on iPhone), changing view scale still changes page scale and window size. * fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html: Added. Verifies that, for a page with a responsive meta viewport tag containing a fixed-width element that forces a minimum width for the page, setting the view scale such that the page scrolls horizontally (2.5) doesn't result in the initial scale being adjusted back to the maximum scale that would accomodate the full contents of the page (2). * platform/ipad/fast/viewport/ios/non-responsive-viewport-after-changing-view-scale-expected.txt: Added. * platform/ipad/fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale-expected.txt: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248292 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Wenson Hsieh [iPadOS] Unable to increase zoom level on Google using the Aa menu https://bugs.webkit.org/show_bug.cgi?id=200453 Reviewed by Tim Horton. Makes a couple of minor adjustments to how layout size scale factor is handled in ViewportConfiguration, to address some scenarios in which adjusting WKWebView's _viewScale does not have any apparent effect on the page. See changes below for more detail. Tests: fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): When the page is either zoomed in or zoomed out using _viewScale, let the specified initial scale take precedence over the scale computed by fitting the content width to the view width, or the scale computed by fitting the content height to the view height. This avoids a scenario in which nothing happens when increasing view scale in a responsively designed web page that has a fixed minimum width. Before this change, when computing the initial scale at a view scale that would not allow the entire content width of the page to fit within the viewport, the new initial scale would remain unchanged if the initial scale in the meta viewport is not also set to 1, because a new initial scale would be computed in ViewportConfiguration::initialScaleFromSize to accomodate for the entire content width. Our new behavior allows us to zoom into the page, even if doing so would cause horizontal scrolling. (WebCore::ViewportConfiguration::updateConfiguration): When the page is either zoomed in or zoomed out using _viewScale and the default viewport configuration has a fixed width (e.g. on iPhone), then adjust the width of the default viewport configuration to account for the _viewScale. For example, the default width of a viewport-less web page is 980px on iPhone; at a view scale of 2, this would become 490px instead, and at 0.5 view scale, it would become 1960px. This ensures that on iPhone, for web pages without a meta viewport, changing the view scale still changes the layout and initial scale of the web page. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::layoutSizeIsExplicitlyScaled const): 2019-08-13 Alan Coon Cherry-pick r248188. rdar://problem/54237663 Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Patch by Andres Gonzalez on 2019-08-02 Reviewed by Chris Fleizach. Explicitly returning BOOL to avoid error in some compiler configurations. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248188 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Andres Gonzalez Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Reviewed by Chris Fleizach. Explicitly returning BOOL to avoid error in some compiler configurations. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): 2019-08-13 Alan Coon Cherry-pick r248169. rdar://problem/54237663 Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Patch by Andres Gonzalez on 2019-08-02 Reviewed by Chris Fleizach. Source/WebCore: Test: accessibility/ios-simulator/element-in-table-cell.html Added _accessibilityIsInTableCell needed for iOS accessibility client. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): Tools: Glue code to exercise new method [WebAccessibilityObjectWrapper _accessibilityIsInTableCell]. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::isInTableCell const): * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::isInTableCell const): LayoutTests: New test that exercises [WebAccessibilityObjectWrapper _accessibilityIsInTableCell]. * accessibility/ios-simulator/element-in-table-cell-expected.txt: Added. * accessibility/ios-simulator/element-in-table-cell.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248169 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Andres Gonzalez Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Reviewed by Chris Fleizach. Test: accessibility/ios-simulator/element-in-table-cell.html Added _accessibilityIsInTableCell needed for iOS accessibility client. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): 2019-08-12 Alan Coon Cherry-pick r248502. rdar://problem/54130670 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-12 Alan Coon Cherry-pick r248501. rdar://problem/54130614 [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-12 Alan Coon Cherry-pick r248494. rdar://problem/54171876 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-12 Alan Coon Cherry-pick r248491. rdar://problem/54130636 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-12 Alan Coon Cherry-pick r248471. rdar://problem/54130624 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-12 Alan Coon Cherry-pick r248463. rdar://problem/54139782 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-12 Alan Coon Cherry-pick r248438. rdar://problem/54093220 [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-12 Alan Coon Cherry-pick r248410. rdar://problem/54084721 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-12 Alan Coon Cherry-pick r248368. rdar://problem/54037153 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-12 Alan Coon Cherry-pick r248265. rdar://problem/54017842 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. 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-12 Alan Coon Cherry-pick r248148. rdar://problem/54017840 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-12 Alan Coon Cherry-pick r248112. rdar://problem/53836593 [Text autosizing] [iPadOS] Add targeted hacks to address some remaining text autosizing issues https://bugs.webkit.org/show_bug.cgi?id=200271 Reviewed by Zalan Bujtas. Source/WebCore: Makes some targeted adjustments to the text autosizing heuristic, to ensure compatibility with several high- profile websites. See changes below for more detail. Tests: fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases.html fast/text-autosizing/ios/idempotentmode/line-height-boosting.html * css/StyleResolver.cpp: (WebCore::StyleResolver::adjustRenderStyleForTextAutosizing): Avoid clipped sidebar links on sohu.com by not performing line-height boosting in the case where the element probably has a small, fixed number of lines. See below for more detail. Additionally, don't attempt to adjust the line height using the boosted font size, in the case where the element is not a candidate for idempotent text autosizing. * rendering/style/RenderStyle.cpp: (WebCore::RenderStyle::isIdempotentTextAutosizingCandidate const): Make various targeted hacks to fix a few websites: - Add a special case for top navigation bar links on yandex.ru, where line height greatly exceeds the specified font size. - Avoid boosting some related video links on v.youku.com by considering the line-clamp CSS property when determining the maximum number of lines of text an element is expected to contain. - Avoid boosting some front page links on asahi.com, which have non-repeating background images. - Add several other adjustments to more aggressively boost pieces of text on Google search results, such as taking the `word-break` CSS property into account. The bottom few pixels of sidebar links on naver.com are also no longer clipped after these changes. * rendering/style/TextSizeAdjustment.cpp: (WebCore::AutosizeStatus::probablyContainsASmallFixedNumberOfLines): Pulls out a piece of the heuristic added to fix sephora.com in r247467 out into a separate helper method. To recap, this heuristic identifies elements with both a fixed height and fixed line height, for which the fixed height is close to an integer multiple of the line height. Also makes several small tweaks in the process: (1) change the max difference between fixed line height and font size from 6 to 5 to ensure that some multiline caption text on Google search results is boosted, and (2) replace usages of `lineHeight()` with `specifiedLineHeight()`, which current prevents this function from being truly idempotent. (WebCore::AutosizeStatus::updateStatus): * rendering/style/TextSizeAdjustment.h: LayoutTests: Add tests to cover some changes to line height boosting and the idempotent text autosizing candidate heuristic. * fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases-expected.txt: Added. * fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases.html: Added. * fast/text-autosizing/ios/idempotentmode/line-height-boosting-expected.txt: * fast/text-autosizing/ios/idempotentmode/line-height-boosting.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248112 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-01 Wenson Hsieh [Text autosizing] [iPadOS] Add targeted hacks to address some remaining text autosizing issues https://bugs.webkit.org/show_bug.cgi?id=200271 Reviewed by Zalan Bujtas. Makes some targeted adjustments to the text autosizing heuristic, to ensure compatibility with several high- profile websites. See changes below for more detail. Tests: fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases.html fast/text-autosizing/ios/idempotentmode/line-height-boosting.html * css/StyleResolver.cpp: (WebCore::StyleResolver::adjustRenderStyleForTextAutosizing): Avoid clipped sidebar links on sohu.com by not performing line-height boosting in the case where the element probably has a small, fixed number of lines. See below for more detail. Additionally, don't attempt to adjust the line height using the boosted font size, in the case where the element is not a candidate for idempotent text autosizing. * rendering/style/RenderStyle.cpp: (WebCore::RenderStyle::isIdempotentTextAutosizingCandidate const): Make various targeted hacks to fix a few websites: - Add a special case for top navigation bar links on yandex.ru, where line height greatly exceeds the specified font size. - Avoid boosting some related video links on v.youku.com by considering the line-clamp CSS property when determining the maximum number of lines of text an element is expected to contain. - Avoid boosting some front page links on asahi.com, which have non-repeating background images. - Add several other adjustments to more aggressively boost pieces of text on Google search results, such as taking the `word-break` CSS property into account. The bottom few pixels of sidebar links on naver.com are also no longer clipped after these changes. * rendering/style/TextSizeAdjustment.cpp: (WebCore::AutosizeStatus::probablyContainsASmallFixedNumberOfLines): Pulls out a piece of the heuristic added to fix sephora.com in r247467 out into a separate helper method. To recap, this heuristic identifies elements with both a fixed height and fixed line height, for which the fixed height is close to an integer multiple of the line height. Also makes several small tweaks in the process: (1) change the max difference between fixed line height and font size from 6 to 5 to ensure that some multiline caption text on Google search results is boosted, and (2) replace usages of `lineHeight()` with `specifiedLineHeight()`, which current prevents this function from being truly idempotent. (WebCore::AutosizeStatus::updateStatus): * rendering/style/TextSizeAdjustment.h: 2019-08-12 Alan Coon Cherry-pick r248095. rdar://problem/53820658 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-08-12 Alan Coon Cherry-pick r248447. rdar://problem/54218162 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-06 Alan Coon Apply patch. rdar://problem/53992160 2019-08-06 Per Arne Vollan [Win] Fix AppleWin build https://bugs.webkit.org/show_bug.cgi?id=200414 Reviewed by Brent Fulgham. * CMakeLists.txt: * PlatformPlayStation.cmake: * PlatformWPE.cmake: * PlatformWin.cmake: 2019-08-01 Alan Coon Apply patch. rdar://problem/53764238 2019-08-01 Ryosuke Niwa The maximum subframe count check should not be skipped for empty URLs. https://bugs.webkit.org/show_bug.cgi?id=200032 Based on the patch by Sergei Glazunov (r247924). Move the check closer to the actual frame creation code in loadSubframe. Tests: fast/dom/connected-subframe-counter-overflow.html * dom/Document.cpp: (WebCore::Document::prepareForDestruction): Assert that all child frames have been detached. * html/HTMLFrameElementBase.cpp: (WebCore::HTMLFrameElementBase::isURLAllowed const): * loader/SubframeLoader.cpp: (WebCore::SubframeLoader::loadSubframe): Added the check here. * page/Frame.cpp: (WebCore::Frame::isURLAllowed const): 2019-07-31 Alan Coon Cherry-pick r248080. rdar://problem/53788956 [ContentChangeObserver] twitch.tv video controls do not always respond to taps in fullscreen https://bugs.webkit.org/show_bug.cgi?id=200309 Reviewed by Simon Fraser. Source/WebCore: Do not consider an element visible if it is not a descendant of the active fullscreen element. This patch fixes the cases when the user taps on a button in fullscreen mode while the non-fullscreen content is being mutated and the ContentChangeObserver mistakenly registers it as a valid, actionable change and as a result we don't fire the click event (stay at hover). Test: fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode.html * page/ios/ContentChangeObserver.cpp: (WebCore::fullscreenElement): (WebCore::ContentChangeObserver::isVisuallyHidden): LayoutTests: * fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode-expected.txt: Added. * fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode.html: Added. * platform/ios/TestExpectations: Fullscreen API is not yet enabled on iOS. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248080 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Zalan Bujtas [ContentChangeObserver] twitch.tv video controls do not always respond to taps in fullscreen https://bugs.webkit.org/show_bug.cgi?id=200309 Reviewed by Simon Fraser. Do not consider an element visible if it is not a descendant of the active fullscreen element. This patch fixes the cases when the user taps on a button in fullscreen mode while the non-fullscreen content is being mutated and the ContentChangeObserver mistakenly registers it as a valid, actionable change and as a result we don't fire the click event (stay at hover). Test: fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode.html * page/ios/ContentChangeObserver.cpp: (WebCore::fullscreenElement): (WebCore::ContentChangeObserver::isVisuallyHidden): 2019-07-31 Alan Coon Cherry-pick r248079. rdar://problem/53788988 [iPadOS] Enable simulated mouse events on iqiyi.com to fix the video controls https://bugs.webkit.org/show_bug.cgi?id=200322 rdar://problem/53235709 Reviewed by Wenson Hsieh. iqiyi.com needs to get mouseMove events for dragging the video scrubber to work. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248079 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Alan Coon Cherry-pick r248071. rdar://problem/53789003 Use CTFontCreateForCharactersWithLanguageAndOption if available instead of CTFontCreateForCharactersWithLanguage https://bugs.webkit.org/show_bug.cgi?id=200241 Source/WebCore: Reviewed by Myles C. Maxfield. We can use CTFontCreateForCharactersWithLanguageAndOption instead of CTFontCreateForCharactersWithLanguage as it allows setting more easily the fallback option. This allows us to never fallback to user installed fonts. In such a case, we no longer need to wrap the fonts to change the fallback option. We also prewarm the fonts with the same SPI and use system fallback as the default value. Covered by existing tests. * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::preparePlatformFont): (WebCore::lookupFallbackFont): (WebCore::FontCache::systemFallbackForCharacters): (WebCore::FontCache::prewarm): (WebCore::fontFamiliesForPrewarming): Source/WebCore/PAL: Reviewed by Myles C. Maxfield. Add new SPI. * pal/spi/cocoa/CoreTextSPI.h: Source/WTF: Reviewed by Myles C. Maxfield. * wtf/Platform.h: Add macro to enable/disable new SPI. LayoutTests: We update the tests to flush font caches as otherwise some debug asserts would be hit. This is due to changing the user installed font runtime flag while browsing which is not a typical situation. Reviewed by Myles C. Maxfield. * fast/text/user-installed-fonts/extended-character-with-user-font.html: * fast/text/user-installed-fonts/extended-character.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248071 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Youenn Fablet Use CTFontCreateForCharactersWithLanguageAndOption if available instead of CTFontCreateForCharactersWithLanguage https://bugs.webkit.org/show_bug.cgi?id=200241 Reviewed by Myles C. Maxfield. We can use CTFontCreateForCharactersWithLanguageAndOption instead of CTFontCreateForCharactersWithLanguage as it allows setting more easily the fallback option. This allows us to never fallback to user installed fonts. In such a case, we no longer need to wrap the fonts to change the fallback option. We also prewarm the fonts with the same SPI and use system fallback as the default value. Covered by existing tests. * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::preparePlatformFont): (WebCore::lookupFallbackFont): (WebCore::FontCache::systemFallbackForCharacters): (WebCore::FontCache::prewarm): (WebCore::fontFamiliesForPrewarming): 2019-07-31 Alan Coon Cherry-pick r248046. rdar://problem/53788952 Owners of MultiChannelResampler should make sure that the output bus given to it has the same number of channels https://bugs.webkit.org/show_bug.cgi?id=200248 Reviewed by Eric Carlson. Source/WebCore: When a track's number of channels changes, MediaStreamAudioSourceNode is expected to update its MultiChannelResampler and its output number of channels. MultiChannelResampler expects to have the same number of channels as the output but it is not always the case since the channel numbers are changed in different threads and locks do not help there. Instead, whenever detecting that the number of channels do not match, render silence and wait for the next rendering where the number of channels should again match. Add internals API to change the number of channels from 2 to 1 or 1 to 2 to allow testing that code path (iOS only as MacOS audio capture is in UIProcess). Covered by updated test. * Modules/webaudio/MediaElementAudioSourceNode.cpp: (WebCore::MediaElementAudioSourceNode::process): * Modules/webaudio/MediaStreamAudioSourceNode.cpp: (WebCore::MediaStreamAudioSourceNode::process): * platform/audio/MultiChannelResampler.cpp: (WebCore::MultiChannelResampler::process): * platform/mediastream/RealtimeMediaSource.h: * platform/mediastream/mac/MockRealtimeAudioSourceMac.mm: (WebCore::MockRealtimeAudioSourceMac::reconfigure): * platform/mock/MockRealtimeAudioSource.cpp: (WebCore::MockRealtimeAudioSource::setChannelCount): * platform/mock/MockRealtimeAudioSource.h: (isType): * platform/mock/MockRealtimeVideoSource.h: * testing/Internals.cpp: (WebCore::Internals::setMockAudioTrackChannelNumber): * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/mediastream/getUserMedia-webaudio-expected.txt: * fast/mediastream/getUserMedia-webaudio.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248046 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Youenn Fablet Owners of MultiChannelResampler should make sure that the output bus given to it has the same number of channels https://bugs.webkit.org/show_bug.cgi?id=200248 Reviewed by Eric Carlson. When a track's number of channels changes, MediaStreamAudioSourceNode is expected to update its MultiChannelResampler and its output number of channels. MultiChannelResampler expects to have the same number of channels as the output but it is not always the case since the channel numbers are changed in different threads and locks do not help there. Instead, whenever detecting that the number of channels do not match, render silence and wait for the next rendering where the number of channels should again match. Add internals API to change the number of channels from 2 to 1 or 1 to 2 to allow testing that code path (iOS only as MacOS audio capture is in UIProcess). Covered by updated test. * Modules/webaudio/MediaElementAudioSourceNode.cpp: (WebCore::MediaElementAudioSourceNode::process): * Modules/webaudio/MediaStreamAudioSourceNode.cpp: (WebCore::MediaStreamAudioSourceNode::process): * platform/audio/MultiChannelResampler.cpp: (WebCore::MultiChannelResampler::process): * platform/mediastream/RealtimeMediaSource.h: * platform/mediastream/mac/MockRealtimeAudioSourceMac.mm: (WebCore::MockRealtimeAudioSourceMac::reconfigure): * platform/mock/MockRealtimeAudioSource.cpp: (WebCore::MockRealtimeAudioSource::setChannelCount): * platform/mock/MockRealtimeAudioSource.h: (isType): * platform/mock/MockRealtimeVideoSource.h: * testing/Internals.cpp: (WebCore::Internals::setMockAudioTrackChannelNumber): * testing/Internals.h: * testing/Internals.idl: 2019-07-31 Alan Coon Cherry-pick r248037. rdar://problem/53764079 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-07-31 Alan Coon Cherry-pick r248024. rdar://problem/53764047 WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey should use local heap objects for replies https://bugs.webkit.org/show_bug.cgi?id=200179 Reviewed by Brent Fulgham. Based on the patch by Jiewen Tan. WorkerGlobalScope::wrapCryptoKey and WorkerGlobalScope::unwrapCryptoKey had a bug that they could exit the function before the main thread had finished writing to the result vector passed in to these functions when the worker's runloop receives MessageQueueTerminated before the main thread finishes writing. Fixed the bug by creating a new temporary Vector inside a ThreadSafeRefCounted object shared between the main thread and the worker thread, which extends the lifetime of the Vector until when the worker thread receives the result or when the main thread finishes writing to the Vector, whichever happens last. Unfortunately no new tests since there is no reproducible test case, and this crash is highly racy. * workers/WorkerGlobalScope.cpp: (WebCore::CryptoBufferContainer): Added. (WebCore::CryptoBufferContainer::create): Added. (WebCore::CryptoBufferContainer::buffer): Added. (WebCore::WorkerGlobalScope::wrapCryptoKey): (WebCore::WorkerGlobalScope::unwrapCryptoKey): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248024 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Ryosuke Niwa WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey should use local heap objects for replies https://bugs.webkit.org/show_bug.cgi?id=200179 Reviewed by Brent Fulgham. Based on the patch by Jiewen Tan. WorkerGlobalScope::wrapCryptoKey and WorkerGlobalScope::unwrapCryptoKey had a bug that they could exit the function before the main thread had finished writing to the result vector passed in to these functions when the worker's runloop receives MessageQueueTerminated before the main thread finishes writing. Fixed the bug by creating a new temporary Vector inside a ThreadSafeRefCounted object shared between the main thread and the worker thread, which extends the lifetime of the Vector until when the worker thread receives the result or when the main thread finishes writing to the Vector, whichever happens last. Unfortunately no new tests since there is no reproducible test case, and this crash is highly racy. * workers/WorkerGlobalScope.cpp: 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: (WebCore::CryptoBufferContainer): Added. (WebCore::CryptoBufferContainer::create): Added. (WebCore::CryptoBufferContainer::buffer): Added. (WebCore::WorkerGlobalScope::wrapCryptoKey): (WebCore::WorkerGlobalScope::unwrapCryptoKey): 2019-07-31 Alan Coon Cherry-pick r248018. rdar://problem/53764057 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-07-31 Alan Coon Cherry-pick r247934. rdar://problem/53764085 MediaSource.isTypeSupported claims FLAC-in-MP4 support on iOS and macOS, but plays silence https://bugs.webkit.org/show_bug.cgi?id=198583 Reviewed by Maciej Stachowiak. * platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.h: (WebCore::AVStreamDataParserMIMETypeCache::canDecodeType): Use anParseExtendedMIMEType: when it is available. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247934 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Eric Carlson MediaSource.isTypeSupported claims FLAC-in-MP4 support on iOS and macOS, but plays silence https://bugs.webkit.org/show_bug.cgi?id=198583 Reviewed by Maciej Stachowiak. * platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.h: (WebCore::AVStreamDataParserMIMETypeCache::canDecodeType): Use anParseExtendedMIMEType: when it is available. 2019-07-31 Alan Coon Cherry-pick r247915. rdar://problem/53764061 Force Reveal to always lookup from menu https://bugs.webkit.org/show_bug.cgi?id=200186 2019-07-31 Simon Fraser [iPadOS] Enable simulated mouse events on iqiyi.com to fix the video controls https://bugs.webkit.org/show_bug.cgi?id=200322 rdar://problem/53235709 Reviewed by Wenson Hsieh. iqiyi.com needs to get mouseMove events for dragging the video scrubber to work. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): Reviewed by Tim Horton. We currently only have the 'lookup' menu item, so we should always force the 'lookup' action from it. Reveal is not currently testable. * editing/cocoa/DictionaryLookup.mm: (WebCore::showPopupOrCreateAnimationController): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247915 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Megan Gardner Force Reveal to always lookup from menu https://bugs.webkit.org/show_bug.cgi?id=200186 Reviewed by Tim Horton. We currently only have the 'lookup' menu item, so we should always force the 'lookup' action from it. Reveal is not currently testable. * editing/cocoa/DictionaryLookup.mm: (WebCore::showPopupOrCreateAnimationController): 2019-07-31 Alan Coon Cherry-pick r247912. rdar://problem/53764200 REGRESSION (r246899): Subtitles show twice when controls show/hide on hulu.com https://bugs.webkit.org/show_bug.cgi?id=200187 rdar://problem/53511121 Reviewed by Zalan Bujtas. Source/WebCore: When a layer that painted into shared backing moved, we'd fail to repaint its old position because the RenderLayer's repaint rects are cleared via BackingSharingState::updateBeforeDescendantTraversal(). Recomputing repaint rects is expensive, so we only want to do it when necessary, which is for layers that start and stop sharing (going into and out of compositing already recomputes them). So add logic to RenderLayerBacking::setBackingSharingLayers() that recomputes repaint rects on layers that will no longer use shared backing, and those that are newly using shared backing. Test: compositing/shared-backing/backing-sharing-repaint.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::setBackingProviderLayer): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::setBackingSharingLayers): * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::BackingSharingState::appendSharingLayer): (WebCore::RenderLayerCompositor::updateBacking): LayoutTests: * compositing/shared-backing/backing-sharing-repaint-expected.html: Added. * compositing/shared-backing/backing-sharing-repaint.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247912 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Simon Fraser REGRESSION (r246899): Subtitles show twice when controls show/hide on hulu.com https://bugs.webkit.org/show_bug.cgi?id=200187 rdar://problem/53511121 Reviewed by Zalan Bujtas. When a layer that painted into shared backing moved, we'd fail to repaint its old position because the RenderLayer's repaint rects are cleared via BackingSharingState::updateBeforeDescendantTraversal(). Recomputing repaint rects is expensive, so we only want to do it when necessary, which is for layers that start and stop sharing (going into and out of compositing already recomputes them). So add logic to RenderLayerBacking::setBackingSharingLayers() that recomputes repaint rects on layers that will no longer use shared backing, and those that are newly using shared backing. Test: compositing/shared-backing/backing-sharing-repaint.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::setBackingProviderLayer): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::setBackingSharingLayers): * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::BackingSharingState::appendSharingLayer): (WebCore::RenderLayerCompositor::updateBacking): 2019-07-31 Alan Coon Cherry-pick r247909. rdar://problem/53764231 The touch-action property was ignored on replaced elements (canvas, img etc) https://bugs.webkit.org/show_bug.cgi?id=200205 rdar://problem/53331224 Reviewed by Antti Koivisto. Source/WebCore: The event region painting code didn't handle replaced elements correctly, causing touch-action to get ignored for , etc. Fix by handling region painting in RenderReplaced. This still doesn't fix