Branch: refs/heads/safari-7616.1.17-branch Home: https://github.com/WebKit/WebKit Commit: 8651a560be06290e09ce8b0da3be36ce3b134bb2 https://github.com/WebKit/WebKit/commit/8651a560be06290e09ce8b0da3be36ce3b134bb2 Author: Elliott Williams <e...@apple.com> Date: 2023-06-06 (Tue, 06 Jun 2023)
Changed paths: M Source/WebKit/Configurations/SandboxProfiles.xcconfig M Source/WebKit/WebKit.xcodeproj/project.pbxproj Log Message: ----------- Cherry-pick c9a65a407c6b. rdar://problem/109790387 Restore iOS sandbox profile generation in engineering builds https://bugs.webkit.org/show_bug.cgi?id=257276 rdar://109790387 Reviewed by Alexey Proskuryakov. 264752@main (6f04c95bf8f3) stopped preprocessing iOS sandbox profiles unconditionally during at-desk builds. The logic was that the profiles are only used during WebKit's production build, so there was no need to generate them locally. However, it's helpful for engineers to be able to manually test the sandbox profiles outside of a production build environment. When building for iOS, make WebKit depend on the "Sandbox Profiles" target. Change that target to install sandbox profiles to BUILT_PRODUCTS_DIR in non-install builds. Add a dependency on WTF, since Platform headers are used to preprocess the sandbox profiles and the target needs to be scheduled after they are available. The result is that sandbox profiles are preprocessed at their old DerivedSources location, and are copied to a path like WebKitBuild/Debug-iphoneos/usr/local/share/sandbox/... Also, remove the old "Copy iOS Sandbox Profiles for Manual Sandboxing" script phase, which was an unused workflow. * Source/WebKit/Configurations/SandboxProfiles.xcconfig: Declare a path variable used to install profiles into BUILT_PRODUCTS_DIR in non-install builds. Add $(BUILT_PRODUCTS_DIR)/usr/local/include to the search path, to pick up WTF headers during engineering builds. * Source/WebKit/WebKit.xcodeproj/project.pbxproj: Canonical link: https://commits.webkit.org/264904@main Canonical link: https://commits.webkit.org/264854.1@safari-7616.1.17-branch Commit: 4307e2ee9baf802bc175cc7c7cc43fd3577242d1 https://github.com/WebKit/WebKit/commit/4307e2ee9baf802bc175cc7c7cc43fd3577242d1 Author: Youenn Fablet <youe...@gmail.com> Date: 2023-06-07 (Wed, 07 Jun 2023) Changed paths: M Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.mm Log Message: ----------- Cherry-pick 5129c74d949f. rdar://problem/110139703 LocalSampleBufferDisplayLayer crops frames with a rotation of 90 degrees https://bugs.webkit.org/show_bug.cgi?id=257747 rdar://110139703 Reviewed by Eric Carlson. We broke the computation of bounds and position in case of rotations in https://github.com/WebKit/WebKit/commit/0e0d7976dfe09316e3cb57a4786defeb5c5d7eb6. We update the code to be back to the previous version. * Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.mm: (WebCore::LocalSampleBufferDisplayLayer::updateRootLayerBoundsAndPosition): Canonical link: https://commits.webkit.org/264930@main Canonical link: https://commits.webkit.org/264854.2@safari-7616.1.17-branch Commit: fb994f0b12070ef302bad9a3565acb7b7e9b9b54 https://github.com/WebKit/WebKit/commit/fb994f0b12070ef302bad9a3565acb7b7e9b9b54 Author: Jer Noble <jer.no...@apple.com> Date: 2023-06-07 (Wed, 07 Jun 2023) Changed paths: M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm M Source/WebKit/GPUProcess/media/cocoa/RemoteMediaPlayerProxyCocoa.mm Log Message: ----------- Cherry-pick 580bf6c28d2b. rdar://problem/110320059 REGRESSION (264795@main) Twitter.com: Video blank/black while scrolling https://bugs.webkit.org/show_bug.cgi?id=257805 rdar://110320059 Reviewed by Eric Carlson. Use videoInlineSize() rather than presentationSize() to determine whether or not a layer should be created in MediaPlayerPrivateMediaSourceAVFObjC. And to ensure the layer does get created when videoInlineSize() changes, override setVideoInlineSizeFenced() in that class, and call it from RemoteMediaPlayerProxy::setVideoInlineSizeFenced(). * Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h: * Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::shouldEnsureLayer const): (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::setVideoInlineSizeFenced): * Source/WebKit/GPUProcess/media/cocoa/RemoteMediaPlayerProxyCocoa.mm: (WebKit::RemoteMediaPlayerProxy::setVideoInlineSizeFenced): Canonical link: https://commits.webkit.org/264949@main Canonical link: https://commits.webkit.org/264854.3@safari-7616.1.17-branch Commit: e55edc40e738aeb2a91b628d6b5d1a6f243529fa https://github.com/WebKit/WebKit/commit/e55edc40e738aeb2a91b628d6b5d1a6f243529fa Author: Russell Epstein <repst...@apple.com> Date: 2023-06-07 (Wed, 07 Jun 2023) Changed paths: M Source/WebKit/Configurations/SandboxProfiles.xcconfig M Source/WebKit/WebKit.xcodeproj/project.pbxproj Log Message: ----------- Revert "Cherry-pick c9a65a407c6b. rdar://problem/109790387" This reverts commit 8651a560be06290e09ce8b0da3be36ce3b134bb2. Canonical link: https://commits.webkit.org/264854.4@safari-7616.1.17-branch Commit: 732cce41da405e97a79ef48e301eca77c4aa4d6a https://github.com/WebKit/WebKit/commit/732cce41da405e97a79ef48e301eca77c4aa4d6a Author: Russell Epstein <repst...@apple.com> Date: 2023-06-07 (Wed, 07 Jun 2023) Changed paths: M Source/WebKit/Configurations/SandboxProfiles.xcconfig M Source/WebKit/WebKit.xcodeproj/project.pbxproj Log Message: ----------- Revert "Revert "Cherry-pick c9a65a407c6b. rdar://problem/109790387"" This reverts commit e55edc40e738aeb2a91b628d6b5d1a6f243529fa. Commit: 485a2cdff769137a4287e50dda76a6412f90b874 https://github.com/WebKit/WebKit/commit/485a2cdff769137a4287e50dda76a6412f90b874 Author: Elliott Williams <e...@apple.com> Date: 2023-06-07 (Wed, 07 Jun 2023) Changed paths: M Source/WebKit/Configurations/SandboxProfiles.xcconfig M Source/WebKit/Configurations/WebKit.xcconfig M Source/WebKit/DerivedSources-input.xcfilelist M Source/WebKit/DerivedSources-output.xcfilelist M Source/WebKit/DerivedSources.make R Source/WebKit/Scripts/preprocess-sandbox-profile-rule.sh M Source/WebKit/WebKit.xcodeproj/project.pbxproj Log Message: ----------- Cherry-pick 1b0e675562c9. rdar://problem/110353926 Revert "[Xcode] Dependencies in preprocessed sandbox profiles not tracked" https://bugs.webkit.org/show_bug.cgi?id=257814 rdar://110353926 Unreviewed. Seems to be causing missing sandbox profiles on some Mac builds. Revert all commits landed under the bug: Revert "Restore iOS sandbox profile generation in engineering builds" This reverts commit c9a65a407c6b09028fa5a074dbc9fc60011937d4. Revert "Add quoting for arrays containing whitespace paths in preprocess-sandbox-profile-rule.sh" This reverts commit 6f04c95bf8f346bf66b311ee0448fce8d60b1791. Revert "Fix whitespace-containing path in preprocess-sandbox-profile-rule.sh" This reverts commit 5f13e1c10eb0f44f1a71f4d6c56d59313f614577. Revert "[Xcode] Dependencies in preprocessed sandbox profiles not tracked" This reverts commit 40fd93b1f2eff242effa1c79d30571d1547c9a74. Canonical link: https://commits.webkit.org/264953@main Canonical link: https://commits.webkit.org/264854.6@safari-7616.1.17-branch Commit: 4309297ef9ad7d05e1b106010c0655d9f61c1fa4 https://github.com/WebKit/WebKit/commit/4309297ef9ad7d05e1b106010c0655d9f61c1fa4 Author: Russell Epstein <repst...@apple.com> Date: 2023-06-07 (Wed, 07 Jun 2023) Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Versioning. WebKit-7616.1.17.1 Identifier: 263322.1539@safari-7616.1.17-branch Commit: 682d2decf21744bf8ef4689d1465b7f6720c4af3 https://github.com/WebKit/WebKit/commit/682d2decf21744bf8ef4689d1465b7f6720c4af3 Author: Jean-Yves Avenard <j...@apple.com> Date: 2023-06-08 (Thu, 08 Jun 2023) Changed paths: M Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm M Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm Log Message: ----------- Cherry-pick 369109ea28ce. rdar://problem/109845717 Safari may crash when tapping on video after returning to full screen from PiP https://bugs.webkit.org/show_bug.cgi?id=257651 rdar://109845717 Reviewed by Youenn Fablet. Temporary fix to get around rdar://110172009. When exiting PiP, the UIWindow gets deleted while the video view is still a child of it. As such [videoView window] becomes a dangling pointers and any references to the old window will cause a crash. For now, we override the window method of the WKLayerHostView so that it can detects if the window parent is still alive. * Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm: (VideoFullscreenInterfaceAVKit::cleanupFullscreen): * Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm: (-[WKLayerHostView willMoveToWindow:]): (-[WKLayerHostView window]): (WebKit::VideoFullscreenManagerProxy::returnVideoView): Canonical link: https://commits.webkit.org/264880@main Identifier: 263322.1540@safari-7616.1.17-branch Commit: b90bf3e9e3798ce7918ce1857027c87e3242e7dc https://github.com/WebKit/WebKit/commit/b90bf3e9e3798ce7918ce1857027c87e3242e7dc Author: Sihui Liu <sihui_...@apple.com> Date: 2023-06-08 (Thu, 08 Jun 2023) Changed paths: M Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.h Log Message: ----------- Cherry-pick ca3c4b77be91. rdar://problem/110281842 Add nullability annotation to removeDataStoreForIdentifier https://bugs.webkit.org/show_bug.cgi?id=257733 rdar://110281842 Reviewed by Per Arne Vollan. The generated Swift API should mark Error as optional. * Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.h: Canonical link: https://commits.webkit.org/264900@main Identifier: 263322.1541@safari-7616.1.17-branch Commit: 357fffd30e23d98af0a2967327b31d17231e793b https://github.com/WebKit/WebKit/commit/357fffd30e23d98af0a2967327b31d17231e793b Author: Gerald Squelart <g_squel...@apple.com> Date: 2023-06-08 (Thu, 08 Jun 2023) Changed paths: M LayoutTests/fast/attachment/cocoa/wide-attachment-save-event-expected.txt M LayoutTests/fast/attachment/mac/wide-attachment-image-controls-basic-expected.txt M LayoutTests/platform/ios-wk2/fast/attachment/cocoa/wide-attachment-rendering-expected.txt M LayoutTests/platform/mac-wk2/fast/attachment/cocoa/wide-attachment-rendering-expected.txt M Source/WebCore/html/HTMLAttachmentElement.cpp M Source/WebCore/html/HTMLAttachmentElement.h M Source/WebCore/html/shadow/attachmentElementShadow.css M Source/WebCore/rendering/RenderAttachment.cpp M Source/WebCore/rendering/RenderAttachment.h M Source/WebCore/rendering/RenderThemeIOS.mm M Source/WebCore/rendering/RenderThemeMac.mm Log Message: ----------- Cherry-pick 333b4b2030a1. rdar://problem/108157331 Use RenderAttachment for wide-layout attachments, with some modified layout and rendering https://bugs.webkit.org/show_bug.cgi?id=256637 rdar://108157331 Reviewed by Alan Baradlay. A lot of the editor code interacting with attachments relies on the renderer being exactly `RenderAttachment`, which led to some misbehavior when the wide-layout attachment was using the more generic `RenderBlockFlow`. So now the renderer is always `RenderAttachment`, but the layout and rendering paths redirect to special wide-layout-only functions. * LayoutTests/fast/attachment/cocoa/wide-attachment-save-event-expected.txt: * LayoutTests/fast/attachment/mac/wide-attachment-image-controls-basic-expected.txt: * LayoutTests/platform/ios-wk2/fast/attachment/cocoa/wide-attachment-rendering-expected.txt: * LayoutTests/platform/mac-wk2/fast/attachment/cocoa/wide-attachment-rendering-expected.txt: * Source/WebCore/html/HTMLAttachmentElement.cpp: (WebCore::HTMLAttachmentElement::createElementRenderer): Always return a `RenderAttachment`, like it was before introducing the wide-layout styling. (WebCore::HTMLAttachmentElement::insertedIntoAncestor): Because of how the root element does the layout, the shadow root element's margins were ignored, so now the margins are added here in the root element. * Source/WebCore/html/HTMLAttachmentElement.h: * Source/WebCore/html/shadow/attachmentElementShadow.css: (div#attachment-container): Since the margin is now in the top-level element outside the shadow tree, it is not needed here anymore. (div#attachment-container::selection): Deleted. The selection coloring is handled by the `RenderReplaced` painting code, so this styling was ignored anyway. * Source/WebCore/rendering/RenderAttachment.cpp: (WebCore::RenderAttachment::RenderAttachment): (WebCore::RenderAttachment::layoutWideLayoutAttachmentOnly): (WebCore::RenderAttachment::layout): Layout the wide-layout shadow tree if present, the "replaced" and shadow content layouts are still performed to handle all the necessary sizing and optional image controls. (WebCore::RenderAttachment::paintWideLayoutAttachmentOnly const): New wide-layout paint code, handling the full Foreground and Selection phases and painting everything in the shadow tree. * Source/WebCore/rendering/RenderAttachment.h: Cleaned up "Shadow" functions, to separate just "shadow controls" (like image controls) and any "shadow content" that may include the wide-layout shadow tree. Also let the `RenderReplaced` painting code handle the selection tint. * Source/WebCore/rendering/RenderThemeIOS.mm: (WebCore::RenderThemeIOS::paintAttachment): * Source/WebCore/rendering/RenderThemeMac.mm: (WebCore::RenderThemeMac::paintAttachment): When actually painting a wide-layout attachment, skip the legacy painting. Canonical link: https://commits.webkit.org/264914@main Identifier: 263322.1542@safari-7616.1.17-branch Commit: 918db9d0c22e9e2fc6485aba9aa77b4dcf13c2cd https://github.com/WebKit/WebKit/commit/918db9d0c22e9e2fc6485aba9aa77b4dcf13c2cd Author: Matt Woodrow <mattwood...@apple.com> Date: 2023-06-08 (Thu, 08 Jun 2023) Changed paths: M Source/WebCore/page/ChromeClient.h M Source/WebCore/page/Page.cpp M Source/WebCore/page/Page.h M Source/WebCore/page/RenderingUpdateScheduler.cpp M Source/WebCore/page/RenderingUpdateScheduler.h M Source/WebKit/SourcesCocoa.txt M Source/WebKit/WebKit.xcodeproj/project.pbxproj M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h M Source/WebKit/WebProcess/WebPage/DrawingArea.h R Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.h R Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm Log Message: ----------- Cherry-pick fa67a2625225. rdar://problem/110174274 Schedule rendering via RemoteLayerTreeDrawingArea directly, rather than using a 'fake' DisplayRefreshMonitor. https://bugs.webkit.org/show_bug.cgi?id=257290 <rdar://problem/109953504> Reviewed by Simon Fraser. RemoteLayerTreeDisplayRefreshMonitor is mostly just a wrapper around asking the RemoteLayerTreeDrawingArea to schedule when it wants to display next. This is specific to that drawing area, and can be throttled if the drawing area is failing to commit layer trees as fast as expected. DisplayRefreshMonitorManager caches DisplayRefreshMonitors, and shares them between all WebCore::Page/RenderingUpdateSchedulers on the same Display. This means if we have multiple RemoteLayerTreeDrawingAreas on the same display (and in the same process), we'll be sharing a single RemoteLayerTreeDisplayRefreshMonitor, driven at the effective rate of one of the drawing areas. If the first drawing area is trying to hit full frame rate, but rendering takes too long, it'll run at the fastest rate it can manage. Any other drawing areas that are using the shared display refresh monitor will then be throttled to that same rate, even if they could otherwise run at full speed. DrawingAreaCoordinatedGraphics is currently working around this by synthesizing a DisplayID for each drawing area, to prevent DisplayRefreshMonitor sharing. This change makes WebChromeClient pass the scheduleRenderingUpdate request onto RemoteLayerTreeDrawingArea directly, so we can avoid falling back to the RenderingUpdateScheduler/DisplayRefreshMonitor implementation. RemoteLayerTreeDisplayRefreshMonitor is removed, since it should never be used. * Source/WebCore/page/ChromeClient.h: (WebCore::ChromeClient::renderingUpdateFrequencyChanged): * Source/WebCore/page/Page.cpp: (WebCore::Page::windowScreenDidChange): (WebCore::Page::triggerRenderingUpdateForTesting): (WebCore::Page::timelineControllerMaximumAnimationFrameRateDidChange): (WebCore::Page::setIsVisuallyIdleInternal): (WebCore::Page::handleLowModePowerChange): * Source/WebCore/page/Page.h: * Source/WebCore/page/RenderingUpdateScheduler.cpp: (WebCore::RenderingUpdateScheduler::triggerRenderingUpdateForTesting): Deleted. * Source/WebCore/page/RenderingUpdateScheduler.h: * Source/WebKit/SourcesCocoa.txt: * Source/WebKit/WebKit.xcodeproj/project.pbxproj: * Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::scheduleRenderingUpdate): (WebKit::WebChromeClient::renderingUpdateFrequencyChanged): * Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h: * Source/WebKit/WebProcess/WebPage/DrawingArea.h: (WebKit::DrawingArea::scheduleRenderingUpdate): (WebKit::DrawingArea::renderingUpdateFrequencyChanged): * Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.h: Removed. * Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm: Removed. * Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h: * Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::RemoteLayerTreeDrawingArea): (WebKit::RemoteLayerTreeDrawingArea::createDisplayRefreshMonitor): (WebKit::RemoteLayerTreeDrawingArea::displayDidRefresh): (WebKit::RemoteLayerTreeDrawingArea::scheduleRenderingUpdate): (WebKit::RemoteLayerTreeDrawingArea::renderingUpdateFrequencyChanged): (WebKit::RemoteLayerTreeDrawingArea::willDestroyDisplayRefreshMonitor): Deleted. (WebKit::RemoteLayerTreeDrawingArea::adoptDisplayRefreshMonitorsFromDrawingArea): Deleted. Canonical link: https://commits.webkit.org/264920@main Identifier: 263322.1543@safari-7616.1.17-branch Commit: 824af0f62f372c352d1550660ae5f26e4bfcc2c3 https://github.com/WebKit/WebKit/commit/824af0f62f372c352d1550660ae5f26e4bfcc2c3 Author: Wenson Hsieh <wenson_hs...@apple.com> Date: 2023-06-08 (Thu, 08 Jun 2023) Changed paths: M Source/WebCore/dom/SimpleRange.h M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm Log Message: ----------- Cherry-pick ce1f5b1c5dd7. rdar://problem/109582406 REGRESSION (264086@main): [iOS 17] Autocorrect highlight is sometimes incorrect in Mail compose https://bugs.webkit.org/show_bug.cgi?id=257830 rdar://109582406 Reviewed by Megan Gardner and Aditya Keerthi. The refactoring in 264086@main introduced a subtle behavior change in the case where the text iterator emits spaces for soft line breaks in an `_editable` web view. When emitting text for a soft line break, we previously appended the zero rect in the list of `textRects` for this character range; however, after `264086@main`, we now skip the rect altogether, which causes the list of rects to fall out of sync with the combined `contextBefore` + `selectedText` + `contextAfter` string. Consequently, UIKit (which currently assumes that indices into the string correspond directly to indices of rects in `textRects`) ends up using the wrong character layout rects. This patch fixes the above by restoring preexisting behavior and appending a single empty rect in the case where the text iterator finds (non-empty) text, but there are no character rects. Additionally, I attempted to add a debug assertion to verify that the number of resulting text rects is always consistent with the combined length of the context and selection strings; however, this uncovered some bugs in the existing implementation, even prior the changes in 264086@main, where we would sometimes end up with either too many or too few rects, when running the following three layout tests: • editing/selection/ios/update-selection-after-iframe-scroll.html • editing/selection/ios/update-selection-after-overflow-scroll.html • editing/selection/shift-click-includes-existing-selection.html This patch fixes the assertion in `editing/selection/shift-click-includes-existing-selection.html`, where we end up with too many text rects due to the fact that the text iterator advances to both the upstream and downstream positions of a line break, emitting "\n" both times with the same rect. To avoid this, we keep track of the last `SimpleRange` we observed, and avoid emitting a duplicate rect in the case where we advance to the a range we just visited. Test: DocumentEditingContext.CharacterRectsInEditableWebView * Source/WebCore/dom/SimpleRange.h: * Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::requestDocumentEditingContext): * Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm: Canonical link: https://commits.webkit.org/264969@main Canonical link: https://commits.webkit.org/264854.12@safari-7616.1.17-branch Commit: 6d07430ef3bb622e595c2fa20b008c138c9903ba https://github.com/WebKit/WebKit/commit/6d07430ef3bb622e595c2fa20b008c138c9903ba Author: Simon Fraser <simon.fra...@apple.com> Date: 2023-06-08 (Thu, 08 Jun 2023) Changed paths: M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm Log Message: ----------- Cherry-pick 10a4bdb95f1d. rdar://problem/109810157 Fix the setDisableImplicitTransactionMainThreadAssert: respondsToSelector check https://bugs.webkit.org/show_bug.cgi?id=257840 rdar://109810157 Reviewed by Matt Woodrow. The SPI is `+[CATransaction setDisableImplicitTransactionMainThreadAssert]` so we need to call `respondsToSelector:` on the Class, not instances of the class. * Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm: (WebKit::RemoteScrollingTreeMac::RemoteScrollingTreeMac): Canonical link: https://commits.webkit.org/264995@main Identifier: 263319.1548@safari-7616.1.17-branch Commit: 09d57f6974acbdea7e35b2575b251d85dbcd8ba6 https://github.com/WebKit/WebKit/commit/09d57f6974acbdea7e35b2575b251d85dbcd8ba6 Author: Myah Cobbs <mco...@apple.com> Date: 2023-06-12 (Mon, 12 Jun 2023) Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Versioning. WebKit-7616.1.17.2 Identifier: 263322.1546@safari-7616.1.17-branch Commit: d07907a41aba70af8ec2b877f3720a4bbee53f67 https://github.com/WebKit/WebKit/commit/d07907a41aba70af8ec2b877f3720a4bbee53f67 Author: Myah Cobbs <mco...@apple.com> Date: 2023-06-13 (Tue, 13 Jun 2023) Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Versioning. WebKit-7616.1.17.3 Identifier: 263319.1550@safari-7616.1.17-branch Commit: a8519b54b2cf9c6e1be003d817cefdabe16f11a6 https://github.com/WebKit/WebKit/commit/a8519b54b2cf9c6e1be003d817cefdabe16f11a6 Author: Myah Cobbs <mco...@apple.com> Date: 2023-06-14 (Wed, 14 Jun 2023) Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Versioning. WebKit-7616.1.17.4 Identifier: 263322.1548@safari-7616.1.17-branch Compare: https://github.com/WebKit/WebKit/compare/8651a560be06%5E...a8519b54b2cf _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes