ChangeLog   [plain text]


2019-11-18  Kocsen Chung  <kocsen_chung@apple.com>

        Apply patch. rdar://problem/57283187

    2019-11-18  John Wilander  <wilander@apple.com>

            Check if ITP is on before applying third-party cookie blocking
            https://bugs.webkit.org/show_bug.cgi?id=204109
            <rdar://problem/57120772>

            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.

            * NetworkProcess/NetworkSession.cpp:
            (WebKit::NetworkSession::setResourceLoadStatisticsEnabled):
                Now tells WebCore::NetworkStorageSession the status of
                ITP.

2019-11-12  Kocsen Chung  <kocsen_chung@apple.com>

        Apply patch. rdar://problem/57123575

    2019-11-12  Chris Dumez  <cdumez@apple.com>

            Networking loading stalls / partial loading
            <rdar://problem/57050996>

            Reviewed by Ryosuke Niwa.

            If the UIProcess's background task expires while we're holding a foreground assertion on behalf
            of the network process, we would fail to release that assertion (i.e. reset the assertion state
            to "Suspended"). We would send the ProcessWillSuspendImminently IPC to the network process, which
            would suspend the StorageManager thread and everything would suspend shortly after.

            When MobileSafari would come back to the foreground after this, the WKWebView would become visible and
            it would indicate it needs a "Foreground" process assertion on behalf of its network process.
            However, because we did not reset the network process assertion state on suspension, the UIProcess
            would still think it has a "Foreground" process assertion on behalf of the network process and
            it would do nothing. As a result, the UIProcess would fail to send the ProcessDidResume to the
            network process and the network process would still have its StorageManager thread suspended.

            If you then try to do a page load and the WebProcess ends up needing the local storage data for
            the origin, it would do a synchronous IPC to the network process to get the data. Getting that
            data is supposed to happen on the StorageManager thread in the network process, which is still
            suspended / hung. As a result, the network process would fail to respond to the sync IPC and
            the WebProcess would hang, usually in the middle of a page load.

            To address the issue, we now reset the process assertion state to "Suspended" when
            uiAssertionWillExpireImminently(), to properly reflect its new state (given that it expired).
            As a result, if we later need a Foreground assertion for the network process, the UIProcess
            will know it does not already have one and it will take one.

            Note that this was already fixed on trunk via <rdar://problem/56547883> /
            <https://trac.webkit.org/changeset/251577>. However, r251577 is fairly large because it
            refactored the code at the same time. This patch only contains the part of r251577 that we
            need on the branch to fix the suspension bug.

            * UIProcess/ProcessThrottler.cpp:
            (WebKit::ProcessThrottler::uiAssertionWillExpireImminently):

2019-11-11  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r252248. rdar://problem/57040121

    [WebAuthn] Return NotAllowedError immediately for UI cancellations
    https://bugs.webkit.org/show_bug.cgi?id=203937
    <rdar://problem/56962420>
    
    Reviewed by Brent Fulgham.
    
    Source/WebKit:
    
    NotAllowedError representing UI cancellations should be returned to sites
    immediately such that sites could show appropriate error page immediately.
    
    Covered by existing tests.
    
    * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
    (WebKit::AuthenticatorManager::cancelRequest):
    (WebKit::AuthenticatorManager::clearState):
    (WebKit::AuthenticatorManager::resetState): Deleted.
    * UIProcess/WebAuthentication/AuthenticatorManager.h:
    
    Tools:
    
    * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm:
    (TestWebKitAPI::TEST):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@252248 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-11-06  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Return NotAllowedError immediately for UI cancellations
            https://bugs.webkit.org/show_bug.cgi?id=203937
            <rdar://problem/56962420>

            Reviewed by Brent Fulgham.

            NotAllowedError representing UI cancellations should be returned to sites
            immediately such that sites could show appropriate error page immediately.

            Covered by existing tests.

            * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
            (WebKit::AuthenticatorManager::cancelRequest):
            (WebKit::AuthenticatorManager::clearState):
            (WebKit::AuthenticatorManager::resetState): Deleted.
            * UIProcess/WebAuthentication/AuthenticatorManager.h:

2019-11-10  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/56962320>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Add quirk needed to support legacy Google NFC Titan security keys
            https://bugs.webkit.org/show_bug.cgi?id=204024
            <rdar://problem/56962320>

            Reviewed by Brent Fulgham.

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

2019-11-05  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/56903274

    2019-11-05  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Guard against unexpected -[_WKWebAuthenticationPanel cancel]
            https://bugs.webkit.org/show_bug.cgi?id=203830
            <rdar://problem/56797134>

            Reviewed by Brent Fulgham .

            -[_WKWebAuthenticationPanel cancel] was only expected to be called on behalf of an
            explicit user cancel from the UI. However, clients may call it in different other
            unexpected scenarios as well. We should guard against that.

            To do so, two counter ways are implemented:
            1) AuthenticatorManager::cancelRequest is changed to invoke the pending request if there
            is no GlobalFrameID. This case can only be reached via calling -[_WKWebAuthenticationPanel cancel]
            before AuthenticatorManager::cancelRequest.
            2) WebAuthenticationPanelClient::updatePanel and WebAuthenticationPanelClient::dismissPanel
            will call delegate methods in the next run loop to prevent -[_WKWebAuthenticationPanel cancel]
            being called in the delegates.

            Covered by new API tests.

            * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
            (WebKit::AuthenticatorManager::cancelRequest):
            (WebKit::AuthenticatorManager::createService const):
            (WebKit::AuthenticatorManager::invokePendingCompletionHandler):
            * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.mm:
            (WebKit::WebAuthenticationPanelClient::updatePanel const):
            (WebKit::WebAuthenticationPanelClient::dismissPanel const):

2019-11-05  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248121. rdar://problem/56903580

    Crash under WebProcessProxy::didBecomeUnresponsive()
    https://bugs.webkit.org/show_bug.cgi?id=200346
    <rdar://problem/53795984>
    
    Reviewed by Geoffrey Garen.
    
    Make sure the BackgroundProcessResponsivenessTimer / ResponsivenessTimer ref their client
    while they call mayBecomeUnresponsive() / willChangeIsResponsive() / didChangeIsResponsive()
    / didBecomeUnresponsive() on their client, in case calling one of these ends up destroying
    the client.
    
    * UIProcess/BackgroundProcessResponsivenessTimer.cpp:
    (WebKit::BackgroundProcessResponsivenessTimer::setResponsive):
    * UIProcess/ResponsivenessTimer.cpp:
    (WebKit::ResponsivenessTimer::timerFired):
    * UIProcess/ResponsivenessTimer.h:
    * UIProcess/WebProcessProxy.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248121 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-01  Chris Dumez  <cdumez@apple.com>

            Crash under WebProcessProxy::didBecomeUnresponsive()
            https://bugs.webkit.org/show_bug.cgi?id=200346
            <rdar://problem/53795984>

            Reviewed by Geoffrey Garen.

            Make sure the BackgroundProcessResponsivenessTimer / ResponsivenessTimer ref their client
            while they call mayBecomeUnresponsive() / willChangeIsResponsive() / didChangeIsResponsive()
            / didBecomeUnresponsive() on their client, in case calling one of these ends up destroying
            the client.

            * UIProcess/BackgroundProcessResponsivenessTimer.cpp:
            (WebKit::BackgroundProcessResponsivenessTimer::setResponsive):
            * UIProcess/ResponsivenessTimer.cpp:
            (WebKit::ResponsivenessTimer::timerFired):
            * UIProcess/ResponsivenessTimer.h:
            * UIProcess/WebProcessProxy.h:

2019-11-04  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/56864381

    2019-11-04  Tim Horton  <timothy_horton@apple.com>

            WKWebView can get stuck blank (Web Content process thinks the app is backgrounded)
            https://bugs.webkit.org/show_bug.cgi?id=203774
            <rdar://problem/53399054>

            With careful timing, if a WKWebView swaps out its content view in the
            background, the incoming view can fail to inform the Web Content process
            when the app comes to the foreground, leaving the layer tree frozen.

            This occurs because the last-sent state is stored per-WKApplicationStateTrackingView,
            and the content view is the WKApplicationStateTrackingView, so it is possible
            for e.g. a WKPDFView to be in the hierarchy, keeping the correct state,
            with an initialized-but-never-parented WKContentView hanging off the WKWebView.

            If it is never parented, WKContentView will think that the current application
            state is foreground (_lastObservedStateWasBackground is initialized to NO).

            If you go into the background with a WKPDFView as the current content view,
            it will inform the Web Content process that the application has backgrounded.

            If, still in the background, WKWebView swaps from the WKPDFView to
            the WKContentView, and then comes into the foreground, when we get the
            notification that the app came to the foreground, we will not forward it
            to the Web Content process, because WKContentView's _lastObservedStateWasBackground
            remains NO.

            To fix this, move _lastObservedStateWasBackground to WebPageProxy, so that
            it always tracks the most recently sent state, regardless of which content view
            is active.

            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::resetState):
            * UIProcess/WebPageProxy.h:
            (WebKit::WebPageProxy::lastObservedStateWasBackground const):
            * UIProcess/ios/WKApplicationStateTrackingView.mm:
            (-[WKApplicationStateTrackingView willMoveToWindow:]):
            (-[WKApplicationStateTrackingView didMoveToWindow]):
            (-[WKApplicationStateTrackingView _applicationDidEnterBackground]):
            (-[WKApplicationStateTrackingView _applicationWillEnterForeground]):
            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::applicationDidEnterBackground):
            (WebKit::WebPageProxy::applicationWillEnterForeground):

2019-11-04  Kocsen Chung  <kocsen_chung@apple.com>

        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<CharType>::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<StringBuilder>::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  <weinig@apple.com>

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

            * Shared/mac/AuxiliaryProcessMac.mm:
            (WebKit::setAndSerializeSandboxParameters):
            * UIProcess/WebProcessPool.cpp:
            (WebKit::WebProcessPool::didReceiveInvalidMessage):
            Update for renames.

2019-11-04  Alan Coon  <alancoon@apple.com>

        Cherry-pick r251979. rdar://problem/56864383

    [WebAuthn] CtapAuthenticator::tryDowngrade should distinguish requestData().options
    https://bugs.webkit.org/show_bug.cgi?id=203771
    <rdar://problem/56832618>
    
    Reviewed by Brent Fulgham.
    
    CtapAuthenticator::tryDowngrade assumes the request is a getAssertion request. This is true
    for most cases but not for Google's registration. For Google's registration, a quirk is
    implemented to use U2F commands for registration if GoogleLegacyAppIdSupportExtension asks
    us to do so.
    
    No tests given there is no way to simulate google.com in our test infrastructures.
    
    * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp:
    (WebKit::CtapAuthenticator::tryDowngrade):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251979 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-11-03  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] CtapAuthenticator::tryDowngrade should distinguish requestData().options
            https://bugs.webkit.org/show_bug.cgi?id=203771
            <rdar://problem/56832618>

            Reviewed by Brent Fulgham.

            CtapAuthenticator::tryDowngrade assumes the request is a getAssertion request. This is true
            for most cases but not for Google's registration. For Google's registration, a quirk is
            implemented to use U2F commands for registration if GoogleLegacyAppIdSupportExtension asks
            us to do so.

            No tests given there is no way to simulate google.com in our test infrastructures.

            * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp:
            (WebKit::CtapAuthenticator::tryDowngrade):

2019-10-30  Alex Christensen  <achristensen@webkit.org>

        Branch build fix after r251754
        https://bugs.webkit.org/show_bug.cgi?id=191523
        <rdar://problem/56579665>

        * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
        (WebKit::AuthenticatorManager::cancelRequest):
        (WebKit::AuthenticatorManager::runPanel):
        * UIProcess/WebAuthentication/AuthenticatorManager.h:
        * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp:
        (WebKit::WebAuthenticatorCoordinatorProxy::makeCredential):
        (WebKit::WebAuthenticatorCoordinatorProxy::getAssertion):
        * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h:
        * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.messages.in:
        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared):
        (WebKit::WebPageProxy::resetState):
        * UIProcess/WebProcessProxy.cpp:
        (WebKit::WebProcessProxy::didDestroyFrame):

2019-10-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r251317. rdar://problem/56598357

    [WebAuthn] Warn users when no credentials are found
    https://bugs.webkit.org/show_bug.cgi?id=203147
    <rdar://problem/55931123>
    
    Reviewed by Brent Fulgham.
    
    Source/WebKit:
    
    This patch returns _WKWebAuthenticationPanelUpdateNoCredentialsFound to client via
    -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] when either
    CtapAuthenticator receives kCtap2ErrNoCredentials or U2fAuthenticator exhausts the
    allow list.
    
    This patch also enhances CtapAuthenticator::tryDowngrade to check if the CTAP command
    can be converted to U2F commands to ensure kCtap2ErrNoCredentials is returned if it
    is the case. Otherwise, after downgrading, U2fAuthenticator will return NotSupportedError
    given it can't convert the commands.
    
    * UIProcess/API/APIUIClient.h:
    * UIProcess/API/APIWebAuthenticationPanelClient.h:
    (API::WebAuthenticationPanelClient::updatePanel const):
    * UIProcess/WebAuthentication/Authenticator.h:
    * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
    (WebKit::AuthenticatorManager::authenticatorStatusUpdated):
    * UIProcess/WebAuthentication/AuthenticatorManager.h:
    * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.h:
    * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.mm:
    (WebKit::WebAuthenticationPanelClient::WebAuthenticationPanelClient):
    (WebKit::wkWebAuthenticationPanelUpdate):
    (WebKit::WebAuthenticationPanelClient::updatePanel const):
    * UIProcess/WebAuthentication/WebAuthenticationFlags.h: Renamed from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationPanelFlags.h.
    * UIProcess/WebAuthentication/WebAuthenticationRequestData.h:
    * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp:
    * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp:
    (WebKit::CtapAuthenticator::continueGetAssertionAfterResponseReceived):
    (WebKit::CtapAuthenticator::tryDowngrade):
    * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp:
    (WebKit::U2fAuthenticator::issueSignCommand):
    * WebKit.xcodeproj/project.pbxproj:
    
    Tools:
    
    Adds new tests for _WKWebAuthenticationPanelUpdateNoCredentialsFound.
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm:
    (-[TestWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:]):
    (TestWebKitAPI::TEST):
    * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion-hid-cancel.html:
    * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion-hid-no-credentials.html: Added.
    * 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-u2f-no-credentials.html: Added.
    
    LayoutTests:
    
    Adds new tests for CtapAuthenticator::tryDowngrade enhancement.
    
    * http/wpt/webauthn/public-key-credential-get-failure-hid.https-expected.txt:
    * http/wpt/webauthn/public-key-credential-get-failure-hid.https.html:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251317 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-18  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Warn users when no credentials are found
            https://bugs.webkit.org/show_bug.cgi?id=203147
            <rdar://problem/55931123>

            Reviewed by Brent Fulgham.

            This patch returns _WKWebAuthenticationPanelUpdateNoCredentialsFound to client via
            -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] when either
            CtapAuthenticator receives kCtap2ErrNoCredentials or U2fAuthenticator exhausts the
            allow list.

            This patch also enhances CtapAuthenticator::tryDowngrade to check if the CTAP command
            can be converted to U2F commands to ensure kCtap2ErrNoCredentials is returned if it
            is the case. Otherwise, after downgrading, U2fAuthenticator will return NotSupportedError
            given it can't convert the commands.

            * UIProcess/API/APIUIClient.h:
            * UIProcess/API/APIWebAuthenticationPanelClient.h:
            (API::WebAuthenticationPanelClient::updatePanel const):
            * UIProcess/WebAuthentication/Authenticator.h:
            * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
            (WebKit::AuthenticatorManager::authenticatorStatusUpdated):
            * UIProcess/WebAuthentication/AuthenticatorManager.h:
            * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.h:
            * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.mm:
            (WebKit::WebAuthenticationPanelClient::WebAuthenticationPanelClient):
            (WebKit::wkWebAuthenticationPanelUpdate):
            (WebKit::WebAuthenticationPanelClient::updatePanel const):
            * UIProcess/WebAuthentication/WebAuthenticationFlags.h: Renamed from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationPanelFlags.h.
            * UIProcess/WebAuthentication/WebAuthenticationRequestData.h:
            * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp:
            * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp:
            (WebKit::CtapAuthenticator::continueGetAssertionAfterResponseReceived):
            (WebKit::CtapAuthenticator::tryDowngrade):
            * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp:
            (WebKit::U2fAuthenticator::issueSignCommand):
            * WebKit.xcodeproj/project.pbxproj:

2019-10-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r251500. rdar://problem/56579657

    [WebAuthn] Warn users when multiple NFC tags present
    https://bugs.webkit.org/show_bug.cgi?id=200932
    <rdar://problem/54890736>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Warn users when multiple NFC tags present
            https://bugs.webkit.org/show_bug.cgi?id=200932
            <rdar://problem/54890736>

            Reviewed by Brent Fulgham.

            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:

2019-10-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r251489. rdar://problem/56579665

    [WebAuthn] Supply FrameInfo in -[WKUIDelegatePrivate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]
    https://bugs.webkit.org/show_bug.cgi?id=202563
    <rdar://problem/55973968>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Supply FrameInfo in -[WKUIDelegatePrivate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]
            https://bugs.webkit.org/show_bug.cgi?id=202563
            <rdar://problem/55973968>

            Reviewed by Brent Fulgham.

            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:

2019-10-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r251295. rdar://problem/56579665

    [WebAuthn] Implement AuthenticatorCancel
    https://bugs.webkit.org/show_bug.cgi?id=191523
    <rdar://problem/55920204>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Implement AuthenticatorCancel
            https://bugs.webkit.org/show_bug.cgi?id=191523
            <rdar://problem/55920204>

            Reviewed by Brent Fulgham.

            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:

2019-10-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r251154. rdar://problem/56715899

    [WebAuthn] Rename -[WKUIDelegatePrivate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:] to -[WKUIDelegatePrivate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]
    https://bugs.webkit.org/show_bug.cgi?id=202564
    <rdar://problem/55974027>
    
    Reviewed by Brent Fulgham.
    
    Source/WebKit:
    
    Rename the SPI to a proper SPI style.
    
    * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
    * UIProcess/Cocoa/UIDelegate.mm:
    (WebKit::UIDelegate::setDelegate):
    (WebKit::UIDelegate::UIClient::runWebAuthenticationPanel):
    
    Tools:
    
    * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm:
    (-[TestWebAuthenticationPanelUIDelegate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]):
    (-[TestWebAuthenticationPanelUIDelegate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]): Deleted.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251154 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-15  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Rename -[WKUIDelegatePrivate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:] to -[WKUIDelegatePrivate _webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]
            https://bugs.webkit.org/show_bug.cgi?id=202564
            <rdar://problem/55974027>

            Reviewed by Brent Fulgham.

            Rename the SPI to a proper SPI style.

            * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
            * UIProcess/Cocoa/UIDelegate.mm:
            (WebKit::UIDelegate::setDelegate):
            (WebKit::UIDelegate::UIClient::runWebAuthenticationPanel):

2019-10-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250940. rdar://problem/56598350

    [WebAuthn] Move the mock testing entrance to Internals
    https://bugs.webkit.org/show_bug.cgi?id=202560
    <rdar://problem/55973793>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Move the mock testing entrance to Internals
            https://bugs.webkit.org/show_bug.cgi?id=202560
            <rdar://problem/55973793>

            Reviewed by Chris Dumez.

            * 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:

2019-10-24  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250640. rdar://problem/56237433

    REGRESSION (r245672): <select> dropdown with text-rendering: optimizeLegibility freezes Safari
    https://bugs.webkit.org/show_bug.cgi?id=202198
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    NSFont has a bug where passing "auto" to kCTFontOpticalSizeAttribute
    causes an exception to be thrown. We don't catch the exception, so we
    pop up back to the runloop, which confuses the UI process.
    
    The solution is twofold: 1) Workaround the bug by passing the font size
    to kCTFontOpticalSizeAttribute instead, and 2) catch any exceptions that
    this part of the code might throw.
    
    * UIProcess/mac/WebPopupMenuProxyMac.mm:
    (WebKit::WebPopupMenuProxyMac::showPopupMenu):
    
    Source/WTF:
    
    * wtf/Platform.h:
    
    LayoutTests:
    
    * fast/forms/select-font-optical-size-expected.txt: Added.
    * fast/forms/select-font-optical-size.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250640 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-02  Myles C. Maxfield  <mmaxfield@apple.com>

            REGRESSION (r245672): <select> dropdown with text-rendering: optimizeLegibility freezes Safari
            https://bugs.webkit.org/show_bug.cgi?id=202198

            Reviewed by Tim Horton.

            NSFont has a bug where passing "auto" to kCTFontOpticalSizeAttribute
            causes an exception to be thrown. We don't catch the exception, so we
            pop up back to the runloop, which confuses the UI process.

            The solution is twofold: 1) Workaround the bug by passing the font size
            to kCTFontOpticalSizeAttribute instead, and 2) catch any exceptions that
            this part of the code might throw.

            * UIProcess/mac/WebPopupMenuProxyMac.mm:
            (WebKit::WebPopupMenuProxyMac::showPopupMenu):

2019-10-24  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r251370. rdar://problem/56579672

    Add more release logging for "Unexpectedly resumed" assertion
    https://bugs.webkit.org/show_bug.cgi?id=203196
    
    Reviewed by Geoffrey Garen.
    
    * WebProcess/WebProcess.cpp:
    (WebKit::WebProcess::processDidResume):
    * WebProcess/cocoa/WebProcessCocoa.mm:
    (WebKit::WebProcess::processTaskStateDidChange):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251370 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-21  Chris Dumez  <cdumez@apple.com>

            Add more release logging for "Unexpectedly resumed" assertion
            https://bugs.webkit.org/show_bug.cgi?id=203196

            Reviewed by Geoffrey Garen.

            * WebProcess/WebProcess.cpp:
            (WebKit::WebProcess::processDidResume):
            * WebProcess/cocoa/WebProcessCocoa.mm:
            (WebKit::WebProcess::processTaskStateDidChange):

2019-10-24  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r251304. rdar://problem/56579672

    [iOS] "Unexpectedly Resumed" process assertion may cause us to get terminated
    https://bugs.webkit.org/show_bug.cgi?id=203046
    <rdar://problem/56179592>
    
    Reviewed by Geoffrey Garen.
    
    This patch implements the following to avoid getting terminated:
    1. Schedule the task to release the assertion on a background thread instead of
       the main thread so that we end up releasing the task even if the main thread
       is somehow hung.
    2. Add an invalidation handler to the process assertion which releases the assertion
       upon expiration.
    
    * UIProcess/Cocoa/WebProcessProxyCocoa.mm:
    (WebKit::WebProcessProxy::processWasUnexpectedlyUnsuspended):
    * WebProcess/WebProcess.cpp:
    (WebKit::WebProcess::processDidResume):
    * WebProcess/WebProcess.h:
    * WebProcess/cocoa/WebProcessCocoa.mm:
    (WebKit::WebProcess::processTaskStateDidChange):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251304 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-18  Chris Dumez  <cdumez@apple.com>

            [iOS] "Unexpectedly Resumed" process assertion may cause us to get terminated
            https://bugs.webkit.org/show_bug.cgi?id=203046
            <rdar://problem/56179592>

            Reviewed by Geoffrey Garen.

            This patch implements the following to avoid getting terminated:
            1. Schedule the task to release the assertion on a background thread instead of
               the main thread so that we end up releasing the task even if the main thread
               is somehow hung.
            2. Add an invalidation handler to the process assertion which releases the assertion
               upon expiration.

            * UIProcess/Cocoa/WebProcessProxyCocoa.mm:
            (WebKit::WebProcessProxy::processWasUnexpectedlyUnsuspended):
            * WebProcess/WebProcess.cpp:
            (WebKit::WebProcess::processDidResume):
            * WebProcess/WebProcess.h:
            * WebProcess/cocoa/WebProcessCocoa.mm:
            (WebKit::WebProcess::processTaskStateDidChange):

2019-10-21  Dean Jackson  <dino@apple.com>

        Cherry-pick r251390. rdar://56579651

    2019-10-21  Dean Jackson  <dino@apple.com>

            Dispatch AR event on the originating anchor element
            https://bugs.webkit.org/show_bug.cgi?id=203198
            <rdar://55743929>

            Reviewed by Simon Fraser.

            Use the ElementContext on SystemPreviewInfo.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _triggerSystemPreviewActionOnElement:frame:page:]):
            (-[WKWebView _triggerSystemPreviewActionOnFrame:page:]): Deleted.
            * UIProcess/API/Cocoa/WKWebViewPrivate.h:
            * UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:
            * UIProcess/SystemPreviewController.h:
            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::systemPreviewActionTriggered):

2019-10-25  Dean Jackson  <dino@apple.com>

        Cherry-pick r251388. rdar://56579651

    Move ElementContext from WebKit to WebCore
    https://bugs.webkit.org/show_bug.cgi?id=203210
    <rdar://problem/56475682>

    Reviewed by Simon Fraser.

2019-10-20  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r250773. rdar://problem/56271900

    WebPageProxy::updatePlayingMediaDidChange should protect from a null m_userMediaPermissionRequestManager
    https://bugs.webkit.org/show_bug.cgi?id=202628
    <rdar://problem/55935091>
    
    Reviewed by Eric Carlson.
    
    On process swap on navigation or process crash, m_userMediaPermissionRequestManager is made null.
    At the same time, the media state is set back to not playing.
    Future calls of updatePlayingMediaDidChange should not have any capture state change until getUserMedia/getDisplayMedia
    is called, which would create m_userMediaPermissionRequestManager.
    But this assumption is not always true given that the media state is computed as process-wide in MediaStreamTrack::captureState on iOS.
    The above behavior is fixed as part of https://bugs.webkit.org/show_bug.cgi?id=202627.
    Since the call to updatePlayingMediaDidChange is triggered straight from IPC, it should not be trusted and a null check should be added.
    
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::updatePlayingMediaDidChange):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250773 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-07  youenn fablet  <youenn@apple.com>

            WebPageProxy::updatePlayingMediaDidChange should protect from a null m_userMediaPermissionRequestManager
            https://bugs.webkit.org/show_bug.cgi?id=202628
            <rdar://problem/55935091>

            Reviewed by Eric Carlson.

            On process swap on navigation or process crash, m_userMediaPermissionRequestManager is made null.
            At the same time, the media state is set back to not playing.
            Future calls of updatePlayingMediaDidChange should not have any capture state change until getUserMedia/getDisplayMedia
            is called, which would create m_userMediaPermissionRequestManager.
            But this assumption is not always true given that the media state is computed as process-wide in MediaStreamTrack::captureState on iOS.
            The above behavior is fixed as part of https://bugs.webkit.org/show_bug.cgi?id=202627.
            Since the call to updatePlayingMediaDidChange is triggered straight from IPC, it should not be trusted and a null check should be added.

            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::updatePlayingMediaDidChange):

2019-10-20  Babak Shafiei  <bshafiei@apple.com>

        Apply patch. rdar://problem/56427498

    2019-10-20  John Wilander  <wilander@apple.com>

                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
            <rdar://problem/56262708>

            Reviewed by Alex Christensen.

            The functional change is in WebCore::NetworkStorageSession::shouldBlockCookies() which is
            called from:
            - NetworkDataTaskCocoa::NetworkDataTaskCocoa()
            - NetworkDataTaskCocoa::willPerformHTTPRedirection

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

            The changes to ResourceLoadStatisticsDatabaseStore and ResourceLoadStatisticsMemoryStore
            are about communicating which domains have received user interaction (prevalent or not)
            to the network storage session so that it can enforce the new restriction.

            The C API change and piping through the WebsiteDataStore is test infrastructure.

            * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp:
            (WebKit::ResourceLoadStatisticsDatabaseStore::clear):
            (WebKit::ResourceLoadStatisticsDatabaseStore::updateCookieBlocking):
            * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp:
            (WebKit::ResourceLoadStatisticsMemoryStore::logUserInteraction):
            (WebKit::ResourceLoadStatisticsMemoryStore::clear):
            (WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking):
            * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp:
            (WebKit::ResourceLoadStatisticsStore::updateCookieBlockingForDomains):
            * NetworkProcess/Classifier/ResourceLoadStatisticsStore.h:
            * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
            (WebKit::WebResourceLoadStatisticsStore::callUpdatePrevalentDomainsToBlockCookiesForHandler):
            (WebKit::WebResourceLoadStatisticsStore::scheduleCookieBlockingUpdateForDomains): Deleted.
            (WebKit::WebResourceLoadStatisticsStore::scheduleClearBlockingStateForDomains): Deleted.
            * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:
            (WebKit::RegistrableDomainsToBlockCookiesFor::isolatedCopy const):
            * NetworkProcess/NetworkProcess.cpp:
            (WebKit::NetworkProcess::setShouldBlockThirdPartyCookiesForTesting):
            * NetworkProcess/NetworkProcess.h:
            * NetworkProcess/NetworkProcess.messages.in:
            * NetworkProcess/NetworkSession.h:
            * NetworkProcess/NetworkSessionCreationParameters.cpp:
            (WebKit::NetworkSessionCreationParameters::privateSessionParameters):
            (WebKit::NetworkSessionCreationParameters::encode const):
            (WebKit::NetworkSessionCreationParameters::decode):
            * NetworkProcess/NetworkSessionCreationParameters.h:
            * NetworkProcess/cocoa/NetworkSessionCocoa.mm:
            (WebKit::NetworkSessionCocoa::NetworkSessionCocoa):
            * Shared/WebPreferences.yaml:
            * UIProcess/API/C/WKWebsiteDataStoreRef.cpp:
            (WKWebsiteDataStoreSetResourceLoadStatisticsShouldBlockThirdPartyCookiesForTesting):
            (WKWebsiteDataStoreStatisticsResetToConsistentState):
            * UIProcess/API/C/WKWebsiteDataStoreRef.h:
            * UIProcess/Network/NetworkProcessProxy.cpp:
            (WebKit::NetworkProcessProxy::setShouldBlockThirdPartyCookiesForTesting):
            * UIProcess/Network/NetworkProcessProxy.h:
            * UIProcess/WebProcessPool.cpp:
            (WebKit::WebProcessPool::ensureNetworkProcess):
            * UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:
            (WebKit::WebsiteDataStore::parameters):
            * UIProcess/WebsiteData/WebsiteDataStore.cpp:
            (WebKit::WebsiteDataStore::setResourceLoadStatisticsShouldBlockThirdPartyCookiesForTesting):
            * UIProcess/WebsiteData/WebsiteDataStore.h:

2019-10-17  Alan Coon  <alancoon@apple.com>

        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
    <rdar://problem/55718526>
    
    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  <wilander@apple.com>

            Storage Access API: document.hasStorageAccess() should return true when the cookie policy allows access
            https://bugs.webkit.org/show_bug.cgi?id=202435
            <rdar://problem/55718526>

            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.

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

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r251086. rdar://problem/56237429

    [Cocoa] REGRESSION (r245672): Contenteditable with optical sizing freezes Safari
    https://bugs.webkit.org/show_bug.cgi?id=202262
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    r250640 didn't go far enough. We need to apply the same fix everywhere [NSFontDescriptor fontDescriptorWithFontAttributes:] is called.
    
    * Shared/Cocoa/ArgumentCodersCocoa.mm:
    (IPC::decodeFontInternal):
    * Shared/Cocoa/CoreTextHelpers.h: Added.
    * Shared/Cocoa/CoreTextHelpers.mm: Added.
    (fontDescriptorWithFontAttributes):
    * SourcesCocoa.txt:
    * UIProcess/Cocoa/WebViewImpl.mm:
    (WebKit::WebViewImpl::updateFontManagerIfNeeded):
    * UIProcess/mac/WebPopupMenuProxyMac.mm:
    (WebKit::WebPopupMenuProxyMac::showPopupMenu):
    * WebKit.xcodeproj/project.pbxproj:
    
    LayoutTests:
    
    * fast/forms/contenteditable-font-optical-size-expected.txt: Added.
    * fast/forms/contenteditable-font-optical-size.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@251086 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-14  Myles C. Maxfield  <mmaxfield@apple.com>

            [Cocoa] REGRESSION (r245672): Contenteditable with optical sizing freezes Safari
            https://bugs.webkit.org/show_bug.cgi?id=202262

            Reviewed by Tim Horton.

            r250640 didn't go far enough. We need to apply the same fix everywhere [NSFontDescriptor fontDescriptorWithFontAttributes:] is called.

            * Shared/Cocoa/ArgumentCodersCocoa.mm:
            (IPC::decodeFontInternal):
            * Shared/Cocoa/CoreTextHelpers.h: Added.
            * Shared/Cocoa/CoreTextHelpers.mm: Added.
            (fontDescriptorWithFontAttributes):
            * SourcesCocoa.txt:
            * UIProcess/Cocoa/WebViewImpl.mm:
            (WebKit::WebViewImpl::updateFontManagerIfNeeded):
            * UIProcess/mac/WebPopupMenuProxyMac.mm:
            (WebKit::WebPopupMenuProxyMac::showPopupMenu):
            * WebKit.xcodeproj/project.pbxproj:

2019-10-15  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250833. rdar://problem/56280706

    Apply patch. rdar://problem/55920073
    
    git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608.3.10.1-branch@250833 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-08  Alan Coon  <alancoon@apple.com>

            Apply patch. rdar://problem/55920073

        2019-10-08  youenn fablet  <youenn@apple.com>

                Remove the protection to spin more than one service worker process at a time.
                rdar://problem/55044713

                Before site isolation, we were creating one service worker process for all domains.
                We now create one service worker process per domain, which makes the protection to only spin
                one service worker process potentially harmful: if two requests to create a service worker processes
                for two different domains are made, only one will actually succeed.
                This is reproduced by API test.

                At UIProcess side, there is already a check to see whether a service worker process for a given domain is launched.
                That protects against spinning several service worker processes for the same domain.

                * NetworkProcess/NetworkProcess.cpp:
                (WebKit::NetworkProcess::createNetworkConnectionToWebProcess):
                (WebKit::NetworkProcess::createServerToContextConnection):
                * NetworkProcess/NetworkProcess.h:

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250780. rdar://problem/56061126

    Provide options for DTTZ to happen in more situations
    https://bugs.webkit.org/show_bug.cgi?id=202634
    <rdar://problem/55732762>
    
    Reviewed by Antoine Quint.
    
    Add two options that can be enabled to trigger double tap zooming
    in more places.
    
    Firstly, an option to keep listening for a double-tap-to-zoom if the
    first tap found a click handler on the body or document element. The
    tap will still be dispatched. This is probably the most common case
    for disabling a DTTZ.
    
    Secondly, an option to always keep listening for a double-tap-to-zoom,
    even if there was a clickable (non-root) element under the first tap.
    
    * Shared/WebPreferences.yaml: Add ZoomOnDoubleTapWhenRoot and AlwaysZoomOnDoubleTap.
    * UIProcess/PageClient.h: The message from the WebProcess now tells the UIProcess if
    the tapped element was a root-level (document or body).
    * UIProcess/WebPageProxy.h:
    * UIProcess/WebPageProxy.messages.in:
    * UIProcess/ios/PageClientImplIOS.h:
    * UIProcess/ios/PageClientImplIOS.mm:
    (WebKit::PageClientImpl::handleSmartMagnificationInformationForPotentialTap):
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _endPotentialTapAndEnableDoubleTapGesturesIfNecessary]):
    (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:nodeIsRootLevel:]):
    Handle the two new options.
    
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::WebPageProxy::handleSmartMagnificationInformationForPotentialTap):
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::potentialTapAtPosition): Check if the tap was on a root-level element.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250780 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-07  Dean Jackson  <dino@apple.com>

            Provide options for DTTZ to happen in more situations
            https://bugs.webkit.org/show_bug.cgi?id=202634
            <rdar://problem/55732762>

            Reviewed by Antoine Quint.

            Add two options that can be enabled to trigger double tap zooming
            in more places.

            Firstly, an option to keep listening for a double-tap-to-zoom if the
            first tap found a click handler on the body or document element. The
            tap will still be dispatched. This is probably the most common case
            for disabling a DTTZ.

            Secondly, an option to always keep listening for a double-tap-to-zoom,
            even if there was a clickable (non-root) element under the first tap.

            * Shared/WebPreferences.yaml: Add ZoomOnDoubleTapWhenRoot and AlwaysZoomOnDoubleTap.
            * UIProcess/PageClient.h: The message from the WebProcess now tells the UIProcess if
            the tapped element was a root-level (document or body).
            * UIProcess/WebPageProxy.h:
            * UIProcess/WebPageProxy.messages.in:
            * UIProcess/ios/PageClientImplIOS.h:
            * UIProcess/ios/PageClientImplIOS.mm:
            (WebKit::PageClientImpl::handleSmartMagnificationInformationForPotentialTap):
            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _endPotentialTapAndEnableDoubleTapGesturesIfNecessary]):
            (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:nodeIsRootLevel:]):
            Handle the two new options.

            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::handleSmartMagnificationInformationForPotentialTap):
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::potentialTapAtPosition): Check if the tap was on a root-level element.

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250755. rdar://problem/56061126

    Use a better name than allowFastClicksEverywhere
    https://bugs.webkit.org/show_bug.cgi?id=202607
    <rdar://problem/55997133>
    
    Reviewed by Tim Horton.
    
    This preference name is quite confusing. Change it to
    PreferFasterClickOverDoubleTap.
    
    * Shared/WebPreferences.yaml:
    * Shared/WebPreferencesDefaultValues.h:
    * UIProcess/WebPageProxy.h:
    (WebKit::WebPageProxy::preferFasterClickOverDoubleTap const):
    (WebKit::WebPageProxy::allowsFastClicksEverywhere const): Deleted.
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:]):
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250755 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-04  Dean Jackson  <dino@apple.com>

            Use a better name than allowFastClicksEverywhere
            https://bugs.webkit.org/show_bug.cgi?id=202607
            <rdar://problem/55997133>

            Reviewed by Tim Horton.

            This preference name is quite confusing. Change it to
            PreferFasterClickOverDoubleTap.

            * Shared/WebPreferences.yaml:
            * Shared/WebPreferencesDefaultValues.h:
            * UIProcess/WebPageProxy.h:
            (WebKit::WebPageProxy::preferFasterClickOverDoubleTap const):
            (WebKit::WebPageProxy::allowsFastClicksEverywhere const): Deleted.
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:]):
            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies):

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250751. rdar://problem/56280731

    Unreviewed, build fix after r250729
    
    * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm:
    * UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250751 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-04  Jiewen Tan  <jiewen_tan@apple.com>

            Unreviewed, build fix after r250729

            * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm:
            * UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h:

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250729. rdar://problem/56280731

    [WebAuthn] Implement _WKWebAuthenticationPanel SPI
    https://bugs.webkit.org/show_bug.cgi?id=202559
    <rdar://problem/55932094>
    
    Reviewed by Brent Fulgham.
    
    Source/WebKit:
    
    This patch implements _WKWebAuthenticationPanel SPI. Here is the structure:
    1) API::WebAuthenticationPanel is the APIObject of _WKWebAuthenticationPanel. It is owned by AuthenticatorManager.
    The lifetime of _WKWebAuthenticationPanel on the other hand is managed by clients. This binding is the surface
    where clients could interact with WebKit's WebAuthentication implementation.
    2) API::WebAuthenticationPanelClient is a base class representing _WKWebAuthenticationPanelDelegate. Its subclass
    WebKit::WebAuthenticationPanelClient implements bridges to _WKWebAuthenticationPanelDelegate methods. It is owned by
    API::WebAuthenticationPanel. A weak pointer of WebKit::WebAuthenticationPanelClient is kept in _WKWebAuthenticationPanel
    to get the _WKWebAuthenticationPanelDelegate set by clients or nil otherwise. This binding is the surface where WebKit
    interacts with clients.
    3) WebAuthenticationPanelFlags is the mirror of enums within _WKWebAuthenticationPanel.
    
    Implementation wise, this patch implements:
    1) -[WKUIDelegatePrivate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:], this is bridged from
    the regular UIDelegate route. Noted, WKFrameInfo is nil for now, a follow up on Bug 202563 will take care of it. This
    will be called from AuthenticatorManager::runPanel() which gates the start of discovery on the callback. For clients
    that don't implement the delegate, the callback will always be called with _WKWebAuthenticationPanelResultUnavailable
    to allow WebKit run on non-UI mode. A specific C API hack is added to always return _WKWebAuthenticationPanelResultPresented
    in WebKitTestRunner for layout tests.
    2) -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] will be implemented in Bug 200932.
    3) -[_WKWebAuthenticationPanelDelegate panel:dismissWebAuthenticationPanelWithResult:], this is bridged from
    API::WebAuthenticationPanel/API::WebAuthenticationPanelClient. This will be called whenever AuthenticatorManager::m_pendingCompletionHandler
    is invoked. Depending on the respond, _WKWebAuthenticationResult will be returned accordingly. To facilitate that,
    invokePendingCompletionHandler is crafted to bundle those two operations.
    4) -[_WKWebAuthenticationPanel cancel] will be implemented in Bug 191523.
    
    Besides the above, this patch also silents the NFC action sheet.
    
    * Platform/spi/Cocoa/NearFieldSPI.h:
    * Shared/API/APIObject.h:
    * Shared/Cocoa/APIObject.mm:
    (API::Object::newObject):
    * Sources.txt:
    * SourcesCocoa.txt:
    * UIProcess/API/APIUIClient.h:
    (API::UIClient::runWebAuthenticationPanel):
    * UIProcess/API/APIWebAuthenticationPanel.cpp: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm.
    (API::WebAuthenticationPanel::create):
    (API::WebAuthenticationPanel::WebAuthenticationPanel):
    (API::WebAuthenticationPanel::setClient):
    * UIProcess/API/APIWebAuthenticationPanel.h: Copied from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationRequestData.h.
    * UIProcess/API/APIWebAuthenticationPanelClient.h: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h.
    (API::WebAuthenticationPanelClient::dismissPanel const):
    * UIProcess/API/C/WKPage.cpp:
    (WKPageSetPageUIClient):
    * UIProcess/API/C/WKPageUIClient.h:
    * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm:
    (-[_WKWebAuthenticationPanel dealloc]):
    (-[_WKWebAuthenticationPanel relyingPartyID]):
    (-[_WKWebAuthenticationPanel delegate]):
    (-[_WKWebAuthenticationPanel setDelegate:]):
    (-[_WKWebAuthenticationPanel _apiObject]):
    (-[_WKWebAuthenticationPanel _initWithRelayingPartyID:]): Deleted.
    * UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h:
    * UIProcess/Cocoa/UIDelegate.h:
    * UIProcess/Cocoa/UIDelegate.mm:
    (WebKit::UIDelegate::setDelegate):
    (WebKit::webAuthenticationPanelResult):
    (WebKit::UIDelegate::UIClient::runWebAuthenticationPanel):
    * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
    (WebKit::WebCore::isFeatureEnabled):
    (WebKit::WebCore::getRpId):
    (WebKit::AuthenticatorManager::handleRequest):
    (WebKit::AuthenticatorManager::respondReceived):
    (WebKit::AuthenticatorManager::startDiscovery):
    (WebKit::AuthenticatorManager::initTimeOutTimer):
    (WebKit::AuthenticatorManager::timeOutTimerFired):
    (WebKit::AuthenticatorManager::runPanel):
    (WebKit::AuthenticatorManager::startRequest):
    (WebKit::AuthenticatorManager::invokePendingCompletionHandler):
    (WebKit::AuthenticatorManagerInternal::collectTransports): Deleted.
    (WebKit::AuthenticatorManagerInternal::processGoogleLegacyAppIdSupportExtension): Deleted.
    * UIProcess/WebAuthentication/AuthenticatorManager.h:
    (WebKit::AuthenticatorManager::pendingCompletionHandler): Deleted.
    * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm:
    (WebKit::NfcConnection::NfcConnection):
    * UIProcess/WebAuthentication/Cocoa/NfcService.mm:
    (WebKit::NfcService::platformStartDiscovery):
    * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.h: Copied from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationRequestData.h.
    * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.mm: Copied from Source/WebKit/UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp.
    (WebKit::WebAuthenticationPanelClient::WebAuthenticationPanelClient):
    (WebKit::wkWebAuthenticationResult):
    (WebKit::WebAuthenticationPanelClient::dismissPanel const):
    * UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp:
    (WebKit::MockAuthenticatorManager::respondReceivedInternal):
    * UIProcess/WebAuthentication/WebAuthenticationPanelFlags.h: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h.
    * UIProcess/WebAuthentication/WebAuthenticationRequestData.h:
    * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp:
    (WebKit::WebAuthenticatorCoordinatorProxy::makeCredential):
    (WebKit::WebAuthenticatorCoordinatorProxy::getAssertion):
    * WebKit.xcodeproj/project.pbxproj:
    
    Tools:
    
    This patch adds a very limited test case to _WKWebAuthenticationPanel.
    Bug 202560 and Bug 202565 will follow up to write more tests.
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: Added.
    (-[TestWebAuthenticationPanelDelegate panel:dismissWebAuthenticationPanelWithResult:]):
    (-[TestWebAuthenticationPanelUIDelegate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]):
    (TestWebKitAPI::TEST):
    * TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion.html: Added.
    * WebKitTestRunner/TestController.cpp:
    (WTR::runWebAuthenticationPanel):
    (WTR::TestController::createWebViewWithOptions):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250729 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-04  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Implement _WKWebAuthenticationPanel SPI
            https://bugs.webkit.org/show_bug.cgi?id=202559
            <rdar://problem/55932094>

            Reviewed by Brent Fulgham.

            This patch implements _WKWebAuthenticationPanel SPI. Here is the structure:
            1) API::WebAuthenticationPanel is the APIObject of _WKWebAuthenticationPanel. It is owned by AuthenticatorManager.
            The lifetime of _WKWebAuthenticationPanel on the other hand is managed by clients. This binding is the surface
            where clients could interact with WebKit's WebAuthentication implementation.
            2) API::WebAuthenticationPanelClient is a base class representing _WKWebAuthenticationPanelDelegate. Its subclass
            WebKit::WebAuthenticationPanelClient implements bridges to _WKWebAuthenticationPanelDelegate methods. It is owned by
            API::WebAuthenticationPanel. A weak pointer of WebKit::WebAuthenticationPanelClient is kept in _WKWebAuthenticationPanel
            to get the _WKWebAuthenticationPanelDelegate set by clients or nil otherwise. This binding is the surface where WebKit
            interacts with clients.
            3) WebAuthenticationPanelFlags is the mirror of enums within _WKWebAuthenticationPanel.

            Implementation wise, this patch implements:
            1) -[WKUIDelegatePrivate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:], this is bridged from
            the regular UIDelegate route. Noted, WKFrameInfo is nil for now, a follow up on Bug 202563 will take care of it. This
            will be called from AuthenticatorManager::runPanel() which gates the start of discovery on the callback. For clients
            that don't implement the delegate, the callback will always be called with _WKWebAuthenticationPanelResultUnavailable
            to allow WebKit run on non-UI mode. A specific C API hack is added to always return _WKWebAuthenticationPanelResultPresented
            in WebKitTestRunner for layout tests.
            2) -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] will be implemented in Bug 200932.
            3) -[_WKWebAuthenticationPanelDelegate panel:dismissWebAuthenticationPanelWithResult:], this is bridged from
            API::WebAuthenticationPanel/API::WebAuthenticationPanelClient. This will be called whenever AuthenticatorManager::m_pendingCompletionHandler
            is invoked. Depending on the respond, _WKWebAuthenticationResult will be returned accordingly. To facilitate that,
            invokePendingCompletionHandler is crafted to bundle those two operations.
            4) -[_WKWebAuthenticationPanel cancel] will be implemented in Bug 191523.

            Besides the above, this patch also silents the NFC action sheet.

            * Platform/spi/Cocoa/NearFieldSPI.h:
            * Shared/API/APIObject.h:
            * Shared/Cocoa/APIObject.mm:
            (API::Object::newObject):
            * Sources.txt:
            * SourcesCocoa.txt:
            * UIProcess/API/APIUIClient.h:
            (API::UIClient::runWebAuthenticationPanel):
            * UIProcess/API/APIWebAuthenticationPanel.cpp: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm.
            (API::WebAuthenticationPanel::create):
            (API::WebAuthenticationPanel::WebAuthenticationPanel):
            (API::WebAuthenticationPanel::setClient):
            * UIProcess/API/APIWebAuthenticationPanel.h: Copied from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationRequestData.h.
            * UIProcess/API/APIWebAuthenticationPanelClient.h: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h.
            (API::WebAuthenticationPanelClient::dismissPanel const):
            * UIProcess/API/C/WKPage.cpp:
            (WKPageSetPageUIClient):
            * UIProcess/API/C/WKPageUIClient.h:
            * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm:
            (-[_WKWebAuthenticationPanel dealloc]):
            (-[_WKWebAuthenticationPanel relyingPartyID]):
            (-[_WKWebAuthenticationPanel delegate]):
            (-[_WKWebAuthenticationPanel setDelegate:]):
            (-[_WKWebAuthenticationPanel _apiObject]):
            (-[_WKWebAuthenticationPanel _initWithRelayingPartyID:]): Deleted.
            * UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h:
            * UIProcess/Cocoa/UIDelegate.h:
            * UIProcess/Cocoa/UIDelegate.mm:
            (WebKit::UIDelegate::setDelegate):
            (WebKit::webAuthenticationPanelResult):
            (WebKit::UIDelegate::UIClient::runWebAuthenticationPanel):
            * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
            (WebKit::WebCore::isFeatureEnabled):
            (WebKit::WebCore::getRpId):
            (WebKit::AuthenticatorManager::handleRequest):
            (WebKit::AuthenticatorManager::respondReceived):
            (WebKit::AuthenticatorManager::startDiscovery):
            (WebKit::AuthenticatorManager::initTimeOutTimer):
            (WebKit::AuthenticatorManager::timeOutTimerFired):
            (WebKit::AuthenticatorManager::runPanel):
            (WebKit::AuthenticatorManager::startRequest):
            (WebKit::AuthenticatorManager::invokePendingCompletionHandler):
            (WebKit::AuthenticatorManagerInternal::collectTransports): Deleted.
            (WebKit::AuthenticatorManagerInternal::processGoogleLegacyAppIdSupportExtension): Deleted.
            * UIProcess/WebAuthentication/AuthenticatorManager.h:
            (WebKit::AuthenticatorManager::pendingCompletionHandler): Deleted.
            * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm:
            (WebKit::NfcConnection::NfcConnection):
            * UIProcess/WebAuthentication/Cocoa/NfcService.mm:
            (WebKit::NfcService::platformStartDiscovery):
            * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.h: Copied from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationRequestData.h.
            * UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.mm: Copied from Source/WebKit/UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp.
            (WebKit::WebAuthenticationPanelClient::WebAuthenticationPanelClient):
            (WebKit::wkWebAuthenticationResult):
            (WebKit::WebAuthenticationPanelClient::dismissPanel const):
            * UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp:
            (WebKit::MockAuthenticatorManager::respondReceivedInternal):
            * UIProcess/WebAuthentication/WebAuthenticationPanelFlags.h: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h.
            * UIProcess/WebAuthentication/WebAuthenticationRequestData.h:
            * UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp:
            (WebKit::WebAuthenticatorCoordinatorProxy::makeCredential):
            (WebKit::WebAuthenticatorCoordinatorProxy::getAssertion):
            * WebKit.xcodeproj/project.pbxproj:

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/54723131>
    
    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 <https://webkit.org/b/202499>.
    
    * 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  <aestes@apple.com>

            [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
            <rdar://problem/54723131>

            Reviewed by Tim Horton.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::startInteractionWithElementAtPosition): Changed to call
            WebCore::Frame::nodeRespondingToInteraction.

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250431. rdar://problem/55927251

    Storage Access API: document.hasStorageAccess() should return false by default
    https://bugs.webkit.org/show_bug.cgi?id=202281
    <rdar://problem/55718526>
    
    Reviewed by Alex Christensen.
    
    document.hasStorageAccess() should return false by default so that it only
    returns true if the context has asked for and been granted storage access.
    
    Source/WebKit:
    
    * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp:
    (WebKit::ResourceLoadStatisticsDatabaseStore::hasStorageAccess):
    * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp:
    (WebKit::ResourceLoadStatisticsMemoryStore::hasStorageAccess):
    
    LayoutTests:
    
    * http/tests/storageAccess/has-storage-access-false-by-default-expected.txt: Added.
    * http/tests/storageAccess/has-storage-access-false-by-default.html: Added.
    * platform/ios/TestExpectations:
        The new test is marked as [ Pass ].
    * platform/mac-wk2/TestExpectations:
        The new test is marked as [ Pass ].
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250431 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-27  John Wilander  <wilander@apple.com>

            Storage Access API: document.hasStorageAccess() should return false by default
            https://bugs.webkit.org/show_bug.cgi?id=202281
            <rdar://problem/55718526>

            Reviewed by Alex Christensen.

            document.hasStorageAccess() should return false by default so that it only
            returns true if the context has asked for and been granted storage access.

            * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp:
            (WebKit::ResourceLoadStatisticsDatabaseStore::hasStorageAccess):
            * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp:
            (WebKit::ResourceLoadStatisticsMemoryStore::hasStorageAccess):

2019-10-15  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250416. rdar://problem/55954224

    SubFrameSOAuthorizationSession should ensure messages are posted in the right order to the parent frame
    https://bugs.webkit.org/show_bug.cgi?id=202061
    <rdar://problem/55485666>
    
    Reviewed by Youenn Fablet.
    
    Source/WebKit:
    
    This patch ensures messages that signal the process of SOAuthorization interception are posted in
    the right order to the parent frame. Before this patch, there are chances that SOAuthorizationDidCancel
    could be posted to the parent before SOAuthorizationDidStart. There are few causes that lead to
    this race condition:
    1) SubFrameSOAuthorizationSession::beforeStart posts SOAuthorizationDidStart in the next runloop. So
    extension could have the chance to invoke SubFrameSOAuthorizationSession::fallBackToWebPathInternal
    before SOAuthorizationDidStart is posted.
    2) Even if the order is right in the UI process, it is not guaranteed that Web process will strictly
    follow the order as the loading process is async.
    
    To fix the issue:
    1) SubFrameSOAuthorizationSession::beforeStart now posts SOAuthorizationDidStart in the same runloop.
    2) Observer is introduced in FrameLoadState such that SubFrameSOAuthorizationSession could know if
    the loading is finished. With this new capacity, SubFrameSOAuthorizationSession can ensure it only
    posts next message when the previous message has been posted.
    
    Implementation wise, a deque to queue requests is provided to maintain order.
    1) When new request is added to the deque, SubFrameSOAuthorizationSession will only load the request
    if it is the only element in the deque. Otherwise, it does nothing.
    2) When SubFrameSOAuthorizationSession receives didFinishLoad, it pops the head of the queue and loads
    the next request in the queue if any.
    The above design should guarantee all requests are loaded in sequence.
    
    * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h:
    * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm:
    (WebKit::SubFrameSOAuthorizationSession::SubFrameSOAuthorizationSession):
    (WebKit::SubFrameSOAuthorizationSession::~SubFrameSOAuthorizationSession):
    (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal):
    (WebKit::SubFrameSOAuthorizationSession::completeInternal):
    (WebKit::SubFrameSOAuthorizationSession::beforeStart):
    (WebKit::SubFrameSOAuthorizationSession::didFinishLoad):
    (WebKit::SubFrameSOAuthorizationSession::appendRequestToLoad):
    (WebKit::SubFrameSOAuthorizationSession::loadRequestToFrame):
    (WebKit::SubFrameSOAuthorizationSession::loadDataToFrame): Deleted.
    (WebKit::SubFrameSOAuthorizationSession::postDidCancelMessageToParent): Deleted.
    * UIProcess/FrameLoadState.cpp:
    (WebKit::FrameLoadState::addObserver):
    (WebKit::FrameLoadState::removeObserver):
    (WebKit::FrameLoadState::didFinishLoad):
    * UIProcess/FrameLoadState.h:
    
    Tools:
    
    Adds tests that check the order of messages posted by SubFrameSOAuthorizationSession.
    
    * TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm:
    (-[TestSOAuthorizationScriptMessageHandler userContentController:didReceiveScriptMessage:]):
    (resetState):
    (TestWebKitAPI::TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250416 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-27  Jiewen Tan  <jiewen_tan@apple.com>

            SubFrameSOAuthorizationSession should ensure messages are posted in the right order to the parent frame
            https://bugs.webkit.org/show_bug.cgi?id=202061
            <rdar://problem/55485666>

            Reviewed by Youenn Fablet.

            This patch ensures messages that signal the process of SOAuthorization interception are posted in
            the right order to the parent frame. Before this patch, there are chances that SOAuthorizationDidCancel
            could be posted to the parent before SOAuthorizationDidStart. There are few causes that lead to
            this race condition:
            1) SubFrameSOAuthorizationSession::beforeStart posts SOAuthorizationDidStart in the next runloop. So
            extension could have the chance to invoke SubFrameSOAuthorizationSession::fallBackToWebPathInternal
            before SOAuthorizationDidStart is posted.
            2) Even if the order is right in the UI process, it is not guaranteed that Web process will strictly
            follow the order as the loading process is async.

            To fix the issue:
            1) SubFrameSOAuthorizationSession::beforeStart now posts SOAuthorizationDidStart in the same runloop.
            2) Observer is introduced in FrameLoadState such that SubFrameSOAuthorizationSession could know if
            the loading is finished. With this new capacity, SubFrameSOAuthorizationSession can ensure it only
            posts next message when the previous message has been posted.

            Implementation wise, a deque to queue requests is provided to maintain order.
            1) When new request is added to the deque, SubFrameSOAuthorizationSession will only load the request
            if it is the only element in the deque. Otherwise, it does nothing.
            2) When SubFrameSOAuthorizationSession receives didFinishLoad, it pops the head of the queue and loads
            the next request in the queue if any.
            The above design should guarantee all requests are loaded in sequence.

            * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h:
            * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm:
            (WebKit::SubFrameSOAuthorizationSession::SubFrameSOAuthorizationSession):
            (WebKit::SubFrameSOAuthorizationSession::~SubFrameSOAuthorizationSession):
            (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal):
            (WebKit::SubFrameSOAuthorizationSession::completeInternal):
            (WebKit::SubFrameSOAuthorizationSession::beforeStart):
            (WebKit::SubFrameSOAuthorizationSession::didFinishLoad):
            (WebKit::SubFrameSOAuthorizationSession::appendRequestToLoad):
            (WebKit::SubFrameSOAuthorizationSession::loadRequestToFrame):
            (WebKit::SubFrameSOAuthorizationSession::loadDataToFrame): Deleted.
            (WebKit::SubFrameSOAuthorizationSession::postDidCancelMessageToParent): Deleted.
            * UIProcess/FrameLoadState.cpp:
            (WebKit::FrameLoadState::addObserver):
            (WebKit::FrameLoadState::removeObserver):
            (WebKit::FrameLoadState::didFinishLoad):
            * UIProcess/FrameLoadState.h:

2019-10-04  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250438. rdar://problem/55984974

    Unreviewed build-fix: wrap the AssertionServicesSPI.h in an IOS_FAMILY check.
    
    * WebProcess/cocoa/WebProcessCocoa.mm:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250438 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-27  Jer Noble  <jer.noble@apple.com>

            Unreviewed build-fix: wrap the AssertionServicesSPI.h in an IOS_FAMILY check.

            * WebProcess/cocoa/WebProcessCocoa.mm:

2019-10-04  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249600. rdar://problem/55989214

    [WebAuthn] Make WebAuthn default off and let clients turn it on at will
    https://bugs.webkit.org/show_bug.cgi?id=201439
    <rdar://problem/54998154>
    
    Reviewed by Youenn Fablet.
    
    This patch makes WebAuthn default off such that clients that have the right entitlements
    could turn it on and we don't risk at turning on a Web API that does nothing by default.
    
    This patch doesn't add any SPI to turn the feature on as it is currently doable via
    - [WKPreferencesPrivate _setEnabled:forExperimentalFeature:].
    
    * Shared/WebPreferences.yaml:
    * Shared/WebPreferencesDefaultValues.cpp:
    (WebKit::defaultWebAuthenticationEnabled): Deleted.
    * Shared/WebPreferencesDefaultValues.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249600 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-06  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Make WebAuthn default off and let clients turn it on at will
            https://bugs.webkit.org/show_bug.cgi?id=201439
            <rdar://problem/54998154>

            Reviewed by Youenn Fablet.

            This patch makes WebAuthn default off such that clients that have the right entitlements
            could turn it on and we don't risk at turning on a Web API that does nothing by default.

            This patch doesn't add any SPI to turn the feature on as it is currently doable via
            - [WKPreferencesPrivate _setEnabled:forExperimentalFeature:].

            * Shared/WebPreferences.yaml:
            * Shared/WebPreferencesDefaultValues.cpp:
            (WebKit::defaultWebAuthenticationEnabled): Deleted.
            * Shared/WebPreferencesDefaultValues.h:

2019-10-04  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249436. rdar://problem/55989217

    [WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService
    https://bugs.webkit.org/show_bug.cgi?id=201369
    <rdar://problem/54903724>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService
            https://bugs.webkit.org/show_bug.cgi?id=201369
            <rdar://problem/54903724>

            Reviewed by Brent Fulgham.

            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:

2019-10-03  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250659. rdar://problem/55954229

    Support googleLegacyAppidSupport extension
    https://bugs.webkit.org/show_bug.cgi?id=202427
    <rdar://problem/55887473>
    
    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  <jiewen_tan@apple.com>

            Support googleLegacyAppidSupport extension
            https://bugs.webkit.org/show_bug.cgi?id=202427
            <rdar://problem/55887473>

            Reviewed by Brent Fulgham.

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

2019-10-03  Alan Coon  <alancoon@apple.com>

        Cherry-pick r249949. rdar://problem/55964883

    [WebAuthn] Use WebPreferences instead of RuntimeEnabledFeatures in UIProcess
    https://bugs.webkit.org/show_bug.cgi?id=198176
    <rdar://problem/55285709>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Use WebPreferences instead of RuntimeEnabledFeatures in UIProcess
            https://bugs.webkit.org/show_bug.cgi?id=198176
            <rdar://problem/55285709>

            Reviewed by Youenn Fablet.

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

2019-08-06  Jiewen Tan  <jiewen_tan@apple.com>

        Unreviewed, a build fix after r248319. 

        Use HAVE(DATA_PROTECTION_KEYCHAIN) instead of HAVE_DATA_PROTECTION_KEYCHAIN.

        * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:
        (WebKit::LocalAuthenticator::makeCredential):
        (WebKit::LocalAuthenticator::continueMakeCredentialAfterUserConsented):
        (WebKit::LocalAuthenticator::continueMakeCredentialAfterAttested):
        (WebKit::LocalAuthenticator::getAssertion):
        (WebKit::LocalAuthenticator::continueGetAssertionAfterUserConsented):

2019-10-03  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248319. rdar://problem/55964805

    Unreviewed, a build fix after r248308
    
    Use kSecUseDataProtectionKeychain for iOS 13 and macOS Catalina or newer.
    
    Source/WebKit:
    
    * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:
    (WebKit::LocalAuthenticator::makeCredential):
    (WebKit::LocalAuthenticator::continueMakeCredentialAfterUserConsented):
    (WebKit::LocalAuthenticator::continueMakeCredentialAfterAttested):
    (WebKit::LocalAuthenticator::getAssertion):
    (WebKit::LocalAuthenticator::continueGetAssertionAfterUserConsented):
    
    Source/WTF:
    
    * wtf/Platform.h:
    
    Tools:
    
    * WebKitTestRunner/cocoa/TestControllerCocoa.mm:
    (WTR::TestController::addTestKeyToKeychain):
    (WTR::TestController::cleanUpKeychain):
    (WTR::TestController::keyExistsInKeychain):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248319 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-06  Jiewen Tan  <jiewen_tan@apple.com>

            Unreviewed, a build fix after r248308

            Use kSecUseDataProtectionKeychain for iOS 13 and macOS Catalina or newer.

            * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:
            (WebKit::LocalAuthenticator::makeCredential):
            (WebKit::LocalAuthenticator::continueMakeCredentialAfterUserConsented):
            (WebKit::LocalAuthenticator::continueMakeCredentialAfterAttested):
            (WebKit::LocalAuthenticator::getAssertion):
            (WebKit::LocalAuthenticator::continueGetAssertionAfterUserConsented):

2019-10-03  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248308. rdar://problem/55964805

    [WebAuthN] Enable LocalAuthenticator for macOS
    https://bugs.webkit.org/show_bug.cgi?id=182772
    <rdar://problem/43347920>
    
    Reviewed by Brent Fulgham.
    
    Source/WebKit:
    
    This patch enables LocalAuthenticator for macOS. The majority
    of this patch is to tweak macOS keychain to use the modern one.
    
    * Configurations/WebKit.xcconfig:
    * Platform/spi/Cocoa/DeviceIdentitySPI.h:
    * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:
    (WebKit::LocalAuthenticatorInternal::toVector):
    (WebKit::LocalAuthenticator::makeCredential):
    (WebKit::LocalAuthenticator::continueMakeCredentialAfterUserConsented):
    (WebKit::LocalAuthenticator::continueMakeCredentialAfterAttested):
    (WebKit::LocalAuthenticator::getAssertion):
    (WebKit::LocalAuthenticator::continueGetAssertionAfterUserConsented):
    * UIProcess/WebAuthentication/Cocoa/LocalConnection.mm:
    (WebKit::LocalConnection::getUserConsent const):
    (WebKit::LocalConnection::getAttestation const):
    * UIProcess/WebAuthentication/Cocoa/LocalService.mm:
    (WebKit::LocalService::isAvailable):
    * UIProcess/WebAuthentication/Mock/MockLocalConnection.mm:
    (WebKit::MockLocalConnection::getAttestation const):
    * config.h:
    
    Source/WTF:
    
    * wtf/Platform.h:
    Adds HAVE_DEVICE_IDENTITY.
    * wtf/spi/cocoa/SecuritySPI.h:
    Adds a SPI for telling macOS keychain to use the modern one.
    
    Tools:
    
    Add an entitlement file to WebKitTestRunner such that it can access
    the modern macOS keychain.
    
    * WebKitTestRunner/Configurations/WebKitTestRunner.entitlements: Added.
    * WebKitTestRunner/Configurations/WebKitTestRunner.xcconfig:
    * WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj:
    * WebKitTestRunner/cocoa/TestControllerCocoa.mm:
    (WTR::TestController::addTestKeyToKeychain):
    (WTR::TestController::cleanUpKeychain):
    (WTR::TestController::keyExistsInKeychain):
    
    LayoutTests:
    
    Enable existing local authenticator tests for macOS. Since OpenSource bots
    don't have the internal setting to include restricted entitlements, tests
    will fail on OpenSource bots.
    
    * platform/mac-wk2/TestExpectations:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248308 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-06  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthN] Enable LocalAuthenticator for macOS
            https://bugs.webkit.org/show_bug.cgi?id=182772
            <rdar://problem/43347920>

            Reviewed by Brent Fulgham.

            This patch enables LocalAuthenticator for macOS. The majority
            of this patch is to tweak macOS keychain to use the modern one.

            * Configurations/WebKit.xcconfig:
            * Platform/spi/Cocoa/DeviceIdentitySPI.h:
            * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:
            (WebKit::LocalAuthenticatorInternal::toVector):
            (WebKit::LocalAuthenticator::makeCredential):
            (WebKit::LocalAuthenticator::continueMakeCredentialAfterUserConsented):
            (WebKit::LocalAuthenticator::continueMakeCredentialAfterAttested):
            (WebKit::LocalAuthenticator::getAssertion):
            (WebKit::LocalAuthenticator::continueGetAssertionAfterUserConsented):
            * UIProcess/WebAuthentication/Cocoa/LocalConnection.mm:
            (WebKit::LocalConnection::getUserConsent const):
            (WebKit::LocalConnection::getAttestation const):
            * UIProcess/WebAuthentication/Cocoa/LocalService.mm:
            (WebKit::LocalService::isAvailable):
            * UIProcess/WebAuthentication/Mock/MockLocalConnection.mm:
            (WebKit::MockLocalConnection::getAttestation const):
            * config.h:

2019-10-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249108. rdar://problem/55927253

    [WebAuthn] Support HID authenticators on iOS
    https://bugs.webkit.org/show_bug.cgi?id=201084
    <rdar://problem/51908390>
    
    Reviewed by Youenn Fablet.
    
    Source/WebCore/PAL:
    
    * pal/spi/cocoa/IOKitSPI.h:
    Move IOHIDDevice.h and IOHIDManager.h to IOKitSPI.h given they are in iOS.
    
    Source/WebKit:
    
    This patch makes the macOS HID implementation available in iOS as well.
    Mostly, it removes the PLATFORM(MAC) compile time flag.
    
    * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
    (WebKit::AuthenticatorManagerInternal::collectTransports):
    * UIProcess/WebAuthentication/AuthenticatorTransportService.cpp:
    (WebKit::AuthenticatorTransportService::create):
    (WebKit::AuthenticatorTransportService::createMock):
    * UIProcess/WebAuthentication/Cocoa/HidConnection.h:
    * UIProcess/WebAuthentication/Cocoa/HidConnection.mm:
    * UIProcess/WebAuthentication/Cocoa/HidService.h:
    * UIProcess/WebAuthentication/Cocoa/HidService.mm:
    * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm:
    (WebKit::NfcConnection::NfcConnection):
    A tentative solution before there is an official UI.
    * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp:
    * UIProcess/WebAuthentication/Mock/MockHidConnection.h:
    * UIProcess/WebAuthentication/Mock/MockHidService.cpp:
    * UIProcess/WebAuthentication/Mock/MockHidService.h:
    * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp:
    * UIProcess/WebAuthentication/fido/CtapHidDriver.h:
    
    LayoutTests:
    
    * platform/ios-wk2/TestExpectations:
    Unskips HID tests for iOS.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249108 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-26  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Support HID authenticators on iOS
            https://bugs.webkit.org/show_bug.cgi?id=201084
            <rdar://problem/51908390>

            Reviewed by Youenn Fablet.

            This patch makes the macOS HID implementation available in iOS as well.
            Mostly, it removes the PLATFORM(MAC) compile time flag.

            * UIProcess/WebAuthentication/AuthenticatorManager.cpp:
            (WebKit::AuthenticatorManagerInternal::collectTransports):
            * UIProcess/WebAuthentication/AuthenticatorTransportService.cpp:
            (WebKit::AuthenticatorTransportService::create):
            (WebKit::AuthenticatorTransportService::createMock):
            * UIProcess/WebAuthentication/Cocoa/HidConnection.h:
            * UIProcess/WebAuthentication/Cocoa/HidConnection.mm:
            * UIProcess/WebAuthentication/Cocoa/HidService.h:
            * UIProcess/WebAuthentication/Cocoa/HidService.mm:
            * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm:
            (WebKit::NfcConnection::NfcConnection):
            A tentative solution before there is an official UI.
            * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp:
            * UIProcess/WebAuthentication/Mock/MockHidConnection.h:
            * UIProcess/WebAuthentication/Mock/MockHidService.cpp:
            * UIProcess/WebAuthentication/Mock/MockHidService.h:
            * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp:
            * UIProcess/WebAuthentication/fido/CtapHidDriver.h:

2019-10-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249068. rdar://problem/55927255

    Unreviewed, build fix after r249059
    
    Source/WebKit:
    
    * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm:
    (WebKit::NfcConnection::NfcConnection):
    Remove the HAVE() macro.
    
    Source/WTF:
    
    * wtf/Platform.h:
    Make HAVE_NEAR_FIELD available only on iOS 13+ and macOS Catalina+.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249068 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-23  Jiewen Tan  <jiewen_tan@apple.com>

            Unreviewed, build fix after r249059

            * UIProcess/WebAuthentication/Cocoa/NfcConnection.mm:
            (WebKit::NfcConnection::NfcConnection):
            Remove the HAVE() macro.

2019-10-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249059. rdar://problem/55927255

    [WebAuthn] Support NFC authenticators for iOS
    https://bugs.webkit.org/show_bug.cgi?id=188624
    <rdar://problem/43354214>
    
    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  <jiewen_tan@apple.com>

            [WebAuthn] Support NFC authenticators for iOS
            https://bugs.webkit.org/show_bug.cgi?id=188624
            <rdar://problem/43354214>

            Reviewed by Chris Dumez.

            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:

2019-10-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r248631. rdar://problem/55934340

    [WebAuthn] Make CtapHidAuthenticator/U2fHidAuthenticator to CtapAuthenticator/U2fAuthenticator
    https://bugs.webkit.org/show_bug.cgi?id=191527
    <rdar://problem/54237146>
    
    Reviewed by Chris Dumez.
    
    This patch makes an ABC CtapDriver, which services as an abstract interface for CtapAuthenticator/U2fAuthenticator to talk to
    the actual object that implement the specific CTAP protocol that mananges communications over different transports, for example,
    CtapHidDriver, such that CtapAuthenticator/U2fAuthenticator can be shared across different transports.
    
    This patch also renames CtapHidAuthenticator/U2fHidAuthenticator to CtapAuthenticator/U2fAuthenticator correspondingly.
    
    * Sources.txt:
    * UIProcess/WebAuthentication/Cocoa/HidService.mm:
    (WebKit::HidService::continueAddDeviceAfterGetInfo):
    * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidAuthenticator.cpp.
    (WebKit::CtapAuthenticator::CtapAuthenticator):
    (WebKit::CtapAuthenticator::makeCredential):
    (WebKit::CtapAuthenticator::continueMakeCredentialAfterResponseReceived const):
    (WebKit::CtapAuthenticator::getAssertion):
    (WebKit::CtapAuthenticator::continueGetAssertionAfterResponseReceived):
    (WebKit::CtapAuthenticator::tryDowngrade):
    * UIProcess/WebAuthentication/fido/CtapAuthenticator.h: Copied from Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidAuthenticator.h.
    * UIProcess/WebAuthentication/fido/CtapDriver.h: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidAuthenticator.h.
    * UIProcess/WebAuthentication/fido/CtapHidDriver.h:
    (WebKit::CtapHidDriver::setProtocol):
    * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/U2fHidAuthenticator.cpp.
    (WebKit::U2fAuthenticator::U2fAuthenticator):
    (WebKit::U2fAuthenticator::makeCredential):
    (WebKit::U2fAuthenticator::checkExcludeList):
    (WebKit::U2fAuthenticator::issueRegisterCommand):
    (WebKit::U2fAuthenticator::getAssertion):
    (WebKit::U2fAuthenticator::issueSignCommand):
    (WebKit::U2fAuthenticator::issueNewCommand):
    (WebKit::U2fAuthenticator::issueCommand):
    (WebKit::U2fAuthenticator::responseReceived):
    (WebKit::U2fAuthenticator::continueRegisterCommandAfterResponseReceived):
    (WebKit::U2fAuthenticator::continueCheckOnlyCommandAfterResponseReceived):
    (WebKit::U2fAuthenticator::continueBogusCommandAfterResponseReceived):
    (WebKit::U2fAuthenticator::continueSignCommandAfterResponseReceived):
    * UIProcess/WebAuthentication/fido/U2fAuthenticator.h: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/U2fHidAuthenticator.h.
    * WebKit.xcodeproj/project.pbxproj:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248631 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-12  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Make CtapHidAuthenticator/U2fHidAuthenticator to CtapAuthenticator/U2fAuthenticator
            https://bugs.webkit.org/show_bug.cgi?id=191527
            <rdar://problem/54237146>

            Reviewed by Chris Dumez.

            This patch makes an ABC CtapDriver, which services as an abstract interface for CtapAuthenticator/U2fAuthenticator to talk to
            the actual object that implement the specific CTAP protocol that mananges communications over different transports, for example,
            CtapHidDriver, such that CtapAuthenticator/U2fAuthenticator can be shared across different transports.

            This patch also renames CtapHidAuthenticator/U2fHidAuthenticator to CtapAuthenticator/U2fAuthenticator correspondingly.

            * Sources.txt:
            * UIProcess/WebAuthentication/Cocoa/HidService.mm:
            (WebKit::HidService::continueAddDeviceAfterGetInfo):
            * UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidAuthenticator.cpp.
            (WebKit::CtapAuthenticator::CtapAuthenticator):
            (WebKit::CtapAuthenticator::makeCredential):
            (WebKit::CtapAuthenticator::continueMakeCredentialAfterResponseReceived const):
            (WebKit::CtapAuthenticator::getAssertion):
            (WebKit::CtapAuthenticator::continueGetAssertionAfterResponseReceived):
            (WebKit::CtapAuthenticator::tryDowngrade):
            * UIProcess/WebAuthentication/fido/CtapAuthenticator.h: Copied from Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidAuthenticator.h.
            * UIProcess/WebAuthentication/fido/CtapDriver.h: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidAuthenticator.h.
            * UIProcess/WebAuthentication/fido/CtapHidDriver.h:
            (WebKit::CtapHidDriver::setProtocol):
            * UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/U2fHidAuthenticator.cpp.
            (WebKit::U2fAuthenticator::U2fAuthenticator):
            (WebKit::U2fAuthenticator::makeCredential):
            (WebKit::U2fAuthenticator::checkExcludeList):
            (WebKit::U2fAuthenticator::issueRegisterCommand):
            (WebKit::U2fAuthenticator::getAssertion):
            (WebKit::U2fAuthenticator::issueSignCommand):
            (WebKit::U2fAuthenticator::issueNewCommand):
            (WebKit::U2fAuthenticator::issueCommand):
            (WebKit::U2fAuthenticator::responseReceived):
            (WebKit::U2fAuthenticator::continueRegisterCommandAfterResponseReceived):
            (WebKit::U2fAuthenticator::continueCheckOnlyCommandAfterResponseReceived):
            (WebKit::U2fAuthenticator::continueBogusCommandAfterResponseReceived):
            (WebKit::U2fAuthenticator::continueSignCommandAfterResponseReceived):
            * UIProcess/WebAuthentication/fido/U2fAuthenticator.h: Renamed from Source/WebKit/UIProcess/WebAuthentication/fido/U2fHidAuthenticator.h.
            * WebKit.xcodeproj/project.pbxproj:

2019-10-03  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250658. rdar://problem/55954221

    [WebAuthn] Implement dummy _WKWebAuthenticationPanel SPI
    https://bugs.webkit.org/show_bug.cgi?id=202507
    <rdar://problem/55918793>
    
    Reviewed by Brent Fulgham.
    
    This patch implements dummy _WKWebAuthenticationPanel SPI to unblock Safari.
    
    Here are the illustrations for each SPI:
    1) -[WKUIDelegatePrivate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:] is used at the beginning of
    any WebAuthn ceremonies. A WKFrameInfo is provided for more info of the initiating frame so clients could decide either show
    the RP ID or the origin of the frame which may or may not be the RP ID. A callback of _WKWebAuthenticationPanelResult is
    provided such that clients could inform WebKit to continue the ceremony or not. Case like rate limiting of a modular dialog
    could result in _WKWebAuthenticationPanelResultDidNotPresent. Then WebKit will abort the operation.
    _WKWebAuthenticationPanelResultUnavailable tells WebKit the client has no UI implemented and therefore WebKit will operate
    in a non UI mode which basically will only enable HID authenticators, and is the current behavior of macOS Safari.
    2) -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] is primarily to instruct users to do some
    actionable thing to recover from some error state. However, it could be used for pure info as well. For
    _WKWebAuthenticationPanelInfoMultipleNFCTagPresents, users can be instructed to only hold one NFC tag to the scanner. For
    _WKWebAuthenticationPanelInfoNoCredentialsFound, users can potentially switch to another security key that could hit a match.
    3) -[_WKWebAuthenticationPanelDelegate panel:dismissWebAuthenticationPanelWithResult:] is to dismiss UI.
    _WKWebAuthenticationResult is provided such that client could show different animations as a hint to the user. The reasons for
    failure could either be timeout or InvalidStateError which will be reported to the page as well. InvalidStateError signals a
    credential matching an entry of the exclude list (excludeCredentials) is found on the authenticator.
    4) -[_WKWebAuthenticationPanel cancel] is the way clients tell WebKit a user cancel.
    
    * SourcesCocoa.txt:
    * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
    * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.h: Added.
    * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm: Added.
    (-[_WKWebAuthenticationPanel _initWithRelayingPartyID:]):
    (-[_WKWebAuthenticationPanel relyingPartyID]):
    (-[_WKWebAuthenticationPanel cancel]):
    * UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h: Added.
    * WebKit.xcodeproj/project.pbxproj:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250658 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-03  Jiewen Tan  <jiewen_tan@apple.com>

            [WebAuthn] Implement dummy _WKWebAuthenticationPanel SPI
            https://bugs.webkit.org/show_bug.cgi?id=202507
            <rdar://problem/55918793>

            Reviewed by Brent Fulgham.

            This patch implements dummy _WKWebAuthenticationPanel SPI to unblock Safari.

            Here are the illustrations for each SPI:
            1) -[WKUIDelegatePrivate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:] is used at the beginning of
            any WebAuthn ceremonies. A WKFrameInfo is provided for more info of the initiating frame so clients could decide either show
            the RP ID or the origin of the frame which may or may not be the RP ID. A callback of _WKWebAuthenticationPanelResult is
            provided such that clients could inform WebKit to continue the ceremony or not. Case like rate limiting of a modular dialog
            could result in _WKWebAuthenticationPanelResultDidNotPresent. Then WebKit will abort the operation.
            _WKWebAuthenticationPanelResultUnavailable tells WebKit the client has no UI implemented and therefore WebKit will operate
            in a non UI mode which basically will only enable HID authenticators, and is the current behavior of macOS Safari.
            2) -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] is primarily to instruct users to do some
            actionable thing to recover from some error state. However, it could be used for pure info as well. For
            _WKWebAuthenticationPanelInfoMultipleNFCTagPresents, users can be instructed to only hold one NFC tag to the scanner. For
            _WKWebAuthenticationPanelInfoNoCredentialsFound, users can potentially switch to another security key that could hit a match.
            3) -[_WKWebAuthenticationPanelDelegate panel:dismissWebAuthenticationPanelWithResult:] is to dismiss UI.
            _WKWebAuthenticationResult is provided such that client could show different animations as a hint to the user. The reasons for
            failure could either be timeout or InvalidStateError which will be reported to the page as well. InvalidStateError signals a
            credential matching an entry of the exclude list (excludeCredentials) is found on the authenticator.
            4) -[_WKWebAuthenticationPanel cancel] is the way clients tell WebKit a user cancel.

            * SourcesCocoa.txt:
            * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
            * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.h: Added.
            * UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm: Added.
            (-[_WKWebAuthenticationPanel _initWithRelayingPartyID:]):
            (-[_WKWebAuthenticationPanel relyingPartyID]):
            (-[_WKWebAuthenticationPanel cancel]):
            * UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h: Added.
            * WebKit.xcodeproj/project.pbxproj:

2019-10-02  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250619. rdar://problem/55927263

    Provide originating website URL to AR QuickLook
    https://bugs.webkit.org/show_bug.cgi?id=202451
    
    Reviewed by Antoine Quint.
    
    Declare the setAdditionalParameters method and
    call it with the originating page URL if available.
    
    * UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250619 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-10-02  Dean Jackson  <dino@apple.com>

            Provide originating website URL to AR QuickLook
            https://bugs.webkit.org/show_bug.cgi?id=202451

            Reviewed by Antoine Quint.

            Declare the setAdditionalParameters method and
            call it with the originating page URL if available.

            * UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:

2019-10-02  Alan Coon  <alancoon@apple.com>

        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
    <rdar://54904781>
    
    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<ResourceRequest>::encode):
    (IPC::ArgumentCoder<ResourceRequest>::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  <dino@apple.com>

            Provide a prototype for AR QuickLook to trigger processing in the originating page
            https://bugs.webkit.org/show_bug.cgi?id=201371
            <rdar://54904781>

            Reviewed by Simon Fraser.

            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<ResourceRequest>::encode):
            (IPC::ArgumentCoder<ResourceRequest>::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:

2019-09-30  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250428. rdar://problem/55825357

    [iOS] Lock screen controls can fail to play web content
    https://bugs.webkit.org/show_bug.cgi?id=202279
    
    Reviewed by Chris Dumez.
    
    When playback is paused from the lock screen via Now Playing controls, the WebProcess,
    UIProcess, and Network Process will all be suspended. MediaRemote will take an assertion
    and wake up the WebProcess when a remote control command to "play" is sent via the Now
    Playing controls. However, if a synchronous message to the (suspended) Network or UIProcess
    is issued before the notification that the process was unexpectedly unsuspended can be
    issued (which will subsequently unsuspend the UIProcess and Network process), we can get
    into a deadlocked state where the main thread is blocked on the sync message to a suspended
    process.
    
    To work around this problem, move all the processing from ProcessTaskStateObserver to a
    WorkQueue / background thread. This requires making the ProcessTaskStateObserver thread-safe,
    though its only current client is a Singleton (the WebProcess class), and so the risk of
    thread safety issues is currently minimal. Regardless, access to the Client pointer must be
    guarded by a Lock, and the Client itself must become ref-counted, so that the
    ProcessTaskStateObserver can ref its Client (the WebProcess) during callback processing.
    
    Unfortunately, sendWithAsyncReply() is not thread safe, nor is ProcessAssertion, so instead
    just use send() and set a 5-second timeout before expiring the assertion, and just use
    BKSProcessStateAssertion directly.
    
    * Shared/Cocoa/ProcessTaskStateObserver.h:
    (WebKit::ProcessTaskStateObserver::Client::ref):
    (WebKit::ProcessTaskStateObserver::Client::deref):
    (WebKit::ProcessTaskStateObserver::setClient): Deleted.
    (WebKit::ProcessTaskStateObserver::client): Deleted.
    * Shared/Cocoa/ProcessTaskStateObserver.mm:
    (-[WKProcessTaskStateObserverDelegate process:taskStateDidChange:]):
    (WebKit::ProcessTaskStateObserver::create):
    (WebKit::ProcessTaskStateObserver::ProcessTaskStateObserver):
    (WebKit::ProcessTaskStateObserver::~ProcessTaskStateObserver):
    (WebKit::ProcessTaskStateObserver::invalidate):
    (WebKit::ProcessTaskStateObserver::client):
    (WebKit::ProcessTaskStateObserver::setTaskState):
    * WebProcess/WebProcess.cpp:
    (WebKit::m_taskStateObserver):
    * WebProcess/WebProcess.h:
    * UIProcess/Cocoa/WebProcessProxyCocoa.mm:
    (WebKit::WebProcessProxy::processWasUnexpectedlyUnsuspended):
    * UIProcess/WebProcessProxy.h:
    * UIProcess/WebProcessProxy.messages.in:
    * WebProcess/cocoa/WebProcessCocoa.mm:
    (WebKit::WebProcess::processTaskStateDidChange):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250428 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-27  Jer Noble  <jer.noble@apple.com>

            [iOS] Lock screen controls can fail to play web content
            https://bugs.webkit.org/show_bug.cgi?id=202279

            Reviewed by Chris Dumez.

            When playback is paused from the lock screen via Now Playing controls, the WebProcess,
            UIProcess, and Network Process will all be suspended. MediaRemote will take an assertion
            and wake up the WebProcess when a remote control command to "play" is sent via the Now
            Playing controls. However, if a synchronous message to the (suspended) Network or UIProcess
            is issued before the notification that the process was unexpectedly unsuspended can be
            issued (which will subsequently unsuspend the UIProcess and Network process), we can get
            into a deadlocked state where the main thread is blocked on the sync message to a suspended
            process.

            To work around this problem, move all the processing from ProcessTaskStateObserver to a
            WorkQueue / background thread. This requires making the ProcessTaskStateObserver thread-safe,
            though its only current client is a Singleton (the WebProcess class), and so the risk of
            thread safety issues is currently minimal. Regardless, access to the Client pointer must be
            guarded by a Lock, and the Client itself must become ref-counted, so that the
            ProcessTaskStateObserver can ref its Client (the WebProcess) during callback processing.

            Unfortunately, sendWithAsyncReply() is not thread safe, nor is ProcessAssertion, so instead
            just use send() and set a 5-second timeout before expiring the assertion, and just use
            BKSProcessStateAssertion directly.

            * Shared/Cocoa/ProcessTaskStateObserver.h:
            (WebKit::ProcessTaskStateObserver::Client::ref):
            (WebKit::ProcessTaskStateObserver::Client::deref):
            (WebKit::ProcessTaskStateObserver::setClient): Deleted.
            (WebKit::ProcessTaskStateObserver::client): Deleted.
            * Shared/Cocoa/ProcessTaskStateObserver.mm:
            (-[WKProcessTaskStateObserverDelegate process:taskStateDidChange:]):
            (WebKit::ProcessTaskStateObserver::create):
            (WebKit::ProcessTaskStateObserver::ProcessTaskStateObserver):
            (WebKit::ProcessTaskStateObserver::~ProcessTaskStateObserver):
            (WebKit::ProcessTaskStateObserver::invalidate):
            (WebKit::ProcessTaskStateObserver::client):
            (WebKit::ProcessTaskStateObserver::setTaskState):
            * WebProcess/WebProcess.cpp:
            (WebKit::m_taskStateObserver):
            * WebProcess/WebProcess.h:
            * UIProcess/Cocoa/WebProcessProxyCocoa.mm:
            (WebKit::WebProcessProxy::processWasUnexpectedlyUnsuspended):
            * UIProcess/WebProcessProxy.h:
            * UIProcess/WebProcessProxy.messages.in:
            * WebProcess/cocoa/WebProcessCocoa.mm:
            (WebKit::WebProcess::processTaskStateDidChange):

2019-09-30  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250405. rdar://problem/55825353

    Add some logging to help diagnose blank or stuck WKWebViews
    https://bugs.webkit.org/show_bug.cgi?id=202297
    <rdar://problem/55763610>
    
    Reviewed by Wenson Hsieh.
    
    Our current logging is insufficient to rule out some of the potential
    causes of stuck/blank WKWebViews in <rdar://problem/53399054>. Add
    some new logging, and improve some existing logging, to aid in diagnosis.
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _willInvokeUIScrollViewDelegateCallback]):
    (-[WKWebView _didInvokeUIScrollViewDelegateCallback]):
    Rename _delayUpdateVisibleContentRects to be more specific that it
    was due to us being underneath a UIScrollView delegate callback.
    
    (-[WKWebView _processWillSwapOrDidExit]):
    (-[WKWebView _didCommitLayerTree:]):
    Add a log when we receive an incoming commit while visible content rect
    updates are being deferred. Also, include the current transaction ID
    and the transaction ID that _needsResetViewState... is waiting for, to
    help rule out a class of potential problems.
    
    Add a log when we receive an incoming commit more than 5 seconds after
    a visible content rect update.
    
    (-[WKWebView _updateVisibleContentRects]):
    Keep track of when we defer visual content rect updates for any reason,
    and log the first time we do an update after deferring them. This will make
    it MUCH easier at-a-glance to tell if one of the "bailing" messages
    represents a long-term state (a problem), or is expected.
    
    Keep track of how long it's been since we sent a visible content rect update
    and didn't get a commit back from the Web Content process; if it's been
    more than 5 seconds, start logging.
    
    (-[WKWebView _cancelAnimatedResize]):
    (-[WKWebView _didCompleteAnimatedResize]):
    (-[WKWebView _beginAnimatedResizeWithUpdates:]):
    (-[WKWebView _endAnimatedResize]):
    (-[WKWebView _resizeWhileHidingContentWithUpdates:]):
    Turn animated resize logging into release logging. It is a common culprit
    for many kinds of bugs, while also not being high volume, so this is well worth it.
    
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::freezeLayerTree):
    (WebKit::WebPage::unfreezeLayerTree):
    Show the current value of m_layerTreeFreezeReasons in addition to the old value and delta,
    so you don't have to manually compute the current value when reading logs.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250405 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-26  Tim Horton  <timothy_horton@apple.com>

            Add some logging to help diagnose blank or stuck WKWebViews
            https://bugs.webkit.org/show_bug.cgi?id=202297
            <rdar://problem/55763610>

            Reviewed by Wenson Hsieh.

            Our current logging is insufficient to rule out some of the potential
            causes of stuck/blank WKWebViews in <rdar://problem/53399054>. Add
            some new logging, and improve some existing logging, to aid in diagnosis.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _willInvokeUIScrollViewDelegateCallback]):
            (-[WKWebView _didInvokeUIScrollViewDelegateCallback]):
            Rename _delayUpdateVisibleContentRects to be more specific that it
            was due to us being underneath a UIScrollView delegate callback.

            (-[WKWebView _processWillSwapOrDidExit]):
            (-[WKWebView _didCommitLayerTree:]):
            Add a log when we receive an incoming commit while visible content rect
            updates are being deferred. Also, include the current transaction ID
            and the transaction ID that _needsResetViewState... is waiting for, to
            help rule out a class of potential problems.

            Add a log when we receive an incoming commit more than 5 seconds after
            a visible content rect update.

            (-[WKWebView _updateVisibleContentRects]):
            Keep track of when we defer visual content rect updates for any reason,
            and log the first time we do an update after deferring them. This will make
            it MUCH easier at-a-glance to tell if one of the "bailing" messages
            represents a long-term state (a problem), or is expected.

            Keep track of how long it's been since we sent a visible content rect update
            and didn't get a commit back from the Web Content process; if it's been
            more than 5 seconds, start logging.

            (-[WKWebView _cancelAnimatedResize]):
            (-[WKWebView _didCompleteAnimatedResize]):
            (-[WKWebView _beginAnimatedResizeWithUpdates:]):
            (-[WKWebView _endAnimatedResize]):
            (-[WKWebView _resizeWhileHidingContentWithUpdates:]):
            Turn animated resize logging into release logging. It is a common culprit
            for many kinds of bugs, while also not being high volume, so this is well worth it.

            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::freezeLayerTree):
            (WebKit::WebPage::unfreezeLayerTree):
            Show the current value of m_layerTreeFreezeReasons in addition to the old value and delta,
            so you don't have to manually compute the current value when reading logs.

2019-09-30  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r250394. rdar://problem/55826250

    Crash under WebPage::beginPrinting when m_printContext becomes null due to synchronous layout
    https://bugs.webkit.org/show_bug.cgi?id=202171
    <rdar://problem/49731211>
    
    Reviewed by Tim Horton.
    
    Speculatively fix a null pointer dereference crash in WebPage::beginPrinting.
    
    WebPage::beginPrinting creates a PrintContext, stores it in m_printContext, then calls
    PrintContext::begin which forces a synchronous, paginated layout. If a post-layout task
    executes script, that might result in the WebPage being closed and m_printContext being set
    to nullptr.
    
    Guard against this in WebPage::beginPrinting by adding a null check before calling
    PrintContext::computePageRects.
    
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::beginPrinting):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250394 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-26  Andy Estes  <aestes@apple.com>

            Crash under WebPage::beginPrinting when m_printContext becomes null due to synchronous layout
            https://bugs.webkit.org/show_bug.cgi?id=202171
            <rdar://problem/49731211>

            Reviewed by Tim Horton.

            Speculatively fix a null pointer dereference crash in WebPage::beginPrinting.

            WebPage::beginPrinting creates a PrintContext, stores it in m_printContext, then calls
            PrintContext::begin which forces a synchronous, paginated layout. If a post-layout task
            executes script, that might result in the WebPage being closed and m_printContext being set
            to nullptr.

            Guard against this in WebPage::beginPrinting by adding a null check before calling
            PrintContext::computePageRects.

            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::beginPrinting):

2019-09-29  Alan Coon  <alancoon@apple.com>

        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
    <rdar://problem/55185021>
    
    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  <wenson_hsieh@apple.com>

            [iPadOS] [DataActivation] Focus moves away after focusing input fields on www.att.com
            https://bugs.webkit.org/show_bug.cgi?id=202167
            <rdar://problem/55185021>

            Reviewed by Tim Horton.

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

2019-09-29  Babak Shafiei  <bshafiei@apple.com>

        Apply patch. rdar://problem/55801087

    2019-09-29  John Wilander  <wilander@apple.com>

            Cherry-pick r250413.

            Patch by Kate Cheney <katherine_cheney@apple.com> on 2019-09-26.

            Resource Load Statistics: Downgrade all third-party referrer headers
            https://bugs.webkit.org/show_bug.cgi?id=201353
            <rdar://problem/54895650>

            Majority of this patch was written by John Wilander <wilander@apple.com>.

            Reviewed by Brent Fulgham.

            When tracking protections are enabled, we should downgrade all third-party
            referrers to their origins. Note that this downgrade will be specific to
            Cocoa so other ports will have to adopt as they see fit.

            Cocoa already does this downgrade in ephemeral sessions (shipping).

            The majority of these changes are test infrastructure. The functional
            change is in WebKit::NetworkDataTaskCocoa and WebKit::NetworkSession.

            * NetworkProcess/NetworkProcess.cpp:
            (WebKit::NetworkProcess::setShouldDowngradeReferrerForTesting):
            * NetworkProcess/NetworkProcess.h:
            * NetworkProcess/NetworkProcess.messages.in:
            * NetworkProcess/NetworkSession.cpp:
            (WebKit::NetworkSession::isResourceLoadStatisticsEnabled const):
            (WebKit::NetworkSession::setShouldDowngradeReferrerForTesting):
            (WebKit::NetworkSession::shouldDowngradeReferrer const):
            * NetworkProcess/NetworkSession.h:
            * NetworkProcess/cocoa/NetworkDataTaskCocoa.h:
            * NetworkProcess/cocoa/NetworkDataTaskCocoa.mm:
            (WebKit::NetworkDataTaskCocoa::isThirdPartyRequest const):
            (WebKit::NetworkDataTaskCocoa::NetworkDataTaskCocoa):
            (WebKit::NetworkDataTaskCocoa::restrictRequestReferrerToOriginIfNeeded):
            (WebKit::NetworkDataTaskCocoa::willPerformHTTPRedirection):
            (WebKit::NetworkDataTaskCocoa::isThirdPartyRequest): Deleted.
            * UIProcess/API/C/WKWebsiteDataStoreRef.cpp:
            (WKWebsiteDataStoreSetResourceLoadStatisticsShouldDowngradeReferrerForTesting):
            (WKWebsiteDataStoreStatisticsResetToConsistentState):
            * UIProcess/API/C/WKWebsiteDataStoreRef.h:
            * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h:
                Added missing property configureJSCForTesting to fix the build.
            * UIProcess/Network/NetworkProcessProxy.cpp:
            (WebKit::NetworkProcessProxy::setShouldDowngradeReferrerForTesting):
            * UIProcess/Network/NetworkProcessProxy.h:
            * UIProcess/WebsiteData/WebsiteDataStore.cpp:
            (WebKit::WebsiteDataStore::setResourceLoadStatisticsShouldDowngradeReferrerForTesting):
            * UIProcess/WebsiteData/WebsiteDataStore.h:

2019-09-27  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250432. rdar://problem/55801091

    [iOS]: When inserting a photo and then inserting auto-corrected text, the photo is removed
    https://bugs.webkit.org/show_bug.cgi?id=202294
    
    Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-09-27
    Reviewed by Wenson Hsieh.
    
    Source/WebKit:
    
    WebPage::applyAutocorrectionInternal() calls wordRangeFromPosition() to
    calculate the range of the word to be replaced with the auto-corrected
    word. But if the text of the range does not match the original text,
    applyAutocorrectionInternal() tries to correct the range by moving it
    forward such that the length of the text range matches the length of the
    original text.
    
    Another case, which should correct the range also, is: the range does not
    have a text but it is not collapsed. In this case, we should set the range
    back to the selection range so non-text nodes is removed.
    
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::applyAutocorrectionInternal):
    
    LayoutTests:
    
    * fast/events/ios/autocorrect-after-image-expected.txt: Added.
    * fast/events/ios/autocorrect-after-image.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250432 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-27  Said Abou-Hallawa  <sabouhallawa@apple.com>

            [iOS]: When inserting a photo and then inserting auto-corrected text, the photo is removed
            https://bugs.webkit.org/show_bug.cgi?id=202294

            Reviewed by Wenson Hsieh.

            WebPage::applyAutocorrectionInternal() calls wordRangeFromPosition() to
            calculate the range of the word to be replaced with the auto-corrected
            word. But if the text of the range does not match the original text,
            applyAutocorrectionInternal() tries to correct the range by moving it
            forward such that the length of the text range matches the length of the
            original text.

            Another case, which should correct the range also, is: the range does not
            have a text but it is not collapsed. In this case, we should set the range
            back to the selection range so non-text nodes is removed.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::applyAutocorrectionInternal):

2019-09-27  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250401. rdar://problem/55770702

    ContextMenu on a link in an email no longer shows web preview
    https://bugs.webkit.org/show_bug.cgi?id=201120
    <rdar://54353617>
    
    Reviewed by Wenson Hsieh.
    
    Source/WebKit:
    
    Only go down the image path if we are not also a link.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView continueContextMenuInteraction:]):
    
    Tools:
    
    Test context menus on a link that is also an image.
    
    * TestWebKitAPI/Tests/WebKitCocoa/ContextMenus.mm:
    (contextMenuWebViewDriver):
    (-[TestContextMenuImageWithoutConfigurationUIDelegate webView:contextMenuConfigurationForElement:completionHandler:]):
    (-[TestContextMenuImageWithoutConfigurationUIDelegate webView:contextMenuWillPresentForElement:]):
    (-[TestContextMenuImageWithoutConfigurationUIDelegate webView:contextMenuForElement:willCommitWithAnimator:]):
    (-[TestContextMenuImageWithoutConfigurationUIDelegate webView:contextMenuDidEndForElement:]):
    (TEST):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250401 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-26  Dean Jackson  <dino@apple.com>

            ContextMenu on a link in an email no longer shows web preview
            https://bugs.webkit.org/show_bug.cgi?id=201120
            <rdar://54353617>

            Reviewed by Wenson Hsieh.

            Only go down the image path if we are not also a link.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView continueContextMenuInteraction:]):

2019-09-27  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250392. rdar://problem/55770703

    [iOS 13] Tapping on a non-editable text selection should toggle callout bar visibility instead of clearing selection
    https://bugs.webkit.org/show_bug.cgi?id=202254
    <rdar://problem/54410263>
    
    Reviewed by Megan Gardner.
    
    Source/WebKit:
    
    In iOS 13, tapping a text selection should toggle callout bar visibility (i.e. "selection commands" in UIKit).
    This currently does not work for non-editable text, since the synthetic click gesture simultaneously fires
    alongside the text interaction assistant's non-editable tap gesture, which dispatches a click to the page which
    then clears the selection.
    
    To remedy this and match platform behavior, we avoid recognizing clicks that occur over the text selection, but
    only in the case where the bounding rect of the text selection doesn't cover a large portion of the visible
    content rect of the web view. This ensures that the user doesn't get stuck in a state where it's impossible to
    dismiss a very large text selection (e.g. after selecting all the content on the page).
    
    Tests:  editing/selection/ios/clear-selection-after-tap-in-large-selected-non-editable-text.html
            editing/selection/ios/toggle-callout-bar-after-tap-in-selected-non-editable-text.html
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _shouldToggleSelectionCommandsAfterTapAt:]):
    
    Check the last known selection rects (on _lastSelectionDrawingInfo) to see if the tapped point lies within at
    least one of the selection rects.
    
    (-[WKContentView gestureRecognizerShouldBegin:]):
    
    LayoutTests:
    
    * editing/selection/ios/clear-selection-after-tap-in-large-selected-non-editable-text-expected.txt: Added.
    * editing/selection/ios/clear-selection-after-tap-in-large-selected-non-editable-text.html: Added.
    
    Add a new layout test to verify that when tapping in a text selection that encompasses the entire page, we allow
    the tap to dismiss the selection instead of toggling callout bar visibility.
    
    * editing/selection/ios/toggle-callout-bar-after-tap-in-selected-non-editable-text-expected.txt: Added.
    * editing/selection/ios/toggle-callout-bar-after-tap-in-selected-non-editable-text.html: Added.
    
    Add another layout test to verify that when tapping inside a text selection, the callout bar is toggled, and
    when tapping outside the selected text, the selection is dismissed.
    
    * resources/ui-helper.js:
    (window.UIHelper.async.waitForSelectionToAppear):
    (window.UIHelper.async.waitForSelectionToDisappear):
    
    New helper methods to wait for selection rects to appear or disappear.
    
    (window.UIHelper):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250392 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-26  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iOS 13] Tapping on a non-editable text selection should toggle callout bar visibility instead of clearing selection
            https://bugs.webkit.org/show_bug.cgi?id=202254
            <rdar://problem/54410263>

            Reviewed by Megan Gardner.

            In iOS 13, tapping a text selection should toggle callout bar visibility (i.e. "selection commands" in UIKit).
            This currently does not work for non-editable text, since the synthetic click gesture simultaneously fires
            alongside the text interaction assistant's non-editable tap gesture, which dispatches a click to the page which
            then clears the selection.

            To remedy this and match platform behavior, we avoid recognizing clicks that occur over the text selection, but
            only in the case where the bounding rect of the text selection doesn't cover a large portion of the visible
            content rect of the web view. This ensures that the user doesn't get stuck in a state where it's impossible to
            dismiss a very large text selection (e.g. after selecting all the content on the page).

            Tests:  editing/selection/ios/clear-selection-after-tap-in-large-selected-non-editable-text.html
                    editing/selection/ios/toggle-callout-bar-after-tap-in-selected-non-editable-text.html

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _shouldToggleSelectionCommandsAfterTapAt:]):

            Check the last known selection rects (on _lastSelectionDrawingInfo) to see if the tapped point lies within at
            least one of the selection rects.

            (-[WKContentView gestureRecognizerShouldBegin:]):

2019-09-27  Alan Coon  <alancoon@apple.com>

        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  <megan_gardner@apple.com>

            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.

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

2019-09-27  Alan Coon  <alancoon@apple.com>

        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
    <rdar://problem/52906640>
    
    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  <wenson_hsieh@apple.com>

            Page temporarily jumps to an excessively small viewport scale while loading usatoday.com
            https://bugs.webkit.org/show_bug.cgi?id=202224
            <rdar://problem/52906640>

            Reviewed by Tim Horton.

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

2019-09-27  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250315. rdar://problem/55770706

    [iPadOs] The second click event is missing on double tap when dblclick handler is not present
    https://bugs.webkit.org/show_bug.cgi?id=202006
    <rdar://problem/51706828>
    
    Reviewed by Wenson Hsieh.
    
    Source/WebKit:
    
    While double tapping,
    1. the first tap triggers a click event through the normal _singleTapIdentified/_singleTapRecognized codepath.
    2. and the second tap should trigger either
      a second single click event or
      a second single click followed by a dblclick event when dblclick handler is present.
    However the second click is dropped on the floor when the node under the cursor does not have a dblclick handler (see handleDoubleTapForDoubleClickAtPoint()) -so we end up sending one click event.
    
    This patch fixes this case by sending the second tap through the normal single tap flow when the dblclick handler is not present.
    
    * Shared/ios/InteractionInformationAtPosition.h:
    * Shared/ios/InteractionInformationAtPosition.mm:
    (WebKit::InteractionInformationAtPosition::encode const):
    (WebKit::InteractionInformationAtPosition::decode):
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView setupInteraction]):
    (-[WKContentView gestureRecognizerShouldBegin:]):
    (WebKit::WebPage::positionInformation):
    (WebKit::WebPage::requestPositionInformation):
    
    LayoutTests:
    
    * fast/events/touch/ios/double-tap-for-two-clicks1-expected.txt: Added.
    * fast/events/touch/ios/double-tap-for-two-clicks1.html: Added.
    * fast/events/touch/ios/double-tap-for-two-clicks2-expected.txt: Added.
    * fast/events/touch/ios/double-tap-for-two-clicks2.html: Added.
    * fast/events/touch/ios/double-tap-for-two-clicks3-expected.txt: Added.
    * fast/events/touch/ios/double-tap-for-two-clicks3.html: Added.
    * fast/events/touch/ios/double-tap-for-two-clicks4-expected.txt: Added.
    * fast/events/touch/ios/double-tap-for-two-clicks4.html: Added.
    * fast/events/touch/ios/doubleclick.html: Added.
    * fast/events/touch/resources/doubleClickContent.html: Added.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250315 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-24  Zalan Bujtas  <zalan@apple.com>

            [iPadOs] The second click event is missing on double tap when dblclick handler is not present
            https://bugs.webkit.org/show_bug.cgi?id=202006
            <rdar://problem/51706828>

            Reviewed by Wenson Hsieh.

            While double tapping,
            1. the first tap triggers a click event through the normal _singleTapIdentified/_singleTapRecognized codepath.
            2. and the second tap should trigger either
              a second single click event or
              a second single click followed by a dblclick event when dblclick handler is present.
            However the second click is dropped on the floor when the node under the cursor does not have a dblclick handler (see handleDoubleTapForDoubleClickAtPoint()) -so we end up sending one click event.

            This patch fixes this case by sending the second tap through the normal single tap flow when the dblclick handler is not present.

            * Shared/ios/InteractionInformationAtPosition.h:
            * Shared/ios/InteractionInformationAtPosition.mm:
            (WebKit::InteractionInformationAtPosition::encode const):
            (WebKit::InteractionInformationAtPosition::decode):
            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView setupInteraction]):
            (-[WKContentView gestureRecognizerShouldBegin:]):
            (WebKit::WebPage::positionInformation):
            (WebKit::WebPage::requestPositionInformation):

2019-09-27  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250197. rdar://problem/55612001

    Fix an assertion failure introduced in r250186.
    
    * UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
    (WebKit::PluginProcessProxy::platformGetLaunchOptionsWithAttributes): Corrected the
      assertion.
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250197 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-21  Dan Bernstein  <mitz@apple.com>

            Fix an assertion failure introduced in r250186.

            * UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
            (WebKit::PluginProcessProxy::platformGetLaunchOptionsWithAttributes): Corrected the
              assertion.

2019-09-27  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250186. rdar://problem/55612001

    Safari 13 may launch leftover 32-bit plug-in process from Safari 12’s WebKit, which crashes
    https://bugs.webkit.org/show_bug.cgi?id=202077
    <rdar://problem/55547063>
    
    Reviewed by Sam Weinig.
    
    * Shared/Plugins/Netscape/mac/NetscapePluginModuleMac.mm:
    (WebKit::getPluginArchitecture): Removed support for i386 plug-ins.
    
    * UIProcess/Launcher/mac/ProcessLauncherMac.mm:
    (WebKit::serviceName): Assert that the requested process type is not Plugin32.
    
    * UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
    (WebKit::PluginProcessProxy::platformGetLaunchOptionsWithAttributes): Assert that the
      plug-in architecture is x86_64.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250186 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-21  Dan Bernstein  <mitz@apple.com>

            Safari 13 may launch leftover 32-bit plug-in process from Safari 12’s WebKit, which crashes
            https://bugs.webkit.org/show_bug.cgi?id=202077
            <rdar://problem/55547063>

            Reviewed by Sam Weinig.

            * Shared/Plugins/Netscape/mac/NetscapePluginModuleMac.mm:
            (WebKit::getPluginArchitecture): Removed support for i386 plug-ins.

            * UIProcess/Launcher/mac/ProcessLauncherMac.mm:
            (WebKit::serviceName): Assert that the requested process type is not Plugin32.

            * UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
            (WebKit::PluginProcessProxy::platformGetLaunchOptionsWithAttributes): Assert that the
              plug-in architecture is x86_64.

2019-09-27  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/55608016

    2019-09-27  Brent Fulgham  <bfulgham@apple.com>

            Create InjectedBundle SPI to better support NSSecureCoding
            https://bugs.webkit.org/show_bug.cgi?id=201810
            <rdar://problem/55265713>

            The encoding/decoding routines used by WebKit’s InjectedBundles are based on NSCoding.
            While we have changed WebKit internals to use NSSecureCoding, there are a number of
            injected bundles that need to serialize custom classes between the InjectedBundle and
            the relevant WebKit UIProcess.

            We need to lock down this communications channel by enforcing NSSecureCoding.

            This patch creates new SPI to allow the UIProcess to specify classes that it will accept
            in messages from the WebContet Process (and Injected Bundle).

            It adds the following property to the WKProcessPoolConfiguration:

                @property (nonatomic, copy) NSSet<Class> *customClassesForParameterCoder;

            If no custom classes are specified, the standard serialization primitives are supported:
                NSArray, NSData, NSDate, NSDictionary, NSNull, NSNumber, NSSet, NSString,
                NSTimeZone, NSURL, and NSUUID.

            Reviewed by Brady Eidson.

            * UIProcess/API/APIProcessPoolConfiguration.cpp:
            (API::ProcessPoolConfiguration::copy): Copy any custom classes.
            * UIProcess/API/APIProcessPoolConfiguration.h:
            * UIProcess/API/C/WKContextConfigurationRef.cpp:
            (WKContextConfigurationCopyCustomClassesForParameterCoder): Added.
            (WKContextConfigurationSetCustomClassesForParameterCoder): Added.
            * UIProcess/API/C/WKContextConfigurationRef.h:
            * UIProcess/API/Cocoa/WKProcessGroup.h:
            * UIProcess/API/Cocoa/WKProcessGroup.mm:
            (toStringVector): Added.
            (-[WKProcessGroup initWithInjectedBundleURL:andCustomClassesForParameterCoder:]):
            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _setInputDelegate:]): Restrict serialization to allowed classes.
            * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h:
            * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.mm:
            (-[_WKProcessPoolConfiguration customClassesForParameterCoder]): Added.
            (-[_WKProcessPoolConfiguration setCustomClassesForParameterCoder:]): Added.
            * UIProcess/Cocoa/WebProcessPoolCocoa.mm:
            (WebKit::WebProcessPool::platformInitialize): Register any custom classes
            provided in the configuraton.
            (WebKit::WebProcessPool::initializeClassesForParameterCoding): Added.
            (WebKit::WebProcessPool::allowedClassesForParameterCoding const): Added.
            * UIProcess/WebProcessPool.h:
            * UIProcess/ios/PageClientImplIOS.mm:
            (WebKit::PageClientImpl::elementDidFocus): Restrict serialization to allowed
            classes only.

2019-09-25  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250187. rdar://problem/55644650

    Regression(iOS 13) web views do not deal properly with their window's UIScene changing
    https://bugs.webkit.org/show_bug.cgi?id=202070
    <rdar://problem/55580699>
    
    Reviewed by Tim Horton.
    
    Web views do not deal properly with their window's UIScene changing. If a Safari window is in the
    background for 1 minute, its UIScene will be detached and the window will get a new UIScene if
    the user later switches to this window. Our web views listen to UIScene notifications to determine
    their visibility and currently stop receiving visibility updates once the window’s UIScene has
    changed. This causes view freezes because our WebContent process does not know its view is visible
    and keeps its layer tree frozen.
    
    Previously, when our view would be added to a window, we would get this window's UIScene and listen
    for UISceneDidEnterBackgroundNotification / UISceneWillEnterForegroundNotification for this UIScene
    object. Instead, we now listen to these notifications for ALL the application's UIScenes. Our handler
    then checks if the notification's UIScene object matches the current window's UIScene before
    forwarding the notification to the rest of WebKit.
    
    * UIProcess/ApplicationStateTracker.mm:
    (WebKit::ApplicationStateTracker::ApplicationStateTracker):
    (WebKit::ApplicationStateTracker::~ApplicationStateTracker):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250187 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-21  Chris Dumez  <cdumez@apple.com>

            Regression(iOS 13) web views do not deal properly with their window's UIScene changing
            https://bugs.webkit.org/show_bug.cgi?id=202070
            <rdar://problem/55580699>

            Reviewed by Tim Horton.

            Web views do not deal properly with their window's UIScene changing. If a Safari window is in the
            background for 1 minute, its UIScene will be detached and the window will get a new UIScene if
            the user later switches to this window. Our web views listen to UIScene notifications to determine
            their visibility and currently stop receiving visibility updates once the window’s UIScene has
            changed. This causes view freezes because our WebContent process does not know its view is visible
            and keeps its layer tree frozen.

            Previously, when our view would be added to a window, we would get this window's UIScene and listen
            for UISceneDidEnterBackgroundNotification / UISceneWillEnterForegroundNotification for this UIScene
            object. Instead, we now listen to these notifications for ALL the application's UIScenes. Our handler
            then checks if the notification's UIScene object matches the current window's UIScene before
            forwarding the notification to the rest of WebKit.

            * UIProcess/ApplicationStateTracker.mm:
            (WebKit::ApplicationStateTracker::ApplicationStateTracker):
            (WebKit::ApplicationStateTracker::~ApplicationStateTracker):

2019-09-25  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250154. rdar://problem/55644650

    ApplicationStateTracker::m_isBackground initialization does not account for UIScenes
    https://bugs.webkit.org/show_bug.cgi?id=202048
    
    Reviewed by Geoffrey Garen.
    
    ApplicationStateTracker::m_isBackground initialization does not account for UIScenes, it merely checks
    the visibility state of the whole app. It should instead check the visibility state of the window's
    UIScene.
    
    This patch also refactors the code a little bit to reduce #ifdef'ing.
    
    * UIProcess/ApplicationStateTracker.mm:
    (WebKit::ApplicationStateTracker::ApplicationStateTracker):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250154 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-20  Chris Dumez  <cdumez@apple.com>

            ApplicationStateTracker::m_isBackground initialization does not account for UIScenes
            https://bugs.webkit.org/show_bug.cgi?id=202048

            Reviewed by Geoffrey Garen.

            ApplicationStateTracker::m_isBackground initialization does not account for UIScenes, it merely checks
            the visibility state of the whole app. It should instead check the visibility state of the window's
            UIScene.

            This patch also refactors the code a little bit to reduce #ifdef'ing.

            * UIProcess/ApplicationStateTracker.mm:
            (WebKit::ApplicationStateTracker::ApplicationStateTracker):

2019-09-25  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250111. rdar://problem/55644650

    Add better logging for when the view visibility state changes
    https://bugs.webkit.org/show_bug.cgi?id=202008
    
    Reviewed by Geoffrey Garen.
    
    * UIProcess/ApplicationStateTracker.mm:
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::updateActivityState):
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::WebPageProxy::applicationDidEnterBackground):
    (WebKit::WebPageProxy::applicationWillEnterForeground):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250111 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-19  Chris Dumez  <cdumez@apple.com>

            Add better logging for when the view visibility state changes
            https://bugs.webkit.org/show_bug.cgi?id=202008

            Reviewed by Geoffrey Garen.

            * UIProcess/ApplicationStateTracker.mm:
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::updateActivityState):
            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::applicationDidEnterBackground):
            (WebKit::WebPageProxy::applicationWillEnterForeground):

2019-09-25  Alan Coon  <alancoon@apple.com>

        Cherry-pick r249933. rdar://problem/55461414

    REGRESSION: iPad: Safari becomes unresponsive after context menu on 1-800-MY-APPLE phone number, tapping 'Add to Contacts'
    https://bugs.webkit.org/show_bug.cgi?id=201816
    <rdar://55105827>
    
    Reviewed by Darin Adler.
    
    Source/WebCore/PAL:
    
    Expose kDataDetectorsSourceRectKey (and sort things while there).
    
    * pal/spi/ios/DataDetectorsUISPI.h:
    
    Source/WebKit:
    
    When generating the DataDetectorsContext for a position, we should
    also provide the source rectangle for the link in root view coordinates.
    This allows DataDetectors to show any modal dialogs in the right
    position.
    
    * UIProcess/ios/WKContentViewInteraction.mm: Use either the bounds of the positionInformation
    or the text bounding rectangle.
    (-[WKContentView dataDetectionContextForPositionInformation:]):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249933 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-16  Dean Jackson  <dino@apple.com>

            REGRESSION: iPad: Safari becomes unresponsive after context menu on 1-800-MY-APPLE phone number, tapping 'Add to Contacts'
            https://bugs.webkit.org/show_bug.cgi?id=201816
            <rdar://55105827>

            Reviewed by Darin Adler.

            When generating the DataDetectorsContext for a position, we should
            also provide the source rectangle for the link in root view coordinates.
            This allows DataDetectors to show any modal dialogs in the right
            position.

            * UIProcess/ios/WKContentViewInteraction.mm: Use either the bounds of the positionInformation
            or the text bounding rectangle.
            (-[WKContentView dataDetectionContextForPositionInformation:]):

2019-09-24  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/51250952>
    
    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  <wenson_hsieh@apple.com>

            [iOS] Drop animation when dragging images from Photos to WebKit2 Mail compose is incorrect
            https://bugs.webkit.org/show_bug.cgi?id=201674
            <rdar://problem/51250952>

            Reviewed by Tim Horton.

            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.

2019-09-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250183. rdar://problem/55608006

    [Pointer Events] touch-action set to pan-x or pan-y alone should disable scrolling altogether if the intial gesture is in the disallowed direction
    https://bugs.webkit.org/show_bug.cgi?id=202053
    <rdar://problem/54542190>
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    Although the Pointer Events specification does not specify this clearly (see https://github.com/w3c/pointerevents/issues/303), setting "touch-action" to a value
    that only allows scrolling a specific direction ("pan-x" or "pan-y") should disable scrolling in the specified direction if the panning gesture initially is directed
    in the opposite direction. In practice, this means that setting "touch-action: pan-y" on an element should disable scrolling if the user initially pans horizontally,
    even if later on in the gesture the user pans vertically. This allows for sites that want to offer a programmatic horizontal scroller to disable vertical scrolling
    if the user pans horizontally.
    
    In order to support this, we add four UISwipeGestureRecognizers, one for each direction, and we selectively allows touches to be recognizer for them based on the
    "touch-action" value specified at the initial touch location for a given gesture. In the case of "touch-action: pan-y" we only allow the left and right swipe recognizers
    to be enabled, and in the case of "touch-action: pan-x" we only allow the up and down swipe recognizers to be enabled. If any of those gesture recognizers is recognized,
    scrolling will be disabled for the duration of this gesture. If a UIScrollView panning gesture recognizer is recognized prior to a swipe, they won't have a chance to be
    recognized.
    
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView setupInteraction]):
    (-[WKContentView cleanupInteraction]):
    (-[WKContentView _removeDefaultGestureRecognizers]):
    (-[WKContentView _addDefaultGestureRecognizers]):
    (-[WKContentView gestureRecognizer:shouldReceiveTouch:]):
    
    LayoutTests:
    
    Add new tests checking that setting "touch-action: pan-y" on an element and initiating a horizontal panning gesture will disallow scrolling vertically
    if a vertical scrolling gesture follows. We test both the case where scrolling would apply to the whole page and the case where scrolling would apply
    to an "overflow: scroll" element.
    
    * pointerevents/ios/touch-action-pan-y-horizontal-gesture-prevents-vertical-scrolling-expected.txt: Added.
    * pointerevents/ios/touch-action-pan-y-horizontal-gesture-prevents-vertical-scrolling.html: Added.
    * pointerevents/ios/touch-action-pan-y-in-overflow-scroll-horizontal-gesture-prevents-vertical-scrolling-expected.txt: Added.
    * pointerevents/ios/touch-action-pan-y-in-overflow-scroll-horizontal-gesture-prevents-vertical-scrolling.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250183 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-21  Antoine Quint  <graouts@apple.com>

            [Pointer Events] touch-action set to pan-x or pan-y alone should disable scrolling altogether if the intial gesture is in the disallowed direction
            https://bugs.webkit.org/show_bug.cgi?id=202053
            <rdar://problem/54542190>

            Reviewed by Tim Horton.

            Although the Pointer Events specification does not specify this clearly (see https://github.com/w3c/pointerevents/issues/303), setting "touch-action" to a value
            that only allows scrolling a specific direction ("pan-x" or "pan-y") should disable scrolling in the specified direction if the panning gesture initially is directed
            in the opposite direction. In practice, this means that setting "touch-action: pan-y" on an element should disable scrolling if the user initially pans horizontally,
            even if later on in the gesture the user pans vertically. This allows for sites that want to offer a programmatic horizontal scroller to disable vertical scrolling
            if the user pans horizontally.

            In order to support this, we add four UISwipeGestureRecognizers, one for each direction, and we selectively allows touches to be recognizer for them based on the
            "touch-action" value specified at the initial touch location for a given gesture. In the case of "touch-action: pan-y" we only allow the left and right swipe recognizers
            to be enabled, and in the case of "touch-action: pan-x" we only allow the up and down swipe recognizers to be enabled. If any of those gesture recognizers is recognized,
            scrolling will be disabled for the duration of this gesture. If a UIScrollView panning gesture recognizer is recognized prior to a swipe, they won't have a chance to be
            recognized.

            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView setupInteraction]):
            (-[WKContentView cleanupInteraction]):
            (-[WKContentView _removeDefaultGestureRecognizers]):
            (-[WKContentView _addDefaultGestureRecognizers]):
            (-[WKContentView gestureRecognizer:shouldReceiveTouch:]):

2019-09-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250157. rdar://problem/55607994

    Sanitize suggested filenames used for saving PDFs
    https://bugs.webkit.org/show_bug.cgi?id=202034
    <rdar://problem/53183075>
    
    Reviewed by Chris Dumez.
    
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::didFinishLoadingDataForCustomContentProvider):
    (WebKit::WebPageProxy::saveDataToFileInDownloadsFolder):
    (WebKit::WebPageProxy::savePDFToFileInDownloadsFolder):
    * UIProcess/WebPageProxy.h:
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::WebPageProxy::savePDFToTemporaryFolderAndOpenWithNativeApplicationRaw): Deleted.
    * UIProcess/mac/WebPageProxyMac.mm:
    (WebKit::WebPageProxy::savePDFToTemporaryFolderAndOpenWithNativeApplication):
    (WebKit::WebPageProxy::savePDFToTemporaryFolderAndOpenWithNativeApplicationRaw): Deleted.
    Sanitize suggested filenames to ensure that they comprise only one path component
    when concatenated with their destination directory.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250157 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-20  Tim Horton  <timothy_horton@apple.com>

            Sanitize suggested filenames used for saving PDFs
            https://bugs.webkit.org/show_bug.cgi?id=202034
            <rdar://problem/53183075>

            Reviewed by Chris Dumez.

            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::didFinishLoadingDataForCustomContentProvider):
            (WebKit::WebPageProxy::saveDataToFileInDownloadsFolder):
            (WebKit::WebPageProxy::savePDFToFileInDownloadsFolder):
            * UIProcess/WebPageProxy.h:
            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::savePDFToTemporaryFolderAndOpenWithNativeApplicationRaw): Deleted.
            * UIProcess/mac/WebPageProxyMac.mm:
            (WebKit::WebPageProxy::savePDFToTemporaryFolderAndOpenWithNativeApplication):
            (WebKit::WebPageProxy::savePDFToTemporaryFolderAndOpenWithNativeApplicationRaw): Deleted.
            Sanitize suggested filenames to ensure that they comprise only one path component
            when concatenated with their destination directory.

2019-09-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250108. rdar://problem/55608024

    macCatalyst apps crash under TextCheckingControllerProxy::replaceRelativeToSelection when spell checking
    https://bugs.webkit.org/show_bug.cgi?id=202010
    <rdar://problem/54974971>
    
    Reviewed by Beth Dakin.
    
    * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.mm:
    (WebKit::TextCheckingControllerProxy::replaceRelativeToSelection):
    relativeReplacementRange is in the coordinate space of the document's text,
    not the replacement string. We need to adjust into replacement string
    coordinates before slicing the replacement, or we'll throw an exception
    trying to read past the end of the string, in the case where the
    replacement string is shorter than the replaced string (by more than 2 characters).
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250108 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-19  Tim Horton  <timothy_horton@apple.com>

            macCatalyst apps crash under TextCheckingControllerProxy::replaceRelativeToSelection when spell checking
            https://bugs.webkit.org/show_bug.cgi?id=202010
            <rdar://problem/54974971>

            Reviewed by Beth Dakin.

            * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.mm:
            (WebKit::TextCheckingControllerProxy::replaceRelativeToSelection):
            relativeReplacementRange is in the coordinate space of the document's text,
            not the replacement string. We need to adjust into replacement string
            coordinates before slicing the replacement, or we'll throw an exception
            trying to read past the end of the string, in the case where the
            replacement string is shorter than the replaced string (by more than 2 characters).

2019-09-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r250069. rdar://problem/55524981

    Eagerly create and add the m_layerHostingView to WKWebView.
    https://bugs.webkit.org/show_bug.cgi?id=201942
    
    Reviewed by Tim Horton.
    
    Some apps will add subviews to WKWebView, and by the time we add our m_layerHostingView view we might be
    adding it behind a view that should have been added behind our layer hosting view subview. This affected
    the Spark email app, due to changes in order of loading delegate calls and when compositing is enabled.
    Instead of delayed creation of m_layerHostingView, always create it and add it to to the WKWebView.
    This ensures proper ordering of subviews when clients add a view behind all existing subviews.
    
    * UIProcess/Cocoa/WebViewImpl.mm:
    (WebKit::WebViewImpl::WebViewImpl): Create and add m_layerHostingView here.
    (WebKit::WebViewImpl::setAcceleratedCompositingRootLayer): Remove creation and removal of m_layerHostingView.
    Just set the sublayers of m_layerHostingView's layer here.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250069 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-18  Timothy Hatcher  <timothy@apple.com>

            Eagerly create and add the m_layerHostingView to WKWebView.
            https://bugs.webkit.org/show_bug.cgi?id=201942

            Reviewed by Tim Horton.

            Some apps will add subviews to WKWebView, and by the time we add our m_layerHostingView view we might be
            adding it behind a view that should have been added behind our layer hosting view subview. This affected
            the Spark email app, due to changes in order of loading delegate calls and when compositing is enabled.
            Instead of delayed creation of m_layerHostingView, always create it and add it to to the WKWebView.
            This ensures proper ordering of subviews when clients add a view behind all existing subviews.

            * UIProcess/Cocoa/WebViewImpl.mm:
            (WebKit::WebViewImpl::WebViewImpl): Create and add m_layerHostingView here.
            (WebKit::WebViewImpl::setAcceleratedCompositingRootLayer): Remove creation and removal of m_layerHostingView.
            Just set the sublayers of m_layerHostingView's layer here.

2019-09-23  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/55608031

    Clean up handling of summary items and payment method updates https://bugs.webkit.org/show_bug.cgi?id=202018 <rdar://problem/55470632>
    
    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<WebCore::PaymentMethodUpdate>::encode):
    (IPC::ArgumentCoder<WebCore::PaymentMethodUpdate>::decode):

    2019-09-19  Andy Estes  <aestes@apple.com>

            [Apple Pay] Clean up handling of summary items and payment method updates
            https://bugs.webkit.org/show_bug.cgi?id=202018
            <rdar://problem/55470632>

            Reviewed by Tim Horton.

            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<WebCore::PaymentMethodUpdate>::encode):
            (IPC::ArgumentCoder<WebCore::PaymentMethodUpdate>::decode):

2019-09-23  Alan Coon  <alancoon@apple.com>

        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:
    
    <rdar://problem/55469706>
    
    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:
    
    <rdar://problem/55469706>
    
    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<WebCore::PaymentSessionError>::encode):
    (IPC::ArgumentCoder<WebCore::PaymentSessionError>::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  <aestes@apple.com>

            [Apple Pay] Tell websites why a session was cancelled
            https://bugs.webkit.org/show_bug.cgi?id=201912
            <rdar://problem/55469706>

            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<WebCore::PaymentSessionError>::encode):
            (IPC::ArgumentCoder<WebCore::PaymentSessionError>::decode):
            * Shared/WebCoreArgumentCoders.h:
            * WebProcess/ApplePay/WebPaymentCoordinator.cpp:
            (WebKit::WebPaymentCoordinator::networkProcessConnectionClosed):
            (WebKit::WebPaymentCoordinator::didCancelPaymentSession):
            * WebProcess/ApplePay/WebPaymentCoordinator.h:
            * WebProcess/ApplePay/WebPaymentCoordinator.messages.in:

2019-09-23  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/55608007

    2019-09-23  Chris Dumez  <cdumez@apple.com>

            Regression(r248832): Unable to quicklook HTML files in Mail
            https://bugs.webkit.org/show_bug.cgi?id=202012
            <rdar://problem/55285295>

            Reviewed by Geoff Garen and Brent Fulgham.

            r248832 inadvertently reverted the fix for Mail that landed in r247400 by not using
            the same logic to initialize the sandbox extension if the process had already
            finished launching or not. In particular, the new code path that happens on process
            launch unconditionally used '/' as resource directory for the sandbox extension if
            the client did not provide one. The logic in maybeInitializeSandboxExtensionHandle()
            would use the file URL's base URL as resource directory when creating a sandbox
            extension for '/' would fail (which it often does).

            To address the issue, have the logic that runs on process launch call
            maybeInitializeSandboxExtensionHandle() so avoid duplicating code and make sure
            both cases now have the Mail fix.

            * UIProcess/AuxiliaryProcessProxy.cpp:
            (WebKit::AuxiliaryProcessProxy::didFinishLaunching):
            * UIProcess/AuxiliaryProcessProxy.h:
            (WebKit::AuxiliaryProcessProxy::isLaunching const):
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
            (WebKit::WebPageProxy::loadRequestWithNavigationShared):
            (WebKit::WebPageProxy::loadFile):
            * UIProcess/WebPageProxy.h:
            * WebProcess/WebPage/WebPage.messages.in:

2019-09-23  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r250015. rdar://problem/55579794

    Remove the "Show Link Previews" and "Hide Link Previews" action menus in the preview platter
    https://bugs.webkit.org/show_bug.cgi?id=201864
    <rdar://55190038>
    
    Reviewed by Simon Fraser.
    
    Source/WebKit:
    
    * UIProcess/ios/WKActionSheetAssistant.mm: Remove the toggle action from the
    default values.
    (-[WKActionSheetAssistant defaultActionsForLinkSheet:]):
    * UIProcess/ios/WKContentViewInteraction.mm: No longer try to add a toggle when
    it isn't there.
    (-[WKContentView assignLegacyDataForContextMenuInteraction]):
    (menuWithShowLinkPreviewAction): Deleted.
    
    Tools:
    
    Test for the suggested actions.
    
    * TestWebKitAPI/Tests/WebKitCocoa/ContextMenus.mm:
    (-[TestContextMenuSuggestedActionsUIDelegate webView:contextMenuConfigurationForElement:completionHandler:]):
    (-[TestContextMenuSuggestedActionsUIDelegate webView:contextMenuWillPresentForElement:]):
    (TEST):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250015 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-17  Dean Jackson  <dino@apple.com>

            Remove the "Show Link Previews" and "Hide Link Previews" action menus in the preview platter
            https://bugs.webkit.org/show_bug.cgi?id=201864
            <rdar://55190038>

            Reviewed by Simon Fraser.

            * UIProcess/ios/WKActionSheetAssistant.mm: Remove the toggle action from the
            default values.
            (-[WKActionSheetAssistant defaultActionsForLinkSheet:]):
            * UIProcess/ios/WKContentViewInteraction.mm: No longer try to add a toggle when
            it isn't there.
            (-[WKContentView assignLegacyDataForContextMenuInteraction]):
            (menuWithShowLinkPreviewAction): Deleted.

2019-09-17  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/55240888

    2019-09-17  Chris Dumez  <cdumez@apple.com>

            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.

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

2019-09-17  Alan Coon  <alancoon@apple.com>

        Revert r249748. rdar://problem/55240888

2019-09-17  Kocsen Chung  <kocsen_chung@apple.com>

        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  <kocsen_chung@apple.com>

            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
        <rdar://problem/54582602>

        Reviewed by Simon Fraser.

        Source/WebCore:

        * platform/RuntimeApplicationChecks.h:
        * platform/cocoa/RuntimeApplicationChecksCocoa.mm:
        (WebCore::IOSApplication::isEventbrite):

        Source/WebKit:

        Content <body> 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  <antti@apple.com>

                REGRESSION (245006): can't scroll in "read more" view in Eventbrite app
                https://bugs.webkit.org/show_bug.cgi?id=201683
                <rdar://problem/54582602>

                Reviewed by Simon Fraser.

                Content <body> 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.

2019-09-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249757. rdar://problem/55427273

    REGRESSION: Scrubbing on ted.com does not work well
    https://bugs.webkit.org/show_bug.cgi?id=201635
    <rdar://problem/51463649>
    
    Patch by Antoine Quint <graouts@apple.com> on 2019-09-11
    Reviewed by Dean Jackson.
    
    This website uses custom media controls that simply don't work well on iOS when the User-Agent string is the desktop one, so we default to the mobile UA.
    
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::desktopClassBrowsingRecommendedForRequest):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249757 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-11  Antoine Quint  <graouts@apple.com>

            REGRESSION: Scrubbing on ted.com does not work well
            https://bugs.webkit.org/show_bug.cgi?id=201635
            <rdar://problem/51463649>

            Reviewed by Dean Jackson.

            This website uses custom media controls that simply don't work well on iOS when the User-Agent string is the desktop one, so we default to the mobile UA.

            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::desktopClassBrowsingRecommendedForRequest):

2019-09-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249754. rdar://problem/55427271

    REGRESSION (r233780): After swiping to navigate back, pinching to zoom in on webcontent snaps back to zoomed out when letting go
    https://bugs.webkit.org/show_bug.cgi?id=201671
    <rdar://problem/50488372>
    
    Reviewed by Simon Fraser.
    
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::didCommitLoad):
    Reset m_lastTransactionIDWithScaleChange, since it is not guaranteed
    to only march forward. Otherwise, we can get stuck with a very large
    m_lastTransactionIDWithScaleChange, and will not allow stable-state
    user-driven zooms until the current transactionID exceeds it.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249754 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-10  Tim Horton  <timothy_horton@apple.com>

            REGRESSION (r233780): After swiping to navigate back, pinching to zoom in on webcontent snaps back to zoomed out when letting go
            https://bugs.webkit.org/show_bug.cgi?id=201671
            <rdar://problem/50488372>

            Reviewed by Simon Fraser.

            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::didCommitLoad):
            Reset m_lastTransactionIDWithScaleChange, since it is not guaranteed
            to only march forward. Otherwise, we can get stuck with a very large
            m_lastTransactionIDWithScaleChange, and will not allow stable-state
            user-driven zooms until the current transactionID exceeds it.

2019-09-17  Kocsen Chung  <kocsen_chung@apple.com>

        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  <cdumez@apple.com>

            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.

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

2019-09-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249723. rdar://problem/55291687

    Hangs on Swiss.com due to the web process being blocked on StorageAreaMap::LoadValuesIfNeeded
    https://bugs.webkit.org/show_bug.cgi?id=201644
    <rdar://problem/54942761>
    
    Reviewed by Geoffrey Garen.
    
    Mark the StorageManagerSet::GetValues sync IPC from the WebContent process to the Network
    process with a UnboundedSynchronousIPCScope so that it will process critical sync IPC
    from the UIProcess (such as WebPage::GetPositionInformation) while waiting for a reply.
    
    * WebProcess/WebStorage/StorageAreaMap.cpp:
    (WebKit::StorageAreaMap::loadValuesIfNeeded):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249723 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-10  Chris Dumez  <cdumez@apple.com>

            Hangs on Swiss.com due to the web process being blocked on StorageAreaMap::LoadValuesIfNeeded
            https://bugs.webkit.org/show_bug.cgi?id=201644
            <rdar://problem/54942761>

            Reviewed by Geoffrey Garen.

            Mark the StorageManagerSet::GetValues sync IPC from the WebContent process to the Network
            process with a UnboundedSynchronousIPCScope so that it will process critical sync IPC
            from the UIProcess (such as WebPage::GetPositionInformation) while waiting for a reply.

            * WebProcess/WebStorage/StorageAreaMap.cpp:
            (WebKit::StorageAreaMap::loadValuesIfNeeded):

2019-09-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249703. rdar://problem/55291692

    [iOS] We sometimes attempt to use a terminated prewarmed WebContent process
    https://bugs.webkit.org/show_bug.cgi?id=201614
    <rdar://problem/54714507>
    
    Reviewed by Geoffrey Garen.
    
    On iOS, it is possible for our processes to get terminated (e.g. jetsammed) while the UIProcess
    is suspended. Upon resuming, it takes a little while for the UIProcess to get the notification
    that the mac connection to its child process has been severed and the UIProcess may try to use
    it for a load. This is especially problematic for prewarmed process because the client will end
    up showing a crash banner and reloading when we could have used a new process rather the prewarmed
    one if we had known it was dead.
    
    This patch makes 2 improvements:
    1. It makes AuxiliaryProcessProxy::state() return Terminated if we still have a connection but
       the PID is not the PID of a running process. I also added a check in tryTakePrewarmedProcess()
       to not use the prewarmed process if it state() is Terminated.
    2. When the UIProcess is about to get suspended, have the process pools terminate their non-critical
       processes (i.e. prewarmed + the ones used for PageCache). This makes WebKit friendlier with
       other apps on the system when suspended with regards to memory. Also, it makes it less likely
       useful WebContent processes will get jetsammed.
    
    * UIProcess/AuxiliaryProcessProxy.cpp:
    (WebKit::AuxiliaryProcessProxy::state const):
    (WebKit::AuxiliaryProcessProxy::isRunningProcessPID):
    * UIProcess/AuxiliaryProcessProxy.h:
    * UIProcess/Cocoa/WebProcessPoolCocoa.mm:
    (WebKit::WebProcessPool::applicationIsAboutToSuspend):
    * UIProcess/WebProcessPool.cpp:
    (WebKit::WebProcessPool::tryTakePrewarmedProcess):
    * UIProcess/WebProcessPool.h:
    * UIProcess/ios/ProcessAssertionIOS.mm:
    (-[WKProcessAssertionBackgroundTaskManager init]):
    (-[WKProcessAssertionBackgroundTaskManager _releaseBackgroundTask]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249703 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-09-11  Simon Fraser  <simon.fraser@apple.com>

        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.

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


    2019-09-09  Chris Dumez  <cdumez@apple.com>

            [iOS] We sometimes attempt to use a terminated prewarmed WebContent process
            https://bugs.webkit.org/show_bug.cgi?id=201614
            <rdar://problem/54714507>

            Reviewed by Geoffrey Garen.

            On iOS, it is possible for our processes to get terminated (e.g. jetsammed) while the UIProcess
            is suspended. Upon resuming, it takes a little while for the UIProcess to get the notification
            that the mac connection to its child process has been severed and the UIProcess may try to use
            it for a load. This is especially problematic for prewarmed process because the client will end
            up showing a crash banner and reloading when we could have used a new process rather the prewarmed
            one if we had known it was dead.

            This patch makes 2 improvements:
            1. It makes AuxiliaryProcessProxy::state() return Terminated if we still have a connection but
               the PID is not the PID of a running process. I also added a check in tryTakePrewarmedProcess()
               to not use the prewarmed process if it state() is Terminated.
            2. When the UIProcess is about to get suspended, have the process pools terminate their non-critical
               processes (i.e. prewarmed + the ones used for PageCache). This makes WebKit friendlier with
               other apps on the system when suspended with regards to memory. Also, it makes it less likely
               useful WebContent processes will get jetsammed.

            * UIProcess/AuxiliaryProcessProxy.cpp:
            (WebKit::AuxiliaryProcessProxy::state const):
            (WebKit::AuxiliaryProcessProxy::isRunningProcessPID):
            * UIProcess/AuxiliaryProcessProxy.h:
            * UIProcess/Cocoa/WebProcessPoolCocoa.mm:
            (WebKit::WebProcessPool::applicationIsAboutToSuspend):
            * UIProcess/WebProcessPool.cpp:
            (WebKit::WebProcessPool::tryTakePrewarmedProcess):
            * UIProcess/WebProcessPool.h:
            * UIProcess/ios/ProcessAssertionIOS.mm:
            (-[WKProcessAssertionBackgroundTaskManager init]):
            (-[WKProcessAssertionBackgroundTaskManager _releaseBackgroundTask]):

2019-09-09  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249649. rdar://problem/55198071

    [macOS] Pid is sometimes invalid when creating sandbox extensions by pid.
    https://bugs.webkit.org/show_bug.cgi?id=201543
    <rdar://problem/54733465>
    
    Reviewed by Brent Fulgham.
    
    There is a race condition when starting a load of a local file, where the WebContent process has not finished
    launching yet, and its pid is not available. When we try to create a sandbox extension by using the pid of the
    WebContent process, it is not available in the cases where the WebContent process has just launched and has not
    finished launching yet. This patch creates a new dummy Web page message, 'LoadRequestWaitingForPID', which will
    be sent instead of a normal 'LoadRequest' message, and only when the WebContent process has not finished
    launching. When the WebContent process has finished launching, and we are about to actually send the pending
    messages, we can detect that a 'LoadRequestWaitingForPID' has been appended for sending, and replace it with a
    normal 'LoadReqest' message where we have created the sandbox extension issue with a valid pid. The message
    'LoadRequestWaitingForPID' is never intended to reach the WebContent process, it is just there to replace with
    a normal 'LoadRequest' message with a new sandbox extension. In the implementation of the message handler on
    the WebContent process side, we assert that the method is never called. This patch makes sure the ordering of
    the Web page messages are the same, even when we modify the message.
    
    * UIProcess/AuxiliaryProcessProxy.cpp:
    (WebKit::AuxiliaryProcessProxy::didFinishLaunching):
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
    (WebKit::WebPageProxy::loadRequestWithNavigationShared):
    (WebKit::WebPageProxy::loadFile):
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::fileLoadRequest):
    * WebProcess/WebPage/WebPage.h:
    * WebProcess/WebPage/WebPage.messages.in:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249649 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-09  Per Arne Vollan  <pvollan@apple.com>

            [macOS] Pid is sometimes invalid when creating sandbox extensions by pid.
            https://bugs.webkit.org/show_bug.cgi?id=201543
            <rdar://problem/54733465>

            Reviewed by Brent Fulgham.

            There is a race condition when starting a load of a local file, where the WebContent process has not finished
            launching yet, and its pid is not available. When we try to create a sandbox extension by using the pid of the
            WebContent process, it is not available in the cases where the WebContent process has just launched and has not
            finished launching yet. This patch creates a new dummy Web page message, 'LoadRequestWaitingForPID', which will
            be sent instead of a normal 'LoadRequest' message, and only when the WebContent process has not finished
            launching. When the WebContent process has finished launching, and we are about to actually send the pending
            messages, we can detect that a 'LoadRequestWaitingForPID' has been appended for sending, and replace it with a
            normal 'LoadReqest' message where we have created the sandbox extension issue with a valid pid. The message
            'LoadRequestWaitingForPID' is never intended to reach the WebContent process, it is just there to replace with
            a normal 'LoadRequest' message with a new sandbox extension. In the implementation of the message handler on
            the WebContent process side, we assert that the method is never called. This patch makes sure the ordering of
            the Web page messages are the same, even when we modify the message.

            * UIProcess/AuxiliaryProcessProxy.cpp:
            (WebKit::AuxiliaryProcessProxy::didFinishLaunching):
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
            (WebKit::WebPageProxy::loadRequestWithNavigationShared):
            (WebKit::WebPageProxy::loadFile):
            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::fileLoadRequest):
            * WebProcess/WebPage/WebPage.h:
            * WebProcess/WebPage/WebPage.messages.in:

2019-09-09  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249624. rdar://problem/55202935

    Marking up a note on iOS results in a PDF with no contents
    https://bugs.webkit.org/show_bug.cgi?id=201530
    <rdar://problem/53686019>
    
    Unreviewed follow-up.
    
    * UIProcess/ios/WKContentView.mm:
    (-[WKContentView _waitForDrawToPDFCallback]):
    Remove an ASSERT_NOT_REACHED that fires if the synchronous wait for printing
    times out. This is a totally legitimite situation that can occur if the process
    crashes; there's no need for an assert there.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249624 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-07  Tim Horton  <timothy_horton@apple.com>

            Marking up a note on iOS results in a PDF with no contents
            https://bugs.webkit.org/show_bug.cgi?id=201530
            <rdar://problem/53686019>

            Unreviewed follow-up.

            * UIProcess/ios/WKContentView.mm:
            (-[WKContentView _waitForDrawToPDFCallback]):
            Remove an ASSERT_NOT_REACHED that fires if the synchronous wait for printing
            times out. This is a totally legitimite situation that can occur if the process
            crashes; there's no need for an assert there.

2019-09-09  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/50956429>
    
    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  <wenson_hsieh@apple.com>

            Incorrect selection rect revealed after pasting images in a contenteditable element
            https://bugs.webkit.org/show_bug.cgi?id=201549
            <rdar://problem/50956429>

            Reviewed by Simon Fraser.

            Tweak some existing logic to use the new visibleImageElementsInRangeWithNonLoadedImages helper function. See
            WebCore for more details.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::didConcludeEditDrag):

2019-09-09  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249584. rdar://problem/55202935

    Marking up a note on iOS results in a PDF with no contents
    https://bugs.webkit.org/show_bug.cgi?id=201530
    <rdar://problem/53686019>
    
    Reviewed by Andy Estes.
    
    Source/WebKit:
    
    * Platform/IPC/Connection.cpp:
    (IPC::Connection::Connection):
    (IPC::Connection::waitForMessage):
    (IPC::Connection::connectionDidClose):
    * Platform/IPC/Connection.h:
    If the main thread is blocked when the Web Content process dies, and
    something eventually calls waitForAndDispatchImmediately without
    returning control to the main run loop, we will wait for the full timeout,
    because a) the code to mark the connection invalid is dispatched
    to the main thread, and b) the secondary thread that is informed of
    the Web Content process dying did not yet have a "waiting for" message
    to mark as interrupted (because it wasn't waiting yet).
    
    Fix this race by adding a bit that is set under the waitForMessage lock
    on the secondary thread when the connection is invalidated, identically
    to m_shouldWaitForSyncReplies, which solves the same problem for sync
    messages.
    
    Read the new bit when we are about to start waiting, and bail if it is set.
    It's OK to not read it inside the loop because we are guaranteed to have
    waitForMessage set at that point, so the normal interruption bit will work.
    
    * UIProcess/ios/WKContentView.mm:
    (-[WKContentView _processDidExit]):
    Reset _isPrintingToPDF; the Web Content process is never going to get
    back to us if it crashes.
    
    (-[WKContentView _wk_pageCountForPrintFormatter:]):
    Do not bail from starting a printing operation if one is already occurring.
    This fixes the original bug, because Markup ends up invalidating the page
    count at least one extra time before asking for the printed document.
    Instead of maintaining the fragile requirement that you cannot recompute
    the page count while printing, just let it happen. In order to make this
    work safely, synchronously wait for the previous printed result before
    continuing with the next print.
    
    We could do more coalescing here if need be, but calls to -_recalcPageCount
    are not high in volume.
    
    Tools:
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewPrintFormatter.mm:
    Add some tests for WKWebViewPrintFormatter; specifically that it is
    possible to _recalcPageCount twice in quick succession, and that
    we don't hang if we start painting the printed content immediately
    after a Web Content process crash.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249584 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-06  Tim Horton  <timothy_horton@apple.com>

            Marking up a note on iOS results in a PDF with no contents
            https://bugs.webkit.org/show_bug.cgi?id=201530
            <rdar://problem/53686019>

            Reviewed by Andy Estes.

            * Platform/IPC/Connection.cpp:
            (IPC::Connection::Connection):
            (IPC::Connection::waitForMessage):
            (IPC::Connection::connectionDidClose):
            * Platform/IPC/Connection.h:
            If the main thread is blocked when the Web Content process dies, and
            something eventually calls waitForAndDispatchImmediately without
            returning control to the main run loop, we will wait for the full timeout,
            because a) the code to mark the connection invalid is dispatched
            to the main thread, and b) the secondary thread that is informed of
            the Web Content process dying did not yet have a "waiting for" message
            to mark as interrupted (because it wasn't waiting yet).

            Fix this race by adding a bit that is set under the waitForMessage lock
            on the secondary thread when the connection is invalidated, identically
            to m_shouldWaitForSyncReplies, which solves the same problem for sync
            messages.

            Read the new bit when we are about to start waiting, and bail if it is set.
            It's OK to not read it inside the loop because we are guaranteed to have
            waitForMessage set at that point, so the normal interruption bit will work.

            * UIProcess/ios/WKContentView.mm:
            (-[WKContentView _processDidExit]):
            Reset _isPrintingToPDF; the Web Content process is never going to get
            back to us if it crashes.

            (-[WKContentView _wk_pageCountForPrintFormatter:]):
            Do not bail from starting a printing operation if one is already occurring.
            This fixes the original bug, because Markup ends up invalidating the page
            count at least one extra time before asking for the printed document.
            Instead of maintaining the fragile requirement that you cannot recompute
            the page count while printing, just let it happen. In order to make this
            work safely, synchronously wait for the previous printed result before
            continuing with the next print.

            We could do more coalescing here if need be, but calls to -_recalcPageCount
            are not high in volume.

2019-09-09  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249514. rdar://problem/55182886

    MobileSafari may crash when invoking the C++ lambda in -[WKContentView _shareForWebView:]
    https://bugs.webkit.org/show_bug.cgi?id=201479
    <rdar://problem/51511834>
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    Fix the crash by making -_shareForWebView: robust in the case where there are no selection rects
    known in the UI process when -[WKContentView _share:] is invoked.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _shareForWebView:]):
    
    Tools:
    
    Add a test to verify that the UI process doesn't crash when invoking `_share:` while there's no selection.
    
    * TestWebKitAPI/Tests/WebKitCocoa/WKContentViewEditingActions.mm:
    * TestWebKitAPI/ios/UIKitSPI.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249514 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-04  Wenson Hsieh  <wenson_hsieh@apple.com>

            MobileSafari may crash when invoking the C++ lambda in -[WKContentView _shareForWebView:]
            https://bugs.webkit.org/show_bug.cgi?id=201479
            <rdar://problem/51511834>

            Reviewed by Tim Horton.

            Fix the crash by making -_shareForWebView: robust in the case where there are no selection rects
            known in the UI process when -[WKContentView _share:] is invoked.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _shareForWebView:]):

2019-09-09  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249454. rdar://problem/55198071

    [macOS] Unable to open local file from favorites bar
    https://bugs.webkit.org/show_bug.cgi?id=201444
    
    Reviewed by Brent Fulgham.
    
    The sandbox extension handle should be created providing the pid of the receiving process.
    
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249454 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-03  Per Arne Vollan  <pvollan@apple.com>

            [macOS] Unable to open local file from favorites bar
            https://bugs.webkit.org/show_bug.cgi?id=201444

            Reviewed by Brent Fulgham.

            The sandbox extension handle should be created providing the pid of the receiving process.

            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):

2019-09-09  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249444. rdar://problem/55093558

    Null deref under -[WKWebView _addUpdateVisibleContentRectPreCommitHandler]'s handler block
    https://bugs.webkit.org/show_bug.cgi?id=201436
    <rdar://problem/40640475>
    
    Reviewed by Simon Fraser.
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView dealloc]):
    (-[WKWebView _addUpdateVisibleContentRectPreCommitHandler]):
    We crash sending a message to a deallocated WKWebView inside the handler block
    passed to +[CATransaction addCommitHandler:]. This seems impossible, because
    we carefully retain it, but it's possible that it could be the result of
    the handler block being installed under -dealloc (in which case retaining
    the WKWebView wouldn't actually extend its lifetime). -[WKWebView dealloc]
    is fairly sizable, and it's hard to follow all paths from it, so instead
    add a RELEASE_LOG_FAULT, so we'll get simulated crash logs, and bail,
    so we'll stop actually crashing (if this is the cause).
    
    This is just a speculative fix, but a hopeful one, since intentionally calling
    -_addUpdateVisibleContentRectPreCommitHandler: from dealloc yields a similar-looking
    crash under the handler block.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249444 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-03  Tim Horton  <timothy_horton@apple.com>

            Null deref under -[WKWebView _addUpdateVisibleContentRectPreCommitHandler]'s handler block
            https://bugs.webkit.org/show_bug.cgi?id=201436
            <rdar://problem/40640475>

            Reviewed by Simon Fraser.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView dealloc]):
            (-[WKWebView _addUpdateVisibleContentRectPreCommitHandler]):
            We crash sending a message to a deallocated WKWebView inside the handler block
            passed to +[CATransaction addCommitHandler:]. This seems impossible, because
            we carefully retain it, but it's possible that it could be the result of
            the handler block being installed under -dealloc (in which case retaining
            the WKWebView wouldn't actually extend its lifetime). -[WKWebView dealloc]
            is fairly sizable, and it's hard to follow all paths from it, so instead
            add a RELEASE_LOG_FAULT, so we'll get simulated crash logs, and bail,
            so we'll stop actually crashing (if this is the cause).

            This is just a speculative fix, but a hopeful one, since intentionally calling
            -_addUpdateVisibleContentRectPreCommitHandler: from dealloc yields a similar-looking
            crash under the handler block.

2019-09-05  Kocsen Chung  <kocsen_chung@apple.com>

        Apply patch. rdar://problem/55001140

    Treat a two-finger single tap as if the user tapped with the Cmd key pressed https://bugs.webkit.org/show_bug.cgi?id=201420 <rdar://problem/53207786>
    
    Reviewed by Simon Fraser.
    
    Source/WebKit:
    
    Set the metaKey modifier to true when generating a click event based on a two-finger single tap. This is important so that sites like Google and DuckDuckGo
    correctly open links in their search results page in a new tab in Safari on iOS. This currently doesn't work because those sites will call preventDefault()
    if the metaKey flag isn't set on a "click" event, and if it is set, they let the browser handle the navigation themselves.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _twoFingerSingleTapGestureRecognized:]):
    
    Tools:
    
    Add a new twoFingerSingleTapAtPoint() method to UIScriptController, which just calls into the existing (but unused)
    -[HIDEventGenerator twoFingerTap:completionBlock:].
    
    * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
    * TestRunnerShared/UIScriptContext/UIScriptController.h:
    (WTR::UIScriptController::twoFingerSingleTapAtPoint):
    * WebKitTestRunner/ios/UIScriptControllerIOS.h:
    * WebKitTestRunner/ios/UIScriptControllerIOS.mm:
    (WTR::UIScriptControllerIOS::twoFingerSingleTapAtPoint):
    
    LayoutTests:
    
    Add a new event that checks that a two-finger single tap on a clickable element yields a "click" event with the metaKey flag set to true.
    
    * fast/events/ios/click-event-two-finger-single-tap-meta-key-expected.txt: Added.
    * fast/events/ios/click-event-two-finger-single-tap-meta-key.html: Added.

    2019-09-03  Antoine Quint  <graouts@apple.com>

            [iOS] Treat a two-finger single tap as if the user tapped with the Cmd key pressed
            https://bugs.webkit.org/show_bug.cgi?id=201420
            <rdar://problem/53207786>

            Reviewed by Simon Fraser.

            Set the metaKey modifier to true when generating a click event based on a two-finger single tap. This is important so that sites like Google and DuckDuckGo
            correctly open links in their search results page in a new tab in Safari on iOS. This currently doesn't work because those sites will call preventDefault()
            if the metaKey flag isn't set on a "click" event, and if it is set, they let the browser handle the navigation themselves.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _twoFingerSingleTapGestureRecognized:]):

2019-09-04  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249430. rdar://problem/55027550

    [macOS] Correct sandbox violation in Flash plugin
    https://bugs.webkit.org/show_bug.cgi?id=201228
    <rdar://problem/54347503>
    
    Reviewed by Alex Christensen.
    
    * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249430 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-28  Brent Fulgham  <bfulgham@apple.com>

            [macOS] Correct sandbox violation in Flash plugin
            https://bugs.webkit.org/show_bug.cgi?id=201228
            <rdar://problem/54347503>

            Reviewed by Alex Christensen.

            * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in:

2019-09-04  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249368. rdar://problem/55001166

    Long presses that interrupt accelerated scrolling dispatch clicks on apps linked against iOS 12 or earlier
    https://bugs.webkit.org/show_bug.cgi?id=201346
    <rdar://problem/54885784>
    
    Reviewed by Dean Jackson.
    
    Source/WebKit:
    
    For apps that are linked on or after iOS 13, we add a context menu interaction to the content view, which
    requires us to disable (or avoid adding) the highlight long press gesture recognizer. However, for apps that are
    linked on the iOS 12 SDK or prior, this gesture is still present, and fires when long pressing for (roughly) up
    to 0.75 seconds if a tap gesture was not recognized instead. Firing this gesture sends a click event to the
    page; this brings back some form of <rdar://problem/53889373>, but only when holding for slightly longer than a
    normal tap, and also only in apps linked on iOS 12 or earlier. To fix this, we apply a similar solution as in
    r248433 and detect whether a long press gesture interrupted scroll view deceleration in
    -gestureRecognizerShouldBegin:. If so, we return NO to avoid clicking. See per-method comments below for more
    details.
    
    Testing this bug as-is was tricky, since there's no way in layout tests to simulate being linked on or before a
    given SDK version. Luckily, recall that:
    1. This bug occurs when the highlight gesture recognizer is enabled and added to the content view.
    2. The highlight gesture recognizer only needs to be disabled or removed when context menu interaction is added.
    As such, we should be able to restore the highlight gesture recognizer by suppressing the context menu
    interaction in an app linked-on-or-after iOS 13, by setting allowsLinkPreview to NO. Unfortunately, this doesn't
    quite work, since we currently always avoid adding the highlight gesture recognizer if the app is linked on
    iOS 13 or later.
    
    However, this means that the highlight gesture recognizer is absent from the content view in apps linked against
    iOS 13 that disable link previews, even though its absence is not required. This means that long pressing a
    clickable element in a web view that disables link previews does not show a tap highlight on iOS 13, whereas it
    would on iOS 12; this is a regression, albeit a very subtle one. To fix this subtle issue and make it possible
    to write a test for this bug, we refactor some logic for creating and configuring the highlight long press
    gesture, such that we now unconditionally add the highlight gesture, but only enable it in apps linked on or
    after iOS 13 if link previews (i.e. context menu interaction) are not allowed.
    
    Test: fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-overflow.html
    
    * SourcesCocoa.txt:
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView setAllowsLinkPreview:]):
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView setupInteraction]):
    
    Refactor our gesture setup logic to always create and add the long press and highlight long press gestures, but
    conditionally disable them based on whether or not (1) the context menu is available, and (2) WKWebView's
    allowsLinkPreview property.
    
    (-[WKContentView _didChangeLinkPreviewAvailability]):
    (-[WKContentView _updateLongPressAndHighlightLongPressGestures]):
    
    Add a new helper to update the enabled state of the long press and highlight long press gestures, by consulting
    -_shouldUseContextMenu and -allowsLinkPreview. This is called when setting up the gestures, as well as whenever
    -allowsLinkPreview changes.
    
    (-[WKContentView gestureRecognizerShouldBegin:]):
    
    Factor out logic to ascend the view hierarchy in search of a UIScrollView that was interrupted while
    decelerating into a local lambda function; use this for both the highlight gesture and the single tap gesture,
    to determine whether they should begin.
    
    * UIProcess/ios/WKHighlightLongPressGestureRecognizer.h: Added.
    * UIProcess/ios/WKHighlightLongPressGestureRecognizer.mm: Added.
    
    In order to remember the UIScrollView (if any) tracked by the highlight long press gesture, we subclass
    _UIWebHighlightLongPressGestureRecognizer. While UILongPressGestureRecognizer does have SPI to ask for a list of
    UITouches, by the time the gesture has been recognized and the gesture delegates are invoked, these UITouches
    no longer correspond to UIViews. As such, the only time we have access to the list of UITouches with their
    UIViews is during the touches* subclass hooks.
    
    (-[WKHighlightLongPressGestureRecognizer reset]):
    
    Clear out the tracked UIScrollView here, when the gesture is reset (i.e. after ending, or being canceled).
    
    (-[WKHighlightLongPressGestureRecognizer touchesBegan:withEvent:]):
    
    Remember the last touched UIScrollView here.
    
    (-[WKHighlightLongPressGestureRecognizer lastTouchedScrollView]):
    * WebKit.xcodeproj/project.pbxproj:
    
    Tools:
    
    Add a new test option to allow tests to disable link previews.
    
    * WebKitTestRunner/TestController.cpp:
    (WTR::updateTestOptionsFromTestHeader):
    * WebKitTestRunner/TestOptions.h:
    
    Drive-by fix: also check enableLazyImageLoading when determining whether two TestOptions are the same.
    
    (WTR::TestOptions::hasSameInitializationOptions const):
    * WebKitTestRunner/cocoa/TestControllerCocoa.mm:
    (WTR::TestController::platformCreateWebView):
    
    LayoutTests:
    
    Add a couple of new layout tests to verify that using a long press gesture to interrupt momentum scrolling in a
    web view that uses API to disable link previews does not result in a click.
    
    * fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-main-frame-expected.txt: Added.
    * fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-main-frame.html: Added.
    * fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-overflow-expected.txt: Added.
    * fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-overflow.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249368 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-09-01  Wenson Hsieh  <wenson_hsieh@apple.com>

            Long presses that interrupt accelerated scrolling dispatch clicks on apps linked against iOS 12 or earlier
            https://bugs.webkit.org/show_bug.cgi?id=201346
            <rdar://problem/54885784>

            Reviewed by Dean Jackson.

            For apps that are linked on or after iOS 13, we add a context menu interaction to the content view, which
            requires us to disable (or avoid adding) the highlight long press gesture recognizer. However, for apps that are
            linked on the iOS 12 SDK or prior, this gesture is still present, and fires when long pressing for (roughly) up
            to 0.75 seconds if a tap gesture was not recognized instead. Firing this gesture sends a click event to the
            page; this brings back some form of <rdar://problem/53889373>, but only when holding for slightly longer than a
            normal tap, and also only in apps linked on iOS 12 or earlier. To fix this, we apply a similar solution as in
            r248433 and detect whether a long press gesture interrupted scroll view deceleration in
            -gestureRecognizerShouldBegin:. If so, we return NO to avoid clicking. See per-method comments below for more
            details.

            Testing this bug as-is was tricky, since there's no way in layout tests to simulate being linked on or before a
            given SDK version. Luckily, recall that:
            1. This bug occurs when the highlight gesture recognizer is enabled and added to the content view.
            2. The highlight gesture recognizer only needs to be disabled or removed when context menu interaction is added.
            As such, we should be able to restore the highlight gesture recognizer by suppressing the context menu
            interaction in an app linked-on-or-after iOS 13, by setting allowsLinkPreview to NO. Unfortunately, this doesn't
            quite work, since we currently always avoid adding the highlight gesture recognizer if the app is linked on
            iOS 13 or later.

            However, this means that the highlight gesture recognizer is absent from the content view in apps linked against
            iOS 13 that disable link previews, even though its absence is not required. This means that long pressing a
            clickable element in a web view that disables link previews does not show a tap highlight on iOS 13, whereas it
            would on iOS 12; this is a regression, albeit a very subtle one. To fix this subtle issue and make it possible
            to write a test for this bug, we refactor some logic for creating and configuring the highlight long press
            gesture, such that we now unconditionally add the highlight gesture, but only enable it in apps linked on or
            after iOS 13 if link previews (i.e. context menu interaction) are not allowed.

            Test: fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-overflow.html

            * SourcesCocoa.txt:
            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView setAllowsLinkPreview:]):
            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView setupInteraction]):

            Refactor our gesture setup logic to always create and add the long press and highlight long press gestures, but
            conditionally disable them based on whether or not (1) the context menu is available, and (2) WKWebView's
            allowsLinkPreview property.

            (-[WKContentView _didChangeLinkPreviewAvailability]):
            (-[WKContentView _updateLongPressAndHighlightLongPressGestures]):

            Add a new helper to update the enabled state of the long press and highlight long press gestures, by consulting
            -_shouldUseContextMenu and -allowsLinkPreview. This is called when setting up the gestures, as well as whenever
            -allowsLinkPreview changes.

            (-[WKContentView gestureRecognizerShouldBegin:]):

            Factor out logic to ascend the view hierarchy in search of a UIScrollView that was interrupted while
            decelerating into a local lambda function; use this for both the highlight gesture and the single tap gesture,
            to determine whether they should begin.

            * UIProcess/ios/WKHighlightLongPressGestureRecognizer.h: Added.
            * UIProcess/ios/WKHighlightLongPressGestureRecognizer.mm: Added.

            In order to remember the UIScrollView (if any) tracked by the highlight long press gesture, we subclass
            _UIWebHighlightLongPressGestureRecognizer. While UILongPressGestureRecognizer does have SPI to ask for a list of
            UITouches, by the time the gesture has been recognized and the gesture delegates are invoked, these UITouches
            no longer correspond to UIViews. As such, the only time we have access to the list of UITouches with their
            UIViews is during the touches* subclass hooks.

            (-[WKHighlightLongPressGestureRecognizer reset]):

            Clear out the tracked UIScrollView here, when the gesture is reset (i.e. after ending, or being canceled).

            (-[WKHighlightLongPressGestureRecognizer touchesBegan:withEvent:]):

            Remember the last touched UIScrollView here.

            (-[WKHighlightLongPressGestureRecognizer lastTouchedScrollView]):
            * WebKit.xcodeproj/project.pbxproj:

2019-09-04  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/54164587>
    
    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  <jer.noble@apple.com>

            Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state.
            https://bugs.webkit.org/show_bug.cgi?id=201101
            <rdar://problem/54164587>

            Reviewed by Eric Carlson.

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

2019-09-03  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/54859264>
    
    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  <wenson_hsieh@apple.com>

            Caret does not appear in text field inside a transformed, overflow: hidden container
            https://bugs.webkit.org/show_bug.cgi?id=201317
            <rdar://problem/54859264>

            Reviewed by Simon Fraser.

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

2019-09-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249296. rdar://problem/55001174

    [iOS 13] Caret does not appear in text field if the body element is translated completely out of the viewport
    https://bugs.webkit.org/show_bug.cgi?id=201287
    <rdar://problem/54780864>
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    During EditorState computation, we use the hidden editable element heuristic to determine whether we should
    begin suppressing selection gestures and UI. Currently, we use the editable root of the selection range to
    determine where in the layer tree we should start our ascent, in search of a completely transparent or
    completely clipped container.
    
    However, in the case where the selection is inside a focused text field, this causes us to walk up the layer
    tree starting at the RenderLayer corresponding to the text field's inner contenteditable div, which is different
    than the text field's enclosing RenderLayer in the case where the containing block is transformed, such that no
    part of it is within the visible viewport. This scenario is exercised by the below test case, in which the caret
    after transforming the body horizontally by -100vw is hidden due to a false positive in the hidden editable area
    heuristic.
    
    Fix this by starting the layer tree ascent from the enclosing layer of the text form control if applicable,
    instead of the inner editable area under the shadow root of the form control.
    
    Test: editing/selection/ios/show-selection-in-transformed-container.html
    
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::platformEditorState const):
    
    LayoutTests:
    
    Add a new layout test that covers this scenario. See WebKit ChangeLog for additional detail.
    
    * editing/selection/ios/show-selection-in-transformed-container-expected.txt: Added.
    * editing/selection/ios/show-selection-in-transformed-container.html: Added.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249296 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-29  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iOS 13] Caret does not appear in text field if the body element is translated completely out of the viewport
            https://bugs.webkit.org/show_bug.cgi?id=201287
            <rdar://problem/54780864>

            Reviewed by Tim Horton.

            During EditorState computation, we use the hidden editable element heuristic to determine whether we should
            begin suppressing selection gestures and UI. Currently, we use the editable root of the selection range to
            determine where in the layer tree we should start our ascent, in search of a completely transparent or
            completely clipped container.

            However, in the case where the selection is inside a focused text field, this causes us to walk up the layer
            tree starting at the RenderLayer corresponding to the text field's inner contenteditable div, which is different
            than the text field's enclosing RenderLayer in the case where the containing block is transformed, such that no
            part of it is within the visible viewport. This scenario is exercised by the below test case, in which the caret
            after transforming the body horizontally by -100vw is hidden due to a false positive in the hidden editable area
            heuristic.

            Fix this by starting the layer tree ascent from the enclosing layer of the text form control if applicable,
            instead of the inner editable area under the shadow root of the form control.

            Test: editing/selection/ios/show-selection-in-transformed-container.html

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::platformEditorState const):

2019-09-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249230. rdar://problem/55001168

    Reloading a web view with a fixed-width viewport and variable content width restores the previous page scale, shouldn't
    https://bugs.webkit.org/show_bug.cgi?id=201256
    <rdar://problem/54809509>
    
    Reviewed by Simon Fraser.
    
    Source/WebKit:
    
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::restorePageState):
    When restoring page state from a history item, if the saved scale was equal to the
    initial scale at the time it was saved, ignore the saved scale and use the current
    initial scale instead.
    
    Normally this doesn't matter because a given page's initial scale doesn't usually change
    between loads, but it totally can! See the test for one example of a way an API client
    might cause this; you could also imagine something similar happening if the actual
    page content changed.
    
    Tools:
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/WebKit/long-email-viewport.html: Added.
    * TestWebKitAPI/Tests/WebKitCocoa/ReloadWithDifferingInitialScale.mm: Added.
    (TestWebKitAPI::TEST):
    Add a test. I left many comments because I had a great deal of trouble
    writing this test and wanted to document my findings.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249230 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-28  Tim Horton  <timothy_horton@apple.com>

            Reloading a web view with a fixed-width viewport and variable content width restores the previous page scale, shouldn't
            https://bugs.webkit.org/show_bug.cgi?id=201256
            <rdar://problem/54809509>

            Reviewed by Simon Fraser.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::restorePageState):
            When restoring page state from a history item, if the saved scale was equal to the
            initial scale at the time it was saved, ignore the saved scale and use the current
            initial scale instead.

            Normally this doesn't matter because a given page's initial scale doesn't usually change
            between loads, but it totally can! See the test for one example of a way an API client
            might cause this; you could also imagine something similar happening if the actual
            page content changed.

2019-09-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r248698. rdar://problem/55001378

    Fix the build when ENABLE(APPLE_PAY) is false.
    
    * Shared/Cocoa/WebCoreArgumentCodersCocoa.mm:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248698 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-14  Andy Estes  <aestes@apple.com>

            Fix the build when ENABLE(APPLE_PAY) is false.

            * Shared/Cocoa/WebCoreArgumentCodersCocoa.mm:

2019-09-03  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r248692. rdar://problem/55001378

    [Cocoa] Add some WKA extension points
    https://bugs.webkit.org/show_bug.cgi?id=200506
    <rdar://problem/51682474>
    
    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<ApplePaySessionPaymentRequest>::encode):
    (IPC::ArgumentCoder<ApplePaySessionPaymentRequest>::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  <aestes@apple.com>

            [Cocoa] Add some WKA extension points
            https://bugs.webkit.org/show_bug.cgi?id=200506
            <rdar://problem/51682474>

            Reviewed by Tim Horton.

            * Shared/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.mm:
            (WebKit::finishCreating):
            (WebKit::WebPaymentCoordinatorProxy::platformPaymentRequest):
            * Shared/Cocoa/WebCoreArgumentCodersCocoa.mm:
            (IPC::finishDecoding):
            (IPC::finishEncoding):
            (IPC::ArgumentCoder<ApplePaySessionPaymentRequest>::encode):
            (IPC::ArgumentCoder<ApplePaySessionPaymentRequest>::decode):
            * Shared/WebCoreArgumentCoders.h:

2019-08-28  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r249224. rdar://problem/54819205

    Null check webFrame when creating a print preview to prevent a crash.
    https://bugs.webkit.org/show_bug.cgi?id=201237
    <rdar://problem/51618863>
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    Move and expend a null check to keep from crashing when making a print preview.
    
    * UIProcess/mac/WKPrintingView.mm:
    (-[WKPrintingView _drawPreview:]):
    (-[WKPrintingView drawRect:]):
    
    Tools:
    
    Test to verify that if we don't have the WebPageProxy, we will not crash when making a print preview.
    
    * TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm:
    (TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249224 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-28  Megan Gardner  <megan_gardner@apple.com>

            Null check webFrame when creating a print preview to prevent a crash.
            https://bugs.webkit.org/show_bug.cgi?id=201237
            <rdar://problem/51618863>

            Reviewed by Tim Horton.

            Move and expend a null check to keep from crashing when making a print preview.

            * UIProcess/mac/WKPrintingView.mm:
            (-[WKPrintingView _drawPreview:]):
            (-[WKPrintingView drawRect:]):

2019-08-27  Alan Coon  <alancoon@apple.com>

        Revert r249147. rdar://problem/54751753

2019-08-27  Alan Coon  <alancoon@apple.com>

        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
    <rdar://problem/54164587>
    
    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  <jer.noble@apple.com>

            Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state.
            https://bugs.webkit.org/show_bug.cgi?id=201101
            <rdar://problem/54164587>

            Reviewed by Eric Carlson.

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

2019-08-27  Alan Coon  <alancoon@apple.com>

        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
    <rdar://problem/53056118>
    
    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  <wenson_hsieh@apple.com>

            [iOS] [WebKit2] Tapping on the “I’m” text suggestion after typing “i’” does nothing
            https://bugs.webkit.org/show_bug.cgi?id=201085
            <rdar://problem/53056118>

            Reviewed by Tim Horton.

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

2019-08-22  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/54294794>
    
    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  <wenson_hsieh@apple.com>

            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
            <rdar://problem/54294794>

            Reviewed by Ryosuke Niwa.

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

2019-08-21  Kocsen Chung  <kocsen_chung@apple.com>

        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
    <rdar://problem/54564878>
    
    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  <timothy_horton@apple.com>

            [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
            <rdar://problem/54564878>

            Reviewed by Wenson Hsieh.

            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.

2019-08-21  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r248959. rdar://problem/54579630

    Crash under StringImpl::~StringImpl() in NetworkProcess::deleteWebsiteDataForRegistrableDomains()
    https://bugs.webkit.org/show_bug.cgi?id=200986
    <rdar://problem/32850192>
    
    Reviewed by Brent Fulgham.
    
    Code was calling postStorageTask() with a lambda that captures Strings that are not isolated copied.
    The lambda would get executed on another thread so this is not safe. The CrossThreadTask constructor
    does not take care of this for you, despite its name (the createCrossThreadTask() function does though).
    
    * NetworkProcess/NetworkProcess.cpp:
    (WebKit::NetworkProcess::fetchWebsiteData):
    (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains):
    (WebKit::NetworkProcess::registrableDomainsWithWebsiteData):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248959 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-21  Chris Dumez  <cdumez@apple.com>

            Crash under StringImpl::~StringImpl() in NetworkProcess::deleteWebsiteDataForRegistrableDomains()
            https://bugs.webkit.org/show_bug.cgi?id=200986
            <rdar://problem/32850192>

            Reviewed by Brent Fulgham.

            Code was calling postStorageTask() with a lambda that captures Strings that are not isolated copied.
            The lambda would get executed on another thread so this is not safe. The CrossThreadTask constructor
            does not take care of this for you, despite its name (the createCrossThreadTask() function does though).

            * NetworkProcess/NetworkProcess.cpp:
            (WebKit::NetworkProcess::fetchWebsiteData):
            (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains):
            (WebKit::NetworkProcess::registrableDomainsWithWebsiteData):

2019-08-20  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248928. rdar://problem/54543351

    [iOS] REGRESSION (248501): gmail.com images are still not shown on some versions of iPhone iOS13
    https://bugs.webkit.org/show_bug.cgi?id=200948
    
    Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-08-20
    Reviewed by Tim Horton.
    
    Apply the gmail.com quirk for all iPhone iOS versions till the gmail.com
    bug is fixed.
    
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::platformUserAgent const):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248928 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-20  Said Abou-Hallawa  <sabouhallawa@apple.com>

            [iOS] REGRESSION (248501): gmail.com images are still not shown on some versions of iPhone iOS13
            https://bugs.webkit.org/show_bug.cgi?id=200948

            Reviewed by Tim Horton.

            Apply the gmail.com quirk for all iPhone iOS versions till the gmail.com
            bug is fixed.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::platformUserAgent const):

2019-08-20  Babak Shafiei  <bshafiei@apple.com>

        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  <cdumez@apple.com>

            Unsafe usage of CookieStorageObserver from a background thread
            https://bugs.webkit.org/show_bug.cgi?id=200920

            Reviewed by Alex Christensen.

            * UIProcess/API/APIHTTPCookieStore.h:
            * UIProcess/API/Cocoa/APIHTTPCookieStoreCocoa.mm:
            (API::HTTPCookieStore::startObservingChangesToDefaultUIProcessCookieStore):

2019-08-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248832. rdar://problem/54454547

    [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions
    https://bugs.webkit.org/show_bug.cgi?id=200543
    <rdar://problem/49394015>
    Source/WebKit:
    
    Reviewed by Brent Fulgham.
    
    Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process
    identifier of the WebContent process.
    
    * Shared/Cocoa/SandboxExtensionCocoa.mm:
    (WebKit::SandboxExtensionImpl::sandboxExtensionForType):
    (WebKit::SandboxExtension::createHandleForReadByPid):
    * Shared/SandboxExtension.h:
    * UIProcess/Cocoa/WebPageProxyCocoa.mm:
    (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded):
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
    (WebKit::WebPageProxy::loadFile):
    
    Source/WTF:
    
    Reviewed by Brent Fulgham.
    
    Add new SPI.
    
    * wtf/Platform.h:
    * wtf/spi/darwin/SandboxSPI.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248832 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-18  Per Arne Vollan  <pvollan@apple.com>

            [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions
            https://bugs.webkit.org/show_bug.cgi?id=200543
            <rdar://problem/49394015>

            Reviewed by Brent Fulgham.

            Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process
            identifier of the WebContent process.

            * Shared/Cocoa/SandboxExtensionCocoa.mm:
            (WebKit::SandboxExtensionImpl::sandboxExtensionForType):
            (WebKit::SandboxExtension::createHandleForReadByPid):
            * Shared/SandboxExtension.h:
            * UIProcess/Cocoa/WebPageProxyCocoa.mm:
            (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded):
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
            (WebKit::WebPageProxy::loadFile):

2019-08-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248823. rdar://problem/54454713

    Source/WebKit:
    Use bundlePath SPI in AccessibilitySupport for WebProcessLoader
    https://bugs.webkit.org/show_bug.cgi?id=200367
    
    Patch by Eric Liang <ericliang@apple.com> on 2019-08-17
    Reviewed by Darin Adler.
    
    * Platform/spi/ios/AccessibilitySupportSPI.h:
    * WebProcess/cocoa/WebProcessCocoa.mm:
    (WebKit::accessibilityWebProcessLoaderBundlePath):
    (WebKit::registerWithAccessibility):
    
    Source/WTF:
    Added HAVE_ACCESSIBILITY_BUNDLES_PATH
    https://bugs.webkit.org/show_bug.cgi?id=200367
    
    Patch by Eric Liang <ericliang@apple.com> on 2019-08-17
    Reviewed by Darin Adler.
    
    * wtf/Platform.h:
    
    Tools:
    Tested that accessibility WebProcessLoader bundle is loaded for the correct path.
    https://bugs.webkit.org/show_bug.cgi?id=200367
    
    Patch by Eric Liang <ericliang@apple.com> on 2019-08-17
    Reviewed by Darin Adler.
    
    Added AccessibilityTestPlugin on the web process to report whether a bundle is loaded and its path, so that it can be tested on WKContentView.
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/WebKitCocoa/AccessibilityTestPlugin.mm: Added.
    (-[AccessibilityTestPlugin webProcessPlugIn:didCreateBrowserContextController:]):
    (-[AccessibilityTestPlugin checkAccessibilityWebProcessLoaderBundleIsLoaded:]):
    * TestWebKitAPI/Tests/WebKitCocoa/AccessibilityTestSupportProtocol.h: Added.
    * TestWebKitAPI/Tests/ios/AccessibilityTestsIOS.mm:
    (TestWebKitAPI::TEST):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248823 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-17  Eric Liang  <ericliang@apple.com>

            Use bundlePath SPI in AccessibilitySupport for WebProcessLoader
            https://bugs.webkit.org/show_bug.cgi?id=200367

            Reviewed by Darin Adler.

            * Platform/spi/ios/AccessibilitySupportSPI.h:
            * WebProcess/cocoa/WebProcessCocoa.mm:
            (WebKit::accessibilityWebProcessLoaderBundlePath):
            (WebKit::registerWithAccessibility):

2019-08-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248819. rdar://problem/54455005

    Content in <iframe> should override "touch-action" set in embedding document
    https://bugs.webkit.org/show_bug.cgi?id=200204
    <rdar://problem/54355249>
    
    Reviewed by Antoine Quint.
    
    Source/WebKit:
    
    Subframes where content doesn't use any touch-action properties won't generate event region for their main layer.
    As a result the touch-action property gets computed in UI process to the parent frames touch-action (instead of 'auto').
    
    * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
    (WebKit::touchActionsForPoint):
    
    If the topmost layer hit is a WKChildScrollView we know its content layer didn't have an event region.
    This means we should return the default value 'auto'.
    
    LayoutTests:
    
    * pointerevents/ios/touch-action-none-with-frame-inside-expected.txt: Added.
    * pointerevents/ios/touch-action-none-with-frame-inside.html: Added.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248819 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-17  Antti Koivisto  <antti@apple.com>

            Content in <iframe> should override "touch-action" set in embedding document
            https://bugs.webkit.org/show_bug.cgi?id=200204
            <rdar://problem/54355249>

            Reviewed by Antoine Quint.

            Subframes where content doesn't use any touch-action properties won't generate event region for their main layer.
            As a result the touch-action property gets computed in UI process to the parent frames touch-action (instead of 'auto').

            * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
            (WebKit::touchActionsForPoint):

            If the topmost layer hit is a WKChildScrollView we know its content layer didn't have an event region.
            This means we should return the default value 'auto'.

2019-08-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248791. rdar://problem/54455008

    Long pressing images with transparent backgrounds in dark mode causes a black background to appear around the image content
    https://bugs.webkit.org/show_bug.cgi?id=200827
    <rdar://53933379>
    
    Reviewed by Tim Horton.
    
    Set a clear color when there is no provided background.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (createTargetedPreview):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248791 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-16  Dean Jackson  <dino@apple.com>

            Long pressing images with transparent backgrounds in dark mode causes a black background to appear around the image content
            https://bugs.webkit.org/show_bug.cgi?id=200827
            <rdar://53933379>

            Reviewed by Tim Horton.

            Set a clear color when there is no provided background.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (createTargetedPreview):

2019-08-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248776. rdar://problem/54455007

    REGRESSION (r248436): WKWebView doesn’t respect isOpaque setting in NIB.
    https://bugs.webkit.org/show_bug.cgi?id=200802
    rdar://problem/54357818
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    Tests: WKWebView.IsOpaqueDefault, WKWebView.SetOpaqueYes, WKWebView.SetOpaqueNo, WKWebView.IsOpaqueYesSubclassOverridden,
    WKWebView.IsOpaqueNoSubclassOverridden, WKWebView.IsOpaqueYesDecodedFromArchive, WKWebView.IsOpaqueNoDecodedFromArchive,
    WKWebView.IsOpaqueDrawsBackgroundYesConfiguration, WKWebView.IsOpaqueDrawsBackgroundNoConfiguration.
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _initializeWithConfiguration:]): Call _setOpaqueInternal:NO instead of self.opaque = NO.
    (-[WKWebView _setOpaqueInternal:]): Added. Moved code from setOpaque:.
    (-[WKWebView setOpaque:]): Call _setOpaqueInternal:.
    
    Tools:
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: Added WKWebViewOpaque.mm.
    * TestWebKitAPI/Tests/ios/WKWebViewOpaque.mm: Added.
    (-[OpaqueTestWKWebView isOpaque]): Added.
    (-[NonOpaqueTestWKWebView isOpaque]): Added.
    (isOpaque): Added.
    (TEST): Added WKWebView.IsOpaqueDefault, WKWebView.SetOpaqueYes, WKWebView.SetOpaqueNo, WKWebView.IsOpaqueYesSubclassOverridden,
    WKWebView.IsOpaqueNoSubclassOverridden, WKWebView.IsOpaqueYesDecodedFromArchive, WKWebView.IsOpaqueNoDecodedFromArchive,
    WKWebView.IsOpaqueDrawsBackgroundYesConfiguration, WKWebView.IsOpaqueDrawsBackgroundNoConfiguration.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248776 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-16  Timothy Hatcher  <timothy@apple.com>

            REGRESSION (r248436): WKWebView doesn’t respect isOpaque setting in NIB.
            https://bugs.webkit.org/show_bug.cgi?id=200802
            rdar://problem/54357818

            Reviewed by Tim Horton.

            Tests: WKWebView.IsOpaqueDefault, WKWebView.SetOpaqueYes, WKWebView.SetOpaqueNo, WKWebView.IsOpaqueYesSubclassOverridden,
            WKWebView.IsOpaqueNoSubclassOverridden, WKWebView.IsOpaqueYesDecodedFromArchive, WKWebView.IsOpaqueNoDecodedFromArchive,
            WKWebView.IsOpaqueDrawsBackgroundYesConfiguration, WKWebView.IsOpaqueDrawsBackgroundNoConfiguration.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _initializeWithConfiguration:]): Call _setOpaqueInternal:NO instead of self.opaque = NO.
            (-[WKWebView _setOpaqueInternal:]): Added. Moved code from setOpaque:.
            (-[WKWebView setOpaque:]): Call _setOpaqueInternal:.

2019-08-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248733. rdar://problem/54454989

    Occasional hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] when long-pressing non-editable text
    https://bugs.webkit.org/show_bug.cgi?id=200731
    <rdar://problem/54315371>
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    When handling a single tap in non-editable content, keyboards logic in UIKit may attempt to wait for all
    pending tasks in UIKeyboardTaskQueue to finish executing (e.g. by calling -waitUntilAllTasksAreFinished]). If
    the task queue has a pending task at this moment - for example, a text selection update that is waiting for a
    response from the web process - this will result in a permanent deadlock, since the main thread will be blocked,
    and therefore cannot receive any IPC communication from the web process.
    
    One way to trigger this is to activate both the loupe gesture and non-editable text tap gesture simultaneously,
    by tapping in a non-editable part of the web page, while an ongoing loupe gesture is driving selection updates
    (see the layout test for more details).
    
    To avoid getting into this scenario, prevent the text tap gesture recognizer from firing in a few edge cases
    that could lead to hangs under keyboard code in UIKit. See comments below.
    
    Test: editing/selection/ios/tap-during-loupe-gesture.html
    
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]):
    
    Don't allow the text tap gesture recognizer to fire if the user is actively modifying the text selection using
    the loupe gesture, or if there's other pending selection change updates that are pending responses from the web
    content process.
    
    (-[WKContentView selectTextWithGranularity:atPoint:completionHandler:]):
    (-[WKContentView updateSelectionWithExtentPoint:withBoundary:completionHandler:]):
    
    Increment and decrement _suppressNonEditableSingleTapTextInteractionCount while handling these selection
    updates.
    
    LayoutTests:
    
    Add a layout test to verify that tapping the page while handling a text loupe gesture doesn't cause the UI
    process to hang indefinitely.
    
    * editing/selection/ios/tap-during-loupe-gesture-expected.txt: Added.
    * editing/selection/ios/tap-during-loupe-gesture.html: Added.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248733 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-15  Wenson Hsieh  <wenson_hsieh@apple.com>

            Occasional hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] when long-pressing non-editable text
            https://bugs.webkit.org/show_bug.cgi?id=200731
            <rdar://problem/54315371>

            Reviewed by Tim Horton.

            When handling a single tap in non-editable content, keyboards logic in UIKit may attempt to wait for all
            pending tasks in UIKeyboardTaskQueue to finish executing (e.g. by calling -waitUntilAllTasksAreFinished]). If
            the task queue has a pending task at this moment - for example, a text selection update that is waiting for a
            response from the web process - this will result in a permanent deadlock, since the main thread will be blocked,
            and therefore cannot receive any IPC communication from the web process.

            One way to trigger this is to activate both the loupe gesture and non-editable text tap gesture simultaneously,
            by tapping in a non-editable part of the web page, while an ongoing loupe gesture is driving selection updates
            (see the layout test for more details).

            To avoid getting into this scenario, prevent the text tap gesture recognizer from firing in a few edge cases
            that could lead to hangs under keyboard code in UIKit. See comments below.

            Test: editing/selection/ios/tap-during-loupe-gesture.html

            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]):

            Don't allow the text tap gesture recognizer to fire if the user is actively modifying the text selection using
            the loupe gesture, or if there's other pending selection change updates that are pending responses from the web
            content process.

            (-[WKContentView selectTextWithGranularity:atPoint:completionHandler:]):
            (-[WKContentView updateSelectionWithExtentPoint:withBoundary:completionHandler:]):

            Increment and decrement _suppressNonEditableSingleTapTextInteractionCount while handling these selection
            updates.

2019-08-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r248696. rdar://problem/54333944

    REGRESSION(r245320): Web Automation: Perform Actions hangs when pointerdown happens near top of page
    https://bugs.webkit.org/show_bug.cgi?id=200728
    <rdar://problem/54260518>
    
    Reviewed by Devin Rousso.
    
    In the last major refactoring for this code, it seems that the argument to
    platformSimulateMouseInteraction was not unified to use viewport coordinates
    in all code paths. This patch fixes both callers to *not* add in topContentInset,
    and instead this is added back in when doing platform-specific event simulation.
    
    This has no effect on iOS since it's guarded by ENABLE(WEBDRIVER_MOUSE_INTERACTIONS),
    which is only built on macOS.
    
    * UIProcess/Automation/WebAutomationSession.h:
    * UIProcess/Automation/WebAutomationSession.cpp:
    (WebKit::WebAutomationSession::performMouseInteraction):
    * UIProcess/Automation/mac/WebAutomationSessionMac.mm:
    (WebKit::WebAutomationSession::platformSimulateMouseInteraction):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248696 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-14  Brian Burg  <bburg@apple.com>

            REGRESSION(r245320): Web Automation: Perform Actions hangs when pointerdown happens near top of page
            https://bugs.webkit.org/show_bug.cgi?id=200728
            <rdar://problem/54260518>

            Reviewed by Devin Rousso.

            In the last major refactoring for this code, it seems that the argument to
            platformSimulateMouseInteraction was not unified to use viewport coordinates
            in all code paths. This patch fixes both callers to *not* add in topContentInset,
            and instead this is added back in when doing platform-specific event simulation.

            This has no effect on iOS since it's guarded by ENABLE(WEBDRIVER_MOUSE_INTERACTIONS),
            which is only built on macOS.

            * UIProcess/Automation/WebAutomationSession.h:
            * UIProcess/Automation/WebAutomationSession.cpp:
            (WebKit::WebAutomationSession::performMouseInteraction):
            * UIProcess/Automation/mac/WebAutomationSessionMac.mm:
            (WebKit::WebAutomationSession::platformSimulateMouseInteraction):

2019-08-15  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248731. rdar://problem/54360857

    Unreviewed, rolling out r248440.
    https://bugs.webkit.org/show_bug.cgi?id=200772
    
    Introduced regressions related to loading of local files.
    (Requested by perarne on #webkit).
    
    Reverted changeset:
    
    "[Mac] Use the PID of the WebContent process when issuing
    local file read sandbox extensions"
    https://bugs.webkit.org/show_bug.cgi?id=200543
    https://trac.webkit.org/changeset/248440
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248731 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-15  Commit Queue  <commit-queue@webkit.org>

            Unreviewed, rolling out r248440.
            https://bugs.webkit.org/show_bug.cgi?id=200772

            Introduced regressions related to loading of local files.
            (Requested by perarne on #webkit).

            Reverted changeset:

            "[Mac] Use the PID of the WebContent process when issuing
            local file read sandbox extensions"
            https://bugs.webkit.org/show_bug.cgi?id=200543
            https://trac.webkit.org/changeset/248440

2019-08-15  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248717. rdar://problem/54360854

    WKUIDelegate's webView:contextMenuDidEndForElement: should be called when context menus end
    https://bugs.webkit.org/show_bug.cgi?id=200750
    <rdar://problem/54232261> and <rdar://problem/52355829>
    
    Patch by Alex Christensen <achristensen@webkit.org> on 2019-08-15
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]):
    
    Tools:
    
    * TestWebKitAPI/Tests/WebKitCocoa/ContextMenus.mm:
    (-[TestContextMenuUIDelegate webView:contextMenuConfigurationForElement:completionHandler:]):
    (-[TestContextMenuUIDelegate webView:contextMenuForElement:willCommitWithAnimator:]):
    (-[TestContextMenuUIDelegate webView:contextMenuDidEndForElement:]):
    (contextMenuWebViewDriver):
    (TEST):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248717 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-15  Alex Christensen  <achristensen@webkit.org>

            WKUIDelegate's webView:contextMenuDidEndForElement: should be called when context menus end
            https://bugs.webkit.org/show_bug.cgi?id=200750
            <rdar://problem/54232261> and <rdar://problem/52355829>

            Reviewed by Tim Horton.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]):

2019-08-15  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248690. rdar://problem/54333950

    v3: CrashTracer: Regression : MobileSafari at UIKitCore: -[UITargetedPreview initWithView:parameters:]
    https://bugs.webkit.org/show_bug.cgi?id=200634
    
    Patch by Luming Yin <luming_yin@apple.com> on 2019-08-14
    Reviewed by Simon Fraser.
    
    Under rare race conditions, the WKContentView may no longer have an associated window. However,
    UIContextMenuInteraction may still attempt initialize a UITargetedPreview with the orphaned
    WKContentView. Speculative fix for crashes under such scenarios, so that we can continue without
    a context menu configuration to prevent the UIKit exception.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView continueContextMenuInteraction:]):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248690 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-14  Luming Yin  <luming_yin@apple.com>

            v3: CrashTracer: Regression : MobileSafari at UIKitCore: -[UITargetedPreview initWithView:parameters:]
            https://bugs.webkit.org/show_bug.cgi?id=200634

            Reviewed by Simon Fraser.

            Under rare race conditions, the WKContentView may no longer have an associated window. However,
            UIContextMenuInteraction may still attempt initialize a UITargetedPreview with the orphaned
            WKContentView. Speculative fix for crashes under such scenarios, so that we can continue without
            a context menu configuration to prevent the UIKit exception.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView continueContextMenuInteraction:]):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248634. rdar://problem/54282811

    Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction()
    https://bugs.webkit.org/show_bug.cgi?id=200688
    
    Reviewed by Alex Christensen.
    
    Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction().
    It passes a RegistrableDomain to another thread without isolated copying it.
    
    * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
    (WebKit::WebResourceLoadStatisticsStore::hasHadUserInteraction):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248634 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-13  Chris Dumez  <cdumez@apple.com>

            Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction()
            https://bugs.webkit.org/show_bug.cgi?id=200688

            Reviewed by Alex Christensen.

            Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction().
            It passes a RegistrableDomain to another thread without isolated copying it.

            * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
            (WebKit::WebResourceLoadStatisticsStore::hasHadUserInteraction):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248633. rdar://problem/54282803

    Fix potential thread safety issue under StorageManager::getSessionStorageOrigins()
    https://bugs.webkit.org/show_bug.cgi?id=200684
    
    Reviewed by Geoffrey Garen.
    
    Fix potential thread safety issue under StorageManager::getSessionStorageOrigins(). The origins are being
    passed from the background queue to the main thread without isolated copy.
    
    * NetworkProcess/WebStorage/StorageManager.cpp:
    (WebKit::StorageManager::getSessionStorageOrigins):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248633 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-13  Chris Dumez  <cdumez@apple.com>

            Fix potential thread safety issue under StorageManager::getSessionStorageOrigins()
            https://bugs.webkit.org/show_bug.cgi?id=200684

            Reviewed by Geoffrey Garen.

            Fix potential thread safety issue under StorageManager::getSessionStorageOrigins(). The origins are being
            passed from the background queue to the main thread without isolated copy.

            * NetworkProcess/WebStorage/StorageManager.cpp:
            (WebKit::StorageManager::getSessionStorageOrigins):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248598. rdar://problem/54282797

    Crash under IPC::Connection::markCurrentlyDispatchedMessageAsInvalid()
    https://bugs.webkit.org/show_bug.cgi?id=200674
    <rdar://problem/50692748>
    
    Reviewed by Geoff Garen.
    
    Source/WebKit:
    
    When the client terminates a provisional process (e.g. via the [WKWebView _killWebContentProcessAndResetState]
    SPI), the WebProcessProxy would notify its associated WebPageProxy objects that it had terminated but would fail
    to notify its associated ProvisionalPageProxy objects. As a result, those objects would not get destroyed and
    would still think that they were in the middle of a provisional load the next time a load started. This inconsistent
    state would lead to crashes such as the one in the radar.
    
    * UIProcess/ProvisionalPageProxy.cpp:
    (WebKit::ProvisionalPageProxy::cancel):
    * UIProcess/WebProcessProxy.cpp:
    (WebKit::WebProcessProxy::requestTermination):
    
    Tools:
    
    Add API test coverage.
    
    * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248598 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-13  Chris Dumez  <cdumez@apple.com>

            Crash under IPC::Connection::markCurrentlyDispatchedMessageAsInvalid()
            https://bugs.webkit.org/show_bug.cgi?id=200674
            <rdar://problem/50692748>

            Reviewed by Geoff Garen.

            When the client terminates a provisional process (e.g. via the [WKWebView _killWebContentProcessAndResetState]
            SPI), the WebProcessProxy would notify its associated WebPageProxy objects that it had terminated but would fail
            to notify its associated ProvisionalPageProxy objects. As a result, those objects would not get destroyed and
            would still think that they were in the middle of a provisional load the next time a load started. This inconsistent
            state would lead to crashes such as the one in the radar.

            * UIProcess/ProvisionalPageProxy.cpp:
            (WebKit::ProvisionalPageProxy::cancel):
            * UIProcess/WebProcessProxy.cpp:
            (WebKit::WebProcessProxy::requestTermination):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/54236234

    2019-08-13  Chris Dumez  <cdumez@apple.com>

            Crash under NetworkResourceLoader::start()
            https://bugs.webkit.org/show_bug.cgi?id=200628
            <rdar://problem/54220519>

            Reviewed by Youenn Fablet.

            Simplified version of r248540 for the branch.

            * NetworkProcess/NetworkResourceLoader.cpp:
            (WebKit::NetworkResourceLoader::start):
            * NetworkProcess/NetworkResourceLoader.h:

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248440. rdar://problem/54237795

    [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions
    https://bugs.webkit.org/show_bug.cgi?id=200543
    Source/WebKit:
    
    Reviewed by Brent Fulgham.
    
    Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process
    identifier of the WebContent process.
    
    * Shared/Cocoa/SandboxExtensionCocoa.mm:
    (WebKit::SandboxExtensionImpl::sandboxExtensionForType):
    (WebKit::SandboxExtension::createHandleForReadByPid):
    * Shared/SandboxExtension.h:
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
    
    Source/WTF:
    
    <rdar://problem/49394015>
    
    Reviewed by Brent Fulgham.
    
    Add new SPI.
    
    * wtf/Platform.h:
    * wtf/spi/darwin/SandboxSPI.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248440 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-08  Per Arne Vollan  <pvollan@apple.com>

            [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions
            https://bugs.webkit.org/show_bug.cgi?id=200543

            Reviewed by Brent Fulgham.

            Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process
            identifier of the WebContent process.

            * Shared/Cocoa/SandboxExtensionCocoa.mm:
            (WebKit::SandboxExtensionImpl::sandboxExtensionForType):
            (WebKit::SandboxExtension::createHandleForReadByPid):
            * Shared/SandboxExtension.h:
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248548. rdar://problem/54237813

    Fix Crash in Mail Search
    https://bugs.webkit.org/show_bug.cgi?id=200589
    Source/WebKit:
    
    <rdar://problem/53666720>
    
    Reviewed by Tim Horton.
    
    If we search in Mail backwards first, for AppKit reasons
    we get a -1 for the index of the found item.
    Do not try and insert data in this case.
    
    * UIProcess/mac/WKTextFinderClient.mm:
    
    Tools:
    
    Reviewed by Tim Horton.
    
    If you search backwards first in mail, we would crash,
    this tests that codepath.
    
    * TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
    (TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248548 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-12  Megan Gardner  <megan_gardner@apple.com>

            Fix Crash in Mail Search
            https://bugs.webkit.org/show_bug.cgi?id=200589
            <rdar://problem/53666720>

            Reviewed by Tim Horton.

            If we search in Mail backwards first, for AppKit reasons
            we get a -1 for the index of the found item.
            Do not try and insert data in this case.

            * UIProcess/mac/WKTextFinderClient.mm:

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248543. rdar://problem/54237801

    Clear m_sessionStorageNamespaces on the background thread
    https://bugs.webkit.org/show_bug.cgi?id=200631
    <rdar://problem/54149638>
    
    Reviewed by Chris Dumez.
    
    Network process receives messages about web page state from web process and destroys sessionStorageNamespace if
    needed. It also receives messages about session state from UI process and destroys StorageManager, which owns
    SessionStorageNamespaces, if needed. Because of the race in receiving the messages from different processes,
    network process may decide to destroy StorageManager before destroying all SessionStorageNamespaces, and
    SessionStorageNamespaces are destroyed with StorageManager on the main thread.
    
    * NetworkProcess/WebStorage/StorageManager.cpp:
    (WebKit::StorageManager::waitUntilTasksFinished):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248543 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-12  Sihui Liu  <sihui_liu@apple.com>

            Clear m_sessionStorageNamespaces on the background thread
            https://bugs.webkit.org/show_bug.cgi?id=200631
            <rdar://problem/54149638>

            Reviewed by Chris Dumez.

            Network process receives messages about web page state from web process and destroys sessionStorageNamespace if
            needed. It also receives messages about session state from UI process and destroys StorageManager, which owns
            SessionStorageNamespaces, if needed. Because of the race in receiving the messages from different processes,
            network process may decide to destroy StorageManager before destroying all SessionStorageNamespaces, and
            SessionStorageNamespaces are destroyed with StorageManager on the main thread.

            * NetworkProcess/WebStorage/StorageManager.cpp:
            (WebKit::StorageManager::waitUntilTasksFinished):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248166. rdar://problem/54237837

    [macOS 10.15] Image dragged from Safari does not appear in Notes
    https://bugs.webkit.org/show_bug.cgi?id=188490
    <rdar://problem/39462717>
    
    Reviewed by Andy Estes.
    
    Source/WebKit:
    
    Removes some logic that clears out the cached promised drag image in the UI process when WebKit is asked to
    provide TIFF image data. This prevents the drop destination from asking for promised image data, if anything
    else (e.g. the system) also asks the web view to provide the same data. Additionally, this logic didn't
    previously guarantee that the promised image would be cleared anyways, since it is dependent on the drop target
    actually requesting the promised image in order to perform the cleanup.
    
    In lieu of clearing the promised drag image when it's requested, we instead clear it out upon mainframe
    navigation, in PageClientImpl::didCommitLoadForMainFrame.
    
    Test: DragAndDropTests.MultiplePromisedImageDataRequests
    
    * UIProcess/Cocoa/WebViewImpl.h:
    * UIProcess/Cocoa/WebViewImpl.mm:
    (WebKit::WebViewImpl::clearPromisedDragImage):
    (WebKit::WebViewImpl::pasteboardChangedOwner):
    (WebKit::WebViewImpl::provideDataForPasteboard):
    
    Fix the bug by not immediately clearing out the promised drag image.
    
    * UIProcess/mac/PageClientImplMac.mm:
    (WebKit::PageClientImpl::didCommitLoadForMainFrame):
    
    Tools:
    
    Add a test to verify that promised image data can be delivered to multiple pasteboards when performing a drop.
    
    * TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248166 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-02  Wenson Hsieh  <wenson_hsieh@apple.com>

            [macOS 10.15] Image dragged from Safari does not appear in Notes
            https://bugs.webkit.org/show_bug.cgi?id=188490
            <rdar://problem/39462717>

            Reviewed by Andy Estes.

            Removes some logic that clears out the cached promised drag image in the UI process when WebKit is asked to
            provide TIFF image data. This prevents the drop destination from asking for promised image data, if anything
            else (e.g. the system) also asks the web view to provide the same data. Additionally, this logic didn't
            previously guarantee that the promised image would be cleared anyways, since it is dependent on the drop target
            actually requesting the promised image in order to perform the cleanup.

            In lieu of clearing the promised drag image when it's requested, we instead clear it out upon mainframe
            navigation, in PageClientImpl::didCommitLoadForMainFrame.

            Test: DragAndDropTests.MultiplePromisedImageDataRequests

            * UIProcess/Cocoa/WebViewImpl.h:
            * UIProcess/Cocoa/WebViewImpl.mm:
            (WebKit::WebViewImpl::clearPromisedDragImage):
            (WebKit::WebViewImpl::pasteboardChangedOwner):
            (WebKit::WebViewImpl::provideDataForPasteboard):

            Fix the bug by not immediately clearing out the promised drag image.

            * UIProcess/mac/PageClientImplMac.mm:
            (WebKit::PageClientImpl::didCommitLoadForMainFrame):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248550. rdar://problem/54237677

    Contextual menu Hide and Show Link Previews should not have a symbol
    https://bugs.webkit.org/show_bug.cgi?id=200645
    <rdar://problem/54129647>
    
    Reviewed by Wenson Hsieh.
    
    Don't use an image on the UIMenuItem.
    
    * UIProcess/API/Cocoa/_WKElementAction.mm:
    (+[_WKElementAction imageForElementActionType:]): Return nil for Show/Hide Link Previews.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248550 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-12  Dean Jackson  <dino@apple.com>

            Contextual menu Hide and Show Link Previews should not have a symbol
            https://bugs.webkit.org/show_bug.cgi?id=200645
            <rdar://problem/54129647>

            Reviewed by Wenson Hsieh.

            Don't use an image on the UIMenuItem.

            * UIProcess/API/Cocoa/_WKElementAction.mm:
            (+[_WKElementAction imageForElementActionType:]): Return nil for Show/Hide Link Previews.

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248541. rdar://problem/54237768

    [iPadOS] Web pages sometimes load at half width in Safari
    https://bugs.webkit.org/show_bug.cgi?id=200624
    <rdar://problem/52694257>
    
    Reviewed by Simon Fraser.
    
    Source/WebKit:
    
    Whenever WKWebView's size changes, it normally notifies the web content process by calling into WebPageProxy::
    setViewportConfigurationViewLayoutSize, which remembers this view layout size using a member variable,
    m_viewportConfigurationViewLayoutSize. Later, m_viewportConfigurationViewLayoutSize is consulted as a part of
    constructing the creation parameters used to set up a new page.
    
    However, during animated resize, WKWebView avoids these calls to setViewportConfigurationViewLayoutSize via the
    dynamic viewport update mode check in -[WKWebView _frameOrBoundsChanged]. Instead, the new view layout size is
    pushed to the web process by calling WebPageProxy::dynamicViewportSizeUpdate.
    
    Since dynamicViewportSizeUpdate doesn't update m_viewportConfigurationViewLayoutSize, the next
    WebPageCreationParameters that are created with this WebPageProxy (e.g. after a process swap, or after
    reloading, if the process was terminated) will use the size of the WKWebView prior to the most recent animated
    resize.
    
    To fix the bug, we simply make sure that m_viewportConfigurationViewLayoutSize is updated in the dynamic
    viewport size update (i.e. animated resize) case as well.
    
    Test: WebKit.CreateWebPageAfterAnimatedResize
    
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::WebPageProxy::dynamicViewportSizeUpdate):
    
    Tools:
    
    Add an API test to verify that after performing an animated resize and killing the web process, the subsequent
    web page is created using the post-animated-resize web view dimensions, rather than the original layout
    dimensions.
    
    * TestWebKitAPI/Tests/WebKitCocoa/AnimatedResize.mm:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248541 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-12  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iPadOS] Web pages sometimes load at half width in Safari
            https://bugs.webkit.org/show_bug.cgi?id=200624
            <rdar://problem/52694257>

            Reviewed by Simon Fraser.

            Whenever WKWebView's size changes, it normally notifies the web content process by calling into WebPageProxy::
            setViewportConfigurationViewLayoutSize, which remembers this view layout size using a member variable,
            m_viewportConfigurationViewLayoutSize. Later, m_viewportConfigurationViewLayoutSize is consulted as a part of
            constructing the creation parameters used to set up a new page.

            However, during animated resize, WKWebView avoids these calls to setViewportConfigurationViewLayoutSize via the
            dynamic viewport update mode check in -[WKWebView _frameOrBoundsChanged]. Instead, the new view layout size is
            pushed to the web process by calling WebPageProxy::dynamicViewportSizeUpdate.

            Since dynamicViewportSizeUpdate doesn't update m_viewportConfigurationViewLayoutSize, the next
            WebPageCreationParameters that are created with this WebPageProxy (e.g. after a process swap, or after
            reloading, if the process was terminated) will use the size of the WKWebView prior to the most recent animated
            resize.

            To fix the bug, we simply make sure that m_viewportConfigurationViewLayoutSize is updated in the dynamic
            viewport size update (i.e. animated resize) case as well.

            Test: WebKit.CreateWebPageAfterAnimatedResize

            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::dynamicViewportSizeUpdate):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248487. rdar://problem/54237679

    [iOS 13] Google Docs/Slides/Sheets: paste often doesn't work and sometimes produces an error
    https://bugs.webkit.org/show_bug.cgi?id=200591
    <rdar://problem/54102238>
    
    Reviewed by Ryosuke Niwa and Tim Horton.
    
    Source/WebKit:
    
    Adopts UIKit SPI to avoid incrementing the general pasteboard's change count whenever an editable element is
    focused. This is due to how, in iOS 13, UIKit temporarily writes an image to the pasteboard when showing the
    keyboard, to determine whether or not to show the Memojis in the input view.
    
    This causes UIPasteboard's changeCount to increment twice due to adding and then removing the image, which means
    that the changeCount sanity checks in the web process will race against the pasteboard gaining and then losing
    this temporary image.
    
    Instead, the new -supportsImagePaste SPI may be used to short-circuit this step, and avoid updating the
    changeCount when UIKeyboardImpl's delegate changes.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView supportsImagePaste]):
    
    Tools:
    
    Add a new API test to exercise -supportsImagePaste.
    
    * TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
    (TestWebKitAPI::TEST):
    * TestWebKitAPI/ios/UIKitSPI.h:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248487 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-09  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iOS 13] Google Docs/Slides/Sheets: paste often doesn't work and sometimes produces an error
            https://bugs.webkit.org/show_bug.cgi?id=200591
            <rdar://problem/54102238>

            Reviewed by Ryosuke Niwa and Tim Horton.

            Adopts UIKit SPI to avoid incrementing the general pasteboard's change count whenever an editable element is
            focused. This is due to how, in iOS 13, UIKit temporarily writes an image to the pasteboard when showing the
            keyboard, to determine whether or not to show the Memojis in the input view.

            This causes UIPasteboard's changeCount to increment twice due to adding and then removing the image, which means
            that the changeCount sanity checks in the web process will race against the pasteboard gaining and then losing
            this temporary image.

            Instead, the new -supportsImagePaste SPI may be used to short-circuit this step, and avoid updating the
            changeCount when UIKeyboardImpl's delegate changes.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView supportsImagePaste]):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248433. rdar://problem/54237689

    [iOS 13] Taps that interrupt momentum scrolling are recognized as clicks
    https://bugs.webkit.org/show_bug.cgi?id=200516
    <rdar://problem/53889373>
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    After <https://trac.webkit.org/r247656>, the -tracksImmediatelyWhileDecelerating property of WKScrollView and
    WKChildScrollView is set to NO. This means that if a user interacts with the page while the scroll view is
    decelerating (e.g. after momentum scrolling), the pan gesture recognizer will not be immediately recognized.
    This gives other gesture recognizers, such as the synthetic click (single tap) gesture a chance to instead
    recognize first. In this particular bug, this causes taps on the web view that are intended to only stop
    momentum scrolling to instead activate clickable elements beneath the touch, such as links and buttons.
    
    To mitigate this, we add some logic to prevent the click gesture recognizer from firing in the case where the
    tap also causes the scroll view to decelerate. This heuristic is similar to the one introduced in r219310, which
    has the same purpose of hiding gestures that stop momentum scrolling from the page, and also consults
    -[UIScrollView _isInterruptingDeceleration].
    
    Tests:  fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame.html
            fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body.html
            fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow.html
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView gestureRecognizerShouldBegin:]):
    
    Return NO in the case of the single tap gesture if the UIScrollView most recently touched by the single tap
    gesture (or one of its enclosing scroll views, up to the main WKScrollView) is being interrupted while
    decelerating.
    
    * UIProcess/ios/WKSyntheticTapGestureRecognizer.h:
    * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm:
    (-[WKSyntheticTapGestureRecognizer reset]):
    (-[WKSyntheticTapGestureRecognizer touchesBegan:withEvent:]):
    
    Teach WKSyntheticTapGestureRecognizer to keep track of the last WKScrollView that was touched, for later use in
    -gestureRecognizerShouldBegin:. To do this, we keep a weak reference to the first UIScrollView we find in the
    set of touches.
    
    (-[WKSyntheticTapGestureRecognizer lastTouchedScrollView]):
    
    LayoutTests:
    
    Add new layout tests. See below for details.
    
    * fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame-expected.txt: Added.
    * fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame.html: Added.
    
    Add a test to verify that interrupting scrolling in the main frame using a tap doesn't fire a click event.
    
    * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body-expected.txt: Added.
    * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body.html: Added.
    
    Add a test to verify that after triggering momentum scrolling in a fast subscrollable region, tapping outside of
    the scroller will still fire a click event.
    
    * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-expected.txt: Added.
    * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow.html: Added.
    
    Add a test to verify that interrupting scrolling in a fast subscrollable region using a tap doesn't fire a
    click event.
    
    * resources/ui-helper.js:
    (window.UIHelper.dragFromPointToPoint):
    (window.UIHelper):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248433 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-08  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iOS 13] Taps that interrupt momentum scrolling are recognized as clicks
            https://bugs.webkit.org/show_bug.cgi?id=200516
            <rdar://problem/53889373>

            Reviewed by Tim Horton.

            After <https://trac.webkit.org/r247656>, the -tracksImmediatelyWhileDecelerating property of WKScrollView and
            WKChildScrollView is set to NO. This means that if a user interacts with the page while the scroll view is
            decelerating (e.g. after momentum scrolling), the pan gesture recognizer will not be immediately recognized.
            This gives other gesture recognizers, such as the synthetic click (single tap) gesture a chance to instead
            recognize first. In this particular bug, this causes taps on the web view that are intended to only stop
            momentum scrolling to instead activate clickable elements beneath the touch, such as links and buttons.

            To mitigate this, we add some logic to prevent the click gesture recognizer from firing in the case where the
            tap also causes the scroll view to decelerate. This heuristic is similar to the one introduced in r219310, which
            has the same purpose of hiding gestures that stop momentum scrolling from the page, and also consults
            -[UIScrollView _isInterruptingDeceleration].

            Tests:  fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame.html
                    fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body.html
                    fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow.html

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView gestureRecognizerShouldBegin:]):

            Return NO in the case of the single tap gesture if the UIScrollView most recently touched by the single tap
            gesture (or one of its enclosing scroll views, up to the main WKScrollView) is being interrupted while
            decelerating.

            * UIProcess/ios/WKSyntheticTapGestureRecognizer.h:
            * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm:
            (-[WKSyntheticTapGestureRecognizer reset]):
            (-[WKSyntheticTapGestureRecognizer touchesBegan:withEvent:]):

            Teach WKSyntheticTapGestureRecognizer to keep track of the last WKScrollView that was touched, for later use in
            -gestureRecognizerShouldBegin:. To do this, we keep a weak reference to the first UIScrollView we find in the
            set of touches.

            (-[WKSyntheticTapGestureRecognizer lastTouchedScrollView]):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248430. rdar://problem/54237652

    Use "safari" glyph for "Show Link Previews" contextual menu
    https://bugs.webkit.org/show_bug.cgi?id=200544
    <rdar://problem/54087842>
    
    Reviewed by Tim Horton.
    
    Use the system image for the compass.
    
    * UIProcess/API/Cocoa/_WKElementAction.mm:
    (+[_WKElementAction imageForElementActionType:]):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248430 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-08  Dean Jackson  <dino@apple.com>

            Use "safari" glyph for "Show Link Previews" contextual menu
            https://bugs.webkit.org/show_bug.cgi?id=200544
            <rdar://problem/54087842>

            Reviewed by Tim Horton.

            Use the system image for the compass.

            * UIProcess/API/Cocoa/_WKElementAction.mm:
            (+[_WKElementAction imageForElementActionType:]):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248338. rdar://problem/54237654

    [iPadOS] slides.google.com: tapping near cursor in a slide title focuses the speaker notes
    https://bugs.webkit.org/show_bug.cgi?id=200216
    
    Reviewed by Wenson Hsieh.
    
    Source/WebKit:
    
    The bug was caused by a race condition between Google slides removing inputmode="none" from the hidden
    content editable and updating the focused region upon receiving a pointerup event, which happens after
    the Google slides had already updated its page layout & coordinates based on new visual viewport with
    the software keyboard's boudning rect taken into account.
    
    Delay bringing up the software keyboard for a inputmode change until all touches are released.
    
    In the future, we could consider also delaying the software keyboard to be brought in general until
    touchend / pointerup events are dispatched but this is rather risky since that could affact random
    other websites while Google suites is the only major site to make use of inputmode="none".
    
    This patch also reverts r243044, which was added for Google slides, since it's no longer needed and
    interferes with this patch by adding another way to bring up the software keyboard.
    
    Note: Adjusting touchend / pointerup coordinates while the keyboard is being brought up doesn't work
    because the page had already updated the layout by then based on new visual viewport size.
    
    Test: fast/forms/ios/inputmode-change-update-keyboard-after-pointerup.html
    
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::handleTouchEventSynchronously): Call didReleaseAllTouchPoints when all
    touches are released.
    (WebKit::WebPageProxy::handleTouchEventAsynchronously): Ditto.
    (WebKit::WebPageProxy::handleTouchEvent): Ditto.
    * UIProcess/WebPageProxy.h:
    (WebKit::WebPageProxy::didReleaseAllTouchPoints): Added for non-iOS platforms.
    (WebKit::WebPageProxy::m_pendingInputModeChange): Added. Used when inputmode is changed while
    there is an on-going touch interaction.
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::WebPageProxy::elementDidFocus): Clear m_pendingInputModeChange when a new element is focused.
    (WebKit::WebPageProxy::elementDidBlur): Ditto for bluring.
    (WebKit::WebPageProxy::focusedElementDidChangeInputMode): Don't bring up the software keyboard now if
    there are on-going touches by exiting early after setting m_pendingInputModeChange.
    (WebKit::WebPageProxy::didReleaseAllTouchPoints): Bring up the software keyboard if inputmode
    had changed from "none" to something else.
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::dispatchTouchEvent): Removed the code added by r243044.
    
    LayoutTests:
    
    Added a new regression test and removed the one added for r243044.
    
    * fast/events/touch/ios/show-keyboard-after-preventing-touchstart-expected.txt: Removed.
    * fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html: Removed.
    * fast/forms/ios/inputmode-change-update-keyboard-after-pointerup-expected.txt: Added.
    * fast/forms/ios/inputmode-change-update-keyboard-after-pointerup.html: Added.
    * fast/forms/ios/inputmode-change-update-keyboard.html: Fixed the test for manual testing.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248338 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-06  Ryosuke Niwa  <rniwa@webkit.org>

            [iPadOS] slides.google.com: tapping near cursor in a slide title focuses the speaker notes
            https://bugs.webkit.org/show_bug.cgi?id=200216

            Reviewed by Wenson Hsieh.

            The bug was caused by a race condition between Google slides removing inputmode="none" from the hidden
            content editable and updating the focused region upon receiving a pointerup event, which happens after
            the Google slides had already updated its page layout & coordinates based on new visual viewport with
            the software keyboard's boudning rect taken into account.

            Delay bringing up the software keyboard for a inputmode change until all touches are released.

            In the future, we could consider also delaying the software keyboard to be brought in general until
            touchend / pointerup events are dispatched but this is rather risky since that could affact random
            other websites while Google suites is the only major site to make use of inputmode="none".

            This patch also reverts r243044, which was added for Google slides, since it's no longer needed and
            interferes with this patch by adding another way to bring up the software keyboard.

            Note: Adjusting touchend / pointerup coordinates while the keyboard is being brought up doesn't work
            because the page had already updated the layout by then based on new visual viewport size.

            Test: fast/forms/ios/inputmode-change-update-keyboard-after-pointerup.html

            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::handleTouchEventSynchronously): Call didReleaseAllTouchPoints when all
            touches are released.
            (WebKit::WebPageProxy::handleTouchEventAsynchronously): Ditto.
            (WebKit::WebPageProxy::handleTouchEvent): Ditto.
            * UIProcess/WebPageProxy.h:
            (WebKit::WebPageProxy::didReleaseAllTouchPoints): Added for non-iOS platforms.
            (WebKit::WebPageProxy::m_pendingInputModeChange): Added. Used when inputmode is changed while
            there is an on-going touch interaction.
            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::elementDidFocus): Clear m_pendingInputModeChange when a new element is focused.
            (WebKit::WebPageProxy::elementDidBlur): Ditto for bluring.
            (WebKit::WebPageProxy::focusedElementDidChangeInputMode): Don't bring up the software keyboard now if
            there are on-going touches by exiting early after setting m_pendingInputModeChange.
            (WebKit::WebPageProxy::didReleaseAllTouchPoints): Bring up the software keyboard if inputmode
            had changed from "none" to something else.
            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::dispatchTouchEvent): Removed the code added by r243044.

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248281. rdar://problem/54237787

    iOS 13: Overflow:hidden on body prevents PDF scroll
    https://bugs.webkit.org/show_bug.cgi?id=200435
    rdar://problem/53942888
    
    Reviewed by Tim Horton.
    Source/WebKit:
    
    When we navigate from an overflow:hidden HTML page to a custom view (like PDF), we need
    to make sure that the scroll view is scrollable.
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _setHasCustomContentView:loadedMIMEType:]):
    
    Tools:
    
    When we navigate from an overflow:hidden HTML page to a custom view (like PDF), we need
    to make sure that the scroll view is scrollable.
    
    * TestWebKitAPI/Tests/ios/ScrollViewScrollabilityTests.mm:
    (TestWebKitAPI::TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248281 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-05  Simon Fraser  <simon.fraser@apple.com>

            iOS 13: Overflow:hidden on body prevents PDF scroll
            https://bugs.webkit.org/show_bug.cgi?id=200435
            rdar://problem/53942888

            Reviewed by Tim Horton.

            When we navigate from an overflow:hidden HTML page to a custom view (like PDF), we need
            to make sure that the scroll view is scrollable.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _setHasCustomContentView:loadedMIMEType:]):

2019-08-13  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248174. rdar://problem/54237758

    [iPadOS] slides.google.com: Full Screen API warning is presented when swiping through slides
    https://bugs.webkit.org/show_bug.cgi?id=200313
    <rdar://problem/53777001>
    
    Reviewed by Eric Carlson.
    
    Only run the secheuristic scoring during UIGestureRecognizerStateEnded, rather than both
    UIGestureRecognizerStateEnded and UIGestureRecognizerStateBegan. The goal of the heuristic is
    to detect fake on-screen keyboards by detecting gestures that look like "typing". Using only
    UIGestureRecognizerStateEnded still allows us to do this (as typing will usually have identical
    geometries for both Ended and Began) without generating false-positives during swipe gestures.
    
    * UIProcess/ios/fullscreen/WKFullScreenViewController.mm:
    (-[WKFullScreenViewController _touchDetected:]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248174 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-02  Jer Noble  <jer.noble@apple.com>

            [iPadOS] slides.google.com: Full Screen API warning is presented when swiping through slides
            https://bugs.webkit.org/show_bug.cgi?id=200313
            <rdar://problem/53777001>

            Reviewed by Eric Carlson.

            Only run the secheuristic scoring during UIGestureRecognizerStateEnded, rather than both
            UIGestureRecognizerStateEnded and UIGestureRecognizerStateBegan. The goal of the heuristic is
            to detect fake on-screen keyboards by detecting gestures that look like "typing". Using only
            UIGestureRecognizerStateEnded still allows us to do this (as typing will usually have identical
            geometries for both Ended and Began) without generating false-positives during swipe gestures.

            * UIProcess/ios/fullscreen/WKFullScreenViewController.mm:
            (-[WKFullScreenViewController _touchDetected:]):

2019-08-12  Alan Coon  <alancoon@apple.com>

        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
    <rdar://problem/54015403>
    
    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  <achristensen@webkit.org>

            Disable ContentChangeObserver TouchEvent adjustment on youtube.com on iOS in mobile browsing mode
            https://bugs.webkit.org/show_bug.cgi?id=200609
            <rdar://problem/54015403>

            Reviewed by Maciej Stachowiak.

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

2019-08-12  Alan Coon  <alancoon@apple.com>

        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 <sabouhallawa@apple.com> 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  <sabouhallawa@apple.com>

            [iOS] Add a quirk for gmail.com messages on iPhone iOS13
            https://bugs.webkit.org/show_bug.cgi?id=200605

            Reviewed by Maciej Stachowiak.

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

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248481. rdar://problem/54130658

    [iOS WK2] Remove context menu hints on navigation
    https://bugs.webkit.org/show_bug.cgi?id=200588
    rdar://problem/54061796
    
    Reviewed by Tim Horton.
    
    Make sure the context menu hint doesn't linger across navigations by hosting it in its
    own container view (shared with drag previews), and hiding that view on navigation (unparenting
    may have bad consequences). We remove the view when the animation ends.
    
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _didCommitLoadForMainFrame]):
    (-[WKContentView containerViewForTargetedPreviews]):
    (-[WKContentView _hideContextMenu]):
    (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248481 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-09  Simon Fraser  <simon.fraser@apple.com>

            [iOS WK2] Remove context menu hints on navigation
            https://bugs.webkit.org/show_bug.cgi?id=200588
            rdar://problem/54061796

            Reviewed by Tim Horton.

            Make sure the context menu hint doesn't linger across navigations by hosting it in its
            own container view (shared with drag previews), and hiding that view on navigation (unparenting
            may have bad consequences). We remove the view when the animation ends.

            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _didCommitLoadForMainFrame]):
            (-[WKContentView containerViewForTargetedPreviews]):
            (-[WKContentView _hideContextMenu]):
            (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]):

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248471. rdar://problem/54130624

    Disable CSSOM View Scrolling API for IMDb iOS app
    https://bugs.webkit.org/show_bug.cgi?id=200586
    <rdar://problem/53645833>
    
    Patch by Alex Christensen <achristensen@webkit.org> 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  <achristensen@webkit.org>

            Disable CSSOM View Scrolling API for IMDb iOS app
            https://bugs.webkit.org/show_bug.cgi?id=200586
            <rdar://problem/53645833>

            Reviewed by Simon Fraser.

            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:

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248469. rdar://problem/54130688

    Tapping buttons in Data Detectors lookup previews doesn't work
    https://bugs.webkit.org/show_bug.cgi?id=200579
    <rdar://problem/54056519>
    
    Reviewed by Megan Gardner.
    
    Source/WebCore/PAL:
    
    * pal/spi/ios/DataDetectorsUISPI.h:
    
    Source/WebKit:
    
    * Platform/spi/ios/UIKitSPI.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _contextMenuInteraction:styleForMenuWithConfiguration:]):
    If a Data Detectors context menu wants the action menu style, provide it.
    
    (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]):
    If a Data Detectors context menu provides a view controller to present
    on context menu commit, present it. We present on top of the same view
    controller that is currently presenting the context menu, but modally
    instead of inside the context menu.
    
    If a Data Detectors context menu instead provides a URL to launch on
    context menu commit, call openURL.
    
    In both cases, change the commit style to pop, since we're committing
    instead of dismissing.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248469 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-09  Tim Horton  <timothy_horton@apple.com>

            Tapping buttons in Data Detectors lookup previews doesn't work
            https://bugs.webkit.org/show_bug.cgi?id=200579
            <rdar://problem/54056519>

            Reviewed by Megan Gardner.

            * Platform/spi/ios/UIKitSPI.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _contextMenuInteraction:styleForMenuWithConfiguration:]):
            If a Data Detectors context menu wants the action menu style, provide it.

            (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]):
            If a Data Detectors context menu provides a view controller to present
            on context menu commit, present it. We present on top of the same view
            controller that is currently presenting the context menu, but modally
            instead of inside the context menu.

            If a Data Detectors context menu instead provides a URL to launch on
            context menu commit, call openURL.

            In both cases, change the commit style to pop, since we're committing
            instead of dismissing.

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248456. rdar://problem/54109877

    REGRESSION (52279987): Most of the WKUIDelegate contextMenu delegate methods are not being called
    https://bugs.webkit.org/show_bug.cgi?id=200557
    <rdar://problem/53717962>
    
    Reviewed by Wenson Hsieh.
    
    UIKit changed the name of delegates recently. We ignored the warning because
    it was still calling the old methods. However, it will only do so for applications
    authored by Apple, breaking 3rd parties.
    
    The change here is just adopting the new methods in place of the old ones.
    It does not change the API that WebKit vends (they still use the older names).
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView contextMenuInteraction:willDisplayMenuForConfiguration:animator:]):
    (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]):
    (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]):
    (-[WKContentView contextMenuInteractionWillPresent:]): Deleted.
    (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): Deleted.
    (-[WKContentView contextMenuInteractionDidEnd:]): Deleted.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248456 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-08  Dean Jackson  <dino@apple.com>

            REGRESSION (52279987): Most of the WKUIDelegate contextMenu delegate methods are not being called
            https://bugs.webkit.org/show_bug.cgi?id=200557
            <rdar://problem/53717962>

            Reviewed by Wenson Hsieh.

            UIKit changed the name of delegates recently. We ignored the warning because
            it was still calling the old methods. However, it will only do so for applications
            authored by Apple, breaking 3rd parties.

            The change here is just adopting the new methods in place of the old ones.
            It does not change the API that WebKit vends (they still use the older names).

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView contextMenuInteraction:willDisplayMenuForConfiguration:animator:]):
            (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]):
            (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]):
            (-[WKContentView contextMenuInteractionWillPresent:]): Deleted.
            (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): Deleted.
            (-[WKContentView contextMenuInteractionDidEnd:]): Deleted.

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248455. rdar://problem/54109872

    [iOS WK2] Hide previews when an inner overflow or frame scrollview scrolls
    https://bugs.webkit.org/show_bug.cgi?id=200552
    rdar://problem/54086338
    
    Reviewed by Wenson Hsieh.
    
    Give UITargetedPreview the UIScrollView that the target element is inside of,
    so it can clean up if the user starts to scroll that view.
    
    * Platform/spi/ios/UIKitSPI.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _createTargetedPreviewIfPossible]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248455 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-08  Simon Fraser  <simon.fraser@apple.com>

            [iOS WK2] Hide previews when an inner overflow or frame scrollview scrolls
            https://bugs.webkit.org/show_bug.cgi?id=200552
            rdar://problem/54086338

            Reviewed by Wenson Hsieh.

            Give UITargetedPreview the UIScrollView that the target element is inside of,
            so it can clean up if the user starts to scroll that view.

            * Platform/spi/ios/UIKitSPI.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _createTargetedPreviewIfPossible]):

2019-08-12  Alan Coon  <alancoon@apple.com>

        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 <sabouhallawa@apple.com> 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  <sabouhallawa@apple.com>

            [iOS] Position image information should respect the image orientation
            https://bugs.webkit.org/show_bug.cgi?id=200487

            Reviewed by Simon Fraser.

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

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248436. rdar://problem/54093228

    Set WKWebView opaque based on drawsBackground in PageConfiguration.
    https://bugs.webkit.org/show_bug.cgi?id=200528
    
    Reviewed by Tim Horton.
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _initializeWithConfiguration:]): Set self.opaque = NO when !self.opaque || !pageConfiguration->drawsBackground().
    It is almost impossible to have !self.opaque be NO at this point, since we are still inside initWithFrame:. A subclass could
    override opaque and return NO, but checking pageConfiguration's drawsBackground is a good alternative.
    * WebProcess/WebPage/WebPage.h: Remove unused m_drawsBackground member.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248436 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-08  Timothy Hatcher  <timothy@apple.com>

            Set WKWebView opaque based on drawsBackground in PageConfiguration.
            https://bugs.webkit.org/show_bug.cgi?id=200528

            Reviewed by Tim Horton.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _initializeWithConfiguration:]): Set self.opaque = NO when !self.opaque || !pageConfiguration->drawsBackground().
            It is almost impossible to have !self.opaque be NO at this point, since we are still inside initWithFrame:. A subclass could
            override opaque and return NO, but checking pageConfiguration's drawsBackground is a good alternative.
            * WebProcess/WebPage/WebPage.h: Remove unused m_drawsBackground member.

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248393. rdar://problem/54066682

    Regression(r247784) ResourceLoadStatisticsMemoryStore / ResourceLoadStatisticsPersistentStorage may get destroyed on the wrong thread
    https://bugs.webkit.org/show_bug.cgi?id=200517
    
    Reviewed by Geoffrey Garen.
    
    The issue is that WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore() is null checking
    m_persistentStorage and m_statisticsStore on the main thread, even though those members are initialized
    and destroyed on the background thread. As a result, if flushAndDestroyPersistentStore() is called *before*
    the background task to initialize those members has had a chance to run, then we'd return early without
    destroying those members. Later on, the background task would then initialize those data members and we
    would then destroy them on the main thread when the WebResourceLoadStatisticsStore is destroyed on the
    main thread.
    
    * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
    (WebKit::WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248393 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-07  Chris Dumez  <cdumez@apple.com>

            Regression(r247784) ResourceLoadStatisticsMemoryStore / ResourceLoadStatisticsPersistentStorage may get destroyed on the wrong thread
            https://bugs.webkit.org/show_bug.cgi?id=200517

            Reviewed by Geoffrey Garen.

            The issue is that WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore() is null checking
            m_persistentStorage and m_statisticsStore on the main thread, even though those members are initialized
            and destroyed on the background thread. As a result, if flushAndDestroyPersistentStore() is called *before*
            the background task to initialize those members has had a chance to run, then we'd return early without
            destroying those members. Later on, the background task would then initialize those data members and we
            would then destroy them on the main thread when the WebResourceLoadStatisticsStore is destroyed on the
            main thread.

            * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
            (WebKit::WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore):

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248380. rdar://problem/54018115

    Context menu on a universal link produces a blank preview
    https://bugs.webkit.org/show_bug.cgi?id=200485
    <rdar://problem/53699620>
    
    Reviewed by Dean Jackson.
    
    Source/WebCore/PAL:
    
    Define iTunesStoreURL from CoreServices.
    
    * pal/spi/cocoa/LaunchServicesSPI.h:
    
    Source/WebKit:
    
    If the context menu is activated on an iTunesStore URL, pass it
    on to DataDetectors, who should know how to handle it.
    
    Two drive-by fixes:
    - make it clear that early returns do not produce a value. Instead call the
      completion handler first, then return.
    - The new API DataDetectors case doesn't need to worry about hiding link previews
      as DataDetectors itself will handle that.
    
    * UIProcess/ios/WKContentViewInteraction.mm: If the URL is an iTunesStoreURL
    (as defined by CoreServices), let DataDetectors handle it.
    (-[WKContentView assignLegacyDataForContextMenuInteraction]):
    (-[WKContentView continueContextMenuInteraction:]):
    (-[WKContentView continueContextMenuInteractionWithDataDetectors:]): New method to
    use DataDetectors if possible.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248380 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-06  Dean Jackson  <dino@apple.com>

            Context menu on a universal link produces a blank preview
            https://bugs.webkit.org/show_bug.cgi?id=200485
            <rdar://problem/53699620>

            Reviewed by Tim Horton.

            If the context menu is activated on an iTunesStore URL, pass it
            on to DataDetectors, who should know how to handle it.

            Two drive-by fixes:
            - make it clear that early returns do not produce a value. Instead call the
              completion handler first, then return.
            - The new API DataDetectors case doesn't need to worry about hiding link previews
              as DataDetectors itself will handle that.

            * UIProcess/ios/WKContentViewInteraction.mm: If the URL is an iTunesStoreURL
            (as defined by CoreServices), let DataDetectors handle it.
            (-[WKContentView assignLegacyDataForContextMenuInteraction]):
            (-[WKContentView continueContextMenuInteraction:]):
            (-[WKContentView continueContextMenuInteractionWithDataDetectors:]): New method to
            use DataDetectors if possible.

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248129. rdar://problem/53836595

    REGRESSION: HSBC Personal Banking download/print dialog is usually positioned off screen on iPad
    https://bugs.webkit.org/show_bug.cgi?id=200356
    <rdar://problem/51885199>
    
    Reviewed by Beth Dakin.
    
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::desktopClassBrowsingRecommendedForRequest):
    Add HSBC domains to the list of sites that recommend mobile mode by default.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248129 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-01  Tim Horton  <timothy_horton@apple.com>

            REGRESSION: HSBC Personal Banking download/print dialog is usually positioned off screen on iPad
            https://bugs.webkit.org/show_bug.cgi?id=200356
            <rdar://problem/51885199>

            Reviewed by Beth Dakin.

            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::desktopClassBrowsingRecommendedForRequest):
            Add HSBC domains to the list of sites that recommend mobile mode by default.

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248104. rdar://problem/53836566

    UserMediaPermissionRequestManagerProxy should not use audio+video denied requests to deny audio-only or video-only requests
    https://bugs.webkit.org/show_bug.cgi?id=200317
    
    Reviewed by Eric Carlson.
    
    Source/WebKit:
    
    Only match audio+video denied requests with new audio+video requests.
    That will ensure that audio can still be captured if user denied access to the camera through preferences
    and website started with a getUserMedia({audio: true, video: true}) call.
    Covered by added API test.
    
    * UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
    (WebKit::UserMediaPermissionRequestManagerProxy::wasRequestDenied):
    
    Tools:
    
    * TestWebKitAPI/Tests/WebKit/getUserMediaAudioVideoCapture.html: Added
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/WebKit/GetUserMediaReprompt.mm:
    (-[GetUserMediaOnlyAudioUIDelegate _webView:requestMediaCaptureAuthorization:decisionHandler:]):
    (-[GetUserMediaOnlyAudioUIDelegate _webView:checkUserMediaPermissionForURL:mainFrameURL:frameIdentifier:decisionHandler:]):
    (TestWebKitAPI::TEST):
    
    LayoutTests:
    
    Update existing test with new behavior.
    Added new test for the case where video is blocked but not audio.
    
    * fast/mediastream/getUserMedia-deny-persistency3-expected.txt:
    * fast/mediastream/getUserMedia-deny-persistency3.html:
    * fast/mediastream/getUserMedia-deny-persistency4-expected.txt: Added.
    * fast/mediastream/getUserMedia-deny-persistency4.html: Added.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248104 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-08-01  Youenn Fablet  <youenn@apple.com>

            UserMediaPermissionRequestManagerProxy should not use audio+video denied requests to deny audio-only or video-only requests
            https://bugs.webkit.org/show_bug.cgi?id=200317

            Reviewed by Eric Carlson.

            Only match audio+video denied requests with new audio+video requests.
            That will ensure that audio can still be captured if user denied access to the camera through preferences
            and website started with a getUserMedia({audio: true, video: true}) call.
            Covered by added API test.

            * UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
            (WebKit::UserMediaPermissionRequestManagerProxy::wasRequestDenied):

2019-08-12  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247914. rdar://problem/53762618

    UI process occasionally hangs in -[UIKeyboardTaskQueue lockWhenReadyForMainThread]
    https://bugs.webkit.org/show_bug.cgi?id=200215
    <rdar://problem/52976965>
    
    Reviewed by Tim Horton.
    
    To implement autocorrection on iOS, UIKit sometimes needs to request contextual information from WebKit. This is
    handled as a sync IPC message in WebKit, since UIKit would otherwise proceed to block the main thread after
    sending the request, preventing WebKit from handling any IPC responses in the UI process (potentially resulting
    in deadlock if any other sync IPC messages were to arrive in the UI process during this time).
    
    The synchronous nature of this autocorrection request means that if any sync IPC message were to be
    simultaneously dispatched in the opposite direction (i.e. web to UI process), we need to immediately handle the
    incoming sync message in the UI process (otherwise, we'd end up deadlocking for 1 second until the
    autocorrection context request hits a 1-second IPC timeout).
    
    One such synchronous message from the web process to the UI process is WebPageProxy::CreateNewPage, triggered as
    a result of synchronously opening a new window. Due to Safari changes in iOS 13 (<rdar://problem/51755088>),
    this message now calls into code which then causes UIKit to call *back into* -[WKContentView
    requestAutocorrectionContextWithCompletionHandler:] for the newly opened web view, under the scope of the call
    to -requestAutocorrectionContextWithCompletionHandler: in the original web view.
    
    This caused a crash, which was tracked in <rdar://problem/52590170>. There was an attempt to fix this in r247345
    by invoking the existing handler well before storing the new one; while this avoided the crash, it didn't solve
    the root problem, which was that keyboard task queues would get into a bad state after this scenario; this would
    manifest in a UI process hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] during the next user
    gesture, which is tracked by this bug (<rdar://problem/52976965>).
    
    As it turns out, the keyboard task queue gets into a bad state because it is architected in such a way that
    tasks added to the queue under the scope of parent task must be finished executing before their parents;
    otherwise, the call to -[UIKeyboardTaskExecutionContext returnExecutionToParentWithInfo:] never happens when
    handling the child task. This has the effect of causing the keyboard task queue to end up with a
    UIKeyboardTaskExecutionContext that can never return execution to its parent context, such that if the task
    queue is then told to wait until any future task is finished executing, it will hang forever, waiting for these
    stuck tasks to finish executing (which never happens, because they're all waiting to return execution to their
    parents which are already done executing!)
    
    To fix this hang and avoid ever getting into this bad state, we need to invoke the autocorrection request
    handlers in this order:
    
    (1) Receive outer autocorrection context request.
    (2) Receive inner autocorrection context request.
    (3) Invoke inner autocorrection context request completion handler.
    (4) Invoke outer autocorrection context request completion handler.
    
    ...instead of swapping (3) and (4), like we do currently.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView resignFirstResponderForWebView]):
    
    Remove the hack added in r247345 to try and avoid reentrant autocorrection context requests; we don't need this
    anymore, since we should now be able to handle these reentrant requests in the way UIKit expects.
    
    (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]):
    
    Add an early return in the case where the request is synchronous and there's already a pending autocorrection
    context to ensure that the completion handler for the nested request is invoked before the outer request is
    finished.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247914 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-29  Wenson Hsieh  <wenson_hsieh@apple.com>

            UI process occasionally hangs in -[UIKeyboardTaskQueue lockWhenReadyForMainThread]
            https://bugs.webkit.org/show_bug.cgi?id=200215
            <rdar://problem/52976965>

            Reviewed by Tim Horton.

            To implement autocorrection on iOS, UIKit sometimes needs to request contextual information from WebKit. This is
            handled as a sync IPC message in WebKit, since UIKit would otherwise proceed to block the main thread after
            sending the request, preventing WebKit from handling any IPC responses in the UI process (potentially resulting
            in deadlock if any other sync IPC messages were to arrive in the UI process during this time).

            The synchronous nature of this autocorrection request means that if any sync IPC message were to be
            simultaneously dispatched in the opposite direction (i.e. web to UI process), we need to immediately handle the
            incoming sync message in the UI process (otherwise, we'd end up deadlocking for 1 second until the
            autocorrection context request hits a 1-second IPC timeout).

            One such synchronous message from the web process to the UI process is WebPageProxy::CreateNewPage, triggered as
            a result of synchronously opening a new window. Due to Safari changes in iOS 13 (<rdar://problem/51755088>),
            this message now calls into code which then causes UIKit to call *back into* -[WKContentView
            requestAutocorrectionContextWithCompletionHandler:] for the newly opened web view, under the scope of the call
            to -requestAutocorrectionContextWithCompletionHandler: in the original web view.

            This caused a crash, which was tracked in <rdar://problem/52590170>. There was an attempt to fix this in r247345
            by invoking the existing handler well before storing the new one; while this avoided the crash, it didn't solve
            the root problem, which was that keyboard task queues would get into a bad state after this scenario; this would
            manifest in a UI process hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] during the next user
            gesture, which is tracked by this bug (<rdar://problem/52976965>).

            As it turns out, the keyboard task queue gets into a bad state because it is architected in such a way that
            tasks added to the queue under the scope of parent task must be finished executing before their parents;
            otherwise, the call to -[UIKeyboardTaskExecutionContext returnExecutionToParentWithInfo:] never happens when
            handling the child task. This has the effect of causing the keyboard task queue to end up with a
            UIKeyboardTaskExecutionContext that can never return execution to its parent context, such that if the task
            queue is then told to wait until any future task is finished executing, it will hang forever, waiting for these
            stuck tasks to finish executing (which never happens, because they're all waiting to return execution to their
            parents which are already done executing!)

            To fix this hang and avoid ever getting into this bad state, we need to invoke the autocorrection request
            handlers in this order:

            (1) Receive outer autocorrection context request.
            (2) Receive inner autocorrection context request.
            (3) Invoke inner autocorrection context request completion handler.
            (4) Invoke outer autocorrection context request completion handler.

            ...instead of swapping (3) and (4), like we do currently.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView resignFirstResponderForWebView]):

            Remove the hack added in r247345 to try and avoid reentrant autocorrection context requests; we don't need this
            anymore, since we should now be able to handle these reentrant requests in the way UIKit expects.

            (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]):

            Add an early return in the case where the request is synchronous and there's already a pending autocorrection
            context to ensure that the completion handler for the nested request is invoked before the outer request is
            finished.

2019-08-12  Alan Coon  <alancoon@apple.com>

        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  <alancoon@apple.com>

            Apply patch. rdar://problem/53992160

        2019-08-06  Per Arne Vollan  <pvollan@apple.com>

                [Win] Fix AppleWin build
                https://bugs.webkit.org/show_bug.cgi?id=200414

                Reviewed by Brent Fulgham.

                * CMakeLists.txt:

2019-08-01  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248085. rdar://problem/53825741

    WKImagePreviewViewController not being autoreleased
    https://bugs.webkit.org/show_bug.cgi?id=200325
    <rdar://problem/53788214>
    
    Reviewed by Wenson Hsieh.
    
    Wenson noticed I wasn't autoreleasing the WKImagePreviewViewController.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView continueContextMenuInteraction:]):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248085 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-31  Dean Jackson  <dino@apple.com>

            WKImagePreviewViewController not being autoreleased
            https://bugs.webkit.org/show_bug.cgi?id=200325
            <rdar://problem/53788214>

            Reviewed by Wenson Hsieh.

            Wenson noticed I wasn't autoreleasing the WKImagePreviewViewController.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView continueContextMenuInteraction:]):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248039. rdar://problem/53788996

    [iOS 13] Safari crashes when closing a tab with a focused element if the unified field has focus
    https://bugs.webkit.org/show_bug.cgi?id=200291
    <rdar://problem/53717946>
    
    Reviewed by Megan Gardner.
    
    Source/WebKit:
    
    Makes -requestAutocorrectionContextWithCompletionHandler: robust in the case where the web page has been closed,
    and there is no Connection object to use when waiting for a sync IPC response.
    
    Test: AutocorrectionTests.RequestAutocorrectionContextAfterClosingPage
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]):
    
    Tools:
    
    Add an API test to exercise the scenario of synchronously requesting the autocorrection context immediately
    after closing the web view, while the web view's content view isn't the first responder.
    
    * TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:
    * TestWebKitAPI/ios/UIKitSPI.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248039 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-31  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iOS 13] Safari crashes when closing a tab with a focused element if the unified field has focus
            https://bugs.webkit.org/show_bug.cgi?id=200291
            <rdar://problem/53717946>

            Reviewed by Megan Gardner.

            Makes -requestAutocorrectionContextWithCompletionHandler: robust in the case where the web page has been closed,
            and there is no Connection object to use when waiting for a sync IPC response.

            Test: AutocorrectionTests.RequestAutocorrectionContextAfterClosingPage

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247700. rdar://problem/53456055

    WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari
    https://bugs.webkit.org/show_bug.cgi?id=200011
    <rdar://problem/53409457>
    
    Reviewed by Tim Horton.
    
    Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:)
    on the WKUIDelegate so that clients that got caught implementing the
    SPI before moving to the real API can still clean-up state. In other words,
    don't force a client that only implements that method to move completely
    to the new API.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (needsDeprecatedPreviewAPI):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247700 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-22  Dean Jackson  <dino@apple.com>

            WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari
            https://bugs.webkit.org/show_bug.cgi?id=200011
            <rdar://problem/53409457>

            Reviewed by Tim Horton.

            Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:)
            on the WKUIDelegate so that clients that got caught implementing the
            SPI before moving to the real API can still clean-up state. In other words,
            don't force a client that only implements that method to move completely
            to the new API.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (needsDeprecatedPreviewAPI):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248038. rdar://problem/53764075

    AX: com.apple.WebKit.WebContent at com.apple.WebKit: -[WKAccessibilityWebPageObject accessibilityParameterizedAttributeNames]
    https://bugs.webkit.org/show_bug.cgi?id=200277
    <rdar://problem/49475009>
    
    Reviewed by Per Arne Vollan.
    
    Verify Page is available before calling into it.
    
    * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:
    (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248038 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-31  Chris Fleizach  <cfleizach@apple.com>

            AX: com.apple.WebKit.WebContent at com.apple.WebKit: -[WKAccessibilityWebPageObject accessibilityParameterizedAttributeNames]
            https://bugs.webkit.org/show_bug.cgi?id=200277
            <rdar://problem/49475009>

            Reviewed by Per Arne Vollan.

            Verify Page is available before calling into it.

            * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:
            (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r248015. rdar://problem/53764191

    Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
    https://bugs.webkit.org/show_bug.cgi?id=200263
    rdar://problem/53679408
    
    Reviewed by Antti Koivisto.
    
    Source/WebKit:
    
    The content on this page had a scale(0) div overlaying an overflow:scroll element,
    and our UI-side hit-testing code would find this scale(0) element, because apparently
    -[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and
    -[UIView pointInside:withEvent:] just compares the point with the view bounds.
    
    Since the view frame takes the transform into account, we can look for an empty frame
    to detect these non-invertible transforms.
    
    * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
    (WebKit::collectDescendantViewsAtPoint):
    
    LayoutTests:
    
    * fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt: Added.
    * fast/scrolling/ios/non-invertible-transformed-over-scroller.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248015 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-31  Alan Coon  <alancoon@apple.com>

            Cherry-pick r247936. rdar://problem/53764217

        YouTube search field shows RTL text outside its border on iPadOS
        https://bugs.webkit.org/show_bug.cgi?id=200253
        <rdar://problem/53680603>

        Reviewed by Beth Dakin.

        Source/WebKit:

        Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This
        behavior was only intended for Mail, and isn't generally compatible with web content.

        While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that
        other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code.
        This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView setBaseWritingDirection:forRange:]):

        LayoutTests:

        * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page-expected.txt: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus-expected.txt.
        * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page.html: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus.html.

        Rename an existing test, rtl-keyboard-input-on-focus.html, to rtl-keyboard-input-on-focus-in-editable-page.html
        to emphasize the fact that it requires an editable web view.

        * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page-expected.txt: Added.
        * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page.html: Added.

        Add a new layout test to ensure that we don't automatically apply an RTL attribute when focusing fields in a
        non-editable web view.


        git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247936 268f45cc-cd09-0410-ab3c-d52691b4dbfc

        2019-07-29  Wenson Hsieh  <wenson_hsieh@apple.com>

                YouTube search field shows RTL text outside its border on iPadOS
                https://bugs.webkit.org/show_bug.cgi?id=200253
                <rdar://problem/53680603>

                Reviewed by Beth Dakin.

                Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This
                behavior was only intended for Mail, and isn't generally compatible with web content.

                While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that
                other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code.
                This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check.

                * UIProcess/ios/WKContentViewInteraction.mm:
                (-[WKContentView setBaseWritingDirection:forRange:]):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247933. rdar://problem/53764069

    Try fixing crash at com.apple.WebKit.Networking: NetworkProcess::setSharedHTTPCookieStorage
    https://bugs.webkit.org/show_bug.cgi?id=200189
    <rdar://problem/41325767>
    
    Reviewed by Chris Dumez.
    
    The crash indicates that sharedCookieStorage is accessed before being set in network process.
    sharedCookieStorage is set during the processing of InitializeNetworkProcess message, and access to
    sharedCookieStorage is supposed to happen after that. Therefore, it is likely some message is received and
    handled before InitializeNetworkProcess.
    
    One possible explanation is WebKit APIs get called on different threads. Because of the race in checking and
    setting m_networkProcess, some message is sent between network process gets launched (m_networkProcess is set)
    and InitializeNetworkProcess message is sent. To mitigate this issue, we make sure m_networkProcess is set only
    in the main runloop and only after InitializeNetworkProcess is sent.
    
    * UIProcess/WebProcessPool.cpp:
    (WebKit::WebProcessPool::ensureNetworkProcess):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247933 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-29  Sihui Liu  <sihui_liu@apple.com>

            Try fixing crash at com.apple.WebKit.Networking: NetworkProcess::setSharedHTTPCookieStorage
            https://bugs.webkit.org/show_bug.cgi?id=200189
            <rdar://problem/41325767>

            Reviewed by Chris Dumez.

            The crash indicates that sharedCookieStorage is accessed before being set in network process.
            sharedCookieStorage is set during the processing of InitializeNetworkProcess message, and access to
            sharedCookieStorage is supposed to happen after that. Therefore, it is likely some message is received and
            handled before InitializeNetworkProcess.

            One possible explanation is WebKit APIs get called on different threads. Because of the race in checking and
            setting m_networkProcess, some message is sent between network process gets launched (m_networkProcess is set)
            and InitializeNetworkProcess message is sent. To mitigate this issue, we make sure m_networkProcess is set only
            in the main runloop and only after InitializeNetworkProcess is sent.

            * UIProcess/WebProcessPool.cpp:
            (WebKit::WebProcessPool::ensureNetworkProcess):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247923. rdar://problem/53764209

    REGRESSION: WebSockets no longer work in Service Workers
    https://bugs.webkit.org/show_bug.cgi?id=199906
    <rdar://problem/53516732>
    
    Reviewed by Geoffrey Garen.
    
    Source/WebKit:
    
    Use WebSocketProvider so that network calls are done in the network process.
    
    * WebProcess/Storage/WebSWContextManagerConnection.cpp:
    (WebKit::WebSWContextManagerConnection::installServiceWorker):
    
    LayoutTests:
    
2019-08-08  Simon Fraser  <simon.fraser@apple.com>

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

    Fix test and make sure messages are exchanged for the test to succeed.
    
    * http/tests/workers/service/resources/serviceworker-websocket-worker.js:
    (async.doTest):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247923 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-29  Youenn Fablet  <youenn@apple.com>

            REGRESSION: WebSockets no longer work in Service Workers
            https://bugs.webkit.org/show_bug.cgi?id=199906
            <rdar://problem/53516732>

            Reviewed by Geoffrey Garen.

            Use WebSocketProvider so that network calls are done in the network process.

            * WebProcess/Storage/WebSWContextManagerConnection.cpp:
            (WebKit::WebSWContextManagerConnection::installServiceWorker):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247920. rdar://problem/53764045

    Contextual menu does not present when holding an embedded photo but works with link and attachments
    https://bugs.webkit.org/show_bug.cgi?id=200239
    <rdar://problem/53318733>
    
    Reviewed by Tim Horton.
    
    If the user long-pressed on an image, and the client implemented the new API but did
    not provide a configuration, we were not falling back to the default behaviour of
    giving a menu allowing the user to copy/share/save the image.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView continueContextMenuInteraction:]): If we get through the delegates,
    and the element is an image, return the default configuration.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247920 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-29  Dean Jackson  <dino@apple.com>

            Contextual menu does not present when holding an embedded photo but works with link and attachments
            https://bugs.webkit.org/show_bug.cgi?id=200239
            <rdar://problem/53318733>

            Reviewed by Tim Horton.

            If the user long-pressed on an image, and the client implemented the new API but did
            not provide a configuration, we were not falling back to the default behaviour of
            giving a menu allowing the user to copy/share/save the image.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView continueContextMenuInteraction:]): If we get through the delegates,
            and the element is an image, return the default configuration.

2019-07-31  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247905. rdar://problem/53764224

    Possible use-after-move under NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated()
    https://bugs.webkit.org/show_bug.cgi?id=200225
    
    Reviewed by Brent Fulgham.
    
    The code was WTFMove()-ing the method parameter inside of a loop, which means that it could
    move it several times. Instead of copying the parameters, I opted into sending the statistics
    only to the network session that matches this WebProcess connection.
    
    * NetworkProcess/NetworkConnectionToWebProcess.cpp:
    (WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247905 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-29  Chris Dumez  <cdumez@apple.com>

            Possible use-after-move under NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated()
            https://bugs.webkit.org/show_bug.cgi?id=200225

            Reviewed by Brent Fulgham.

            The code was WTFMove()-ing the method parameter inside of a loop, which means that it could
            move it several times. Instead of copying the parameters, I opted into sending the statistics
            only to the network session that matches this WebProcess connection.

            * NetworkProcess/NetworkConnectionToWebProcess.cpp:
            (WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated):

2019-07-31  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/53764240

    2019-07-31  Ryosuke Niwa  <rniwa@webkit.org>

            Add a missing null check to ShareableBitmap::makeCGImageCopy()
            https://bugs.webkit.org/show_bug.cgi?id=200184

            Reviewed by Wenson Hsieh.

            Added a null check to makeCGImageCopy to when either GraphicsContext or its platform context is null.
            Added the same platform context null check to convertImageToBitmap and convertCGImageToBitmap
            since the crash intendeed to be fixed in r247134 is still happening.

            * Shared/cg/ShareableBitmapCG.cpp:
            (WebKit::ShareableBitmap::makeCGImageCopy):
            * WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:
            (WebKit::convertImageToBitmap):
            (WebKit::convertCGImageToBitmap):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247823. rdar://problem/53449739

    Unreviewed, fix -Wredundant-move warning spam after r247672
    https://bugs.webkit.org/show_bug.cgi?id=199967
    <rdar://problem/53351435>
    
    * Platform/IPC/ArgumentCoders.cpp:
    (IPC::decodeStringText):
    * Platform/IPC/ArgumentCoders.h:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247823 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-25  Michael Catanzaro  <mcatanzaro@igalia.com>

            Unreviewed, fix -Wredundant-move warning spam after r247672
            https://bugs.webkit.org/show_bug.cgi?id=199967
            <rdar://problem/53351435>

            * Platform/IPC/ArgumentCoders.cpp:
            (IPC::decodeStringText):
            * Platform/IPC/ArgumentCoders.h:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247673. rdar://problem/53449723

    Speed up HashTable decoding by reserving capacity and avoiding rehashing
    https://bugs.webkit.org/show_bug.cgi?id=199982
    
    Reviewed by Saam Barati.
    
    Source/WebKit:
    
    Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for
    performance. I measured a ~35% improvement when decoding a very large
    HashMap of Strings (~160k entries) in the context of the
    StorageManager::GetValues IPC.
    
    * Platform/IPC/ArgumentCoders.h:
    * Shared/API/c/WKDictionary.cpp:
    (WKDictionaryCreate):
    
    Source/WTF:
    
    Introduce reserveInitialCapacity() on HashMap to reserve capacity on a
    HashMap and cut down on rehashing cost when possible.
    
    * wtf/HashMap.h:
    * wtf/HashTable.h:
    (WTF::HashTable::reserveInitialCapacity):
    
    * wtf/persistence/PersistentCoders.h:
    Use HashMap::reserveInitialCapacity() in the HashMap persistent decoder for
    performance.
    
    Tools:
    
    Add API test coverage.
    
    * TestWebKitAPI/Tests/WTF/HashMap.cpp:
    (TestWebKitAPI::TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247673 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-20  Chris Dumez  <cdumez@apple.com>

            Speed up HashTable decoding by reserving capacity and avoiding rehashing
            https://bugs.webkit.org/show_bug.cgi?id=199982

            Reviewed by Saam Barati.

            Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for
            performance. I measured a ~35% improvement when decoding a very large
            HashMap of Strings (~160k entries) in the context of the
            StorageManager::GetValues IPC.

            * Platform/IPC/ArgumentCoders.h:
            * Shared/API/c/WKDictionary.cpp:
            (WKDictionaryCreate):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247672. rdar://problem/53449739
2019-07-29  Simon Fraser  <simon.fraser@apple.com>

        Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
        https://bugs.webkit.org/show_bug.cgi?id=200263
        rdar://problem/53679408

        Reviewed by Antti Koivisto.

        The content on this page had a scale(0) div overlaying an overflow:scroll element,
        and our UI-side hit-testing code would find this scale(0) element, because apparently
        -[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and 
        -[UIView pointInside:withEvent:] just compares the point with the view bounds.

        Since the view frame takes the transform into account, we can look for an empty frame
        to detect these non-invertible transforms.

        * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
        (WebKit::collectDescendantViewsAtPoint):


    Micro-optimize HashMap & String IPC decoding
    https://bugs.webkit.org/show_bug.cgi?id=199967
    
    Reviewed by Geoffrey Garen.
    
    The legacy HashMap decoder (returning a boolean) was failing to WTFMove()
    the key & value when calling HashMap::add(). The modern decoder (returning
    an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder
    to call the modern one to reduce code duplication and to get this optimization.
    
    Also, encode HashMap::size() as a uint32_t instead of a uint64_t since
    HashMap::size() returns an 'unsigned int' type. Finally, update the modern
    decoder to WTFMove(hashMap) when returning. Because the function returns an
    Optional<HashMap> and not a HashMap, I do not believe we get return value
    optimization (RVO).
    
    Do similar changes to String IPC coders.
    
    * Platform/IPC/ArgumentCoders.cpp:
    (IPC::decodeStringText):
    (IPC::ArgumentCoder<String>::decode):
    * Platform/IPC/ArgumentCoders.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247672 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-20  Chris Dumez  <cdumez@apple.com>

            Micro-optimize HashMap & String IPC decoding
            https://bugs.webkit.org/show_bug.cgi?id=199967

            Reviewed by Geoffrey Garen.

            The legacy HashMap decoder (returning a boolean) was failing to WTFMove()
            the key & value when calling HashMap::add(). The modern decoder (returning
            an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder
            to call the modern one to reduce code duplication and to get this optimization.

            Also, encode HashMap::size() as a uint32_t instead of a uint64_t since
            HashMap::size() returns an 'unsigned int' type. Finally, update the modern
            decoder to WTFMove(hashMap) when returning. Because the function returns an
            Optional<HashMap> and not a HashMap, I do not believe we get return value
            optimization (RVO).

            Do similar changes to String IPC coders.

            * Platform/IPC/ArgumentCoders.cpp:
            (IPC::decodeStringText):
            (IPC::ArgumentCoder<String>::decode):
            * Platform/IPC/ArgumentCoders.h:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247890. rdar://problem/53647283

    Allow more syscalls in the WebContent process' sandbox profile
    https://bugs.webkit.org/show_bug.cgi?id=200182
    <rdar://problem/53594973>
    
    Reviewed by Geoffrey Garen.
    
    I reviewed all crash traces attached to the radar and found the following
    syscalls that we not yet allowed by the WebContent process's sandbox
    profile.
    
    * WebProcess/com.apple.WebProcess.sb.in:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247890 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-27  Chris Dumez  <cdumez@apple.com>

            Allow more syscalls in the WebContent process' sandbox profile
            https://bugs.webkit.org/show_bug.cgi?id=200182
            <rdar://problem/53594973>

            Reviewed by Geoffrey Garen.

            I reviewed all crash traces attached to the radar and found the following
            syscalls that we not yet allowed by the WebContent process's sandbox
            profile.

            * WebProcess/com.apple.WebProcess.sb.in:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247885. rdar://problem/53648025

    NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
    https://bugs.webkit.org/show_bug.cgi?id=200150
    <rdar://problem/53280170>
    
    Reviewed by Brent Fulgham.
    
    Source/WebKit:
    
    NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
    as the page might have already changed the location.
    
    * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h:
    * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm:
    (WebKit::NavigationSOAuthorizationSession::shouldStartInternal):
    (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow):
    (WebKit::NavigationSOAuthorizationSession::pageActiveURLDidChangeDuringWaiting const):
    * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm:
    (WebKit::SubFrameSOAuthorizationSession::abortInternal):
    
    Tools:
    
    * TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm:
    (TestWebKitAPI::TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247885 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-26  Jiewen Tan  <jiewen_tan@apple.com>

            NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
            https://bugs.webkit.org/show_bug.cgi?id=200150
            <rdar://problem/53280170>

            Reviewed by Brent Fulgham.

            NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
            as the page might have already changed the location.

            * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h:
            * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm:
            (WebKit::NavigationSOAuthorizationSession::shouldStartInternal):
            (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow):
            (WebKit::NavigationSOAuthorizationSession::pageActiveURLDidChangeDuringWaiting const):
            * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm:
            (WebKit::SubFrameSOAuthorizationSession::abortInternal):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247876. rdar://problem/53647283

    Crashes under XPCServiceMain() / mach_msg_trap() due to sandboxing
    https://bugs.webkit.org/show_bug.cgi?id=200173
    <rdar://problem/53594973>
    
    Reviewed by Per Arne Vollan.
    
    Allow a few more syscalls as they appear to be needed by mach_msg_trap().
    
    * WebProcess/com.apple.WebProcess.sb.in:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247876 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-26  Chris Dumez  <cdumez@apple.com>

            Crashes under XPCServiceMain() / mach_msg_trap() due to sandboxing
            https://bugs.webkit.org/show_bug.cgi?id=200173
            <rdar://problem/53594973>

            Reviewed by Per Arne Vollan.

            Allow a few more syscalls as they appear to be needed by mach_msg_trap().

            * WebProcess/com.apple.WebProcess.sb.in:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247875. rdar://problem/53648065

    [iOS] REGRESSION: Keyboard dismisses and reappears when typing 2FA pin on appleid.apple.com
    https://bugs.webkit.org/show_bug.cgi?id=200171
    <rdar://problem/50245251>
    
    Reviewed by Wenson Hsieh.
    
    Take out an InputViewUpdateDeferrer token (if we don't already have one) to temporarily defer
    tearing down the input view (keyboard) before bluring the previously focused element as part
    of switching between focused elements. This avoid a noticeable flash caused by UIKit animating
    out and animating in the keyboard should the newly focused element require the keyboard. We
    only take out the InputViewUpdateDeferrer until we fall off the end of _elementDidFocus: (or
    bail early). Once we fall of the end UIKit will update input view UI.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247875 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-26  Daniel Bates  <dabates@apple.com>

            [iOS] REGRESSION: Keyboard dismisses and reappears when typing 2FA pin on appleid.apple.com
            https://bugs.webkit.org/show_bug.cgi?id=200171
            <rdar://problem/50245251>

            Reviewed by Wenson Hsieh.

            Take out an InputViewUpdateDeferrer token (if we don't already have one) to temporarily defer
            tearing down the input view (keyboard) before bluring the previously focused element as part
            of switching between focused elements. This avoid a noticeable flash caused by UIKit animating
            out and animating in the keyboard should the newly focused element require the keyboard. We
            only take out the InputViewUpdateDeferrer until we fall off the end of _elementDidFocus: (or
            bail early). Once we fall of the end UIKit will update input view UI.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247872. rdar://problem/53647297

    Avoid WebContent process SIGKILL when using kevent()
    https://bugs.webkit.org/show_bug.cgi?id=200170
    <rdar://problem/51559921>
    
    Reviewed by Per Arne Vollan.
    
    Avoid WebContent process SIGKILL when using kevent() by updated its sandboxing profile.
    
    * WebProcess/com.apple.WebProcess.sb.in:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247872 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-26  Chris Dumez  <cdumez@apple.com>

            Avoid WebContent process SIGKILL when using kevent()
            https://bugs.webkit.org/show_bug.cgi?id=200170
            <rdar://problem/51559921>

            Reviewed by Per Arne Vollan.

            Avoid WebContent process SIGKILL when using kevent() by updated its sandboxing profile.

            * WebProcess/com.apple.WebProcess.sb.in:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247868. rdar://problem/53648207

    [iOS] WebPage::TouchEventSync() & WebPage::GetPositionInformation() sync IPC causes UIProcess hangs
    https://bugs.webkit.org/show_bug.cgi?id=200138
    <rdar://problem/52698157>
    
    Reviewed by Geoffrey Garen.
    
    Source/WebKit:
    
    Revert most of r247822 and use an alternative approach to address hangs. In this patch, the proposal
    is to add a SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply flag on the
    WebPage::TouchEventSync() & WebPage::GetPositionInformation() sendSync() calls in the UIProcess.
    Those will cause this IPCs to get dispatched right away in the WebContent process, even if the
    WebContent process is itself currently stuck on unbounded (i.e. potentially slow) synchronous IPC
    (JS alerts / prompts & sync XHR). Because re-entering WebCore on sync IPC is generally unsafe, this
    patch also updates the WebPage::getPositionInformation() & WebPage::touchEventSync() to return early
    (i.e. cancelled) if they get called while the WebContent process is stuck on a slow sendSync.
    
    This approach should address the UIProcess hangs caused by the WebPage::TouchEventSync() and
    WebPage::GetPositionInformation() sync IPC messages when the WebContent process is busy on a slow XHR
    or a JS prompt / alert. It should be safe because we do not re-enter WebCore. The only drawback is that
    those IPCs will be cancelled (early return with default value) when the WebContent process is busy.
    However, I am being told that this is likely acceptable in practice.
    
    * Platform/IPC/Connection.cpp:
    (IPC::Connection::SyncMessageState::processIncomingMessage):
    (IPC::Connection::sendMessage):
    (IPC::Connection::sendSyncMessage):
    (IPC::Connection::dispatchMessage):
    * Platform/IPC/Connection.h:
    (IPC::UnboundedSynchronousIPCScope::UnboundedSynchronousIPCScope):
    (IPC::UnboundedSynchronousIPCScope::~UnboundedSynchronousIPCScope):
    (IPC::UnboundedSynchronousIPCScope::hasOngoingUnboundedSyncIPC):
    * Platform/IPC/Decoder.cpp:
    (IPC::Decoder::shouldDispatchMessageWhenWaitingForSyncReply const):
    * Platform/IPC/Decoder.h:
    * Platform/IPC/Encoder.cpp:
    (IPC::Encoder::shouldDispatchMessageWhenWaitingForSyncReply const):
    (IPC::Encoder::setShouldDispatchMessageWhenWaitingForSyncReply):
    (IPC::Encoder::wrapForTesting):
    * Platform/IPC/Encoder.h:
    * Platform/IPC/MessageFlags.h:
    * UIProcess/Network/NetworkProcessProxy.cpp:
    (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::handleTouchEventSynchronously):
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView ensurePositionInformationIsUpToDate:]):
    * WebProcess/Network/WebLoaderStrategy.cpp:
    (WebKit::WebLoaderStrategy::loadResourceSynchronously):
    * WebProcess/WebCoreSupport/WebChromeClient.cpp:
    (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    (WebKit::WebChromeClient::runJavaScriptAlert):
    (WebKit::WebChromeClient::runJavaScriptConfirm):
    (WebKit::WebChromeClient::runJavaScriptPrompt):
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::layerVolatilityTimerFired):
    (WebKit::WebPage::markLayersVolatile):
    (WebKit::WebPage::cancelMarkLayersVolatile):
    (WebKit::WebPage::touchEventSync):
    (WebKit::WebPage::didCompletePageTransition):
    (WebKit::WebPage::updatePreferences):
    (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    * WebProcess/WebPage/WebPage.h:
    (WebKit::WebPage::sendSyncWithDelayedReply):
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::getPositionInformation):
    
    LayoutTests:
    
    Update existing layout test accordingly.
    
    * fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply-expected.txt: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt.
    * fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply.html: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247868 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-26  Chris Dumez  <cdumez@apple.com>

            [iOS] WebPage::TouchEventSync() & WebPage::GetPositionInformation() sync IPC causes UIProcess hangs
            https://bugs.webkit.org/show_bug.cgi?id=200138
            <rdar://problem/52698157>

            Reviewed by Geoffrey Garen.

            Revert most of r247822 and use an alternative approach to address hangs. In this patch, the proposal
            is to add a SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply flag on the
            WebPage::TouchEventSync() & WebPage::GetPositionInformation() sendSync() calls in the UIProcess.
            Those will cause this IPCs to get dispatched right away in the WebContent process, even if the
            WebContent process is itself currently stuck on unbounded (i.e. potentially slow) synchronous IPC
            (JS alerts / prompts & sync XHR). Because re-entering WebCore on sync IPC is generally unsafe, this
            patch also updates the WebPage::getPositionInformation() & WebPage::touchEventSync() to return early
            (i.e. cancelled) if they get called while the WebContent process is stuck on a slow sendSync.

            This approach should address the UIProcess hangs caused by the WebPage::TouchEventSync() and
            WebPage::GetPositionInformation() sync IPC messages when the WebContent process is busy on a slow XHR
            or a JS prompt / alert. It should be safe because we do not re-enter WebCore. The only drawback is that
            those IPCs will be cancelled (early return with default value) when the WebContent process is busy.
            However, I am being told that this is likely acceptable in practice.

            * Platform/IPC/Connection.cpp:
            (IPC::Connection::SyncMessageState::processIncomingMessage):
            (IPC::Connection::sendMessage):
            (IPC::Connection::sendSyncMessage):
            (IPC::Connection::dispatchMessage):
            * Platform/IPC/Connection.h:
            (IPC::UnboundedSynchronousIPCScope::UnboundedSynchronousIPCScope):
            (IPC::UnboundedSynchronousIPCScope::~UnboundedSynchronousIPCScope):
            (IPC::UnboundedSynchronousIPCScope::hasOngoingUnboundedSyncIPC):
            * Platform/IPC/Decoder.cpp:
            (IPC::Decoder::shouldDispatchMessageWhenWaitingForSyncReply const):
            * Platform/IPC/Decoder.h:
            * Platform/IPC/Encoder.cpp:
            (IPC::Encoder::shouldDispatchMessageWhenWaitingForSyncReply const):
            (IPC::Encoder::setShouldDispatchMessageWhenWaitingForSyncReply):
            (IPC::Encoder::wrapForTesting):
            * Platform/IPC/Encoder.h:
            * Platform/IPC/MessageFlags.h:
            * UIProcess/Network/NetworkProcessProxy.cpp:
            (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::handleTouchEventSynchronously):
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView ensurePositionInformationIsUpToDate:]):
            * WebProcess/Network/WebLoaderStrategy.cpp:
            (WebKit::WebLoaderStrategy::loadResourceSynchronously):
            * WebProcess/WebCoreSupport/WebChromeClient.cpp:
            (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
            (WebKit::WebChromeClient::runJavaScriptAlert):
            (WebKit::WebChromeClient::runJavaScriptConfirm):
            (WebKit::WebChromeClient::runJavaScriptPrompt):
            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::layerVolatilityTimerFired):
            (WebKit::WebPage::markLayersVolatile):
            (WebKit::WebPage::cancelMarkLayersVolatile):
            (WebKit::WebPage::touchEventSync):
            (WebKit::WebPage::didCompletePageTransition):
            (WebKit::WebPage::updatePreferences):
            (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
            * WebProcess/WebPage/WebPage.h:
            (WebKit::WebPage::sendSyncWithDelayedReply):
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::getPositionInformation):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247864. rdar://problem/53647289

    AX: web process should load correct bundle path for MACCATALYST
    https://bugs.webkit.org/show_bug.cgi?id=200122
    
    Patch by Eric Liang <ericliang@apple.com> on 2019-07-26
    Reviewed by Brent Fulgham.
    
    Added the path to accessibility bundle for Mac Catalyst.
    Added sandbox profile to read accessibility settings.
    
    * WebProcess/cocoa/WebProcessCocoa.mm:
    (WebKit::registerWithAccessibility):
    * WebProcess/com.apple.WebProcess.sb.in:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247864 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-26  Eric Liang  <ericliang@apple.com>

            AX: web process should load correct bundle path for MACCATALYST
            https://bugs.webkit.org/show_bug.cgi?id=200122

            Reviewed by Brent Fulgham.

            Added the path to accessibility bundle for Mac Catalyst.
            Added sandbox profile to read accessibility settings.

            * WebProcess/cocoa/WebProcessCocoa.mm:
            (WebKit::registerWithAccessibility):
            * WebProcess/com.apple.WebProcess.sb.in:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247853. rdar://problem/53648225

    Unreviewed, build fix after r247851
    
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::decidePolicyForNavigationAction):
    Reverts an unnecessary change.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247853 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-25  Jiewen Tan  <jiewen_tan@apple.com>

            Unreviewed, build fix after r247851

            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::decidePolicyForNavigationAction):
            Reverts an unnecessary change.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247851. rdar://problem/53648225

    WebPageProxy::receivedPolicyDecision should check navigation ID before clear pendingAPIRequest
    https://bugs.webkit.org/show_bug.cgi?id=200108
    <rdar://problem/53521238>
    
    Reviewed by Chris Dumez.
    
    Source/WebKit:
    
    Assuming there are two loads happening one after another. There is an issue when clients save
    the first decisionHandler and then call WKNavigationActionPolicyCancel for it right after the
    second decisionHandler received, -[WKWebView URL] could return a null string even though it is
    loading the second one.
    
    To solve that, this patch pairs a navigationID with the pendingAPIRequestURL such that
    WebPageProxy::receivedPolicyDecision could clear the pendingAPIRequestURL only if
    the passed navigation ID matches the current one.
    
    * UIProcess/PageLoadState.cpp:
    (WebKit::PageLoadState::reset):
    (WebKit::PageLoadState::activeURL):
    (WebKit::PageLoadState::estimatedProgress):
    (WebKit::PageLoadState::pendingAPIRequestURL const):
    (WebKit::PageLoadState::pendingAPIRequest const):
    (WebKit::PageLoadState::setPendingAPIRequest):
    (WebKit::PageLoadState::clearPendingAPIRequest):
    (WebKit::PageLoadState::isLoading):
    (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted.
    (WebKit::PageLoadState::clearPendingAPIRequestURL): Deleted.
    * UIProcess/PageLoadState.h:
    (WebKit::PageLoadState::setPendingAPIRequest):
    (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted.
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::launchProcessForReload):
    (WebKit::WebPageProxy::loadRequestWithNavigationShared):
    (WebKit::WebPageProxy::loadFile):
    (WebKit::WebPageProxy::loadDataWithNavigationShared):
    (WebKit::WebPageProxy::loadAlternateHTML):
    (WebKit::WebPageProxy::loadWebArchiveData):
    (WebKit::WebPageProxy::reload):
    (WebKit::WebPageProxy::goToBackForwardItem):
    (WebKit::WebPageProxy::receivedPolicyDecision):
    (WebKit::WebPageProxy::continueNavigationInNewProcess):
    (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared):
    (WebKit::WebPageProxy::didSameDocumentNavigationForFrame):
    (WebKit::WebPageProxy::decidePolicyForNavigationAction):
    
    Tools:
    
    Added an API test.
    
    * TestWebKitAPI/Tests/WebKitCocoa/DecidePolicyForNavigationAction.mm:
    (-[DecidePolicyForNavigationActionController webView:decidePolicyForNavigationAction:decisionHandler:]):
    (TEST):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247851 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-25  Jiewen Tan  <jiewen_tan@apple.com>

            WebPageProxy::receivedPolicyDecision should check navigation ID before clear pendingAPIRequest
            https://bugs.webkit.org/show_bug.cgi?id=200108
            <rdar://problem/53521238>

            Reviewed by Chris Dumez.

            Assuming there are two loads happening one after another. There is an issue when clients save
            the first decisionHandler and then call WKNavigationActionPolicyCancel for it right after the
            second decisionHandler received, -[WKWebView URL] could return a null string even though it is
            loading the second one.

            To solve that, this patch pairs a navigationID with the pendingAPIRequestURL such that
            WebPageProxy::receivedPolicyDecision could clear the pendingAPIRequestURL only if
            the passed navigation ID matches the current one.

            * UIProcess/PageLoadState.cpp:
            (WebKit::PageLoadState::reset):
            (WebKit::PageLoadState::activeURL):
            (WebKit::PageLoadState::estimatedProgress):
            (WebKit::PageLoadState::pendingAPIRequestURL const):
            (WebKit::PageLoadState::pendingAPIRequest const):
            (WebKit::PageLoadState::setPendingAPIRequest):
            (WebKit::PageLoadState::clearPendingAPIRequest):
            (WebKit::PageLoadState::isLoading):
            (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted.
            (WebKit::PageLoadState::clearPendingAPIRequestURL): Deleted.
            * UIProcess/PageLoadState.h:
            (WebKit::PageLoadState::setPendingAPIRequest):
            (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted.
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::launchProcessForReload):
            (WebKit::WebPageProxy::loadRequestWithNavigationShared):
            (WebKit::WebPageProxy::loadFile):
            (WebKit::WebPageProxy::loadDataWithNavigationShared):
            (WebKit::WebPageProxy::loadAlternateHTML):
            (WebKit::WebPageProxy::loadWebArchiveData):
            (WebKit::WebPageProxy::reload):
            (WebKit::WebPageProxy::goToBackForwardItem):
            (WebKit::WebPageProxy::receivedPolicyDecision):
            (WebKit::WebPageProxy::continueNavigationInNewProcess):
            (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared):
            (WebKit::WebPageProxy::didSameDocumentNavigationForFrame):
            (WebKit::WebPageProxy::decidePolicyForNavigationAction):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247839. rdar://problem/53647896

    [iOS WK2] A top fixed bar can flicker when scrolling with the keyboard up
    https://bugs.webkit.org/show_bug.cgi?id=200105
    rdar://problem/52871975
    
    Reviewed by Wenson Hsieh.
    
    Source/WebCore:
    
    ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport
    from the current scroll position and scrollableAreaSize(). This doesn't know anything about
    the impact of keyboards on the visual viewport, so it computes a too-large visual viewport
    when the keyboard is up, triggering incorrect manipulations of the layout viewport. This
    leads to the top bar flashing to position 0 when it should be hidden off the top.
    
    Fix by feeding into the scrolling tree the height of the visual viewport which takes
    FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/
    ScrollingTreeFrameScrollingNode.
    
    Test: scrollingcoordinator/ios/fixed-scrolling-with-keyboard.html
    
    * page/FrameView.h:
    * page/scrolling/AsyncScrollingCoordinator.cpp:
    (WebCore::AsyncScrollingCoordinator::setFrameScrollingNodeState):
    * page/scrolling/ScrollingStateFrameScrollingNode.cpp:
    (WebCore::ScrollingStateFrameScrollingNode::ScrollingStateFrameScrollingNode):
    (WebCore::ScrollingStateFrameScrollingNode::setPropertyChangedBitsAfterReattach):
    (WebCore::ScrollingStateFrameScrollingNode::setOverrideVisualViewportSize):
    (WebCore::ScrollingStateFrameScrollingNode::dumpProperties const):
    * page/scrolling/ScrollingStateFrameScrollingNode.h:
    * page/scrolling/ScrollingTree.cpp:
    (WebCore::ScrollingTree::commitTreeState): LOG_WITH_STREAM() doesn't evaluate scrollingTreeAsText()
    every time.
    * page/scrolling/ScrollingTreeFrameScrollingNode.cpp:
    (WebCore::ScrollingTreeFrameScrollingNode::commitStateBeforeChildren):
    (WebCore::ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition const):
    (WebCore::ScrollingTreeFrameScrollingNode::dumpProperties const):
    * page/scrolling/ScrollingTreeFrameScrollingNode.h:
    
    Source/WebKit:
    
    ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport
    from the current scroll position and scrollableAreaSize(). This doesn't know anything about
    the impact of keyboards on the visual viewport, so it computes a too-large visual viewport
    when the keyboard is up, triggering incorrect manipulations of the layout viewport. This
    leads to the top bar flashing to position 0 when it should be hidden off the top.
    
    Fix by feeding into the scrolling tree the height of the visual viewport which takes
    FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/
    ScrollingTreeFrameScrollingNode.
    
    * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
    (ArgumentCoder<ScrollingStateFrameScrollingNode>::encode):
    (ArgumentCoder<ScrollingStateFrameScrollingNode>::decode):
    
    LayoutTests:
    
    * resources/ui-helper.js:
    (window.UIHelper.ensureStablePresentationUpdate.return.new.Promise):
    (window.UIHelper.ensureStablePresentationUpdate):
    * scrollingcoordinator/ios/fixed-scrolling-with-keyboard-expected.txt: Added.
    * scrollingcoordinator/ios/fixed-scrolling-with-keyboard.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247839 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-29  Alan Coon  <alancoon@apple.com>

            Cherry-pick r247838. rdar://problem/53648220

        WebKit/UIProcess/ios/WKContentViewInteraction.mm: error: implementing deprecated method contextMenuInteractionWillPresent
        https://bugs.webkit.org/show_bug.cgi?id=200136
        <rdar://problem/53547698>

        Reviewed by Wenson Hsieh.

        Ignore deprecation warnings for these UIContextMenuInteraction delegates.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView contextMenuInteractionWillPresent:]):
        (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]):
        (-[WKContentView contextMenuInteractionDidEnd:]):

        git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247838 268f45cc-cd09-0410-ab3c-d52691b4dbfc

        2019-07-25  Dean Jackson  <dino@apple.com>

                WebKit/UIProcess/ios/WKContentViewInteraction.mm: error: implementing deprecated method contextMenuInteractionWillPresent
                https://bugs.webkit.org/show_bug.cgi?id=200136
                <rdar://problem/53547698>

                Reviewed by Wenson Hsieh.

                Ignore deprecation warnings for these UIContextMenuInteraction delegates.

                * UIProcess/ios/WKContentViewInteraction.mm:
                (-[WKContentView contextMenuInteractionWillPresent:]):
                (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]):
                (-[WKContentView contextMenuInteractionDidEnd:]):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247837. rdar://problem/53648220

    Add helper for ignoring deprecated implementation warnings
    https://bugs.webkit.org/show_bug.cgi?id=200135
    
    Reviewed by Wenson Hsieh.
    
    Add ALLOW_DEPRECATED_IMPLEMENTATIONS_BEGIN/END macro which
    is IGNORE_WARNINGS_BEGIN("deprecated-implementations")
    
    Source/WebCore:
    
    * accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
    (-[WebAccessibilityObjectWrapper ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]):
    (-[WebAccessibilityObjectWrapper accessibilityIsAttributeSettable:]):
    (-[WebAccessibilityObjectWrapper accessibilityPerformAction:]):
    (-[WebAccessibilityObjectWrapper accessibilitySetValue:forAttribute:]):
    (-[WebAccessibilityObjectWrapper accessibilityActionDescription:]):
    (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]):
    (-[WebAccessibilityObjectWrapper IGNORE_WARNINGS_END]): Deleted.
    * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
    (-[WebAVStreamDataParserListener streamDataParserWillProvideContentKeyRequestInitializationData:forTrackID:]):
    (-[WebAVStreamDataParserListener streamDataParser:didProvideContentKeyRequestInitializationData:forTrackID:]):
    * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm:
    (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveAuthenticationChallenge:]):
    (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]):
    
    Source/WebKit:
    
    * UIProcess/API/Cocoa/LegacyBundleForClass.mm:
    * UIProcess/API/Cocoa/WKBrowsingContextController.mm:
    (IGNORE_WARNINGS_BEGIN): Deleted.
    * UIProcess/API/Cocoa/WKBrowsingContextGroup.mm:
    (IGNORE_WARNINGS_BEGIN): Deleted.
    * UIProcess/API/Cocoa/WKConnection.mm:
    (IGNORE_WARNINGS_BEGIN): Deleted.
    * UIProcess/API/Cocoa/WKPreviewElementInfo.mm:
    * UIProcess/API/Cocoa/WKProcessGroup.mm:
    (IGNORE_WARNINGS_BEGIN): Deleted.
    * UIProcess/API/Cocoa/WKTypeRefWrapper.mm:
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WKWebView draggedImage:endedAt:operation:]):
    (-[WKWebView accessibilityAttributeValue:]):
    (-[WKWebView accessibilityAttributeValue:forParameter:]):
    (-[WKWebView namesOfPromisedFilesDroppedAtDestination:]):
    (-[WKWebView IGNORE_WARNINGS_END]): Deleted.
    * UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
    (-[WKWebViewConfiguration ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WKWebViewConfiguration _setWebsiteDataStore:]):
    (-[WKWebViewConfiguration IGNORE_WARNINGS_END]): Deleted.
    * UIProcess/API/Cocoa/_WKWebsiteDataStore.mm:
    * UIProcess/API/mac/WKView.mm:
    (-[WKView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WKView draggedImage:endedAt:operation:]):
    (-[WKView accessibilityAttributeValue:]):
    (-[WKView accessibilityAttributeValue:forParameter:]):
    (-[WKView namesOfPromisedFilesDroppedAtDestination:]):
    (-[WKView IGNORE_WARNINGS_END]): Deleted.
    * UIProcess/WKImagePreviewViewController.mm:
    (-[WKImagePreviewViewController ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WKImagePreviewViewController IGNORE_WARNINGS_END]): Deleted.
    * UIProcess/ios/forms/WKAirPlayRoutePicker.mm:
    (-[WKAirPlayRoutePicker popoverControllerDidDismissPopover:]):
    * UIProcess/ios/forms/WKFileUploadPanel.mm:
    (-[WKFileUploadPanel popoverControllerDidDismissPopover:]):
    * UIProcess/ios/forms/WKFormPopover.mm:
    (-[WKRotatingPopover popoverControllerDidDismissPopover:]):
    * WebProcess/Plugins/PDF/PDFPlugin.mm:
    (-[WKPDFPluginAccessibilityObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:]):
    (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:forParameter:]):
    (-[WKPDFPluginAccessibilityObject accessibilityPerformAction:]):
    (-[WKPDFPluginAccessibilityObject accessibilityIsAttributeSettable:]):
    (-[WKPDFPluginAccessibilityObject accessibilitySetValue:forAttribute:]):
    (-[WKPDFPluginAccessibilityObject IGNORE_WARNINGS_END]): Deleted.
    * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:
    (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WKAccessibilityWebPageObject accessibilityIsAttributeSettable:]):
    (-[WKAccessibilityWebPageObject accessibilitySetValue:forAttribute:]):
    (-[WKAccessibilityWebPageObject accessibilityAttributeValue:]):
    (-[WKAccessibilityWebPageObject accessibilityAttributeValue:forParameter:]):
    (-[WKAccessibilityWebPageObject IGNORE_WARNINGS_END]): Deleted.
    
    Source/WebKitLegacy/mac:
    
    * Misc/WebDownload.mm:
    (-[WebDownload initWithRequest:delegate:]):
    * Misc/WebIconDatabase.mm:
    * Plugins/WebBaseNetscapePluginView.mm:
    (-[WebBaseNetscapePluginView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WebBaseNetscapePluginView IGNORE_WARNINGS_END]): Deleted.
    * WebView/WebDynamicScrollBarsView.mm:
    (-[WebDynamicScrollBarsView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WebDynamicScrollBarsView IGNORE_WARNINGS_END]): Deleted.
    * WebView/WebHTMLView.mm:
    (-[WebHTMLView draggingSourceOperationMaskForLocal:]):
    (-[WebHTMLView draggedImage:endedAt:operation:]):
    (-[WebHTMLView namesOfPromisedFilesDroppedAtDestination:]):
    (-[WebHTMLView accessibilityAttributeValue:]):
    (-[WebHTMLView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
    (-[WebHTMLView characterIndexForPoint:]):
    (-[WebHTMLView firstRectForCharacterRange:]):
    (-[WebHTMLView attributedSubstringFromRange:]):
    (-[WebHTMLView setMarkedText:selectedRange:]):
    (-[WebHTMLView doCommandBySelector:]):
    (-[WebHTMLView insertText:]):
    (-[WebHTMLView IGNORE_WARNINGS_END]): Deleted.
    
    Source/WTF:
    
    * wtf/Compiler.h:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247837 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-25  Dean Jackson  <dino@apple.com>

            Add helper for ignoring deprecated implementation warnings
            https://bugs.webkit.org/show_bug.cgi?id=200135

            Reviewed by Wenson Hsieh.

            Add ALLOW_DEPRECATED_IMPLEMENTATIONS_BEGIN/END macro which
            is IGNORE_WARNINGS_BEGIN("deprecated-implementations")

            * UIProcess/API/Cocoa/LegacyBundleForClass.mm:
            * UIProcess/API/Cocoa/WKBrowsingContextController.mm:
            (IGNORE_WARNINGS_BEGIN): Deleted.
            * UIProcess/API/Cocoa/WKBrowsingContextGroup.mm:
            (IGNORE_WARNINGS_BEGIN): Deleted.
            * UIProcess/API/Cocoa/WKConnection.mm:
            (IGNORE_WARNINGS_BEGIN): Deleted.
            * UIProcess/API/Cocoa/WKPreviewElementInfo.mm:
            * UIProcess/API/Cocoa/WKProcessGroup.mm:
            (IGNORE_WARNINGS_BEGIN): Deleted.
            * UIProcess/API/Cocoa/WKTypeRefWrapper.mm:
            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
            (-[WKWebView draggedImage:endedAt:operation:]):
            (-[WKWebView accessibilityAttributeValue:]):
            (-[WKWebView accessibilityAttributeValue:forParameter:]):
            (-[WKWebView namesOfPromisedFilesDroppedAtDestination:]):
            (-[WKWebView IGNORE_WARNINGS_END]): Deleted.
            * UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
            (-[WKWebViewConfiguration ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
            (-[WKWebViewConfiguration _setWebsiteDataStore:]):
            (-[WKWebViewConfiguration IGNORE_WARNINGS_END]): Deleted.
            * UIProcess/API/Cocoa/_WKWebsiteDataStore.mm:
            * UIProcess/API/mac/WKView.mm:
            (-[WKView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
            (-[WKView draggedImage:endedAt:operation:]):
            (-[WKView accessibilityAttributeValue:]):
            (-[WKView accessibilityAttributeValue:forParameter:]):
            (-[WKView namesOfPromisedFilesDroppedAtDestination:]):
            (-[WKView IGNORE_WARNINGS_END]): Deleted.
            * UIProcess/WKImagePreviewViewController.mm:
            (-[WKImagePreviewViewController ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
            (-[WKImagePreviewViewController IGNORE_WARNINGS_END]): Deleted.
            * UIProcess/ios/forms/WKAirPlayRoutePicker.mm:
            (-[WKAirPlayRoutePicker popoverControllerDidDismissPopover:]):
            * UIProcess/ios/forms/WKFileUploadPanel.mm:
            (-[WKFileUploadPanel popoverControllerDidDismissPopover:]):
            * UIProcess/ios/forms/WKFormPopover.mm:
            (-[WKRotatingPopover popoverControllerDidDismissPopover:]):
            * WebProcess/Plugins/PDF/PDFPlugin.mm:
            (-[WKPDFPluginAccessibilityObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
            (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:]):
            (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:forParameter:]):
            (-[WKPDFPluginAccessibilityObject accessibilityPerformAction:]):
            (-[WKPDFPluginAccessibilityObject accessibilityIsAttributeSettable:]):
            (-[WKPDFPluginAccessibilityObject accessibilitySetValue:forAttribute:]):
            (-[WKPDFPluginAccessibilityObject IGNORE_WARNINGS_END]): Deleted.
            * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:
            (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
            (-[WKAccessibilityWebPageObject accessibilityIsAttributeSettable:]):
            (-[WKAccessibilityWebPageObject accessibilitySetValue:forAttribute:]):
            (-[WKAccessibilityWebPageObject accessibilityAttributeValue:]):
            (-[WKAccessibilityWebPageObject accessibilityAttributeValue:forParameter:]):
            (-[WKAccessibilityWebPageObject IGNORE_WARNINGS_END]): Deleted.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247822. rdar://problem/53648211

    Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts
    https://bugs.webkit.org/show_bug.cgi?id=200107
    <rdar://problem/53034592>
    
    Reviewed by Geoffrey Garen.
    
    Source/WebCore:
    
    Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply.
    
    Test: fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html
    
    * page/ChromeClient.h:
    * testing/Internals.cpp:
    (WebCore::Internals::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    * testing/Internals.h:
    * testing/Internals.idl:
    
    Source/WebKit:
    
    * Platform/IPC/Connection.cpp:
    (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount):
    (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount):
    (IPC::Connection::SyncMessageState::processIncomingMessage):
    (IPC::Connection::sendSyncMessage):
    * Platform/IPC/Connection.h:
    Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag
    to allow processing incoming sync messages while sending a particular sync IPC. This is the
    default behavior in all processes except in the WebContent process, where we try to avoid
    re-entering to prevent bugs. This flag allows the WebContent process to change its default
    behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits
    performance to re-renter.
    
    * NetworkProcess/NetworkConnectionToWebProcess.cpp:
    (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    * NetworkProcess/NetworkConnectionToWebProcess.h:
    * NetworkProcess/NetworkConnectionToWebProcess.messages.in:
    * UIProcess/Network/NetworkProcessProxy.cpp:
    (WebKit::NetworkProcessProxy::didReceiveSyncMessage):
    (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    * UIProcess/Network/NetworkProcessProxy.h:
    * UIProcess/Network/NetworkProcessProxy.messages.in:
    * WebProcess/WebCoreSupport/WebChromeClient.cpp:
    (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    * WebProcess/WebCoreSupport/WebChromeClient.h:
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
    * WebProcess/WebPage/WebPage.h:
    (WebKit::WebPage::sendSyncWithDelayedReply):
    * WebProcess/WebPage/WebPage.messages.in:
    SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply
    Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply
    flag.
    
    * WebProcess/WebCoreSupport/WebChromeClient.cpp:
    (WebKit::WebChromeClient::runJavaScriptAlert):
    (WebKit::WebChromeClient::runJavaScriptConfirm):
    (WebKit::WebChromeClient::runJavaScriptPrompt):
    Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending
    the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process
    incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked
    on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs
    since they are triggered by JS and we return to JS right after. This should avoid UIProcess
    hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself
    stuck on the sync IPC to show a JS alert.
    
    LayoutTests:
    
    Add layout test coverage for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply.
    Without the flag on the sendSync from the WebContent process of the
    NetworkConnectionToWebProcess::TestProcessIncomingSyncMessagesWhenWaitingForSyncReply IPC, the
    test would hang. This is because the WebContent process sends a sync IPC to the network process,
    which in turns sends one to the UIProcess, which itself sends one back to the WebContent process.
    This would attempt to re-enter the WebContent process which is currently sending a sync IPC, which
    is not allowed by default.
    
    * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt: Added.
    * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247822 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-25  Chris Dumez  <cdumez@apple.com>

            Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts
            https://bugs.webkit.org/show_bug.cgi?id=200107
            <rdar://problem/53034592>

            Reviewed by Geoffrey Garen.

            * Platform/IPC/Connection.cpp:
            (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount):
            (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount):
            (IPC::Connection::SyncMessageState::processIncomingMessage):
            (IPC::Connection::sendSyncMessage):
            * Platform/IPC/Connection.h:
            Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag
            to allow processing incoming sync messages while sending a particular sync IPC. This is the
            default behavior in all processes except in the WebContent process, where we try to avoid
            re-entering to prevent bugs. This flag allows the WebContent process to change its default
            behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits
            performance to re-renter.

            * NetworkProcess/NetworkConnectionToWebProcess.cpp:
            (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
            * NetworkProcess/NetworkConnectionToWebProcess.h:
            * NetworkProcess/NetworkConnectionToWebProcess.messages.in:
            * UIProcess/Network/NetworkProcessProxy.cpp:
            (WebKit::NetworkProcessProxy::didReceiveSyncMessage):
            (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
            * UIProcess/Network/NetworkProcessProxy.h:
            * UIProcess/Network/NetworkProcessProxy.messages.in:
            * WebProcess/WebCoreSupport/WebChromeClient.cpp:
            (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
            * WebProcess/WebCoreSupport/WebChromeClient.h:
            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
            * WebProcess/WebPage/WebPage.h:
            (WebKit::WebPage::sendSyncWithDelayedReply):
            * WebProcess/WebPage/WebPage.messages.in:
            SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply
            Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply
            flag.

            * WebProcess/WebCoreSupport/WebChromeClient.cpp:
            (WebKit::WebChromeClient::runJavaScriptAlert):
            (WebKit::WebChromeClient::runJavaScriptConfirm):
            (WebKit::WebChromeClient::runJavaScriptPrompt):
            Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending
            the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process
            incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked
            on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs
            since they are triggered by JS and we return to JS right after. This should avoid UIProcess
            hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself
            stuck on the sync IPC to show a JS alert.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247817. rdar://problem/53648067

    Unable to tap/double tap to open files/folders in Google Drive in Safari
    https://bugs.webkit.org/show_bug.cgi?id=200096
    <rdar://problem/52748552>
    
    Reviewed by Wenson Hsieh.
    
    Source/WebKit:
    
    This patch reverts to the original double-tap-for-double-click implementation (see r244775 and r246347 for more information).
    
    * Shared/WebPageCreationParameters.cpp:
    (WebKit::WebPageCreationParameters::encode const):
    (WebKit::WebPageCreationParameters::decode):
    * Shared/WebPageCreationParameters.h:
    * UIProcess/PageClient.h:
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::creationParameters):
    * UIProcess/WebPageProxy.h:
    * UIProcess/ios/PageClientImplIOS.h:
    * UIProcess/ios/PageClientImplIOS.mm:
    (WebKit::PageClientImpl::doubleTapForDoubleClickDelay): Deleted.
    (WebKit::PageClientImpl::doubleTapForDoubleClickRadius): Deleted.
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView setupInteraction]):
    (-[WKContentView cleanupInteraction]):
    (-[WKContentView _removeDefaultGestureRecognizers]):
    (-[WKContentView _addDefaultGestureRecognizers]):
    (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): Do not recognize the single and double gestures the same time.
    (-[WKContentView gestureRecognizerShouldBegin:]):
    (-[WKContentView _doubleTapRecognizedForDoubleClick:]):
    (-[WKContentView _didStartProvisionalLoadForMainFrame]):
    (-[WKContentView _ensureNonBlockingDoubleTapGestureRecognizer]): Deleted.
    (-[WKContentView _doubleTapForDoubleClickDelay]): Deleted.
    (-[WKContentView _doubleTapForDoubleClickRadius]): Deleted.
    * UIProcess/ios/WebPageProxyIOS.mm:
    (WebKit::WebPageProxy::handleDoubleTapForDoubleClickAtPoint):
    * WebProcess/WebPage/WebPage.cpp:
    * WebProcess/WebPage/WebPage.h:
    * WebProcess/WebPage/WebPage.messages.in:
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::handleDoubleTapForDoubleClickAtPoint):
    (WebKit::WebPage::commitPotentialTap):
    (WebKit::WebPage::handlePotentialDoubleTapForDoubleClickAtPoint): Deleted.
    
    LayoutTests:
    
    Rebaseline.
    
    * fast/events/touch/ios/double-tap-for-double-click3-expected.txt:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247817 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Zalan Bujtas  <zalan@apple.com>

            Unable to tap/double tap to open files/folders in Google Drive in Safari
            https://bugs.webkit.org/show_bug.cgi?id=200096
            <rdar://problem/52748552>

            Reviewed by Wenson Hsieh.

            This patch reverts to the original double-tap-for-double-click implementation (see r244775 and r246347 for more information).

            * Shared/WebPageCreationParameters.cpp:
            (WebKit::WebPageCreationParameters::encode const):
            (WebKit::WebPageCreationParameters::decode):
            * Shared/WebPageCreationParameters.h:
            * UIProcess/PageClient.h:
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::creationParameters):
            * UIProcess/WebPageProxy.h:
            * UIProcess/ios/PageClientImplIOS.h:
            * UIProcess/ios/PageClientImplIOS.mm:
            (WebKit::PageClientImpl::doubleTapForDoubleClickDelay): Deleted.
            (WebKit::PageClientImpl::doubleTapForDoubleClickRadius): Deleted.
            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView setupInteraction]):
            (-[WKContentView cleanupInteraction]):
            (-[WKContentView _removeDefaultGestureRecognizers]):
            (-[WKContentView _addDefaultGestureRecognizers]):
            (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): Do not recognize the single and double gestures the same time.
            (-[WKContentView gestureRecognizerShouldBegin:]):
            (-[WKContentView _doubleTapRecognizedForDoubleClick:]):
            (-[WKContentView _didStartProvisionalLoadForMainFrame]):
            (-[WKContentView _ensureNonBlockingDoubleTapGestureRecognizer]): Deleted.
            (-[WKContentView _doubleTapForDoubleClickDelay]): Deleted.
            (-[WKContentView _doubleTapForDoubleClickRadius]): Deleted.
            * UIProcess/ios/WebPageProxyIOS.mm:
            (WebKit::WebPageProxy::handleDoubleTapForDoubleClickAtPoint):
            * WebProcess/WebPage/WebPage.cpp:
            * WebProcess/WebPage/WebPage.h:
            * WebProcess/WebPage/WebPage.messages.in:
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::handleDoubleTapForDoubleClickAtPoint):
            (WebKit::WebPage::commitPotentialTap):
            (WebKit::WebPage::handlePotentialDoubleTapForDoubleClickAtPoint): Deleted.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247793. rdar://problem/53648076

    Regression(r247400): Unable to log into AIB Mobile Banking App
    https://bugs.webkit.org/show_bug.cgi?id=200094
    <rdar://problem/52519818>
    
    Reviewed by Brent Fulgham.
    
    In r247400, a change was made to only set the 'app has universal sandbox access' flag
    only when issueing the sandbox extension for / actually succeeded (it usually fails
    in practice). Previously, AIB Mobile Banking app was relying on this behavior to
    trigger a load for file:///login which is outside their container. However, now that
    the 'app has universal sandbox access' flag is no longer set, it trips our security
    checks and the load gets ignored.
    
    To address the issue, apply only the 'app has universal sandbox access' flag fix with
    a linked-on-after check.
    
    * UIProcess/Cocoa/VersionChecks.h:
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247793 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Chris Dumez  <cdumez@apple.com>

            Regression(r247400): Unable to log into AIB Mobile Banking App
            https://bugs.webkit.org/show_bug.cgi?id=200094
            <rdar://problem/52519818>

            Reviewed by Brent Fulgham.

            In r247400, a change was made to only set the 'app has universal sandbox access' flag
            only when issueing the sandbox extension for / actually succeeded (it usually fails
            in practice). Previously, AIB Mobile Banking app was relying on this behavior to
            trigger a load for file:///login which is outside their container. However, now that
            the 'app has universal sandbox access' flag is no longer set, it trips our security
            checks and the load gets ignored.

            To address the issue, apply only the 'app has universal sandbox access' flag fix with
            a linked-on-after check.

            * UIProcess/Cocoa/VersionChecks.h:
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247791. rdar://problem/53647631

    Module-enabled users of WKWebProcessPlugInFrame.h fail to build; duplicate declaration
    https://bugs.webkit.org/show_bug.cgi?id=200095
    <rdar://problem/53512407>
    
    Reviewed by Wenson Hsieh.
    
    * WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFrame.h:
    Import <JavaScriptCore/JavaScriptCore.h> (the module header) instead of
    <JavaScriptCore/JSContext.h> directly, otherwise we can end up getting
    JSContext.h included twice, to the compiler's chagrin.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247791 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Tim Horton  <timothy_horton@apple.com>

            Module-enabled users of WKWebProcessPlugInFrame.h fail to build; duplicate declaration
            https://bugs.webkit.org/show_bug.cgi?id=200095
            <rdar://problem/53512407>

            Reviewed by Wenson Hsieh.

            * WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFrame.h:
            Import <JavaScriptCore/JavaScriptCore.h> (the module header) instead of
            <JavaScriptCore/JSContext.h> directly, otherwise we can end up getting
            JSContext.h included twice, to the compiler's chagrin.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247787. rdar://problem/53647890

    Crash in WebContent process with custom schemes.
    <rdar://problem/52968793> and https://bugs.webkit.org/show_bug.cgi?id=200062
    
    Reviewed by Andy Estes.
    
    Almost everywhere in WebURLSchemeTaskProxy where we call processNextPendingTask() we first protect the task with a ref.
    But not in didReceiveData.
    So lets do that.
    
    * WebProcess/WebPage/WebURLSchemeTaskProxy.cpp:
    (WebKit::WebURLSchemeTaskProxy::didReceiveData): Protect this.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247787 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Brady Eidson  <beidson@apple.com>

            Crash in WebContent process with custom schemes.
            <rdar://problem/52968793> and https://bugs.webkit.org/show_bug.cgi?id=200062

            Reviewed by Andy Estes.

            Almost everywhere in WebURLSchemeTaskProxy where we call processNextPendingTask() we first protect the task with a ref.
            But not in didReceiveData.
            So lets do that.

            * WebProcess/WebPage/WebURLSchemeTaskProxy.cpp:
            (WebKit::WebURLSchemeTaskProxy::didReceiveData): Protect this.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247786. rdar://problem/53647457

    Null check CompletionHandler in WebPreviewLoaderClient::didReceivePassword
    https://bugs.webkit.org/show_bug.cgi?id=200080
    <rdar://problem/37275772>
    
    Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-24
    Reviewed by Chris Dumez.
    
    * WebProcess/WebCoreSupport/ios/WebPreviewLoaderClient.cpp:
    (WebKit::WebPreviewLoaderClient::didReceivePassword):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247786 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Alex Christensen  <achristensen@webkit.org>

            Null check CompletionHandler in WebPreviewLoaderClient::didReceivePassword
            https://bugs.webkit.org/show_bug.cgi?id=200080
            <rdar://problem/37275772>

            Reviewed by Chris Dumez.

            * WebProcess/WebCoreSupport/ios/WebPreviewLoaderClient.cpp:
            (WebKit::WebPreviewLoaderClient::didReceivePassword):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247784. rdar://problem/53647468

    Crash under WebKit:WTF::Detail::CallableWrapper<WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking(WTF::CompletionHandler<void ()>&&)::$_32::operator()()::'lambda'(), void>::call
    https://bugs.webkit.org/show_bug.cgi?id=200071
    <rdar://problem/53335583>
    
    Reviewed by Brent Fulgham and Youenn Fablet.
    
    The WebResourceLoadStatisticsStore is a main thread object. In its destructor, it was dispatching
    to the background queue to destroy the m_statisticsStore / m_persistentStorage data members, which
    live on the background queue. It would then synchronously wait for the background queue to finish
    destroying them. The idea was to guarantee that the ResourceLoadStatisticsMemoryStore and the
    ResourceLoadStatisticsPersistentStorage would never outlive the WebResourceLoadStatisticsStore,
    given that they keep a raw pointer back to the WebResourceLoadStatisticsStore (via m_store data
    member).
    
    The issue is that *while* the WebResourceLoadStatisticsStore destructor is running on the main
    thread, the background queue may be running code in ResourceLoadStatisticsMemoryStore or
    ResourceLoadStatisticsPersistentStorage which refs the WebResourceLoadStatisticsStore, even
    though its ref count has already reached 0. It is actually a common pattern in
    ResourceLoadStatisticsMemoryStore to call RunLoop::main().dispatch() and ref their m_store in
    the lambda, so that they can interact with the WebResourceLoadStatisticsStore.
    
    To address the issue, we now destroy m_statisticsStore / m_persistentStorage *before* the
    WebResourceLoadStatisticsStore destructor runs. The NetworkSession destructor now calls
    WebResourceLoadStatisticsStore::didDestroyNetworkSession() which takes care of destroying
    m_statisticsStore / m_persistentStorage on the background queue, synchronously. The
    WebResourceLoadStatisticsStore destructor will only run later, once all remaining references
    to it are gone.
    
    * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
    (WebKit::WebResourceLoadStatisticsStore::~WebResourceLoadStatisticsStore):
    (WebKit::WebResourceLoadStatisticsStore::didDestroyNetworkSession):
    * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:
    * NetworkProcess/NetworkSession.cpp:
    (WebKit::NetworkSession::~NetworkSession):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247784 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Chris Dumez  <cdumez@apple.com>

            Crash under WebKit:WTF::Detail::CallableWrapper<WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking(WTF::CompletionHandler<void ()>&&)::$_32::operator()()::'lambda'(), void>::call
            https://bugs.webkit.org/show_bug.cgi?id=200071
            <rdar://problem/53335583>

            Reviewed by Brent Fulgham and Youenn Fablet.

            The WebResourceLoadStatisticsStore is a main thread object. In its destructor, it was dispatching
            to the background queue to destroy the m_statisticsStore / m_persistentStorage data members, which
            live on the background queue. It would then synchronously wait for the background queue to finish
            destroying them. The idea was to guarantee that the ResourceLoadStatisticsMemoryStore and the
            ResourceLoadStatisticsPersistentStorage would never outlive the WebResourceLoadStatisticsStore,
            given that they keep a raw pointer back to the WebResourceLoadStatisticsStore (via m_store data
            member).

            The issue is that *while* the WebResourceLoadStatisticsStore destructor is running on the main
            thread, the background queue may be running code in ResourceLoadStatisticsMemoryStore or
            ResourceLoadStatisticsPersistentStorage which refs the WebResourceLoadStatisticsStore, even
            though its ref count has already reached 0. It is actually a common pattern in
            ResourceLoadStatisticsMemoryStore to call RunLoop::main().dispatch() and ref their m_store in
            the lambda, so that they can interact with the WebResourceLoadStatisticsStore.
2019-07-24  Simon Fraser  <simon.fraser@apple.com>

        [iOS WK2] A top fixed bar can flicker when scrolling with the keyboard up
        https://bugs.webkit.org/show_bug.cgi?id=200105
        rdar://problem/52871975

        Reviewed by Wenson Hsieh.

        ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport
        from the current scroll position and scrollableAreaSize(). This doesn't know anything about
        the impact of keyboards on the visual viewport, so it computes a too-large visual viewport
        when the keyboard is up, triggering incorrect manipulations of the layout viewport. This
        leads to the top bar flashing to position 0 when it should be hidden off the top.

        Fix by feeding into the scrolling tree the height of the visual viewport which takes
        FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/
        ScrollingTreeFrameScrollingNode.

        * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
        (ArgumentCoder<ScrollingStateFrameScrollingNode>::encode):
        (ArgumentCoder<ScrollingStateFrameScrollingNode>::decode):


            To address the issue, we now destroy m_statisticsStore / m_persistentStorage *before* the
            WebResourceLoadStatisticsStore destructor runs. The NetworkSession destructor now calls
            WebResourceLoadStatisticsStore::didDestroyNetworkSession() which takes care of destroying
            m_statisticsStore / m_persistentStorage on the background queue, synchronously. The
            WebResourceLoadStatisticsStore destructor will only run later, once all remaining references
            to it are gone.

            * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
            (WebKit::WebResourceLoadStatisticsStore::~WebResourceLoadStatisticsStore):
            (WebKit::WebResourceLoadStatisticsStore::didDestroyNetworkSession):
            * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:
            * NetworkProcess/NetworkSession.cpp:
            (WebKit::NetworkSession::~NetworkSession):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247782. rdar://problem/53647473

    SYS___pthread_markcancel is sometimes used by libwebrtc
    https://bugs.webkit.org/show_bug.cgi?id=200087
    <rdar://problem/53408606>
    
    Reviewed by Brent Fulgham.
    
    * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:
    Whitelist this unix-call within WebProcess as libwebrtc uses it.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247782 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Youenn Fablet  <youenn@apple.com>

            SYS___pthread_markcancel is sometimes used by libwebrtc
            https://bugs.webkit.org/show_bug.cgi?id=200087
            <rdar://problem/53408606>

            Reviewed by Brent Fulgham.

            * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:
            Whitelist this unix-call within WebProcess as libwebrtc uses it.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247780. rdar://problem/53647618

    ASSERTION FAILED: settings().textAutosizingEnabled() && settings().textAutosizingUsesIdempotentMode() in WebCore::Page::recomputeTextAutoSizingInAllFrames()
    https://bugs.webkit.org/show_bug.cgi?id=200079
    <rdar://problem/53474325>
    
    Reviewed by Wenson Hsieh.
    
    Source/WebKit:
    
    Do not reset idempotent values when the text autosizing is off.
    
    * UIProcess/API/C/WKPreferences.cpp:
    (WKPreferencesSetTextAutosizingUsesIdempotentMode):
    (WKPreferencesGetTextAutosizingUsesIdempotentMode):
    * UIProcess/API/C/WKPreferencesRef.h:
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded):
    
    Tools:
    
    Reset textAutosizingUsesIdempotentMode when transitioning to a new test.
    
    * WebKitTestRunner/ios/TestControllerIOS.mm:
    (WTR::TestController::platformResetPreferencesToConsistentValues):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247780 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-24  Zalan Bujtas  <zalan@apple.com>

            ASSERTION FAILED: settings().textAutosizingEnabled() && settings().textAutosizingUsesIdempotentMode() in WebCore::Page::recomputeTextAutoSizingInAllFrames()
            https://bugs.webkit.org/show_bug.cgi?id=200079
            <rdar://problem/53474325>

            Reviewed by Wenson Hsieh.

            Do not reset idempotent values when the text autosizing is off.

            * UIProcess/API/C/WKPreferences.cpp:
            (WKPreferencesSetTextAutosizingUsesIdempotentMode):
            (WKPreferencesGetTextAutosizingUsesIdempotentMode):
            * UIProcess/API/C/WKPreferencesRef.h:
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247755. rdar://problem/53575423

    AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak
    https://bugs.webkit.org/show_bug.cgi?id=199988
    
    Reviewed by Per Arne Vollan.
    
    Source/WebCore:
    
    Implement the reset state to cancel current speech jobs.
    
    * Modules/speech/SpeechSynthesis.cpp:
    (WebCore::SpeechSynthesis::startSpeakingImmediately):
    (WebCore::SpeechSynthesis::cancel):
    * platform/PlatformSpeechSynthesizer.h:
    * platform/ios/PlatformSpeechSynthesizerIOS.mm:
    (WebCore::PlatformSpeechSynthesizer::resetState):
    * platform/mac/PlatformSpeechSynthesizerMac.mm:
    (WebCore::PlatformSpeechSynthesizer::resetState):
    
    Source/WebKit:
    
    Improvements to WebSpeechSynthesis to avoid crashing and improve correctness.
    - Reset and cancel speech jobs on page close or reload (otherwise the synthesizer keeps talking after your page is gone)
    - Have a separate speech finish callback mechanism, use the start speaking callback when the synthesizer tells us.
    - Move an assert on utterance state to only apply when we use the in process synthesizer.
    
    * UIProcess/Cocoa/WebPageProxyCocoa.mm:
    (WebKit::WebPageProxy::didStartSpeaking):
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::reload):
    (WebKit::WebPageProxy::resetState):
    (WebKit::WebPageProxy::resetSpeechSynthesizer):
    (WebKit::WebPageProxy::speechSynthesisSetFinishedCallback):
    (WebKit::WebPageProxy::speechSynthesisSpeak):
    * UIProcess/WebPageProxy.h:
    * UIProcess/WebPageProxy.messages.in:
    * WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp:
    (WebKit::WebSpeechSynthesisClient::speak):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247755 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-23  Chris Fleizach  <cfleizach@apple.com>

            AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak
            https://bugs.webkit.org/show_bug.cgi?id=199988

            Reviewed by Per Arne Vollan.

            Improvements to WebSpeechSynthesis to avoid crashing and improve correctness.
            - Reset and cancel speech jobs on page close or reload (otherwise the synthesizer keeps talking after your page is gone)
            - Have a separate speech finish callback mechanism, use the start speaking callback when the synthesizer tells us.
            - Move an assert on utterance state to only apply when we use the in process synthesizer.

            * UIProcess/Cocoa/WebPageProxyCocoa.mm:
            (WebKit::WebPageProxy::didStartSpeaking):
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::reload):
            (WebKit::WebPageProxy::resetState):
            (WebKit::WebPageProxy::resetSpeechSynthesizer):
            (WebKit::WebPageProxy::speechSynthesisSetFinishedCallback):
            (WebKit::WebPageProxy::speechSynthesisSpeak):
            * UIProcess/WebPageProxy.h:
            * UIProcess/WebPageProxy.messages.in:
            * WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp:
            (WebKit::WebSpeechSynthesisClient::speak):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247722. rdar://problem/53647293

    [macOS 10.15] Web process crashes when attempting to show the font panel via Font > Show Fonts
    https://bugs.webkit.org/show_bug.cgi?id=200021
    <rdar://problem/53301325>
    
    Reviewed by Ryosuke Niwa.
    
    Source/WebCore:
    
    In macOS 10.15, attempting to access ~/Library/FontCollections/ from the web process causes a Sandbox violation
    and a subsequent crash. This can be triggered by trying to show the font panel via Font > Show Fonts in the
    context menu after right clicking.
    
    In the (near) future, we should fix this by moving logic to show the font panel, color panel and styles panel
    from the Editor in the web process to the UI process in WebKit2. However, for the time being, we can just work
    around this by adding a new EditorClient hook to determine whether to allow the font panel to show; this returns
    true in the legacy macOS WebKit port, and false everywhere else.
    
    Test: editing/mac/style/do-not-crash-when-showing-font-panel.html
    
    * editing/mac/EditorMac.mm:
    (WebCore::Editor::showFontPanel):
    * loader/EmptyClients.cpp:
    * page/EditorClient.h:
    
    Source/WebKit:
    
    Always return false from canShowFontPanel in WebKit2.
    
    * WebProcess/WebCoreSupport/WebEditorClient.h:
    
    Source/WebKitLegacy/mac:
    
    Implement a new editing client hook. In WebKit1, this always returns true on macOS and false on iOS.
    
    * WebCoreSupport/WebEditorClient.h:
    
    Source/WebKitLegacy/win:
    
    Implement a new editing client hook.
    
    * WebCoreSupport/WebEditorClient.h:
    
    Tools:
    
    Add support for grabbing the child menu items of a context menu item.
    
    * WebKitTestRunner/InjectedBundle/EventSendingController.cpp:
    (WTR::getMenuItemChildrenCallback):
    
    LayoutTests:
    
    Add a new layout test to verify that attempting to show the font panel doesn't crash the web process in WebKit2.
    This test is skipped in WebKit1, since EventSender::contextClick() in WebKit1 only returns an array of strings
    corresponding to the titles of each menu item.
    
    * editing/mac/style/do-not-crash-when-showing-font-panel-expected.txt: Added.
    * editing/mac/style/do-not-crash-when-showing-font-panel.html: Added.
    * platform/mac-wk1/TestExpectations:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247722 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-23  Wenson Hsieh  <wenson_hsieh@apple.com>

            [macOS 10.15] Web process crashes when attempting to show the font panel via Font > Show Fonts
            https://bugs.webkit.org/show_bug.cgi?id=200021
            <rdar://problem/53301325>

            Reviewed by Ryosuke Niwa.

            Always return false from canShowFontPanel in WebKit2.

            * WebProcess/WebCoreSupport/WebEditorClient.h:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247695. rdar://problem/53648210

    REGRESSION(rUnknown): YouTube playback pauses when switching to a new tab
    https://bugs.webkit.org/show_bug.cgi?id=199971
    <rdar://problem/51951218>
    
    Reviewed by Alex Christensen.
    
    Source/WebKit:
    
    When we get a message notifying us that the view has been removed from the window, we unconditionally
    ask the fullscreen manager to exit fullscreen, which has the side effect (on iOS) of pausing the video
    unconditionally. Only ask the fullscreen manager to exit fullscreen if there is actually a video in
    fullscreen mode.
    
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::viewDidLeaveWindow):
    
    Tools:
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/WebKitCocoa/NoPauseWhenSwitchingTabs.mm: Added.
    (TestWebKitAPI::TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247695 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-22  Jer Noble  <jer.noble@apple.com>

            REGRESSION(rUnknown): YouTube playback pauses when switching to a new tab
            https://bugs.webkit.org/show_bug.cgi?id=199971
            <rdar://problem/51951218>

            Reviewed by Alex Christensen.

            When we get a message notifying us that the view has been removed from the window, we unconditionally
            ask the fullscreen manager to exit fullscreen, which has the side effect (on iOS) of pausing the video
            unconditionally. Only ask the fullscreen manager to exit fullscreen if there is actually a video in
            fullscreen mode.

            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::viewDidLeaveWindow):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247687. rdar://problem/53648060

    [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused
    https://bugs.webkit.org/show_bug.cgi?id=199807
    <rdar://problem/52760259>
    
    Fix a bad merge of r247653. svn-apply was way too forgiving. The original patch touched
    the non-existent function, -_didCommitLoadForMainFrame in WKContentViewInteraction.mm. Because
    that didn't exist, svn-apply patched up -clearSelection.
    
    * UIProcess/ios/WKContentView.h:
    * UIProcess/ios/WKContentView.mm:
    (-[WKContentView _didCommitLoadForMainFrame]): Deleted; moved to WKContentViewInteraction.mm
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView clearSelection]): Remove code that should be in -_didCommitLoadForMainFrame.
    (-[WKContentView _didCommitLoadForMainFrame]): Moved from WKContentView.mm
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247687 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-22  Daniel Bates  <dabates@apple.com>

            [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused
            https://bugs.webkit.org/show_bug.cgi?id=199807
            <rdar://problem/52760259>

            Fix a bad merge of r247653. svn-apply was way too forgiving. The original patch touched
            the non-existent function, -_didCommitLoadForMainFrame in WKContentViewInteraction.mm. Because
            that didn't exist, svn-apply patched up -clearSelection.

            * UIProcess/ios/WKContentView.h:
            * UIProcess/ios/WKContentView.mm:
            (-[WKContentView _didCommitLoadForMainFrame]): Deleted; moved to WKContentViewInteraction.mm
            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView clearSelection]): Remove code that should be in -_didCommitLoadForMainFrame.
            (-[WKContentView _didCommitLoadForMainFrame]): Moved from WKContentView.mm

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247679. rdar://problem/53648080

    [iOS] [WebKit2] Add limited support for -isPosition:atBoundary:inDirection: in WKContentView
    https://bugs.webkit.org/show_bug.cgi?id=199993
    <rdar://problem/49523528>
    
    Reviewed by Beth Dakin.
    
    Source/WebKit:
    
    Add support for -isPosition:atBoundary:inDirection:, only in the cases where the given position is the start or
    and position and the given granularity is UITextGranularityParagraph.
    
    Test: EditorStateTests.ParagraphBoundary
    
    * Shared/EditorState.cpp:
    (WebKit::EditorState::PostLayoutData::encode const):
    (WebKit::EditorState::PostLayoutData::decode):
    * Shared/EditorState.h:
    
    Add a couple of bits to indicate whether the selection start or end positions are at paragraph boundaries.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView isPosition:atBoundary:inDirection:]):
    
    Implement this to return selectionStartIsAtParagraphBoundary or selectionEndIsAtParagraphBoundary.
    
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::platformEditorState const):
    
    Tools:
    
    Add a new API test to verify the behavior of -isPosition:atBoundary:inDirection:.
    
    * TestWebKitAPI/Tests/WebKitCocoa/EditorStateTests.mm:
    (TestWebKitAPI::TEST):
    * TestWebKitAPI/cocoa/TestWKWebView.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247679 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-21  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iOS] [WebKit2] Add limited support for -isPosition:atBoundary:inDirection: in WKContentView
            https://bugs.webkit.org/show_bug.cgi?id=199993
            <rdar://problem/49523528>

            Reviewed by Beth Dakin.

            Add support for -isPosition:atBoundary:inDirection:, only in the cases where the given position is the start or
            and position and the given granularity is UITextGranularityParagraph.

            Test: EditorStateTests.ParagraphBoundary

            * Shared/EditorState.cpp:
            (WebKit::EditorState::PostLayoutData::encode const):
            (WebKit::EditorState::PostLayoutData::decode):
            * Shared/EditorState.h:

            Add a couple of bits to indicate whether the selection start or end positions are at paragraph boundaries.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView isPosition:atBoundary:inDirection:]):

            Implement this to return selectionStartIsAtParagraphBoundary or selectionEndIsAtParagraphBoundary.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::platformEditorState const):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247667. rdar://problem/53647463

    [Text autosizing] Do not nuke the style on dynamicViewportSizeUpdate
    https://bugs.webkit.org/show_bug.cgi?id=199718
    <rdar://problem/53344961>
    
    Reviewed by Simon Fraser.
    
    Source/WebCore:
    
    When the page scale changes (e.g. as the result of shink to fit mode) we need to visit all the text content on the page and check whether they need to be boosted.
    Currently we call setNeedsRecalcStyleInAllFrames() to accomplish it. Unfortunatelly setNeedsRecalcStyleInAllFrames destroys all the style information which means that the
    subsequent styleResolve() needs to start from scratch.
    This patch addresses this issue by directly adjusting the computed style information when text boosting is required and schedules layout accordingly. We also trigger this style adjusting
    on a timer so that rapid dynamicViewportSizeUpdate() calls won't trigger redundant layouts.
    
    * css/StyleResolver.cpp:
    (WebCore::hasTextChild):
    (WebCore::StyleResolver::adjustRenderStyleForTextAutosizing):
    (WebCore::hasTextChildren): Deleted.
    * css/StyleResolver.h:
    * page/FrameView.h:
    * page/Page.cpp:
    (WebCore::Page::invalidateTextAutoSizeInAllFrames):
    * page/Page.h:
    
    Source/WebKit:
    
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::m_textAutoSizingAdjustmentTimer):
    (WebKit::WebPage::close):
    (WebKit::WebPage::didCommitLoad):
    (WebKit::WebPage::textAutoSizingAdjustmentTimerFired):
    (WebKit::m_shrinkToFitContentTimer): Deleted.
    * WebProcess/WebPage/WebPage.h:
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::dynamicViewportSizeUpdate):
    (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded):
    (WebKit::WebPage::resetTextAutosizing):
    (WebKit::WebPage::viewportConfigurationChanged):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247667 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-20  Zalan Bujtas  <zalan@apple.com>

            [Text autosizing] Do not nuke the style on dynamicViewportSizeUpdate
            https://bugs.webkit.org/show_bug.cgi?id=199718
            <rdar://problem/53344961>

            Reviewed by Simon Fraser.

            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::m_textAutoSizingAdjustmentTimer):
            (WebKit::WebPage::close):
            (WebKit::WebPage::didCommitLoad):
            (WebKit::WebPage::textAutoSizingAdjustmentTimerFired):
            (WebKit::m_shrinkToFitContentTimer): Deleted.
            * WebProcess/WebPage/WebPage.h:
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::dynamicViewportSizeUpdate):
            (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded):
            (WebKit::WebPage::resetTextAutosizing):
            (WebKit::WebPage::viewportConfigurationChanged):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247662. rdar://problem/53648208

    Remote WebInspector should enable mock capture devices in UIProcess if doing it in WebProcess
    https://bugs.webkit.org/show_bug.cgi?id=199924
    <rdar://problem/50552067>
    
    Reviewed by Devin Rousso.
    
    Source/WebCore:
    
    Add necessary API to set mock capture devices override.
    In case of desynchronization between webprocess and uiprocess, make sure to return early
    and fail capture instead of crashing.
    
    * inspector/InspectorClient.h:
    (WebCore::InspectorClient::setMockCaptureDevicesEnabled):
    * inspector/agents/InspectorPageAgent.cpp:
    (WebCore::InspectorPageAgent::disable):
    (WebCore::InspectorPageAgent::overrideSetting):
    * platform/mock/MockRealtimeMediaSourceCenter.cpp:
    
    Source/WebKit:
    
    Add IPC plumbery to pass inspector override value for mock capture devices.
    Add an override in UserMediaPermissionRequestManagerProxy so that the value stays in sync with web inspector.
    The override will be removed when web inspector goes away.
    
    * UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
    (WebKit::UserMediaPermissionRequestManagerProxy::syncWithWebCorePrefs const):
    * UIProcess/UserMediaPermissionRequestManagerProxy.h:
    (WebKit::UserMediaPermissionRequestManagerProxy::setMockCaptureDevicesEnabledOverride):
    * UIProcess/WebInspectorProxy.cpp:
    (WebKit::WebInspectorProxy::setMockCaptureDevicesEnabled):
    * UIProcess/WebInspectorProxy.h:
    * UIProcess/WebInspectorProxy.messages.in:
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::setMockCaptureDevicesEnabledOverride):
    * UIProcess/WebPageProxy.h:
    * WebProcess/WebCoreSupport/WebInspectorClient.cpp:
    (WebKit::WebInspectorClient::setMockCaptureDevicesEnabled):
    * WebProcess/WebCoreSupport/WebInspectorClient.h:
    * WebProcess/WebPage/WebInspector.cpp:
    (WebKit::WebInspector::setMockCaptureDevicesEnabled):
    * WebProcess/WebPage/WebInspector.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247662 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-19  Youenn Fablet  <youenn@apple.com>

            Remote WebInspector should enable mock capture devices in UIProcess if doing it in WebProcess
            https://bugs.webkit.org/show_bug.cgi?id=199924
            <rdar://problem/50552067>

            Reviewed by Devin Rousso.

            Add IPC plumbery to pass inspector override value for mock capture devices.
            Add an override in UserMediaPermissionRequestManagerProxy so that the value stays in sync with web inspector.
            The override will be removed when web inspector goes away.

            * UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
            (WebKit::UserMediaPermissionRequestManagerProxy::syncWithWebCorePrefs const):
            * UIProcess/UserMediaPermissionRequestManagerProxy.h:
            (WebKit::UserMediaPermissionRequestManagerProxy::setMockCaptureDevicesEnabledOverride):
            * UIProcess/WebInspectorProxy.cpp:
            (WebKit::WebInspectorProxy::setMockCaptureDevicesEnabled):
            * UIProcess/WebInspectorProxy.h:
            * UIProcess/WebInspectorProxy.messages.in:
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::setMockCaptureDevicesEnabledOverride):
            * UIProcess/WebPageProxy.h:
            * WebProcess/WebCoreSupport/WebInspectorClient.cpp:
            (WebKit::WebInspectorClient::setMockCaptureDevicesEnabled):
            * WebProcess/WebCoreSupport/WebInspectorClient.h:
            * WebProcess/WebPage/WebInspector.cpp:
            (WebKit::WebInspector::setMockCaptureDevicesEnabled):
            * WebProcess/WebPage/WebInspector.h:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247657. rdar://problem/53648058

    Provide correct names for UIContextMenuInteraction API replacements
    https://bugs.webkit.org/show_bug.cgi?id=199966
    
    Reviewed by Tim Horton.
    
    We had some old incorrect names for replacements to SPI. While
    here, I reordered and expanded the documentation for the new API.
    
    * UIProcess/API/Cocoa/WKUIDelegate.h:
    * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247657 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-19  Dean Jackson  <dino@apple.com>

            Provide correct names for UIContextMenuInteraction API replacements
            https://bugs.webkit.org/show_bug.cgi?id=199966

            Reviewed by Tim Horton.

            We had some old incorrect names for replacements to SPI. While
            here, I reordered and expanded the documentation for the new API.

            * UIProcess/API/Cocoa/WKUIDelegate.h:
            * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247656. rdar://problem/53648229

    [iOS WK2] Allow scrolling interaction on frames and oveflow scroll even when the main frame is rubber-banding
    https://bugs.webkit.org/show_bug.cgi?id=199963
    rdar://problem/52897797
    
    Reviewed by Tim Horton.
    
    Adopt UIKit SPI to allow for scrolling of inner UIScrollViews when the outer one is still rubber-banding.
    
    * Platform/spi/ios/UIKitSPI.h:
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _initializeWithConfiguration:]):
    * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm:
    (WebKit::ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247656 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-29  Alan Coon  <alancoon@apple.com>

            Cherry-pick r247653. rdar://problem/53648060

        [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused
        https://bugs.webkit.org/show_bug.cgi?id=199807
        <rdar://problem/52760259>

        Reviewed by Wenson Hsieh.

        Sometimes the correction highlight may not hide when defocusing an editable field.
        This occurs only when a person pressed a key in a non-editable element beforehand.
        We need to reset some state to force a re-computation of whether a keyboard is still
        needed whenever an element is defocused (blurred in web paralance).

        Following r241734 both editable and non-editable key events are handled using the same
        code path. This is accomplished by having WKContentView's -_requiresKeyboardWhenFirstResponder
        return YES to tell UIKit it needs a keyboard even when there is no editable element focused.
        As a result UIKit retains all the keyboard state, including keeping the correction highlight
        visible. Prior to r241734 WKContentView's -_requiresKeyboardWhenFirstResponder would not return
        YES when a non-editable element was focused and hence UIKit would tear down the keyboard
        and its state, including the correction highlight. In r245154, we made keyboard instantiate
        for a focused non-editable element lazy as a performance optimization. Although r245154
        kept the r241734 behavior (just made it lazy) it re-wrote the code in such a way that we
        can utilize it as a hook to fix this bug. In particular, we now clear the bit about a
        seen keydown in a non-editable element whenever we are defocusing an editable element
        before we reload the input views, as part of hiding the keyboard. On the reload, UIKit
        will call -_requiresKeyboardWhenFirstResponder, WebKit will respond with NO now that
        a non-editable element is focused and hence UIKit will do what it did pre r241734: tear
        down the keyboard.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _didCommitLoadForMainFrame]): Clear the bit about a seen keydown here
        so that we don't keep the keyboard around on a new page commit. This includes the case
        when the same page is reloaded. There is not much advantage to keeping the keyboard
        around across reloads and not doing so will reduce our memory footprint.
        (-[WKContentView _elementDidBlur]): Clear the same bit as well when defocusing an
        editable element. This will cause UIKit to tear down the keyboard on reload removing
        the correction highlight.

        git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247653 268f45cc-cd09-0410-ab3c-d52691b4dbfc

        2019-07-19  Daniel Bates  <dabates@apple.com>

                [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused
                https://bugs.webkit.org/show_bug.cgi?id=199807
                <rdar://problem/52760259>

                Reviewed by Wenson Hsieh.

                Sometimes the correction highlight may not hide when defocusing an editable field.
                This occurs only when a person pressed a key in a non-editable element beforehand.
                We need to reset some state to force a re-computation of whether a keyboard is still
                needed whenever an element is defocused (blurred in web paralance).

                Following r241734 both editable and non-editable key events are handled using the same
                code path. This is accomplished by having WKContentView's -_requiresKeyboardWhenFirstResponder
                return YES to tell UIKit it needs a keyboard even when there is no editable element focused.
                As a result UIKit retains all the keyboard state, including keeping the correction highlight
                visible. Prior to r241734 WKContentView's -_requiresKeyboardWhenFirstResponder would not return
                YES when a non-editable element was focused and hence UIKit would tear down the keyboard
                and its state, including the correction highlight. In r245154, we made keyboard instantiate
                for a focused non-editable element lazy as a performance optimization. Although r245154
                kept the r241734 behavior (just made it lazy) it re-wrote the code in such a way that we
                can utilize it as a hook to fix this bug. In particular, we now clear the bit about a
                seen keydown in a non-editable element whenever we are defocusing an editable element
                before we reload the input views, as part of hiding the keyboard. On the reload, UIKit
                will call -_requiresKeyboardWhenFirstResponder, WebKit will respond with NO now that
                a non-editable element is focused and hence UIKit will do what it did pre r241734: tear
                down the keyboard.

                * UIProcess/ios/WKContentViewInteraction.mm:
                (-[WKContentView _didCommitLoadForMainFrame]): Clear the bit about a seen keydown here
                so that we don't keep the keyboard around on a new page commit. This includes the case
                when the same page is reloaded. There is not much advantage to keeping the keyboard
                around across reloads and not doing so will reduce our memory footprint.
                (-[WKContentView _elementDidBlur]): Clear the same bit as well when defocusing an
                editable element. This will cause UIKit to tear down the keyboard on reload removing
                the correction highlight.

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247651. rdar://problem/53648007

    [iOS] Entering 2FA code on idmsa.apple.com causes unexpected scrolling
    https://bugs.webkit.org/show_bug.cgi?id=199949
    <rdar://problem/49944428>
    
    Reviewed by Tim Horton and Megan Gardner.
    
    Source/WebKit:
    
    Since at least iOS 11, -[UIScrollView _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] adjusts the
    scroll view's content offset to account for updated keyboard bottom insets. In WebKit, we call this method
    whenever keyboard geometry changes (based on system notifications, such as UIKeyboardWillHideNotification).
    
    When switching between focused form fields, we hide the keyboard for the previous focused element prior to
    showing the keyboard for the newly focused element. This means that we will actually dismiss the keyboard in the
    process of changing the focused element, which posts keyboard geometry notifications, which causes us to scroll
    WKScrollView.
    
    On iOS 12, this would be immediately followed by re-presenting the keyboard for the new focused element, which
    causes us to adjust the scroll view back to its original position right away; this means that the scrolling that
    happens as a result of adjusting for the keyboard insets after dismissal doesn't result in any visible change.
    
    However, on iOS 13, after r239441 and r244546, we now defer scrolling and zooming to reveal the focused element
    until later; this means the scrolling that happens as a result of initially dismissing the keyboard now causes a
    consistent jump in the scroll view's scroll position (whereas on iOS 12, this only happens rarely, and the jump
    is also less noticeable).
    
    To mitigate this, we detect the case where we're moving focus from one element to another; if we're about to
    show a keyboard for the newly focused element, then we should avoid scrolling as a result of the impending
    "keyboard will hide" notification.
    
    Test: fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _keyboardChangedWithInfo:adjustScrollView:]):
    (-[WKWebView _keyboardWillHide:]):
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (shouldShowKeyboardForElement):
    
    Add a helper to determine whether we're focusing an element which presents a "keyboard" (i.e. a UIKit input
    view, as opposed to modal select pickers, modal date pickers, or fields with inputmode="none", for which we
    don't show an input view).
    
    (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
    (-[WKContentView shouldIgnoreKeyboardWillHideNotification]):
    
    LayoutTests:
    
    Add a new layout test to verify that moving focus between horizontally adjacent form controls doesn't induce
    vertical scrolling.
    
    * fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields-expected.txt: Added.
    * fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html: Added.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247651 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-19  Wenson Hsieh  <wenson_hsieh@apple.com>

            [iOS] Entering 2FA code on idmsa.apple.com causes unexpected scrolling
            https://bugs.webkit.org/show_bug.cgi?id=199949
            <rdar://problem/49944428>

            Reviewed by Tim Horton and Megan Gardner.

            Since at least iOS 11, -[UIScrollView _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] adjusts the
            scroll view's content offset to account for updated keyboard bottom insets. In WebKit, we call this method
            whenever keyboard geometry changes (based on system notifications, such as UIKeyboardWillHideNotification).

            When switching between focused form fields, we hide the keyboard for the previous focused element prior to
            showing the keyboard for the newly focused element. This means that we will actually dismiss the keyboard in the
            process of changing the focused element, which posts keyboard geometry notifications, which causes us to scroll
            WKScrollView.

            On iOS 12, this would be immediately followed by re-presenting the keyboard for the new focused element, which
            causes us to adjust the scroll view back to its original position right away; this means that the scrolling that
            happens as a result of adjusting for the keyboard insets after dismissal doesn't result in any visible change.

            However, on iOS 13, after r239441 and r244546, we now defer scrolling and zooming to reveal the focused element
            until later; this means the scrolling that happens as a result of initially dismissing the keyboard now causes a
            consistent jump in the scroll view's scroll position (whereas on iOS 12, this only happens rarely, and the jump
            is also less noticeable).

            To mitigate this, we detect the case where we're moving focus from one element to another; if we're about to
            show a keyboard for the newly focused element, then we should avoid scrolling as a result of the impending
            "keyboard will hide" notification.

            Test: fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _keyboardChangedWithInfo:adjustScrollView:]):
            (-[WKWebView _keyboardWillHide:]):
            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (shouldShowKeyboardForElement):

            Add a helper to determine whether we're focusing an element which presents a "keyboard" (i.e. a UIKit input
            view, as opposed to modal select pickers, modal date pickers, or fields with inputmode="none", for which we
            don't show an input view).

            (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
            (-[WKContentView shouldIgnoreKeyboardWillHideNotification]):

2019-07-29  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247635. rdar://problem/53647467

    Fix warning when importing WebKit in Swift
    https://bugs.webkit.org/show_bug.cgi?id=199914
    <rdar://problem/52854930>
    
    Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-18
    Reviewed by Wenson Hsieh.
    
    * UIProcess/API/Cocoa/NSAttributedString.h:
    Declare NSAttributedString and update a swift name.
    This fix was proposed by Argyrios Kyrtzidis.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247635 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-18  Alex Christensen  <achristensen@webkit.org>

            Fix warning when importing WebKit in Swift
            https://bugs.webkit.org/show_bug.cgi?id=199914
            <rdar://problem/52854930>

            Reviewed by Wenson Hsieh.

            * UIProcess/API/Cocoa/NSAttributedString.h:
            Declare NSAttributedString and update a swift name.
            This fix was proposed by Argyrios Kyrtzidis.

2019-07-24  Alan Coon  <alancoon@apple.com>

        Apply patch. rdar://problem/53483188

    Disable ENABLE_LAYOUT_FORMATTING_CONTEXT https://bugs.webkit.org/show_bug.cgi?id=200038 <rdar://problem/53457282>
    
    Reviewed by Zalan Bujtas.
    
    This feature is not complete. It is enabled for the trunk, but needs
    to be disabled in branches for shipping products.
    
    Source/JavaScriptCore:
    
    * Configurations/FeatureDefines.xcconfig:
    
    Source/WebCore:
    
    No new tests -- this change does not add any new functionality.
    
    * Configurations/FeatureDefines.xcconfig:
    
    Source/WebCore/PAL:
    
    * Configurations/FeatureDefines.xcconfig:
    
    Source/WebKit:
    
    * Configurations/FeatureDefines.xcconfig:
    
    Source/WebKitLegacy/mac:
    
    * Configurations/FeatureDefines.xcconfig:
    
    Tools:
    
    * TestWebKitAPI/Configurations/FeatureDefines.xcconfig:

    2019-07-23  Keith Rollin  <krollin@apple.com>

            Disable ENABLE_LAYOUT_FORMATTING_CONTEXT
            https://bugs.webkit.org/show_bug.cgi?id=200038
            <rdar://problem/53457282>

            Reviewed by Zalan Bujtas.

            This feature is not complete. It is enabled for the trunk, but needs
            to be disabled in branches for shipping products.

            * Configurations/FeatureDefines.xcconfig:

2019-07-24  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247746. rdar://problem/53483297

    [iOS] Tapping the search field on a search results page on zillow.com shows and immediately dismisses the keyboard
    https://bugs.webkit.org/show_bug.cgi?id=200044
    <rdar://problem/53103732>
    
    Reviewed by Wenson Hsieh.
    
    Source/WebCore:
    
    1. The keyboard gets dismissed as the result of scroll event.
    2. The (horizontal)scroll event is initiated by WebKit as we try to re-center the content.
    3. The content gets off-centered as the result of the newly constructed drop-down menu which slightly sticks out of the document to the right (layout overflows).
    
    It works with shipping version of iOS because _zoomToFocusRect operates on stale viewport information (see r244494 for the progression).
    This patch applies a site specific quirk to restore shipping behavior.
    
    * page/Quirks.cpp:
    (WebCore::Quirks::shouldAvoidScrollingWhenFocusedContentIsVisible const):
    * page/Quirks.h:
    
    Source/WebKit:
    
    * Shared/FocusedElementInformation.cpp:
    (WebKit::FocusedElementInformation::encode const):
    (WebKit::FocusedElementInformation::decode):
    * Shared/FocusedElementInformation.h:
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]):
    * UIProcess/ios/WKContentViewInteraction.h:
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _elementDidBlur]):
    (-[WKContentView _shouldAvoidScrollingWhenFocusedContentIsVisible]):
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::getFocusedElementInformation):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247746 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-23  Zalan Bujtas  <zalan@apple.com>

            [iOS] Tapping the search field on a search results page on zillow.com shows and immediately dismisses the keyboard
            https://bugs.webkit.org/show_bug.cgi?id=200044
            <rdar://problem/53103732>

            Reviewed by Wenson Hsieh.

            * Shared/FocusedElementInformation.cpp:
            (WebKit::FocusedElementInformation::encode const):
            (WebKit::FocusedElementInformation::decode):
            * Shared/FocusedElementInformation.h:
            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]):
            * UIProcess/ios/WKContentViewInteraction.h:
            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _elementDidBlur]):
            (-[WKContentView _shouldAvoidScrollingWhenFocusedContentIsVisible]):
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::getFocusedElementInformation):

2019-07-24  Alan Coon  <alancoon@apple.com>

        Revert r247700. rdar://problem/53456070

2019-07-19  Simon Fraser  <simon.fraser@apple.com>

        [iOS WK2] Allow scrolling interaction on frames and oveflow scroll even when the main frame is rubber-banding
        https://bugs.webkit.org/show_bug.cgi?id=199963
        rdar://problem/52897797

        Reviewed by Tim Horton.

        Adopt UIKit SPI to allow for scrolling of inner UIScrollViews when the outer one is still rubber-banding.

        * Platform/spi/ios/UIKitSPI.h:
        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _initializeWithConfiguration:]):
        * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm:
        (WebKit::ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren):

2019-07-23  Alan Coon  <alancoon@apple.com>

        Revert r247672. rdar://problem/53449739

2019-07-23  Alan Coon  <alancoon@apple.com>

        Revert r247673. rdar://problem/53449723

2019-07-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247701. rdar://problem/53449745

    Correct web audio-related crash in seed reports
    https://bugs.webkit.org/show_bug.cgi?id=200009
    <rdar://problem/51565203>
    
    Reviewed by Per Arne Vollan.
    
    Source/WebCore:
    
    Update the 'createMix' method to do proper return value checking so that
    we can clear the result of MTAudioProcessingTapCreate if the create operation
    failed.
    
    * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm:
    (WebCore::AudioSourceProviderAVFObjC::createMix):
    
    Source/WebKit:
    
    Revise the iOS sandbox to allow the WebContent process to communicate with
    the 'com.apple.coremedia.audioprocessingtap.xpc' service, which is needed by
    some types of WebAudio.
    
    * WebProcess/com.apple.WebKit.WebContent.sb.in:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247701 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-22  Brent Fulgham  <bfulgham@apple.com>

            Correct web audio-related crash in seed reports
            https://bugs.webkit.org/show_bug.cgi?id=200009
            <rdar://problem/51565203>

            Reviewed by Per Arne Vollan.

            Revise the iOS sandbox to allow the WebContent process to communicate with
            the 'com.apple.coremedia.audioprocessingtap.xpc' service, which is needed by
            some types of WebAudio.

            * WebProcess/com.apple.WebKit.WebContent.sb.in:

2019-07-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247700. rdar://problem/53456055

    WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari
    https://bugs.webkit.org/show_bug.cgi?id=200011
    <rdar://problem/53409457>
    
    Reviewed by Tim Horton.
    
    Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:)
    on the WKUIDelegate so that clients that got caught implementing the
    SPI before moving to the real API can still clean-up state. In other words,
    don't force a client that only implements that method to move completely
    to the new API.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (needsDeprecatedPreviewAPI):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247700 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-22  Dean Jackson  <dino@apple.com>

            WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari
            https://bugs.webkit.org/show_bug.cgi?id=200011
            <rdar://problem/53409457>

            Reviewed by Tim Horton.

            Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:)
            on the WKUIDelegate so that clients that got caught implementing the
            SPI before moving to the real API can still clean-up state. In other words,
            don't force a client that only implements that method to move completely
            to the new API.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (needsDeprecatedPreviewAPI):

2019-07-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247673. rdar://problem/53449723

    Speed up HashTable decoding by reserving capacity and avoiding rehashing
    https://bugs.webkit.org/show_bug.cgi?id=199982
    
    Reviewed by Saam Barati.
    
    Source/WebKit:
    
    Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for
    performance. I measured a ~35% improvement when decoding a very large
    HashMap of Strings (~160k entries) in the context of the
    StorageManager::GetValues IPC.
    
    * Platform/IPC/ArgumentCoders.h:
    * Shared/API/c/WKDictionary.cpp:
    (WKDictionaryCreate):
    
    Source/WTF:
    
    Introduce reserveInitialCapacity() on HashMap to reserve capacity on a
    HashMap and cut down on rehashing cost when possible.
    
    * wtf/HashMap.h:
    * wtf/HashTable.h:
    (WTF::HashTable::reserveInitialCapacity):
    
    * wtf/persistence/PersistentCoders.h:
    Use HashMap::reserveInitialCapacity() in the HashMap persistent decoder for
    performance.
    
    Tools:
    
    Add API test coverage.
    
    * TestWebKitAPI/Tests/WTF/HashMap.cpp:
    (TestWebKitAPI::TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247673 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-20  Chris Dumez  <cdumez@apple.com>

            Speed up HashTable decoding by reserving capacity and avoiding rehashing
            https://bugs.webkit.org/show_bug.cgi?id=199982

            Reviewed by Saam Barati.

            Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for
            performance. I measured a ~35% improvement when decoding a very large
            HashMap of Strings (~160k entries) in the context of the
            StorageManager::GetValues IPC.

            * Platform/IPC/ArgumentCoders.h:
            * Shared/API/c/WKDictionary.cpp:
            (WKDictionaryCreate):

2019-07-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247672. rdar://problem/53449739

    Micro-optimize HashMap & String IPC decoding
    https://bugs.webkit.org/show_bug.cgi?id=199967
    
    Reviewed by Geoffrey Garen.
    
    The legacy HashMap decoder (returning a boolean) was failing to WTFMove()
    the key & value when calling HashMap::add(). The modern decoder (returning
    an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder
    to call the modern one to reduce code duplication and to get this optimization.
    
    Also, encode HashMap::size() as a uint32_t instead of a uint64_t since
    HashMap::size() returns an 'unsigned int' type. Finally, update the modern
    decoder to WTFMove(hashMap) when returning. Because the function returns an
    Optional<HashMap> and not a HashMap, I do not believe we get return value
    optimization (RVO).
    
    Do similar changes to String IPC coders.
    
    * Platform/IPC/ArgumentCoders.cpp:
    (IPC::decodeStringText):
    (IPC::ArgumentCoder<String>::decode):
    * Platform/IPC/ArgumentCoders.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247672 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-20  Chris Dumez  <cdumez@apple.com>

            Micro-optimize HashMap & String IPC decoding
            https://bugs.webkit.org/show_bug.cgi?id=199967

            Reviewed by Geoffrey Garen.

            The legacy HashMap decoder (returning a boolean) was failing to WTFMove()
            the key & value when calling HashMap::add(). The modern decoder (returning
            an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder
            to call the modern one to reduce code duplication and to get this optimization.

            Also, encode HashMap::size() as a uint32_t instead of a uint64_t since
            HashMap::size() returns an 'unsigned int' type. Finally, update the modern
            decoder to WTFMove(hashMap) when returning. Because the function returns an
            Optional<HashMap> and not a HashMap, I do not believe we get return value
            optimization (RVO).

            Do similar changes to String IPC coders.

            * Platform/IPC/ArgumentCoders.cpp:
            (IPC::decodeStringText):
            (IPC::ArgumentCoder<String>::decode):
            * Platform/IPC/ArgumentCoders.h:

2019-07-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247658. rdar://problem/53449709

    Web Content process gets stuck suspended after navigating away from a system preview
    https://bugs.webkit.org/show_bug.cgi?id=199965
    <rdar://problem/53109004>
    
    Reviewed by Dean Jackson.
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _isBackground]):
    * UIProcess/ios/WKSystemPreviewView.h:
    * UIProcess/ios/WKSystemPreviewView.mm:
    (-[WKSystemPreviewView web_initWithFrame:webView:mimeType:]):
    (-[WKSystemPreviewView web_isBackground]):
    Apply the fix from r193481 to WKSystemPreviewView as well, having it
    become a WKApplicationStateTrackingView and plumbing that through
    to our is-background machinery.
    
    We really, really should instead have WKWebView itself be the application
    state tracking view, but that is a bigger change (and has some implications
    for full-screen video and whatnot).
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247658 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-19  Tim Horton  <timothy_horton@apple.com>

            Web Content process gets stuck suspended after navigating away from a system preview
            https://bugs.webkit.org/show_bug.cgi?id=199965
            <rdar://problem/53109004>

            Reviewed by Dean Jackson.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _isBackground]):
            * UIProcess/ios/WKSystemPreviewView.h:
            * UIProcess/ios/WKSystemPreviewView.mm:
            (-[WKSystemPreviewView web_initWithFrame:webView:mimeType:]):
            (-[WKSystemPreviewView web_isBackground]):
            Apply the fix from r193481 to WKSystemPreviewView as well, having it
            become a WKApplicationStateTrackingView and plumbing that through
            to our is-background machinery.

            We really, really should instead have WKWebView itself be the application
            state tracking view, but that is a bigger change (and has some implications
            for full-screen video and whatnot).

2019-07-23  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247652. rdar://problem/53423997

    Add a menu item to toggle between showing and hiding link previews
    https://bugs.webkit.org/show_bug.cgi?id=199940
    <rdar://problem/53032288>
    
    Reviewed by Beth Dakin.
    
    Source/WebCore:
    
    New strings for Show/Hide Link Previews.
    
    * en.lproj/Localizable.strings:
    
    Source/WebKit:
    
    Add a new _WKElementAction that toggles the display of link previews
    in context menus, and add it to the default set of actions we provide
    for links.
    
    When a UIAction is created from this new _WKElementAction type,
    it can be identified by WKElementActionTypeToggleShowLinkPreviewsIdentifier.
    This allows us to check a UIMenu provided by a delegate to make sure
    that they have provided the toggle menu item. If they haven't, we add it
    back.
    
    The preference for showing links is moved from kCFPreferencesAnyApplication
    to standard user defaults, so that it can be set no matter what the
    hosting application is.
    
    * UIProcess/API/Cocoa/_WKElementAction.h: New action type.
    * UIProcess/API/Cocoa/_WKElementAction.mm:
    (+[_WKElementAction _elementActionWithType:customTitle:assistant:]):
    (+[_WKElementAction imageForElementActionType:]): Use eye.fill for now.
    I'll need to check with HI to see if there is a more appropriate glyph.
    (elementActionTypeToUIActionIdentifier):
    (uiActionIdentifierToElementActionType):
    
    * UIProcess/ios/WKActionSheetAssistant.mm: Add the toggle action to
    the default set.
    (-[WKActionSheetAssistant defaultActionsForLinkSheet:]):
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _registerPreview]): No need to listen for CFPreferences
    notifications any more.
    (-[WKContentView _unregisterPreview]):
    (menuWithShowLinkPreviewAction): New method that adds the UIAction
    for toggling previews to a UIMenu if necessary.
    (-[WKContentView assignLegacyDataForContextMenuInteraction]):
    (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]):
    (-[WKContentView _showLinkPreviewsPreferenceChanged:]): Deleted.
    (titleForMenu): Deleted. URL text previews will be provided separately.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247652 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-19  Dean Jackson  <dino@apple.com>

            Add a menu item to toggle between showing and hiding link previews
            https://bugs.webkit.org/show_bug.cgi?id=199940
            <rdar://problem/53032288>

            Reviewed by Beth Dakin.

            Add a new _WKElementAction that toggles the display of link previews
            in context menus, and add it to the default set of actions we provide
            for links.

            When a UIAction is created from this new _WKElementAction type,
            it can be identified by WKElementActionTypeToggleShowLinkPreviewsIdentifier.
            This allows us to check a UIMenu provided by a delegate to make sure
            that they have provided the toggle menu item. If they haven't, we add it
            back.

            The preference for showing links is moved from kCFPreferencesAnyApplication
            to standard user defaults, so that it can be set no matter what the
            hosting application is.

            * UIProcess/API/Cocoa/_WKElementAction.h: New action type.
            * UIProcess/API/Cocoa/_WKElementAction.mm:
            (+[_WKElementAction _elementActionWithType:customTitle:assistant:]):
            (+[_WKElementAction imageForElementActionType:]): Use eye.fill for now.
            I'll need to check with HI to see if there is a more appropriate glyph.
            (elementActionTypeToUIActionIdentifier):
            (uiActionIdentifierToElementActionType):

            * UIProcess/ios/WKActionSheetAssistant.mm: Add the toggle action to
            the default set.
            (-[WKActionSheetAssistant defaultActionsForLinkSheet:]):

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _registerPreview]): No need to listen for CFPreferences
            notifications any more.
            (-[WKContentView _unregisterPreview]):
            (menuWithShowLinkPreviewAction): New method that adds the UIAction
            for toggling previews to a UIMenu if necessary.
            (-[WKContentView assignLegacyDataForContextMenuInteraction]):
            (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]):
            (-[WKContentView _showLinkPreviewsPreferenceChanged:]): Deleted.
            (titleForMenu): Deleted. URL text previews will be provided separately.

2019-07-18  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247565. rdar://problem/53279116

    Regression(r247486) Multiple Layout Tests in http/tests/cache/* are crashing on iOS Debug WK2
    https://bugs.webkit.org/show_bug.cgi?id=199892
    <rdar://problem/53230217>
    
    Reviewed by Geoffrey Garen.
    
    The StorageManager was unregistering itself as a WorkQueueMessageReceiver on a given IPC
    connection too early. As a result, we would sometimes receive a 'StorageManager:DestroyStorageMap'
    IPC in NetworkConnectionToWebProcess::didReceiveMessage() with nobody to process it, which would
    trigger an assertion. To address the issue, we stop unregistering the StorageManager as a
    WorkQueueMessageReceiver inside removeAllowedSessionStorageNamespaceConnection(). Instead, we
    let the logic inside processDidCloseConnection() take care of it once the connection closes.
    
    * NetworkProcess/WebStorage/StorageManager.cpp:
    (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection):
    (WebKit::StorageManager::processDidCloseConnection):
    * NetworkProcess/WebStorage/StorageManager.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247565 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-18  Chris Dumez  <cdumez@apple.com>

            Regression(r247486) Multiple Layout Tests in http/tests/cache/* are crashing on iOS Debug WK2
            https://bugs.webkit.org/show_bug.cgi?id=199892
            <rdar://problem/53230217>

            Reviewed by Geoffrey Garen.

            The StorageManager was unregistering itself as a WorkQueueMessageReceiver on a given IPC
            connection too early. As a result, we would sometimes receive a 'StorageManager:DestroyStorageMap'
            IPC in NetworkConnectionToWebProcess::didReceiveMessage() with nobody to process it, which would
            trigger an assertion. To address the issue, we stop unregistering the StorageManager as a
            WorkQueueMessageReceiver inside removeAllowedSessionStorageNamespaceConnection(). Instead, we
            let the logic inside processDidCloseConnection() take care of it once the connection closes.

            * NetworkProcess/WebStorage/StorageManager.cpp:
            (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection):
            (WebKit::StorageManager::processDidCloseConnection):
            * NetworkProcess/WebStorage/StorageManager.h:

2019-07-18  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247552. rdar://problem/53279120

    Set WordIsNearTap flag, was not being set at all before
    https://bugs.webkit.org/show_bug.cgi?id=199880
    
    Reviewed by Wenson Hsieh.
    
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::selectWithGesture):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247552 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-17  Megan Gardner  <megan_gardner@apple.com>

            Set WordIsNearTap flag, was not being set at all before
            https://bugs.webkit.org/show_bug.cgi?id=199880

            Reviewed by Wenson Hsieh.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::selectWithGesture):

2019-07-18  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247557. rdar://problem/53254407

    [macCatalyst] Unable to interact with YouTube video while it's playing
    https://bugs.webkit.org/show_bug.cgi?id=199893
    <rdar://problem/51871151>
    
    Reviewed by Simon Fraser.
    
    * Platform/spi/ios/UIKitSPI.h:
    * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
    (-[WKRemoteView initWithFrame:contextID:]):
    (-[WKUIRemoteView initWithFrame:pid:contextID:]):
    Disable remote context hit-testing for WKUIRemoteView just like we
    already do for WKRemoteView.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247557 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-17  Tim Horton  <timothy_horton@apple.com>

            [macCatalyst] Unable to interact with YouTube video while it's playing
            https://bugs.webkit.org/show_bug.cgi?id=199893
            <rdar://problem/51871151>

            Reviewed by Simon Fraser.

            * Platform/spi/ios/UIKitSPI.h:
            * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
            (-[WKRemoteView initWithFrame:contextID:]):
            (-[WKUIRemoteView initWithFrame:pid:contextID:]):
            Disable remote context hit-testing for WKUIRemoteView just like we
            already do for WKRemoteView.

2019-07-18  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247555. rdar://problem/53254411

    Prewarm local storage in the NetworkProcess to reduce WebContent process hangs
    https://bugs.webkit.org/show_bug.cgi?id=199879
    <rdar://problem/53217757>
    
    Reviewed by Ryosuke Niwa.
    
    Source/WebCore:
    
    When JS accesses window.localStorage for the first time, we end up doing a
    synchronous IPC to the network process to pull in all items in the local
    storage for the origin. If the network process does not have this data in
    memory, it has to read it from a database on disk, which may take a significant
    amount of time and hang the WebContent process during this time.
    
    To alleviate this problem, this patch introduces prewarming on the local storage
    in the network process when loading a given origin in the WebContent process.
    This way, in most cases, when the JS accesses window.localStorage for the first
    time, the synchronous IPC to the network process returns much faster (measured
    50-100ms for a very large database, down from 250-300ms), as it only needs to
    IPC the data over, without the need to fetch it from disk.
    
    As a safety net to avoid excessive prewarming, we currently prewarm at most 5
    security origins per page load.
    
    * loader/DocumentLoader.cpp:
    (WebCore::DocumentLoader::commitData):
    * page/DOMWindow.cpp:
    (WebCore::DOMWindow::prewarmLocalStorageIfNecessary):
    * page/DOMWindow.h:
    * page/Frame.cpp:
    (WebCore::Frame::didPrewarmLocalStorage):
    (WebCore::Frame::mayPrewarmLocalStorage const):
    * page/Frame.h:
    * storage/Storage.cpp:
    (WebCore::Storage::prewarm):
    * storage/Storage.h:
    * storage/StorageArea.h:
    (WebCore::StorageArea::prewarm):
    
    Source/WebKit:
    
    * NetworkProcess/WebStorage/StorageManager.cpp:
    (WebKit::StorageManager::prewarm):
    (WebKit::StorageManager::getValues):
    * NetworkProcess/WebStorage/StorageManager.h:
    * NetworkProcess/WebStorage/StorageManager.messages.in:
    * WebProcess/WebStorage/StorageAreaImpl.cpp:
    (WebKit::StorageAreaImpl::prewarm):
    * WebProcess/WebStorage/StorageAreaImpl.h:
    * WebProcess/WebStorage/StorageAreaMap.cpp:
    (WebKit::StorageAreaMap::loadValuesIfNeeded):
    (WebKit::StorageAreaMap::prewarm):
    * WebProcess/WebStorage/StorageAreaMap.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247555 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-17  Chris Dumez  <cdumez@apple.com>

            Prewarm local storage in the NetworkProcess to reduce WebContent process hangs
            https://bugs.webkit.org/show_bug.cgi?id=199879
            <rdar://problem/53217757>

            Reviewed by Ryosuke Niwa.

            * NetworkProcess/WebStorage/StorageManager.cpp:
            (WebKit::StorageManager::prewarm):
            (WebKit::StorageManager::getValues):
            * NetworkProcess/WebStorage/StorageManager.h:
            * NetworkProcess/WebStorage/StorageManager.messages.in:
            * WebProcess/WebStorage/StorageAreaImpl.cpp:
            (WebKit::StorageAreaImpl::prewarm):
            * WebProcess/WebStorage/StorageAreaImpl.h:
            * WebProcess/WebStorage/StorageAreaMap.cpp:
            (WebKit::StorageAreaMap::loadValuesIfNeeded):
            (WebKit::StorageAreaMap::prewarm):
            * WebProcess/WebStorage/StorageAreaMap.h:

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247559. rdar://problem/53230035

    Early Out of positionInfomation check if possible
    https://bugs.webkit.org/show_bug.cgi?id=199885
    <rdar://problem/53229413>
    
    This is an early-out check that happens after most of the work is done.
    Move it to happen before we make all these calls, if in the end, we will not use the information.
    
    Reviewed by Tim Horton.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247559 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-17  Megan Gardner  <megan_gardner@apple.com>

            Early Out of positionInfomation check if possible
            https://bugs.webkit.org/show_bug.cgi?id=199885
            <rdar://problem/53229413>

            This is an early-out check that happens after most of the work is done.
            Move it to happen before we make all these calls, if in the end, we will not use the information.

            Reviewed by Tim Horton.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]):

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247547. rdar://problem/53230043

    Provide a NSURL cateogry to tell AppSSO Kerberos URLs
    https://bugs.webkit.org/show_bug.cgi?id=199887
    <rdar://problem/52323161>
    
    Reviewed by Brent Fulgham.
    
    * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.h:
    * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.mm:
    (+[NSURL _web_willPerformSOKerberosAuthorizationWithURL:]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247547 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-17  Jiewen Tan  <jiewen_tan@apple.com>

            Provide a NSURL cateogry to tell AppSSO Kerberos URLs
            https://bugs.webkit.org/show_bug.cgi?id=199887
            <rdar://problem/52323161>

            Reviewed by Brent Fulgham.

            * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.h:
            * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.mm:
            (+[NSURL _web_willPerformSOKerberosAuthorizationWithURL:]):

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247530. rdar://problem/53229569

    Typing into a cell in a Google Sheet lags behind by one character
    https://bugs.webkit.org/show_bug.cgi?id=199587
    <rdar://problem/51616845>
    
    Reviewed by Brent Fulgham.
    
    Source/WebCore:
    
    Add a Google Sheets quirk. Put all DOM timers scheduled from keydown and keypress event listeners
    into a holding tank. The timers continue to tick, but are barred from executing their action until
    the next text insertion or deletion or 32 ms (on device) have elapsed, whichever is sooner. We only
    allocate a holding tank once per document, only if the quirk is active, and this allocation is done
    when the document schedules a timer on keydown or keypress. The holding tank lives for the lifetime
    of the document.
    
    The story behind the quirk:
    
    On keypress Google Sheets schedules timers and expects that a DOM update will occur (i.e. text
    will be inserted or deleted) within the same event loop iteration as the dispatched keypress. The
    UI Events spec. [1] makes no such guarantee of when a DOM update must occur in relation to the keypress
    event. It could happen in the same event loop iteration as the key press (as Google expects), the
    next iteration, 500ms later, 2 minutes later, etc. What the spec does guarantee is that by the time
    a DOM input event is dispatched that the DOM will be updated. And this is the solution to the problem
    Google Sheets is trying to solve, but is doing so using pre-IE 9 technology (though similar
    functionality was available via onpropertychange in IE < 9).
    
    See also <https://github.com/w3c/uievents/issues/238>, which is tracking a spec. text update for
    this quirk.
    
    Test: fast/events/ios/dom-update-on-keydown-quirk.html
    
    [1] <https://w3c.github.io/uievents/> (Editor's Draft, 14 October 2018)
    
    * SourcesCocoa.txt:
    * WebCore.xcodeproj/project.pbxproj:
    Add some files to the project.
    
    * dom/Document.cpp:
    (WebCore::Document::domTimerHoldingTank): Added.
    * dom/Document.h:
    (WebCore::Document::domTimerHoldingTankIfExists): Added.
    
    * page/DOMTimer.cpp:
    (WebCore::DOMTimer::install): Put the newly instantiated timer into the holding tank.
    (WebCore::DOMTimer::removeById): Remove the timer from the holding tank.
    (WebCore::DOMTimer::fired): Check if the timer is in the holding tank. If it is and it is a one-
    shot timer then schedule it for the next event loop iteration. If it's a repeating timer just
    let it continue ticking. Otherwise, do what we no now and execute the timer's action. The reason
    we do not suspend timers in the holding tank is because:
        1. Far out timers (Google Sheets registers timers as far out as 5 minutes!) are not penalized.
        Though smart supension logic could avoid this. See (3).
    
        2. Empirical observations indicate that the keyboard will perform the insertion or deletion
        reasonably quickly (not the same event loop iteration as the keydown, but within two iterations out).
        So, the timers in the holding tank are short-lived.
    
        3. Simplifies the code. There is no need to keep additional bookkeeping to track multiple timer
        suspension reasons (timers currently can only have one suspension reason) or alternatively defer
        scheduling a timer until a later time and computing a new "fair" firing time when scheduled.
    * page/EventHandler.cpp:
    (WebCore::EventHandler::internalKeyEvent): Place a token on the stack to put all DOM timers
    scheduled on keydown and keypress into the holding tank if the quirk is enabled.
    * page/Quirks.cpp:
    (WebCore::Quirks::needsDeferKeyDownAndKeyPressTimersUntilNextEditingCommand const): Added.
    * page/Quirks.h:
    * page/Settings.yaml: Added setting so that this quirk can be enabled from a layout test. This setting
    also lets us enable the quirk for all sites or for certain third-party apps if desired.
    * page/ios/DOMTimerHoldingTank.cpp: Added.
    (WebCore::DOMTimerHoldingTank::DOMTimerHoldingTank):
    (WebCore::DOMTimerHoldingTank::add):
    (WebCore::DOMTimerHoldingTank::remove):
    (WebCore::DOMTimerHoldingTank::contains):
    (WebCore::DOMTimerHoldingTank::removeAll):
    (WebCore::DOMTimerHoldingTank::stopExceededMaximumHoldTimer):
    * page/ios/DOMTimerHoldingTank.h: Added.
    (WebCore::DeferDOMTimersForScope::DeferDOMTimersForScope):
    (WebCore::DeferDOMTimersForScope::~DeferDOMTimersForScope):
    (WebCore::DeferDOMTimersForScope::isDeferring):
    
    Source/WebKit:
    
    Remove all timers from the holding tank on text insertion or deletion (represented as an
    editing command). Timers that were in the holding tank never stopped ticking and will now
    be able to execute their action.
    
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::executeEditingCommand):
    (WebKit::WebPage::insertTextAsync):
    (WebKit::WebPage::setCompositionAsync):
    (WebKit::WebPage::confirmCompositionAsync):
    Call platformWillPerformEditingCommand().
    
    * WebProcess/WebPage/WebPage.h:
    (WebKit::WebPage::platformWillPerformEditingCommand): Added.
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::platformWillPerformEditingCommand): Remove all the timers from the holding
    tank if we have a holding tank.
    
    LayoutTests:
    
    Add a test that enables the quirk and ensures that the DOM is up-to-date on expiration of a
    zero timer scheduled from keydown, keypress, keyup, and input.
    
    * fast/events/ios/dom-update-on-keydown-quirk-expected.txt: Added.
    * fast/events/ios/dom-update-on-keydown-quirk.html: Added.
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247530 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-17  Daniel Bates  <dabates@apple.com>

            Typing into a cell in a Google Sheet lags behind by one character
            https://bugs.webkit.org/show_bug.cgi?id=199587
            <rdar://problem/51616845>

            Reviewed by Brent Fulgham.

            Remove all timers from the holding tank on text insertion or deletion (represented as an
            editing command). Timers that were in the holding tank never stopped ticking and will now
            be able to execute their action.

            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::executeEditingCommand):
            (WebKit::WebPage::insertTextAsync):
            (WebKit::WebPage::setCompositionAsync):
            (WebKit::WebPage::confirmCompositionAsync):
            Call platformWillPerformEditingCommand().

            * WebProcess/WebPage/WebPage.h:
            (WebKit::WebPage::platformWillPerformEditingCommand): Added.
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::platformWillPerformEditingCommand): Remove all the timers from the holding
            tank if we have a holding tank.

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247524. rdar://problem/53229635

    [iOS] Option + Up or Down Arrow key doesn’t move cursor past paragraph boundaries in WebKit2
    https://bugs.webkit.org/show_bug.cgi?id=199851
    
    Reviewed by Wenson Hsieh.
    
    Source/WebKit:
    
    The bug was caused by the difference in the way AppKit and UIKit responds to Option + Up / Down.
    
    On macOS, AppKit sends moveForward before sending moveToStartOfParagraph and moveBackward
    before sending moveToEndOfParagraph. As a result, when Option + Down is pressed when we are at
    the end of a line, we would first move to the beginning of the next line (i.e. after the line break)
    before moving or extending selection with the paragraph boundary granurality.
    
    On iOS, UIKit only calls _moveToStartOfParagraph without moving forward by a character. As a result,
    moving forward by the paragraph boundary granurality immediately stops when we're starting at the
    end of a line when Option + Down is pressed. Option + Up case is similar.
    
    Fix the bug on iOS by emulating what happens on macOS. Namely, move the selection forward or backward
    by the character granurality before moving by the paragraph boundary granurality.
    
    * UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _moveToStartOfParagraph:withHistory:]):
    (-[WKContentView _moveToEndOfParagraph:withHistory:]):
    
    Tools:
    
    Added a regression test for iOS. Unfortunately, event sender, etc... doesn't work because
    this code is getting directly triggered from UIKeyboard's code.
    
    * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.h: Added.
    * TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.mm: Added.
    * TestWebKitAPI/ios/UIKitSPI.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247524 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-17  Ryosuke Niwa  <rniwa@webkit.org>

            [iOS] Option + Up or Down Arrow key doesn’t move cursor past paragraph boundaries in WebKit2
            https://bugs.webkit.org/show_bug.cgi?id=199851

            Reviewed by Wenson Hsieh.

            The bug was caused by the difference in the way AppKit and UIKit responds to Option + Up / Down.

            On macOS, AppKit sends moveForward before sending moveToStartOfParagraph and moveBackward
            before sending moveToEndOfParagraph. As a result, when Option + Down is pressed when we are at
            the end of a line, we would first move to the beginning of the next line (i.e. after the line break)
            before moving or extending selection with the paragraph boundary granurality.

            On iOS, UIKit only calls _moveToStartOfParagraph without moving forward by a character. As a result,
            moving forward by the paragraph boundary granurality immediately stops when we're starting at the
            end of a line when Option + Down is pressed. Option + Up case is similar.

            Fix the bug on iOS by emulating what happens on macOS. Namely, move the selection forward or backward
            by the character granurality before moving by the paragraph boundary granurality.

            * UIProcess/ios/WKContentViewInteraction.mm:
            (-[WKContentView _moveToStartOfParagraph:withHistory:]):
            (-[WKContentView _moveToEndOfParagraph:withHistory:]):

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247502. rdar://problem/53229564

    REGRESSION: fast/events/watchos/double-tap-to-zoom* tests crashing in com.apple.WebKit: -[WKContentView(WKInteraction) _singleTapDidReset:]
    https://bugs.webkit.org/show_bug.cgi?id=199840
    <rdar://problem/52856531>
    
    Patch by Antoine Quint <graouts@apple.com> on 2019-07-16
    Reviewed by Wenson Hsieh.
    
    Source/WebCore:
    
    Fix a build error that occured when building for the watchOS Simulator in the debug configuration.
    
    * rendering/RenderLayerCompositor.cpp:
    (WebCore::RenderLayerCompositor::updateScrollingNodeForScrollingProxyRole):
    
    Source/WebKit:
    
    We need to ensure the NSNumber used for -[WKSyntheticTapGestureRecognizer lastActiveTouchIdentifier] is retained. This innocent change required
    the use of RetainPtr<>, which required the move to an Objective-C++ file, which lead to a change in the order files are unified, which lead to
    build errors, which leads to a much bigger patch than just the source change necessary to fix the crash.
    
    * SourcesCocoa.txt:
    * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm: Renamed from Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.m.
    * UIProcess/ios/forms/WKFormPeripheralBase.h:
    * UIProcess/ios/forms/WKFormPeripheralBase.mm:
    * WebKit.xcodeproj/project.pbxproj:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247502 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-16  Antoine Quint  <graouts@apple.com>

            REGRESSION: fast/events/watchos/double-tap-to-zoom* tests crashing in com.apple.WebKit: -[WKContentView(WKInteraction) _singleTapDidReset:]
            https://bugs.webkit.org/show_bug.cgi?id=199840
            <rdar://problem/52856531>

            Reviewed by Wenson Hsieh.

            We need to ensure the NSNumber used for -[WKSyntheticTapGestureRecognizer lastActiveTouchIdentifier] is retained. This innocent change required
            the use of RetainPtr<>, which required the move to an Objective-C++ file, which lead to a change in the order files are unified, which lead to
            build errors, which leads to a much bigger patch than just the source change necessary to fix the crash.

            * SourcesCocoa.txt:
            * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm: Renamed from Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.m.
            * UIProcess/ios/forms/WKFormPeripheralBase.h:
            * UIProcess/ios/forms/WKFormPeripheralBase.mm:
            * WebKit.xcodeproj/project.pbxproj:

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247494. rdar://problem/53229554

    [macCatalyst] Do not include WebKitLegacy.h in WebKit.h
    https://bugs.webkit.org/show_bug.cgi?id=199833
    <rdar://problem/53036744>
    
    Reviewed by Tim Horton.
    
    * Shared/API/Cocoa/WebKit.h:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247494 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-16  Andy Estes  <aestes@apple.com>

            [macCatalyst] Do not include WebKitLegacy.h in WebKit.h
            https://bugs.webkit.org/show_bug.cgi?id=199833
            <rdar://problem/53036744>

            Reviewed by Tim Horton.

            * Shared/API/Cocoa/WebKit.h:

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247490. rdar://problem/53229559

    NSTextFinder holes don't scroll with the page
    https://bugs.webkit.org/show_bug.cgi?id=199815
    <rdar://problem/52280514>
    
    Reviewed by Simon Fraser.
    
    Source/WebCore:
    
    * rendering/ScrollAlignment.h:
    
    Source/WebKit:
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _usePlatformFindUI]):
    (-[WKWebView _setUsePlatformFindUI:]):
    (-[WKWebView _ensureTextFinderClient]):
    Add a bit so that clients can choose whether they want our find UI,
    which respects scrolling, or the system find UI, which works when
    doing multi-document searches. Right now you can't have both.
    
    (-[WKWebView scrollFindMatchToVisible:]):
    Implement and plumb scrollFindMatchToVisible.
    
    * UIProcess/API/Cocoa/WKWebViewPrivate.h:
    * UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::indicateFindMatch):
    * UIProcess/WebPageProxy.h:
    * WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::indicateFindMatch):
    * WebProcess/WebPage/WebPage.h:
    * WebProcess/WebPage/WebPage.messages.in:
    Plumb indicateFindMatch to FindController.
    
    * UIProcess/mac/WKTextFinderClient.h:
    * UIProcess/mac/WKTextFinderClient.mm:
    (-[WKTextFinderClient initWithPage:view:usePlatformFindUI:]):
    Store whether or not we are using the platform find UI.
    
    (-[WKTextFinderClient findMatchesForString:relativeToMatch:findOptions:maxResults:resultCollector:]):
    If using WebKit find UI, turn on our UI in the options passed to findString[Matches].
    
    (-[WKTextFinderClient scrollFindMatchToVisible:]):
    If using WebKit find UI, when the platform tells us to reveal a find match, indicate it.
    
    (-[WKTextFinderClient didFindStringMatchesWithRects:didWrapAround:]):
    If using WebKit find UI, lie to the platform and return no rects so that it doesn't paint a yellow rectangle.
    
    (-[WKTextFinderClient getImageForMatchResult:completionHandler:]):
    If using WebKit find UI, lie to the platform and return no image so that it doesn't paint a yellow rectangle.
    
    (-[WKTextFinderClient initWithPage:view:]): Deleted.
    
    * WebProcess/WebPage/FindController.cpp:
    (WebKit::FindController::updateFindUIAfterPageScroll):
    Make it possible to use our find UI with 'findStringMatches'; since the platform
    find infrastrucutre depends on knowing about all matches up front, we need
    to use 'findStringMatches' instead of 'findString', but we had never combined
    that with our UI. Don't throw away the other matches when we indicate one, and
    don't send DidFindString in the case we are coming from 'findStringMatches'.
    This all needs a bit of cleanup in the future.
    
    (WebKit::FindController::findString):
    Tell updateFindUIAfterPageScroll that we are 'findString' so that it uses its normal behavior.
    
    (WebKit::FindController::findStringMatches):
    Tell updateFindUIAfterPageScroll that we are 'findStringMatches' so that it uses the adjusted behavior.
    
    (WebKit::FindController::indicateFindMatch):
    Add 'indicateFindMatch', which both selects the match and moves the indicator there.
    
    * WebProcess/WebPage/FindController.h:
    
    Tools:
    
    * MiniBrowser/mac/WK2BrowserWindowController.m:
    (-[MiniBrowserNSTextFinder performAction:]):
    (-[WK2BrowserWindowController awakeFromNib]):
    Adopt the WebKit UI in MiniBrowser. Also, override NSTextFinder's
    -performAction: so that we can intercept the close action and
    hide our own find UI, since there is no delegate for that action yet.
    
    * TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
    (TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247490 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-16  Tim Horton  <timothy_horton@apple.com>

            NSTextFinder holes don't scroll with the page
            https://bugs.webkit.org/show_bug.cgi?id=199815
            <rdar://problem/52280514>

            Reviewed by Simon Fraser.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _usePlatformFindUI]):
            (-[WKWebView _setUsePlatformFindUI:]):
            (-[WKWebView _ensureTextFinderClient]):
            Add a bit so that clients can choose whether they want our find UI,
            which respects scrolling, or the system find UI, which works when
            doing multi-document searches. Right now you can't have both.

            (-[WKWebView scrollFindMatchToVisible:]):
            Implement and plumb scrollFindMatchToVisible.

            * UIProcess/API/Cocoa/WKWebViewPrivate.h:
            * UIProcess/WebPageProxy.cpp:
            (WebKit::WebPageProxy::indicateFindMatch):
            * UIProcess/WebPageProxy.h:
            * WebProcess/WebPage/WebPage.cpp:
            (WebKit::WebPage::indicateFindMatch):
            * WebProcess/WebPage/WebPage.h:
            * WebProcess/WebPage/WebPage.messages.in:
            Plumb indicateFindMatch to FindController.

            * UIProcess/mac/WKTextFinderClient.h:
            * UIProcess/mac/WKTextFinderClient.mm:
            (-[WKTextFinderClient initWithPage:view:usePlatformFindUI:]):
            Store whether or not we are using the platform find UI.

            (-[WKTextFinderClient findMatchesForString:relativeToMatch:findOptions:maxResults:resultCollector:]):
            If using WebKit find UI, turn on our UI in the options passed to findString[Matches].

            (-[WKTextFinderClient scrollFindMatchToVisible:]):
            If using WebKit find UI, when the platform tells us to reveal a find match, indicate it.

            (-[WKTextFinderClient didFindStringMatchesWithRects:didWrapAround:]):
            If using WebKit find UI, lie to the platform and return no rects so that it doesn't paint a yellow rectangle.

            (-[WKTextFinderClient getImageForMatchResult:completionHandler:]):
            If using WebKit find UI, lie to the platform and return no image so that it doesn't paint a yellow rectangle.

            (-[WKTextFinderClient initWithPage:view:]): Deleted.

            * WebProcess/WebPage/FindController.cpp:
            (WebKit::FindController::updateFindUIAfterPageScroll):
            Make it possible to use our find UI with 'findStringMatches'; since the platform
            find infrastrucutre depends on knowing about all matches up front, we need
            to use 'findStringMatches' instead of 'findString', but we had never combined
            that with our UI. Don't throw away the other matches when we indicate one, and
            don't send DidFindString in the case we are coming from 'findStringMatches'.
            This all needs a bit of cleanup in the future.

            (WebKit::FindController::findString):
            Tell updateFindUIAfterPageScroll that we are 'findString' so that it uses its normal behavior.

            (WebKit::FindController::findStringMatches):
            Tell updateFindUIAfterPageScroll that we are 'findStringMatches' so that it uses the adjusted behavior.

            (WebKit::FindController::indicateFindMatch):
            Add 'indicateFindMatch', which both selects the match and moves the indicator there.

            * WebProcess/WebPage/FindController.h:

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247486. rdar://problem/53229738

    Speed up StorageManager::getValues()
    https://bugs.webkit.org/show_bug.cgi?id=199812
    
    Reviewed by Alex Christensen.
    
    Source/WebCore:
    
    * storage/StorageMap.cpp:
    (WebCore::StorageMap::importItems):
    * storage/StorageMap.h:
    
    Source/WebKit:
    
    Made the following performance improvements:
    - Made StorageManager a WorkQueueMessageReceiver again (like it was before it
      got moved from the UIProcess to the Network process). This avoids a lot of
      thread hopping (IPC thread -> Main thread -> StorageManagerThread -> Main Thread)
      and a lot of isolatedCopying of the strings.
    - Move values around when possible to avoid copying.
    - Add fast path to StorageMap::importItems() for when the StorageMap is
      empty when importing (15ms -> 2.5ms).
    
    * NetworkProcess/NetworkConnectionToWebProcess.cpp:
    (WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
    (WebKit::NetworkConnectionToWebProcess::didReceiveSyncMessage):
    * NetworkProcess/WebStorage/LocalStorageDatabase.cpp:
    (WebKit::LocalStorageDatabase::importItems):
    * NetworkProcess/WebStorage/StorageManager.cpp:
    (WebKit::StorageManager::addAllowedSessionStorageNamespaceConnection):
    (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection):
    (WebKit::StorageManager::processDidCloseConnection):
    (WebKit::StorageManager::createLocalStorageMap):
    (WebKit::StorageManager::createTransientLocalStorageMap):
    (WebKit::StorageManager::createSessionStorageMap):
    (WebKit::StorageManager::destroyStorageMap):
    (WebKit::StorageManager::getValues):
    (WebKit::StorageManager::setItem):
    (WebKit::StorageManager::setItems):
    (WebKit::StorageManager::removeItem):
    (WebKit::StorageManager::clear):
    * NetworkProcess/WebStorage/StorageManager.h:
    
    * Platform/IPC/Connection.cpp:
    (IPC::Connection::addWorkQueueMessageReceiver):
    (IPC::Connection::removeWorkQueueMessageReceiver):
    (IPC::Connection::processIncomingMessage):
    (IPC::Connection::dispatchMessage):
    (IPC::Connection::dispatchMessageToWorkQueueReceiver):
    * Platform/IPC/Connection.h:
    * WebProcess/WebStorage/StorageAreaMap.cpp:
    (WebKit::StorageAreaMap::loadValuesIfNeeded):
    Messages to WorkQueueMessageReceivers are normally dispatched from the IPC WorkQueue. However, there is a race if
    a client (here StorageManager) adds itself as a WorkQueueMessageReceiver as a result of receiving an IPC message
    on the main thread (here NetworkConnectionToWebProcess::WebPageWasAdded).
    The message might have already been dispatched from the IPC WorkQueue to the main thread by the time the
    client registers itself as a WorkQueueMessageReceiver. To address this, we check again for messages receivers
    once the message arrives on the main thread.
    
    Source/WebKitLegacy:
    
    * Storage/StorageAreaImpl.cpp:
    (WebKit::StorageAreaImpl::importItems):
    * Storage/StorageAreaImpl.h:
    * Storage/StorageAreaSync.cpp:
    (WebKit::StorageAreaSync::performImport):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247486 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-16  Chris Dumez  <cdumez@apple.com>

            Speed up StorageManager::getValues()
            https://bugs.webkit.org/show_bug.cgi?id=199812

            Reviewed by Alex Christensen.

            Made the following performance improvements:
            - Made StorageManager a WorkQueueMessageReceiver again (like it was before it
              got moved from the UIProcess to the Network process). This avoids a lot of
              thread hopping (IPC thread -> Main thread -> StorageManagerThread -> Main Thread)
              and a lot of isolatedCopying of the strings.
            - Move values around when possible to avoid copying.
            - Add fast path to StorageMap::importItems() for when the StorageMap is
              empty when importing (15ms -> 2.5ms).

            * NetworkProcess/NetworkConnectionToWebProcess.cpp:
            (WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
            (WebKit::NetworkConnectionToWebProcess::didReceiveSyncMessage):
            * NetworkProcess/WebStorage/LocalStorageDatabase.cpp:
            (WebKit::LocalStorageDatabase::importItems):
            * NetworkProcess/WebStorage/StorageManager.cpp:
            (WebKit::StorageManager::addAllowedSessionStorageNamespaceConnection):
            (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection):
            (WebKit::StorageManager::processDidCloseConnection):
            (WebKit::StorageManager::createLocalStorageMap):
            (WebKit::StorageManager::createTransientLocalStorageMap):
            (WebKit::StorageManager::createSessionStorageMap):
            (WebKit::StorageManager::destroyStorageMap):
            (WebKit::StorageManager::getValues):
            (WebKit::StorageManager::setItem):
            (WebKit::StorageManager::setItems):
            (WebKit::StorageManager::removeItem):
            (WebKit::StorageManager::clear):
            * NetworkProcess/WebStorage/StorageManager.h:

            * Platform/IPC/Connection.cpp:
            (IPC::Connection::addWorkQueueMessageReceiver):
            (IPC::Connection::removeWorkQueueMessageReceiver):
            (IPC::Connection::processIncomingMessage):
            (IPC::Connection::dispatchMessage):
            (IPC::Connection::dispatchMessageToWorkQueueReceiver):
            * Platform/IPC/Connection.h:
            * WebProcess/WebStorage/StorageAreaMap.cpp:
            (WebKit::StorageAreaMap::loadValuesIfNeeded):
            Messages to WorkQueueMessageReceivers are normally dispatched from the IPC WorkQueue. However, there is a race if
            a client (here StorageManager) adds itself as a WorkQueueMessageReceiver as a result of receiving an IPC message
            on the main thread (here NetworkConnectionToWebProcess::WebPageWasAdded).
            The message might have already been dispatched from the IPC WorkQueue to the main thread by the time the
            client registers itself as a WorkQueueMessageReceiver. To address this, we check again for messages receivers
            once the message arrives on the main thread.

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247483. rdar://problem/53229618

    [ContentChangeObserver] Cancel ongoing content observation when tap is failed/cancelled
    https://bugs.webkit.org/show_bug.cgi?id=199828
    <rdar://problem/53152696>
    
    Reviewed by Wenson Hsieh.
    
    Source/WebCore:
    
    This patch ensures that we stop the content observation (initiated by touch start) when the tap
    is cancelled/failed.
    
    Not testable.
    
    * page/ios/ContentChangeObserver.cpp:
    (WebCore::ContentChangeObserver::didCancelPotentialTap):
    * page/ios/ContentChangeObserver.h:
    
    Source/WebKit:
    
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::commitPotentialTapFailed):
    (WebKit::WebPage::cancelPotentialTap):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247483 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-16  Zalan Bujtas  <zalan@apple.com>

            [ContentChangeObserver] Cancel ongoing content observation when tap is failed/cancelled
            https://bugs.webkit.org/show_bug.cgi?id=199828
            <rdar://problem/53152696>

            Reviewed by Wenson Hsieh.

            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::commitPotentialTapFailed):
            (WebKit::WebPage::cancelPotentialTap):

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247470. rdar://problem/53229634

    outlook.live.com has odd viewport with edge gap
    https://bugs.webkit.org/show_bug.cgi?id=199822
    <rdar://problem/53029072>
    
    Reviewed by Wenson Hsieh.
    
    Source/WebCore:
    
    r244944 introduced a viewport width quirk because at certain screen size outlook.live.com's flex setup produced a slighly broken layout.
    We don't seem to need this quirk anymore (composed column's min-width is removed.)
    
    * page/Quirks.cpp:
    (WebCore::Quirks::shouldIgnoreShrinkToFitContent const): Deleted.
    (WebCore::Quirks::overriddenViewLayoutWidth const): Deleted.
    * page/Quirks.h:
    
    Source/WebKit:
    
    * WebProcess/WebPage/WebPage.h:
    * WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::setViewportConfigurationViewLayoutSize):
    (WebKit::WebPage::dynamicViewportSizeUpdate):
    (WebKit::WebPage::resetViewportDefaultConfiguration):
    (WebKit::WebPage::immediatelyShrinkToFitContent):
    (WebKit::WebPage::viewLayoutSizeAdjustedForQuirks): Deleted.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247470 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-15  Zalan Bujtas  <zalan@apple.com>

            outlook.live.com has odd viewport with edge gap
            https://bugs.webkit.org/show_bug.cgi?id=199822
            <rdar://problem/53029072>

            Reviewed by Wenson Hsieh.

            * WebProcess/WebPage/WebPage.h:
            * WebProcess/WebPage/ios/WebPageIOS.mm:
            (WebKit::WebPage::setViewportConfigurationViewLayoutSize):
            (WebKit::WebPage::dynamicViewportSizeUpdate):
            (WebKit::WebPage::resetViewportDefaultConfiguration):
            (WebKit::WebPage::immediatelyShrinkToFitContent):
            (WebKit::WebPage::viewLayoutSizeAdjustedForQuirks): Deleted.

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247461. rdar://problem/53229637

    Make WKURLSchemeTask thread safe.
    <rdar://problem/50471863> and https://bugs.webkit.org/show_bug.cgi?id=199764
    
    Reviewed by Alex Christensen.
    
    Source/WebKit:
    
    Punt most of the WKURLSchemeTask operations back to the main thread.
    Make accessing the NSURLRequest be thread safe with lock protection.
    
    * UIProcess/API/Cocoa/WKURLSchemeTask.mm:
    (getExceptionTypeFromMainRunLoop):
    (-[WKURLSchemeTaskImpl dealloc]):
    (-[WKURLSchemeTaskImpl request]):
    (-[WKURLSchemeTaskImpl _requestOnlyIfCached]):
    (-[WKURLSchemeTaskImpl didReceiveResponse:]):
    (-[WKURLSchemeTaskImpl didReceiveData:]):
    (-[WKURLSchemeTaskImpl didFinish]):
    (-[WKURLSchemeTaskImpl didFailWithError:]):
    (-[WKURLSchemeTaskImpl _didPerformRedirection:newRequest:]):
    
    * UIProcess/WebURLSchemeTask.cpp:
    (WebKit::WebURLSchemeTask::WebURLSchemeTask):
    (WebKit::WebURLSchemeTask::~WebURLSchemeTask):
    (WebKit::WebURLSchemeTask::didPerformRedirection):
    (WebKit::WebURLSchemeTask::didReceiveResponse):
    (WebKit::WebURLSchemeTask::didReceiveData):
    (WebKit::WebURLSchemeTask::didComplete):
    (WebKit::WebURLSchemeTask::pageDestroyed):
    (WebKit::WebURLSchemeTask::stop):
    (WebKit::WebURLSchemeTask::nsRequest const):
    
    * UIProcess/WebURLSchemeTask.h:
    (WebKit::WebURLSchemeTask::identifier const):
    (WebKit::WebURLSchemeTask::pageID const):
    (WebKit::WebURLSchemeTask::process):
    (WebKit::WebURLSchemeTask::process const): Deleted.
    (WebKit::WebURLSchemeTask::request const): Deleted.
    
    Source/WTF:
    
    * wtf/MainThread.cpp:
    (WTF::callOnMainAndWait):
    (WTF::callOnMainRunLoopAndWait):
    (WTF::callOnMainThreadAndWait):
    * wtf/MainThread.h:
    
    Tools:
    
    * TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm:
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247461 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-15  Brady Eidson  <beidson@apple.com>

            Make WKURLSchemeTask thread safe.
            <rdar://problem/50471863> and https://bugs.webkit.org/show_bug.cgi?id=199764

            Reviewed by Alex Christensen.

            Punt most of the WKURLSchemeTask operations back to the main thread.
            Make accessing the NSURLRequest be thread safe with lock protection.

            * UIProcess/API/Cocoa/WKURLSchemeTask.mm:
            (getExceptionTypeFromMainRunLoop):
            (-[WKURLSchemeTaskImpl dealloc]):
            (-[WKURLSchemeTaskImpl request]):
            (-[WKURLSchemeTaskImpl _requestOnlyIfCached]):
            (-[WKURLSchemeTaskImpl didReceiveResponse:]):
            (-[WKURLSchemeTaskImpl didReceiveData:]):
            (-[WKURLSchemeTaskImpl didFinish]):
            (-[WKURLSchemeTaskImpl didFailWithError:]):
            (-[WKURLSchemeTaskImpl _didPerformRedirection:newRequest:]):

            * UIProcess/WebURLSchemeTask.cpp:
            (WebKit::WebURLSchemeTask::WebURLSchemeTask):
            (WebKit::WebURLSchemeTask::~WebURLSchemeTask):
            (WebKit::WebURLSchemeTask::didPerformRedirection):
            (WebKit::WebURLSchemeTask::didReceiveResponse):
            (WebKit::WebURLSchemeTask::didReceiveData):
            (WebKit::WebURLSchemeTask::didComplete):
            (WebKit::WebURLSchemeTask::pageDestroyed):
            (WebKit::WebURLSchemeTask::stop):
            (WebKit::WebURLSchemeTask::nsRequest const):

            * UIProcess/WebURLSchemeTask.h:
            (WebKit::WebURLSchemeTask::identifier const):
            (WebKit::WebURLSchemeTask::pageID const):
            (WebKit::WebURLSchemeTask::process):
            (WebKit::WebURLSchemeTask::process const): Deleted.
            (WebKit::WebURLSchemeTask::request const): Deleted.

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247460. rdar://problem/53229628

    Followup to r247439
    https://bugs.webkit.org/show_bug.cgi?id=199788
    <rdar://problem/52142570>
    
    Reviewed by Tim Horton.
    
    As it turns out, sending modern async completion-handler based IPC messages while processing incoming sync
    messages results in a debug assertion. Instead of migrating FontAtSelection to the new async IPC mechanism,
    restore the older CallbackID-based async IPC.
    
    * UIProcess/WebPageProxy.h:
    * UIProcess/WebPageProxy.messages.in:
    * UIProcess/mac/WebPageProxyMac.mm:
    (WebKit::WebPageProxy::fontAtSelection):
    (WebKit::WebPageProxy::fontAtSelectionCallback):
    * WebProcess/WebPage/WebPage.h:
    * WebProcess/WebPage/WebPage.messages.in:
    * WebProcess/WebPage/mac/WebPageMac.mm:
    (WebKit::WebPage::fontAtSelection):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247460 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-15  Wenson Hsieh  <wenson_hsieh@apple.com>

            Followup to r247439
            https://bugs.webkit.org/show_bug.cgi?id=199788
            <rdar://problem/52142570>

            Reviewed by Tim Horton.

            As it turns out, sending modern async completion-handler based IPC messages while processing incoming sync
            messages results in a debug assertion. Instead of migrating FontAtSelection to the new async IPC mechanism,
            restore the older CallbackID-based async IPC.

            * UIProcess/WebPageProxy.h:
            * UIProcess/WebPageProxy.messages.in:
            * UIProcess/mac/WebPageProxyMac.mm:
            (WebKit::WebPageProxy::fontAtSelection):
            (WebKit::WebPageProxy::fontAtSelectionCallback):
            * WebProcess/WebPage/WebPage.h:
            * WebProcess/WebPage/WebPage.messages.in:
            * WebProcess/WebPage/mac/WebPageMac.mm:
            (WebKit::WebPage::fontAtSelection):

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247439. rdar://problem/53229628

    [macOS 10.15] Cannot unbold selected text when the system font is used
    https://bugs.webkit.org/show_bug.cgi?id=199788
    <rdar://problem/52142570>
    
    Reviewed by Tim Horton.
    
    Source/WebKit:
    
    In macOS 10.15, +[NSFont fontWithName:size:] no longer recognizes system fonts (of name
    ".SFNS-*") and returns nil instead. However, our existing implementation of
    WebPageProxy::fontAtSelection works by grabbing the font name in the web process, and
    sending it over to the UI process, where it is mapped to an NSFont. As a result, this always
    results in a nil font in macOS 10.15, which causes us to never update NSFontManager's
    selected font. In turn, this means that once selected text is bolded, it can't be unbolded
    via NSFontManager, since NSFontManager thinks that the text is still not bold.
    
    To fix this, we simply encode and send a platform FontInfo instead of sending the font name.
    This allows the UI process to reconstruct NSFonts from font attribute dictionaries instead,
    and update the font manager.
    
    * UIProcess/Cocoa/WebViewImpl.mm:
    (WebKit::WebViewImpl::updateFontManagerIfNeeded):
    * UIProcess/WebPageProxy.h:
    * UIProcess/WebPageProxy.messages.in:
    * UIProcess/mac/WebPageProxyMac.mm:
    (WebKit::WebPageProxy::fontAtSelection):
    
    Refactor this to send a FontInfo (containing a font attribute dictionary) instead of a font
    name.
    
    (WebKit::WebPageProxy::fontAtSelectionCallback): Deleted.
    * WebProcess/WebPage/WebPage.h:
    * WebProcess/WebPage/WebPage.messages.in:
    
    Change FontAtSelection to use sendWithAsyncReply instead of sending a callback ID. This also
    allows us to remove FontAtSelectionCallback.
    
    * WebProcess/WebPage/mac/WebPageMac.mm:
    (WebKit::WebPage::fontAtSelection):
    
    Tools:
    
    Add a new API test to verify that bolding and unbolding updates the
    shared font manager's selected font.
    
    * TestWebKitAPI/Tests/mac/FontManagerTests.mm:
    (TestWebKitAPI::TEST):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247439 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-15  Wenson Hsieh  <wenson_hsieh@apple.com>

            [macOS 10.15] Cannot unbold selected text when the system font is used
            https://bugs.webkit.org/show_bug.cgi?id=199788
            <rdar://problem/52142570>

            Reviewed by Tim Horton.

            In macOS 10.15, +[NSFont fontWithName:size:] no longer recognizes system fonts (of name
            ".SFNS-*") and returns nil instead. However, our existing implementation of
            WebPageProxy::fontAtSelection works by grabbing the font name in the web process, and
            sending it over to the UI process, where it is mapped to an NSFont. As a result, this always
            results in a nil font in macOS 10.15, which causes us to never update NSFontManager's
            selected font. In turn, this means that once selected text is bolded, it can't be unbolded
            via NSFontManager, since NSFontManager thinks that the text is still not bold.

            To fix this, we simply encode and send a platform FontInfo instead of sending the font name.
            This allows the UI process to reconstruct NSFonts from font attribute dictionaries instead,
            and update the font manager.

            * UIProcess/Cocoa/WebViewImpl.mm:
            (WebKit::WebViewImpl::updateFontManagerIfNeeded):
            * UIProcess/WebPageProxy.h:
            * UIProcess/WebPageProxy.messages.in:
            * UIProcess/mac/WebPageProxyMac.mm:
            (WebKit::WebPageProxy::fontAtSelection):

            Refactor this to send a FontInfo (containing a font attribute dictionary) instead of a font
            name.

            (WebKit::WebPageProxy::fontAtSelectionCallback): Deleted.
            * WebProcess/WebPage/WebPage.h:
            * WebProcess/WebPage/WebPage.messages.in:

            Change FontAtSelection to use sendWithAsyncReply instead of sending a callback ID. This also
            allows us to remove FontAtSelectionCallback.

            * WebProcess/WebPage/mac/WebPageMac.mm:
            (WebKit::WebPage::fontAtSelection):

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247437. rdar://problem/53229545

    [iOS] SOAuthorizationSession should tell AppSSO whether the UIClient is capable of showing the extension UI
    https://bugs.webkit.org/show_bug.cgi?id=199790
    <rdar://problem/52790112>
    
    Reviewed by Brent Fulgham.
    
    Source/WebKit:
    
    On iOS, WebKit relies on a SPI -[WKUIDelegatePrivate _presentingViewControllerForWebView:] to present the
    extension UI. However, third party clients often don't implement this SPI. Therefore, WebKit will not be
    able to present the extension UI for them.
    
    To be able to show the extension UI for third party WebKit clients, WebKit should unset SOAuthorization.enableEmbeddedAuthorizationViewController
    whenever clients don't implement the above SPI such that AppSSO could show the UI in their UI process.
    
    * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
    (WebKit::SOAuthorizationSession::start):
    
    Tools:
    
    Add tests to check SOAuthorization.enableEmbeddedAuthorizationViewController accordingly.
    
    * TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm:
    (-[TestSOAuthorizationDelegate _presentingViewControllerForWebView:]):
    (configureSOAuthorizationWebView):
    (TestWebKitAPI::TEST):
    (-[TestSOAuthorizationNavigationDelegate init]): Deleted.
    (-[TestSOAuthorizationNavigationDelegate webView:didFinishNavigation:]): Deleted.
    (-[TestSOAuthorizationNavigationDelegate webView:decidePolicyForNavigationAction:decisionHandler:]): Deleted.
    (-[TestSOAuthorizationNavigationDelegate webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:]): Deleted.
    (-[TestSOAuthorizationNavigationDelegate _webView:decidePolicyForSOAuthorizationLoadWithCurrentPolicy:forExtension:completionHandler:]): Deleted.
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247437 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-15  Jiewen Tan  <jiewen_tan@apple.com>

            [iOS] SOAuthorizationSession should tell AppSSO whether the UIClient is capable of showing the extension UI
            https://bugs.webkit.org/show_bug.cgi?id=199790
            <rdar://problem/52790112>

            Reviewed by Brent Fulgham.

            On iOS, WebKit relies on a SPI -[WKUIDelegatePrivate _presentingViewControllerForWebView:] to present the
            extension UI. However, third party clients often don't implement this SPI. Therefore, WebKit will not be
            able to present the extension UI for them.

            To be able to show the extension UI for third party WebKit clients, WebKit should unset SOAuthorization.enableEmbeddedAuthorizationViewController
            whenever clients don't implement the above SPI such that AppSSO could show the UI in their UI process.

            * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
            (WebKit::SOAuthorizationSession::start):

2019-07-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r247377. rdar://problem/53229731

    New York font erroneously gets synthetic bold
    https://bugs.webkit.org/show_bug.cgi?id=199653
    <rdar://problem/51692592>
    
    Reviewed by Simon Fraser.
    
    Source/WebCore:
    
    This patch adds support for -apple-system-ui-serif, -apple-system-ui-monospaced,
    and -apple-system-ui-rounded, behind an SPI that is off-by-default. We don't want
    to expose these fonts to the web because we don't a standardization story for them
    yet, but we do want some apps to be able to use them.
    
    WebKit clients who want to use these fonts can set
    -[WKPreferences _shouldAllowDesignSystemUIFonts] = YES.
    
    The patch generalizes our existing system-ui infrastructure to handle these three
    additional fonts. It also explicitly disables the unsupported dot-prefixed names
    so they don't leak out into Web content.
    
    Tests: fast/text/design-system-ui-10.html
           fast/text/design-system-ui-11.html
           fast/text/design-system-ui-12.html
           fast/text/design-system-ui-13.html
           fast/text/design-system-ui-14.html
           fast/text/design-system-ui-15.html
           fast/text/design-system-ui-16.html
           fast/text/design-system-ui-2.html
           fast/text/design-system-ui-3.html
           fast/text/design-system-ui-4.html
           fast/text/design-system-ui-5.html
           fast/text/design-system-ui-6.html
           fast/text/design-system-ui-7.html
           fast/text/design-system-ui-8.html
           fast/text/design-system-ui-9.html
           fast/text/design-system-ui.html
    
    * css/CSSFontFace.cpp:
    (WebCore::CSSFontFace::shouldAllowDesignSystemUIFonts const):
    * css/CSSFontFace.h:
    * css/CSSFontFaceSource.cpp:
    (WebCore::CSSFontFaceSource::load):
    * css/StyleResolver.cpp:
    (WebCore::StyleResolver::initializeFontStyle):
    * page/Settings.yaml:
    * platform/graphics/FontDescription.cpp:
    (WebCore::m_shouldAllowDesignSystemUIFonts):
    (WebCore::m_shouldAllowUserInstalledFonts): Deleted.
    * platform/graphics/FontDescription.h:
    (WebCore::FontDescription::shouldAllowDesignSystemUIFonts const):
    (WebCore::FontDescription::setShouldAllowDesignSystemUIFonts):
    (WebCore::FontDescription::operator== const):
    * platform/graphics/cocoa/FontCacheCoreText.cpp:
    (WebCore::platformFontLookupWithFamily):
    (WebCore::fontWithFamily):
    * platform/graphics/cocoa/FontCacheCoreText.h:
    * platform/graphics/cocoa/FontDescriptionCocoa.cpp:
    (WebCore::systemFontUse):
    (WebCore::systemFontCascadeList):
    (WebCore::FontCascadeDescription::effectiveFamilyCount const):
    (WebCore::FontCascadeDescription::effectiveFamilyAt const):
    (WebCore::isSystemFontString): Deleted.
    (WebCore::isUIFontTextStyle): Deleted.
    * platform/graphics/cocoa/FontPlatformDataCocoa.mm:
    (WebCore::FontPlatformData::ctFont const):
    * platform/graphics/cocoa/SystemFontDatabaseCoreText.cpp:
    (WebCore::SystemFontDatabaseCoreText::createSystemUI):
    (WebCore::SystemFontDatabaseCoreText::createDesignSystemUI):
    (WebCore::SystemFontDatabaseCoreText::createTextStyle):
    (WebCore::SystemFontDatabaseCoreText::cascadeList):
    (WebCore::SystemFontDatabaseCoreText::applyWeightItalicsAndFallbackBehavior):
    (WebCore::SystemFontDatabaseCoreText::systemFontParameters):
    * platform/graphics/cocoa/SystemFontDatabaseCoreText.h:
    * platform/graphics/ios/FontCacheIOS.mm:
    (WebCore::platformFontWithFamilySpecialCase):
    * platform/graphics/mac/FontCacheMac.mm:
    (WebCore::platformFontWithFamilySpecialCase):
    * style/StyleResolveForDocument.cpp:
    (WebCore::Style::resolveForDocument):
    * svg/graphics/SVGImage.cpp:
    (WebCore::SVGImage::dataChanged):
    * testing/InternalSettings.cpp:
    (WebCore::InternalSettings::Backup::Backup):
    (WebCore::InternalSettings::Backup::restoreTo):
    (WebCore::InternalSettings::setShouldAllowDesignSystemUIFonts):
    * testing/InternalSettings.h:
    * testing/InternalSettings.idl:
    
    Source/WebCore/PAL:
    
    * pal/spi/cocoa/CoreTextSPI.h:
    
    Source/WebKit:
    
    Add the SPI to enable the new fonts.
    
    * Shared/WebPreferences.yaml:
    * UIProcess/API/C/WKPreferences.cpp:
    (WKPreferencesSetShouldAllowDesignSystemUIFonts):
    (WKPreferencesGetShouldAllowDesignSystemUIFonts):
    * UIProcess/API/C/WKPreferencesRefPrivate.h:
    * UIProcess/API/Cocoa/WKPreferences.mm:
    (-[WKPreferences _shouldAllowDesignSystemUIFonts]):
    (-[WKPreferences _setShouldAllowDesignSystemUIFonts:]):
    * UIProcess/API/Cocoa/WKPreferencesPrivate.h:
    
    Source/WTF:
    
    * wtf/Platform.h:
    
    LayoutTests:
    
    * TestExpectations:
    * fast/text/design-system-ui-10-expected-mismatch.html: Added.
    * fast/text/design-system-ui-10.html: Added.
    * fast/text/design-system-ui-11-expected-mismatch.html: Added.
    * fast/text/design-system-ui-11.html: Added.
    * fast/text/design-system-ui-12-expected-mismatch.html: Added.
    * fast/text/design-system-ui-12.html: Added.
    * fast/text/design-system-ui-13-expected-mismatch.html: Added.
    * fast/text/design-system-ui-13.html: Added.
    * fast/text/design-system-ui-14-expected-mismatch.html: Added.
    * fast/text/design-system-ui-14.html: Added.
    * fast/text/design-system-ui-15-expected-mismatch.html: Added.
    * fast/text/design-system-ui-15.html: Added.
    * fast/text/design-system-ui-16-expected-mismatch.html: Added.
    * fast/text/design-system-ui-16.html: Added.
    * fast/text/design-system-ui-2-expected.html: Added.
    * fast/text/design-system-ui-2.html: Added.
    * fast/text/design-system-ui-3-expected-mismatch.html: Added.
    * fast/text/design-system-ui-3.html: Added.
    * fast/text/design-system-ui-4-expected-mismatch.html: Added.
    * fast/text/design-system-ui-4.html: Added.
    * fast/text/design-system-ui-5-expected-mismatch.html: Added.
    * fast/text/design-system-ui-5.html: Added.
    * fast/text/design-system-ui-6-expected.html: Added.
    * fast/text/design-system-ui-6.html: Added.
    * fast/text/design-system-ui-7-expected.html: Added.
    * fast/text/design-system-ui-7.html: Added.
    * fast/text/design-system-ui-8-expected-mismatch.html: Added.
    * fast/text/design-system-ui-8.html: Added.
    * fast/text/design-system-ui-9-expected-mismatch.html: Added.
    * fast/text/design-system-ui-9.html: Added.
    * fast/text/design-system-ui-expected.html: Added.
    * fast/text/design-system-ui.html: Added.
    * platform/mac/TestExpectations:
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247377 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-11  Myles C. Maxfield  <mmaxfield@apple.com>

            New York font erroneously gets synthetic bold
            https://bugs.webkit.org/show_bug.cgi?id=199653
            <rdar://problem/51692592>

            Reviewed by Simon Fraser.

            Add the SPI to enable the new fonts.

            * Shared/WebPreferences.yaml:
            * UIProcess/API/C/WKPreferences.cpp:
            (WKPreferencesSetShouldAllowDesignSystemUIFonts):
            (WKPreferencesGetShouldAllowDesignSystemUIFonts):
            * UIProcess/API/C/WKPreferencesRefPrivate.h:
            * UIProcess/API/Cocoa/WKPreferences.mm:
            (-[WKPreferences _shouldAllowDesignSystemUIFonts]):
            (-[WKPreferences _setShouldAllowDesignSystemUIFonts:]):
            * UIProcess/API/Cocoa/WKPreferencesPrivate.h:

2019-07-15  Alan Coon  <alancoon@apple.com>

        Revert r247377. rdar://problem/53125241

2019-07-15  Alan Coon  <alancoon@apple.com>

        Cherry-pick r247436. rdar://problem/53106179

    REGRESSION: Chase app crashes immediately after authentication
    https://bugs.webkit.org/show_bug.cgi?id=199798
    <rdar://problem/53106179>
    
    Reviewed by Alex Christensen.
    
    After r247411, we sometimes try to consult `_page` from WKWebView, before WKWebView's `_page` has been set. This
    happens under a check for -[WKWebView _isEditable], from within -[WKContentView setupInteraction], which happens
    if the host app is not linked on the iOS 12 SDK or earlier. To mitigate this, simply add a null check in
    -_isEditable.
    
    There's currently no great way to test this, since we don't have a mechanism for simulating linked-on checks.
    
    * UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView _isEditable]):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247436 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2019-07-15  Wenson Hsieh  <wenson_hsieh@apple.com>

            REGRESSION: Chase app crashes immediately after authentication
            https://bugs.webkit.org/show_bug.cgi?id=199798
            <rdar://problem/53106179>

            Reviewed by Alex Christensen.

            After r247411, we sometimes try to consult `_page` from WKWebView, before WKWebView's `_page` has been set. This
            happens under a check for -[WKWebView _isEditable], from within -[WKContentView setupInteraction], which happens
            if the host app is not linked on the iOS 12 SDK or earlier. To mitigate this, simply add a null check in
            -_isEditable.

            There's currently no great way to test this, since we don't have a mechanism for simulating linked-on checks.

            * UIProcess/API/Cocoa/WKWebView.mm:
            (-[WKWebView _isEditable]):

2019-07-13  Andres Gonzalez  <andresg_22@apple.com>

        Add accessibility support to WKDataListSuggestionsView.
        https://bugs.webkit.org/show_bug.cgi?id=199772
        <rdar://problem/47095851>

        Reviewed by Chris Fleizach.

        Added accessibility announcement notifications to show, dismiss and selection change for the datalist suggestions view.
        * UIProcess/mac/WebDataListSuggestionsDropdownMac.mm:
        (-[WKDataListSuggestionsView notifyAccessibilityClients:]):
        (-[WKDataListSuggestionsView moveSelectionByDirection:]):
        (-[WKDataListSuggestionsView invalidate]):
        (-[WKDataListSuggestionsView showSuggestionsDropdown:]):

2019-07-13  Zalan Bujtas  <zalan@apple.com>

        Cannot bring up custom media controls at all on v.youku.com
        https://bugs.webkit.org/show_bug.cgi?id=199699
        <rdar://problem/51835327>

        Reviewed by Simon Fraser.

        * WebProcess/InjectedBundle/InjectedBundleNavigationAction.cpp:
        (WebKit::InjectedBundleNavigationAction::InjectedBundleNavigationAction):
        * WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
        (WebKit::WebPage::performDictionaryLookupAtLocation):
        * WebProcess/WebPage/WebFrame.cpp:
        (WebKit::WebFrame::hitTest const):
        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::handleContextMenuEvent):
        (WebKit::WebPage::characterIndexForPointAsync):
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::handleStylusSingleTapAtPoint):
        (WebKit::textInteractionPositionInformation):
        * WebProcess/WebPage/mac/WebPageMac.mm:
        (WebKit::WebPage::shouldDelayWindowOrderingEvent):
        (WebKit::WebPage::acceptsFirstMouse):
        (WebKit::WebPage::performImmediateActionHitTestAtLocation):

2019-07-12  Andy Estes  <aestes@apple.com>

        [Cocoa] -loadFileURL:allowingReadAccessToURL: should fully resolve file URLs
        https://bugs.webkit.org/show_bug.cgi?id=199768
        <rdar://problem/52002206>

        Reviewed by Geoffrey Garen.

        -loadFileURL:allowingReadAccessToURL: used -_web_originalDataAsWTFString from WKNSURLExtras
        to convert the file and read access NSURLs to strings, which under the hood calls
        CFURLGetBytes(). CFURLGetBytes() gets the URL's string without considering the base URL, so
        if the client creates a URL like this:

            NSURL *url = [NSURL fileURLWithPath:@"tmpfile.txt" relativeToURL:[NSURL fileURLWithPath:@"/tmp"]]

        ... then -_web_originalDataAsWTFString will merely return the string "tmpfile.txt". When
        that is later converted back to a URL in WebPageProxy::loadFile(), we lose track of the base
        component and refuse to load something that no longer looks like a file: URL.

        Fixed this by fully resolving the URLs passed to -loadFileURL:allowingReadAccessToURL: when
        converting to strings by using -[NSURL absoluteString] instead of -_web_originalDataAsWTFString.

        * Shared/Cocoa/WKNSURLExtras.mm:
        (-[NSURL _web_originalDataAsWTFString]):
        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView loadFileURL:allowingReadAccessToURL:]):

2019-07-12  Megan Gardner  <megan_gardner@apple.com>

        Turn off two finger gestures for editable non-scaled content
        https://bugs.webkit.org/show_bug.cgi?id=199739
        <rdar://problem/52107190>

        Reviewed by Tim Horton.

        This gesture is blocking a selection gesture. Turn it off as it is not
        even being used in editable content.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView setupInteraction]):
        (-[WKContentView _didChangeWebViewEditability]):

2019-07-12  Jiewen Tan  <jiewen_tan@apple.com>

        SOAuthorizationSession::presentViewController should check WebPageProxy::isClosed()
        https://bugs.webkit.org/show_bug.cgi?id=199755
        <rdar://problem/52323585>

        Reviewed by Chris Dumez.

        WebPageProxy::pageClient() is not guaranteed to be non null all the time. Therefore, we should check
        WebPageProxy::isClosed() before using it.

        * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
        (WebKit::SOAuthorizationSession::presentViewController):

2019-07-12  Chris Dumez  <cdumez@apple.com>

        Regression(macOS Catalina): Cannot quick look html documents in Mail
        https://bugs.webkit.org/show_bug.cgi?id=199754
        <rdar://problem/51304961>

        Reviewed by Geoff Garen.

        If the client asks us to load a file URL but does not provide a resource path, WebKit
        would fallback to issuing a sandbox extension for /. This no longer works on mac OS
        Catalina and it would thus fail to load the file.

        To address the issue, if the attempt to create a sandbox extension for / fails, we now
        fall back to issuing one for the file's baseURL (path of containing folder).

        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):

2019-07-12  Michael Catanzaro  <mcatanzaro@igalia.com>

        WebBackForwardListItem::setPageState should receive pageState by rvalue reference
        https://bugs.webkit.org/show_bug.cgi?id=199535

        Reviewed by Alex Christensen

        Coverity is complaining here about copying PageState by value in the parameter list. It's
        sort of a false positive, in that the PageState really does need to be copied here, so this
        is the best we can do. But pass by value and then WTFMove() is a pretty strange way to write
        it. Passing by rvalue reference would be better. This makes the copy more clear.

        * Shared/WebBackForwardListItem.h:
        (WebKit::WebBackForwardListItem::setPageState):
        * UIProcess/WebProcessProxy.cpp:
        (WebKit::WebProcessProxy::updateBackForwardItem):

2019-07-12  Youenn Fablet  <youenn@apple.com>

        Add release logging for quota checks
        https://bugs.webkit.org/show_bug.cgi?id=199697

        Reviewed by Alex Christensen.

        Log requests made to the page and the result from the application.

        * Platform/Logging.h:
        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::requestStorageSpace):

2019-07-12  Youenn Fablet  <youenn@apple.com>

        Remove unneeded variable in LocalStorageNamespace::getOrCreateStorageArea
        https://bugs.webkit.org/show_bug.cgi?id=199477

        Reviewed by Alex Christensen.

        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::LocalStorageNamespace::getOrCreateStorageArea):

2019-07-12  Pawel Stanek  <p.stanek@metrological.com>

        Connection::waitForSyncReply() uses wall time clock for timeout
        https://bugs.webkit.org/show_bug.cgi?id=198712
        Due to a nature of the system time (it might not be set, jump, be off
        by a lot) it is better to use monotonically increasing time which is
        exactly what's used in a similar place i.e. Connection::waitForMessage()
        
        Reviewed by Alex Christensen.

        * Platform/IPC/Connection.cpp:
        (IPC::Connection::waitForSyncReply):

2019-07-12  Timothy Hatcher  <timothy@apple.com>

        Drop DarkModeCSSEnabled as an experimental feature and always enable it.
        https://bugs.webkit.org/show_bug.cgi?id=199725
        rdar://problem/52970972

        Reviewed by Megan Gardner.

        * Shared/WebPreferences.yaml: Removed DarkModeCSSEnabled.

2019-07-11  Myles C. Maxfield  <mmaxfield@apple.com>

        New York font erroneously gets synthetic bold
        https://bugs.webkit.org/show_bug.cgi?id=199653
        <rdar://problem/51692592>

        Reviewed by Simon Fraser.

        Add the SPI to enable the new fonts.

        * Shared/WebPreferences.yaml:
        * UIProcess/API/C/WKPreferences.cpp:
        (WKPreferencesSetShouldAllowDesignSystemUIFonts):
        (WKPreferencesGetShouldAllowDesignSystemUIFonts):
        * UIProcess/API/C/WKPreferencesRefPrivate.h:
        * UIProcess/API/Cocoa/WKPreferences.mm:
        (-[WKPreferences _shouldAllowDesignSystemUIFonts]):
        (-[WKPreferences _setShouldAllowDesignSystemUIFonts:]):
        * UIProcess/API/Cocoa/WKPreferencesPrivate.h:

2019-07-11  Chris Dumez  <cdumez@apple.com>

        ASSERTION FAILED: RunLoop::isMain() under IPC::Connection::sendWithAsyncReply()
        https://bugs.webkit.org/show_bug.cgi?id=199734
        <rdar://problem/52977439>

        Reviewed by Geoffrey Garen.

        It appears WKProcessTaskStateObserverDelegate's taskStateDidChange handler can get called
        on a background thread so we need to make sure we go back to the main thread before we
        go into WebKit and do IPC.

        * Shared/Cocoa/ProcessTaskStateObserver.mm:
        (-[WKProcessTaskStateObserverDelegate process:taskStateDidChange:]):

2019-07-11  Sihui Liu  <sihui_liu@apple.com>

        StorageArea should not be destructed on the main thread
        https://bugs.webkit.org/show_bug.cgi?id=199713
        <rdar://problem/52911900>

        Reviewed by Alex Christensen.

        After r246079, LocalStorageNameSpace could be destructed on the main thread and it may hold the last reference 
        to StorageArea. Then we saw the crashes that StorageArea was wrongly destructed on the main thread.

        * NetworkProcess/NetworkSession.cpp:
        (WebKit::NetworkSession::~NetworkSession):
        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::waitUntilTasksFinished):
        (WebKit::StorageManager::waitUntilWritesFinished): Deleted.
        * NetworkProcess/WebStorage/StorageManager.h:

2019-07-11  Tim Horton  <timothy_horton@apple.com>

        Null deref of Range under WebPage::startAutoscrollAtPosition
        https://bugs.webkit.org/show_bug.cgi?id=199724
        <rdar://problem/41127089>

        Reviewed by Dean Jackson.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::startAutoscrollAtPosition):
        Refactor this function to be early-return-y, and add one more
        early return if the Range is null.

2019-07-11  Pablo Saavedra  <psaavedra@igalia.com>

        [WPE][GTK] Build failure with ENABLE_ACCESSIBILITY=OFF
        https://bugs.webkit.org/show_bug.cgi?id=199625

        Added ENABLE(ACCESSIBILITY) and replaced HAVE(ACCESSIBILITY)
        with ENABLE(ACCESSIBILITY) in the code.

        Additionally, the TestRunner code generator now honors the
        Conditional IDL format.

        Reviewed by Konstantin Tokarev.

        * UIProcess/API/glib/WebKitWebViewAccessible.cpp:
        * UIProcess/API/glib/WebKitWebViewAccessible.h:
        * UIProcess/API/wpe/PageClientImpl.cpp:
        * UIProcess/API/wpe/PageClientImpl.h:
        * UIProcess/API/wpe/WPEView.cpp:
        (WKWPE::m_backend):
        (WKWPE::View::~View):
        * UIProcess/API/wpe/WPEView.h:
        * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
        (WKAccessibilityRootObject):
        (WKAccessibilityFocusedObject):
        (WKAccessibilityEnableEnhancedAccessibility):
        (WKAccessibilityEnhancedAccessibilityEnabled):
        * WebProcess/WebPage/WebPage.cpp:
        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/atk/WebKitWebPageAccessibilityObject.cpp:
        * WebProcess/WebPage/atk/WebKitWebPageAccessibilityObject.h:
        * WebProcess/WebPage/gtk/WebPageGtk.cpp:
        (WebKit::WebPage::platformInitialize):
        * WebProcess/WebPage/wpe/WebPageWPE.cpp:
        (WebKit::WebPage::platformInitialize):
        * WebProcess/wpe/WebProcessMainWPE.cpp:

2019-07-11  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r247314.
        https://bugs.webkit.org/show_bug.cgi?id=199721

        Caused performance regression. (Requested by deanj on
        #webkit).

        Reverted changeset:

        "Disable speculative loading if cache is not to be used for
        the load"
        https://bugs.webkit.org/show_bug.cgi?id=199644
        https://trac.webkit.org/changeset/247314

2019-07-11  Dean Jackson  <dino@apple.com>

        CrashTracer: Regression : MobileSafari at UIKit: -[CALayerAccessibility__UIKit__QuartzCore setBounds:]
        https://bugs.webkit.org/show_bug.cgi?id=199720
        <rdar://problem/51470469>

        Reviewed by Tim Horton.

        Speculative fix after confirming that this crash can occur when
        a zero width/height view is used for a UITargetedPreview. We
        already guarded against this in the default flow, but not in
        the fallback path where we take a view snapshot.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (createFallbackTargetedPreview): Return early if rectangles are empty.

2019-07-11  Alex Christensen  <achristensen@webkit.org>

        Use mobile UA on jsfiddle.net
        https://bugs.webkit.org/show_bug.cgi?id=199687
        <rdar://problem/50839844>

        Reviewed by Maciej Stachowiak.

        Text selection does not work on iPads using desktop UA.
        This isn't the best solution, but it's certainly *a* solution.

        * UIProcess/ios/WebPageProxyIOS.mm:
        (WebKit::desktopClassBrowsingRecommendedForRequest):

2019-07-11  Simon Fraser  <simon.fraser@apple.com>

        [iOS WK2] Can't place caret or select in content that overflows a contenteditable element
        https://bugs.webkit.org/show_bug.cgi?id=199741
        rdar://problem/50545233

        Reviewed by Wenson Hsieh.

        Various code paths for editing used renderer->absoluteBoundingBoxRect(), which is the border
        box of the element (or a set of line boxes for inline elements) converted to absolute
        coordinates. This excludes overflow content, but contenteditable needs to be able to
        place the caret in overflow content, and allow selection rects to be in the overflow area
        (if the element has visible overflow).

        Try to clean this up by adding some static helpers on WebPage for accessing the relevant
        rects, and use them in code call from visiblePositionInFocusedNodeForPoint(), and
        code that is input to selectionClipRect.

        This changes selectionClipRect to use the padding box (excluding borders), which is a progression.

        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::platformEditorState const):
        (WebKit::elementBoundsInFrame):
        (WebKit::constrainPoint):
        (WebKit::WebPage::rootViewBoundsForElement):
        (WebKit::WebPage::absoluteInteractionBoundsForElement):
        (WebKit::WebPage::rootViewInteractionBoundsForElement):
        (WebKit::WebPage::dispatchSyntheticMouseEventsForSelectionGesture):
        (WebKit::WebPage::getFocusedElementInformation):
        (WebKit::innerFrameQuad): Deleted.
        (WebKit::elementRectInRootViewCoordinates): Deleted.

2019-07-11  Jonathan Bedard  <jbedard@apple.com>

        [iOS 13] Enable WebKit build
        https://bugs.webkit.org/show_bug.cgi?id=199481
        <rdar://problem/52619048>

        Reviewed by Tim Horton.

        * Platform/spi/ios/UIKitSPI.h: Add UITextEffectsWindow.sharedTextEffectsWindowForWindowScene SPI.
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView showGlobalMenuControllerInRect:]): setTargetRect, setMenuVisible marked depreciated in iOS 13.
        (-[WKContentView hideGlobalMenuController]): Ditto.

2019-07-11  Wenson Hsieh  <wenson_hsieh@apple.com>

        MobileSafari may crash under -[UIKeyboardTaskExecutionContext transferExecutionToMainThreadWithTask:]
        https://bugs.webkit.org/show_bug.cgi?id=199701
        <rdar://problem/52590170>

        Reviewed by Tim Horton.

        Mitigates a crash wherein we end up calling the completion handler of
        -requestAutocorrectionContextWithCompletionHandler: within a nested call
        to -requestAutocorrectionContextWithCompletionHandler:. In this particular
        case, a sync `window.open` from the web process to the UI process happens
        while the UI process is already handling a sync autocorrection context
        request. This causes the UI process to try and immediately dispatch the
        incoming sync message to avoid deadlock. However, Safari's logic to create
        and set up a new web view when opening a new window makes the new view the
        first responder, which then prompts UIKit logic to request an autocorrection
        context for the new web view.

        To avoid the issue for now, simply use -resignFirstResponder as a cue to invoke
        pending autocorrection context handlers in the original web view before UIKit
        tries to request autocorrection context in the newly created view.

        I attempted to write a test for this, but realized that we only end up hitting
        the debug assertion pointed out in <https://webkit.org/b/199680>; we should be
        able to write a test for this in the future, if we teach Connection to handle
        multiple outgoing sync messages.

        For the time being, I've attached a manual test case to the bug.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView resignFirstResponderForWebView]):
        (-[WKContentView _cancelPendingAutocorrectionContextHandler]):

        Add a new helper to signify that a pending autocorrection context handler should be cancelled (invoked
        immediately with empty data). Use this in a few places where we currently explicitly pass
        -[WKAutocorrectionContext emptyAutocorrectionContext].

        (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]):

2019-07-10  Simon Fraser  <simon.fraser@apple.com>

        [iOS WK2] With modal overlay and body overflow:hidden, can't access all the content
        https://bugs.webkit.org/show_bug.cgi?id=199693
        rdar://problem/51930364

        Reviewed by Tim Horton.

        A page with overflow:hidden on the root needs to be scrollable if:
        * it's zoomed
        * the visual viewport is smaller than the layout viewport (including visible keyboard)
        * scrolling is required to hide MobileSafari's squishy bars

        This patch does the last two, plumbing a "visual viewport is smaller than layout viewport"
        bit up from WebCore via the scrolling tree (that way, when it changes we automatically trigger
        a commit), and checking for squished bars in WKWebView.

        * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
        (ArgumentCoder<ScrollingStateFrameScrollingNode>::encode):
        (ArgumentCoder<ScrollingStateFrameScrollingNode>::decode):
        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _didCommitLayerTree:]):
        (-[WKWebView _overrideLayoutParametersWithMinimumLayoutSize:maximumUnobscuredSizeOverride:]):
        * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
        (WebKit::RemoteScrollingCoordinatorProxy::hasScrollableMainFrame const):
        * UIProcess/WebPageProxy.h:
        (WebKit::WebPageProxy::maximumUnobscuredSize const):
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::dynamicViewportSizeUpdate):
        (WebKit::WebPage::updateVisibleContentRects):

2019-07-10  Tim Horton  <timothy_horton@apple.com>

        Long pressing on attachments will crash the WebContent process
        https://bugs.webkit.org/show_bug.cgi?id=199696
        <rdar://problem/52920241>

        Reviewed by Dean Jackson.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::linkIndicatorPositionInformation):
        (WebKit::elementPositionInformation):
        (WebKit::selectionPositionInformation):
        (WebKit::WebPage::positionInformation):
        Instead of one-off creating a node snapshot for <attachment>, just
        use TextIndicator. This way, we get an estimated background color,
        paint at the right resolution, etc.

        Also, hitNode was often null where we were previously calling
        shareableBitmapSnapshotForNode, because it depends on the element
        having click event handlers. selectionPositionInformation() re-hit-tests
        more permissively to find the <attachment>, so moving this code
        inside that function ensures that we don't try to snapshot a null node.

2019-07-10  Dean Jackson  <dino@apple.com>

        Safari’s context menu actions are missing options
        https://bugs.webkit.org/show_bug.cgi?id=199694
        <rdar://problem/52726822>

        Reviewed by Tim Horton.

        One of the most embarrassing errors I've ever made. I was returning
        early when something existed, instead of when it didn't exist.
        (*cough* tests *cough*)

        * UIProcess/ios/WKContentViewInteraction.mm:

2019-07-10  Jon Lee  <jonlee@apple.com>

        Opt trello.com to mobile UA
        https://bugs.webkit.org/show_bug.cgi?id=199686
        rdar://problem/51708119

        Reviewed by Wenson Hsieh.

        * UIProcess/ios/WebPageProxyIOS.mm:
        (WebKit::desktopClassBrowsingRecommendedForRequest): Currently the desktop version
        of the site prevents users from tapping cards to edit them. Opt trello into the mobile
        UA for now.

2019-07-10  Daniel Bates  <dabates@apple.com>

        [iOS] Selection handles "Lollipops" can become gray and stay gray
        https://bugs.webkit.org/show_bug.cgi?id=198852
        <rdar://problem/51736130>

        Reviewed by Wenson Hsieh.

        Tell the text interaction assistant to update the selection UI when the tint color changes.
        We do this by way of deactivating and activating selection.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView tintColorDidChange]):

2019-07-10  Dean Jackson  <dino@apple.com>

        Share or Copy image from context menu does not share the correct data
        https://bugs.webkit.org/show_bug.cgi?id=199681
        <rdar://problem/50538771>

        Reviewed by Tim Horton.

        The UIContextMenuInteraction calls didEndInteraction before executing the
        actions of a selected menu item. This means we were assuming the interaction
        had finished before performing the action triggered in the interaction, ending
        up in the state where we had forgotten which element we were working with.

        Rather than ask for UIKit to change, I'm just starting the interaction again
        as the action is run. Thankfully we already had the location of the interaction.
        There is a small risk that the page has changed in the meantime, but I'm not
        sure what to do about that.

        While here, I moved a method only used by us into _WKElementActionInternal,
        and changed the location stored by _WKActivatedElementInfo from a CGPoint
        to an WebCore::IntPoint (since it doesn't escape WebKit).

        * UIProcess/API/Cocoa/_WKActivatedElementInfo.mm: Use a WebCore::IntPoint rather than a CGPoint.
        (-[_WKActivatedElementInfo _initWithType:URL:imageURL:location:title:ID:rect:image:]):
        (-[_WKActivatedElementInfo _initWithType:URL:imageURL:location:title:ID:rect:image:userInfo:]):
        (-[_WKActivatedElementInfo _interactionLocation]):
        * UIProcess/API/Cocoa/_WKActivatedElementInfoInternal.h:

        * UIProcess/API/Cocoa/_WKElementAction.h: Move uiActionForElementInfo to Internal.
        * UIProcess/API/Cocoa/_WKElementActionInternal.h:

        * UIProcess/API/Cocoa/_WKElementAction.mm: When executing the handlers, restart the interaction
        using the location in _WKActivatedElementInfo.
        (+[_WKElementAction _elementActionWithType:customTitle:assistant:]):

        * UIProcess/ios/WKContentViewInteraction.mm: Explicitly start and stop interactions at
        the appropriate points in the UIContextMenu flow. This isn't really needed since we're
        doing it in the handlers, but it will be correct if the UIKit delegate order changes.
        (-[WKContentView continueContextMenuInteraction:]):
        (-[WKContentView contextMenuInteractionDidEnd:]):

2019-07-10  Chris Dumez  <cdumez@apple.com>

        Crash under IPC::Connection::waitForMessage()
        https://bugs.webkit.org/show_bug.cgi?id=199680
        <rdar://problem/52500561>

        Reviewed by Tim Horton.

        IPC::Connection::waitForMessage() is crashing due to a null defererence of
        m_waitingForMessage. Since m_waitingForMessage is only ever set to null in
        waitForMessage(), this seems to imply we've re-entered waitForMessage().
        This is in theory possible since the loop inside waitForMessage() calls
        SyncMessageState::singleton().dispatchMessages() on every iteration to
        process incoming synchronous IPC messages. In theory, one of these sync
        IPC messages could run code which ends up calling waitForAndDispatchImmediately()
        (and thus waitForMessage()).

        We had a debug assertion to try and catch re-entrancy with a comment stating
        "We don't support having multiple clients waiting for messages." but we
        would not see those in release and we would crash with a null dereference
        instead.

        To address the crashes in release, return early in case of re-entrancy
        (we would still hit an assertion in debug).

        * Platform/IPC/Connection.cpp:
        (IPC::Connection::Connection):
        (IPC::Connection::waitForMessage):
        * Platform/IPC/Connection.h:

2019-07-10  Tim Horton  <timothy_horton@apple.com>

        Context menus are not presented for WKWebViews that don't have UIDelegates
        https://bugs.webkit.org/show_bug.cgi?id=199678

        Reviewed by Dean Jackson.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView continueContextMenuInteraction:]):
        Remove this unnecessary early-return if we don't have a UIDelegate.
        We have a default behavior that we totally want to happen.
        Also, rename completion() to continueWithContextMenuConfiguration()
        to reduce confusion between completion() and completionBlock() in
        this method.

2019-07-10  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r247223.
        https://bugs.webkit.org/show_bug.cgi?id=199679

        Caused perf regression. (Requested by deanj on #webkit).

        Reverted changeset:

        "[iPadOS] Viewport pops while loading sohu.com, xinhuanet.com,
        and various other websites"
        https://bugs.webkit.org/show_bug.cgi?id=199575
        https://trac.webkit.org/changeset/247223

2019-07-10  Youenn Fablet  <youenn@apple.com>

        Disable speculative loading if cache is not to be used for the load
        https://bugs.webkit.org/show_bug.cgi?id=199644

        Reviewed by Chris Dumez.

        When the page is reloaded, loads are instructed to not use the cache.
        It is therefore unneeded to do speculative revalidation.
        Allow speculative revalidation if the cache policy is either the default HTTP policy or
        if policy is to refresh all cache data.
        Covered by added test.

        * NetworkProcess/cache/NetworkCache.cpp:
        (WebKit::NetworkCache::cachePolicyValidForSpeculativeRevalidation):
        (WebKit::NetworkCache::canRequestUseSpeculativeRevalidation):

2019-07-10  Alex Christensen  <achristensen@webkit.org>

        Fix build after Foundation changes UIEdgeInsets definition
        https://bugs.webkit.org/show_bug.cgi?id=199660
        <rdar://problem/52390453>

        Reviewed by Tim Horton.

        * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
        * UIProcess/Cocoa/WKWebViewContentProvider.h:

2019-07-10  Antti Koivisto  <antti@apple.com>

        Remove TouchActionData
        https://bugs.webkit.org/show_bug.cgi?id=199668

        Reviewed by Simon Fraser.

        * Shared/WebCoreArgumentCoders.cpp:
        (IPC::ArgumentCoder<EventTrackingRegions>::encode):
        (IPC::ArgumentCoder<EventTrackingRegions>::decode):
        (IPC::ArgumentCoder<TouchActionData>::encode): Deleted.
        (IPC::ArgumentCoder<TouchActionData>::decode): Deleted.

2019-07-09  Michael Catanzaro  <mcatanzaro@igalia.com>

        [WPE][GTK] GUniqueOutPtr::release should return a raw pointer
        https://bugs.webkit.org/show_bug.cgi?id=199579

        Reviewed by Carlos Garcia Campos.

        * NetworkProcess/glib/WebKitCachedResolver.cpp:
        (webkitCachedResolverLookupByNameAsync):
        (webkitCachedResolverLookupByNameWithFlagsAsync):
        * UIProcess/API/glib/WebKitFaviconDatabase.cpp:
        (processPendingIconsForPageURL):
        (webkit_favicon_database_get_favicon):
        * UIProcess/API/glib/WebKitUserContentFilterStore.cpp:
        (webkit_user_content_filter_store_save_from_file):

2019-07-09  Tim Horton  <timothy_horton@apple.com>

        Fixed elements appear in the middle of full page screenshots taken when scrolled
        https://bugs.webkit.org/show_bug.cgi?id=199649
        <rdar://problem/52476226>

        Reviewed by Simon Fraser.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::computePagesForPrintingAndDrawToPDF):
        Temporarily expand the layout viewport to the size of the snapshotting page,
        so that fixed elements sit against the bounds of the page instead of
        wherever you're currently scrolled to.

2019-07-09  Simon Fraser  <simon.fraser@apple.com>

        [iOS WK2] Use Optional<> for two data members of WKWebView
        https://bugs.webkit.org/show_bug.cgi?id=199637

        Reviewed by Tim Horton.

        Use Optional<CGSize> to replace _overridesViewLayoutSize/_viewLayoutSizeOverride
        and _overridesMaximumUnobscuredSize/_maximumUnobscuredSizeOverride.

        No behavior change.

        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView activeViewLayoutSize:]):
        (-[WKWebView _frameOrBoundsChanged]):
        (activeMaximumUnobscuredSize):
        (-[WKWebView _minimumLayoutSizeOverride]):
        (-[WKWebView _setViewLayoutSizeOverride:]):
        (-[WKWebView _maximumUnobscuredSizeOverride]):
        (-[WKWebView _setMaximumUnobscuredSizeOverride:]):
        (-[WKWebView _beginAnimatedResizeWithUpdates:]):
        (-[WKWebView _clearOverrideLayoutParameters]):

2019-07-09  Chris Dumez  <cdumez@apple.com>

        Fix integer type encoding / decoding in WKRemoteObjectCoder
        https://bugs.webkit.org/show_bug.cgi?id=199643
        <rdar://problem/52732342>

        Reviewed by Anders Carlsson.

        As per [1], q / Q match to long long / unsigned long long, not long / unsigned long.

        [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html#//apple_ref/doc/uid/TP40008048-CH100

        * Shared/API/Cocoa/WKRemoteObjectCoder.mm:
        (encodeInvocationArguments):
        (decodeInvocationArguments):

2019-07-09  Chris Dumez  <cdumez@apple.com>

        Cleanup uses of NetworkProcess::m_sessionByConnection
        https://bugs.webkit.org/show_bug.cgi?id=199586

        Reviewed by Alex Christensen.

        Avoid double HashMap lookups and call add() instead of ensure() when appropriate.

        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::networkSessionByConnection const):
        (WebKit::NetworkProcess::webPageWasAdded):
        (WebKit::NetworkProcess::webProcessWasDisconnected):

2019-07-09  Saagar Jha  <saagarjha@apple.com>

        WKObject's minimum object alignment needs to be larger
        https://bugs.webkit.org/show_bug.cgi?id=199523

        Reviewed by Alex Christensen.

        WKObject's wrapped objects are currently constructed at addresses aligned to 8-byte boundaries, but some
        classes have more stringent requirements. By querying std::aligned_storage for the alignment of an object
        larger than anything we can construct, we should be able to satisfy alignment for any of WebKit's types.

        * Shared/Cocoa/APIObject.mm: Use std::aligned_storage in conjunction with alignof to determine
        minimumObjectAlignment, instead of hardcoding 8.

2019-07-09  Megan Gardner  <megan_gardner@apple.com>

        Don't strip out spaces for personalized Autocorrections
        https://bugs.webkit.org/show_bug.cgi?id=199476
        <rdar://problem/50782015>

        Reviewed by Dean Jackson.

        When inserting 'autocorrections' that are really predictive
        text suggestions based on personal data, we would remove the space
        before the suggestion, resulting in incorrect input.
        To fix, do not remove a space when the autocorrected text and the text it is 
        replacing do not have any length.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::applyAutocorrectionInternal):

2019-07-09  Truitt Savell  <tsavell@apple.com>

        Unreviewed, rolling out r247230.

        Caused storage/domstorage/localstorage/private-browsing-
        affects-storage.html to crash with an assertion.

        Reverted changeset:

        "Cleanup uses of NetworkProcess::m_sessionByConnection"
        https://bugs.webkit.org/show_bug.cgi?id=199586
        https://trac.webkit.org/changeset/247230

2019-07-09  Youenn Fablet  <youenn@apple.com>

        XHR CORS requests logged twice in the server
        https://bugs.webkit.org/show_bug.cgi?id=199492
        <rdar://problem/52757558>

        Reviewed by Chris Dumez.

        Disable speculative loading for XHR and fetch.
        These speculative requests might have specific headers that are no longer relevant
        when reloading the page. This might then confuse servers.

        * NetworkProcess/cache/NetworkCache.cpp:
        (WebKit::NetworkCache::makeStoreDecision):
        (WebKit::NetworkCache::canRequestUseSpeculativeRevalidation):
        (WebKit::NetworkCache::Cache::retrieve):

2019-07-09  Chris Dumez  <cdumez@apple.com>

        Fix validation of method signature in decodeInvocation()
        https://bugs.webkit.org/show_bug.cgi?id=199629
        <rdar://problem/52731659>

        Reviewed by Dan Bernstein.

        The decoder was mistakenly assigning remoteMethodSignature to localMethodSignature
        before comparing remoteMethodSignature and localMethodSignature, thus making the
        check useless.

        * Shared/API/Cocoa/WKRemoteObjectCoder.mm:
        (decodeInvocation):

2019-07-09  Youenn Fablet  <youenn@apple.com>

        Revert conditional WebPageProxy check to grant universal file read sandbox upon correct sandbox creation
        https://bugs.webkit.org/show_bug.cgi?id=199622
        <rdar://problem/52357508>

        Reviewed by Alex Christensen.

        On iOS, the sandbox extension to '/' will usually fail, thus the universal file read sandbox is not granted.
        This makes WebPageProxy cancel some file:// loads to the application own container.
        As a short term fix, go back to previous behavior.
        Covered by testing broken app identified in rdar://problem/52357508.

        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):

2019-07-09  Sihui Liu  <sihui_liu@apple.com>

        Only allow fetching and removing session credentials from WebsiteDataStore
        https://bugs.webkit.org/show_bug.cgi?id=199385
        <rdar://problem/52622080>

        Reviewed by Alex Christensen.

        Stop sending an extra message to network process for fetching or removing persistent credentials.

        Also introduce a new SPI for clearing persistent credentials created in test.

        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::clearPermanentCredentialsForProtectionSpace):
        (WebKit::NetworkProcess::fetchWebsiteData):
        (WebKit::NetworkProcess::deleteWebsiteData):
        (WebKit::NetworkProcess::deleteWebsiteDataForOrigins):
        (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains):
        (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted.
        (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted.
        * NetworkProcess/NetworkProcess.h:
        * NetworkProcess/NetworkProcess.messages.in:
        * NetworkProcess/cocoa/NetworkProcessCocoa.mm:
        (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted.
        (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted.
        * UIProcess/API/Cocoa/WKProcessPool.mm:
        (-[WKProcessPool _clearPermanentCredentialsForProtectionSpace:completionHandler:]):
        * UIProcess/API/Cocoa/WKProcessPoolPrivate.h:
        * UIProcess/WebProcessPool.cpp:
        (WebKit::WebProcessPool::clearPermanentCredentialsForProtectionSpace):
        * UIProcess/WebProcessPool.h:
        * UIProcess/WebsiteData/WebsiteDataStore.cpp:
        (WebKit::WebsiteDataStore::fetchDataAndApply):
        (WebKit::computeWebProcessAccessTypeForDataRemoval):
        (WebKit::WebsiteDataStore::removeData):

2019-07-09  Antoine Quint  <graouts@apple.com>

        [Pointer Events] Scroll indicators should not show for scrollable content with touch-action: none
        https://bugs.webkit.org/show_bug.cgi?id=199618

        Reviewed by Simon Fraser.

        Even though we correctly didn't scroll when "touch-action: none" was specified on an element, we would only apply
        scrolling constraints after the panning gesture was recognized and the backing UIScrollView would show its scroll
        indicators. While this is correct when only "pan-x" or "pan-y" is specified, we should not show the scroll indicators
        at all for "touch-action: none" since no scrolling should happen.

        To do this, we add a new method to the WKTouchActionGestureRecognizerDelegate protocol to indicate whether a given
        gesture recognizer may pan content in the WKWebView. If the gesture recognizer is the top-level scroll view or one
        created within the page to back "overflow: scroll" content or an iframe, we correctly make that gesture recognizer
        fail to recognize if neither "pan-x" nor "pan-y" is specified for this touch identifier.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView gestureRecognizerMayPanWebView:]):
        * UIProcess/ios/WKTouchActionGestureRecognizer.h:
        * UIProcess/ios/WKTouchActionGestureRecognizer.mm:
        (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]):

2019-07-09  Chris Dumez  <cdumez@apple.com>

        Validate reply block signature in [WKRemoteObjectRegistry _invokeMethod]
        https://bugs.webkit.org/show_bug.cgi?id=199584
        <rdar://problem/46268249>

        Reviewed by Geoffrey Garen.

        Validate reply block signature in [WKRemoteObjectRegistry _invokeMethod] for robustness.

        * Shared/API/Cocoa/_WKRemoteObjectRegistry.mm:
        (validateReplyBlockSignature):
        (-[_WKRemoteObjectRegistry _invokeMethod:]):

2019-07-09  Alex Christensen  <achristensen@webkit.org>

        UserData::decode should return false when decoding an unrecognized type
        https://bugs.webkit.org/show_bug.cgi?id=199598
        <rdar://52735138>

        Reviewed by Ryosuke Niwa.

        * Shared/UserData.cpp:
        (WebKit::UserData::decode):

2019-07-08  Chris Dumez  <cdumez@apple.com>

        Speculative fix for crashes under LocalStorageDatabaseTracker::databasePath()
        https://bugs.webkit.org/show_bug.cgi?id=199599
        <rdar://problem/31169686>

        Reviewed by Ryosuke Niwa.

        Speculative fix for crashes under LocalStorageDatabaseTracker::databasePath():
        - Add new localStorageDirectory() getter to LocalStorageDatabaseTracker which
          calls isolatedCopy() on m_localStorageDirectory before returning it.
          Use it everywhere instead of m_localStorageDirectory since it is not safe
          to use the same String from various threads like it was done.
        - Move localStorageDirectory when constructing the LocalStorageDatabaseTracker
          instead of copying it.
        - Make sure that LocalStorageDatabaseTracker and StorageManager are both
          constructed and destroyed on the main thread.

        * NetworkProcess/NetworkSession.cpp:
        (WebKit::NetworkSession::NetworkSession):
        * NetworkProcess/NetworkSession.h:
        * NetworkProcess/WebStorage/LocalStorageDatabaseTracker.cpp:
        (WebKit::LocalStorageDatabaseTracker::create):
        (WebKit::LocalStorageDatabaseTracker::LocalStorageDatabaseTracker):
        (WebKit::LocalStorageDatabaseTracker::localStorageDirectory const):
        (WebKit::LocalStorageDatabaseTracker::~LocalStorageDatabaseTracker):
        (WebKit::LocalStorageDatabaseTracker::deleteAllDatabases):
        (WebKit::LocalStorageDatabaseTracker::origins const):
        (WebKit::LocalStorageDatabaseTracker::databasePath const):
        * NetworkProcess/WebStorage/LocalStorageDatabaseTracker.h:
        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::create):
        (WebKit::StorageManager::StorageManager):
        (WebKit::StorageManager::~StorageManager):
        * NetworkProcess/WebStorage/StorageManager.h:
        * NetworkProcess/WebStorage/ios/LocalStorageDatabaseTrackerIOS.mm:
        (WebKit::LocalStorageDatabaseTracker::platformMaybeExcludeFromBackup const):
        * NetworkProcess/cocoa/NetworkSessionCocoa.mm:
        (WebKit::NetworkSessionCocoa::NetworkSessionCocoa):
        * NetworkProcess/curl/NetworkSessionCurl.cpp:
        (WebKit::NetworkSessionCurl::NetworkSessionCurl):
        * NetworkProcess/soup/NetworkSessionSoup.cpp:
        (WebKit::NetworkSessionSoup::NetworkSessionSoup):

2019-07-08  Chris Dumez  <cdumez@apple.com>

        Use WeakHashSet for WebUserContentControllerProxy::m_processes
        https://bugs.webkit.org/show_bug.cgi?id=199591
        <rdar://problem/52798721>

        Reviewed by Youenn Fablet.

        Use WeakHashSet for WebUserContentControllerProxy::m_processses for safety. In theory, a WebProcessProxy could
        stay in the map if we failed to call WebProcessProxy::shutDown() before destroying it.

        * UIProcess/UserContent/WebUserContentControllerProxy.cpp:
        (WebKit::WebUserContentControllerProxy::~WebUserContentControllerProxy):
        (WebKit::WebUserContentControllerProxy::addProcess):
        (WebKit::WebUserContentControllerProxy::removeProcess):
        (WebKit::WebUserContentControllerProxy::addUserContentWorldUse):
        (WebKit::WebUserContentControllerProxy::removeUserContentWorldUses):
        (WebKit::WebUserContentControllerProxy::addUserScript):
        (WebKit::WebUserContentControllerProxy::removeUserScript):
        (WebKit::WebUserContentControllerProxy::removeAllUserScripts):
        (WebKit::WebUserContentControllerProxy::addUserStyleSheet):
        (WebKit::WebUserContentControllerProxy::removeUserStyleSheet):
        (WebKit::WebUserContentControllerProxy::removeAllUserStyleSheets):
        (WebKit::WebUserContentControllerProxy::addUserScriptMessageHandler):
        (WebKit::WebUserContentControllerProxy::removeUserMessageHandlerForName):
        (WebKit::WebUserContentControllerProxy::removeAllUserMessageHandlers):
        (WebKit::WebUserContentControllerProxy::addContentRuleList):
        (WebKit::WebUserContentControllerProxy::removeContentRuleList):
        (WebKit::WebUserContentControllerProxy::removeAllContentRuleLists):
        * UIProcess/UserContent/WebUserContentControllerProxy.h:
        (WebKit::WebUserContentControllerProxy::addNetworkProcess):
        (WebKit::WebUserContentControllerProxy::removeNetworkProcess):

2019-07-08  Daniel Bates  <dabates@apple.com>

        [iOS] Support select all in non-editable element
        https://bugs.webkit.org/show_bug.cgi?id=199257
        <rdar://problem/52553667>

        Reviewed by Wenson Hsieh.

        Unless we are populating the callout bar always advertise that WebKit can perform Select All
        when building with USE(UIKIT_KEYBOARD_ADDITIONS). This way you can press Command + A to select
        all text even in a non-editable element just like you can on Mac.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView canPerformActionForWebView:withSender:]):

2019-07-08  Chris Dumez  <cdumez@apple.com>

        Cleanup uses of NetworkProcess::m_sessionByConnection
        https://bugs.webkit.org/show_bug.cgi?id=199586

        Reviewed by Alex Christensen.

        Avoid double HashMap lookups and call add() instead of ensure() when appropriate.

        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::networkSessionByConnection const):
        (WebKit::NetworkProcess::webPageWasAdded):
        (WebKit::NetworkProcess::webProcessWasDisconnected):

2019-07-08  Tim Horton  <timothy_horton@apple.com>

        WKWebView fails to render when another view uses CoreImage filters
        https://bugs.webkit.org/show_bug.cgi?id=199488
        <rdar://problem/52695825>

        Reviewed by Dean Jackson.

        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::layerHostingModeDidChange):
        Update m_layerHostingMode when it changes, even if we can't message
        the Web Content process. This ensures that the next time we launch
        a Web Content process, WebPageCreationParameters will have the correct
        layer hosting mode, and is the usual pattern for such things.

2019-07-08  Wenson Hsieh  <wenson_hsieh@apple.com>

        [iPadOS] Viewport pops while loading sohu.com, xinhuanet.com, and various other websites
        https://bugs.webkit.org/show_bug.cgi?id=199575
        <rdar://problem/51842220>

        Reviewed by Simon Fraser.

        Currently, the shrink-to-fit-content heuristic added to scale desktop sites fit within the viewport on iPadOS
        only runs during two intervals: after document load, and after page load. On very script-heavy websites, this
        may cause a visible jump, as rendering may commence well before the document is finished parsing.

        To mitigate this, we move the first opportunity for the shrink-to-fit heuristic from after document, to right
        after the page transition has completed (before we unfreeze the layer tree).

        * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
        (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad):
        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::WebPage::didCompletePageTransition):
        (WebKit::WebPage::didFinishDocumentLoad): Deleted.

        Remove this didFinishDocumentLoad hook, which was only used to schedule the shrink-to-fit timer.

        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::immediatelyShrinkToFitContent):

        m_mainFrame might be null after page transition completes, so we need to ensure immediatelyShrinkToFitContent is
        robust in this scenario.

2019-07-08  Chris Dumez  <cdumez@apple.com>

        Add threading assertion to WTF::CompletionHandler
        https://bugs.webkit.org/show_bug.cgi?id=199516

        Reviewed by Alex Christensen.

        Update some MessagePort-related code to use WTF::Function instead of WTF::CompletionHandler
        since the callback is always called on the main thread, even when it was created on a
        worker thread. Ideally, this code would be refactored so that the callback gets called on
        the worker thread directly.

        * UIProcess/UIMessagePortChannelProvider.cpp:
        (WebKit::UIMessagePortChannelProvider::checkRemotePortForActivity):
        * UIProcess/UIMessagePortChannelProvider.h:
        * WebProcess/WebCoreSupport/WebMessagePortChannelProvider.cpp:
        (WebKit::WebMessagePortChannelProvider::checkRemotePortForActivity):
        * WebProcess/WebCoreSupport/WebMessagePortChannelProvider.h:

2019-07-08  Antoine Quint  <graouts@apple.com>

        [Pointer Events] "touch-action: none" does not prevent double-tap-to-zoom
        https://bugs.webkit.org/show_bug.cgi?id=199571
        <rdar://problem/51715002>

        Reviewed by Wenson Hsieh.

        We add a new WKTouchActionGestureRecognizerDelegate method to check whether a gesture recognizer may lead to
        zooming the page as a result of double-tapping, which can be caused by two different gesture recognizers
        managed by WKContentViewInteraction. If that delegate method returns true and we have "touch-action: none"
        set for this touch, we cause those gesture recognizers to fail and prevent double-tap-to-zoom behavior.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView gestureRecognizerMayDoubleTapToZoomWebView:]):
        * UIProcess/ios/WKTouchActionGestureRecognizer.h:
        * UIProcess/ios/WKTouchActionGestureRecognizer.mm:
        (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]):

2019-07-08  Per Arne Vollan  <pvollan@apple.com>

        [iOS] WebContent processes should not globally allow mach lookup to the AX server.
        https://bugs.webkit.org/show_bug.cgi?id=199386
        <rdar://problem/52487468>

        Reviewed by Chris Fleizach.

        Instead, a mach extension for this service should be issued to the WebContent process. This has already been implemented.

        * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:

2019-07-08  Claudio Saavedra  <csaavedra@igalia.com>

        REGRESSION(r246671): [WPE][GTK] Crash in NetworkProcess since the DNS cache landed
        https://bugs.webkit.org/show_bug.cgi?id=199572

        Reviewed by Michael Catanzaro.

        The GError coming from the wrapped resolver shouldn't be freed,
        but passed onto the caller.

        * NetworkProcess/glib/WebKitCachedResolver.cpp:
        (webkitCachedResolverLookupByNameAsync):
        (webkitCachedResolverLookupByNameWithFlagsAsync):

2019-07-07  Antoine Quint  <graouts@apple.com>

        [Pointer Events] touch-action should affect the behavior of pinch-to-zoom to show tabs in Safari
        https://bugs.webkit.org/show_bug.cgi?id=199560
        <rdar://problem/52742265>

        Reviewed by Dean Jackson.

        There are other UIPinchGestureRecognizer objects that may lead to pinch-to-zoom behavior, for instance pinching
        out to show open tabs in Safari on iOS. We add a new WKUIDelegatePrivate method that will allow Safari to indicate
        that a UIPinchGestureRecognizer considered for prevention would lead to pinch-to-zoom behavior.

        * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView gestureRecognizerMayPinchToZoomWebView:]):

2019-07-08  Antoine Quint  <graouts@apple.com>

        [Pointer Events] Enable only on the most recent version of the supported iOS family
        https://bugs.webkit.org/show_bug.cgi?id=199562
        <rdar://problem/52766511>

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView cancelPointersForGestureRecognizer:]):
        (-[WKContentView activeTouchIdentifierForGestureRecognizer:]):
        (-[WKContentView touchActionActiveTouches]):
        * UIProcess/ios/WKSyntheticTapGestureRecognizer.m:
        (-[WKSyntheticTapGestureRecognizer touchesEnded:withEvent:]):
        * UIProcess/ios/WKTouchActionGestureRecognizer.h:
        * UIProcess/ios/WKTouchActionGestureRecognizer.mm:
        (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]):

2019-07-08  Michael Catanzaro  <mcatanzaro@igalia.com>

        [GTK] ViewGestureController constructor leaves m_direction uninitialized
        https://bugs.webkit.org/show_bug.cgi?id=199532

        Reviewed by Carlos Garcia Campos.

        This is harmless because it should never be read until after it's initialized, but still not
        robust. Fix it by assuming Back as the default value until the first swipe begins.

        * UIProcess/ViewGestureController.h:

2019-07-07  Zalan Bujtas  <zalan@apple.com>

        [ContentChangeObserver] Difficult to control videos on iqiyi.com as the actions are mouse hover
        https://bugs.webkit.org/show_bug.cgi?id=199542
        <rdar://problem/51886813>

        Reviewed by Simon Fraser.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::handleSyntheticClick):

2019-07-06  Antoine Quint  <graouts@apple.com>

        [Pointer Events] Use a gesture recognizer to prevent pinch-to-zoom behavior
        https://bugs.webkit.org/show_bug.cgi?id=199543

        Reviewed by Dean Jackson.

        We used to set the "enabled" property on the main UIScrollView's UIPinchGestureRecognizer to disable pinch-to-zoom
        behavior based on the "touch-action" CSS property. This was sub-optimal since this gesture recognizer can be publicly
        accessible by third-party developers, but also because it set state instead of a run-time solution.

        We now introduce a new WKTouchActionGestureRecognizer dedicated to preventing clearly identified gesture recognizers
        from being recognized to disable some built-in behavior. As a new touch starts, we record the computed touch-action
        property for the given touch identifier on the WKTouchActionGestureRecognizer, then WKTouchActionGestureRecognizer
        determines, by implementing -[canPreventGestureRecognizer:], whether the possibly-prevented gesture recognizer
        is known to lead to a pinch-to-zoom behavior and whether it contains a touch that should prevent it.

        To support the WKTouchActionGestureRecognizer, WKContentViewInteraction implements the new WKTouchActionGestureRecognizerDelegate
        protocol to indicate whether the possibly-prevented gesture recognizer is the main UIScrollView's UIPinchGestureRecognizer.

        No new test since this changes the implementation of existing behavior.

        * SourcesCocoa.txt:
        * UIProcess/ios/WKContentViewInteraction.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView setupInteraction]):
        (-[WKContentView cleanupInteraction]):
        (-[WKContentView _removeDefaultGestureRecognizers]):
        (-[WKContentView _addDefaultGestureRecognizers]):
        (-[WKContentView _handleTouchActionsForTouchEvent:]):
        (-[WKContentView gestureRecognizerMayPinchToZoomWebView:]):
        (-[WKContentView touchActionActiveTouches]):
        * UIProcess/ios/WKTouchActionGestureRecognizer.h: Added.
        * UIProcess/ios/WKTouchActionGestureRecognizer.mm: Added.
        (-[WKTouchActionGestureRecognizer initWithTouchActionDelegate:]):
        (-[WKTouchActionGestureRecognizer setTouchActions:forTouchIdentifier:]):
        (-[WKTouchActionGestureRecognizer clearTouchActionsForTouchIdentifier:]):
        (-[WKTouchActionGestureRecognizer touchesBegan:withEvent:]):
        (-[WKTouchActionGestureRecognizer touchesMoved:withEvent:]):
        (-[WKTouchActionGestureRecognizer touchesEnded:withEvent:]):
        (-[WKTouchActionGestureRecognizer touchesCancelled:withEvent:]):
        (-[WKTouchActionGestureRecognizer _updateState]):
        (-[WKTouchActionGestureRecognizer canBePreventedByGestureRecognizer:]):
        (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]):
        * WebKit.xcodeproj/project.pbxproj:

2019-07-06  Chris Fleizach  <cfleizach@apple.com>

        AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak
        https://bugs.webkit.org/show_bug.cgi?id=199435

        Reviewed by Ryosuke Niwa.

        Ensure we don't access null observers in speech callbacks.

        * WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp:
        (WebKit::WebSpeechSynthesisClient::voiceList):
        (WebKit::WebSpeechSynthesisClient::speak):
        (WebKit::WebSpeechSynthesisClient::pause):
        (WebKit::WebSpeechSynthesisClient::resume):
        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::WebPage::speakingErrorOccurred):
        (WebKit::WebPage::boundaryEventOccurred):
        (WebKit::WebPage::voicesDidChange):

2019-07-05  Chris Dumez  <cdumez@apple.com>

        Fix thread safety bug in WebResourceLoadStatisticsTelemetry::calculateAndSubmit()
        https://bugs.webkit.org/show_bug.cgi?id=199536

        Reviewed by Youenn Fablet.

        The resourceLoadStatisticsStore is an object that is created / used / destroyed on the background
        queue. It is therefore not safe to create a WeakPtr for it and use that WeakPtr on the main thread.

        * NetworkProcess/Classifier/WebResourceLoadStatisticsTelemetry.cpp:
        (WebKit::WebResourceLoadStatisticsTelemetry::calculateAndSubmit):

2019-07-05  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, fix -Wswitch warning

        We don't support HTTPCookieAcceptPolicy::ExclusivelyFromMainDocumentDomain.

        Fun fact, soup's OnlyFromMainDocumentDomain functions the same as Apple's
        ExclusivelyFromMainDocumentDomain. These should be renamed....

        * NetworkProcess/Cookies/soup/WebCookieManagerSoup.cpp:
        (WebKit::WebCookieManager::platformSetHTTPCookieAcceptPolicy):

2019-07-05  Dean Jackson  <dino@apple.com>

        [iOS] Context Menu - Add to Reading List does nothing
        https://bugs.webkit.org/show_bug.cgi?id=199504
        <rdar://problem/52554137>

        Reviewed by Anders Carlsson.

        We were holding weak references to the _WKElementAction in
        the handler provided to UIAction. By the time the handler was
        called, the object had been deallocated.

        * UIProcess/API/Cocoa/_WKElementAction.mm:
        (-[_WKElementAction uiActionForElementInfo:]): Use strong references in handler.

2019-07-05  Ryosuke Niwa  <rniwa@webkit.org>

        [iOS] Crash in WebKit::WebPage::positionInformation via Range::startPosition
        https://bugs.webkit.org/show_bug.cgi?id=199503

        Reviewed by Wenson Hsieh.

        The crash was caused because focusedElementPositionInformation asssumes Editor::compositionRange is not null
        whenever Editor::hasComposition returns true, which is not necessary the case when Editor::m_compositionNode
        contains no text (data is of length 0).

        Fixed the crash by adding an early return for when Editor::compositionRange returns nullptr.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::focusedElementPositionInformation):

2019-07-05  Zalan Bujtas  <zalan@apple.com>

        [ContentChangeObserver] REGRESSION (r247015): facebook photo/video upload button is unresponsive to user interaction.
        https://bugs.webkit.org/show_bug.cgi?id=199502
        <rdar://problem/52547473>

        Reviewed by Simon Fraser.

        Apparently it's a common practice to put transparent elements over visible click targets (button like divs) and use the invisible
        elements to catch the user input (e.g. Facebook's Photo/Video button).
        This patch modifies the original "do not trigger click on invisible targets" heuristic to a more restrictive "do not trigger
        click if the click target was previously hidden and became visible through touch start".
        If this still breaks some use cases, we could turn it into YouTube quirk.       

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::handleSyntheticClick):

2019-07-05  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r247123.

        Caused TestWebKitAPI.Challenge.BasicProposedCredential to
        fail.

        Reverted changeset:

        "Only allow fetching and removing session credentials from
        WebsiteDataStore"
        https://bugs.webkit.org/show_bug.cgi?id=199385
        https://trac.webkit.org/changeset/247123

2019-07-05  Wenson Hsieh  <wenson_hsieh@apple.com>

        Click events on outer page are not being dispatched correctly after touch-zooming within an iframe
        https://bugs.webkit.org/show_bug.cgi?id=185001
        <rdar://problem/40569615>

        Reviewed by Simon Fraser.

        Mitigations introduced in r227759 prevent a touch inside a document of origin A to result in a click event being
        dispatched on an element inside a document of origin B. It accomplishes this by keeping track of the security
        origin of the last touch via m_potentialTapSecurityOrigin on WebPage. However, there exists a corner case in
        which m_potentialTapSecurityOrigin, set after touching a document in a subframe, may persist even after the user
        has finished interacting, causing taps in subsequent documents to not result in synthetic click events due to
        mismatched potential tap origins.

        This may happen if the first user gesture happens inside an element in a subframe with touch event handlers, but
        no click event handler (and the touch is additionally not over some clickable element). In this case,
        m_potentialTapNode is set to null in WebPage::potentialTapAtPosition, and when we consult it in
        WebPage::commitPotentialTap, we just end up calling commitPotentialTapFailed(); and return early. This means
        that m_potentialTapNode, m_potentialTapLocation, and (importantly) m_potentialTapSecurityOrigin are not reset.
        This causes subsequent taps in the top-level document to never dispatch click events, if the security origin
        does not match with that of the subframe.

        To fix this, we add a new async IPC message from the UI process to the web process to ensure that our current
        security origin is reset before attempting to handle a tap.

        Test: http/tests/events/touch/ios/click-after-handling-touch-in-cross-origin-frame.https.html

        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::resetPotentialTapSecurityOrigin):

        Reset any stale potential tap security origin if needed.

        * UIProcess/WebPageProxy.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _webTouchEventsRecognized:]):

        Send the new IPC message when starting a touch.

        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::WebPage::resetPotentialTapSecurityOrigin):
        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/WebPage.messages.in:

2019-07-05  Wenson Hsieh  <wenson_hsieh@apple.com>

        Touching media controls sometimes shows software keyboard
        https://bugs.webkit.org/show_bug.cgi?id=199490
        <rdar://problem/52076270>

        Reviewed by Eric Carlson.

        In r243044, we added a compatibility hack for Google Slides (and other G-suite properties) to allow the on-
        screen keyboard to show up after a prevented touch event in the case where an element was already focused, even
        if the touch event handler doesn't explicitly refocus the element. However, this means that if a regular text
        field (or other form control) has been programmatically focused, then interacting with any other element that
        prevents default on touchstart will cause us to show the keyboard for that focused element.

        To mitigate this, only fall down this refocusing codepath in the case where the focused element is a hidden
        editable element (in the style of many Google productivity web apps). For non-hidden editable elements that are
        already focused, this refocusing logic is not necessary, since the user should be able to interact with the
        control to show the keyboard anyways; for hidden editable areas, this compatibility hack is actually needed,
        since there is typically no other way for a user to focus these elements and show an on-screen keyboard.

        Tests:  fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html
                fast/events/touch/ios/do-not-show-keyboard-after-preventing-touchstart.html

        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::WebPage::dispatchTouchEvent):
        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::isTransparentOrFullyClipped const):

        Renamed from enclosingLayerIsTransparentOrFullyClipped, and pulled out into a private helper method.

        (WebKit::WebPage::platformEditorState const):
        (WebKit::WebPage::requestEvasionRectsAboveSelection):
        (WebKit::WebPage::getFocusedElementInformation):
        (WebKit::enclosingLayerIsTransparentOrFullyClipped): Deleted.

2019-07-04  Chris Dumez  <cdumez@apple.com>

        Simplify logic that handles registering WebProcessProxy objects with their WebsiteDataStore
        https://bugs.webkit.org/show_bug.cgi?id=199412
        <rdar://problem/51899751>

        Reviewed by Ryosuke Niwa.

        Simplify logic that handles registering WebProcessProxy objects with their WebsiteDataStore to make
        it more maintainable and less error-prone (avoid bugs like <rdar://problem/51899751>).

        The following changes were made:
        1. The WebProcess now registers / unregisters itself directly with its WebsiteDataStore when needed,
           instead of having the WebPageProxy/ProvisionalPageProxy be in charge of calling the right
           WebProcessLifetimeTracker / WebProcessLifetimeObserver abstractions.
        2. The WebProcessLifetimeTracker / WebProcessLifetimeObserver abstractions were dropped. The
           WebsiteDataStore was the only observer.
        3. The WebProcessProxy is now registered with its WebsiteDataStore as soon as it has a page (provisional
           or not) instead of waiting until the process has finished launching. This simplifies the logic a
           lot and waiting until the process has launched is not needed by the WebsiteDataStore.
           

        * Sources.txt:
        * UIProcess/ProvisionalPageProxy.cpp:
        (WebKit::ProvisionalPageProxy::ProvisionalPageProxy):
        (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy):
        * UIProcess/ProvisionalPageProxy.h:
        * UIProcess/WebPageProxy.cpp:
        (WebKit::m_resetRecentCrashCountTimer):
        (WebKit::WebPageProxy::finishAttachingToWebProcess):
        (WebKit::WebPageProxy::close):
        (WebKit::WebPageProxy::processDidTerminate):
        * UIProcess/WebPageProxy.h:
        * UIProcess/WebProcessCache.cpp:
        (WebKit::WebProcessCache::CachedProcess::CachedProcess):
        * UIProcess/WebProcessLifetimeObserver.cpp: Removed.
        * UIProcess/WebProcessLifetimeObserver.h: Removed.
        * UIProcess/WebProcessLifetimeTracker.cpp: Removed.
        * UIProcess/WebProcessLifetimeTracker.h: Removed.
        * UIProcess/WebProcessProxy.cpp:
        (WebKit::WebProcessProxy::setWebsiteDataStore):
        (WebKit::WebProcessProxy::updateRegistrationWithDataStore):
        (WebKit::WebProcessProxy::addProvisionalPageProxy):
        (WebKit::WebProcessProxy::removeProvisionalPageProxy):
        (WebKit::WebProcessProxy::connectionWillOpen):
        (WebKit::WebProcessProxy::processWillShutDown):
        (WebKit::WebProcessProxy::addExistingWebPage):
        (WebKit::WebProcessProxy::removeWebPage):
        * UIProcess/WebProcessProxy.h:
        * UIProcess/WebsiteData/WebsiteDataStore.cpp:
        (WebKit::WebsiteDataStore::registerProcess):
        (WebKit::WebsiteDataStore::unregisterProcess):

        (WebKit::WebsiteDataStore::processPoolForCookieStorageOperations):
        Drop change that was added in r246097 to work around the fact that WebProcessProxy objects
        were only registering themselves with their data store after their process had finished
        launching.

        (WebKit::WebsiteDataStore::fetchDataAndApply):
        (WebKit::WebsiteDataStore::removeData):
        (WebKit::WebsiteDataStore::processPools const):
        * UIProcess/WebsiteData/WebsiteDataStore.h:
        (WebKit::WebsiteDataStore::processes const):
        * WebKit.xcodeproj/project.pbxproj:

2019-07-04  Zalan Bujtas  <zalan@apple.com>

        [ContentChangeObserver] Limit mouseOut dispatching after synthetic click to YouTube.com
        https://bugs.webkit.org/show_bug.cgi?id=199497
        <rdar://problem/52361019>

        Reviewed by Wenson Hsieh.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::completeSyntheticClick):

2019-07-03  Ryosuke Niwa  <rniwa@webkit.org>

        Crash in WebDragClient::startDrag because GraphicsContext is nullptr
        https://bugs.webkit.org/show_bug.cgi?id=199491

        Reviewed by Wenson Hsieh.

        Added a nullptr check.

        Unfortunately no new tests since we don't have a reproducible test case.

        * WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:
        (WebKit::convertImageToBitmap):

2019-07-03  Tim Horton  <timothy_horton@apple.com>

        Data Detectors are not working for context menus in clients that use the legacy preview API
        https://bugs.webkit.org/show_bug.cgi?id=199486
        <rdar://problem/52117322>

        Reviewed by Dean Jackson.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView assignLegacyDataForContextMenuInteraction]):
        The Data Detectors code in the legacy preview path is guarded by a
        #define that did not survive upstreaming. Remove it.

2019-07-03  Chris Dumez  <cdumez@apple.com>

        StorageManager::suspend() sometimes fails to call its completion handler
        https://bugs.webkit.org/show_bug.cgi?id=199482

        Reviewed by Youenn Fablet.

        Make sure the completion handler gets called in the early return cases.

        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::suspend):

2019-07-03  Youenn Fablet  <youenn@apple.com>

        Make CacheStorage::Engine directory listing operations in a background thread
        https://bugs.webkit.org/show_bug.cgi?id=199470

        Reviewed by Chris Dumez.

        Use the io work queue to get the list of directories.
        Then go back to main thread and trigger clear/fetch operation as currently done.

        * NetworkProcess/cache/CacheStorageEngine.cpp:
        (WebKit::CacheStorage::ReadOriginsTaskCounter::create):
        (WebKit::CacheStorage::ReadOriginsTaskCounter::ReadOriginsTaskCounter):
        (WebKit::CacheStorage::Engine::getDirectories):
        (WebKit::CacheStorage::Engine::fetchEntries):
        (WebKit::CacheStorage::Engine::fetchDirectoryEntries):
        (WebKit::CacheStorage::Engine::clearCachesForOriginFromDisk):
        (WebKit::CacheStorage::Engine::clearCachesForOriginFromDirectories):
        * NetworkProcess/cache/CacheStorageEngine.h:

2019-07-03  Sihui Liu  <sihui_liu@apple.com>

        Only allow fetching and removing session credentials from WebsiteDataStore
        https://bugs.webkit.org/show_bug.cgi?id=199385

        Reviewed by Alex Christensen.

        Stop sending an extra message to network process for fetching or removing persistent credentials.

        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::fetchWebsiteData):
        (WebKit::NetworkProcess::deleteWebsiteData):
        (WebKit::NetworkProcess::deleteWebsiteDataForOrigins):
        (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains):
        (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted.
        (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted.
        * NetworkProcess/NetworkProcess.h:
        * NetworkProcess/NetworkProcess.messages.in:
        * NetworkProcess/cocoa/NetworkProcessCocoa.mm:
        (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted.
        (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted.
        * UIProcess/WebsiteData/WebsiteDataStore.cpp:
        (WebKit::WebsiteDataStore::fetchDataAndApply):
        (WebKit::computeWebProcessAccessTypeForDataRemoval):
        (WebKit::WebsiteDataStore::removeData):

2019-07-03  Tim Horton  <timothy_horton@apple.com>

        UI process exception when dragging an <attachment> with no content type
        https://bugs.webkit.org/show_bug.cgi?id=199480
        <rdar://problem/44351353>

        Reviewed by Wenson Hsieh.

        * UIProcess/API/Cocoa/APIAttachmentCocoa.mm:
        (API::Attachment::mimeType const):
        (API::Attachment::utiType const):
        * UIProcess/Cocoa/WebViewImpl.mm:
        (WebKit::WebViewImpl::startDrag):
        Make null or empty contentType fail the drag, instead of crashing.

2019-07-03  Chris Dumez  <cdumez@apple.com>

        Clarify threading model for WebResourceLoadStatisticsStore::dumpResourceLoadStatistics()
        https://bugs.webkit.org/show_bug.cgi?id=199468

        Reviewed by Youenn Fablet.

        Our convention is that the WebResourceLoadStatisticsStore is always created, used and
        destroyed on the main thread, while the ResourceLoadStatisticsStore is always created,
        used and destroyed on the background queue.

        r245517 broke this convention by introducing a tryDumpResourceLoadStatistics() method
        to WebResourceLoadStatisticsStore which gets called on the background queue. This patch
        fixes this since this has been a huge source of thread-safety bugs in the past.

        * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp:
        (WebKit::ResourceLoadStatisticsDatabaseStore::dumpResourceLoadStatistics):
        * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.h:
        * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp:
        (WebKit::ResourceLoadStatisticsMemoryStore::dumpResourceLoadStatistics):
        * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.h:
        * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp:
        (WebKit::ResourceLoadStatisticsStore::removeDataRecords):
        * NetworkProcess/Classifier/ResourceLoadStatisticsStore.h:
        (WebKit::ResourceLoadStatisticsStore::dataRecordsBeingRemoved const):
        * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
        (WebKit::WebResourceLoadStatisticsStore::dumpResourceLoadStatistics):
        * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:

2019-07-03  Jonathan Bedard  <jbedard@apple.com>

        [Catalina] Enable WebKit build
        https://bugs.webkit.org/show_bug.cgi?id=199209

        Reviewed by Darin Adler.

        * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h: AppSSO is SPI.
        * WebKit2Prefix.h: SecTask.h declares SecTaskGetCodeSignStatus(...) unavailable
        on Mac, exclude this header.

2019-07-03  Daniel Bates  <dabates@apple.com>

        REGRESSION (r246817): fast/events/ios/key-events-comprehensive/key-events-{control, control-shift}.html are failing
        https://bugs.webkit.org/show_bug.cgi?id=199465
        <rdar://problem/52613496>

        Reviewed by Wenson Hsieh.

        Don't advertise that WebKit can perform cursor movements when there isn't some kind of selection.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView canPerformAction:withSender:]):

2019-07-03  Chris Dumez  <cdumez@apple.com>

        Fix a couple of thread safety issues in ResourceLoadStatisticsStore
        https://bugs.webkit.org/show_bug.cgi?id=199463

        Reviewed by Alex Christensen.

        The ResourceLoadStatisticsStore object is constructed / used / destroyed on a background queue.
        It is therefore not safe to use a WeakPtr to the ResourceLoadStatisticsStore on the main thread.

        The safe pattern is to have the ResourceLoadStatisticsStore capture a Ref<> of its m_store before
        dispatching to the main thread and use this store on the main thread instead of weakThis->m_store.
        ResourceLoadStatisticsStore's m_store is constructed / used / destroyed on the main thread.

        * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp:
        (WebKit::ResourceLoadStatisticsStore::removeDataRecords):
        (WebKit::ResourceLoadStatisticsStore::processStatisticsAndDataRecords):

2019-07-03  Youenn Fablet  <youenn@apple.com>

        Isolate CacheStorage::Engine path when hopping to a background thread
        https://bugs.webkit.org/show_bug.cgi?id=199461

        Reviewed by Chris Dumez.

        * NetworkProcess/cache/CacheStorageEngine.cpp:
        (WebKit::CacheStorage::Engine::initialize):

2019-07-03  Jer Noble  <jer.noble@apple.com>

        Unreviewed, rolling out r246053.

        This changeset caused media playback to break when the hosting app was backgrounded.

        * UIProcess/ApplicationStateTracker.mm:
        * UIProcess/ios/ProcessAssertionIOS.mm:
        (-[WKProcessAssertionBackgroundTaskManager init]):
        (-[WKProcessAssertionBackgroundTaskManager _scheduleReleaseTask]):
        (-[WKProcessAssertionBackgroundTaskManager _cancelPendingReleaseTask]):
        (-[WKProcessAssertionBackgroundTaskManager _updateBackgroundTask]):
        (-[WKProcessAssertionBackgroundTaskManager _releaseBackgroundTask]):

2019-07-03  Alex Christensen  <achristensen@webkit.org>

        Use smarter pointers in WKDownloadProgress
        https://bugs.webkit.org/show_bug.cgi?id=199456
        <rdar://problem/51392926>

        Reviewed by Chris Dumez.

        There's still a problem related to our use of raw pointers.  Let's just not use raw pointers.

        * NetworkProcess/Downloads/Download.h:
        * NetworkProcess/Downloads/cocoa/DownloadCocoa.mm:
        (WebKit::Download::publishProgress):
        * NetworkProcess/Downloads/cocoa/WKDownloadProgress.h:
        * NetworkProcess/Downloads/cocoa/WKDownloadProgress.mm:
        (-[WKDownloadProgress performCancel]):
        (-[WKDownloadProgress initWithDownloadTask:download:URL:sandboxExtension:]):
        (-[WKDownloadProgress progressCancelled]): Deleted.

2019-07-03  Sam Weinig  <weinig@apple.com>

        Adopt simple structured bindings in more places
        https://bugs.webkit.org/show_bug.cgi?id=199247

        Reviewed by Alex Christensen.

        Replaces simple uses of std::tie() with structured bindings. Does not touch
        uses of std::tie() that are not initial declarations, use std::ignore or in
        case where the binding is captured by a lambda, as structured bindings don't
        work for those cases yet.

        * NetworkProcess/cache/NetworkCacheSpeculativeLoadManager.cpp:
        (WebKit::NetworkCache::printSpeculativeLoadingDiagnosticMessageCounts):
        * NetworkProcess/cache/PrefetchCache.cpp:
        (WebKit::PrefetchCache::clearExpiredEntries):
        * Platform/IPC/MessageReceiverMap.cpp:
        (IPC::MessageReceiverMap::removeMessageReceiver):
        * UIProcess/Cocoa/PlaybackSessionManagerProxy.mm:
        (WebKit::PlaybackSessionManagerProxy::invalidate):
        * UIProcess/Cocoa/VideoFullscreenManagerProxy.mm:
        (WebKit::VideoFullscreenManagerProxy::invalidate):
        (WebKit::VideoFullscreenManagerProxy::requestHideAndExitFullscreen):
        (WebKit::VideoFullscreenManagerProxy::hasMode const):
        (WebKit::VideoFullscreenManagerProxy::mayAutomaticallyShowVideoPictureInPicture const):
        (WebKit::VideoFullscreenManagerProxy::isPlayingVideoInEnhancedFullscreen const):
        (WebKit::VideoFullscreenManagerProxy::applicationDidBecomeActive):
        (WebKit::VideoFullscreenManagerProxy::setupFullscreenWithID):
        (WebKit::VideoFullscreenManagerProxy::didCleanupFullscreen):
        * UIProcess/ios/SmartMagnificationController.mm:
        (WebKit::SmartMagnificationController::zoomFactorForTargetRect):
        (WebKit::SmartMagnificationController::didCollectGeometryForSmartMagnificationGesture):
        (WebKit::SmartMagnificationController::magnify):
        * WebProcess/Plugins/PDF/PDFPlugin.mm:
        (WebKit:: const):
        * WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
        (WebKit::WebPage::performDictionaryLookupAtLocation):
        (WebKit::WebPage::performDictionaryLookupForSelection):
        * WebProcess/cocoa/PlaybackSessionManager.mm:
        (WebKit::PlaybackSessionManager::~PlaybackSessionManager):
        (WebKit::PlaybackSessionManager::removeContext):
        * WebProcess/cocoa/VideoFullscreenManager.mm:
        (WebKit::VideoFullscreenManager::~VideoFullscreenManager):
        (WebKit::VideoFullscreenManager::removeContext):
        (WebKit::VideoFullscreenManager::enterVideoFullscreenForVideoElement):
        (WebKit::VideoFullscreenManager::requestVideoContentLayer):
        (WebKit::VideoFullscreenManager::didSetupFullscreen):
        (WebKit::VideoFullscreenManager::willExitFullscreen):
        (WebKit::VideoFullscreenManager::didEnterFullscreen):
        (WebKit::VideoFullscreenManager::didCleanupFullscreen):
        (WebKit::VideoFullscreenManager::setVideoLayerFrameFenced):

2019-07-03  Zalan Bujtas  <zalan@apple.com>

        [ContentChangeObserver] REGRESSION (r244356): Drop down menus collapse without user input - Ebay.com
        https://bugs.webkit.org/show_bug.cgi?id=199457
        <rdar://problem/52386563>

        Reviewed by Simon Fraser.

        There's a fixed, 32ms window for observing content changes after the tap is committed. r244356 introduced the fast-click behavior on form elements by omitting this fixed window and
        dispatch the synthetic click on the target node.
        This patch preserves the fast-click behavior, but now we stay at hover if the mouseMove event triggers a synchronous actionable visiblity change (as opposed to always proceed with click).

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::handleSyntheticClick):

2019-07-03  Patrick Griffis  <pgriffis@igalia.com>

        [GTK][WPE] Remove Flatpak sandbox
        https://bugs.webkit.org/show_bug.cgi?id=199416

        Reviewed by Michael Catanzaro.

        The flatpak-spawn based sandbox was only a proof of concept and
        lacks flexibility for our needs so we ended up using it with very
        permissive permissions and it still imposed limitations that our main
        bubblewrap sandbox didn't have.

        So in order to get as many applications using the sandbox as possible we
        will just remove this for now and focus on bubblewrap. At some point
        it may be possible to improve flatpak-spawn to fit our needs.

        * SourcesGTK.txt:
        * SourcesWPE.txt:
        * UIProcess/Launcher/glib/FlatpakLauncher.cpp: Removed.
        * UIProcess/Launcher/glib/FlatpakLauncher.h: Removed.
        * UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:
        (WebKit::ProcessLauncher::launchProcess):

2019-07-03  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r246616.

        Caused http/tests/inspector/network/har/har-page.html to fail
        on Catalina.

        Reverted changeset:

        "Web Inspector: Network: replace CFNetwork SPI with new API
        where able"
        https://bugs.webkit.org/show_bug.cgi?id=198762
        https://trac.webkit.org/changeset/246616

2019-07-03  Chris Dumez  <cdumez@apple.com>

        Crash under WTF::RefCounted<WebKit::TaskCounter>::deref()
        https://bugs.webkit.org/show_bug.cgi?id=199453
        <rdar://problem/51991477>

        Reviewed by Youenn Fablet.

        The crash was caused by StorageManager::suspend() getting called on the main thread but calling
        its completion handler on a background queue. The completion handler was capturing a TaskCounter
        object which is RefCounted (not ThreadSafeRefCounted).

        Address the issue by making sure StorageManager::suspend() calls its completion handler on the
        main thread. Also get rid of TaskCounter and use a WTF::CallbackAggregator instead.

        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::actualPrepareToSuspend):
        (WebKit::TaskCounter::TaskCounter): Deleted.
        (WebKit::TaskCounter::~TaskCounter): Deleted.
        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::suspend):

2019-07-03  Youenn Fablet  <youenn@apple.com>

        Make sure to cross-thread copy in StorageManager when hopping back to the main thread
        https://bugs.webkit.org/show_bug.cgi?id=199423

        Reviewed by Chris Dumez.

        Make sure to isolate copy some strings that may not be isolated in case of ephemeral sessions.
        Small refactoring to use crossThreadCopy instead of doing vector copy ourselves.

        * NetworkProcess/WebStorage/LocalStorageDatabaseTracker.h:
        (WebKit::LocalStorageDatabaseTracker::OriginDetails::isolatedCopy const):
        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::deleteSessionStorageEntriesForOrigins):
        (WebKit::StorageManager::getLocalStorageOrigins):
        (WebKit::StorageManager::getLocalStorageOriginDetails):
        (WebKit::StorageManager::deleteLocalStorageEntriesForOrigins):

2019-07-02  Joonghun Park  <jh718.park@samsung.com>

        Unreviewed. Fix build break introduced in r247058.

        * UIProcess/API/gtk/WebKitRemoteInspectorProtocolHandler.cpp:

2019-07-02  Youenn Fablet  <youenn@apple.com>

        StorageManager does not need to be a WorkQueueMessageReceiver anymore
        https://bugs.webkit.org/show_bug.cgi?id=199421

        Reviewed by Chris Dumez.

        * NetworkProcess/WebStorage/StorageManager.h:

2019-07-02  Chris Dumez  <cdumez@apple.com>

        ThreadSafeRefCounted<DestructionThread::Main> is not safe to use in the UIProcess
        https://bugs.webkit.org/show_bug.cgi?id=199420
        <rdar://problem/52289717>

        Reviewed by Ryosuke Niwa.

        Update IPC::Connection and DeviceIdHashSaltStorage to use DestructionThread::MainRunLoop
        instead of DestructionThread::Main, since both classes are used in the UIProcess.

        Using DestructionThread::Main is not safe in the UIProcess because its implementation relies
        on isMainThread() / callOnMainThread(). Those get confused about which thread is the main
        thread when an application uses both WK1 and WK2.

        * Platform/IPC/Connection.h:
        * UIProcess/DeviceIdHashSaltStorage.h:

2019-07-02  Patrick Griffis  <pgriffis@igalia.com>

        [GTK][WPE] Explicitly blacklist problematic directories for sandbox
        https://bugs.webkit.org/show_bug.cgi?id=199367

        Reviewed by Michael Catanzaro.

        There are some directories that simply do not make sense to bind into the sandbox
        and will only cause issues such as `/proc` so lets just block them.

        * UIProcess/API/glib/WebKitWebContext.cpp:
        (path_is_not_blacklisted):
        (webkit_web_context_add_path_to_sandbox):

2019-07-02  Tim Horton  <timothy_horton@apple.com>

        REGRESSION (r243240): Unable to swipe back in Safari
        https://bugs.webkit.org/show_bug.cgi?id=199394
        <rdar://problem/51137447>

        Reviewed by Wenson Hsieh.

        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _processDidExit]):
        r243240 started nilling out the ViewGestureController, but we don't actually
        expect that; the only time WKWebView's ViewGestureController goes away
        is if the client turns off the gestures... and so nothing ever puts it back.
        Instead, just always disconnect, don't nil it out.

2019-07-02  Chris Dumez  <cdumez@apple.com>

        Protect NetworkProcess::m_networkSessions against corruption
        https://bugs.webkit.org/show_bug.cgi?id=199418
        <rdar://problem/50614019>

        Reviewed by Youenn Fablet.

        I believe the most likely reason for the crash at <rdar://problem/50614019> is that NetworkProcess::m_networkSessions
        is getting corrupted and is returning us a bad pointer.

        To harden our code, I added debug assertions to make sure that this HashMap is only used on the main thread and
        to make sure that the sessionID used as key is always valid. I have also added if checks to avoid crashing in
        release whenever possible.

        Note that we came to a similar conclusion for NetworkProcess::m_swServers when investigating rdar://problem/51859081,
        so the two radars are potentially related. Both HashMaps are owned by the NetworkProcess and use a SessionID
        as key.

        * NetworkProcess/NetworkConnectionToWebProcess.cpp:
        (WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
        (WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
        (WebKit::NetworkConnectionToWebProcess::logUserInteraction):
        (WebKit::NetworkConnectionToWebProcess::logWebSocketLoading):
        (WebKit::NetworkConnectionToWebProcess::logSubresourceLoading):
        (WebKit::NetworkConnectionToWebProcess::logSubresourceRedirect):
        (WebKit::NetworkConnectionToWebProcess::hasStorageAccess):
        (WebKit::NetworkConnectionToWebProcess::requestStorageAccess):
        (WebKit::NetworkConnectionToWebProcess::requestStorageAccessUnderOpener):
        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::networkSession const):
        (WebKit::NetworkProcess::setSession):
        (WebKit::NetworkProcess::destroySession):
        (WebKit::NetworkProcess::addKeptAliveLoad):
        (WebKit::NetworkProcess::removeKeptAliveLoad):
        (WebKit::NetworkProcess::webProcessWasDisconnected):
        * NetworkProcess/NetworkProcess.h:
        * NetworkProcess/NetworkResourceLoader.cpp:
        (WebKit::NetworkResourceLoader::retrieveCacheEntry):
        (WebKit::NetworkResourceLoader::didFinishWithRedirectResponse):
        (WebKit::NetworkResourceLoader::tryStoreAsCacheEntry):
        (WebKit::NetworkResourceLoader::shouldLogCookieInformation):
        * NetworkProcess/ios/NetworkConnectionToWebProcessIOS.mm:
        (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorBoundInterfaceIdentifier):
        (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorCTDataConnectionServiceType):
        (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorSourceApplicationBundleIdentifier):
        (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorSourceApplicationSecondaryIdentifier):

2019-07-02  Chris Dumez  <cdumez@apple.com>

        VisitedLinkStore does not need to subclass WebProcessLifetimeObserver
        https://bugs.webkit.org/show_bug.cgi?id=199407

        Reviewed by Sam Weinig.

        VisitedLinkStore does not need to subclass WebProcessLifetimeObserver, it overrides
        only 2 of WebProcessLifetimeObserver's functions and the implementation of those
        overrides is empty. It also does not use WebProcessLifetimeObserver::processes()
        since the VisitedLinkStore maintains its own list of processes.

        * UIProcess/API/mac/WKView.mm:
        * UIProcess/Automation/WebAutomationSession.cpp:
        * UIProcess/VisitedLinkStore.cpp:
        * UIProcess/VisitedLinkStore.h:
        * UIProcess/WebPageProxy.cpp:
        (WebKit::m_resetRecentCrashCountTimer):
        * UIProcess/WebProcessPool.h:
        * UIProcess/WebsiteData/WebsiteDataStore.cpp:

2019-07-02  Chris Dumez  <cdumez@apple.com>

        Null dereference under StorageManager::destroySessionStorageNamespace()
        https://bugs.webkit.org/show_bug.cgi?id=199388
        <rdar://problem/52030641>

        Reviewed by Youenn Fablet.

        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::createSessionStorageNamespace):
        Call HashMap::ensure() instead of contains() + set() to avoid double hash lookup.

        (WebKit::StorageManager::destroySessionStorageNamespace):
        Add null check to address top crasher, similarly to what was done in r246552.
        I am keeping the debug assertion since this is not supposed to happen.

2019-07-02  Daniel Bates  <dabates@apple.com>

        [iOS] Cannot tab cycle through credit card fields on antonsvpatisserie.com checkout page
        https://bugs.webkit.org/show_bug.cgi?id=196053
        <rdar://problem/49093034>

        Reviewed by Wenson Hsieh.

        Allow iframes to be keyboard focusable when pressing the Tab key on the keyboard. This
        also allow the that the focus controller to search their content document for other
        editable elements. This makes iOS match the behavior on Mac.

        Although iframes can be focused by pressing the Tab key we maintain the current UI
        restriction on iOS of not allowing iframes themselves to be focusable via the next and
        previous accessory bar buttons. We do this because it's unclear what value supporting
        such focusing brings, but it's clear that doing so makes tab cycling more confusing
        since the default focus appearance for an iframe is indistinguishable from its non-
        focused appearance.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::isAssistableElement): Do not consider an iframe as assistable.

2019-07-02  Alexander Mikhaylenko  <exalm7659@gmail.com>

        [GTK] Support cancelling touchscreen back/forward gesture
        https://bugs.webkit.org/show_bug.cgi?id=199401

        Reviewed by Michael Catanzaro.

        It should be possible to cancel the gesture when performing it on
        touchscreen, for example, by moving pen too far from the screen.
        Handle this case properly.

        Only DragGesture in GestureController needs to handle this,
        SwipeGesture simply won't emit the relevant event in this case.

        * UIProcess/API/gtk/WebKitWebViewBase.cpp:
        * UIProcess/ViewGestureController.h:
        * UIProcess/gtk/GestureController.cpp:
        (WebKit::GestureController::DragGesture::cancelDrag):
        (WebKit::GestureController::DragGesture::cancel):
        (WebKit::GestureController::DragGesture::DragGesture):
        * UIProcess/gtk/GestureController.h:
        * UIProcess/gtk/ViewGestureControllerGtk.cpp:
        (WebKit::ViewGestureController::platformTeardown):
        (WebKit::ViewGestureController::cancelSwipe):

2019-07-02  Devin Rousso  <drousso@apple.com>

        Web Inspector: Debug: "Reset Web Inspector" should also clear the saved window size and attachment side
        https://bugs.webkit.org/show_bug.cgi?id=198956

        Reviewed by Matt Baker.

        * UIProcess/WebPreferences.h:
        * UIProcess/WebPreferences.cpp:
        (WebKit::WebPreferences::deleteKey): Added.
        * UIProcess/gtk/WebPreferencesGtk.cpp:
        (WebKit::WebPreferences::platformDeleteKey): Added.
        * UIProcess/mac/WebPreferencesMac.mm:
        (WebKit::WebPreferences::platformDeleteKey): Added.
        * UIProcess/wpe/WebPreferencesWPE.cpp:
        (WebKit::WebPreferences::platformDeleteKey): Added.
        * UIProcess/win/WebPreferencesWin.cpp:
        (WebKit::WebPreferences::platformDeleteKey): Added.
        * Shared/WebPreferencesStore.h:
        * Shared/WebPreferencesStore.cpp:
        (WebKit::WebPreferencesStore::deleteKey): Added.

        * UIProcess/WebInspectorProxy.messages.in:
        * UIProcess/WebInspectorProxy.h:
        * UIProcess/WebInspectorProxy.cpp:
        (WebKit::WebInspectorProxy::resetWindowState): Added.
        (WebKit::WebInspectorProxy::platformResetWindowState): Added.
        * UIProcess/gtk/WebInspectorProxyGtk.cpp:
        (WebKit::WebInspectorProxy::platformResetWindowState): Added.
        * UIProcess/mac/WebInspectorProxyMac.mm:
        (WebKit::WebInspectorProxy::platformResetWindowState): Added.
        * UIProcess/wpe/WebInspectorProxyWPE.cpp:
        (WebKit::WebInspectorProxy::platformResetWindowState): Added.
        * UIProcess/win/WebInspectorProxyWin.cpp:
        (WebKit::WebInspectorProxy::platformResetWindowState): Added.
        * WebProcess/WebPage/WebInspectorUI.h:
        * WebProcess/WebPage/WebInspectorUI.cpp:
        (WebKit::WebInspectorUI::resetWindowState): Added.

        * UIProcess/RemoteWebInspectorProxy.messages.in:
        * UIProcess/RemoteWebInspectorProxy.h:
        * UIProcess/RemoteWebInspectorProxy.cpp:
        (WebKit::RemoteWebInspectorProxy::resetWindowState): Added.
        (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added.
        * UIProcess/gtk/RemoteWebInspectorProxyGtk.cpp:
        (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added.
        * UIProcess/mac/RemoteWebInspectorProxyMac.mm:
        (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added.
        * UIProcess/win/RemoteWebInspectorProxyWin.cpp:
        (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added.
        * WebProcess/WebPage/RemoteWebInspectorUI.h:
        * WebProcess/WebPage/RemoteWebInspectorUI.cpp:
        (WebKit::RemoteWebInspectorUI::resetWindowState): Added.

2019-07-01  Chris Dumez  <cdumez@apple.com>

        Remove virtual functions on WebProcessLifetimeObserver that are unused after r245540
        https://bugs.webkit.org/show_bug.cgi?id=199383

        Reviewed by Alex Christensen.

        * UIProcess/WebProcessLifetimeObserver.h:
        (WebKit::WebProcessLifetimeObserver::webProcessDidCloseConnection):
        * UIProcess/WebProcessLifetimeTracker.cpp:
        (WebKit::WebProcessLifetimeTracker::addObserver):
        (WebKit::WebProcessLifetimeTracker::pageWasInvalidated):

2019-07-01  Chris Dumez  <cdumez@apple.com>

        StorageManager::SessionStorageNamespace::allowedConnections() should not copy the HashSet
        https://bugs.webkit.org/show_bug.cgi?id=199379

        Reviewed by Alex Christensen.

        This was pretty inefficient.

        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::SessionStorageNamespace::allowedConnections const):

2019-07-01  Wenson Hsieh  <wenson_hsieh@apple.com>

        [iOS] REGRESSION (r246757): Unable to select non-editable text in subframes
        https://bugs.webkit.org/show_bug.cgi?id=199366
        <rdar://problem/52460509>

        Reviewed by Tim Horton.

        r246757 removed logic in selectionPositionInformation responsible for setting the focused frame when handling a
        position information request. As the FIXME formerly in InteractionInformationRequest.h alluded to, text
        selection gestures on iOS were dependent on this behavior when selecting text in subframes, since text selection
        helpers in WebPageIOS.mm assume that the focused frame already contains the selection being set.

        Rather than calling setFocusedFrame when requesting position information, we can fix this by making
        WebPage::selectWithGesture and WebPage::selectTextWithGranularityAtPoint both set the focused frame if needed
        before extending or moving text selections.

        Covered by layout tests that began to fail after r246757:
        - editing/selection/ios/selection-handles-in-iframe.html
        - editing/selection/ios/selection-handle-clamping-in-iframe.html

        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::selectWithGesture):

        Only call the new helper method, setFocusedFrameBeforeSelectingTextAtLocation, at the start of the gesture.

        (WebKit::WebPage::setFocusedFrameBeforeSelectingTextAtLocation):
        (WebKit::WebPage::selectTextWithGranularityAtPoint):

2019-07-01  Alex Christensen  <achristensen@webkit.org>

        Add new decidePolicyForNavigationAction SPI with preferences and userInfo
        https://bugs.webkit.org/show_bug.cgi?id=199371
        <rdar://problem/52352905>

        Reviewed by Tim Horton.

        Also deprecate some older SPI so we may someday clean up this mess.

        * UIProcess/API/Cocoa/WKNavigationDelegatePrivate.h:
        * UIProcess/Cocoa/NavigationState.h:
        * UIProcess/Cocoa/NavigationState.mm:
        (WebKit::NavigationState::setNavigationDelegate):
        (WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction):
        (WebKit::NavigationState::NavigationClient::shouldBypassContentModeSafeguards const):

2019-07-01  Alex Christensen  <achristensen@webkit.org>

        Deprecate but still call _webView:showCustomSheetForElement: after transition to UIContextMenuInteraction
        https://bugs.webkit.org/show_bug.cgi?id=199296
        <rdar://problem/51041960>

        Reviewed by Darin Adler.

        * UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _showAttachmentSheet]):
        (-[WKContentView actionSheetAssistant:showCustomSheetForElement:]):
        (-[WKContentView continueContextMenuInteraction:]):

2019-07-01  Alex Christensen  <achristensen@webkit.org>

        Add main thread assertions in sendWithAsyncReply code
        https://bugs.webkit.org/show_bug.cgi?id=199324

        Reviewed by Sam Weinig.

        sendWithAsyncReply can only be used on the main thread because
        the CompletionHandler will be called on the main thread, and if it's
        called from a background thread, then HashMap corruption will likely happen.
        Add assertions to alert developers that they should only call sendWithAsyncReply
        from the main thread.

        This is responding to good feedback from r237294

        * Platform/IPC/Connection.cpp:
        (IPC::asyncReplyHandlerMap):
        (IPC::nextAsyncReplyHandlerID):
        (IPC::addAsyncReplyHandler):
        (IPC::clearAsyncReplyHandlers):
        (IPC::CompletionHandler<void):

2019-07-01  Eric Carlson  <eric.carlson@apple.com>

        [iOS] Exiting from fullscreen scrolls to top of page
        https://bugs.webkit.org/show_bug.cgi?id=199338
        <rdar://problem/51273017>

        Reviewed by Jer Noble.

        * UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
        (-[WKFullScreenWindowController _completedExitFullScreen]): Restore scroll position.
        Hide window after restoring scroll position.
        (-[WKFullScreenWindowController _exitFullscreenImmediately]): Drive-by fix: remove code
        already also done in _completedExitFullScreen.

2019-07-01  Zalan Bujtas  <zalan@apple.com>

        Tapping on the bottom part of youtube video behaves as if controls were visible
        https://bugs.webkit.org/show_bug.cgi?id=199349
        <rdar://problem/51955744>

        Reviewed by Simon Fraser.

        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::handleTouchEvent):
        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::handleSyntheticClick):
        (WebKit::WebPage::completePendingSyntheticClickForContentChangeObserver):
        (WebKit::WebPage::completeSyntheticClick):
        (WebKit::WebPage::potentialTapAtPosition):

2019-07-01  Wenson Hsieh  <wenson_hsieh@apple.com>

        iOS: REGRESSION(async scroll): Caret doesn't scroll when scrolling textarea
        https://bugs.webkit.org/show_bug.cgi?id=198217
        <rdar://problem/51097296>

        Reviewed by Simon Fraser.

        In iOS 12, when scrolling a text selection in an fast-scrolling container, editor state updates are scheduled
        under AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll after the end of the scrolling gesture,
        when the scrolling layer action is ScrollingLayerPositionAction::Set. This is no longer the case in iOS 13,
        because we now bail in ScrollingTreeScrollingNode::wasScrolledByDelegatedScrolling after scroll deceleration
        finishes since the scroll position didn't end up changing. Additionally, we no longer use
        ScrollingLayerPositionAction::Set in the case where scrolling finished decelerating, since
        ScrollingTreeScrollingNodeDelegateIOS::scrollViewDidScroll no longer uses to value of inUserInteraction to
        determine whether to Set or Sync scrolling layer positions.

        To restore iOS 12 behavior, ensure that we send a scrolling tree update using ScrollingLayerPositionAction::Set
        after scrolling ends.

        * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm:
        (WebKit::ScrollingTreeScrollingNodeDelegateIOS::scrollViewDidScroll):

2019-07-01  Per Arne Vollan  <pvollan@apple.com>

        Perform less work when a pre-warmed WebProcess is suspended or resumed.
        https://bugs.webkit.org/show_bug.cgi?id=199195

        Reviewed by Darin Adler.

        Return early from WebProcess::actualPrepareToSuspend and WebProcess::processDidResume
        if this is a pre-warmed process. This is a confirmed improvement in page load time.

        * WebProcess/WebProcess.cpp:
        (WebKit::WebProcess::actualPrepareToSuspend):
        (WebKit::WebProcess::cancelPrepareToSuspend):
        (WebKit::WebProcess::processDidResume):

2019-07-01  Carlos Garcia Campos  <cgarcia@igalia.com>

        WebSockets: add support for sending blob messages when using web sockets platform APIs
        https://bugs.webkit.org/show_bug.cgi?id=199189

        Reviewed by Youenn Fablet.

        Add helper private class BlobLoader that uses FileReaderLoader to load the blobs. Since blob loads are
        asynchronous, the messages are queued using another helper internal class PendingMessage.

        * WebProcess/Network/WebSocketChannel.cpp:
        (WebKit::WebSocketChannel::increaseBufferedAmount): Increase the buffered amount checking we don't overlofw.
        (WebKit::WebSocketChannel::decreaseBufferedAmount): Decrease the buffered amount.
        (WebKit::WebSocketChannel::sendMessage): Helper class to send message to the network process and decrease the
        buffered amount when done.
        (WebKit::WebSocketChannel::send): Queue the message in pending queue if there are pending messages in the queue
        for text and binary messages. For blobs, always queue the message unless it's an empty blob that we can handle
        as empty binary data directly.
        (WebKit::PendingMessage::PendingMessage): Helper class to queue message requests.
        (WebKit::PendingMessage::type const): Type of message: Text, Binary, Blob.
        (WebKit::PendingMessage::textMessage const): The text message.
        (WebKit::PendingMessage::binaryData const): The binary data.
        (WebKit::PendingMessage::blobLoader const): The blob loader.
        (WebKit::WebSocketChannel::fail): Notify the client about the error to ensure onclose is emitted.
        (WebKit::WebSocketChannel::disconnect): Clear the pending messages queue.
        * WebProcess/Network/WebSocketChannel.h:

2019-07-01  Miguel Gomez  <magomez@igalia.com>

        [WPE][GTK] Content disappearing when using CSS transforms
        https://bugs.webkit.org/show_bug.cgi?id=181757

        Reviewed by Žan Doberšek.

        Set the appropriate AnimatedBackingStoreClient to the TextureMapperLayers when required.

        * Shared/CoordinatedGraphics/CoordinatedGraphicsScene.cpp:
        (WebKit::CoordinatedGraphicsScene::updateSceneState):

2019-06-30  Antti Koivisto  <antti@apple.com>

        Use separate variables for moving and stationary scrolling relationships in RemoteLayerTreeNode
        https://bugs.webkit.org/show_bug.cgi?id=199348

        Reviewed by Darin Adler.

        A layer can have only one acting scroll parent. Not using a vector for that case makes the code clearer.

        * UIProcess/RemoteLayerTree/RemoteLayerTreeNode.h:
        (WebKit::RemoteLayerTreeNode::actingScrollContainerID const):
        (WebKit::RemoteLayerTreeNode::stationaryScrollContainerIDs const):

        Separate fields for the acting container and stationary containers.

        (WebKit::RemoteLayerTreeNode::setActingScrollContainerID):
        (WebKit::RemoteLayerTreeNode::setStationaryScrollContainerIDs):
        (WebKit::RemoteLayerTreeNode::relatedScrollContainerIDs const): Deleted.
        (WebKit::RemoteLayerTreeNode::relatedScrollContainerPositioningBehavior const): Deleted.
        * UIProcess/RemoteLayerTree/RemoteLayerTreeNode.mm:
        (WebKit::RemoteLayerTreeNode::setRelatedScrollContainerBehaviorAndIDs): Deleted.
        * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
        (WebKit::isScrolledBy):
        (WebKit::findActingScrollParent):
        * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
        (WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations):

2019-06-30  Fujii Hironori  <Hironori.Fujii@sony.com>

        [Win] Multiline mode of tooltip control does word-wrapping very slowly
        https://bugs.webkit.org/show_bug.cgi?id=198989

        Reviewed by Ross Kirsling.

        * UIProcess/win/WebView.cpp:
        (WebKit::truncatedString): Added.
        (WebKit::WebView::setToolTip): Use truncatedString.

2019-06-30  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        Pass WebProcess information to platformInitializeWebProcess().
        https://bugs.webkit.org/show_bug.cgi?id=199345

        Reviewed by Darin Adler.

        Add const reference to WebProcessProxy for first argument of
        WebProcessPool::platformInitializeWebProcess().

        * UIProcess/Cocoa/WebProcessPoolCocoa.mm:
        (WebKit::WebProcessPool::platformInitializeWebProcess):
        * UIProcess/WebProcessPool.cpp:
        (WebKit::WebProcessPool::initializeNewWebProcess):
        * UIProcess/WebProcessPool.h:
        * UIProcess/glib/WebProcessPoolGLib.cpp:
        (WebKit::WebProcessPool::platformInitializeWebProcess):
        * UIProcess/win/WebProcessPoolWin.cpp:
        (WebKit::WebProcessPool::platformInitializeWebProcess):

2019-06-28  Brent Fulgham  <bfulgham@apple.com>

        Revise WebContent sandbox based on seed feedback
        https://bugs.webkit.org/show_bug.cgi?id=199339
        <rdar://problem/49609201>

        Reviewed by Alexey Proskuryakov.

        Unblock syscall needed by CoreText.

        * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:
        * WebProcess/com.apple.WebProcess.sb.in:

2019-06-28  Tim Horton  <timothy_horton@apple.com>

        iOS WebKit2 find-in-page indicator doesn't move with 'overflow: scroll'
        https://bugs.webkit.org/show_bug.cgi?id=175032
        <rdar://problem/29346482>

        Reviewed by Wenson Hsieh.

        * WebProcess/WebPage/FindController.cpp:
        (WebKit::FindController::drawRect):
        (WebKit::FindController::didScrollAffectingFindIndicatorPosition):
        Adopt the macOS code that notices that the find highlight doesn't match
        its original position, but instead of hiding the highlight like we do on macOS,
        update it. We do this asynchronously to avoid mutating the layer tree
        in the middle of painting, which is not /truly/ unsafe, but definitely
        non-ideal and causes fun flashes.

        * WebProcess/WebPage/FindController.h:
        * WebProcess/WebPage/ios/FindControllerIOS.mm:
        (WebKit::FindController::updateFindIndicator):
        Store m_findIndicatorRect when updating the indicator, just like we do on macOS.

2019-06-28  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed build fix attempt after r246928.

        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _closeAllMediaPresentations]):

2019-06-28  Youenn Fablet  <youenn@apple.com>

        Protect NetworkProcess::m_swServers from bad session IDs
        https://bugs.webkit.org/show_bug.cgi?id=199298
        <rdar://problem/51859081>

        Reviewed by Chris Dumez.

        Protect NetworkProcess from receiving bad session IDs in service worker code path by checking for session ID validity whenever interacting with the map.
        One of the check is done in WebProcess in which case, if the session ID is bad, the SW connection to NetworkProcess will not be made.
        For bad session IDs, this will in that case trigger timing out of service worker operations.

        For get/clear data, exit early in case of bad session ID.

        Made some refactoring to remove swOriginStoreForSession method.
        In the one call site where it is used, the store should already be created so we reuse existingSWOriginStoreForSession.

        Added a bunch of additional ASSERTs.

        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::destroySession):
        (WebKit::NetworkProcess::fetchWebsiteData):
        (WebKit::NetworkProcess::deleteWebsiteData):
        (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains):
        (WebKit::NetworkProcess::registrableDomainsWithWebsiteData):
        (WebKit::NetworkProcess::actualPrepareToSuspend):
        (WebKit::NetworkProcess::swServerForSession):
        (WebKit::NetworkProcess::existingSWOriginStoreForSession const):
        (WebKit::NetworkProcess::registerSWServerConnection):
        * NetworkProcess/NetworkProcess.h:
        * WebProcess/Network/NetworkProcessConnection.cpp:
        (WebKit::NetworkProcessConnection::initializeSWClientConnection):
        * WebProcess/Storage/WebSWClientConnection.cpp:
        (WebKit::WebSWClientConnection::WebSWClientConnection):
        (WebKit::WebSWClientConnection::initializeConnectionIfNeeded):
        (WebKit::WebSWClientConnection::ensureConnectionAndSend):

2019-06-28  Timothy Hatcher  <timothy@apple.com>

        Rename effectiveAppearanceIsInactive and useInactiveAppearance to better match UIUserInterfaceLevel.
        https://bugs.webkit.org/show_bug.cgi?id=199336
        rdar://problem/52348938

        Reviewed by Tim Horton.

        * Shared/WebPageCreationParameters.cpp:
        (WebKit::WebPageCreationParameters::encode const):
        (WebKit::WebPageCreationParameters::decode):
        * Shared/WebPageCreationParameters.h:
        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _effectiveUserInterfaceLevelIsElevated]):
        (-[WKWebView _effectiveAppearanceIsInactive]): Deleted.
        * UIProcess/API/Cocoa/WKWebViewInternal.h:
        * UIProcess/Cocoa/WebViewImpl.h:
        * UIProcess/Cocoa/WebViewImpl.mm:
        (WebKit::WebViewImpl::effectiveUserInterfaceLevelIsElevated):
        (WebKit::WebViewImpl::effectiveAppearanceIsInactive): Deleted.
        * UIProcess/PageClient.h:
        (WebKit::PageClient::effectiveUserInterfaceLevelIsElevated const):
        (WebKit::PageClient::effectiveAppearanceIsInactive const): Deleted.
        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::creationParameters):
        (WebKit::WebPageProxy::useElevatedUserInterfaceLevel const):
        (WebKit::WebPageProxy::effectiveAppearanceDidChange):
        (WebKit::WebPageProxy::useInactiveAppearance const): Deleted.
        * UIProcess/WebPageProxy.h:
        * UIProcess/ios/PageClientImplIOS.h:
        * UIProcess/ios/PageClientImplIOS.mm:
        (WebKit::PageClientImpl::effectiveUserInterfaceLevelIsElevated const):
        (WebKit::PageClientImpl::effectiveAppearanceIsInactive const): Deleted.
        * UIProcess/mac/PageClientImplMac.h:
        * UIProcess/mac/PageClientImplMac.mm:
        (WebKit::PageClientImpl::effectiveUserInterfaceLevelIsElevated const):
        (WebKit::PageClientImpl::effectiveAppearanceIsInactive const): Deleted.
        * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
        (WKBundlePageSetUseDarkAppearance):
        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::m_shrinkToFitContentTimer):
        (WebKit::WebPage::effectiveAppearanceDidChange):
        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/WebPage.messages.in:

2019-06-28  Jer Noble  <jer.noble@apple.com>

        Unreviewed maccatalyst build fix; add ENABLE(FULLSCREEN) checks around calls to fullScreenManager().

        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _closeAllMediaPresentations]):

2019-06-28  Tim Horton  <timothy_horton@apple.com>

        macCatalyst: Selected range sometimes wrong after autocorrection
        https://bugs.webkit.org/show_bug.cgi?id=199299
        <rdar://problem/49717224>

        Reviewed by Wenson Hsieh.

        * UIProcess/Cocoa/TextCheckingController.h:
        * UIProcess/Cocoa/TextCheckingController.mm:
        (WebKit::TextCheckingController::replaceRelativeToSelection):
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView replaceSelectionOffset:length:withAnnotatedString:relativeReplacementRange:]):
        Plumb the whole relative replacement range through to the Web Content process.

        * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.h:
        * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.messages.in:
        * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.mm:
        (WebKit::TextCheckingControllerProxy::replaceRelativeToSelection):
        Only replace the text of the substring that changed (the replacement range),
        and fix up the selection offset math (it was really just wrong before).

2019-06-28  Wenson Hsieh  <wenson_hsieh@apple.com>

        Need a way for SPI clients to know when to avoid resizing to accommodate for the input view bounds
        https://bugs.webkit.org/show_bug.cgi?id=199331
        <rdar://problem/52116170>

        Reviewed by Tim Horton.

        Expose new SPI, such that clients may check whether to avoid resizing the web view when changing input view
        bounds. In particular, resizing the web view in this case causes toolbar menus in Microsoft Word online to
        dismiss immediately after opening them, due to resize events fired as a result of the input view dismissing.

        * Shared/FocusedElementInformation.cpp:
        (WebKit::FocusedElementInformation::encode const):
        (WebKit::FocusedElementInformation::decode):
        * Shared/FocusedElementInformation.h:

        Add a new flag to FocusedElementInformation to indicate whether we should avoid resizing the web view when an
        input view is presented.

        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _shouldAvoidResizingWhenInputViewBoundsChange]):
        * UIProcess/API/Cocoa/WKWebViewPrivate.h:
        * UIProcess/ios/WKContentViewInteraction.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _elementDidBlur]):

        Reset the value of the flag.

        (-[WKContentView _shouldAvoidResizingWhenInputViewBoundsChange]):
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::getFocusedElementInformation):

2019-06-28  Jer Noble  <jer.noble@apple.com>

        Add new -[WKWebView _closeAllMediaPresentations] SPI
        https://bugs.webkit.org/show_bug.cgi?id=199294
        <rdar://problem/51965958>

        Reviewed by Alex Christensen.

        Add a new SPI that will close all out-of-window media presentations, including
        picture-in-picture, video fullscreen, and element fullscreen.

        Drive-by fixes:

        + -[WKApplicationStateTrackingView didMoveToWindow] incorrectly assumes that a WKWebView will
          never be moved frome one window to another, and asserts.

        + -[WKFullScreenWindowController close] doesn't fire the correct 'webkitfullscreenchange' event
          when called in the middle of animating into fullscreen.

        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _closeAllMediaPresentations]):
        * UIProcess/API/Cocoa/WKWebViewPrivate.h:
        * UIProcess/Cocoa/VideoFullscreenManagerProxy.h:
        * UIProcess/Cocoa/VideoFullscreenManagerProxy.mm:
        (WebKit::VideoFullscreenManagerProxy::forEachSession):
        * UIProcess/ios/WKApplicationStateTrackingView.mm:
        (-[WKApplicationStateTrackingView didMoveToWindow]):
        * UIProcess/mac/WKFullScreenWindowController.h:
        * UIProcess/mac/WKFullScreenWindowController.mm:
        (-[WKFullScreenWindowController exitFullScreenImmediately]):
        (-[WKFullScreenWindowController close]):

2019-06-28  Antti Koivisto  <antti@apple.com>

        [iOS Scrolling] Propagate scrolls to non-nested UIScrollViews
        https://bugs.webkit.org/show_bug.cgi?id=199222

        Reviewed by Simon Fraser.

        We may generate scrolling hierarchies where the scrolling ancestor of a layer is not
        an ancestor in the layer tree. We  handle this in most situations but there is still
        a problem where a scroller fails to propage scroll to the ancestor when it reaches
        the edge.

        This patch hooks up a new SPI that allows us to tell UIKit about non-ancestor scrolling
        relations and solve this problem.

        * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.h:
        * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
        (WebKit::findActingScrollParent):
        * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.h:
        * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm:
        (-[WKScrollingNodeScrollViewDelegate _actingParentScrollViewForScrollView:]):

        Hook into UIKit SPI.

        (WebKit::ScrollingTreeScrollingNodeDelegateIOS::findActingScrollParent):

2019-06-28  Konstantin Tokarev  <annulen@yandex.ru>

        Remove traces of ENABLE_ICONDATABASE remaining after its removal in 219733
        https://bugs.webkit.org/show_bug.cgi?id=199317

        Reviewed by Michael Catanzaro.

        While IconDatabase and all code using it was removed,
        ENABLE_ICONDATABASE still exists as build option and C++ macro.

        * Configurations/FeatureDefines.xcconfig:
        * PlatformGTK.cmake: Remove reference to unused urlIcon.png file.

2019-06-28  Wenson Hsieh  <wenson_hsieh@apple.com>

        -[WKContentView _selectionClipRects] returns a bogus value in -reloadInputViews when focusing an element
        https://bugs.webkit.org/show_bug.cgi?id=199310
        <rdar://problem/52292137>

        Reviewed by Megan Gardner.

        When reloading input views under -_elementDidFocus:, -_selectionClipRect returns the value of the previously
        focused element; this is because _selectionClipRect depends on EditorState's post layout data, which is only
        guaranteed to arrive during the next remote layer tree commit after the element is focused.

        However, some clients need to inspect this value under the call to -reloadInputViews when an element is focused;
        to make this work, simply check whether we are currently waiting for post-layout EditorState data to arrive
        following element focus; if so, return the FocusedElementInformation's elementRect, which represents the initial
        state of the focused element. Otherwise, use the EditorState's post layout data, which is guaranteed to be more
        up-to-date than the FocusedElementInformation's element rect.

        Test: KeyboardInputTests.SelectionClipRectsWhenPresentingInputView

        * UIProcess/WebPageProxy.h:
        (WebKit::WebPageProxy::waitingForPostLayoutEditorStateUpdateAfterFocusingElement const):
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _selectionClipRect]):

2019-06-28  Carlos Garcia Campos  <cgarcia@igalia.com>

        [SOUP] WebSockets: runtime critical warning when closing the connection in some cases
        https://bugs.webkit.org/show_bug.cgi?id=199265

        Reviewed by Michael Catanzaro.

        Ensure the connection is still open before calling soup_websocket_connection_close().

        * NetworkProcess/soup/WebSocketTaskSoup.cpp:
        (WebKit::WebSocketTask::close):

2019-06-27  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed WPE build fix.

        * SourcesWPE.txt: Add WebSocketTaskSoup.cpp to the build.

2019-06-27  Dean Jackson  <dino@apple.com>

        Provide overrides for UIKit's suggested actions in UIContextMenuInteraction
        https://bugs.webkit.org/show_bug.cgi?id=199301
        <rdar://problem/52297380>

        Reviewed by Tim Horton.

        We were previously wrapping the actionMenuProvider with our own block
        in order to ensure the correct suggestedActions were passed to the provider.
        UIKit added API for us to override the actions separately.

        Unfortunately we can't quite yet get rid of our access into the
        UIContextMenuConfiguration, because we still need to override the preview
        handler in the case where the user does not want link previews.

        * Platform/spi/ios/UIKitSPI.h:
        * UIProcess/ios/WKContentViewInteraction.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView continueContextMenuInteraction:]):
        (-[WKContentView _contextMenuInteraction:overrideSuggestedActionsForConfiguration:]):
        Implement the new delegate SPI to provide our own actions.

2019-06-27  Daniel Bates  <dabates@apple.com>

        [iOS] Select all with existing range selection replaces range instead of selecting all text
        https://bugs.webkit.org/show_bug.cgi?id=197950
        <rdar://problem/50245131>

        Reviewed by Wenson Hsieh.

        Following <rdar://problem/47333786>, UIKit now asks WebKit whether it can handle Command + A as
        "select all" instead of just demanding that we handle it. So, WebKit needs to be able to correctly
        tell UIKit in advance whether it can handle it. Currenlty WebKit tells UIKit it cannot handle a
        "select all" whenever there is an existing range selection. So, UIKit does not tell WebKit to
        perform the "select all". Moreover, since UIKit has no other means to handle this key command
        itself it tells WebKit the key command was not handled. So, WebKit tells the keyboard to insert
        the "a". Instead, WebKit should tell UIKit it can handle a "select all" even when this is an
        existing range selection. However we need to keep the current logic just for when UIKit is
        asking us with respect to populating the callout menu to not regress platform behavior.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView canPerformActionForWebView:withSender:]): Do what we do now if we are called
        when populating the callout menu and action is Select All. Otherwise, return YES for the Select All
        action if we have a non-empty selection.

2019-06-27  Andy Estes  <aestes@apple.com>

        [iOS] Stop using cached UITargetedPreviews from previous interactions when starting a new context menu interaction
        https://bugs.webkit.org/show_bug.cgi?id=199285
        <rdar://problem/52074916>

        Reviewed by Tim Horton.

        WKContentView was caching the UITargetedPreview created in
        -contextMenuInteraction:previewForHighlightingMenuWithConfiguration: for later reuse by
        -contextMenuInteraction:previewForDismissingMenuWithConfiguration:. The cached value was
        then cleared in -contextMenuInteractionDidEnd:.

        This was wrong, because -contextMenuInteractionDidEnd: can be called before
        -contextMenuInteraction:previewForDismissingMenuWithConfiguration:, so we would clear the
        cache then create and cache a new UITargetedPreview during dismissal. Then when a new
        context menu interaction started, we'd reuse the targeted preview created for the previous
        dismissal (which has the wrong geometry).

        Stop assuming an ordering between
        -contextMenuInteraction:previewForDismissingMenuWithConfiguration: and
        -contextMenuInteractionDidEnd:. Instead, always create and cache a new UITargetedPreview in
        -contextMenuInteraction:previewForHighlightingMenuWithConfiguration:, then reuse it and
        clear the cache in -contextMenuInteraction:previewForDismissingMenuWithConfiguration:.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _createTargetedPreviewIfPossible]):
        (-[WKContentView contextMenuInteraction:previewForDismissingMenuWithConfiguration:]):
        (-[WKContentView contextMenuInteractionDidEnd:]):

2019-06-27  Sihui Liu  <sihui_liu@apple.com>

        Regression(r246526): StorageManager thread hangs
        https://bugs.webkit.org/show_bug.cgi?id=199278
        <rdar://problem/52202948>

        Reviewed by Geoffrey Garen.

        r246526 adds a lock m_localStorageNamespacesMutex to protect m_localStorageNamespaces, because 
        m_localStorageNamespaces is destroyed at main thread while accesses to m_localStorageNamespaces happen in the 
        background thread.
        After r246526, getOrCreateLocalStorageNamespace acquires lock m_localStorageNamespacesMutex when 
        m_localStorageNamespacesMutex is already acquired in cloneSessionStorageNamespace, so the StorageManager thread
        hangs.
        To solve this issue, we can remove the lock in getOrCreateLocalStorageNamespace, or we can remove the 
        m_localStorageNamespacesMutex. waitUntilWritesFinished() before ~StorageManager() already guarantees nothing 
        will be running in the background thread, so it is unlikely we the access to m_localStorageNamespaces in the 
        background thread would collide with the destruction of m_localStorageNamespaces. Also, we don't need 
        didDestroyStorageArea as LocalStorageNamespace can hold the last reference of StorageArea after r245881.

        * NetworkProcess/WebStorage/StorageManager.cpp:
        (WebKit::StorageManager::StorageArea::StorageArea):
        (WebKit::StorageManager::StorageArea::~StorageArea):
        (WebKit::StorageManager::LocalStorageNamespace::LocalStorageNamespace):
        (WebKit::StorageManager::cloneSessionStorageNamespace):
        (WebKit::StorageManager::getLocalStorageOrigins):
        (WebKit::StorageManager::deleteLocalStorageEntriesForOrigin):
        (WebKit::StorageManager::deleteLocalStorageOriginsModifiedSince):
        (WebKit::StorageManager::deleteLocalStorageEntriesForOrigins):
        (WebKit::StorageManager::getOrCreateLocalStorageNamespace):
        (WebKit::StorageManager::LocalStorageNamespace::didDestroyStorageArea): Deleted.
        * NetworkProcess/WebStorage/StorageManager.h:

2019-06-27  Carlos Garcia Campos  <cgarcia@igalia.com>

        WebSockets: avoid data copies when queuing tasks in WebSocketChannel
        https://bugs.webkit.org/show_bug.cgi?id=199262

        Reviewed by Alex Christensen.

        For IPC message handler arguments we can receive rvalue references instead of const references.

        * WebProcess/Network/WebSocketChannel.cpp:
        (WebKit::WebSocketChannel::didConnect):
        (WebKit::WebSocketChannel::didReceiveText):
        (WebKit::WebSocketChannel::didReceiveBinaryData):
        (WebKit::WebSocketChannel::didClose):
        (WebKit::WebSocketChannel::didReceiveMessageError):
        * WebProcess/Network/WebSocketChannel.h:

2019-06-27  Youenn Fablet  <youenn@apple.com>

        Fix build after revision 246877
        https://bugs.webkit.org/show_bug.cgi?id=199276

        Unreviewed.

        Pass protocol parameter to NetworkSocketChannel.

        * NetworkProcess/cocoa/NetworkSessionCocoa.mm:
        (-[WKNetworkSessionDelegate URLSession:webSocketTask:didOpenWithProtocol:]):
        * NetworkProcess/cocoa/WebSocketTaskCocoa.h:
        * NetworkProcess/cocoa/WebSocketTaskCocoa.mm:
        (WebKit::WebSocketTask::didConnect):

2019-06-27  Beth Dakin  <bdakin@apple.com>

        Upstream use of MACCATALYST
        https://bugs.webkit.org/show_bug.cgi?id=199245
        rdar://problem/51687723

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/Network-iOSMac.entitlements: Removed.
        * Configurations/Network-macCatalyst.entitlements: Copied from Source/WebKit/Configurations/Network-iOSMac.entitlements.
        * Configurations/NetworkService.xcconfig:
        * Configurations/SDKVariant.xcconfig:
        * Configurations/WebContent-iOSMac.entitlements: Removed.
        * Configurations/WebContent-macCatalyst.entitlements: Copied from Source/WebKit/Configurations/WebContent-iOSMac.entitlements.
        * Configurations/WebContentService.xcconfig:
        * Configurations/WebKit.xcconfig:
        * NetworkProcess/ios/NetworkProcessIOS.mm:
        * NetworkProcess/mac/NetworkProcessMac.mm:
        (WebKit::NetworkProcess::initializeProcess):
        (WebKit::NetworkProcess::initializeProcessName):
        * Platform/mac/LayerHostingContext.mm:
        (WebKit::LayerHostingContext::createForExternalHostingProcess):
        * Platform/spi/ios/ManagedConfigurationSPI.h:
        * Platform/spi/ios/UIKitSPI.h:
        * Shared/WebPreferencesDefaultValues.cpp:
        (WebKit::defaultCustomPasteboardDataEnabled):
        * Shared/ios/AuxiliaryProcessIOS.mm:
        (WebKit::AuxiliaryProcess::initializeSandbox):
        * Shared/ios/InteractionInformationAtPosition.h:
        * Shared/ios/InteractionInformationAtPosition.mm:
        (WebKit::InteractionInformationAtPosition::encode const):
        (WebKit::InteractionInformationAtPosition::decode):
        * Shared/mac/AuxiliaryProcessMac.mm:
        (WebKit::enableSandboxStyleFileQuarantine):
        * Shared/mac/CodeSigning.mm:
        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _webViewPrintFormatter]):
        * UIProcess/API/Cocoa/WKWebViewInternal.h:
        * UIProcess/API/Cocoa/WKWebViewPrivate.h:
        * UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm:
        (WebKit::RemoteLayerTreeHost::updateLayerTree):
        * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
        (-[WKRemoteView initWithFrame:contextID:]):
        * UIProcess/_WKWebViewPrintFormatter.mm:
        * UIProcess/_WKWebViewPrintFormatterInternal.h:
        * UIProcess/ios/WKActionSheetAssistant.mm:
        (-[WKActionSheetAssistant _elementActionForDDAction:]):
        * UIProcess/ios/WKContentView.mm:
        (-[WKContentView _commonInitializationWithProcessPool:configuration:]):
        * UIProcess/ios/WKContentViewInteraction.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView setupInteraction]):
        (-[WKContentView cleanupInteraction]):
        (-[WKContentView _removeDefaultGestureRecognizers]):
        (-[WKContentView _addDefaultGestureRecognizers]):
        (-[WKContentView _showTapHighlight]):
        (-[WKContentView gestureRecognizer:canBePreventedByGestureRecognizer:]):
        (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]):
        (-[WKContentView canPerformActionForWebView:withSender:]):
        (-[WKContentView _defineForWebView:]):
        (-[WKContentView setSelectedTextRange:]):
        (-[WKContentView closestPositionToPoint:]):
        (-[WKContentView _showShareSheet:inRect:completionHandler:]):
        * UIProcess/ios/WebPageProxyIOS.mm:
        (WebKit::desktopClassBrowsingSupported):
        (WebKit::desktopClassBrowsingRecommended):
        * UIProcess/ios/forms/WKFileUploadPanel.mm:
        (-[WKFileUploadPanel _showDocumentPickerMenu]):
        * WebKit.xcodeproj/project.pbxproj:
        * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.mm:
        * WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
        (WebKit::WebPage::dictionaryPopupInfoForRange):
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::platformEditorState const):
        (WebKit::WebPage::selectWithGesture):
        (WebKit::selectionPositionInformation):
        * WebProcess/cocoa/WebProcessCocoa.mm:
        (WebKit::WebProcess::initializeSandbox):
        * WebProcess/com.apple.WebProcess.sb.in:

2019-06-27  Saam Barati  <sbarati@apple.com>

        Make WEBGPU enabled only on Mojave and later.

        Rubber-stamped by Myles C. Maxfield.

        * Configurations/FeatureDefines.xcconfig:

2019-06-27  Adrian Perez de Castro  <aperez@igalia.com>

        [GTK][WPE] Fix build non-unified builds after r246856
        https://bugs.webkit.org/show_bug.cgi?id=199263

        Reviewed by Michael Catanzaro.

        * UIProcess/API/C/WKMessageListener.cpp: Added missing inclusion of WKAPICast.h and usage of WebKit namespace.

2019-06-27  Carlos Garcia Campos  <cgarcia@igalia.com>

        [SOUP] WebSockets: handle TLS certificate and errors
        https://bugs.webkit.org/show_bug.cgi?id=199223

        Reviewed by Michael Catanzaro.

        Connect to accept-certificate signal on the WebSocket message connection to decide what to do in case of TLS errors.

        * NetworkProcess/soup/NetworkSessionSoup.cpp:
        (WebKit::webSocketAcceptCertificateCallback):
        (WebKit::webSocketMessageNetworkEventCallback):
        (WebKit::NetworkSessionSoup::createWebSocketTask):

2019-06-27  Carlos Garcia Campos  <cgarcia@igalia.com>

        [SOUP] Use libsoup WebSockets API
        https://bugs.webkit.org/show_bug.cgi?id=199151

        Reviewed by Michael Catanzaro.

        Use the new WebSockets code path that depends on platform specific WebSockets implementation using the libsoup
        API. This is an initial implementation manually tested using the layout tests, which most of them fail due to
        missing console messages, missing features in the new code path or differences in the platform
        implementation. It will be disabled by default until it's feature complete compared to the internal WebKit
        implementation.

        * NetworkProcess/NetworkSocketChannel.cpp:
        (WebKit::NetworkSocketChannel::NetworkSocketChannel): Null check m_socket before using it, because
        createWebSocketTask() can return nullptr;
        (WebKit::NetworkSocketChannel::didConnect): Receive the protocol accepted by the server.
        (WebKit::NetworkSocketChannel::didReceiveMessageError): Something failed in the server side.
        * NetworkProcess/NetworkSocketChannel.h:
        * NetworkProcess/WebSocketTask.h:
        * NetworkProcess/soup/NetworkSessionSoup.cpp:
        (WebKit::NetworkSessionSoup::createWebSocketTask): Create a WebSocketTask.
        * NetworkProcess/soup/NetworkSessionSoup.h:
        * NetworkProcess/soup/WebSocketTaskSoup.cpp: Added.
        (WebKit::WebSocketTask::WebSocketTask):
        (WebKit::WebSocketTask::~WebSocketTask):
        (WebKit::WebSocketTask::didConnect):
        (WebKit::WebSocketTask::didReceiveMessageCallback):
        (WebKit::WebSocketTask::didReceiveErrorCallback):
        (WebKit::WebSocketTask::didFail):
        (WebKit::WebSocketTask::didCloseCallback):
        (WebKit::WebSocketTask::didClose):
        (WebKit::WebSocketTask::sendString):
        (WebKit::WebSocketTask::sendData):
        (WebKit::WebSocketTask::close):
        (WebKit::WebSocketTask::cancel):
        (WebKit::WebSocketTask::resume):
        * NetworkProcess/soup/WebSocketTaskSoup.h: Copied from Source/WebKit/NetworkProcess/WebSocketTask.h.
        * SourcesGTK.txt:
        * WebProcess/Network/WebSocketChannel.cpp:
        (WebKit::WebSocketChannel::subprotocol): Return the protocol accepted by the server.
        (WebKit::WebSocketChannel::didConnect): Set the protocol accepted by the server.
        (WebKit::WebSocketChannel::didReceiveMessageError): It's now an IPC message handler and receives the reason as parameter.
        (WebKit::WebSocketChannel::networkProcessCrashed): Pass empty reason.
        * WebProcess/Network/WebSocketChannel.h:
        * WebProcess/Network/WebSocketChannel.messages.in:

2019-06-21  Konstantin Tokarev  <annulen@yandex.ru>

        [cmake] Switch to built-in handling of C++ standard instead of hardcoding -std=c++17
        https://bugs.webkit.org/show_bug.cgi?id=199108

        Reviewed by Don Olmstead.

        Rationale:

        1. It provides an abstraction over exact flags of particular compilers -
           we just specify required version of C++ standard
        2. External libraries (like Qt used in WPEQt) may require particular C++
           standard or even particular C++ features to be availabe (e.g. Qt
           requires INTERFACE_COMPILE_FEATURES cxx_decltype, which causes cmake
           to add -std=gnu++11 unless proper CXX_STANDARD is defined)

        * PlatformWPE.cmake: Use project-level default for CXX_STANDARD
        property.

2019-06-26  Jiewen Tan  <jiewen_tan@apple.com>

        SubFrameSOAuthorizationSession should preserve the referrer header when fall back to web path
        https://bugs.webkit.org/show_bug.cgi?id=199232
        <rdar://problem/51718328>

        Reviewed by Youenn Fablet.

        The fall back to web path mechanism in SubFrameSOAuthorizationSession doesn't actually resume
        the previous navigation. Instead it starts a new one. The current implementation doesn't carry
        any information from the previous navigation. It is problematic when it comes to http referrer
        as the server might use that to determine what kind of responses to send back. Therefore, we
        add that information now.

        To accomplish the above, the patch teaches WebFrameProxy::loadURL to carry referrer information
        when it is available. Then SubFrameSOAuthorizationSession can reuses the referrer from the
        original request.

        * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm:
        (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal):
        * UIProcess/WebFrameProxy.cpp:
        (WebKit::WebFrameProxy::loadURL):
        * UIProcess/WebFrameProxy.h:
        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::WebPage::loadURLInFrame):
        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/WebPage.messages.in:

2019-06-26  Fujii Hironori  <Hironori.Fujii@sony.com>

        testRunner.setAlwaysAcceptCookies should wait for cookie accept policy to be set
        https://bugs.webkit.org/show_bug.cgi?id=199230
        <rdar://problem/52217933>

        Unreviewed build fix for WinCairo WK2 since r246856.

        * PlatformWin.cmake: Added WKMessageListener.h to WebKit_PUBLIC_FRAMEWORK_HEADERS.

2019-06-26  Dean Jackson  <dino@apple.com>

        Add type to UIImage symbol mapping for _WKElementAction
        https://bugs.webkit.org/show_bug.cgi?id=199255

        Reviewed by Sam Weinig.

        Moving some code in from WebKitAdditions now
        that the API is public.

        * UIProcess/API/Cocoa/_WKElementAction.mm:
        (+[_WKElementAction imageForElementActionType:]):
        (elementActionTypeToUIActionIdentifier):
        (uiActionIdentifierToElementActionType):

2019-06-26  Dean Jackson  <dino@apple.com>

        Expose UIAction identifiers for _WKElementActions
        https://bugs.webkit.org/show_bug.cgi?id=199246
        <rdar://problem/52218950>

        Reviewed by Tim Horton.

        In order for clients to create a contextual menu, they are given
        a set of suggested UIActions, created from _WKElementActions.
        By associating identifiers (strings) with the UIActions, clients
        can inspect the suggestions and make a decision on whether or
        not to include them in the final menu.

        * UIProcess/API/Cocoa/_WKElementAction.h: Typedef UIActionIdentifier,
        add a method to create a UIAction from an _WKElementAction, and a
        helper to map between identifiers and types.

        * UIProcess/API/Cocoa/_WKElementAction.mm:
        (elementActionTypeToUIActionIdentifier): Helper to convert between the two types.
        (uiActionIdentifierToElementActionType): The inverse of above.
        (+[_WKElementAction elementActionTypeForUIActionIdentifier:]): A client given
        a UIAction object can use this helper method to see what _WKElementActionType it
        corresponds to.
        (-[_WKElementAction uiActionForElementInfo:]): Used by WKContentViewInteraction to
        create a UIAction from this _WKElementAction.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (uiActionForLegacyPreviewAction): Renamed to make it clear this is a legacy approach.
        (menuFromLegacyPreviewOrDefaultActions): Split these functions to separate the legacy
        and non-legacy approach.
        (-[WKContentView assignLegacyDataForContextMenuInteraction]):
        (-[WKContentView continueContextMenuInteraction:]):
        (uiActionForPreviewAction): Deleted.
        (menuFromPreviewOrDefaults): Deleted.

2019-06-26  Wenson Hsieh  <wenson_hsieh@apple.com>

        [iPadOS] Fix another crash in -[UIPreviewTarget initWithContainer:center:transform:] when generating a fallback targeted preview
        https://bugs.webkit.org/show_bug.cgi?id=199243
        <rdar://problem/51554509>

        Reviewed by Tim Horton.

        Additionally make createFallbackTargetedPreview robust in the case where the content view is unparented, and
        rename _ensureTargetedPreview to _createTargetedPreviewIfPossible, to reflect the fact that it may now return
        nil.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (createTargetedPreview):
        (createFallbackTargetedPreview):
        (-[WKContentView _createTargetedPreviewIfPossible]):
        (-[WKContentView contextMenuInteraction:previewForHighlightingMenuWithConfiguration:]):
        (-[WKContentView contextMenuInteraction:previewForDismissingMenuWithConfiguration:]):
        (-[WKContentView _ensureTargetedPreview]): Deleted.

2019-06-26  Alex Christensen  <achristensen@webkit.org>

        testRunner.setAlwaysAcceptCookies should wait for cookie accept policy to be set
        https://bugs.webkit.org/show_bug.cgi?id=199230
        <rdar://51757107>

        Reviewed by Andy Estes.

        This patch adds an optional callback to WKCookieManagerSetHTTPCookieAcceptPolicy which is luckily only used for testing.
        It also adds listener-based asynchronous versions of didReceiveSynchronousMessageFromInjectedBundle.
        WebKitTestRunner uses these new abilities to wait for the cookie accept policy to be set in the network process while the web process is hung.
        This removes the race condition that was causing some flakiness in tests that use testRunner.setAlwaysAcceptCookies

        * Shared/API/APIObject.h:
        * Shared/API/c/WKBase.h:
        * Sources.txt:
        * UIProcess/API/APIInjectedBundleClient.h:
        (API::InjectedBundleClient::didReceiveSynchronousMessageFromInjectedBundle):
        * UIProcess/API/APIMessageListener.h: Copied from Source/WebKit/UIProcess/API/APIInjectedBundleClient.h.
        (API::MessageListener::create):
        (API::MessageListener::sendReply):
        (API::MessageListener::MessageListener):
        * UIProcess/API/C/WKAPICast.h:
        * UIProcess/API/C/WKContextInjectedBundleClient.h:
        * UIProcess/API/C/WKCookieManager.cpp:
        (WKCookieManagerSetHTTPCookieAcceptPolicy):
        * UIProcess/API/C/WKCookieManager.h:
        * UIProcess/API/C/WKMessageListener.cpp: Copied from Source/WebKit/UIProcess/API/APIInjectedBundleClient.h.
        (WKMessageListenerGetTypeID):
        (WKMessageListenerSendReply):
        * UIProcess/API/C/WKMessageListener.h: Copied from Source/WebKit/UIProcess/API/APIInjectedBundleClient.h.
        * UIProcess/API/C/WKPageInjectedBundleClient.h:
        * UIProcess/WebContextInjectedBundleClient.cpp:
        (WebKit::WebContextInjectedBundleClient::didReceiveSynchronousMessageFromInjectedBundle):
        * UIProcess/WebContextInjectedBundleClient.h:
        * UIProcess/WebPageInjectedBundleClient.cpp:
        (WebKit::WebPageInjectedBundleClient::didReceiveSynchronousMessageFromInjectedBundle):
        * UIProcess/WebPageInjectedBundleClient.h:
        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::handleSynchronousMessage):
        * UIProcess/WebPageProxy.h:
        (WebKit::WebPageProxy::injectedBundleClient): Deleted.
        * UIProcess/WebProcessPool.cpp:
        (WebKit::WebProcessPool::handleSynchronousMessage):
        * WebKit.xcodeproj/project.pbxproj:

2019-06-26  Wenson Hsieh  <wenson_hsieh@apple.com>

        [iPadOS] eddm.usps.com scrolls horizontally due to explicit width set in viewport meta tag
        https://bugs.webkit.org/show_bug.cgi?id=199219
        <rdar://problem/50425765>

        Reviewed by Tim Horton.

        Currently, the heuristic to determine whether the page should be shrunk to fit the content width after loading
        works by checking whether the page's content is wider than the layout width we've provided for the page.
        However, in the case where an explicit width larger than the true view width is specified by the page's meta
        viewport, we'll end up believing that the page's content is not wider than the layout width, which is dictated
        by the fixed meta viewport width. Instead, we can shrink the page down in this scenario by comparing the content
        width against the scaled size of the view when computing the amount of horizontal overflow.

        Test: fast/viewport/ios/shrink-to-fit-content-large-constant-width.html

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::immediatelyShrinkToFitContent):

2019-06-26  Zalan Bujtas  <zalan@apple.com>

        [ContentChangeObserver] Dispatch synthetic mouse event asynchronously in completePendingSyntheticClickForContentChangeObserver
        https://bugs.webkit.org/show_bug.cgi?id=199220
        <rdar://problem/51787961>

        Reviewed by Simon Fraser.

        WebPage::completePendingSyntheticClickForContentChangeObserver should not dispatch mouse events synchronously.
        Mouse events, through style updates could destroy the element that initiated this change.
        WebPage::handleSyntheticClick() already implements this pattern.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::WebPage::completePendingSyntheticClickForContentChangeObserver):

2019-06-25  Jiewen Tan  <jiewen_tan@apple.com>

        Implement a new SPI to inform clients about AppSSO
        https://bugs.webkit.org/show_bug.cgi?id=199085
        <rdar://problem/50028246>

        Reviewed by Geoffrey Garen.

        This patch implements a new SPI to inform clients about incoming AppSSO interceptions during
        navigations. Therefore, clients can make an informed decision about whether this is the right
        moment to do the interception as interceptions often show native UI. Also, the SPI is designed
        to pass along a human readable name for the extension such that clients can do whatever they
        want to inform users about what's going on.

        Here is the new SPI:
        - (void)_webView:(WKWebView *)webView decidePolicyForSOAuthorizationLoadWithCurrentPolicy:(_WKSOAuthorizationLoadPolicy)policy forExtension:(NSString *)extension completionHandler:(void (^)(_WKSOAuthorizationLoadPolicy policy))completionHandler;

        * UIProcess/API/APINavigationClient.h:
        (API::NavigationClient::decidePolicyForSOAuthorizationLoad):
        * UIProcess/API/Cocoa/WKNavigationDelegatePrivate.h:
        * UIProcess/Cocoa/NavigationState.h:
        * UIProcess/Cocoa/NavigationState.mm:
        (WebKit::NavigationState::setNavigationDelegate):
        (WebKit::soAuthorizationLoadPolicy):
        (WebKit::wkSOAuthorizationLoadPolicy):
        (WebKit::NavigationState::NavigationClient::decidePolicyForSOAuthorizationLoad):
        * UIProcess/Cocoa/SOAuthorization/SOAuthorizationLoadPolicy.h: Added.
        * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
        (WebKit::SOAuthorizationSession::start):
        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::decidePolicyForSOAuthorizationLoad):
        * UIProcess/WebPageProxy.h:
        * WebKit.xcodeproj/project.pbxproj:

2019-06-25  Simon Fraser  <simon.fraser@apple.com>

        [iOS WK2 Debug] scrollingcoordinator/scrolling-tree/scroller-with-negative-z-child.html asserts
        https://bugs.webkit.org/show_bug.cgi?id=199218

        Reviewed by Zalan Bujtas.

        Followup to r246766; don't assert in the UI process if a ScrollingTreeOverflowScrollProxyNode
        doesn't have a related overflow node; this is currently expected behavior with negative z-order
        children of a scroller.

        * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
        (WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations):

2019-06-25  Daniel Bates  <dabates@apple.com>

        Non-editable text selections should be modifiable with hardware keyboard
        https://bugs.webkit.org/show_bug.cgi?id=199204
        <rdar://problem/51651496>

        Reviewed by Wenson Hsieh.

        UIKit changes are need for this to work, including <rdar://problem/48322899>.
        Note that without these changes, -canPerformAction is never called for _move*
        selectors.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView canPerformAction:withSender:]):

2019-06-25  Daniel Bates  <dabates@apple.com>

        [iOS] Should not process key events in non-editable elements using IME
        https://bugs.webkit.org/show_bug.cgi?id=199122
        <rdar://problem/52006654>

        Reviewed by Brent Fulgham.

        Use the non-Input Method code path (the one we use for US keyboard input) for all key events
        targeting a non-editable element. Such key events will never require Input Method support
        (i.e. show candidate suggestions). Moreover, this behavior matches the behavior on Mac.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView handleKeyWebEvent:withCompletionHandler:]):

2019-06-25  Alex Christensen  <achristensen@webkit.org>

        Make HTTPCookieAcceptPolicy an enum class
        https://bugs.webkit.org/show_bug.cgi?id=199081

        Reviewed by Michael Catanzaro.

        Doing so reveals some interesting bugs in the C API that are also fixed:
        WKPreferencesGetIncrementalRenderingSuppressionTimeout was using its toAPI function to convert a double to a double because HTTPCookieAcceptPolicy used to be an unsigned integer.
        toAPI(WebCore::MouseButton) was also using the toAPI(HTTPCookieAcceptPolicy) because HTTPCookieAcceptPolicy used to be an unsigned integer.
        Yikes!  Type safety is our friend.

        * NetworkProcess/Cookies/WebCookieManager.messages.in:
        * NetworkProcess/Cookies/mac/WebCookieManagerMac.mm:
        (WebKit::toCFHTTPCookieStorageAcceptPolicy):
        (WebKit::WebCookieManager::platformSetHTTPCookieAcceptPolicy):
        (WebKit::WebCookieManager::platformGetHTTPCookieAcceptPolicy):
        * Shared/API/c/WKSharedAPICast.h:
        (WebKit::toAPI):
        * Shared/HTTPCookieAcceptPolicy.h:
        (): Deleted.
        * UIProcess/API/C/WKAPICast.h:
        (WebKit::toHTTPCookieAcceptPolicy):
        (WebKit::toAPI):
        * UIProcess/API/C/WKPreferences.cpp:
        (WKPreferencesGetIncrementalRenderingSuppressionTimeout):
        * UIProcess/API/Cocoa/WKProcessPool.mm:
        (toHTTPCookieAcceptPolicy):
        * UIProcess/WebCookieManagerProxy.cpp:
        (WebKit::WebCookieManagerProxy::didGetHTTPCookieAcceptPolicy):
        * UIProcess/WebCookieManagerProxy.h:
        * UIProcess/WebCookieManagerProxy.messages.in:

2019-06-25  Tim Horton  <timothy_horton@apple.com>

        Wrong title for Data Detectors tap action menu
        https://bugs.webkit.org/show_bug.cgi?id=199198
        <rdar://problem/51957842>

        Reviewed by Wenson Hsieh.

        * UIProcess/ios/WKActionSheetAssistant.mm:
        (-[WKActionSheetAssistant showDataDetectorsSheet]):
        Always pass the results array through to DataDetectors; they need it
        to figure out the title too!

2019-06-25  Wenson Hsieh  <wenson_hsieh@apple.com>

        [iOS] Occasional crash under -[UIPreviewTarget initWithContainer:center:transform:] when generating a drag preview
        https://bugs.webkit.org/show_bug.cgi?id=199192
        <rdar://problem/51554509>

        Reviewed by Tim Horton.

        Tweak our preview generation code (for both the context menu and dragging) to be robust in the case where the
        content view's unscaled view is nil; this may happen in the case after the web content process is terminated
        and -cleanupInteraction is called, but before -setupInteraction is subsequently called.

        Additionally, make our logic for creating targeted previews robust in the case where the view is removed from
        the view hierarchy right before the platform asks for a targeted preview.

        Test:   DragAndDropTests.WebProcessTerminationDuringDrag
                DragAndDropTests.WebViewRemovedFromViewHierarchyDuringDrag

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView containerViewForTargetedPreviews]):
        (-[WKContentView _deliverDelayedDropPreviewIfPossible:]):
        (-[WKContentView dragInteraction:previewForLiftingItem:session:]):
        (-[WKContentView _ensureTargetedPreview]):

2019-06-25  Youenn Fablet  <youenn@apple.com>

        Close sockets with too high file descriptor
        https://bugs.webkit.org/show_bug.cgi?id=199116

        Reviewed by Eric Carlson.

        Log the case of failing to open a socket.

        * NetworkProcess/webrtc/NetworkRTCProvider.cpp:
        (WebKit::NetworkRTCProvider::createSocket):

2019-06-25  Tim Horton  <timothy_horton@apple.com>

        When Caps Lock is enabled on the Smart Keyboard, can't scroll with space or arrow keys
        https://bugs.webkit.org/show_bug.cgi?id=199187
        <rdar://problem/51521709>

        Reviewed by Anders Carlsson.

        * UIProcess/ios/WKKeyboardScrollingAnimator.mm:
        (-[WKKeyboardScrollingAnimator keyboardScrollForEvent:]):
        When deciding whether a key event should start a scroll, ignore all
        modifiers other than the ones we actually care about (including Caps Lock).

2019-06-25  Michael Catanzaro  <mcatanzaro@igalia.com>

        Fully rename WebKitGTK+ -> WebKitGTK everywhere
        https://bugs.webkit.org/show_bug.cgi?id=199159

        Reviewed by Carlos Garcia Campos.

        * UIProcess/API/glib/APIWebsiteDataStoreGLib.cpp:

2019-06-24  Brady Eidson  <beidson@apple.com>

        Null deref in WebFrameLoaderClient::dispatchDidReceiveServerRedirectForProvisionalLoad.
        <rdar://problem/51535942> and https://bugs.webkit.org/show_bug.cgi?id=199123

        Reviewed by Andy Estes.

        * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
        (WebKit::WebFrameLoaderClient::dispatchDidReceiveServerRedirectForProvisionalLoad): Properly detect this null DocumentLoader
          and try to learn more about the state of things.

2019-06-24  Chris Dumez  <cdumez@apple.com>

        Pages using Google's anti-flicker optimization may take ~5 seconds to do initial paint
        https://bugs.webkit.org/show_bug.cgi?id=199173
        <rdar://problem/45968770>

        Reviewed by Geoffrey Garen.

        Add experimental feature for the quirk.

        * Shared/WebPreferences.yaml:

2019-06-24  John Wilander  <wilander@apple.com>

        Remove IsITPFirstPartyWebsiteDataRemovalEnabled as runtime check
        https://bugs.webkit.org/show_bug.cgi?id=199164
        <rdar://problem/52061147>

        Reviewed by Brent Fulgham.

        We've had this toggle as a safety thing since mid-March. No need for it any longer.

        * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp:
        (WebKit::ResourceLoadStatisticsMemoryStore::shouldRemoveAllButCookiesFor const):
        * NetworkProcess/NetworkProcess.cpp:
        (WebKit::NetworkProcess::initializeNetworkProcess):
        * NetworkProcess/NetworkProcessCreationParameters.cpp:
        (WebKit::NetworkProcessCreationParameters::encode const):
        (WebKit::NetworkProcessCreationParameters::decode):
        * NetworkProcess/NetworkProcessCreationParameters.h:
        * Shared/WebPreferences.yaml:
        * UIProcess/Cocoa/WebProcessPoolCocoa.mm:
        (WebKit::WebProcessPool::platformInitializeNetworkProcess):

2019-06-24  Daniel Bates  <dabates@apple.com>

        m_focusedElement != &element in WebPage::elementDidBlur() sometimes
        https://bugs.webkit.org/show_bug.cgi?id=198928
        <rdar://problem/51814327>

        Reviewed by Brent Fulgham.

        This can happen when the focused editable element is inside a nested frame and a person
        taps outside that frame. For reasons that seem lost to time, WebKit2 on iOS would mutate
        the focused frame whenever computing selection positioning information (say, for a tap).
        This "quirk" was added in r163476, but that code has go through multiple iterations and
        is no longer comparable to the current code. Yet, the original mutation of the focused
        frame remained. As a result the UI process and Web process go out of sync with respect
        to what each thinks is the focused element and this visually manifest itself in at least
        two ways:

            1. A non-sensical DOM focus event would be dispatched at the frame tapped, but
            we would keep the focused element focused.

            2. Because we would keep the focused element focused in (1), even though its frame
            is not focused, the keyboard would be active (software keyboard on screen or candidate bar
            on screen if a hardware keyboard is attached), but appear unresponsive: any keys pressed
            would not cause text to be typed into the editable field.

        Because of (1) it was possible for m_focusedElement != &element in WebPage::elementDidBlur().
        When this happens the UI process would never receive an ElementDidBlur message and hence would
        not clear out the focused element state and hide the keyboard.

        We neither do this frame focus mutation in Legacy WebKit on iOS nor Mac. Let's remove this quirk.
        If it turns out that it causes a compatibility issue then we will be in a better position to
        understand its purpose and consider bringing this quirk back, if needed.

        * Shared/ios/InteractionInformationRequest.cpp:
        (WebKit::InteractionInformationRequest::encode const):
        (WebKit::InteractionInformationRequest::decode):
        (WebKit::InteractionInformationRequest::isValidForRequest):
        (WebKit::InteractionInformationRequest::isApproximatelyValidForRequest):
        * Shared/ios/InteractionInformationRequest.h:
        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _requestActivatedElementAtPosition:completionBlock:]):
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _webTouchEventsRecognized:]):
        Remove the readOnly field.

        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::selectionPositionInformation): Remove code to mutate the focused frame.

2019-06-24  Per Arne Vollan  <pvollan@apple.com>

        [Cocoa] Avoid creating a PlatformMediaSessionManager when the WebProcess is suspended or resumed
        https://bugs.webkit.org/show_bug.cgi?id=199160

        Reviewed by Brent Fulgham.

        When the WebProcess suspends or resumes, the PlatformMediaSessionManager is notified about this.
        Avoid creating a new PlatformMediaSessionManager if it does not already exist.

        * WebProcess/WebProcess.cpp:
        (WebKit::WebProcess::actualPrepareToSuspend):
        (WebKit::WebProcess::cancelPrepareToSuspend):
        (WebKit::WebProcess::processDidResume):

2019-06-24  Adrian Perez de Castro  <aperez@igalia.com>

        [WPE][GTK] Fixes for compilation with unified builds disabled
        https://bugs.webkit.org/show_bug.cgi?id=199155

        Reviewed by Michael Catanzaro.

        * NetworkProcess/glib/DNSCache.cpp: Add missing inclusion of wtf/glib/RunLoopSourcePriority.h
        * NetworkProcess/glib/DNSCache.h: Add missing forward declaration for GInetAddress

2019-06-24  Alexander Mikhaylenko  <exalm7659@gmail.com>

        [GTK] Navigation gesture should use dark fallback bg color on dark themes
        https://bugs.webkit.org/show_bug.cgi?id=199104

        Reviewed by Michael Catanzaro.

        Use theme_base_color instead of white background for swipe gesture fallback if no snapshot is found and
        the page did not specify a color. This allows it to use dark colors for dark themes. If the color was
        not found, still fall back to white.

        * UIProcess/gtk/ViewGestureControllerGtk.cpp:
        (WebKit::ViewGestureController::beginSwipeGesture):

2019-06-23  Dan Bernstein  <mitz@apple.com>

        Platform font class gets needlessly initialized in the Networking process
        https://bugs.webkit.org/show_bug.cgi?id=199140

        Reviewed by Tim Horton.

        * NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in: Revert a change that was made in
          r246702, which is not needed anymore.
        * Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb: Ditto.

        * Shared/Cocoa/ArgumentCodersCocoa.mm:
        (IPC::platformColorClass): Added getter that uses NSClassFromString, thereby avoiding
          initializing the class.
        (IPC::platformFontClass): Ditto.
        (IPC::typeFromObject): Changed to use the above getters instead of +class.

2019-06-23  Simon Fraser  <simon.fraser@apple.com>

        [Async overflow scroll] Clipped composited layers inside overflow scroll jitter and get incorrectly clipped
        https://bugs.webkit.org/show_bug.cgi?id=199133
        rdar://problem/43614439

        Reviewed by Antti Koivisto.
        
        LayoutConstraints -> AbsolutePositionConstraints rename.

        * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
        (ArgumentCoder<ScrollingStatePositionedNode>::decode):
        * Shared/WebCoreArgumentCoders.cpp:
        (IPC::ArgumentCoder<AbsolutePositionConstraints>::encode):
        (IPC::ArgumentCoder<AbsolutePositionConstraints>::decode):
        (IPC::ArgumentCoder<LayoutConstraints>::encode): Deleted.
        (IPC::ArgumentCoder<LayoutConstraints>::decode): Deleted.
        * Shared/WebCoreArgumentCoders.h:
        * Shared/WebRenderLayer.cpp:
        (WebKit::WebRenderLayer::WebRenderLayer):
        * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
        (WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations): ScrollingTreeOverflowScrollProxyNode
        have overflow scroll relations now too.

2019-06-23  Simon Fraser  <simon.fraser@apple.com>

        Add OverflowScrollProxyNodes to the scrolling tree
        https://bugs.webkit.org/show_bug.cgi?id=199132

        Reviewed by Antti Koivisto.

        Add ScrollingStateOverflowScrollProxyNode and ScrollingTreeOverflowScrollProxyNode. These
        nodes represent clip and scroll position for an overflow:scroll in the containing block chain,
        but not the paint ancestor chain of a layer. They will be used to correctly manipulate clip
        rects for composited layers in non-stacking-context scrollers, and in a future patch will
        replace the functionality of "Moves" positioned nodes.

        An OverflowScrollProxyNode has the ScrollingNodeID of the scrolling node that it relates to,
        and we use the existing "related overflow nodes" to create the back references in the scrolling tree.

        These nodes are not instantiated yet; a future patch will hook them up.

        * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
        (ArgumentCoder<ScrollingStateOverflowScrollProxyNode>::encode):
        (ArgumentCoder<ScrollingStateOverflowScrollProxyNode>::decode):
        (WebKit::encodeNodeAndDescendants):
        (WebKit::RemoteScrollingCoordinatorTransaction::decode):
        (WebKit::dump):
        * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
        (WebKit::RemoteScrollingCoordinatorProxy::connectStateNodeLayers):
        * UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp:
        (WebKit::RemoteScrollingTree::createScrollingTreeNode):
        * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
        (WebKit::RemoteScrollingCoordinatorProxy::connectStateNodeLayers):
        * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm:
        (WebKit::ScrollingTreeScrollingNodeDelegateIOS::repositionScrollingLayers):

2019-06-21  Jiewen Tan  <jiewen_tan@apple.com>

        Unreviewed, a build fix after r246701

        * Shared/LoadParameters.h:
        Add a default value for shouldOpenExternalURLsPolicy.

2019-06-21  Brent Fulgham  <bfulgham@apple.com>

        Adjust sandboxes based on seed feedback
        https://bugs.webkit.org/show_bug.cgi?id=199119
        <rdar://problem/50164879>

        Reviewed by Geoffrey Garen.

        Update our sandboxes to address test failures and bugs encountered during initial iOS 13 and
        macOS Catalina testing.

        * NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in:
        * Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb:
        * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:
        * WebProcess/com.apple.WebProcess.sb.in:

2019-06-21  Jiewen Tan  <jiewen_tan@apple.com>

        WebPageProxy::loadData should accept ShouldOpenExternalURLsPolicy
        https://bugs.webkit.org/show_bug.cgi?id=199114
        <rdar://problem/51671674>

        Reviewed by Youenn Fablet.

        This patch teaches WebPageProxy::loadData to accept ShouldOpenExternalURLsPolicy policy,
        and then utilize it in RedirectSOAuthorizationSession. Therefore, the response loaded after
        successful interceptions will be able to propagate the same policy from the last navigation
        as it were continuous loading.

        Besides the above, this patch also fixes some minor issues.

        * Shared/LoadParameters.h:
        * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm:
        (WebKit::NavigationSOAuthorizationSession::shouldStartInternal):
        (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow):
        * UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.h:
        * UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.mm:
        (WebKit::PopUpSOAuthorizationSession::completeInternal):
        * UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.h:
        * UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.mm:
        (WebKit::shouldOpenExternalURLsPolicy):
        (WebKit::RedirectSOAuthorizationSession::completeInternal):
        * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h:
        * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
        (WebKit::SOAuthorizationSession::complete):
        * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h:
        * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm:
        (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal):
        (WebKit::SubFrameSOAuthorizationSession::completeInternal):
        (WebKit::SubFrameSOAuthorizationSession::loadDataToFrame):
        (WebKit::SubFrameSOAuthorizationSession::postDidCancelMessageToParent):
        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::loadRequestWithNavigationShared):
        (WebKit::WebPageProxy::loadFile):
        (WebKit::WebPageProxy::loadData):
        (WebKit::WebPageProxy::loadDataWithNavigationShared):
        * UIProcess/WebPageProxy.h:
        * WebProcess/WebPage/WebPage.cpp:
        (WebKit::WebPage::loadDataImpl):
        (WebKit::WebPage::loadData):
        * WebProcess/WebPage/WebPage.h:

2019-06-21  Tim Horton  <timothy_horton@apple.com>

        WebKit context menu highlights include extra padding
        https://bugs.webkit.org/show_bug.cgi?id=199080
        <rdar://problem/51140126>

        Reviewed by Dean Jackson.

        * Shared/ios/InteractionInformationRequest.cpp:
        (WebKit::InteractionInformationRequest::encode const):
        (WebKit::InteractionInformationRequest::decode):
        (WebKit::InteractionInformationRequest::isValidForRequest):
        (WebKit::InteractionInformationRequest::isApproximatelyValidForRequest):
        * Shared/ios/InteractionInformationRequest.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView gestureRecognizerShouldBegin:]):
        (-[WKContentView positionInformationForActionSheetAssistant:]):
        (-[WKContentView updatePositionInformationForActionSheetAssistant:]):
        (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]):
        (-[WKContentView _interactionShouldBeginFromPreviewItemController:forPosition:]):
        * WebProcess/WebPage/ios/WebPageIOS.mm:
        (WebKit::linkIndicatorPositionInformation):
        Disable the margin going forward, but leave it if we're using the legacy
        API, because there is no way to add margin at the platform level with
        the legacy API.

        In the future we should always have no margin in our indicator, and just
        apply it in whatever consumes the indicator, so that there is no
        disagreement between clients about the size of the margin.

2019-06-21  Youenn Fablet  <youenn@apple.com>

        WebPageProxy should use the right path for sandbox extension
        https://bugs.webkit.org/show_bug.cgi?id=198902
        <rdar://problem/50772810>

        Reviewed by Geoffrey Garen.

        Store the sandbox path, if any, in UIProcess for each page in its PageLoadState.
        This allows proper sandbox handling for reload after crash and process swap cases.
        Store the sandbox path, if any, in the b/w list so that the sandbox path can be properly computed
        during b/f navigation works.

        Add SPI for test purposes to check what is the current sandbox path.

        * Shared/WebBackForwardListItem.h:
        (WebKit::WebBackForwardListItem::resourceDirectoryURL const):
        (WebKit::WebBackForwardListItem::setResourceDirectoryURL):
        * UIProcess/API/Cocoa/WKWebView.mm:
        (-[WKWebView _resourceDirectoryURL]):
        * UIProcess/API/Cocoa/WKWebViewPrivate.h:
        * UIProcess/PageLoadState.cpp:
        (WebKit::PageLoadState::resourceDirectoryURL const):
        (WebKit::PageLoadState::setPendingAPIRequestURL):
        * UIProcess/PageLoadState.h:
        (WebKit::PageLoadState::setPendingAPIRequestURL):
        * UIProcess/WebPageProxy.cpp:
        (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):
        (WebKit::WebPageProxy::loadRequestWithNavigationShared):
        (WebKit::WebPageProxy::loadFile):
        (WebKit::WebPageProxy::reload):
        (WebKit::WebPageProxy::backForwardAddItem):
        (WebKit::WebPageProxy::backForwardGoToItemShared):
        (WebKit::WebPageProxy::currentResourceDirectoryURL const):
        * UIProcess/WebPageProxy.h:

2019-06-21  Antoine Quint  <graouts@apple.com>

        [iOS] Compatibility mouse events aren't prevented by calling preventDefault() on pointerdown
        https://bugs.webkit.org/show_bug.cgi?id=198124
        <rdar://problem/50410863>

        Reviewed by Dean Jackson.

        Ensure we wait until completion of a tap before removing the pointer ID and the preventDefault() state along with it.

        * UIProcess/ios/WKContentViewInteraction.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _singleTapDidReset:]):
        (-[WKContentView _commitPotentialTapFailed]):
        (-[WKContentView _didCompleteSyntheticClick]):
        (-[WKContentView _singleTapRecognized:]):

2019-06-21  Keith Rollin  <krollin@apple.com>

        Address reference to UIColor.groupTableViewBackgroundColor in WKPasswordView.mm
        https://bugs.webkit.org/show_bug.cgi?id=199111
        <rdar://problem/51992107>

        Reviewed by Timothy Hatcher.

        WKPasswordView.mm is used on iOS-family devices. However, it doesn't
        build on tvOS or watchOS when "treat deprecation warnings as errors"
        is enabled. This build failure is due to a reference to
        UIColor.groupTableViewBackgroundColor in a branch of non-dark-mode
        code. Address this by surrounding the reference with
        ALLOW_DEPRECATED_DECLARATIONS_* macros.

        Attempting to address the build failure by unconditionally enabling
        the dark-mode code works for tvOS, but fails for watchOS due to lack
        of dark-mode support on that platform.

        * UIProcess/ios/WKPasswordView.mm:
        (-[WKPasswordView showInScrollView:]):

2019-06-21  Michael Catanzaro  <mcatanzaro@igalia.com>

        [WPE][GTK] Bump minimum versions of GLib, GTK, libsoup, ATK, GStreamer, and Cairo
        https://bugs.webkit.org/show_bug.cgi?id=199094

        Reviewed by Carlos Garcia Campos.

        * NetworkProcess/soup/NetworkDataTaskSoup.cpp:
        (WebKit::NetworkDataTaskSoup::createRequest):
        (WebKit::NetworkDataTaskSoup::writeDownloadCallback):
        (WebKit::NetworkDataTaskSoup::writeDownload):
        (WebKit::NetworkDataTaskSoup::startingCallback):
        (WebKit::NetworkDataTaskSoup::requestStartedCallback): Deleted.
        * Shared/gtk/WebEventFactory.cpp:
        (WebKit::buttonForEvent):
        (WebKit::WebEventFactory::createWebMouseEvent):
        (WebKit::WebEventFactory::createWebWheelEvent):
        (WebKit::WebEventFactory::createWebKeyboardEvent):
        (WebKit::WebEventFactory::createWebTouchEvent):
        * UIProcess/API/gtk/PageClientImpl.cpp:
        (WebKit::PageClientImpl::doneWithTouchEvent):
        * UIProcess/API/gtk/WebKitWebViewBase.cpp:
        (ClickCounter::currentClickCountForGdkButtonEvent):
        (webkitWebViewBaseRealize):
        (webkitWebViewBaseHandleMouseEvent):
        (webkitWebViewBaseGetTouchPointsForEvent):
        (webkitWebViewBaseTouchEvent):
        (webkitWebViewBaseGestureController):
        (webkitWebViewBaseEvent):
        (deviceScaleFactorChanged):
        (webkitWebViewBaseCreateWebPage):
        (webkitWebViewBaseTakeViewSnapshot):
        * UIProcess/API/gtk/WebKitWebViewBasePrivate.h:
        * UIProcess/API/gtk/WebKitWebViewDialog.cpp:
        (webkitWebViewDialogDraw):
        (webkitWebViewDialogConstructed):
        (webkit_web_view_dialog_class_init):
        * UIProcess/API/gtk/WebKitWebViewGtk.cpp:
        (fileChooserDialogResponseCallback):
        (webkitWebViewRunFileChooser):
        * UIProcess/Automation/gtk/WebAutomationSessionGtk.cpp:
        (WebKit::doMouseEvent):
        (WebKit::doMotionEvent):
        (WebKit::doKeyStrokeEvent):
        * UIProcess/WebPageProxy.h:
        * UIProcess/gtk/AcceleratedBackingStoreWayland.cpp:
        (WebKit::AcceleratedBackingStoreWayland::~AcceleratedBackingStoreWayland):
        (WebKit::AcceleratedBackingStoreWayland::tryEnsureGLContext):
        (WebKit::AcceleratedBackingStoreWayland::makeContextCurrent):
        (WebKit::AcceleratedBackingStoreWayland::paint):
        * UIProcess/gtk/AcceleratedBackingStoreWayland.h:
        * UIProcess/gtk/DragAndDropHandler.cpp:
        (WebKit::DragAndDropHandler::startDrag):
        (WebKit::DragAndDropHandler::fillDragData):
        (WebKit::DragAndDropHandler::finishDrag):
        * UIProcess/gtk/DragAndDropHandler.h:
        * UIProcess/gtk/GestureController.cpp:
        (WebKit::GestureController::handleEvent):
        * UIProcess/gtk/GestureController.h:
        * UIProcess/gtk/InputMethodFilter.cpp:
        (WebKit::InputMethodFilter::filterKeyEvent):
        (WebKit::InputMethodFilter::logHandleKeyboardEventForTesting):
        (WebKit::InputMethodFilter::logHandleKeyboardEventWithCompositionResultsForTesting):
        * UIProcess/gtk/ViewGestureControllerGtk.cpp:
        (WebKit::isEventStop):
        (WebKit::createScrollEvent):
        * UIProcess/gtk/WebContextMenuProxyGtk.cpp:
        (WebKit::WebContextMenuProxyGtk::append):
        (WebKit::WebContextMenuProxyGtk::WebContextMenuProxyGtk):
        (WebKit::WebContextMenuProxyGtk::~WebContextMenuProxyGtk):
        * UIProcess/gtk/WebKitInspectorWindow.cpp:
        (webkit_inspector_window_init):
        (webkitInspectorWindowSetSubtitle):
        * UIProcess/gtk/WebPageProxyGtk.cpp:
        (WebKit::WebPageProxy::getCenterForZoomGesture):
        * UIProcess/gtk/WebPopupMenuProxyGtk.cpp:
        (WebKit::WebPopupMenuProxyGtk::showPopupMenu):
        (WebKit::WebPopupMenuProxyGtk::hidePopupMenu):
        * WebProcess/WebPage/WebPage.h:
        * WebProcess/WebPage/WebPage.messages.in:
        * WebProcess/WebPage/gtk/WebPageGtk.cpp:
        (WebKit::WebPage::getCenterForZoomGesture):

2019-06-20  Patrick Griffis  <pgriffis@igalia.com> and Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK][WPE] Implement a basic DNS cache
        https://bugs.webkit.org/show_bug.cgi?id=196094

        Reviewed by Michael Catanzaro.

        This adds a simple cache to all DNS operations in the network process.

        * NetworkProcess/glib/DNSCache.cpp: Added.
        (WebKit::DNSCache::DNSCache):
        (WebKit::DNSCache::mapForType):
        (WebKit::DNSCache::lookup):
        (WebKit::DNSCache::update):
        (WebKit::DNSCache::removeExpiredResponsesInMap):
        (WebKit::DNSCache::pruneResponsesInMap):
        (WebKit::DNSCache::removeExpiredResponsesFired):
        (WebKit::DNSCache::clear):
        * NetworkProcess/glib/DNSCache.h: Added.
        * NetworkProcess/glib/WebKitCachedResolver.cpp: Added.
        (addressListVectorToGList):
        (addressListGListToVector):
        (webkitCachedResolverLookupByName):
        (webkitCachedResolverLookupByNameAsync):
        (webkitCachedResolverLookupByNameFinish):
        (dnsCacheType):
        (webkitCachedResolverLookupByNameWithFlags):
        (webkitCachedResolverLookupByNameWithFlagsAsync):
        (webkitCachedResolverLookupByNameWithFlagsFinish):
        (webkitCachedResolverLookupByAddress):
        (webkitCachedResolverLookupByAddressAsync):
        (webkitCachedResolverLookupByAddressFinish):
        (webkitCachedResolverLookupRecords):
        (webkitCachedResolverLookupRecordsAsync):
        (webkitCachedResolverLookupRecordsFinish):
        (webkitCachedResolverReload):
        (webkit_cached_resolver_class_init):
        (webkitCachedResolverNew):
        * NetworkProcess/glib/WebKitCachedResolver.h: Added.
        * NetworkProcess/soup/NetworkProcessSoup.cpp:
        (WebKit::NetworkProcess::platformInitializeNetworkProcess):
        * PlatformGTK.cmake:
        * PlatformWPE.cmake:
        * SourcesGTK.txt:
        * SourcesWPE.txt:

2019-06-20  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK] Stop pretending WebCore::Widget can have a platform widget
        https://bugs.webkit.org/show_bug.cgi?id=199066

        Reviewed by Michael Catanzaro.

        Rename PlatformWidget as PlatformViewWidget to avoid conflict with PlatformWidget defined in WebCore.

        * UIProcess/WebPageProxy.h:
        * UIProcess/win/WebPageProxyWin.cpp:
        (WebKit::WebPageProxy::viewWidget):

2019-06-20  Megan Gardner  <megan_gardner@apple.com>

        Remove change that was causing hangs
        https://bugs.webkit.org/show_bug.cgi?id=199055
        <rdar://problem/51820516>

        Reviewed by Darin Adler.

        This fix can sometimes cause deadlocks in the UIProcess.
        We have a different fix that will go into UIKit <rdar://problem/51927701>.

        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _selectionChanged]):

2019-06-20  Daniel Bates  <dabates@apple.com>

        [iOS] Evernote crashes when creating a note
        https://bugs.webkit.org/show_bug.cgi?id=199083
        <rdar://problem/51759247>

        Reviewed by Brent Fulgham.

        Add a hack just for Evernote linked before iOS 13 that dynamically adds a placeholder -[WKContentView keyCommands]
        method (it just calls super). Evernote swizzles the IPI -[WKContentView keyCommands], but this
        method may not always be present in the WebKit binary following r240514. So, Evernote may end
        up swizzling -[UIResponder keyCommands], but their implementation doesn't account for this
        scenario and they end up crashing because they call an unrecognized selector.

        * UIProcess/Cocoa/VersionChecks.h: Add version check.
        * UIProcess/ios/WKContentView.mm:
        (keyCommandsPlaceholderHackForEvernote): Added.
        (-[WKContentView _commonInitializationWithProcessPool:configuration:]): Install the hack.

2019-06-20  Brady Eidson  <beidson@apple.com>

        WebURLSchemeHandlerProxy::loadSynchronously crash with sync request.
        <rdar://problem/51862206> and https://bugs.webkit.org/show_bug.cgi?id=199063

        Reviewed by Geoffrey Garen.

        Don't use a DataReference for the sync reply type.

        * UIProcess/WebPageProxy.messages.in:
        * UIProcess/WebURLSchemeHandler.h:

        * UIProcess/WebURLSchemeTask.cpp:
        (WebKit::WebURLSchemeTask::didComplete):
        * UIProcess/WebURLSchemeTask.h:

        * WebProcess/WebPage/WebURLSchemeHandlerProxy.cpp:
        (WebKit::WebURLSchemeHandlerProxy::loadSynchronously):

2019-06-20  Alex Christensen  <achristensen@webkit.org>

        Add unit test for UIContextMenuConfiguration API
        https://bugs.webkit.org/show_bug.cgi?id=199043

        Reviewed by Wenson Hsieh.

        * UIProcess/API/APIPageConfiguration.cpp:
        (API::PageConfiguration::copy const):
        * UIProcess/API/APIPageConfiguration.h:
        (API::PageConfiguration::clickInteractionDriverForTesting const):
        (API::PageConfiguration::setClickInteractionDriverForTesting):
        * UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
        (-[WKWebViewConfiguration _setClickInteractionDriverForTesting:]):
        (-[WKWebViewConfiguration _clickInteractionDriverForTesting]):
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _registerPreview]):

2019-06-20  Alexander Mikhaylenko  <exalm7659@gmail.com>

        [GTK] Enable navigation swipe layout tests
        https://bugs.webkit.org/show_bug.cgi?id=198995

        Reviewed by Michael Catanzaro.

        Implement API for enabling and controlling swipes from WebKitTestRunner.

        Implement beginSimulatedSwipeInDirectionForTesting() and completeSimulatedSwipeInDirectionForTesting()
        in ViewGestureController for controlling the test swipes. Add functions in WebKitWebViewBase for calling
        them.

        Simulate the gesture by generating two scroll events: one to begin the gesture and one to complete it.

        Since there's no reliable way to set source device type of the generated events to touchpad, don't check
        source device type for simulated swipes.

        * UIProcess/API/C/gtk/WKView.cpp:
        (WKViewSetEnableBackForwardNavigationGesture): Added.
        (WKViewBeginBackSwipeForTesting): Added.
        (WKViewCompleteBackSwipeForTesting): Added.
        * UIProcess/API/C/gtk/WKViewPrivate.h:
        * UIProcess/API/gtk/WebKitWebViewBase.cpp:
        (webkitWebViewBaseBeginBackSwipeForTesting): Added.
        (webkitWebViewBaseCompleteBackSwipeForTesting): Added.
        * UIProcess/API/gtk/WebKitWebViewBasePrivate.h:
        * UIProcess/ViewGestureController.h:
        * UIProcess/gtk/ViewGestureControllerGtk.cpp:
        (WebKit::ViewGestureController::PendingSwipeTracker::scrollEventCanInfluenceSwipe):
        Skip source device type check for simulated swipes. Also, remove an incorrect FIXME.
        (WebKit::createScrollEvent): Added.
        (WebKit::ViewGestureController::beginSimulatedSwipeInDirectionForTesting): Implemented.
        (WebKit::ViewGestureController::completeSimulatedSwipeInDirectionForTesting): Implemented.

2019-06-20  Charlie Turner  <cturner@igalia.com>

        [GTK] Make startup pause available in DEVELOPER_MODE rather than DEBUG.
        https://bugs.webkit.org/show_bug.cgi?id=199069

        Reviewed by Michael Catanzaro.

        * WebProcess/gtk/WebProcessMainGtk.cpp: Allow developers to pause
        the web process in DEVELOPER_MODE rather than only DEBUG, matching
        the WPE behaviour and also the purpose of DEVELOPER_MODE.

2019-06-20  Alexander Mikhaylenko  <exalm7659@gmail.com>

        [GTK] The Previous/Next gesture should handle RTL
        https://bugs.webkit.org/show_bug.cgi?id=198707

        Reviewed by Michael Catanzaro.

        The gesture uses PageClientImpl::userInterfaceLayoutDirection() to determine the text
        direction. Implement that method, then adjust drawing so that the pages move from/to
        the left instead of right side for RTL locales.

        * UIProcess/API/gtk/PageClientImpl.cpp:
        (WebKit::): Implemented.
        * UIProcess/API/gtk/PageClientImpl.h:
        * UIProcess/gtk/ViewGestureControllerGtk.cpp:
        (WebKit::ViewGestureController::draw):

2019-06-20  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK] Remove support for GTK2 plugins
        https://bugs.webkit.org/show_bug.cgi?id=199065

        Reviewed by Sergio Villar Senin.

        * PlatformGTK.cmake:
        * Shared/Plugins/Netscape/NetscapePluginModule.cpp:
        (WebKit::moduleMixesGtkSymbols):
        * Shared/Plugins/Netscape/unix/NetscapePluginModuleUnix.cpp:
        (WebKit::NetscapePluginModule::getPluginInfo):
        * Shared/Plugins/PluginModuleInfo.h:
        * Shared/gtk/WebEventFactory.cpp:
        (WebKit::isGdkKeyCodeFromKeyPad):
        (WebKit::buttonForEvent):
        (WebKit::WebEventFactory::createWebMouseEvent):
        (WebKit::WebEventFactory::createWebWheelEvent):
        (WebKit::WebEventFactory::createWebKeyboardEvent):
        (WebKit::WebEventFactory::createWebTouchEvent):
        * SourcesGTK.txt:
        * UIProcess/API/gtk/WebKitWebViewBase.cpp:
        * UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:
        (WebKit::ProcessLauncher::launchProcess):
        * UIProcess/Plugins/PluginProcessProxy.h:
        * UIProcess/Plugins/gtk/PluginInfoCache.cpp:
        (WebKit::PluginInfoCache::getPluginInfo):
        (WebKit::PluginInfoCache::updatePluginInfo):
        * UIProcess/Plugins/unix/PluginInfoStoreUnix.cpp:
        (WebKit::PluginInfoStore::getPluginInfo):
        * UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp:
        (WebKit::PluginProcessProxy::platformGetLaunchOptionsWithAttributes):
        (WebKit::PluginProcessProxy::scanPlugin):
        * WebProcess/Plugins/Netscape/x11/NetscapePluginX11.cpp:

2019-06-19  Dean Jackson  <dino@apple.com>

        No menu pop-up when long pressing on a link in Firefox app
        https://bugs.webkit.org/show_bug.cgi?id=199045
        <rdar://problem/51422407>

        Reviewed by Tim Horton.

        Add a version check for linking on-or-after iOS 13. When
        that isn't true, we don't use UIContextMenuInteraction
        and instead fall back on the legacy UIPreviewItem API.

        * UIProcess/Cocoa/VersionChecks.h: Add FirstThatHasUIContextMenuInteraction.
        * UIProcess/ios/WKContentViewInteraction.h: 
        * UIProcess/ios/WKContentViewInteraction.mm:
        (-[WKContentView _shouldUseContextMenus]): New method to decide if we should
        use context menus or preview items.
        (-[WKContentView setupInteraction]): Make the decision at runtime rather than
        compile time.
        (-[WKContentView _contentsOfUserInterfaceItem:]): Ditto.
        (-[WKContentView _registerPreview]): Ditto.
        (-[WKContentView _unregisterPreview]): Ditto.

2019-06-19  Andy Estes  <aestes@apple.com>

        [iOS] Fall back to taking a UIView snapshohot for UITargetedPreviews if InteractionInformationAtPosition does not have an image
        https://bugs.webkit.org/show_bug.cgi?id=199038
        <rdar://problem/50555810>

        Reviewed by Tim Horton.

        In -contextMenuInteraction:previewForHighlightingMenuWithConfiguration: and friend, we
        should always return a non-nil UITargetedPreview. When we do return nil, UIKit uses the web
        view itself as the snapshot view, creating an unsightly animation.

        For cases where we fail to create a UITargetedPreview from the information in
        InteractionInformationAtPosition, this patch falls back to creating a UITargetedPreview with
        a snapshot view obtained from
        -[UIView resizableSnapshotViewFromRect:afterScreenUpdates:withCapInsets:].

        Also renamed -targetedPreview to -_ensureTargetedPreview and cached the UITargetedPreview
        for reuse in -contextMenuInteraction:previewForDismissingMenuWithConfiguration:.

        * UIProcess/ios/WKContentViewInteraction.h:
        * UIProcess/ios/WKContentViewInteraction.mm:
        (createFallbackTargetedPreview):
        (-[WKContentView _ensureTargetedPreview]):
        (-[WKContentView contextMenuInteraction:previewForHighlightingMenuWithConfiguration:]):
        (-[WKContentView contextMenuInteraction:previewForDismissingMenuWithConfiguration:]):
        (-[WKContentView contextMenuInteractionDidEnd:]):
        (-[WKContentView _targetedPreview]): Renamed to _ensureTargetedPreview.

2019-06-19  Devin Rousso  <drousso@apple.com>

        Web Inspector: Network: replace CFNetwork SPI with new API where able
        https://bugs.webkit.org/show_bug.cgi?id=198762

        Reviewed by Timothy Hatcher.

        * NetworkProcess/cocoa/NetworkSessionCocoa.mm:
        (-[WKNetworkSessionDelegate URLSession:task:didFinishCollectingMetrics:]):

2019-06-19  Alex Christensen  <achristensen@webkit.org>

        DownloadMonitor::measuredThroughputRate should approach zero with no throughput
        https://bugs.webkit.org/show_bug.cgi?id=198981
        <rdar://problem/51456914>

        Reviewed by Geoffrey Garen.

        When the timer fires to approximate the download rate, add a new timestamp with 0 bytes received since the last time we received bytes.
        Then, if there's only one timestamp, assume the throughput rate is 0 instead of infinite.
        This will prevent false positives estimating large download rates based on old data when the throughput drops to 0.

        * NetworkProcess/Downloads/DownloadMonitor.cpp:
        (WebKit::DownloadMonitor::measuredThroughputRate const):
        (WebKit::DownloadMonitor::timerFired):

2019-06-19  Sihui Liu  <sihui_liu@apple.com>

        Remove unused originsWithCredentials from WebsiteData
        https://bugs.webkit.org/show_bug.cgi?id=199020