Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 7f9aac406e5b278abf7734e70e3eaa7a19dd2471
https://github.com/WebKit/WebKit/commit/7f9aac406e5b278abf7734e70e3eaa7a19dd2471
Author: Charlie Wolfe <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
A
LayoutTests/http/tests/resourceLoadStatistics/third-party-cookie-blocking-about-blank-popup-expected.txt
A
LayoutTests/http/tests/resourceLoadStatistics/third-party-cookie-blocking-about-blank-popup.html
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
Cherry-pick 305413.366@safari-7624-branch (8acf8433e6be).
https://bugs.webkit.org/show_bug.cgi?id=308445
Block third-party cookies for requests from about:blank popups
https://bugs.webkit.org/show_bug.cgi?id=308445
rdar://168927271
Reviewed by Matthew Finkel.
When an about:blank popup made cross-origin requests, its
firstPartyForCookies was set to about:blank,
which has an empty registrable domain.
thirdPartyCookieBlockingDecisionForRequest() returns
ThirdPartyCookieBlockingDecision::None for empty domains, bypassing
third-party cookie blocking.
FrameLoader::updateFirstPartyForCookies() should inherit the opener's
firstPartyForCookies when the main
frame URL is an about:blank or other owner-inherited document.
*
LayoutTests/http/tests/resourceLoadStatistics/third-party-cookie-blocking-about-blank-popup-expected.txt:
Added.
*
LayoutTests/http/tests/resourceLoadStatistics/third-party-cookie-blocking-about-blank-popup.html:
Added.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::updateFirstPartyForCookies):
Identifier: 305413.366@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.499@webkitglib/2.52
Commit: 49e38d5404ca6e014d68dfaa6545ab33ad261d17
https://github.com/WebKit/WebKit/commit/49e38d5404ca6e014d68dfaa6545ab33ad261d17
Author: Sihui Liu <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WebCore/page/Frame.cpp
M Source/WebCore/page/Frame.h
M Source/WebKit/Shared/FrameInfoData.cpp
M Source/WebKit/Shared/FrameInfoData.h
M Source/WebKit/Shared/FrameInfoData.serialization.in
M Source/WebKit/UIProcess/Cocoa/UIDelegate.mm
M Source/WebKit/UIProcess/ProvisionalPageProxy.cpp
M
Source/WebKit/UIProcess/WebsiteData/WebDeviceOrientationAndMotionAccessController.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebPage/WebFrame.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/DeviceOrientation.mm
Log Message:
-----------
Cherry-pick 305413.367@safari-7624-branch (322ddc58184f).
https://bugs.webkit.org/show_bug.cgi?id=308445
Use requesting origin instead of active origin for DeviceOrientation
permission request
rdar://168597925
Reviewed by Chris Dumez.
The current implementation uses active origin (origin being navigating to)
instead of requesting origin in permission
prompt, and this might lead to permission being granted to a wrong origin.
API test: DeviceOrientation.PermissionOriginDuringPendingNavigation
* Source/WebCore/page/Frame.cpp:
(WebCore::Frame::topOrigin const):
* Source/WebCore/page/Frame.h:
* Source/WebKit/Shared/FrameInfoData.cpp:
(WebKit::legacyEmptyFrameInfo):
* Source/WebKit/Shared/FrameInfoData.h:
* Source/WebKit/Shared/FrameInfoData.serialization.in:
* Source/WebKit/UIProcess/Cocoa/UIDelegate.mm:
(WebKit::UIDelegate::UIClient::shouldAllowDeviceOrientationAndMotionAccess):
* Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:
(WebKit::ProvisionalPageProxy::cancel):
*
Source/WebKit/UIProcess/WebsiteData/WebDeviceOrientationAndMotionAccessController.cpp:
(WebKit::WebDeviceOrientationAndMotionAccessController::shouldAllowAccess):
* Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::navigationActionData const):
* Source/WebKit/WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::info const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/DeviceOrientation.mm:
((DeviceOrientation, PermissionOriginDuringPendingNavigation)):
Identifier: 305413.367@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.500@webkitglib/2.52
Commit: 60e6301e22c8516b50856d0d5b0619e0c741e6b4
https://github.com/WebKit/WebKit/commit/60e6301e22c8516b50856d0d5b0619e0c741e6b4
Author: Roberto Rodriguez <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
A
LayoutTests/http/tests/security/contentSecurityPolicy/path-traversal-bypass-with-percent-encoding-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/path-traversal-bypass-with-percent-encoding.html
M Source/WebCore/page/csp/ContentSecurityPolicySource.cpp
M Source/WebCore/page/csp/ContentSecurityPolicySourceList.cpp
Log Message:
-----------
Cherry-pick 305413.379@safari-7624-branch (e979e8c9cdc1).
https://bugs.webkit.org/show_bug.cgi?id=308675
Align ContentSecurityPolicySource::pathMatches() with CSP3 spec path
matching algorithm
https://bugs.webkit.org/show_bug.cgi?id=308675
rdar://168933742
Reviewed by Anne van Kesteren.
WebKit's pathMatches() diverged from the CSP3 spec by percent-decoding
the entire URL path as a flat string, then doing prefix/equality checks.
This made it vulnerable to %2F..%2F path traversal bypasses.
This change adopts the spec's algorithm (§ 6.7.2.12): split both paths
on literal '/', percent-decode each segment, and compare corresponding
pairs. This eliminates the vulnerability — %2F never produces a segment
boundary, so sequences like %2F..%2F stay trapped in a single segment
and won't match the expected path component.
Test:
http/tests/security/contentSecurityPolicy/path-traversal-bypass-with-percent-encoding.html
*
LayoutTests/http/tests/security/contentSecurityPolicy/path-traversal-bypass-with-percent-encoding-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/path-traversal-bypass-with-percent-encoding.html:
Added.
* Source/WebCore/page/csp/ContentSecurityPolicySource.cpp:
(WebCore::ContentSecurityPolicySource::pathMatches const):
* Source/WebCore/page/csp/ContentSecurityPolicySourceList.cpp:
(WebCore::ContentSecurityPolicySourceList::parsePath):
Identifier: 305413.379@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.501@webkitglib/2.52
Commit: 6e172821747e972e3bd722b520d0bce3de56aac0
https://github.com/WebKit/WebKit/commit/6e172821747e972e3bd722b520d0bce3de56aac0
Author: David Kilzer <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WebCore/workers/service/server/SWServer.cpp
Log Message:
-----------
Cherry-pick 305413.383@safari-7624-branch (91ab7f0ce691).
https://bugs.webkit.org/show_bug.cgi?id=308844
SWServer::topLevelServiceWorkerClientFromPageIdentifier() crashes when maps
are out-of-sync
<https://bugs.webkit.org/show_bug.cgi?id=308844>
<rdar://157943937>
Reviewed by Brent Fulgham.
A crash occurs in `topLevelServiceWorkerClientFromPageIdentifier()` when
the Service Worker maps `m_clientIdentifiersPerOrigin` and `m_clientsById`
become out-of-sync. The function iterates over client identifiers from
`m_clientIdentifiersPerOrigin` and calls `m_clientsById.find()` for each
one, but never checks whether the result equals `m_clientsById.end()`
before dereferencing it.
Add an end-iterator check in
`topLevelServiceWorkerClientFromPageIdentifier()`
and use `continue` to skip missing clients (matching the pattern in
`clientIsAppInitiatedForRegistrableDomain()`).
Also replace the ASSERT-only guard in `serviceWorkerClientWithOriginByID()`
with a proper end-iterator check that returns `std::nullopt` in release
builds.
No test since this is a race condition with no known steps to reproduce.
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::serviceWorkerClientWithOriginByID):
- Replace ASSERT-only check with end-iterator check returning
std::nullopt.
(WebCore::SWServer::topLevelServiceWorkerClientFromPageIdentifier):
- Add end-iterator check with ASSERT_NOT_REACHED() to continue in order
to skip missing clients.
Identifier: 305413.383@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.502@webkitglib/2.52
Commit: 3807b6715c0e4edc800b91dcc4d4cee519531069
https://github.com/WebKit/WebKit/commit/3807b6715c0e4edc800b91dcc4d4cee519531069
Author: Roberto Rodriguez <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
A
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-inherits-multiple-csp-policies-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-inherits-multiple-csp-policies.html
A
LayoutTests/http/tests/security/contentSecurityPolicy/resources/create-blob-iframe.js
A
LayoutTests/http/tests/security/contentSecurityPolicy/resources/echo-multiple-csp-blob-iframe.py
M
LayoutTests/imported/w3c/web-platform-tests/trusted-types/inheriting-csp-for-local-schemes-expected.txt
M Source/WebCore/page/csp/ContentSecurityPolicyResponseHeaders.cpp
Log Message:
-----------
Cherry-pick 305413.385@safari-7624-branch (a90148642299).
https://bugs.webkit.org/show_bug.cgi?id=308906
Fix CSP policy loss in blob: URL inheritance when page sends multiple CSP
headers
https://bugs.webkit.org/show_bug.cgi?id=308906
rdar://168927377
Reviewed by Anne van Kesteren.
A page with two or more CSP headers correctly enforces those policies on
itself, but blob: URLs it creates only see the last one. The policies
are correctly captured in the policy container, but
ContentSecurityPolicyResponseHeaders::addPolicyHeadersTo() writes them
to the blob response using ResourceResponse::setHTTPHeaderField(), which
overwrites policies rather than appending them together.
Change to use ResourceResponse::addHTTPHeaderField() which
comma-concatenates the values and preserves all CSP policies.
Test:
http/tests/security/contentSecurityPolicy/blob-url-inherits-multiple-csp-policies.html
*
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-inherits-multiple-csp-policies-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-inherits-multiple-csp-policies.html:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/resources/create-blob-iframe.js:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/resources/echo-multiple-csp-blob-iframe.py:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/trusted-types/inheriting-csp-for-local-schemes-expected.txt:
* Source/WebCore/page/csp/ContentSecurityPolicyResponseHeaders.cpp:
(WebCore::ContentSecurityPolicyResponseHeaders::addPolicyHeadersTo const):
Identifier: 305413.385@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.503@webkitglib/2.52
Commit: 4a8a90644cfc7a9a4b3cab13c4c0b49c53862787
https://github.com/WebKit/WebKit/commit/4a8a90644cfc7a9a4b3cab13c4c0b49c53862787
Author: Aditya Keerthi <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
A
LayoutTests/fast/forms/label/label-click-event-dispatch-untrusted-expected.txt
A LayoutTests/fast/forms/label/label-click-event-dispatch-untrusted.html
M Source/WebCore/dom/Element.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SwitchInputTests.mm
Log Message:
-----------
Cherry-pick 305413.395@safari-7624-branch (2c99c891b64c).
https://bugs.webkit.org/show_bug.cgi?id=309082
Haptic feedback for <input type=checkbox switch> can be triggered with a
programmatic click on an associated label
https://bugs.webkit.org/show_bug.cgi?id=309082
rdar://171635705
Reviewed by Lily Spiniolas, Wenson Hsieh, and Abrar Rahman Protyasha.
288403@main ensured that haptic feedback for <input type=checkbox switch>
required
user activation. However, it is also desired that haptics are only
triggered for
trusted events. This goal can currently be bypassed by calling `click()` on
a label
associated with the input. The result is that calling `click()` on the
label,
immediately following a user gesture, can allow for haptics to be
programmatically
triggered.
The underlying issue is that untrusted click events on label elements become
trusted click events on the associated control. This is because
`Element::dispatchSimulatedClick` unconditionally sets
`SimulatedClickSource::UserAgent`.
While this is desirable for accessibility use cases, it is incorrect when
the
underlying event is untrusted.
Fix by specifying `SimulatedClickSource::Bindings` if there is an underlying
event and it is untrusted.
Tests: fast/forms/label/label-click-event-dispatch-untrusted.html
Tools/TestWebKitAPI/Tests/WebKitCocoa/SwitchInputTests.mm
*
LayoutTests/fast/forms/label/label-click-event-dispatch-untrusted-expected.txt:
Added.
* LayoutTests/fast/forms/label/label-click-event-dispatch-untrusted.html:
Added.
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::dispatchSimulatedClick):
If there is an underlying event, the simulated click should be marked as
from
"bindings", making it untrusted. This change is not made to `simulateClick`
itself
since that is used by `Element::click()`, which has no underlying event and
is
always untrusted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SwitchInputTests.mm:
(TEST(SwitchInputTests, HapticFeedbackOnClick)):
Add a test to verify that haptics are still triggered for a trusted click.
(TEST(SwitchInputTests, HapticFeedbackRequiresUserGestureAndTrustedEvent)):
Update the `HapticFeedbackRequiresUserGesture` test to also perform a user
gesture, and ensure haptics cannot be triggered programmatically.
(TEST(SwitchInputTests, HapticFeedbackRequiresUserGesture)): Deleted.
Identifier: 305413.395@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.504@webkitglib/2.52
Commit: 4cc26452c9a257db6d3539b144a2d6277398cb1d
https://github.com/WebKit/WebKit/commit/4cc26452c9a257db6d3539b144a2d6277398cb1d
Author: David Kilzer <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/mac/WebPageProxyMac.mm
Log Message:
-----------
Cherry-pick 305413.397@safari-7624-branch (79f65b10f8d8).
https://bugs.webkit.org/show_bug.cgi?id=309108
WebPageProxy crash in dispatchSetObscuredContentInsets() and
clearTextIndicatorWithAnimation()
<https://bugs.webkit.org/show_bug.cgi?id=309108>
<rdar://167427221>
Reviewed by Anne van Kesteren.
Crashes occur when a `WebPageProxy` object is destroyed when a `WeakPtr`
is used to make a method call since it doesn't keep the object alive.
Promote unsafe `WeakPtr<WebPageProxy>` usage to `RefPtr<WebPageProxy` to
ensure the object stays alive for the duration of the method call. Also
promote `WeakPtr<WebProcessProxy>` in completion callbacks where the
process object could be destroyed during sandbox extension processing.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::loadSimulatedRequest):
(WebKit::WebPageProxy::loadAlternateHTML):
(WebKit::WebPageProxy::reload):
(WebKit::WebPageProxy::executeEditCommand):
(WebKit::WebPageProxy::contextMenuItemSelected):
* Source/WebKit/UIProcess/mac/WebPageProxyMac.mm:
(WebKit::WebPageProxy::didPerformDictionaryLookup):
(WebKit::WebPageProxy::scheduleSetObscuredContentInsetsDispatch):
Identifier: 305413.397@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.505@webkitglib/2.52
Commit: 38e0495846f0bfbe71f8a0cf21c56e70f2061a5e
https://github.com/WebKit/WebKit/commit/38e0495846f0bfbe71f8a0cf21c56e70f2061a5e
Author: Yusuke Suzuki <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/JavaScriptCore/yarr/RegularExpression.cpp
M Tools/TestWebKitAPI/CMakeLists.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/JavaScriptCore/RegularExpression.cpp
Log Message:
-----------
Cherry-pick 305413.398@safari-7624-branch (86cffcf010ab).
https://bugs.webkit.org/show_bug.cgi?id=308707
[JSC] YARR RegularExpression heap overflow - duplicate named capture groups
https://bugs.webkit.org/show_bug.cgi?id=308707
rdar://171240602
Reviewed by Keith Miller.
RegularExpression's offsets vector allocation size is incorrect: that
formula was updated when named captures are added, but
RegularExpression's computation was not updated correctly. This patch
fixes it.
Tests: Tools/TestWebKitAPI/CMakeLists.txt
Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
Tools/TestWebKitAPI/Tests/JavaScriptCore/RegularExpression.cpp
* Source/JavaScriptCore/yarr/RegularExpression.cpp:
(JSC::Yarr::RegularExpression::match const):
* Tools/TestWebKitAPI/CMakeLists.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/JavaScriptCore/RegularExpression.cpp: Added.
(TestWebKitAPI::TEST(JavaScriptCore_RegularExpression,
DuplicateNamedCaptureGroupSimple)):
(TestWebKitAPI::TEST(JavaScriptCore_RegularExpression,
DuplicateNamedCaptureGroupMultiple)):
(TestWebKitAPI::TEST(JavaScriptCore_RegularExpression,
DuplicateNamedCaptureGroupNoMatch)):
(TestWebKitAPI::TEST(JavaScriptCore_RegularExpression,
DuplicateNamedCaptureGroupSearchRev)):
Identifier: 305413.398@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.506@webkitglib/2.52
Commit: 824d13f1f428de98f19fefb65880b0a3e3c1b47b
https://github.com/WebKit/WebKit/commit/824d13f1f428de98f19fefb65880b0a3e3c1b47b
Author: Gerald Squelart <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WebCore/animation/StyleOriginatedTimelinesController.cpp
Log Message:
-----------
Cherry-pick 305413.400@safari-7624-branch (a8304e8264d0).
https://bugs.webkit.org/show_bug.cgi?id=308707
StyleOriginatedTimelinesController::documentDidResolveStyle: Use removeIf
rdar://171096572
Reviewed by Tim Horton.
To avoid invalidating the loop iterator by removing the current element,
use HashMap::removeIf to correctly remove elements whose timeline have
become empty.
* Source/WebCore/animation/StyleOriginatedTimelinesController.cpp:
(WebCore::StyleOriginatedTimelinesController::documentDidResolveStyle):
Identifier: 305413.400@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.507@webkitglib/2.52
Commit: 5f2edbc0d76694e21300425e9b52bff23655ad84
https://github.com/WebKit/WebKit/commit/5f2edbc0d76694e21300425e9b52bff23655ad84
Author: Gerald Squelart <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WebCore/platform/graphics/PixelBufferConversion.cpp
Log Message:
-----------
Cherry-pick 305413.404@safari-7624-branch (790d8fc2d3b4).
https://bugs.webkit.org/show_bug.cgi?id=308707
Check Float16 buffer sizes before conversion
rdar://169442684
Reviewed by Mike Wyrzykowski.
Check that Float16 buffers are large enough to fit the expected amount
of data to be read/written by convertImagePixels() and subroutines.
* Source/WebCore/platform/graphics/PixelBufferConversion.cpp:
(WebCore::convertImagePixels):
Identifier: 305413.404@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.508@webkitglib/2.52
Commit: b156190d9ea698c104e7df5cba288f05fb2017b4
https://github.com/WebKit/WebKit/commit/b156190d9ea698c104e7df5cba288f05fb2017b4
Author: Timothy Hatcher <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WebKit/UIProcess/Extensions/WebExtensionContext.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIScripting.mm
Log Message:
-----------
Cherry-pick 305413.426@safari-7624-branch (7f6a77dee81b).
https://bugs.webkit.org/show_bug.cgi?id=309516
Extension scripts/style sheets are injected into denied domains if Other
Websites are set to allow.
https://webkit.org/b/309516
rdar://171724038
Reviewed by Brian Weinstein.
During Objective-C++ to C++ conversion, NSMutableSet's unionSet: (modifies
in place) was incorrectly
translated to HashSet::unionWith() (returns new set). Changed to addAll()
to match original semantics.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIScripting.mm
* Source/WebKit/UIProcess/Extensions/WebExtensionContext.cpp:
(WebKit::WebExtensionContext::addInjectedContent): Use addAll() instead of
unionWith().
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIScripting.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIScripting,
ContentScriptsRespectDeniedMatchPatterns)): Added.
Identifier: 305413.426@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.509@webkitglib/2.52
Commit: d68285a796d6f6dbafc0ba1f97539f3c6c174792
https://github.com/WebKit/WebKit/commit/d68285a796d6f6dbafc0ba1f97539f3c6c174792
Author: Darryl Parkinson <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
M Tools/WebKitTestRunner/TestController.cpp
M Tools/WebKitTestRunner/TestOptions.cpp
M Tools/WebKitTestRunner/TestOptions.h
Log Message:
-----------
Cherry-pick 305413.421@safari-7624-branch (44da09d437d9).
https://bugs.webkit.org/show_bug.cgi?id=309516
Gate AddOriginAccessAllowListEntry IPC behind AllowTestOnlyIPC
rdar://171243270
Reviewed by Charlie Wolfe and Ryosuke Niwa.
Origin access allowlist IPC messages on NetworkConnectionToWebProcess
modify a process-global allowlist with no validation, allowing a
compromised WebContent process to bypass CORS for all connections.
These messages are only used by TestRunner SPI. Gate them behind
EnabledBy=AllowTestOnlyIPC so they are rejected unless the test-only
flag is set.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
(AddOriginAccessAllowListEntryRequiresTestOnlyIPC)):
(AddOriginAccessAllowListEntryAllowedWithTestOnlyIPC)):
* Tools/WebKitTestRunner/TestController.cpp:
(WTR::TestController::resetPreferencesToConsistentValues):
* Tools/WebKitTestRunner/TestOptions.cpp:
(WTR::TestOptions::defaults):
(WTR::TestOptions::keyTypeMapping):
* Tools/WebKitTestRunner/TestOptions.h:
(WTR::TestOptions::allowTestOnlyOriginAccessAllowListIPC const):
Identifier: 305413.421@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.510@webkitglib/2.52
Commit: 4e802b153d9bbd8e2b9c6578b22f0501a7690406
https://github.com/WebKit/WebKit/commit/4e802b153d9bbd8e2b9c6578b22f0501a7690406
Author: Pascoe <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebRemoteFrameClient.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SiteIsolation.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/VerifyUserGestureFromUIProcess.mm
Log Message:
-----------
Cherry-pick 305413.427@safari-7624-branch (e7c824391cd2).
https://bugs.webkit.org/show_bug.cgi?id=309184
Same user gesture can be used for both opening a window and focussing
previous one
rdar://168506684
https://bugs.webkit.org/show_bug.cgi?id=309184
Reviewed by Ryosuke Niwa.
chrome().focus() sends SetFocus(true) to the UIProcess with no user gesture
context. A common client consuming the _WKUserInitiatedAction during popup
creation (in createWebViewWithConfiguration) has no way to prevent a
subsequent
focus of an existing window from the same gesture — the focus path bypasses
the
consumed check entirely.
To fix this, we plumb UserGestureTokenIdentifier through SetFocus and
FocusRemoteFrame IPC so setFocus() can look up the API::UserInitiatedAction
and
skip the focus if already consumed.
Test:
Tools/TestWebKitAPI/Tests/WebKitCocoa/VerifyUserGestureFromUIProcess.mm
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::setFocus):
(WebKit::WebPageProxy::focusRemoteFrame):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::focus):
(WebKit::WebChromeClient::unfocus):
* Source/WebKit/WebProcess/WebCoreSupport/WebRemoteFrameClient.cpp:
(WebKit::WebRemoteFrameClient::focus):
(WebKit::WebRemoteFrameClient::unfocus):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SiteIsolation.mm:
(TestWebKitAPI::TEST(SiteIsolation, PopunderPreventedByConsumedAction)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/VerifyUserGestureFromUIProcess.mm:
(TestWebKitAPI::TEST(VerifyUserGesture, PopunderPreventedByConsumedAction)):
Identifier: 305413.427@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.511@webkitglib/2.52
Commit: 2935a3518a2f62765b368d82ed77e4bcefb55ba6
https://github.com/WebKit/WebKit/commit/2935a3518a2f62765b368d82ed77e4bcefb55ba6
Author: Youenn Fablet <[email protected]>
Date: 2026-05-16 (Sat, 16 May 2026)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/acm_random.h
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/encode_api_test.cc
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_pickmode.c
Log Message:
-----------
Cherry-pick 305413.428@safari-7624-branch (b29ab81cd8b0).
https://bugs.webkit.org/show_bug.cgi?id=309184
Potential 'overflow' issue committed to upstream libwebrtc
rdar://171591550
Reviewed by Jean-Yves Avenard.
Cherry-picking of
https://github.com/webmproject/libvpx/commit/ab5ec7a1852f634b81d29ade3c5fa74056498973,
given WebKit uses that code path.
Identifier: 305413.428@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.512@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/7be2e7352727...2935a3518a2f
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
