Branch: refs/heads/safari-7619.1.5.6-branch Home: https://github.com/WebKit/WebKit Commit: d371998f7deca077c617eafd6bbfef59ed89c1ec https://github.com/WebKit/WebKit/commit/d371998f7deca077c617eafd6bbfef59ed89c1ec Author: Myah Cobbs <mco...@apple.com> Date: 2024-03-11 (Mon, 11 Mar 2024)
Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Versioning. Identifier: 273664.1360@safari-7619.1.5.6-branch Commit: 2994a63f6a6eebb415643193ac34895dd0a779c5 https://github.com/WebKit/WebKit/commit/2994a63f6a6eebb415643193ac34895dd0a779c5 Author: Myah Cobbs <mco...@apple.com> Date: 2024-03-11 (Mon, 11 Mar 2024) Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Correct Versioning. Commit: a7d8aa97cc3dd9294dc198f0bf244b6ebc6efde7 https://github.com/WebKit/WebKit/commit/a7d8aa97cc3dd9294dc198f0bf244b6ebc6efde7 Author: Brian Weinstein <bweinst...@apple.com> Date: 2024-03-11 (Mon, 11 Mar 2024) Changed paths: M Source/WebKit/WebProcess/Extensions/WebExtensionContextProxy.cpp Log Message: ----------- Cherry-pick 5e8c33f6e1ce. rdar://123409359 Check both browser and chrome objects in enumerateFramesAndNamespaceObjects https://bugs.webkit.org/show_bug.cgi?id=270657 rdar://123409359 Reviewed by Timothy Hatcher. Some extensions use a polyfill to overwrite the browser object with their own proxy. The Blue Canoe extension was doing this, and it led to WebExtensionContextProxy::enumerateFramesAndNamespaceObjects not being able to find the namespace object for the extension, since we were only checking the `browser` object. To fix this, check both `browser` and `chrome`, and use whichever one is valid. * Source/WebKit/WebProcess/Extensions/WebExtensionContextProxy.cpp: (WebKit::WebExtensionContextProxy::enumerateFramesAndNamespaceObjects): Canonical link: https://commits.webkit.org/275809@main Identifier: 273664.1362@safari-7619.1.5.6-branch Commit: 2704ec5246abb5d74b261b18fc88cc555006e28d https://github.com/WebKit/WebKit/commit/2704ec5246abb5d74b261b18fc88cc555006e28d Author: Tim Horton <thor...@apple.com> Date: 2024-03-11 (Mon, 11 Mar 2024) Changed paths: M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.h M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.h Log Message: ----------- Cherry-pick b46e324ca99c. rdar://122577452 Apply 274319@main to GPU-process rendered layers https://bugs.webkit.org/show_bug.cgi?id=270680 rdar://122577452 Reviewed by Megan Gardner and Richard Robinson. * Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp: (WebKit::RemoteImageBufferSet::ensureBufferForDisplay): (WebKit::RemoteImageBufferSet::ensureDynamicContentScalingResourceCache): * Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.h: * Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp: (WebKit::RemoteRenderingBackend::allocateImageBuffer): (WebKit::RemoteRenderingBackend::createImageBuffer): * Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.h: Copy the fix from 274319@main into RemoteImageBufferSet, to fix the bug for the GPU-process-enabled case. Canonical link: https://commits.webkit.org/275825@main Identifier: 273664.1363@safari-7619.1.5.6-branch Commit: b1493cd55783dbd7ee61bf1bb016bd0f045a5400 https://github.com/WebKit/WebKit/commit/b1493cd55783dbd7ee61bf1bb016bd0f045a5400 Author: Ada Chan <adac...@apple.com> Date: 2024-03-11 (Mon, 11 Mar 2024) Changed paths: M Source/WebCore/page/Page.cpp M Source/WebCore/page/Page.h M Source/WebKit/WebProcess/WebPage/WebPage.cpp Log Message: ----------- Cherry-pick 2b9b6bf2f2fb. rdar://123777699 [WebXR] Skip freezing layer tree with an active WebXR immersive session only when there's video content https://bugs.webkit.org/show_bug.cgi?id=270669 rdar://123777699 Reviewed by Eric Carlson. We initially skip freezing the layer tree with an active WebXR immersive session so videos can continue to get their requestVideoFrameCallback serviced. However, since this also incurs a power cost, we'll only do this when there's video content on the page. * Source/WebCore/page/Page.cpp: (WebCore::Page::shouldBlockLayerTreeFreezingForVideo): * Source/WebCore/page/Page.h: * Source/WebKit/WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::updateDrawingAreaLayerTreeFreezeState): Canonical link: https://commits.webkit.org/275842@main Identifier: 273664.1364@safari-7619.1.5.6-branch Commit: 3a8dc20ce2dfb3d6f767ac67f7223191e6e078e6 https://github.com/WebKit/WebKit/commit/3a8dc20ce2dfb3d6f767ac67f7223191e6e078e6 Author: Megan Gardner <megan_gard...@apple.com> Date: 2024-03-11 (Mon, 11 Mar 2024) Changed paths: M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm Log Message: ----------- Cherry-pick 89bc7dd33ce8. rdar://122843511 Find in Note: Dark gray outline (shadow) appears behind gray/yellow highlights when matched text found in HTML note. https://bugs.webkit.org/show_bug.cgi?id=270666 rdar://122843511 Reviewed by Aditya Keerthi. In notes, the WKContentView is transparent, so our original solution of putting an additional grey layer behind the content view that filled up the empty parts of the scroll view would show through and make the find ui have a incorrect grey cast. So instead, we make four views that surround the WKContentView to fill in any part of the scrollView that isn't covered by the contentView. These are arranged around the content view like so: ----- ----------- | | | | |----------| | | | | | | | | ----- ------ | | | | |__________|____| Each view is expanded to reach the edges of the scroll view every time the view is scrolled or the bounds change. This means that no matter where the content view is scrolled to, there will be a view that gives the correct grey cast to the scroll view. * Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h: * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm: (-[WKWebView scrollViewDidScroll:]): (-[WKWebView _frameOrBoundsMayHaveChanged]): (-[WKWebView _updateFindOverlayForOverflowScrollPositions]): (-[WKWebView _showFindOverlay]): (-[WKWebView _hideFindOverlay]): (-[WKWebView _didAddLayerForFindOverlay:]): (-[WKWebView _updateFindOverlayPosition]): Deleted. Canonical link: https://commits.webkit.org/275873@main Identifier: 273664.1365@safari-7619.1.5.6-branch Commit: 39d7eb24d8f385a409d6cec2ae7297583bfc6116 https://github.com/WebKit/WebKit/commit/39d7eb24d8f385a409d6cec2ae7297583bfc6116 Author: Chris Dumez <cdu...@apple.com> Date: 2024-03-11 (Mon, 11 Mar 2024) Changed paths: M Source/WebKit/Shared/Cocoa/WKKeyedCoder.mm Log Message: ----------- Cherry-pick b1fa8241a6a7. rdar://124247709 Fix memory leak under [WKKeyedCoder initWithDictionary] https://bugs.webkit.org/show_bug.cgi?id=270734 rdar://124247709 Reviewed by Darin Adler. Make sure we adopt the result of `[NSDictionary mutableCopy]`. * Source/WebKit/Shared/Cocoa/WKKeyedCoder.mm: (-[WKKeyedCoder initWithDictionary:]): Canonical link: https://commits.webkit.org/275875@main Identifier: 273664.1366@safari-7619.1.5.6-branch Compare: https://github.com/WebKit/WebKit/compare/d371998f7dec%5E...39d7eb24d8f3 To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes