[webkit-changes] [WebKit/WebKit] cf8b52: Cherry-pick 252432.1045 at safari-7614-branch (77446d...

[Chris Dumez]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: cf8b521ab2010b043f9ce89169149f479c5f02ac
      https://github.com/WebKit/WebKit/commit/cf8b521ab2010b043f9ce89169149f479c5f02ac
  Author: Mark Lam <mark.lam at apple.com>
  Date:   2023-03-31 (Fri, 31 Mar 2023)

  Changed paths:
    M Source/JavaScriptCore/API/JSCallbackConstructor.h
    M Source/JavaScriptCore/API/JSCallbackFunction.h
    M Source/JavaScriptCore/API/JSClassRef.h
    M Source/JavaScriptCore/API/JSWeakObjectMapRefInternal.h
    M Source/JavaScriptCore/API/ObjCCallbackFunction.h
    M Source/JavaScriptCore/runtime/ClassInfo.h
    M Source/JavaScriptCore/runtime/Lookup.h

  Log Message:
  -----------
  Cherry-pick 252432.1045 at safari-7614-branch (77446d5c727e). rdar://107473787

    [Re-land] Add additional PAC diversity for function pointers in JSC API data structures as we do for vtbls.
    https://bugs.webkit.org/show_bug.cgi?id=248702
    <rdar://problem/102768157>

    Reviewed by Yusuke Suzuki.

    * Source/JavaScriptCore/API/JSCallbackConstructor.h:
    * Source/JavaScriptCore/API/JSCallbackFunction.h:
    * Source/JavaScriptCore/API/JSClassRef.h:
    * Source/JavaScriptCore/API/JSWeakObjectMapRefInternal.h:
    * Source/JavaScriptCore/API/ObjCCallbackFunction.h:
    * Source/JavaScriptCore/runtime/ClassInfo.h:
    * Source/JavaScriptCore/runtime/Lookup.h:

    Canonical link: https://commits.webkit.org/252432.1045@safari-7614-branch

Canonical link: https://commits.webkit.org/262447@main


  Commit: bbd4b0ac5848fa94bbcb7c6aa87df4ab352acabf
      https://github.com/WebKit/WebKit/commit/bbd4b0ac5848fa94bbcb7c6aa87df4ab352acabf
  Author: Ryan Reno <rreno at apple.com>
  Date:   2023-03-31 (Fri, 31 Mar 2023)

  Changed paths:
    M Source/JavaScriptCore/API/JSScript.mm
    M Source/JavaScriptCore/API/JSScriptRef.cpp
    M Source/JavaScriptCore/inspector/ScriptCallFrame.cpp
    M Source/JavaScriptCore/inspector/ScriptCallFrame.h
    M Source/JavaScriptCore/inspector/ScriptCallStackFactory.cpp
    M Source/JavaScriptCore/interpreter/StackVisitor.cpp
    M Source/JavaScriptCore/interpreter/StackVisitor.h
    M Source/JavaScriptCore/parser/SourceProvider.cpp
    M Source/JavaScriptCore/parser/SourceProvider.h
    M Source/JavaScriptCore/runtime/CachedTypes.cpp
    M Source/JavaScriptCore/runtime/ScriptExecutable.h
    M Source/WebCore/bindings/js/CachedScriptSourceProvider.h
    M Source/WebCore/bindings/js/ScriptBufferSourceProvider.h
    M Source/WebCore/bindings/js/ScriptModuleLoader.cpp
    M Source/WebCore/bindings/js/ScriptSourceCode.h
    M Source/WebCore/page/csp/ContentSecurityPolicy.cpp
    M Source/WebCore/workers/WorkerGlobalScope.cpp
    M Source/WebCore/workers/WorkerThread.cpp

  Log Message:
  -----------
  Cherry-pick 259548.39 at safari-7615-branch (c68b7da0d9b4). rdar://107474520

    Cross-Site Information Leak: CSP violation reports may contain a post-redirect URL
    https://bugs.webkit.org/show_bug.cgi?id=251282
    rdar://104753003

    Reviewed by Yusuke Suzuki.

    The source-file field of a CSP violation report may contain a URL which has sensitive data in the
    query string if it was the result of a redirect. The CSP spec in non-normative terms suggests
    that in the case of a redirect (such as a login flow which appends a login token) we should report
    violations in the resulting resource with the pre-redirect URL to avoid cross-site information leaks
    via the CSP reporting API.

    Source/JavaScriptCore:
      Plubming code to make pre-redirect URLs available in ScriptCallStacks.
      When a ScriptCallStack is created by the StackVisitor the ScriptCallFrame
      objects will be populated with the pre-redirect URL by consulting the SourceProvider. WebCore
      will conditionally set the preRedirectURL member if the resource was obtained via a redirected
      response.

    * Source/JavaScriptCore/API/JSScript.mm:
    (-[JSScript sourceCode]):
    * Source/JavaScriptCore/API/JSScriptRef.cpp:
    * Source/JavaScriptCore/inspector/ScriptCallFrame.cpp:
    (Inspector::ScriptCallFrame::ScriptCallFrame):
    (Inspector::ScriptCallFrame::isEqual const):
    * Source/JavaScriptCore/inspector/ScriptCallFrame.h:
    * Source/JavaScriptCore/inspector/ScriptCallStackFactory.cpp:
    (Inspector::CreateScriptCallStackFunctor::operator() const):
    * Source/JavaScriptCore/interpreter/StackVisitor.cpp:
    (JSC::StackVisitor::Frame::preRedirectURL const):
    * Source/JavaScriptCore/interpreter/StackVisitor.h:
    * Source/JavaScriptCore/parser/SourceProvider.cpp:
    (JSC::SourceProvider::SourceProvider):
    (JSC::BaseWebAssemblySourceProvider::BaseWebAssemblySourceProvider):
    * Source/JavaScriptCore/parser/SourceProvider.h:
    (JSC::SourceProvider::preRedirectURL const):
    (JSC::StringSourceProvider::StringSourceProvider):
    * Source/JavaScriptCore/runtime/CachedTypes.cpp:
    (JSC::CachedSourceProviderShape::encode):
    * Source/JavaScriptCore/runtime/ScriptExecutable.h:
    (JSC::ScriptExecutable::preRedirectURL const):

    Source/WebCore:
      This updates the constructors for ScriptSourceCode objects to pass
      null strings for the preRedirectURL parameter. In the cases where we can detect
      whether a redirect happened or not we pass the pre-redirect URL to the SourceProvider.

    * Source/WebCore/bindings/js/CachedScriptSourceProvider.h:
    (WebCore::CachedScriptSourceProvider::CachedScriptSourceProvider):
    * Source/WebCore/bindings/js/ScriptBufferSourceProvider.h:
    * Source/WebCore/bindings/js/ScriptModuleLoader.cpp:
    (WebCore::ScriptModuleLoader::notifyFinished):
    * Source/WebCore/bindings/js/ScriptSourceCode.h:
    (WebCore::ScriptSourceCode::ScriptSourceCode):
    * Source/WebCore/workers/WorkerGlobalScope.cpp:
    (WebCore::WorkerGlobalScope::importScripts):
    * Source/WebCore/workers/WorkerThread.cpp:
    (WebCore::WorkerThread::evaluateScriptIfNecessary):

    * Source/WebCore/page/csp/ContentSecurityPolicy.cpp:
    (WebCore::ContentSecurityPolicy::reportViolation const):
      To populate the source-file field of a CSP report we consult the
      JavaScript call stack. The source URL of the frame may be the
      result of a redirect in which case we should use the pre-redirect
      URL in the report to avoid leaking potentially sensitive data in the post-redirect URL.

    Canonical link: https://commits.webkit.org/259548.39@safari-7615-branch

Canonical link: https://commits.webkit.org/262448@main


  Commit: faa22c0d431338ec56125e08b68ae2bf9b4e5949
      https://github.com/WebKit/WebKit/commit/faa22c0d431338ec56125e08b68ae2bf9b4e5949
  Author: Chirag M Shah <chirag_m_shah at apple.com>
  Date:   2023-03-31 (Fri, 31 Mar 2023)

  Changed paths:
    M LayoutTests/imported/w3c/web-platform-tests/mathml/relations/css-styling/out-of-flow/all-mathml-containers-expected.txt
    A LayoutTests/mathml/mathmltoken-layout-crash-expected.txt
    A LayoutTests/mathml/mathmltoken-layout-crash.html
    M Source/WebCore/rendering/mathml/RenderMathMLToken.cpp

  Log Message:
  -----------
  Cherry-pick 259548.40 at safari-7615-branch (bf2c7c5b03b0). rdar://107474555

    Fix layout for positioned children for RenderMathMLToken
    rdar://104598552

    Reviewed by Alan Baradlay.

    Before this change, the layout method in RenderMathMLToken (<ms>) never
    added positioned elements to the map for their container, which meant if
    the positioned children are dirty, their layout will never be triggered.
    This change fixes that by looking at direct children of
    RenderMathMLToken and adding them to their container's positioned
    elements map, so that their layout happens as expected.

    * LayoutTests/mathml/mathmltoken-layout-crash-expected.txt: Added.
    * LayoutTests/mathml/mathmltoken-layout-crash.html: Added.
    * Source/WebCore/rendering/mathml/RenderMathMLToken.cpp:
    (WebCore::RenderMathMLToken::layoutBlock):

    Canonical link: https://commits.webkit.org/259548.40@safari-7615-branch

Canonical link: https://commits.webkit.org/262449@main


  Commit: 16963d77f57d897e338a0bea9e74257fc65c88d9
      https://github.com/WebKit/WebKit/commit/16963d77f57d897e338a0bea9e74257fc65c88d9
  Author: Michael Saboff <msaboff at apple.com>
  Date:   2023-03-31 (Fri, 31 Mar 2023)

  Changed paths:
    M Source/JavaScriptCore/yarr/YarrJIT.cpp

  Log Message:
  -----------
  Cherry-pick 259548.45 at safari-7615-branch (9930b53ebce1). rdar://107474607

    [JSC] RegExp.test inline is missing another stack overflow checks
    https://bugs.webkit.org/show_bug.cgi?id=251741
    rdar://104072550

    Reviewed by Mark Lam.

    Converted the ASSERT(!m_failureReason) into a check that when true will bail out of the inline code
    and call out to the C++ operation.  This check handles any errors while compiling the RegExp pattern
    into YarrJIT IR during the processing of opCompileBody().

    I also audited all of the other possible error cases that the YarrJIT might produce and they are already
    handled by this and the prior change.

    The current test already covers this case.

    * Source/JavaScriptCore/yarr/YarrJIT.cpp:

    Canonical link: https://commits.webkit.org/259548.45@safari-7615-branch

Canonical link: https://commits.webkit.org/262450@main


  Commit: 2f7c74050e5b28c93963c359dddc44325fe14832
      https://github.com/WebKit/WebKit/commit/2f7c74050e5b28c93963c359dddc44325fe14832
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-03-31 (Fri, 31 Mar 2023)

  Changed paths:
    M Source/WTF/wtf/PlatformUse.h
    M Source/WebCore/page/MemoryRelease.cpp
    M Source/WebCore/platform/audio/HRTFElevation.cpp
    M Source/WebCore/platform/audio/HRTFElevation.h

  Log Message:
  -----------
  Cherry-pick 259548.46 at safari-7615-branch (a00a15e7abe0). rdar://107474676

    Fix various issues with HRTFElevation's getConcatenatedImpulseResponsesForSubject()
    https://bugs.webkit.org/show_bug.cgi?id=251643
    rdar://104980786

    Reviewed by Eric Carlson.

    Fix various issues with HRTFElevation's getConcatenatedImpulseResponsesForSubject():
    - Add a lock to synchronize access to the global HashMap of AudioBus objects
      since this may get called from different threads.
    - Make sure we call isolatedCopy() on the String key before adding it to the HashMap
      for thread safety.
    - Make sure we clear this global HashMap on critical memory pressure to free up
      memory.
    - Use smart pointers instead of raw pointers.
    - Modernize the code a bit.

    * Source/WTF/wtf/PlatformUse.h:
    * Source/WebCore/page/MemoryRelease.cpp:
    (WebCore::releaseCriticalMemory):
    * Source/WebCore/platform/audio/HRTFElevation.cpp:
    (WebCore::WTF_REQUIRES_LOCK):
    (WebCore::getConcatenatedImpulseResponsesForSubject):
    (WebCore::HRTFElevation::clearCache):
    (WebCore::HRTFElevation::calculateKernelsForAzimuthElevation):
    * Source/WebCore/platform/audio/HRTFElevation.h:

    Canonical link: https://commits.webkit.org/259548.46@safari-7615-branch

Canonical link: https://commits.webkit.org/262451@main


Compare: https://github.com/WebKit/WebKit/compare/55616cb231b6...2f7c74050e5b