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
