[webkit-changes] [WebKit/WebKit] 52d51c: Cherry-pick 00e61ef559b5. rdar://problem/113143403

Mon Oct 2 16:50:44 PDT 2023

  Branch: refs/heads/safari-7616.1.27.12-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 52d51c5672dd40065ca16dbcb13292f7bd9e32da
      https://github.com/WebKit/WebKit/commit/52d51c5672dd40065ca16dbcb13292f7bd9e32da
  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

  Commit: d7bf98f9420dd7fcff6074b8ea61e96873048bde
      https://github.com/WebKit/WebKit/commit/d7bf98f9420dd7fcff6074b8ea61e96873048bde
  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

  Commit: 1119c707f2d15667066db70d913af44d941e1c5e
      https://github.com/WebKit/WebKit/commit/1119c707f2d15667066db70d913af44d941e1c5e
  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

  Commit: 31d334ea3a59fcba14b796764a7dc57dfa461775
      https://github.com/WebKit/WebKit/commit/31d334ea3a59fcba14b796764a7dc57dfa461775
  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

  Commit: 90d1e36ae21e73cf68ee55fc7b8f20bbd614a92d
      https://github.com/WebKit/WebKit/commit/90d1e36ae21e73cf68ee55fc7b8f20bbd614a92d
  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

  Commit: 3a3690406bad482c86bc0fa26340c862ccc68aaf
      https://github.com/WebKit/WebKit/commit/3a3690406bad482c86bc0fa26340c862ccc68aaf
  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

  Commit: 781cdefc43c252f7d971582acb89904571c89f98
      https://github.com/WebKit/WebKit/commit/781cdefc43c252f7d971582acb89904571c89f98
  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

  Commit: bd66501be48747b904cd5f17253a072eb29e1a4f
      https://github.com/WebKit/WebKit/commit/bd66501be48747b904cd5f17253a072eb29e1a4f
  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

  Commit: 5cbb600e07bc21afcce98a7769da10eb0446c643
      https://github.com/WebKit/WebKit/commit/5cbb600e07bc21afcce98a7769da10eb0446c643
  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

  Commit: 5fd4a3661b3595370077221b59dfbfcb85129894
      https://github.com/WebKit/WebKit/commit/5fd4a3661b3595370077221b59dfbfcb85129894
  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

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

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.12.1

Identifier: 265423.730 at safari-7616.1.27.12-branch

  Commit: b89253d49b3cd6e5fac8548e203122ac582526a9
      https://github.com/WebKit/WebKit/commit/b89253d49b3cd6e5fac8548e203122ac582526a9
  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

    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: 265423.731 at safari-7616.1.27.12-branch

  Commit: e518f3d1adf803bb1384cf349968c2c711ac9815
      https://github.com/WebKit/WebKit/commit/e518f3d1adf803bb1384cf349968c2c711ac9815
  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: 265423.732 at safari-7616.1.27.12-branch

  Commit: e44faa01639796ab2a4162ab31a5293c25b61147
      https://github.com/WebKit/WebKit/commit/e44faa01639796ab2a4162ab31a5293c25b61147
  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"

This reverts commit d5628c0d1d4fe59b2de1788c5d4f9f4a477000ee.

Identifier: 265423.733 at safari-7616.1.27.12-branch

  Commit: 3fc65eb2fc83bd96b73138fd72a72554cd20344a
      https://github.com/WebKit/WebKit/commit/3fc65eb2fc83bd96b73138fd72a72554cd20344a
  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

    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: 265423.734 at safari-7616.1.27.12-branch

  Commit: c4744a0b2aada6b4f1a95a19f5abc23160c60f5b
      https://github.com/WebKit/WebKit/commit/c4744a0b2aada6b4f1a95a19f5abc23160c60f5b
  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 3a3690406bad482c86bc0fa26340c862ccc68aaf.

Identifier: 265423.735 at safari-7616.1.27.12-branch

  Commit: 0500520ad9e91f51672af8ebedab3c44f9fd8a59
      https://github.com/WebKit/WebKit/commit/0500520ad9e91f51672af8ebedab3c44f9fd8a59
  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: 265423.736 at safari-7616.1.27.12-branch

  Commit: 71b60c14ecdab01b39ca202561ea51b223f3a437
      https://github.com/WebKit/WebKit/commit/71b60c14ecdab01b39ca202561ea51b223f3a437
  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.12-branch

  Commit: ad8ed2ff992809713d2419d97d84b73b8f76a992
      https://github.com/WebKit/WebKit/commit/ad8ed2ff992809713d2419d97d84b73b8f76a992
  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.12-branch

  Commit: 634dedd15e817017b3eb365b8cc99f15be88c7a3
      https://github.com/WebKit/WebKit/commit/634dedd15e817017b3eb365b8cc99f15be88c7a3
  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: 265870.292 at safari-7616.1.27.12-branch

  Commit: 6d1f8f7754c663c59c42eea0191797057034afdc
      https://github.com/WebKit/WebKit/commit/6d1f8f7754c663c59c42eea0191797057034afdc
  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: 59abeaa908ae80f4b5dcc727a4e1399926027533
      https://github.com/WebKit/WebKit/commit/59abeaa908ae80f4b5dcc727a4e1399926027533
  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: e0a2de4aff82ff5a9bc40c38fc60f3c6601b4d9c
      https://github.com/WebKit/WebKit/commit/e0a2de4aff82ff5a9bc40c38fc60f3c6601b4d9c
  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.12.2

Identifier: 265870.295 at safari-7616.1.27.12-branch

  Commit: 9df68116621ca266507bc919d884c5a5a4d7935a
      https://github.com/WebKit/WebKit/commit/9df68116621ca266507bc919d884c5a5a4d7935a
  Author: Kocsen Chung <kocsen_chung at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.12.3

Identifier: 265870.296 at safari-7616.1.27.12-branch

  Commit: f694ce5984bfa4743695a4e285bdd4bee812f71a
      https://github.com/WebKit/WebKit/commit/f694ce5984bfa4743695a4e285bdd4bee812f71a
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/LockdownModeFonts.mm

  Log Message:
  -----------
  Cherry-pick eb66cb954736. rdar://problem/112281112

    [watchOS] Turning on lockdown mode should not cause certain web fonts to be enabled
    https://bugs.webkit.org/show_bug.cgi?id=259791
    rdar://112281112

    Reviewed by Aditya Keerthi.

    To optimize performance and data use, web fonts are currently always disabled on watchOS. However,
    enabling lockdown mode on watchOS actually causes us to *enable* support for a small subset for web
    fonts, since we change `DownloadableBinaryFontAllowedTypes` state from `None` (i.e. no web fonts
    allowed at all) to `Restricted`. This subsequently causes cached fonts in the GPU process to end up
    in an unexpected state on watchOS, triggering a `MESSAGE_CHECK` and causing the web process to
    terminate.

    It doesn't make sense for Lockdown mode to make web fonts *less* restrictive, so we can simply fix
    this by maintaining `DownloadableBinaryFontAllowedTypes::None` in the case where web fonts are
    already unconditionally disabled.

    * Source/WebKit/WebProcess/WebPage/WebPage.cpp:
    (WebKit::adjustSettingsForLockdownMode):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/LockdownModeFonts.mm:

    Rebaseline an API test for compatibility with watchOS as well, where web fonts are always disabled.

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

  Commit: be537d95832ec87a3325c11f8850f71f1a1c4735
      https://github.com/WebKit/WebKit/commit/be537d95832ec87a3325c11f8850f71f1a1c4735
  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.12.4

Identifier: 265870.298 at safari-7616.1.27.12-branch

  Commit: 58863a520c8919bcf403ee6ba4fba7dcd5c18080
      https://github.com/WebKit/WebKit/commit/58863a520c8919bcf403ee6ba4fba7dcd5c18080
  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.299 at safari-7616.1.27.12-branch

  Commit: d4513469c1400a29dc6eb056a1c0cf1a99d32192
      https://github.com/WebKit/WebKit/commit/d4513469c1400a29dc6eb056a1c0cf1a99d32192
  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://problem/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.12-branch

  Commit: e1deb17f80640b781913badba2fce9a761689e9f
      https://github.com/WebKit/WebKit/commit/e1deb17f80640b781913badba2fce9a761689e9f
  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.12.5

Identifier: 265870.301 at safari-7616.1.27.12-branch

Compare: https://github.com/WebKit/WebKit/compare/52d51c5672dd%5E...e1deb17f8064