[webkit-changes] [WebKit/WebKit] 19413c: Versioning.

Mon Oct 2 16:50:47 PDT 2023

  Branch: refs/heads/safari-7616.1.27.13-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 19413cffce1b18e788ca45bd6be249378ee677e4
      https://github.com/WebKit/WebKit/commit/19413cffce1b18e788ca45bd6be249378ee677e4
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

Identifier: 265870.273 at safari-7616.1.27.13-branch

  Commit: b12841fcb133e051c9f4a2a61a6459f4f6f70c59
      https://github.com/WebKit/WebKit/commit/b12841fcb133e051c9f4a2a61a6459f4f6f70c59
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
    M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h
    M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
    M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
    M Source/JavaScriptCore/jit/AssemblyHelpers.cpp
    M Source/JavaScriptCore/jit/AssemblyHelpers.h
    M Source/JavaScriptCore/jit/JITOpcodes.cpp

  Log Message:
  -----------
  Cherry-pick 00e61ef559b5. rdar://problem/113143403

    [JSC] Squeeze object allocation JIT code
    https://bugs.webkit.org/show_bug.cgi?id=259151
    rdar://112145626

    Reviewed by Mark Lam.

    1. Use stp to update FreeList's data.
    2. Avoid unnecessary instructions (null clear) for most of cases by passing SlowAllocationResult enum.

    * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
    (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
    * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h:
    (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
    (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
    (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
    (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
    * Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
    (JSC::DFG::SpeculativeJIT::compileNewBoundFunction):
    (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
    * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
    (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
    * Source/JavaScriptCore/jit/AssemblyHelpers.cpp:
    (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
    (JSC::AssemblyHelpers::emitAllocate):
    (JSC::AssemblyHelpers::emitAllocateVariableSized):
    * Source/JavaScriptCore/jit/AssemblyHelpers.h:
    (JSC::AssemblyHelpers::emitAllocateJSCell):
    (JSC::AssemblyHelpers::emitAllocateJSObject):
    (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
    (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
    (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
    * Source/JavaScriptCore/jit/JITOpcodes.cpp:
    (JSC::JIT::emit_op_new_object):
    (JSC::JIT::emit_op_create_this):

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

Identifier: 265870.274 at safari-7616.1.27.13-branch

  Commit: 8af6c38ecf3a7c044a7fec099104f12226051e2f
      https://github.com/WebKit/WebKit/commit/8af6c38ecf3a7c044a7fec099104f12226051e2f
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    A JSTests/stress/rope-resolve-recursive-non-ascii.js
    A JSTests/stress/rope-resolve-recursive.js
    A JSTests/stress/three-rope-non-ascii.js
    A JSTests/stress/three-rope.js
    A JSTests/stress/two-rope-non-ascii.js
    A JSTests/stress/two-rope.js
    M Source/JavaScriptCore/runtime/JSString.cpp
    M Source/JavaScriptCore/runtime/JSString.h
    M Source/JavaScriptCore/runtime/JSStringInlines.h

  Log Message:
  -----------
  Cherry-pick 9c5c2c9fc89f. rdar://problem/113143401

    [JSC] JSRopeString::resolveToBuffer should have fast path for two rope+non-rope case
    https://bugs.webkit.org/show_bug.cgi?id=259176
    rdar://112178098

    Reviewed by Michael Saboff.

    JSRopeString can have three fibers. But we observed two fibers case, where only one is a rope, very commonly.
    This happens when you write code like this,

        var string = '';
        for (var i = 0; i < 1e6; ++i)
            string += char

    Then, the resulted string becomes two fibers rope, only left hand side gets super deep.
    We can handle this string, just recursively handle the left side (via tail-call), but just spreading the right side.

    This patch changes JSRopeString::resolveToBuffer to handle this kind of patterns efficiently. We carefully crafted this
    code so that the above pattern becomes repeated tail call to JSRopeString::resolveToBuffer. We also have sp checker so that
    this code works perfectly well even if the compiler is not supporting tail-calls (at some level, we stop and use slow-but-works mode).

    * Source/JavaScriptCore/runtime/JSString.cpp:
    (JSC::JSRopeString::resolveRopeInternalNoSubstring const):
    (JSC::JSRopeString::resolveRopeToAtomString const):
    (JSC::JSRopeString::resolveRopeToExistingAtomString const):
    (JSC::JSRopeString::resolveRopeWithFunction const):
    * Source/JavaScriptCore/runtime/JSString.h:
    * Source/JavaScriptCore/runtime/JSStringInlines.h:
    (JSC::JSRopeString::resolveToBuffer):
    (JSC::jsAtomString):

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

Identifier: 265870.275 at safari-7616.1.27.13-branch

  Commit: 5d545d4f84e2ea414361c3b3fa1ebff112e26f72
      https://github.com/WebKit/WebKit/commit/5d545d4f84e2ea414361c3b3fa1ebff112e26f72
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    A JSTests/stress/string-from-char-code-double.js
    M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
    M Source/JavaScriptCore/dfg/DFGClobberize.h
    M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
    M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp

  Log Message:
  -----------
  Cherry-pick 5d994adeb6a3. rdar://problem/113143381

    [JSC] Handle String.fromCharCode(double) in DFG
    https://bugs.webkit.org/show_bug.cgi?id=259207
    rdar://112245867

    Reviewed by Mark Lam.

    String.fromCharCode will perform toUInt32 onto the input. So we can just use existing mechanism (DFG's ValueToInt32)
    to accept it even if the input is double.

    * JSTests/stress/string-from-char-code-double.js: Added.
    (shouldBe):
    (test):
    * Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
    (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
    * Source/JavaScriptCore/dfg/DFGClobberize.h:
    (JSC::DFG::clobberize):
    * Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
    (JSC::DFG::FixupPhase::fixupNode):
    * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
    (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):

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

Identifier: 265870.276 at safari-7616.1.27.13-branch

  Commit: 999bdda0e4303dace301d42bce4f922fd0a275c1
      https://github.com/WebKit/WebKit/commit/999bdda0e4303dace301d42bce4f922fd0a275c1
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    A JSTests/microbenchmarks/rope-resolve-recursive.js
    M Source/JavaScriptCore/runtime/JSString.cpp
    M Source/JavaScriptCore/runtime/JSString.h
    M Source/JavaScriptCore/runtime/JSStringInlines.h
    M Source/WTF/wtf/Compiler.h

  Log Message:
  -----------
  Cherry-pick 4d816460b765. rdar://problem/113143358

    [JSC] Further optimize JSRopeString::resolveRope
    https://bugs.webkit.org/show_bug.cgi?id=259203
    rdar://112241674

    Reviewed by Mark Lam.

    This patch furhter improves JSRopeString::resolveRope and jsAtomString.

    1. We crafted JSRopeString::resolveToBuffer very carefully so that it becomes tail calls well.
       This allows clang to make it loop instead of calls for recursive resolveToBuffer calls, which
       is significantly efficient. We ensure this condition is met by using MUST_TAIL_CALL C++ attribute,
       which is available in clang.
    2. We tweak jsAtomString to make it better in terms of performance. It turned out these duplicate part
       is mandatory to make it super efficient, which is observed by JetStream2/WSL.

    Simple rope resolution gets 3-4% improvement.

                                       ToT                     Patched

    rope-resolve-recursive       21.3292+-0.6975     ^     20.5524+-0.0687        ^ definitely 1.0378x faster

    * Source/JavaScriptCore/runtime/JSString.cpp:
    (JSC::JSRopeString::resolveRopeInternalNoSubstring const):
    * Source/JavaScriptCore/runtime/JSString.h:
    * Source/JavaScriptCore/runtime/JSStringInlines.h:
    (JSC::JSRopeString::resolveToBufferSlow):
    (JSC::JSRopeString::resolveToBuffer):
    (JSC::jsAtomString):
    (JSC::JSStringFibers::JSStringFibers): Deleted.
    (JSC::JSStringFibers::fiber const): Deleted.
    (JSC::JSStringFibers::fiber0 const): Deleted.
    (JSC::JSStringFibers::fiber1 const): Deleted.
    (JSC::JSStringFibers::fiber2 const): Deleted.
    (): Deleted.
    * Source/WTF/wtf/Compiler.h:

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

Identifier: 265870.277 at safari-7616.1.27.13-branch

  Commit: 87c475770c900826785b589791b1b1a241710228
      https://github.com/WebKit/WebKit/commit/87c475770c900826785b589791b1b1a241710228
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/JavaScriptCore/runtime/PropertyName.h

  Log Message:
  -----------
  Cherry-pick 7b6f95072a21. rdar://problem/113143380

    [JSC] Early return from isCanonicalNumericIndexString when it is definitely not a number
    https://bugs.webkit.org/show_bug.cgi?id=259230
    rdar://112292849

    Reviewed by Alexey Shvayka.

    This patch makes isCanonicalNumericIndexString early return for obvious non number cases
    so that we avoid super costly number-to-string & string-to-number path.

    * Source/JavaScriptCore/runtime/PropertyName.h:
    (JSC::isCanonicalNumericIndexString):

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

Identifier: 265870.278 at safari-7616.1.27.13-branch

  Commit: 551d35f13ec0301694bf5f9135ad2fb324955437
      https://github.com/WebKit/WebKit/commit/551d35f13ec0301694bf5f9135ad2fb324955437
  Author: Richard Robinson <richard_robinson2 at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/WTF/wtf/PlatformHave.h
    M Source/WebKit/Platform/spi/mac/AppKitSPI.h
    M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
    M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
    M Source/WebKit/UIProcess/API/mac/WKView.mm
    M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
    M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h
    M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm
    M Source/WebKit/UIProcess/mac/WebViewImpl.h
    M Source/WebKit/UIProcess/mac/WebViewImpl.mm

  Log Message:
  -----------
  Cherry-pick 3d721c09585b. rdar://problem/111534888

    REGRESSION (UI-side compositing): Jumpy full screen transition animation
    https://bugs.webkit.org/show_bug.cgi?id=259375
    rdar://111534888

    Reviewed by Wenson Hsieh.

    With UI-side compositing, when entering or exiting window fullscreen mode, the transition is
    sometimes jumpy. This happens in cases where the UI process resizes before the web content has a
    chance to resize. The web content and the UI Process should always resize in the same CA commit.

    Fix by adopting an AppKit SPI to defer entering or exiting window fullscreen mode until the web
    content has actually been resized to the new size. This is done by using a "window snapshot readiness handler".

    * Source/WTF/wtf/PlatformHave.h:
    Add a new `HAVE` definition to only enable this on macOS, and only on versions where the SPI exists.

    * Source/WebKit/Platform/spi/mac/AppKitSPI.h:
    * Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
    (-[WKWebView dealloc]):
    (-[WKWebView _invalidateWindowSnapshotReadinessHandler]):
    Invokes the readiness handler and then resets it, indicating to AppKit that the full screen should
    be allowed to resume.

    * Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
    * Source/WebKit/UIProcess/API/mac/WKView.mm:
    (-[WKView _web_windowWillEnterFullScreen]):
    (-[WKView _web_windowWillExitFullScreen]):
    Stub methods required to compile legacy WebKit.

    * Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
    (-[WKWebView _doWindowSnapshotReadinessUpdate]):
    (-[WKWebView setFrameSize:]):
    When `setFrameSize` gets called with the new frame size, the UI process waits for the next presentation
    update of the web prcoess. Once in the completion handler, we know that the web content has properly
    resized, and so we should now invalidate the readiness handler.

    (-[WKWebView _web_windowWillEnterFullScreen]):
    (-[WKWebView _web_windowWillExitFullScreen]):
    Upon receiving one of these notifications, we take out a window snapshot readiness handler and store
    it. This tells AppKit to defer the final stage of the enter and exit full screen animations until
    the handler is invoked.

    * Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
    * Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
    (-[WKViewLayoutStrategy disableFrameSizeUpdates]):
    (-[WKViewLayoutStrategy enableFrameSizeUpdates]):
    (-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
    (-[WKViewLayoutStrategy didChangeFrameSize]):
    In some cases, `setFrameSize` would early return inside of `didChangeFrameSize` due to these set of
    methods. This caused the bug to still reproduce, since the new drawing area size was no longer being set.

    These methods have long been not actually needed, so their implementations are now removed and there is
    no longer a need for an early return.

    * Source/WebKit/UIProcess/mac/WebViewImpl.h:
    * Source/WebKit/UIProcess/mac/WebViewImpl.mm:
    (-[WKWindowVisibilityObserver startObserving:]):
    (-[WKWindowVisibilityObserver stopObserving:]):
    (-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]):
    (-[WKWindowVisibilityObserver _windowWillExitFullScreen:]):
    (WebKit::WebViewImpl::windowWillEnterFullScreen):
    (WebKit::WebViewImpl::windowWillExitFullScreen):
    When entering or exiting full screen, we now listen to their respective notifications.

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

Identifier: 265870.279 at safari-7616.1.27.13-branch

  Commit: d3ee930967af12ead6f09f97ffe956f1ad9d00ab
      https://github.com/WebKit/WebKit/commit/d3ee930967af12ead6f09f97ffe956f1ad9d00ab
  Author: Kyle Piddington <kpiddington at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj

  Log Message:
  -----------
  Cherry-pick b258292b1506. rdar://problem/112819533

    Dont build default.metallib when building ANGLE
    https://bugs.webkit.org/show_bug.cgi?id=259509
    <rdar://112819533>
    Reviewed by Alex Christensen.

    The autogenerated metal file was accidently included as a
    build target in ANGLE's default shared library. It's previously
    been compiled in a seperate project that builds to
    "ANGLEMetalLib.metallib". After the last ANGLE roll,
    it was building to both "default.metallib" and 'ANGLEMetalLib.metallib'

    This change restores the previous behavior for this library.

    * Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj:

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

Identifier: 265870.280 at safari-7616.1.27.13-branch

  Commit: 6595f7362fd5d57d0abe89af093bf085ba646e67
      https://github.com/WebKit/WebKit/commit/6595f7362fd5d57d0abe89af093bf085ba646e67
  Author: Commit Queue <commit-queue at webkit.org>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    R LayoutTests/fast/forms/label/label-selection-expected.txt
    R LayoutTests/fast/forms/label/label-selection.html
    M LayoutTests/platform/ios/TestExpectations
    M Source/WebCore/html/HTMLLabelElement.cpp

  Log Message:
  -----------
  Cherry-pick a799925247d5. rdar://problem/112973142

    Unreviewed, reverting 263420 at main.
    https://bugs.webkit.org/show_bug.cgi?id=259558

    'caused WPT regression in test *proxy-modifier-click-to-associated-element.tentative.html'*

    Reverted changeset:

    "Cannot select text within a label element that is linked to an input field"
    https://bugs.webkit.org/show_bug.cgi?id=96734
    https://commits.webkit.org/263420@main

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

Identifier: 265870.281 at safari-7616.1.27.13-branch

  Commit: 6583e3e153197dbf213ac495086d09c2fc538deb
      https://github.com/WebKit/WebKit/commit/6583e3e153197dbf213ac495086d09c2fc538deb
  Author: Razvan Caliman <rcaliman at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js

  Log Message:
  -----------
  Cherry-pick 48da5f9506d1. rdar://problem/112984488

    Uncaught Exception: TypeError: undefined is not an object (evaluating 'this.contentBrowser.currentContentView')
    https://bugs.webkit.org/show_bug.cgi?id=259566
    rdar://112984488

    Reviewed by Devin Rousso.

    * Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js:
    (WI.SourcesNavigationSidebarPanel.prototype._handleResourceGroupingModeChanged):

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

Identifier: 265870.282 at safari-7616.1.27.13-branch

  Commit: f98ac85df52f74789c4cc43350a24513f3014a82
      https://github.com/WebKit/WebKit/commit/f98ac85df52f74789c4cc43350a24513f3014a82
  Author: Tim Nguyen <ntim at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    A LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree-expected.txt
    A LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree.html
    M Source/WebCore/dom/Document.cpp

  Log Message:
  -----------
  Cherry-pick 9336846dfe3b. rdar://problem/112410375

    [popover] Using shadow DOM wrongly auto-hides popover by light dismiss
    https://bugs.webkit.org/show_bug.cgi?id=259261
    rdar://112410375

    Reviewed by Ryosuke Niwa and Darin Adler.

    Use the flat tree as mandated by the spec when calculating which popover to light dismiss:
    - https://html.spec.whatwg.org/#topmost-clicked-popover
    - https://html.spec.whatwg.org/#nearest-inclusive-open-popover
    - https://html.spec.whatwg.org/#nearest-inclusive-target-popover-for-invoker

    * LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree-expected.txt: Added.
    * LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree.html: Added.
    * Source/WebCore/dom/Document.cpp:
    (WebCore::Document::handlePopoverLightDismiss):

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

Identifier: 265870.283 at safari-7616.1.27.13-branch

  Commit: 422f537ae4b3c8066a3c58271435b8f12f5bfe68
      https://github.com/WebKit/WebKit/commit/422f537ae4b3c8066a3c58271435b8f12f5bfe68
  Author: Tyler Wilcock <tyler_w at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/WebCore/accessibility/AXLogger.cpp
    M Source/WebCore/accessibility/AXObjectCache.cpp
    M Source/WebCore/accessibility/AXObjectCache.h
    M Source/WebCore/accessibility/AccessibilityMenuListOption.h
    M Source/WebCore/accessibility/AccessibilitySpinButton.h

  Log Message:
  -----------
  Cherry-pick 5b4bb30a99e4. rdar://problem/113042000

    Cherry-pick 266406 at main (5b4bb30a99e4). rdar://113042000

        AX: Finish converting all WebCore/accessibility member variables to use smart pointers
        https://bugs.webkit.org/show_bug.cgi?id=259606
        rdar://113042000

        Reviewed by Chris Fleizach.

        Continued work towards complying with https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines.

        * Source/WebCore/accessibility/AXLogger.cpp:
        (WebCore::AXLogger::log):
        * Source/WebCore/accessibility/AXObjectCache.cpp:
        (WebCore::AXObjectCache::AXObjectCache):
        (WebCore::AXObjectCache::rootObject):
        (WebCore::AXObjectCache::setIsolatedTreeRoot):
        (WebCore::AXObjectCache::remove):
        (WebCore::AXObjectCache::deferNodeAddedOrRemoved):
        (WebCore::AXObjectCache::notificationPostTimerFired):
        (WebCore::AXObjectCache::focusCurrentModal):
        (WebCore::AXObjectCache::characterOffsetForPoint):
        (WebCore::filterWeakListHashSetForRemoval):
        (WebCore::filterWeakHashMapForRemoval):
        (WebCore::AXObjectCache::prepareForDocumentDestruction):
        (WebCore::AXObjectCache::performDeferredCacheUpdate):
        (WebCore::AXObjectCache::deferTextChangedIfNeeded):
        (WebCore::AXObjectCache::deferTextReplacementNotificationForTextControl):
        (WebCore::AXObjectCache::rootWebArea):
        (WebCore::AXObjectCache::updateRelationsIfNeeded):
        (WebCore::AXObjectCache::addRelations):
        * Source/WebCore/accessibility/AXObjectCache.h:
        (WebCore::AXObjectCache::document const):
        * Source/WebCore/accessibility/AccessibilityMenuListOption.h:
        * Source/WebCore/accessibility/AccessibilitySpinButton.h:

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

Identifier: 265870.284 at safari-7616.1.27.13-branch

  Commit: 651b005b2ef77b0a44d2c3024a95f3801a8d1eb7
      https://github.com/WebKit/WebKit/commit/651b005b2ef77b0a44d2c3024a95f3801a8d1eb7
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp
    M Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm

  Log Message:
  -----------
  Cherry-pick 4f26424a4687. rdar://problem/113060681

    REGRESSION (266341 at main): mousemove no longer dispatched when UI-side compositing is disabled
    https://bugs.webkit.org/show_bug.cgi?id=259618

    Reviewed by Aditya Keerthi.

    After the changes in 266341 at main, when UI-side compositing is disabled, we can end up in a state where mouse events are
    indefinitely queued in the UI process, as the web process never flushes the deferred DidReceiveEvent message for a
    mousemove event that has already been handled. This is because `TiledCoreAnimationDrawingArea::scheduleRenderingUpdate`
    is unimplemented, and so nothing guarantees that we'll eventually send the deferred `DidReceiveEvent` back to the UI
    process.

    Fix this by avoiding the deferred `DidReceiveEvent` if `scheduleRenderingUpdate()` returns `false` (indicating that no
    rendering update is scheduled). In practice, this effectively disables the changes in 266341 at main unless we're using a
    remote layer tree drawing area, which is now the default on both macOS Sonoma (in most device models) and iOS 17, which
    enable UI-side compositing.

    Test: MouseEventTests.SendMouseMoveEventStream

    * Source/WebKit/WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::mouseEvent):
    * Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm:

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

Identifier: 265870.285 at safari-7616.1.27.13-branch

  Commit: 9165679994d6d4a37796d116e9a85f139da903f3
      https://github.com/WebKit/WebKit/commit/9165679994d6d4a37796d116e9a85f139da903f3
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    R LayoutTests/fast/table/table-inside-continuation-removed-expected.txt
    R LayoutTests/fast/table/table-inside-continuation-removed.html
    M Source/WebCore/rendering/RenderTable.cpp
    M Source/WebCore/rendering/RenderTable.h
    M Source/WebCore/rendering/RenderTableCol.cpp

  Log Message:
  -----------
   Revert "Cherry-pick e1cc9fc57dbe. rdar://problem/111803504"

* LayoutTests/fast/table/table-inside-continuation-removed-expected.txt: Removed.
* LayoutTests/fast/table/table-inside-continuation-removed.html: Removed.
* Source/WebCore/rendering/RenderTable.cpp:
(WebCore::RenderTable::removeColumn):
(WebCore::RenderTable::invalidateColumns): Deleted.
* Source/WebCore/rendering/RenderTable.h:
* Source/WebCore/rendering/RenderTableCol.cpp:
(WebCore::RenderTableCol::willBeRemovedFromTree):

Identifier: 265870.286 at safari-7616.1.27.13-branch

  Commit: 995ad4598bd2399e6feec6a7cec1c298b98a5742
      https://github.com/WebKit/WebKit/commit/995ad4598bd2399e6feec6a7cec1c298b98a5742
  Author: Cameron McCormack <heycam at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Source/WebCore/html/HTMLCanvasElement.h
    M Source/WebCore/html/canvas/CanvasStyle.cpp

  Log Message:
  -----------
  Cherry-pick 5ec234192a2e. rdar://problem/112439220

    Cherry-pick 266238 at main (5ec234192a2e). rdar://112439220

        Avoid creating a new CSSParserContext each time a color is assigned to fillStyle/strokeStyle on a canvas context
        https://bugs.webkit.org/show_bug.cgi?id=259431
        rdar://112439220

        Reviewed by Tim Nguyen.

        Creating the CSSParserContext is slightly expensive, since it fetches all of the relevant document Settings.

        * Source/WebCore/html/HTMLCanvasElement.h:
        (WebCore::HTMLCanvasElement::cssParserContext):
        * Source/WebCore/html/canvas/CanvasStyle.cpp:
        (WebCore::parseColor):

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

Identifier: 265870.287 at safari-7616.1.27.13-branch

  Commit: 06e494697172df9383c7f1a4e214e3a48452bc6b
      https://github.com/WebKit/WebKit/commit/06e494697172df9383c7f1a4e214e3a48452bc6b
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-08-03 (Thu, 03 Aug 2023)

  Changed paths:
    M Source/WTF/wtf/PlatformHave.h
    M Source/WebKit/Platform/spi/mac/AppKitSPI.h
    M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
    M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
    M Source/WebKit/UIProcess/API/mac/WKView.mm
    M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
    M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h
    M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm
    M Source/WebKit/UIProcess/mac/WebViewImpl.h
    M Source/WebKit/UIProcess/mac/WebViewImpl.mm

  Log Message:
  -----------
   Revert "Cherry-pick 3d721c09585b. rdar://problem/111534888"

 This reverts commit 551d35f13ec0301694bf5f9135ad2fb324955437.

* Source/WTF/wtf/PlatformHave.h:
* Source/WebKit/Platform/spi/mac/AppKitSPI.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView dealloc]):
(-[WKWebView _invalidateWindowSnapshotReadinessHandler]): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView setFrameSize:]):
(-[WKWebView _doWindowSnapshotReadinessUpdate]): Deleted.
(-[WKWebView _holdWindowResizeSnapshotWithReason:]): Deleted.
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
(-[WKViewLayoutStrategy disableFrameSizeUpdates]):
(-[WKViewLayoutStrategy enableFrameSizeUpdates]):
(-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
(-[WKViewLayoutStrategy didChangeFrameSize]):
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.

Identifier: 265870.288 at safari-7616.1.27.13-branch

  Commit: 3de3fe9c701d81b18a7ca8317c0dfae068b18980
      https://github.com/WebKit/WebKit/commit/3de3fe9c701d81b18a7ca8317c0dfae068b18980
  Author: Ryan Reno <rreno at apple.com>
  Date:   2023-08-03 (Thu, 03 Aug 2023)

  Changed paths:
    M Source/WTF/wtf/MemoryPressureHandler.h
    M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  -----------
  Cherry-pick 8299d7639dd9. rdar://problem/109875865

    Change compositing policy in response to memory pressure status
    https://bugs.webkit.org/show_bug.cgi?id=259580
    rdar://109875865

    Reviewed by Simon Fraser.

    We switch to a more conservative compositing policy when the
    MemoryPressureHandler has a change in memory usage policy at most every
    2 seconds. In some cases we can enter memory warning and critical memory
    pressure situations and get a foreground jetsam before this 2s has
    expired. This change will respond to recent memory warning and memory
    pressure notifications in order to change the compositing policy. While we
    can't guarantee to not jetsam, this does improve our chances of
    reducing layer counts before the system gets critically low on
    memory.

    * Source/WTF/wtf/MemoryPressureHandler.h:
    (WTF::MemoryPressureHandler::isUnderMemoryWarning const):
    * Source/WebCore/rendering/RenderLayerCompositor.cpp:
    (WebCore::RenderLayerCompositor::updateCompositingPolicy):

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

Identifier: 265870.289 at safari-7616.1.27.13-branch

  Commit: c8736cca5fbdc1c0f2e6fbab5b8e1a0c25e2a1c3
      https://github.com/WebKit/WebKit/commit/c8736cca5fbdc1c0f2e6fbab5b8e1a0c25e2a1c3
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-08-03 (Thu, 03 Aug 2023)

  Changed paths:
    M Source/WTF/wtf/dtoa/utils.h

  Log Message:
  -----------
  Cherry-pick 9bd05bda44cc. rdar://problem/113341253

    dtoa/utils.h doesn't parse after recent SDK changes
    https://bugs.webkit.org/show_bug.cgi?id=259789
    rdar://113341253

    Reviewed by Wenson Hsieh.

    * Source/WTF/wtf/dtoa/utils.h:
    Recent SDK changes resulted in CoreUtils headers getting imported into
    translation units (OutputContext.mm) that also import `dtoa/utils.h`.

    The aforementioned CoreUtils headers have long had macros Min() and Max(),
    which conflict with our template functions' definitions, and make utils.h
    fail to parse.

    As a quick workaround, undefine the rogue macros before our Min() and Max().

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

Canonical link: https://commits.webkit.org/265870.290@safari-7616.1.27.13-branch

  Commit: 553da0f7b52cc50e34d76e9e1379c700f349385b
      https://github.com/WebKit/WebKit/commit/553da0f7b52cc50e34d76e9e1379c700f349385b
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-08-03 (Thu, 03 Aug 2023)

  Changed paths:
    M Source/WTF/wtf/SHA1.h

  Log Message:
  -----------
  Cherry-pick 9809c1a27c82. rdar://problem/113360320

    SHA1.h doesn't parse after recent SDK changes
    https://bugs.webkit.org/show_bug.cgi?id=259800
    rdar://113360320

    Reviewed by Megan Gardner and Wenson Hsieh.

    * Source/WTF/wtf/SHA1.h:
    Recent SDK changes resulted in CoreUtils headers getting imported into
    translation units (MediaPlayerPrivateWebM.mm) that also import `SHA1.h`.

    The aforementioned CoreUtils headers have long had a macro SHA1(),
    which conflict with our template functions' definitions, and make SHA1.h
    fail to parse.

    As a quick workaround, undefine the rogue macros before our SHA1 class.

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

Canonical link: https://commits.webkit.org/265870.291@safari-7616.1.27.13-branch

  Commit: de9566e607cb7bf528b77db2a8fa87638954639c
      https://github.com/WebKit/WebKit/commit/de9566e607cb7bf528b77db2a8fa87638954639c
  Author: Richard Robinson <richard_robinson2 at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm

  Log Message:
  -----------
  Cherry-pick 43da1fd1587a. rdar://problem/111534888

    WebKit Media: Toggling fullscreen fails to work
    https://bugs.webkit.org/show_bug.cgi?id=259760
    rdar://111534888

    Reviewed by Aditya Keerthi.

    The window resize handler is created when receiving the `will{Enter|Exit}FullScreen` notification,
    and is then invalidated as a result of `setFrameSize` being called. However, when transiting to/from
    element full screen, `setFrameSize` is called before the notification is posted, instead of after.
    This causes the handler to never be invalidated.

    Fix by creating the handler directly inside `setFrameSize`, and not rely on the full screen
    notifications at all. This is ok since `_holdResizeSnapshotWithReason` only returns a non-nil block
    when entering or exiting full screen, so it has no effect in other cases.

    No new tests, since all tests in `FullscreenVideoTextRecognition` already test this behavior in some
    configurations.

    * Source/WebKit/UIProcess/API/mac/WKView.mm:
    (-[WKView _web_windowWillEnterFullScreen]): Deleted.
    (-[WKView _web_windowWillExitFullScreen]): Deleted.
    * Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
    (-[WKWebView _holdWindowResizeSnapshotWithReason:]):
    (-[WKWebView setFrameSize:]):
    (-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
    (-[WKWebView _web_windowWillExitFullScreen]): Deleted.
    * Source/WebKit/UIProcess/mac/WebViewImpl.h:
    * Source/WebKit/UIProcess/mac/WebViewImpl.mm:
    (-[WKWindowVisibilityObserver startObserving:]):
    (-[WKWindowVisibilityObserver stopObserving:]):
    (-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
    (-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
    (WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
    (WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.

    Canonical link: https://commits.webkit.org/266558@main
Identifier: 265423.739 at safari-7616.1.27.13-branch

  Commit: 916a90535d784a62a78224e1223d546c69c5fe91
      https://github.com/WebKit/WebKit/commit/916a90535d784a62a78224e1223d546c69c5fe91
  Author: Andres Gonzalez <andresg_22 at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M LayoutTests/accessibility/mac/basic-embed-pdf-accessibility-expected.txt
    M LayoutTests/accessibility/mac/basic-embed-pdf-accessibility.html
    M LayoutTests/accessibility/mac/iframe-pdf.html

  Log Message:
  -----------
  Cherry-pick 00389e4e1673. rdar://problem/110029481

    REGRESSION: Two accessibility/mac/ tests are a consistent failure
    https://bugs.webkit.org/show_bug.cgi?id=259452
    rdar://110029481

    Reviewed by Chris Fleizach.

    These tests needed to be re-based and the value of the static text needs to be trimEnd() to accomodate differences in trailing \n between OS versions.

    * LayoutTests/accessibility/mac/basic-embed-pdf-accessibility-expected.txt:
    * LayoutTests/accessibility/mac/basic-embed-pdf-accessibility.html:
    * LayoutTests/accessibility/mac/iframe-pdf-expected.txt:

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

  Commit: 8505c76e299d4d6360072eac71d8ea9f072fb5c3
      https://github.com/WebKit/WebKit/commit/8505c76e299d4d6360072eac71d8ea9f072fb5c3
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Source/WTF/wtf/ThreadSafeWeakHashSet.h
    M Source/WTF/wtf/WeakHashMap.h
    M Source/WTF/wtf/WeakHashSet.h
    M Source/WTF/wtf/WeakListHashSet.h
    M Source/WebKit/NetworkProcess/NetworkDataTask.cpp
    M Source/WebKit/NetworkProcess/NetworkDataTaskBlob.cpp
    M Source/WebKit/NetworkProcess/NetworkDataTaskDataURL.cpp
    M Source/WebKit/NetworkProcess/NetworkSession.cpp
    M Source/WebKit/NetworkProcess/NetworkSession.h
    M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm
    M Source/WebKit/NetworkProcess/curl/NetworkDataTaskCurl.cpp
    M Source/WebKit/NetworkProcess/soup/NetworkDataTaskSoup.cpp
    M Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp

  Log Message:
  -----------
  Cherry-pick 177d6881d88d. rdar://problem/112162921

    Regression: NetworkDataTask's ThreadSafeWeakPtrControlBlock are leaking
    https://bugs.webkit.org/show_bug.cgi?id=259808
    rdar://112162921

    Reviewed by Alex Christensen.

    The NetworkProcess memory was growing unboundedly during long-running browsing
    benchmarks, which the number of NetworkDataTask's ThreadSafeWeakPtrControlBlock
    objects growing very large.

    The issue was with the `ThreadSafeWeakHashSet<NetworkDataTask> m_dataTaskSet`
    container on the NetworkSession. We would add NetworkDataTask objects to this
    WeakHashSet and never explicitly remove them. We had a comment in the code
    indicating that the ThreadSafeWeakHashSet's amortized clean up would take care
    of removing them. The issue though is that amortized clean up would never happen
    and m_dataTaskSet's internal Set would just grow unboundedly, keeping control
    blocks alive.

    The reason amortized clean up never triggered is that we only add to m_dataTaskSet,
    we never remove from it, never clear it and we only very rarely call forEach() on
    it. As a result, ThreadSafeWeakHashSet::m_operationCountSinceLastCleanup would only
    increment due to the add() calls. The condition for amortized clean up was:
    `++m_operationCountSinceLastCleanup / 2 > m_set.size()`.

    Since m_operationCountSinceLastCleanup would only increase due to the add() calls
    and since nothing would ever get removed from the set, `m_operationCountSinceLastCleanup / 2`
    could never reach the size of the set.

    I am making several fixes in this patch:
    1. I added a `|| m_operationCountSinceLastCleanup > m_maxOperationCountWithoutCleanup`
       check to amortized clean up to guarantee that amortized clean up eventually happens
       and that such weak containers can never grow unboundedly, no matter how they are used.
       m_maxOperationCountWithoutCleanup gets multiplied by 2 whenever the clean up finds
       nothing for proper amortization.
    2. I made it so that NetworkDataTask objects remove themselves from the ThreadSafeWeakHashSet
       in their destructor. This is good practice no matter what and makes such the set stays
       small.
    3. I actually found a bug in `ThreadSafeWeakHashSet::remove()` when implementing the fix in
       (2). ThreadSafeWeakHashSet::remove() would fail to remove the object from the set if the
       call if made after the object destructor has started running! The reason for this is that
       the ThreadSafeWeakHashSet was using a `std::pair<ControlBlockRefPtr, const T*>` as set
       key internally. This means that we needed to create a ControlBlockRefPtr of the object's
       control block in remove() in order to remove the object from the map. However, 265344 at main
       made it so that ref'ing a control block returns nullptr after the object has started
       destruction. As a result, the first item in the key pair would be nullptr and we'd fail
       to remove. To address the issue, I am dropping the ControlBlockRefPtr from the key and
       using a `HashMap<const T*, ControlBlockRefPtr>` instead of a HashSet.

    * Source/WTF/wtf/ThreadSafeWeakHashSet.h:
    * Source/WTF/wtf/WeakHashMap.h:
    * Source/WTF/wtf/WeakHashSet.h:
    * Source/WTF/wtf/WeakListHashSet.h:
    * Source/WebKit/NetworkProcess/NetworkDataTask.cpp:
    (WebKit::NetworkDataTask::~NetworkDataTask):
    * Source/WebKit/NetworkProcess/NetworkSession.cpp:
    (WebKit::NetworkSession::registerNetworkDataTask):
    (WebKit::NetworkSession::unregisterNetworkDataTask):
    * Source/WebKit/NetworkProcess/NetworkSession.h:
    * Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp:
    (TestWebKitAPI::ObjectAddingAndRemovingItself::create):
    (TestWebKitAPI::ObjectAddingAndRemovingItself::~ObjectAddingAndRemovingItself):
    (TestWebKitAPI::ObjectAddingAndRemovingItself::ObjectAddingAndRemovingItself):
    (TestWebKitAPI::TEST):
    (TestWebKitAPI::ObjectAddingItselfOnly::create):
    (TestWebKitAPI::ObjectAddingItselfOnly::ObjectAddingItselfOnly):

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

  Commit: 6e35c55b155033cc5a6c6fb467753559df2af02b
      https://github.com/WebKit/WebKit/commit/6e35c55b155033cc5a6c6fb467753559df2af02b
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-7616.1.27.13.2

Identifier: 265423.742 at safari-7616.1.27.13-branch

  Commit: 77a5e1d430357bce4a8aa65a99df0d975c782633
      https://github.com/WebKit/WebKit/commit/77a5e1d430357bce4a8aa65a99df0d975c782633
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2023-08-17 (Thu, 17 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-7616.1.27.13.3

Identifier: 265870.296 at safari-7616.1.27.13-branch

  Commit: e6ebf7aee39a8b14045a26626a122dc105226b06
      https://github.com/WebKit/WebKit/commit/e6ebf7aee39a8b14045a26626a122dc105226b06
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-08-17 (Thu, 17 Aug 2023)

  Changed paths:
    M Source/WebKit/NetworkProcess/NetworkDataTask.cpp

  Log Message:
  -----------
  Cherry-pick c0a7c3bf2d79. rdar://problem/114003508

    Regression(266594 at main) Crash under NetworkSession::unregisterNetworkDataTask()
    https://bugs.webkit.org/show_bug.cgi?id=259910
    <rdar://113530127>

    Reviewed by J Pascoe.

    NetworkDataTask::m_session is a WeakPtr and may thus be null by the time the
    NetworkDataTask runs. Null check it before calling `unregisterNetworkDataTask()`
    on it.

    * Source/WebKit/NetworkProcess/NetworkDataTask.cpp:
    (WebKit::NetworkDataTask::~NetworkDataTask):

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

Identifier: 265870.297 at safari-7616.1.27.13-branch

  Commit: 56841855159e36c4ce337e6c1985a3a4e4c90fd8
      https://github.com/WebKit/WebKit/commit/56841855159e36c4ce337e6c1985a3a4e4c90fd8
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2023-08-17 (Thu, 17 Aug 2023)

  Changed paths:
    M Source/WebKit/NetworkProcess/NetworkDataTask.cpp

  Log Message:
  -----------
  Revert "Cherry-pick c0a7c3bf2d79. rdar://problem/114003508"

This reverts commit e6ebf7aee39a8b14045a26626a122dc105226b06.

Identifier: 265870.298 at safari-7616.1.27.13-branch

  Commit: e1e3821203984ac9d25c3f6e613b71b10ea071dd
      https://github.com/WebKit/WebKit/commit/e1e3821203984ac9d25c3f6e613b71b10ea071dd
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2023-08-18 (Fri, 18 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-7616.1.27.13.4

Identifier: 265870.299 at safari-7616.1.27.13-branch

  Commit: db16d356bd90d790b7fc3c296ef70ba4b08efa4f
      https://github.com/WebKit/WebKit/commit/db16d356bd90d790b7fc3c296ef70ba4b08efa4f
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-08-18 (Fri, 18 Aug 2023)

  Changed paths:
    M Source/JavaScriptCore/heap/MachineStackMarker.h
    M Source/WTF/wtf/ThreadGroup.cpp
    M Source/WTF/wtf/ThreadGroup.h
    M Source/WTF/wtf/Threading.cpp
    M Source/WTF/wtf/Threading.h
    M Source/WTF/wtf/linux/RealTimeThreads.h
    M Source/WTF/wtf/threads/Signals.cpp
    M Tools/TestWebKitAPI/Tests/WTF/ThreadGroup.cpp

  Log Message:
  -----------
  Cherry-pick 3dd121c2e42e. rdar://113739113

    [WTF] Revert ThreadGroup to std::shared_ptr / std::weak_ptr implementation
    https://bugs.webkit.org/show_bug.cgi?id=260373
    rdar://113739113

    Reviewed by Mark Lam.

    Speculative fix. Let's revert our ThreadGroup and Thread implementation to use std::shared_ptr and std::weak_ptr
    instead of WebKit ThreadSafeWeakPtr and ThreadSafeWeakHashSet. This is basically partial revert of 257595 at main
    and 258267 at main (reverting part related to ThreadGroup and Thread).

    * Source/JavaScriptCore/heap/MachineStackMarker.h:
    * Source/WTF/wtf/ThreadGroup.cpp:
    (WTF::ThreadGroup::~ThreadGroup):
    (WTF::ThreadGroup::create): Deleted.
    * Source/WTF/wtf/ThreadGroup.h:
    * Source/WTF/wtf/Threading.cpp:
    (WTF::Thread::didExit):
    (WTF::Thread::addToThreadGroup):
    (WTF::Thread::removeFromThreadGroup):
    (WTF::Thread::numberOfThreadGroups):
    * Source/WTF/wtf/Threading.h:
    * Source/WTF/wtf/linux/RealTimeThreads.h:
    * Source/WTF/wtf/threads/Signals.cpp:
    (WTF::activeThreads):
    * Tools/TestWebKitAPI/Tests/WTF/ThreadGroup.cpp:
    (TestWebKitAPI::testThreadGroup):
    (TestWebKitAPI::TEST):

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

Identifier: 265870.300 at safari-7616.1.27.13-branch

Compare: https://github.com/WebKit/WebKit/compare/19413cffce1b%5E...db16d356bd90