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
