[webkit-changes] [WebKit/WebKit] 83ac77: Cherry-pick 3d721c09585b. rdar://problem/111534888

Russell Epstein noreply at github.com
Tue Sep 26 13:39:52 PDT 2023


  Branch: refs/heads/safari-7616.1.27.10-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 83ac7712f7b72150e386af52868a152043ab3a07
      https://github.com/WebKit/WebKit/commit/83ac7712f7b72150e386af52868a152043ab3a07
  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: bcf883add6c47772e6d36a9bbd6fba4d955b4be6
      https://github.com/WebKit/WebKit/commit/bcf883add6c47772e6d36a9bbd6fba4d955b4be6
  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: 8c7cad2a3dd796e7041042b3f730d4c03155bba6
      https://github.com/WebKit/WebKit/commit/8c7cad2a3dd796e7041042b3f730d4c03155bba6
  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


  Commit: 7eab4bf12073bbf43644567c00e5b4f5a95da7a2
      https://github.com/WebKit/WebKit/commit/7eab4bf12073bbf43644567c00e5b4f5a95da7a2
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-02 (Wed, 02 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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


  Commit: 19a205366d53ef73cbde2493c437ca7bf96cc0c6
      https://github.com/WebKit/WebKit/commit/19a205366d53ef73cbde2493c437ca7bf96cc0c6
  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.277 at safari-7616.1.27.10-branch


  Commit: 26adcb4a709b6d3bf76308615aa336eef7ac282e
      https://github.com/WebKit/WebKit/commit/26adcb4a709b6d3bf76308615aa336eef7ac282e
  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.278 at safari-7616.1.27.10-branch


  Commit: 73b00a17177fb79f1bbb95f3d9cb13558536fa85
      https://github.com/WebKit/WebKit/commit/73b00a17177fb79f1bbb95f3d9cb13558536fa85
  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.279 at safari-7616.1.27.10-branch


  Commit: 7d8ffa57102b0d10c59a5eced535df5b617c1ae9
      https://github.com/WebKit/WebKit/commit/7d8ffa57102b0d10c59a5eced535df5b617c1ae9
  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.280 at safari-7616.1.27.10-branch


  Commit: 00ae0650b862169faed634b2f691537a6ccb5954
      https://github.com/WebKit/WebKit/commit/00ae0650b862169faed634b2f691537a6ccb5954
  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.281 at safari-7616.1.27.10-branch


  Commit: d3c8565a3467765a21e80136a7828959eacd5569
      https://github.com/WebKit/WebKit/commit/d3c8565a3467765a21e80136a7828959eacd5569
  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.282 at safari-7616.1.27.10-branch


  Commit: 702d81bed263b006bad16d90497e4d106bf0a8e5
      https://github.com/WebKit/WebKit/commit/702d81bed263b006bad16d90497e4d106bf0a8e5
  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.283 at safari-7616.1.27.10-branch


  Commit: d6e9002c0665c37b9569959b3cb0c9b8c0af09fc
      https://github.com/WebKit/WebKit/commit/d6e9002c0665c37b9569959b3cb0c9b8c0af09fc
  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.284 at safari-7616.1.27.10-branch


  Commit: b791843f9dad81c8433ef8c1f4632f6a3aa7e91d
      https://github.com/WebKit/WebKit/commit/b791843f9dad81c8433ef8c1f4632f6a3aa7e91d
  Author: Russell Epstein <repstein 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: 265870.285 at safari-7616.1.27.10-branch


  Commit: c9a82da8a8fddea9d91329e0a1568d9defb2595c
      https://github.com/WebKit/WebKit/commit/c9a82da8a8fddea9d91329e0a1568d9defb2595c
  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: 265870.286 at safari-7616.1.27.10-branch


  Commit: b04f5b6ac7628655129a456b05ed5bb832019f4e
      https://github.com/WebKit/WebKit/commit/b04f5b6ac7628655129a456b05ed5bb832019f4e
  Author: Russell Epstein <repstein 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:
  -----------
  Revert "Cherry-pick 3d721c09585b. rdar://problem/111534888"

This reverts commit 83ac7712f7b72150e386af52868a152043ab3a07.

Identifier: 265870.287 at safari-7616.1.27.10-branch


  Commit: d8a77a94748597f7ba09a7cc45e46e1a08e6342f
      https://github.com/WebKit/WebKit/commit/d8a77a94748597f7ba09a7cc45e46e1a08e6342f
  Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
  Date:   2023-08-03 (Thu, 03 Aug 2023)

  Changed paths:
    M Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp
    M Source/WebCore/Modules/applepay/ApplePaySetup.cpp
    M Source/WebCore/Modules/applepay/PaymentCoordinator.cpp
    M Source/WebCore/page/Page.cpp
    M Source/WebCore/page/Page.h

  Log Message:
  -----------
  Cherry-pick bb9c7e0fd205. rdar://problem/113143083

    Ensure -[PKPaymentRequest originatingURL] is always set to the top-level document URL
    https://bugs.webkit.org/show_bug.cgi?id=259667
    rdar://113143083

    Reviewed by Andy Estes.

    We support Apple Pay on cross-origin iframes following 262616 at main, but
    since we are plumbing the iframe domain rather than that of the parent
    document embedding said iframe, we lose some Apple Pay domain validation
    and abuse detection mitigations.

    In this patch, we preserve our existing security mitigations by passing
    the top-level domain to `-[PKPaymentRequest setOriginatingURL:]`.
    This change also aligns ourselves to the existing shipping model for
    payment session domain reporting in iOS 16.

    Note that this patch necessitates that a website provide the top level
    domain in its merchant session, i.e. "you can iFrame in Apple Pay, but
    your merchant session must use the top-level domain". This is a
    pre-existing invariant in PassKit, and this commit aligns WebKit in the
    same direction.

    * Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp:
    (WebCore::ApplePayAMSUIPaymentHandler::show):
    * Source/WebCore/Modules/applepay/ApplePaySetup.cpp:
    (WebCore::ApplePaySetup::begin):
    * Source/WebCore/Modules/applepay/PaymentCoordinator.cpp:
    (WebCore::PaymentCoordinator::beginPaymentSession):
    * Source/WebCore/page/Page.cpp:
    (WebCore::Page::startApplePayAMSUISession):
    * Source/WebCore/page/Page.h:

    Canonical link: https://commits.webkit.org/265870.231@safari-7616-branch

Identifier: 265870.288 at safari-7616.1.27.10-branch


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


  Commit: d9a11999a3bb9c4f3b4dc7c2def2781466b69f2e
      https://github.com/WebKit/WebKit/commit/d9a11999a3bb9c4f3b4dc7c2def2781466b69f2e
  Author: Jer Noble <jer.noble at apple.com>
  Date:   2023-08-03 (Thu, 03 Aug 2023)

  Changed paths:
    M Source/WebKit/UIProcess/WebFullScreenManagerProxy.cpp
    M Source/WebKit/UIProcess/WebFullScreenManagerProxy.h
    M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
    M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp
    M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp

  Log Message:
  -----------
  Cherry-pick 20b21450ef4d. rdar://problem/113308053

    [Cocoa] Add logging for Element Fullscreen path inside WebKit
    https://bugs.webkit.org/show_bug.cgi?id=259761
    rdar://113308053

    Reviewed by Simon Fraser.

    Add LoggerHelper-style logging to WebFullScreenManager, WebFullScreenManagerProxy,
    and WKFullScreenWindowController (iOS).

    Drive-by Fix: Ensure the WebPage parameter to the WebFullScreenManagerProxy::create()
    method is non-null by making it a reference (&) rather than pointer (*).

    * Source/WebKit/UIProcess/WebFullScreenManagerProxy.cpp:
    (WebKit::WebFullScreenManagerProxy::WebFullScreenManagerProxy):
    (WebKit::WebFullScreenManagerProxy::willEnterFullScreen):
    (WebKit::WebFullScreenManagerProxy::didEnterFullScreen):
    (WebKit::WebFullScreenManagerProxy::willExitFullScreen):
    (WebKit::WebFullScreenManagerProxy::didExitFullScreen):
    (WebKit::WebFullScreenManagerProxy::requestRestoreFullScreen):
    (WebKit::WebFullScreenManagerProxy::requestExitFullScreen):
    (WebKit::WebFullScreenManagerProxy::logChannel const):
    * Source/WebKit/UIProcess/WebFullScreenManagerProxy.h:
    (WebKit::WebFullScreenManagerProxy::logger const):
    (WebKit::WebFullScreenManagerProxy::logIdentifier const):
    (WebKit::WebFullScreenManagerProxy::logClassName const):
    * Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
    (WTF::LogArgument<WebKit::FullScreenState>::toString):
    (-[WKFullScreenWindowController initWithWebView:]):
    (-[WKFullScreenWindowController enterFullScreen:]):
    (-[WKFullScreenWindowController beganEnterFullScreenWithInitialFrame:finalFrame:]):
    (-[WKFullScreenWindowController requestRestoreFullScreen]):
    (-[WKFullScreenWindowController requestExitFullScreen]):
    (-[WKFullScreenWindowController exitFullScreen]):
    (-[WKFullScreenWindowController beganExitFullScreenWithInitialFrame:finalFrame:]):
    (-[WKFullScreenWindowController _completedExitFullScreen]):
    (-[WKFullScreenWindowController close]):
    (-[WKFullScreenWindowController webViewDidRemoveFromSuperviewWhileInFullscreen]):
    (-[WKFullScreenWindowController didEnterPictureInPicture]):
    (-[WKFullScreenWindowController didExitPictureInPicture]):
    (-[WKFullScreenWindowController _exitFullscreenImmediately]):
    (-[WKFullScreenWindowController _startToDismissFullscreenChanged:]):
    (-[WKFullScreenWindowController _dismissFullscreenViewController]):
    (-[WKFullScreenWindowController _interactiveDismissChanged:]):
    (-[WKFullScreenWindowController _interactivePinchDismissChanged:]):
    (-[WKFullScreenWindowController _configureSpatialFullScreenTransition]):
    (-[WKFullScreenWindowController _performSpatialFullScreenTransition:completionHandler:]):
    (-[WKFullScreenWindowController logIdentifier]):
    (-[WKFullScreenWindowController loggerPtr]):
    (-[WKFullScreenWindowController logChannel]):
    * Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp:
    (WebKit::WebFullScreenManager::create):
    (WebKit::WebFullScreenManager::WebFullScreenManager):
    (WebKit::WebFullScreenManager::invalidate):
    (WebKit::WebFullScreenManager::videoControlsManagerDidChange):
    (WebKit::WebFullScreenManager::setPIPStandbyElement):
    (WebKit::WebFullScreenManager::supportsFullScreen):
    (WebKit::WebFullScreenManager::enterFullScreenForElement):
    (WebKit::WebFullScreenManager::exitFullScreenForElement):
    (WebKit::WebFullScreenManager::willEnterFullScreen):
    (WebKit::WebFullScreenManager::didEnterFullScreen):
    (WebKit::WebFullScreenManager::willExitFullScreen):
    (WebKit::WebFullScreenManager::didExitFullScreen):
    (WebKit::WebFullScreenManager::requestRestoreFullScreen):
    (WebKit::WebFullScreenManager::requestExitFullScreen):
    (WebKit::WebFullScreenManager::close):
    (WebKit::WebFullScreenManager::logChannel const):
    * Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h:
    * Source/WebKit/WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::fullScreenManager):

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

Identifier: 265870.290 at safari-7616.1.27.10-branch


  Commit: 248f893713f3805bb61e95b161eb40d7f0e76c0c
      https://github.com/WebKit/WebKit/commit/248f893713f3805bb61e95b161eb40d7f0e76c0c
  Author: Dean Jackson <dino at apple.com>
  Date:   2023-08-03 (Thu, 03 Aug 2023)

  Changed paths:
    M Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/SystemPreview.mm

  Log Message:
  -----------
  Cherry-pick 416f2342d7bf. rdar://problem/110978209

    AR issues. Right after opening the USDZ and GLB file in the browser, it closes itself
    https://bugs.webkit.org/show_bug.cgi?id=259670
    rdar://110978209

    Reviewed by Tim Horton.

    We tightened the list of MIME types we accepted in ARQL during
    the past year. Unfortunately still many servers are not configured
    to send USD with the correct type, so we need to relax the list
    a bit. For now, we'll add "application/octet-stream".

    Added a new API test for this case.

    * Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/SystemPreview.mm:
    (TestWebKitAPI::TEST):

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

Identifier: 265870.291 at safari-7616.1.27.10-branch


  Commit: 14a42d83e12ed903a7a39a081b3915bb38d28532
      https://github.com/WebKit/WebKit/commit/14a42d83e12ed903a7a39a081b3915bb38d28532
  Author: Tyler Wilcock <tyler_w at apple.com>
  Date:   2023-08-03 (Thu, 03 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: 265870.292 at safari-7616.1.27.10-branch


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


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


  Commit: ccb976224ab6a4a9157be4f02ae5ddbee8915504
      https://github.com/WebKit/WebKit/commit/ccb976224ab6a4a9157be4f02ae5ddbee8915504
  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.295 at safari-7616.1.27.10-branch


  Commit: 6e40b4c5f4422b55ac3d24005bc54472f21ad127
      https://github.com/WebKit/WebKit/commit/6e40b4c5f4422b55ac3d24005bc54472f21ad127
  Author: Richard Robinson <richard_robinson2 at apple.com>
  Date:   2023-08-04 (Fri, 04 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.296 at safari-7616.1.27.10-branch


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

Identifier: 265870.297 at safari-7616.1.27.10-branch


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

Identifier: 265870.298 at safari-7616.1.27.10-branch


  Commit: 5b0eda999aebda26e967175b4bfe536211fca9c9
      https://github.com/WebKit/WebKit/commit/5b0eda999aebda26e967175b4bfe536211fca9c9
  Author: Eric Carlson <eric.carlson at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp

  Log Message:
  -----------
  Cherry-pick a41543cba4bf. rdar://problem/113271473

    InputDevice capabilities are not required until capture is active
    https://bugs.webkit.org/show_bug.cgi?id=259814
    rdar://113271473

    Reviewed by Jer Noble.

    InputDevice capabilities are not exposed until after the user has given consent to
    capture, so don't bother asking for them unless they will be revealed as activating the
    AVAudioSession may change the characteristics of the audio rendering in other processes.

    * Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
    (WebKit::UserMediaPermissionRequestManagerProxy::platformGetMediaStreamDevices):

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

Identifier: 265870.299 at safari-7616.1.27.10-branch


  Commit: 4f6d46c4a61997c1776f123438af177eefca9b14
      https://github.com/WebKit/WebKit/commit/4f6d46c4a61997c1776f123438af177eefca9b14
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Source/WebCore/loader/PingLoader.cpp
    M Source/WebCore/loader/cache/CachedResourceLoader.cpp
    M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
    M Source/WebKit/NetworkProcess/NetworkProcess.cpp
    M Source/WebKit/NetworkProcess/NetworkProcess.h
    M Source/WebKit/Shared/AuxiliaryProcess.cpp
    M Source/WebKit/Shared/AuxiliaryProcess.h
    M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
    M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
    M Source/WebKit/WebProcess/Plugins/PluginView.cpp
    M Source/WebKit/WebProcess/WebProcess.cpp

  Log Message:
  -----------
  Revert "Cherry-pick 266074 at main (cb29a8742b53). rdar://112497411"

This reverts commit 53706abee76cd06bc7e54bb1b4d4156d75cd994a.

Identifier: 265870.300 at safari-7616.1.27.10-branch


  Commit: 480c83c2602e7bdc49bf4efacbe4c2b711541fb4
      https://github.com/WebKit/WebKit/commit/480c83c2602e7bdc49bf4efacbe4c2b711541fb4
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.2

Identifier: 265870.301 at safari-7616.1.27.10-branch


  Commit: 028e6efda9825b258ea2ef7d4abfb65484fb9362
      https://github.com/WebKit/WebKit/commit/028e6efda9825b258ea2ef7d4abfb65484fb9362
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.3

Identifier: 265870.302 at safari-7616.1.27.10-branch


  Commit: 54ed588a4ca838c2ede8ac8b9b74c50698dfb2f0
      https://github.com/WebKit/WebKit/commit/54ed588a4ca838c2ede8ac8b9b74c50698dfb2f0
  Author: Dean Jackson <dino at apple.com>
  Date:   2023-08-04 (Fri, 04 Aug 2023)

  Changed paths:
    M Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h
    M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm

  Log Message:
  -----------
  Cherry-pick ab6f0338a00f. rdar://problem/111986083

    REGRESSION (265825 at main): Safari CPU usage in SurferJoannaProxy increased by 5.8%
    https://bugs.webkit.org/show_bug.cgi?id=259805
    rdar://111986083

    Reviewed by Matt Woodrow.

    The fix in 265825 at main caused a slight performance regression. We can
    now back out most of it, thanks to a change in CoreAnimation.

    The thing we don't restore is the CATransaction.

    * Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h:
    * Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
    (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):

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

Identifier: 265870.303 at safari-7616.1.27.10-branch


  Commit: 0a1a05f08154e8478e8cc087ee073664c9074722
      https://github.com/WebKit/WebKit/commit/0a1a05f08154e8478e8cc087ee073664c9074722
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.4

Identifier: 265870.304 at safari-7616.1.27.10-branch


  Commit: a76acff8e983048b416d3480cb27e1b451ee98d5
      https://github.com/WebKit/WebKit/commit/a76acff8e983048b416d3480cb27e1b451ee98d5
  Author: Jer Noble <jer.noble at apple.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.h
    M Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.mm
    M Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm

  Log Message:
  -----------
  Cherry-pick de279587fd2e. rdar://problem/112625311

    [Cocoa] memorialpress.com: Video not playing in iOS 17
    https://bugs.webkit.org/show_bug.cgi?id=259838
    rdar://112625311

    Reviewed by Simon Fraser.

    There was a misspelling of a new AVFoundation option to be passed into -isPlayableExtendedMIMEType:options:
    which prevents queries of `application/x-mpegURL; codecs="avc1.42E01E"` from succeding.

    * Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.h:
    * Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.mm:
    * Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:
    (WebCore::AVAssetMIMETypeCache::canDecodeExtendedType):

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

Identifier: 265870.305 at safari-7616.1.27.10-branch


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

  Changed paths:
    M Source/WebKit/UIProcess/ProcessThrottler.cpp

  Log Message:
  -----------
  Cherry-pick fe792fdab477. rdar://problem/113459152

    Crash under ProcessThrottlerActivity::isValid()
    https://bugs.webkit.org/show_bug.cgi?id=259886
    rdar://113459152

    Reviewed by Brent Fulgham.

    ProcessThrottlerTimedActivity::activityTimedOut() was getting called, it
    would set `m_activity` to nullptr, which would destroy the
    ProcessThrottlerActivity. Because this was the last activity, it would
    cause the prepareToSuspend logic to get called, which could cause
    `m_activity` to get queried while in the middle of the assignment, causing
    a crash.

    To address the issue, I now use std::variant::swap() in activityTimedOut()
    so that m_activity is in a good state (nullptr) when the
    ProcessThrottlerActivity gets destroyed.

    * Source/WebKit/UIProcess/ProcessThrottler.cpp:
    (WebKit::ProcessThrottlerTimedActivity::activityTimedOut):

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

Identifier: 265870.306 at safari-7616.1.27.10-branch


  Commit: 6707a4323f9f7e55f68b27184eae7e2922d2ab80
      https://github.com/WebKit/WebKit/commit/6707a4323f9f7e55f68b27184eae7e2922d2ab80
  Author: Nikolaos Mouchtaris <nmouchtaris at apple.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta-and-position-expected.html
    A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta-and-position.html
    A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta-expected.html
    A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta.html
    A LayoutTests/fast/scrolling/programmatic-scroll-merge-position-and-delta-expected.html
    A LayoutTests/fast/scrolling/programmatic-scroll-merge-position-and-delta.html
    M Source/WebCore/page/scrolling/ScrollingCoordinatorTypes.cpp

  Log Message:
  -----------
  Cherry-pick 2f97007c9a1e. rdar://problem/113366817

    [UI-side compositing] Webpage going blank when navigating diffs in https://whatpr.org/html/9537/238086f...f400a41/canvas.html#drawing-state
    https://bugs.webkit.org/show_bug.cgi?id=259813
    rdar://113366817

    Reviewed by Simon Fraser and Cameron McCormack.

    When getting multiple non-animated scroll requests, the current merging code loses the previous
    scroll request if a new delta update comes in. To resolve this, add the two scroll requests together
    if either or both are a delta update. Added a couple new tests for this since the tests in
    imported/w3c/web-platform-tests/css/cssom-view/scroll-behavior-* do not cover this since they
    are testing the web process position.

    * Source/WebCore/page/scrolling/ScrollingCoordinatorTypes.cpp:
    (WebCore::RequestedScrollData::merge):

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

Identifier: 265870.307 at safari-7616.1.27.10-branch


  Commit: 153a885ad87d4498cb7196141ee38b34255fa2c5
      https://github.com/WebKit/WebKit/commit/153a885ad87d4498cb7196141ee38b34255fa2c5
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-08 (Tue, 08 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.5

Identifier: 265870.308 at safari-7616.1.27.10-branch


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

  Changed paths:
    M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.cpp
    M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h
    M Source/WebCore/page/Quirks.cpp
    M Source/WebCore/page/Quirks.h
    M Source/WebCore/platform/RuntimeApplicationChecks.h
    M Source/WebCore/platform/cocoa/RuntimeApplicationChecksCocoa.mm
    M Source/WebCore/style/Styleable.cpp

  Log Message:
  -----------
  Cherry-pick 4f35a025c0ba. rdar://problem/112679186

    REGRESSION (260398 at main): DOFUS Touch app: Color palette canvas element is blank during character creation
    https://bugs.webkit.org/show_bug.cgi?id=259849
    rdar://112679186

    Reviewed by Wenson Hsieh.

    With 260398 at main, fewer transitionend events may be emitted for cancelling transitions. Add a Quirk for DOFUS Touch.

    * Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.cpp:
    (WTF::computeSDKAlignedBehaviors):
    * Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h:
    * Source/WebCore/page/Quirks.cpp:
    (WebCore::Quirks::needsResettingTransitionCancelsRunningTransitionQuirk const):
    * Source/WebCore/page/Quirks.h:
    * Source/WebCore/platform/RuntimeApplicationChecks.h:
    * Source/WebCore/platform/cocoa/RuntimeApplicationChecksCocoa.mm:
    (WebCore::IOSApplication::isDOFUSTouch):
    * Source/WebCore/style/Styleable.cpp:
    (WebCore::updateCSSTransitionsForStyleableAndProperty):

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

Identifier: 265870.309 at safari-7616.1.27.10-branch


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

  Changed paths:
    M Source/WebKit/Shared/EditorState.cpp

  Log Message:
  -----------
  Cherry-pick bfc6efd0dc4e. rdar://problem/113287677

    REGRESSION: WebKit provides rectilinear selection rects for rotated text in images
    https://bugs.webkit.org/show_bug.cgi?id=259888
    rdar://113287677

    Reviewed by Wenson Hsieh.

    `EditorState::clipOwnedRectExtentsToNumericLimits` was erroneously converting some selection
    geometries from quads to rects.

    Fix by removing these conversions. Since `FloatQuad`s have no notion of validity, there is no
    need to clip them to numeric limits.

    * Source/WebKit/Shared/EditorState.cpp:
    (WebKit::EditorState::clipOwnedRectExtentsToNumericLimits):

    Canonical link: https://commits.webkit.org/265870.235@safari-7616-branch

Identifier: 265870.310 at safari-7616.1.27.10-branch


  Commit: 68eec7e48f116d70681f0aef8c394164300abae0
      https://github.com/WebKit/WebKit/commit/68eec7e48f116d70681f0aef8c394164300abae0
  Author: Cameron McCormack <heycam at apple.com>
  Date:   2023-08-08 (Tue, 08 Aug 2023)

  Changed paths:
    M LayoutTests/platform/glib/TestExpectations
    M Source/WebCore/platform/graphics/Path.cpp
    M Source/WebCore/platform/graphics/PathImpl.h
    M Source/WebCore/platform/graphics/PathSegment.cpp
    M Source/WebCore/platform/graphics/PathSegment.h
    M Source/WebCore/platform/graphics/PathSegmentData.cpp
    M Source/WebCore/platform/graphics/PathSegmentData.h
    M Source/WebCore/platform/graphics/PathStream.cpp
    M Source/WebCore/platform/graphics/PathStream.h
    M Source/WebCore/platform/graphics/cairo/PathCairo.cpp
    M Source/WebCore/platform/graphics/cairo/PathCairo.h
    M Source/WebCore/platform/graphics/cg/PathCG.cpp
    M Source/WebCore/platform/graphics/cg/PathCG.h

  Log Message:
  -----------
  Cherry-pick bc527208a62f. rdar://problem/111934640

    Path::transform() should not trigger creation of a platform path
    https://bugs.webkit.org/show_bug.cgi?id=258759
    rdar://problem/111934640

    Reviewed by Simon Fraser.

    Many paths consist only of Move/Line/Quadratic/Cubic/Close segments, which are
    all simple to apply an AffineTransform to. Transform single segment and PathStream
    based paths in place when Path::transform() is called, to avoid the overhead of
    generating a CGPath. If other segment types are in the path, continue to convert
    to a platform path first.

    Some WPT (path + transform) tests fail on GTK ports because the tests are fragile
    to floating point calculations. The tests rotate the context by 90 degree and scale
    it by 283 then they stroke a line to cover the whole canvas by the stroke color.
    If we scale by 282, the last row in the canvas will not be stroked even without
    this patch. On GKT port and with this patch, the last row is stroked but it is
    anti-aliased with the background.

    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/platform/graphics/Path.cpp:
    (WebCore::Path::transform):
    * Source/WebCore/platform/graphics/PathImpl.h:
    * Source/WebCore/platform/graphics/PathSegment.cpp:
    (WebCore::PathSegment::canTransform const):
    (WebCore::PathSegment::transform):
    * Source/WebCore/platform/graphics/PathSegment.h:
    * Source/WebCore/platform/graphics/PathSegmentData.cpp:
    (WebCore::PathMoveTo::transform):
    (WebCore::PathLineTo::transform):
    (WebCore::PathQuadCurveTo::transform):
    (WebCore::PathBezierCurveTo::transform):
    (WebCore::PathDataLine::transform):
    (WebCore::PathDataQuadCurve::transform):
    (WebCore::PathDataBezierCurve::transform):
    (WebCore::PathCloseSubpath::transform):
    * Source/WebCore/platform/graphics/PathSegmentData.h:
    * Source/WebCore/platform/graphics/PathStream.cpp:
    (WebCore::PathStream::transform):
    * Source/WebCore/platform/graphics/PathStream.h:
    * Source/WebCore/platform/graphics/cairo/PathCairo.cpp:
    (WebCore::PathCairo::transform):
    * Source/WebCore/platform/graphics/cairo/PathCairo.h:
    * Source/WebCore/platform/graphics/cg/PathCG.cpp:
    (WebCore::PathCG::transform):
    * Source/WebCore/platform/graphics/cg/PathCG.h:

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

Identifier: 265870.311 at safari-7616.1.27.10-branch


  Commit: 1d2056ae612ba2c49811861708037999d2f197cd
      https://github.com/WebKit/WebKit/commit/1d2056ae612ba2c49811861708037999d2f197cd
  Author: Youenn Fablet <youennf at gmail.com>
  Date:   2023-08-08 (Tue, 08 Aug 2023)

  Changed paths:
    M Source/ThirdParty/libwebrtc/Source/webrtc/api/video_codecs/h264_profile_level_id.cc

  Log Message:
  -----------
  Cherry-pick 9b88dbfe47d7. rdar://problem/113008968

    [RTCVideoEncoderH264 initWithCodecInfo] should cope with invalid profile level id
    https://bugs.webkit.org/show_bug.cgi?id=259592
    rdar://113008968

    Reviewed by Eric Carlson.

    With WebCodecs, we allow JS to pass any profile level id to RTCVideoEncoderH264.
    For now, we are defaulting to a default profile level id if none is matching.
    A future patch should probably make sure that we return an error so that JS knows the configuration is not unsupported.

    * Source/ThirdParty/libwebrtc/Source/webrtc/api/video_codecs/h264_profile_level_id.cc:

    Canonical link: https://commits.webkit.org/266392@main
Identifier: 265423.759 at safari-7616.1.27.10-branch


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

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

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

    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: 265423.760 at safari-7616.1.27.10-branch


  Commit: 9e06dee5974b950de6c5e1623f0904b48f0ad92b
      https://github.com/WebKit/WebKit/commit/9e06dee5974b950de6c5e1623f0904b48f0ad92b
  Author: Eric Carlson <eric.carlson at apple.com>
  Date:   2023-08-08 (Tue, 08 Aug 2023)

  Changed paths:
    M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm

  Log Message:
  -----------
  Cherry-pick 52ced8d1a83a. rdar://problem/113510677

    [macOS] Suppress the SCStream privacy alert
    https://bugs.webkit.org/show_bug.cgi?id=259889
    rdar://113510677

    Reviewed by Andy Estes.

    WebKit only allows one tab to capture at a time, so the SCStream privacy alert is confusing
    and unnecessary.

    * Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm:
    (WebCore::ScreenCaptureKitCaptureSource::streamConfiguration): Set
    `configuration.presenterOverlayPrivacyAlertSetting` to `SCPresenterOverlayAlertSettingNever`

    Canonical link: https://commits.webkit.org/266661@main
Identifier: 265423.761 at safari-7616.1.27.10-branch


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

  Changed paths:
    M LayoutTests/fast/history/visited-link-caret-color-expected.html
    M LayoutTests/fast/history/visited-link-caret-color.html
    M Source/WebCore/editing/FrameSelection.cpp

  Log Message:
  -----------
  Cherry-pick eb3e8157099d. rdar://problem/111077813

    REGRESSION: fast/history/visited-link-caret-color.html is a consistent image failure
    https://bugs.webkit.org/show_bug.cgi?id=259469
    rdar://111077813

    Reviewed by Megan Gardner and Aditya Keerthi.

    When the caret doesn't need to use the system accent color, it should just get the color the normal
    way, which already both accounts for the visited-ness and any color filter.

    * LayoutTests/fast/history/visited-link-caret-color-expected.html:
    * LayoutTests/fast/history/visited-link-caret-color.html:
    * Source/WebCore/editing/FrameSelection.cpp:
    (WebCore::CaretBase::computeCaretColor):

    Canonical link: https://commits.webkit.org/266295@main
Identifier: 265423.762 at safari-7616.1.27.10-branch


  Commit: a8a61abc176ad7135d94dbeb3c8437416160a5a4
      https://github.com/WebKit/WebKit/commit/a8a61abc176ad7135d94dbeb3c8437416160a5a4
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-08 (Tue, 08 Aug 2023)

  Changed paths:
    M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm

  Log Message:
  -----------
  Revert "Cherry-pick 52ced8d1a83a. rdar://problem/113510677"

This reverts commit 9e06dee5974b950de6c5e1623f0904b48f0ad92b.

Canonical link: https://commits.webkit.org/265870.316@safari-7616.1.27.10-branch


  Commit: b6c2627143e84d2574c2ebc4846b6b5351950597
      https://github.com/WebKit/WebKit/commit/b6c2627143e84d2574c2ebc4846b6b5351950597
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-08-09 (Wed, 09 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.6

Identifier: 265870.317 at safari-7616.1.27.10-branch


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

  Changed paths:
    M Source/WebCore/loader/mac/LoaderNSURLExtras.mm
    M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
    R Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLCanonicalization.mm
    A Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLExtras.mm

  Log Message:
  -----------
  Cherry-pick d94ee98c7619. rdar://problem/113638429

    Safari crashes when showing the downloads menu for a download with no MIME type
    https://bugs.webkit.org/show_bug.cgi?id=259622
    rdar://113058721

    Reviewed by Wenson Hsieh.

    * Source/WebCore/loader/mac/LoaderNSURLExtras.mm:
    Add a null check.

    * Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLExtras.mm: Renamed from Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLCanonicalization.mm.
    (TestWebKitAPI::TEST):
    * Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    Rename URLCanonicalization to URLExtras and add a (very simple) positive and
    negative test for _webkit_suggestedFilenameWithMIMEType, which was what
    was triggering this crash.

    Canonical link: https://commits.webkit.org/266414@main
Identifier: 265423.765 at safari-7616.1.27.10-branch


  Commit: 995de116221977667adc71f2e7127e371196d574
      https://github.com/WebKit/WebKit/commit/995de116221977667adc71f2e7127e371196d574
  Author: Per Arne Vollan <pvollan at apple.com>
  Date:   2023-08-09 (Wed, 09 Aug 2023)

  Changed paths:
    M Source/WTF/wtf/PlatformEnableCocoa.h
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Cherry-pick 3ef8682eac94. rdar://problem/113557767

    Low end devices should not prewarm Web process on provisional load
    https://bugs.webkit.org/show_bug.cgi?id=259927
    rdar://113557767

    Reviewed by Chris Dumez.

    After 266255 at main, a Web process is prewarmed on provisional load instead of when the main frame load has finished.
    This is a page load time progression on most iOS devices, except for the low end ones. For these devices, we should
    still be prewarming when the main frame load has finished. The change in 266255 at main is also performance neutral on
    macOS, so we can also keep the original behavior there.

    * Source/WTF/wtf/PlatformEnableCocoa.h:
    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::shouldPrewarmWebProcessOnProvisionalLoad):
    (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared):
    (WebKit::WebPageProxy::didFinishLoadForFrame):

    Canonical link: https://commits.webkit.org/266717@main
Identifier: 265423.766 at safari-7616.1.27.10-branch


  Commit: faffcf23971192f1334251a1eafddb8c95d492b0
      https://github.com/WebKit/WebKit/commit/faffcf23971192f1334251a1eafddb8c95d492b0
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2023-08-09 (Wed, 09 Aug 2023)

  Changed paths:
    A LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution-expected.txt
    A LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution.html
    A LayoutTests/compositing/layer-creation/overlap-transform-filter-expected.txt
    A LayoutTests/compositing/layer-creation/overlap-transform-filter.html
    A LayoutTests/platform/ios-wk2/compositing/layer-creation/overlap-transform-filter-contribution-expected.txt
    M Source/WebCore/rendering/RenderLayer.cpp
    M Source/WebCore/rendering/RenderLayerBacking.cpp

  Log Message:
  -----------
  Cherry-pick 2e1ca5ac8e80. rdar://problem/113420795

    Compositing overlap testing is broken with filters in some configurations
    https://bugs.webkit.org/show_bug.cgi?id=259848
    rdar://113420795

    Reviewed by Alan Baradlay.

    `RenderLayer::overlapBounds()` needs to return a rectangle which doesn't include the layer's own transform,
    since the caller applies the transform. However, if the layer has a filter that moves pixels (causing
    `overlapBoundsIncludeChildren()` to return true), then it used `defaultCalculateLayerBoundsFlags()`
    which includes `IncludeSelfTransform`.

    So pass a set of flags that cause the transform to be ignored.

    The tests exercise a filtered layer overlapping another layer, and other layers overlapping a filtered
    layer.

    This is part of a set of issues that affect reddit.com (rdar://112807737).

    * LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution-expected.txt: Added.
    * LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution.html: Added.
    * LayoutTests/compositing/layer-creation/overlap-transform-filter-expected.txt: Added.
    * LayoutTests/compositing/layer-creation/overlap-transform-filter.html: Added.
    * Source/WebCore/rendering/RenderLayer.cpp:
    (WebCore::RenderLayer::calculateClipRects const):
    * Source/WebCore/rendering/RenderLayerBacking.cpp:
    (WebCore::operator<<):

    Canonical link: https://commits.webkit.org/266669@main
Identifier: 265423.767 at safari-7616.1.27.10-branch


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

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.7

Canonical link: https://commits.webkit.org/265870.321@safari-7616.1.27.10-branch


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

  Changed paths:
    M LayoutTests/resources/ui-helper.js
    M Source/WebKit/UIProcess/ios/WKTextSelectionRect.mm
    M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
    M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
    M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
    M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm

  Log Message:
  -----------
  Cherry-pick 69d07a6b99c8. rdar://problem/111793617

    When selecting Live Text in Safari on iOS, the selection handles move away from the selection when zooming
    https://bugs.webkit.org/show_bug.cgi?id=259964
    rdar://111793617

    Reviewed by Wenson Hsieh.

    UIKit now scales the selection handles when zooming and updates their position accordingly.
    Since WebKit is also scaling them ourselves, this results in a position that's offset from the
    selection proportional to the zoom amount.

    Fix by no longer scaling the selection handles in WebKit.

    * LayoutTests/resources/ui-helper.js:
    (window.UIHelper.getSelectionEndGrabberViewShapePathDescription.return.new.Promise.):
    (window.UIHelper.getSelectionEndGrabberViewShapePathDescription.return.new.Promise):
    (window.UIHelper.getSelectionEndGrabberViewShapePathDescription):
    * Source/WebKit/UIProcess/ios/WKTextSelectionRect.mm:
    (-[WKTextSelectionRect _customHandleInfo]):
    * Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
    * Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
    (WTR::UIScriptController::selectionEndGrabberViewShapePathDescription const):
    * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
    * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
    (WTR::UIScriptControllerIOS::selectionEndGrabberViewShapePathDescription const):

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

Canonical link: https://commits.webkit.org/265870.322@safari-7616.1.27.10-branch


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

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.8

Identifier: 265423.770 at safari-7616.1.27.10-branch


  Commit: a5b1224ff28c2e1690c104d1f87ad503d8d4abf4
      https://github.com/WebKit/WebKit/commit/a5b1224ff28c2e1690c104d1f87ad503d8d4abf4
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-08-14 (Mon, 14 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.9

Identifier: 265870.324 at safari-7616.1.27.10-branch


  Commit: 38c5927aae7f199f9ffd2f7ca74dc3d349b9dc02
      https://github.com/WebKit/WebKit/commit/38c5927aae7f199f9ffd2f7ca74dc3d349b9dc02
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-08-14 (Mon, 14 Aug 2023)

  Changed paths:
    M Source/WebCore/platform/cocoa/MIMETypeRegistryCocoa.mm
    M Tools/TestWebKitAPI/Tests/WebCore/MIMETypeRegistry.cpp

  Log Message:
  -----------
  Cherry-pick 97c1b7fd0b15. rdar://problem/113774128

    Regression(266049 at main) Crash in MIMETypeRegistry::preferredExtensionForMIMEType
    https://bugs.webkit.org/show_bug.cgi?id=260098
    rdar://113774128

    Reviewed by Aditya Keerthi.

    Make sure we early return if `type` is a null string to avoid doing a HashMap
    lookup with it later on, which would cause crashes.

    * Source/WebCore/platform/cocoa/MIMETypeRegistryCocoa.mm:
    (WebCore::MIMETypeRegistry::preferredExtensionForMIMEType):
    * Tools/TestWebKitAPI/Tests/WebCore/MIMETypeRegistry.cpp:
    (TestWebKitAPI::TEST):

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

Identifier: 265870.325 at safari-7616.1.27.10-branch


  Commit: e4ed176d0da6d8ab90a2eb7cf0b85ddd2351729d
      https://github.com/WebKit/WebKit/commit/e4ed176d0da6d8ab90a2eb7cf0b85ddd2351729d
  Author: Sihui Liu <sihui_liu at apple.com>
  Date:   2023-08-15 (Tue, 15 Aug 2023)

  Changed paths:
    M Source/WebCore/workers/service/server/SWRegistrationDatabase.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm

  Log Message:
  -----------
  Cherry-pick 8e9f2eb04c2e. rdar://problem/112092827

    ServiceWorkerRegistration data is not deleted correctly
    https://bugs.webkit.org/show_bug.cgi?id=260163
    rdar://112092827

    Reviewed by Brent Fulgham.

    bindText() returns error code and 0 (SQLITE_OK) means the operation succeeds, so updateRegistrations should not return
    early.

    API Test: WKWebsiteDataStore.RemoveServiceWorkerDataByOrigin

    * Source/WebCore/workers/service/server/SWRegistrationDatabase.cpp:
    (WebCore::SWRegistrationDatabase::updateRegistrations):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm:

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


  Commit: e32a49b2a7aa0f497e7fdcf88e88ad7cc8fff702
      https://github.com/WebKit/WebKit/commit/e32a49b2a7aa0f497e7fdcf88e88ad7cc8fff702
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-08-15 (Tue, 15 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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


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

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.11

Identifier: 265870.328 at safari-7616.1.27.10-branch


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

Identifier: 265870.329 at safari-7616.1.27.10-branch


  Commit: 800232e3691f5fb1a3b7d134945b4d7231b2a44c
      https://github.com/WebKit/WebKit/commit/800232e3691f5fb1a3b7d134945b4d7231b2a44c
  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.330 at safari-7616.1.27.10-branch


  Commit: ebecfd8330eb8a467e4a0e037d4d5cc7a3a9a8ef
      https://github.com/WebKit/WebKit/commit/ebecfd8330eb8a467e4a0e037d4d5cc7a3a9a8ef
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-08-22 (Tue, 22 Aug 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.13

Identifier: 265870.331 at safari-7616.1.27.10-branch


  Commit: 387e93e40d0d1ab5bad4e63f1d2fdde91a66f048
      https://github.com/WebKit/WebKit/commit/387e93e40d0d1ab5bad4e63f1d2fdde91a66f048
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-09-14 (Thu, 14 Sep 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.14

Identifier: 265423.779 at safari-7616.1.27.10-branch


  Commit: ab5c6119c4697b1bb0ca87608c96a2d225957a65
      https://github.com/WebKit/WebKit/commit/ab5c6119c4697b1bb0ca87608c96a2d225957a65
  Author: Keith Miller <keith_miller at apple.com>
  Date:   2023-09-14 (Thu, 14 Sep 2023)

  Changed paths:
    A JSTests/stress/getbyoffset-cse-consistency.js
    A JSTests/stress/multigetbyoffset-cse-consistency.js
    M Source/JavaScriptCore/dfg/DFGCSEPhase.cpp
    M Source/JavaScriptCore/dfg/DFGClobberize.h
    M Source/JavaScriptCore/dfg/DFGHeapLocation.h

  Log Message:
  -----------
  Cherry-pick 47e039ffd689. rdar://115399657

    clobberize needs to be more precise with the *ByOffset nodes
    https://bugs.webkit.org/show_bug.cgi?id=261544
    rdar://115399657

    Reviewed by Yusuke Suzuki and Mark Lam.

    CSE phase uses clobberize to figure out if it's safe to merge two operations that
    def the same HeapLocation. Since HeapLocation does not currently have a way to
    track the offset used by the various *ByOffset nodes it can get confused and
    think that two ByOffset instructions produce the same value even if they don't
    use the same offset. This patch solves this by adding a new field to HeapLocation,
    which takes the metadata associated with the corresponding *ByOffset node. If two
    *ByOffset operations don't share the same metadata then they cannot be CSEed.

    * Source/JavaScriptCore/dfg/DFGCSEPhase.cpp:
    * Source/JavaScriptCore/dfg/DFGClobberize.h:
    (JSC::DFG::clobberize):
    * Source/JavaScriptCore/dfg/DFGHeapLocation.h:
    (JSC::DFG::HeapLocation::HeapLocation):
    (JSC::DFG::HeapLocation::extraState const):
    (JSC::DFG::HeapLocation::hash const):

    Canonical link: https://commits.webkit.org/265870.558@safari-7616-branch
Identifier: 265423.780 at safari-7616.1.27.10-branch


  Commit: 8d8ee64c2070b665b7bae48eebb1a4f05a231814
      https://github.com/WebKit/WebKit/commit/8d8ee64c2070b665b7bae48eebb1a4f05a231814
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-09-15 (Fri, 15 Sep 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7617.1.27.10.15

Canonical link: https://commits.webkit.org/265870.334@safari-7616.1.27.10-branch


  Commit: a3e6679c8d74247d493c920ac77dcd2649ec7ccc
      https://github.com/WebKit/WebKit/commit/a3e6679c8d74247d493c920ac77dcd2649ec7ccc
  Author: Russell Epstein <repstein at apple.com>
  Date:   2023-09-15 (Fri, 15 Sep 2023)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7616.1.27.10.15

Canonical link: https://commits.webkit.org/265870.335@safari-7616.1.27.10-branch


Compare: https://github.com/WebKit/WebKit/compare/83ac7712f7b7%5E...a3e6679c8d74


More information about the webkit-changes mailing list