Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: fa063c4341847c2e191141bf227ab72f72b26e11
https://github.com/WebKit/WebKit/commit/fa063c4341847c2e191141bf227ab72f72b26e11
Author: Charlie Wolfe <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A
LayoutTests/http/tests/security/contentSecurityPolicy/iframe-srcdoc-import-bypass-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/iframe-srcdoc-import-bypass.html
A
LayoutTests/http/tests/security/contentSecurityPolicy/resources/module-pass.py
M
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/inheritance-from-initiator.sub-expected.txt
M Source/WebCore/loader/DocumentWriter.cpp
Log Message:
-----------
Cherry-pick 305413.3@safari-7624-branch (ffc8c894635c).
https://bugs.webkit.org/show_bug.cgi?id=304951
Fix CSP bypass in sandboxed srcdoc iframes
https://bugs.webkit.org/show_bug.cgi?id=304951
rdar://154201938
Reviewed by Ryan Reno and Pascoe.
Only inherit the policy container from history item during back/forward
navigations. Previously, iframes
without an initial srcdoc attribute could bypass CSP when srcdoc was set
dynamically because they
incorrectly inherited from history instead of from the actual initiator.
Test:
http/tests/security/contentSecurityPolicy/iframe-srcdoc-import-bypass.html
*
LayoutTests/http/tests/security/contentSecurityPolicy/iframe-srcdoc-import-bypass-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/iframe-srcdoc-import-bypass.html:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/resources/module-pass.py:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/inheritance-from-initiator.sub-expected.txt:
* Source/WebCore/loader/DocumentWriter.cpp:
(WebCore::DocumentWriter::begin):
Identifier: 305413.3@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.261@webkitglib/2.52
Commit: 32becff2ee8f09a63ed1e9516bc8fd14b6b0bab2
https://github.com/WebKit/WebKit/commit/32becff2ee8f09a63ed1e9516bc8fd14b6b0bab2
Author: Timothy Hatcher <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/dom/Element.h
M Source/WebCore/editing/markup.h
M Source/WebCore/html/HTMLImageElement.h
M Source/WebCore/loader/archive/cf/LegacyWebArchive.cpp
M Source/WebCore/page/PageSerializer.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm
Log Message:
-----------
Cherry-pick 305413.31@safari-7624-branch (31eb1554d216).
https://bugs.webkit.org/show_bug.cgi?id=304155
safari-web-extension url masking bypass.
https://webkit.org/b/304155
rdar://problem/166499973
Reviewed by Chris Dumez.
Audited remaining ResolveURLs::No and ResolveURLs::Yes uses, and changed to
ExcludingURLsForPrivacy
versions to catch places where extension URLs could be returned unmasked
including XMLSerializer.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm
* Source/WebCore/dom/Element.h:
* Source/WebCore/editing/markup.h:
(WebCore::serializeFragment):
* Source/WebCore/html/HTMLImageElement.h:
* Source/WebCore/loader/archive/cf/LegacyWebArchive.cpp:
(WebCore::LegacyWebArchive::createInternal):
(WebCore::LegacyWebArchive::createFromSelection):
* Source/WebCore/page/PageSerializer.cpp:
(WebCore::PageSerializer::SerializerMarkupAccumulator::SerializerMarkupAccumulator):
* Source/WebCore/xml/XMLSerializer.cpp:
(WebCore::XMLSerializer::serializeToString):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm:
(TEST(WebKit, ConfigurationMaskedURLSchemes)): Added XMLSerializer tests.
Identifier: 305413.31@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.262@webkitglib/2.52
Commit: c5344a6c2e67df94ca66092dbcc3a51adf66d601
https://github.com/WebKit/WebKit/commit/c5344a6c2e67df94ca66092dbcc3a51adf66d601
Author: Frédéric Wang <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A
LayoutTests/fast/dom/Document/open-triggered-by-mutation-observer-on-element-from-a-parsed-doc-crash-expected.txt
A
LayoutTests/fast/dom/Document/open-triggered-by-mutation-observer-on-element-from-a-parsed-doc-crash.html
Log Message:
-----------
Cherry-pick [email protected] (cb9035f59bbb).
https://bugs.webkit.org/show_bug.cgi?id=300372
[WebKit][Main+SU?] [a3b9e8b1b7c6c7b7] ASAN_SEGV | WebCore::firstDOMWindow;
WebCore::jsDocumentPrototypeFunction_write; ADDRESS
https://bugs.webkit.org/show_bug.cgi?id=300372
Reviewed by Ryosuke Niwa.
Add a regression test for [1], which was later reverted in [2].
[1] https://commits.webkit.org/300757@main
[2] https://commits.webkit.org/300886@main
*
LayoutTests/fast/dom/Document/open-triggered-by-mutation-observer-on-element-from-a-parsed-doc-crash-expected.txt:
Added.
*
LayoutTests/fast/dom/Document/open-triggered-by-mutation-observer-on-element-from-a-parsed-doc-crash.html:
Added.
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 301765.295@safari-7623-branch
Identifier: 305413.77@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.263@webkitglib/2.52
Commit: 511919d9e1ba49df0a544c1a7e15591794c6aad2
https://github.com/WebKit/WebKit/commit/511919d9e1ba49df0a544c1a7e15591794c6aad2
Author: Simon Lewis <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/http/tests/security/registerBlobURL-expected.txt
A LayoutTests/http/tests/security/registerBlobURL.html
M LayoutTests/platform/mac/TestExpectations
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 305413.85@safari-7624-branch (1dfe7a1fcb33).
https://bugs.webkit.org/show_bug.cgi?id=305353
NetworkConnectionToWebProcess::registerInternalFileBlobURL should check
whether accessing replacementPath is allowed or not
https://bugs.webkit.org/show_bug.cgi?id=305353
rdar://134025127
Reviewed by Per Arne Vollan and Chris Dumez.
Adding a MESSAGE_CHECK for parameter: replacementPath.
* LayoutTests/TestExpectations:
* LayoutTests/http/tests/security/registerBlobURL-expected.txt: Added.
* LayoutTests/http/tests/security/registerBlobURL.html: Added.
* LayoutTests/platform/mac/TestExpectations:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::registerInternalFileBlobURL):
Identifier: 305413.85@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.264@webkitglib/2.52
Commit: ecf3b859b0e021c918a1075d2d072f3fbd3e6b05
https://github.com/WebKit/WebKit/commit/ecf3b859b0e021c918a1075d2d072f3fbd3e6b05
Author: Anthony Tarbinian <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/loader/CrossOriginPreflightChecker.cpp
M Source/WebCore/loader/DocumentThreadableLoader.cpp
Log Message:
-----------
Cherry-pick 301765.317@safari-7623-branch (f6b5d41d0e82).
https://bugs.webkit.org/show_bug.cgi?id=301373
[WebCore] Check for liveliness before dereferencing m_document WeakPtr in
DocumentThreadableLoader
https://bugs.webkit.org/show_bug.cgi?id=301373
rdar://161561780
Reviewed by Ryosuke Niwa.
This patch adds liveliness checks for dereferencing a WeakPtr
in WebCore::DocumentThreadableLoader.
Previously the `m_document` `WeakPtr` was dereferenced by calling
the `document()` or `protectedDocument()` member functions.
Since it's possible for the `WeakPtr` `m_document` to be null, we
should add checks before dereferencing it to avoid hitting
a RELEASE_ASSERT in `WeakPtr`'s * operator. To ensure that
m_document is kept alive after performing the null check,
we convert it to a `RefPtr`.
* Source/WebCore/loader/CrossOriginPreflightChecker.cpp:
(WebCore::CrossOriginPreflightChecker::validatePreflightResponse):
(WebCore::CrossOriginPreflightChecker::notifyFinished):
(WebCore::CrossOriginPreflightChecker::startPreflight):
(WebCore::CrossOriginPreflightChecker::doPreflight):
* Source/WebCore/loader/DocumentThreadableLoader.cpp:
(WebCore::DocumentThreadableLoader::shouldSetHTTPHeadersToKeep const):
(WebCore::DocumentThreadableLoader::makeCrossOriginAccessRequest):
(WebCore::DocumentThreadableLoader::cancel):
(WebCore::DocumentThreadableLoader::didReceiveResponse):
(WebCore::DocumentThreadableLoader::didFail):
(WebCore::DocumentThreadableLoader::preflightFailure):
(WebCore::DocumentThreadableLoader::loadRequest):
(WebCore::DocumentThreadableLoader::securityOrigin const):
(WebCore::DocumentThreadableLoader::topOrigin const):
(WebCore::DocumentThreadableLoader::contentSecurityPolicy const):
(WebCore::DocumentThreadableLoader::crossOriginEmbedderPolicy const):
(WebCore::DocumentThreadableLoader::logErrorAndFail):
(WebCore::DocumentThreadableLoader::protectedDocument): Deleted.
* Source/WebCore/loader/DocumentThreadableLoader.h:
(WebCore::DocumentThreadableLoader::document): Deleted.
Identifier: 301765.317@safari-7623-branch
Identifier: 305413.89@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.265@webkitglib/2.52
Commit: d9f1c30056c57860cddcb3e1032074ab6b6a1c79
https://github.com/WebKit/WebKit/commit/d9f1c30056c57860cddcb3e1032074ab6b6a1c79
Author: Brandon Stewart <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/Modules/compression/ZStream.cpp
M Source/WebCore/Modules/compression/ZStream.h
Log Message:
-----------
Cherry-pick 301765.318@safari-7623-branch (f0c4a925385f).
https://bugs.webkit.org/show_bug.cgi?id=302216
ZStream: deflateEnd() called after inflateInit2() via DecompressionStream →
invalid free (UB/crash)
https://bugs.webkit.org/show_bug.cgi?id=302216
rdar://164363410
Reviewed by Chris Dumez.
Ensure that we properly select inflateEnd vs deflateEnd when closing a
stream.
No new test because I was not able to get this to crash locally, but it is
the correct fix.
* Source/WebCore/Modules/compression/ZStream.cpp:
(WebCore::ZStream::initializeIfNecessary):
(WebCore::ZStream::~ZStream):
* Source/WebCore/Modules/compression/ZStream.h:
Identifier: 301765.318@safari-7623-branch
Identifier: 305413.113@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.266@webkitglib/2.52
Commit: f31f79e95f7be8912e7fdca09dea4b344b33c30c
https://github.com/WebKit/WebKit/commit/f31f79e95f7be8912e7fdca09dea4b344b33c30c
Author: Timothy Hatcher <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Cherry-pick 305413.117@safari-7624-branch (a1d9944acf9d).
https://bugs.webkit.org/show_bug.cgi?id=306036
REGRESSION(305413.31@safari-7624-branch): Broke
editing/pasteboard/img-srcset-copy-paste-canonicalization.html
https://webkit.org/b/306036
rdar://168512100
Reviewed by Brian Weinstein.
ResolveURLs::YesExcludingURLsForPrivacy was incorrectly not completing file
URLs
like ResolveURLs::Yes does. Drop the extra branch to match Yes.
* LayoutTests/TestExpectations: Remove Failure exception.
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::resolveURLStringIfNeeded const):
Identifier: 305413.117@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.267@webkitglib/2.52
Commit: 367bcdd137c5d9456df72254e41ce49e7d8b1848
https://github.com/WebKit/WebKit/commit/367bcdd137c5d9456df72254e41ce49e7d8b1848
Author: Rupin Mittal <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/page/Navigation.cpp
M Tools/TestWebKitAPI/SourcesCocoa.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKitCocoa/NavigationAPI.mm
Log Message:
-----------
Cherry-pick 305413.125@safari-7624-branch (67e3366c7a2c).
https://bugs.webkit.org/show_bug.cgi?id=306050
[Navigation API] intercept() wrongly succeeds for cross-subdomain
navigations
https://bugs.webkit.org/show_bug.cgi?id=306050
rdar://165690775
Reviewed by Alex Christensen.
Consider that we have two sites that differ in subdomain:
1. page1.example.com
2. page2.example.com
If we navigate from page1 to page2, page1 should not be able to intercept
the
navigation because this is a cross-origin navigation. Our bug is that
currently,
the intercept succeeds.
How it's supposed to work:
One of the steps in firing a navigate event says:
(Step 9 in
https://html.spec.whatwg.org/multipage/nav-history-apis.html#inner-navigate-event-firing-algorithm)
"If document can have its URL rewritten to destination's URL, and either
destination's is same document is true or navigationType is not "traverse",
then
initialize event's canIntercept to true. Otherwise, initialize it to false."
One of the steps for checking if the URL can be rewritten to destination's
URL is:
(https://html.spec.whatwg.org/multipage/nav-history-apis.html#can-have-its-url-rewritten)
"If targetURL and documentURL differ in their scheme, username, password,
host,
or port components, then return false."
Our two URLs differ in host. so canIntercept should be set to false.
Later on, when intercept() is called, it should fail because it's steps say:
(https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-navigateevent-intercept)
"If this's canIntercept attribute was initialized to false, then throw a
"SecurityError" DOMException."
What's wrong:
Our issue is that the "can-have-its-url-rewritten" check returns true, so
canIntercept is set to true and later on the intercept succeeds. The check
is
implemented incorrectly. Instead of checking if the URLS differ in scheme,
username, password, host, or port components, it simply does:
bool isSameSite = documentOrigin->isSameSiteAs(targetOrigin);
bool isSameOrigin = documentOrigin->isSameOriginAs(targetOrigin);
if (!isSameSite && !isSameOrigin)
return false;
For our two URLs, isSameSite is true, so this check doesn't return false as
it
should. Also this check never compares the usernames and passwords. This
means
that not only does the cross-origin check fail in the case of URLs that
differ by
subdomain but it will also fail for URLs that differ in username and
password.
We fix this by changing to check to follow the spec. We also add new API
tests for
both the subdomain and username/password cases.
* Source/WebCore/page/Navigation.cpp:
(WebCore::documentCanHaveURLRewritten):
* Tools/TestWebKitAPI/SourcesCocoa.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/NavigationAPI.mm: Added.
(TestWebKitAPI::TEST(NavigationAPI, InterceptFailsForDifferentSubdomain)):
(TestWebKitAPI::TEST(NavigationAPI,
InterceptFailsForDifferentUsernameAndPassword)):
Identifier: 305413.125@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.268@webkitglib/2.52
Commit: fce7de4c807dc806921edce189dffa5a739a5329
https://github.com/WebKit/WebKit/commit/fce7de4c807dc806921edce189dffa5a739a5329
Author: Kai Tamkun <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A JSTests/wasm/stress/call-indirect-exceptions.js
M Source/JavaScriptCore/llint/InPlaceInterpreter32_64.asm
M Source/JavaScriptCore/llint/InPlaceInterpreter64.asm
Log Message:
-----------
Cherry-pick 305413.149@safari-7624-branch (63358b77f417).
https://bugs.webkit.org/show_bug.cgi?id=305148
[JSC] Delay PC advancement until after operationCallMayThrow in IPInt
https://bugs.webkit.org/show_bug.cgi?id=305148
rdar://166602356
Reviewed by Yusuke Suzuki.
Currently, some IPInt instructions will advance the PC before invoking
operationCallMayThrow. Because that invocation will save the call site
index,
this means that the call site index of the next instruction will be saved
instead of the call site index of the instruction currently being executed.
If the call does throw, it will then choose a handler based on the index of
the next instruction. Therefore, it's necessary to move the PC advancement
instructions past the invocation of operationCallMayThrow.
An earlier iteration of this PR was reverted for accidental register
clobbering
on x86_64, which manifested as a crash. This version of the PR uses t3 (rcx)
instead of t2 (rdx) to avoid clobbering one of the return values of the
preceding calls.
Test: JSTests/wasm/stress/call-indirect-exceptions.js
* JSTests/wasm/stress/call-indirect-exceptions.js: Added.
(async test): Tests that exceptions are properly handled.
* Source/JavaScriptCore/llint/InPlaceInterpreter32_64.asm: Delay PC
advancement
* Source/JavaScriptCore/llint/InPlaceInterpreter64.asm: Delay PC advancement
Identifier: 305413.149@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.269@webkitglib/2.52
Commit: edce9ee6725347e4970cabd89b9715887f370e98
https://github.com/WebKit/WebKit/commit/edce9ee6725347e4970cabd89b9715887f370e98
Author: David Kilzer <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/workers/service/server/SWServer.cpp
Log Message:
-----------
Cherry-pick 305413.160@safari-7624-branch (561472a83605).
https://bugs.webkit.org/show_bug.cgi?id=305878
Crash in SWServer::unregisterServiceWorkerClient() when client doesn't exist
<https://bugs.webkit.org/show_bug.cgi?id=305878>
<rdar://154918456>
Reviewed by Youenn Fablet and Chris Dumez.
A crash in SWServer::unregisterServiceWorkerClientInternal() occurred
when clientRegistrableDomain was not found in
m_clientsByRegistrableDomain.
Fix this by adding an iterator check for end(), and skipping code that
used the iterator when that was true. We also add an iterator end()
check in a second place in the same method.
No test since this is a race condition with no known steps to reproduce.
However, a similar crash was reproduced temporarily by adding code to
call SWServer::unregisterServiceWorkerClient() twice.
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::unregisterServiceWorkerClientInternal):
- Add end() checks for iterators and skip code that assumed a match was
found.
(WebCore::SWServer::unregisterServiceWorkerClient):
- Add comment that we're purposely calling
unregisterServiceWorkerClientInternal() when the client identifier is
not found in case maps get out-of-sync.
Identifier: 305413.160@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.270@webkitglib/2.52
Commit: a525b3aca074c553313c517ec51b7f5bc9d6f2e7
https://github.com/WebKit/WebKit/commit/a525b3aca074c553313c517ec51b7f5bc9d6f2e7
Author: Vassili Bykov <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A JSTests/wasm/stress/resizable-buffer-grow-view-refresh.js
M Source/JavaScriptCore/runtime/ArrayBuffer.cpp
M Source/JavaScriptCore/runtime/JSArrayBufferView.h
M Source/JavaScriptCore/runtime/JSArrayBufferViewInlines.h
Log Message:
-----------
Cherry-pick 305413.190@safari-7624-branch (59c4a7a31ef6).
https://bugs.webkit.org/show_bug.cgi?id=306136
[JSC] Use-after-free after growing a resizable buffer on a WebAssembly
memory
https://bugs.webkit.org/show_bug.cgi?id=306136
rdar://167095753
Reviewed by Yijia Huang.
This issue is related to earlier work on WebAssembly memory buffers. As
part of that work, it became
possible for an ArrayBuffer's underlying storage to change its location in
memory as a result of
growing. To deal with this change, two methods were introduced:
ArrayBuffer::refreshAfterMemoryGrow
and ArrayBufferContents::refreshAfterMemoryGrow. However:
1. ArrayBufferContents::refreshAfterMemoryGrow does not update the m_data
field, which is a direct
pointer to the memory base.
2. Refreshing array buffer objects is not enough because a
JSArrayBufferView has its own direct
pointer into the underlying buffer's data (m_vector).
The patch makes the following changes to address this:
* Source/JavaScriptCore/runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::refreshAfterWasmMemoryGrow):
If the buffer location in memory changes as a result of growing,
uses incoming references of the buffer to notify the existing views of the
change.
* Source/JavaScriptCore/runtime/ArrayBuffer.cpp:
(JSC::ArrayBufferContents::refreshAfterWasmMemoryGrow):
Properly updates the m_data field.
* Source/JavaScriptCore/runtime/JSArrayBufferView.h:
* Source/JavaScriptCore/runtime/JSArrayBufferViewInlines.h:
A new method 'refreshVector' is added to be used by
ArrayBuffer::refreshAfterWasmMemoryGrow.
Test: JSTests/wasm/stress/resizable-buffer-grow-view-refresh.js
Identifier: 305413.190@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.271@webkitglib/2.52
Commit: c636d82549c48f5fe2b46a347be72a6f4b43c61f
https://github.com/WebKit/WebKit/commit/c636d82549c48f5fe2b46a347be72a6f4b43c61f
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp
M Source/WebKit/Shared/WebGL.serialization.in
Log Message:
-----------
Cherry-pick 305413.206@safari-7624-branch (d593ad8b45c3).
https://bugs.webkit.org/show_bug.cgi?id=306323
WebGL: GPUP should expose draft extension related extensions only if the
setting is on
https://bugs.webkit.org/show_bug.cgi?id=306323
rdar://166537204
Reviewed by Dan Glastonbury.
Expose ANGLE extensions related to WebGL draft extensions only if
the setting is on.
Add the GraphicsContextGLAttributes.supportWebGLDraftExtensions property
since that is what controls the GraphicsContextGLANGLE. Validate this
property against the real settings.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::resolveGraphicsContextGLAttributes):
(WebCore::WebGLRenderingContextBase::create):
* Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h:
* Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp:
(WebCore::GraphicsContextGLANGLE::initialize):
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp:
(WebKit::GPUConnectionToWebProcess::createGraphicsContextGL):
* Source/WebKit/Shared/WebGL.serialization.in:
Identifier: 305413.206@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.272@webkitglib/2.52
Commit: 9704d447b5c5a07f352e28a9f5416cefdf04e542
https://github.com/WebKit/WebKit/commit/9704d447b5c5a07f352e28a9f5416cefdf04e542
Author: Vassili Bykov <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/JavaScriptCore/wasm/js/WebAssemblyGCStructure.cpp
Log Message:
-----------
Cherry-pick 305413.210@safari-7624-branch (f0eba4757433).
https://bugs.webkit.org/show_bug.cgi?id=306479
[JSC] `WebAssemblyGCStructureTypeDependencies::process` should traverse
expanded types
https://bugs.webkit.org/show_bug.cgi?id=306479
rdar://165898811
Reviewed by Yusuke Suzuki.
The patch changes WebAssemblyGCStructureTypeDependencies::process so that
the type added to the work
list is the effective (expanded) type of a field. Without the patch, if the
type is a Subtype, the
effective type is not reached and never scanned for dependencies.
Testing: not testable directly. The original steps to reproduce require a
Debug+ASan build with a
special diagnostic patch applied to StructParameterTypes::equal().
Identifier: 305413.210@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.273@webkitglib/2.52
Commit: 049c589878e343dfd13132abef2c9e709a929ee3
https://github.com/WebKit/WebKit/commit/049c589878e343dfd13132abef2c9e709a929ee3
Author: David Kilzer <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/boringssl/src/include/openssl/asm_base.h
Log Message:
-----------
Cherry-pick 305413.211@safari-7624-branch (718d5fa2ffc3).
https://bugs.webkit.org/show_bug.cgi?id=306486
[boringssl] Fix .note.gnu.property section emission on non-ELF platforms
<https://bugs.webkit.org/show_bug.cgi?id=306486>
<rdar://168952064>
Reviewed by Matthew Finkel.
Bug 303938 enabled PAC (return address signing) for boringssl by adding
`-mbranch-protection=pac-ret+b-key` flags to ARM64 assembly files. This
caused a `.note.gnu.property` section to be emitted on all platforms,
including Apple/Mach-O targets where it's invalid and caused crashes in
ktrace/libtrace.
The root cause is that boringssl's `asm_base.h` lacks an `__ELF__` guard
around the `.note.gnu.property` section emission.
No new tests since this change is not directly testable.
*
Source/ThirdParty/libwebrtc/Source/third_party/boringssl/src/include/openssl/asm_base.h:
Identifier: 305413.211@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.274@webkitglib/2.52
Commit: 9d819f2219f3c7cca40ed87f7557bd74efa3bcb5
https://github.com/WebKit/WebKit/commit/9d819f2219f3c7cca40ed87f7557bd74efa3bcb5
Author: Kristian Monsen <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WTF/wtf/Vector.h
Log Message:
-----------
Cherry-pick 305413.213@safari-7624-branch (51da13afbf99).
https://bugs.webkit.org/show_bug.cgi?id=305884
Upgrade vector.grow() assert to release assert
https://bugs.webkit.org/show_bug.cgi?id=305884
rdar://168546677
Reviewed by Vitor Roriz and Alan Baradlay.
Making the assert a RELEASE_ assert means it is always protecting the user.
* Source/WTF/wtf/Vector.h:
(WTF::Malloc>::growImpl):
Identifier: 305413.213@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.275@webkitglib/2.52
Commit: 925aee5b2cf4c8b6ae9abb24f74d7e2a4558704e
https://github.com/WebKit/WebKit/commit/925aee5b2cf4c8b6ae9abb24f74d7e2a4558704e
Author: Yulun Wu <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-line-break-crash-6-expected.txt
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-line-break-crash-6.html
M
Source/WebCore/layout/formattingContexts/inline/InlineContentConstrainer.cpp
Log Message:
-----------
Cherry-pick 305413.232@safari-7624-branch (551e424600a5).
https://bugs.webkit.org/show_bug.cgi?id=306377
d[text-wrap] Fix crash in text-wrap-pretty due to index type confusion
https://bugs.webkit.org/show_bug.cgi?id=306377
<rdar://168927397>
Reviewed by Alan Baradlay.
The text-wrap-pretty algorithm was storing indices into the
breakOpportunities
array in InlineItemPosition::index, but this field expects inline item
indices.
This type confusion caused out-of-bounds access when hyphenation created
additional breaks.
This patch fixes the crash by:
1. Storing actual inline item indices (breakOpportunities[i]) instead of
breakOpportunities
array indices in state[].lineEnd
2. Adding bounds checking before accessing m_inlineItemList
3. Fixing unsigned integer underflow in hasEnoughItemsForNextLine check by
rewriting the comparison to use addition instead of subtraction
*
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-line-break-crash-6-expected.txt:
Added.
*
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-line-break-crash-6.html:
Added.
*
Source/WebCore/layout/formattingContexts/inline/InlineContentConstrainer.cpp:
(WebCore::Layout::InlineContentConstrainer::layoutSingleLineForPretty):
(WebCore::Layout::InlineContentConstrainer::prettifyRange):
Identifier: 305413.232@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.276@webkitglib/2.52
Commit: f4fa0b616a94d3b610c363d66ccc84f56d1d14a7
https://github.com/WebKit/WebKit/commit/f4fa0b616a94d3b610c363d66ccc84f56d1d14a7
Author: Vassili Bykov <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A JSTests/wasm/regress/wasm-tag-retains-reachable-types.js
M Source/JavaScriptCore/wasm/WasmTag.h
M Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
M Source/JavaScriptCore/wasm/js/WebAssemblyGCStructure.cpp
M Source/JavaScriptCore/wasm/js/WebAssemblyGCStructure.h
Log Message:
-----------
Cherry-pick 305413.237@safari-7624-branch (5c551f153c01).
https://bugs.webkit.org/show_bug.cgi?id=306559
[JSC] JSWebAssemblyTag should retain FunctionSignature types
https://bugs.webkit.org/show_bug.cgi?id=306559
rdar://168041308
Reviewed by Marcus Plutowski.
This problem is similar to the problem from a few months ago with
WebAssemblyGCStructure not
retaining all TypeDefinitions it depends on. That problem was fixed by
introducing
WebAssemblyGCStructureTypeDependencies which holds a transitive closure of
all types reachable from
a given root type (a StructType or ArrayType). It is retained by a
WebAssemblyGCStructure to ensure
all reachable TypeDefinitions stay alive for as long as the structure can
reference them.
This patch adapts WebAssemblyGCStructureTypeDependencies to also ensure
that a Wasm::Tag retains all
TypeDefinitions reachable from its 'm_type' (a FunctionSignature).
Specifically:
- WebAssemblyGCStructureTypeDependencies is moved from
WebAssemblyGCStructure.h/.cpp to
WasmTypeDefinition.h/.cpp and renamed WebAssemblyGCTypeDependencies.
- The implementation is extended to traverse FunctionSignatures.
- An instance of WebAssemblyGCTypeDependencies is created and stored by
Wasm::Tag constructor to
capture all TypeDefinitions reachable from the tag's function signature.
Test: JSTests/wasm/regress/wasm-tag-retains-reachable-types.js
Identifier: 305413.237@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.277@webkitglib/2.52
Commit: bd533118036eda99636836957372976d01150555
https://github.com/WebKit/WebKit/commit/bd533118036eda99636836957372976d01150555
Author: Per Arne Vollan <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.h
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
Log Message:
-----------
Cherry-pick 305413.239@safari-7624-branch (b87ed58db51b).
https://bugs.webkit.org/show_bug.cgi?id=306827
The WebContent process should not start local files loads for files it
cannot access
https://bugs.webkit.org/show_bug.cgi?id=306827
rdar://168696983
Reviewed by Chris Dumez.
This will prevent local file loads from succeeding when the WebContent
process does not have access to the file,
but the Networking process does.
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:
(WebKit::NetworkResourceLoadParameters::createSandboxExtensionHandlesIfNecessary):
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.h:
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess):
Identifier: 305413.239@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.278@webkitglib/2.52
Commit: 657ace3d28f57eb78accb153ff9ccc0a32f0c2ee
https://github.com/WebKit/WebKit/commit/657ace3d28f57eb78accb153ff9ccc0a32f0c2ee
Author: Alex Christensen <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/page/UserMessageHandler.cpp
M Source/WebCore/page/UserMessageHandler.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEvaluateJavaScript.mm
Log Message:
-----------
Cherry-pick 305413.250@safari-7624-branch (c4006ba4ad2a).
https://bugs.webkit.org/show_bug.cgi?id=307014
UserMessageHandler.postMessage should fail if called from another frame
https://bugs.webkit.org/show_bug.cgi?id=307014
rdar://168617144
Reviewed by Chris Dumez.
Before this fix, a reference to the UserMessageHandler can be stored
outside the
frame, then the frame can be navigated, then the stored reference can be
used to
post messages that appeared to come from the navigated frame. This adds a
restriction
to make it so a UserMessageHandler can only be used by an origin that is
the same
as the frame's current origin.
I considered an alternative solution where I just make sure the global
objects are
the same, but that would be more of a restriction than this, and it's
normal for
frames to be able to access and use each other's JS objects when they are
in the same
origin, and this change is less drastic of a change.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEvaluateJavaScript.mm
* Source/WebCore/page/UserMessageHandler.cpp:
(WebCore::passesSameOriginCheck):
(WebCore::UserMessageHandler::postMessage):
(WebCore::UserMessageHandler::postLegacySynchronousMessage):
* Source/WebCore/page/UserMessageHandler.h:
(WebCore::UserMessageHandler::descriptor const):
(WebCore::UserMessageHandler::descriptor): Deleted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEvaluateJavaScript.mm:
(-[ScriptMessageHandlerThatShouldNotReceiveAnything
userContentController:didReceiveScriptMessage:]):
(TEST(WKWebView, MessageHandlerFromIframe)):
Identifier: 305413.250@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.279@webkitglib/2.52
Commit: a41e6bd278e306b9baeffa27e27967ae59808d02
https://github.com/WebKit/WebKit/commit/a41e6bd278e306b9baeffa27e27967ae59808d02
Author: Shu-yu Guo <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/JavaScriptCore/dfg/DFGValueRepReductionPhase.cpp
Log Message:
-----------
Cherry-pick 305413.251@safari-7624-branch (d2086e16a217).
https://bugs.webkit.org/show_bug.cgi?id=306986
[JSC] Escape MultiGetByOffset constants that aren't convertible to double
https://bugs.webkit.org/show_bug.cgi?id=306986
rdar://169245825
Reviewed by Yusuke Suzuki.
ValueRepReduction for doubles needs to eagerly convert constants in
MultiGetByoffset cases to doubles. This patch escapes MultiGetByOffset
constants that cannot be converted to doubles purely.
* Source/JavaScriptCore/dfg/DFGValueRepReductionPhase.cpp:
(JSC::DFG::ValueRepReductionPhase::convertValueRepsToUnboxed):
Identifier: 305413.251@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.280@webkitglib/2.52
Commit: db06e99e2bde09a0b624f20597431009e41ddc40
https://github.com/WebKit/WebKit/commit/db06e99e2bde09a0b624f20597431009e41ddc40
Author: Zak Ridouh <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/platform/graphics/Color.h
Log Message:
-----------
Cherry-pick 305413.270@safari-7624-branch (ff676342841b).
https://bugs.webkit.org/show_bug.cgi?id=306157
[MTE] Harden `WebCore::Color` and `WebCore::Color::OutOfLineComponents`
objects
<https://bugs.webkit.org/show_bug.cgi?id=306157>
<rdar://168435437>
Reviewed by Darin Adler.
`WebCore::Color` is made of a single field that contains flags in the upper
bits
and can eventually contain a pointer to an `OutOfLineComponents` as well.
This compact pointer is untagged by libpas, so we should manually clear it
to prevent any security issues if the Color object is Use After Free'd.
* Source/WebCore/platform/graphics/Color.h:
(WebCore::Color::~Color):
Identifier: 305413.270@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.281@webkitglib/2.52
Commit: 85d66aa6fc6ad69d9ac1c5f70e8716e691c7eb87
https://github.com/WebKit/WebKit/commit/85d66aa6fc6ad69d9ac1c5f70e8716e691c7eb87
Author: Frédéric Wang <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A
LayoutTests/fast/pdf-plugin-destruction-dispatches-print-event-crash-expected.txt
A LayoutTests/fast/pdf-plugin-destruction-dispatches-print-event-crash.html
M Source/WebCore/loader/DocumentLoader.cpp
Log Message:
-----------
Cherry-pick [email protected] (308756637681).
https://bugs.webkit.org/show_bug.cgi?id=303411
[WebKit][Main+SU] [fdae418b9cd3d6ba] WK_SEC |
WebCore::EventTarget::fireEventListeners;
WebCore::LocalDOMWindow::dispatchEvent; WebCore::dispatchPrintEvent
https://bugs.webkit.org/show_bug.cgi?id=303411
Reviewed by Ryosuke Niwa.
Document::updateStyleIfNeeded() forbids script execution in main thread
by creating a ScriptDisallowedScope. However, it can also trigger the
destruction of a PluginView, which may end up dispatching a print event,
triggering an assertion with security implication for
ScriptDisallowedScope::isScriptAllowedInMainThread(). In order to avoid
that issue, we ensure the print event is dispatched asynchronously.
Test: fast/pdf-plugin-destruction-dispatches-print-event-crash.html
*
LayoutTests/fast/pdf-plugin-destruction-dispatches-print-event-crash-expected.txt:
Added.
*
LayoutTests/fast/pdf-plugin-destruction-dispatches-print-event-crash.html:
Added.
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::removePlugInStreamLoader): Perform the load
completion check asynchronously, so that we don't execute any script in this
context.
Canonical link:
https://commits.webkit.org/[email protected]
Identifier: 305413.282@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.282@webkitglib/2.52
Commit: fa32d78c4b4110a26a387175f7cd01534bec2375
https://github.com/WebKit/WebKit/commit/fa32d78c4b4110a26a387175f7cd01534bec2375
Author: Rob Buis <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A LayoutTests/fast/loader/navigate-on-pageswap-crash-expected.txt
A LayoutTests/fast/loader/navigate-on-pageswap-crash.html
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebCore/page/Navigation.cpp
Log Message:
-----------
Cherry-pick [email protected] (7f4921b7e92c).
https://bugs.webkit.org/show_bug.cgi?id=303364
[WebKit][Main+SU] [3473ae787b8859f0] ASAN_SEGV |
WebCore::DocumentLoader::urlForHistory;
WebCore::HistoryController::updateForStandardLoad;
WebCore::FrameLoader::transitionToCommitted
https://bugs.webkit.org/show_bug.cgi?id=303364
rdar://165387940
Reviewed by Chris Dumez.
The test shows a case where a reload that is transitioning to be committed
can be interupted by a naigation.navigate during pageswap dispatching, which
does a sync policy check and so can clear the provisional loader, causing
a crash when executing the commitProvisionalLoad code after the pageswap
event
dispatch is done.
To fix this abort the navigate when this gets detected.
Test: fast/loader/navigate-on-pageswap-crash.html
* LayoutTests/fast/loader/navigate-on-pageswap-crash-expected.txt: Added.
* LayoutTests/fast/loader/navigate-on-pageswap-crash.html: Added.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::commitProvisionalLoad):
* Source/WebCore/loader/FrameLoader.h:
* Source/WebCore/page/Navigation.cpp:
(WebCore::Navigation::navigate):
Canonical link:
https://commits.webkit.org/[email protected]
Identifier: 305413.285@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.283@webkitglib/2.52
Commit: 8f6129771db350d02260b257773ab4051bad8b8c
https://github.com/WebKit/WebKit/commit/8f6129771db350d02260b257773ab4051bad8b8c
Author: Youenn Fablet <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M LayoutTests/http/tests/navigation/post-basic-expected.txt
M LayoutTests/http/tests/navigation/post-frames-expected.txt
M LayoutTests/http/tests/navigation/post-frames-goback1-expected.txt
M LayoutTests/http/tests/navigation/post-goback1-expected.txt
M LayoutTests/http/tests/navigation/resources/form-target.pl
M
LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-allowed-expected.txt
M
LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-default-ignored-expected.txt
M
LayoutTests/http/tests/security/contentSecurityPolicy/1.1/form-action-src-get-allowed-expected.txt
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
Log Message:
-----------
Cherry-pick 305413.287@safari-7624-branch (41592221f73c).
https://bugs.webkit.org/show_bug.cgi?id=303364
ASSERTION FAILED: request.hasHTTPHeaderField(HTTPHeaderName::SecFetchDest)
rdar://169836073
Reviewed by Chris Dumez.
In rdar://158416842, we made sure to reuse Sec-Fetch headers in case of
form resubmission, which happens when reloading for instance
(FrameLoader::reload).
The other case where form resubmission happens is in
FrameLoader::loadDifferentDocumentItem, where the request is recreated from
scratch.
In that case, there is no Sec-Fetch headers in the request, and we should
populate those headers.
We update shouldReuseExistingFetchMetadata to return false when there is no
Sec-Fetch headers.
We update a test to cover this change.
Identifier: 305413.287@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.284@webkitglib/2.52
Commit: 9ed75119d1b2f8e859ab7d86ccd0d4f5c7b80ab5
https://github.com/WebKit/WebKit/commit/9ed75119d1b2f8e859ab7d86ccd0d4f5c7b80ab5
Author: Shu-yu Guo <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A
JSTests/stress/growable-sharedarraybuffer-parallel-grow-during-prototype-methods.js
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h
Log Message:
-----------
Cherry-pick 305413.294@safari-7624-branch (17128d39f814).
https://bugs.webkit.org/show_bug.cgi?id=307723
[JSC] Snapshot span of TypedArrays in toSorted, toReversed, and with
https://bugs.webkit.org/show_bug.cgi?id=307723
rdar://170264253
Reviewed by Mark Lam.
The TypedArray.prototype.toSorted, toReversed, and with methods all create a
new TA and copies from the original. This copying is currently done with a
typedSpan(), which reads the TA's length. If the TA is backed by a growable
SharedArrayBuffer, this typedSpan may have a different length than the copy
as
it may have grown in parallel. This PR fixes this by snapshotting the span
ahead of the time.
Test:
JSTests/stress/growable-sharedarraybuffer-parallel-grow-during-prototype-methods.js
*
JSTests/stress/growable-sharedarraybuffer-parallel-grow-during-prototype-methods.js:
Added.
(round.agent.start.agent.receiveBroadcast):
(round.i.catch):
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncToReversed):
(JSC::genericTypedArrayViewProtoFuncToSorted):
(JSC::genericTypedArrayViewProtoFuncWith):
Identifier: 305413.294@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.285@webkitglib/2.52
Commit: a1326085f8fe95db95d6f27775b25c4115b1356d
https://github.com/WebKit/WebKit/commit/a1326085f8fe95db95d6f27775b25c4115b1356d
Author: David Kilzer <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/Shared/Extensions/WebExtensionUtilities.cpp
M Source/WebKit/Shared/Extensions/WebExtensionUtilities.h
M
Source/WebKit/UIProcess/Extensions/API/WebExtensionContextAPIDeclarativeNetRequest.cpp
M
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIDeclarativeNetRequestCocoa.mm
M
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIScriptingCocoa.mm
M
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPITabsCocoa.mm
M
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIWindowsCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIActionCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPICookiesCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIDeclarativeNetRequestCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIDevToolsInspectedWindowCocoa.mm
M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIMenusCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIPermissionsCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIScriptingCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPISidebarActionCocoa.mm
M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPITabsCocoa.mm
M
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWindowsCocoa.mm
M
Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebNavigationURLFilter.mm
M
Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebRequestFilter.mm
Log Message:
-----------
Cherry-pick 305413.295@safari-7624-branch (5cbcce761278).
https://bugs.webkit.org/show_bug.cgi?id=307732
Fix format string issue in WebExtension error handling
<https://bugs.webkit.org/show_bug.cgi?id=307732>
<rdar://146743429>
Reviewed by Timothy Hatcher.
Remove variadic formatting from `toErrorString()` entirely by changing
the function signature to accept only fixed parameters and replacing all
`formatString()` calls with safe `makeString()` concatenation.
Covered by existing tests in
Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPI*.mm.
* Source/WebKit/Shared/Extensions/WebExtensionUtilities.cpp:
(WebKit::toErrorString):
* Source/WebKit/Shared/Extensions/WebExtensionUtilities.h:
*
Source/WebKit/UIProcess/Extensions/API/WebExtensionContextAPIDeclarativeNetRequest.cpp:
(WebKit::WebExtensionContext::declarativeNetRequestUpdateEnabledRulesets):
*
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIDeclarativeNetRequestCocoa.mm:
(WebKit::WebExtensionContext::declarativeNetRequestGetEnabledRulesets):
*
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIScriptingCocoa.mm:
(WebKit::WebExtensionContext::scriptingGetRegisteredContentScripts):
(WebKit::WebExtensionContext::scriptingRegisterContentScripts):
(WebKit::WebExtensionContext::scriptingUnregisterContentScripts):
(WebKit::WebExtensionContext::scriptingUpdateContentScripts):
(WebKit::WebExtensionContext::scriptingRemoveCSS):
(WebKit::WebExtensionContext::scriptingInsertCSS):
(WebKit::WebExtensionContext::scriptingExecuteScript):
*
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPITabsCocoa.mm:
(WebKit::WebExtensionContext::tabsUpdate):
(WebKit::WebExtensionContext::tabsReload):
*
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIWindowsCocoa.mm:
(WebKit::WebExtensionContext::windowsUpdate):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIActionCocoa.mm:
(WebKit::WebExtensionAPIAction::parseActionDetails):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPICookiesCocoa.mm:
(WebKit::WebExtensionAPICookies::get):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIDeclarativeNetRequestCocoa.mm:
(WebKit::WebExtensionAPIDeclarativeNetRequest::updateEnabledRulesets):
(WebKit::WebExtensionAPIDeclarativeNetRequest::getEnabledRulesets):
(WebKit::WebExtensionAPIDeclarativeNetRequest::updateSessionRules):
(WebKit::WebExtensionAPIDeclarativeNetRequest::getSessionRules):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIDevToolsInspectedWindowCocoa.mm:
(WebKit::WebExtensionAPIDevToolsInspectedWindow::eval):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIMenusCocoa.mm:
(WebKit::WebExtensionAPIMenus::parseMenuProperties):
(WebKit::WebExtensionAPIMenus::update):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIPermissionsCocoa.mm:
(WebKit::WebExtensionAPIPermissions::request):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIScriptingCocoa.mm:
(WebKit::WebExtensionAPIScripting::insertCSS):
(WebKit::WebExtensionAPIScripting::removeCSS):
(WebKit::WebExtensionAPIScripting::executeScript):
(WebKit::WebExtensionAPIScripting::registerContentScripts):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPISidebarActionCocoa.mm:
(WebKit::WebExtensionAPISidebarAction::parseActionDetails):
(WebKit::WebExtensionAPISidebarAction::setTitle):
(WebKit::WebExtensionAPISidebarAction::setIcon):
(WebKit::WebExtensionAPISidebarAction::setPanel):
* Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPITabsCocoa.mm:
(WebKit::WebExtensionAPITabs::parseTabQueryOptions):
(WebKit::WebExtensionAPITabs::parseTabCreateOptions):
(WebKit::WebExtensionAPITabs::parseTabUpdateOptions):
(WebKit::WebExtensionAPITabs::parseTabMoveOptions):
(WebKit::WebExtensionAPITabs::parseTabReloadOptions):
(WebKit::WebExtensionAPITabs::get):
(WebKit::WebExtensionAPITabs::create):
(WebKit::WebExtensionAPITabs::duplicate):
(WebKit::WebExtensionAPITabs::query):
(WebKit::WebExtensionAPITabs::update):
(WebKit::WebExtensionAPITabs::move):
(WebKit::WebExtensionAPITabs::reload):
(WebKit::WebExtensionAPITabs::goBack):
(WebKit::WebExtensionAPITabs::goForward):
*
Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWindowsCocoa.mm:
(WebKit::WebExtensionAPIWindows::parseWindowCreateOptions):
(WebKit::WebExtensionAPIWindows::parseWindowUpdateOptions):
*
Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebNavigationURLFilter.mm:
(-[_WKWebExtensionWebNavigationURLFilter
_initWithDictionary:callingAPIName:]):
(+[_WKWebExtensionWebNavigationURLFilter
filtersWithArray:callingAPIName:outErrorMessage:]):
*
Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebRequestFilter.mm:
(-[_WKWebExtensionWebRequestFilter _initWithDictionary:callingAPIName:]):
Identifier: 305413.295@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.286@webkitglib/2.52
Commit: 54d37e2c5f5c1924a6d9d7d71c8224e0be05b348
https://github.com/WebKit/WebKit/commit/54d37e2c5f5c1924a6d9d7d71c8224e0be05b348
Author: Shu-yu Guo <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A JSTests/wasm/stress/const-expr-evaluate-error-offset.js
M Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp
M Source/JavaScriptCore/wasm/WasmConstExprGenerator.h
M Source/JavaScriptCore/wasm/WasmModuleInformation.h
M Source/JavaScriptCore/wasm/WasmSectionParser.cpp
M Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp
M Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.h
Log Message:
-----------
Cherry-pick 305413.298@safari-7624-branch (248a2c0ce1cb).
https://bugs.webkit.org/show_bug.cgi?id=307841
[JSC] Save source offset for evaluating Wasm constant expressions
https://bugs.webkit.org/show_bug.cgi?id=307841
rdar://166778509
Reviewed by Mark Lam.
Constant expressions may throw exceptions during evaluation, which need the
source offset. This PR saves the source offset until evaluation time so that
errors can be thrown with the correct offset.
Test: JSTests/wasm/stress/const-expr-evaluate-error-offset.js
* JSTests/wasm/stress/const-expr-evaluate-error-offset.js: Added.
(catch):
(error.message.indexOf):
* Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp:
(JSC::Wasm::ConstExprGenerator::ConstExprGenerator):
(JSC::Wasm::evaluateExtendedConstExpr):
* Source/JavaScriptCore/wasm/WasmConstExprGenerator.h:
* Source/JavaScriptCore/wasm/WasmModuleInformation.h:
* Source/JavaScriptCore/wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseInitExpr):
* Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluateConstantExpression):
* Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.h:
Identifier: 305413.298@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.287@webkitglib/2.52
Commit: 6fed574d5bf8d27394cd55d38a6dd31181e395a2
https://github.com/WebKit/WebKit/commit/6fed574d5bf8d27394cd55d38a6dd31181e395a2
Author: Jer Noble <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A LayoutTests/media/iframe-load-html-as-m2ts-expected.txt
A LayoutTests/media/iframe-load-html-as-m2ts.html
M Source/WebCore/dom/DOMImplementation.cpp
M
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
Log Message:
-----------
Cherry-pick 305413.302@safari-7624-branch (ee94245e338e).
https://bugs.webkit.org/show_bug.cgi?id=305859
Content served as video/mp2t can be loaded as html
rdar://166121363
https://bugs.webkit.org/show_bug.cgi?id=305859
Reviewed by Eric Carlson.
FrameLoader will ask whether content can be displayed by calling
MIMETypeRegistry::canShowMIMEType(type) with the mime type provided
by the network. Later, DOMImplementation will decide which type of
document (HTMLDocument, MediaDocument, ImageDocument, etc.) to
instantiate by asking MediaPlayer if the given mime is playable.
However, a MSE media player can report supported MIME types which
cannot be played as bare file URLs, which leads to the DOMImplementation
creating a HTMLDocument for a non-playable media type.
Rather than calling all the way to MediaPlayer, DOMImplementation
should just use MIMETypeRegistry to decide which document type to
instantiate. In addition to being more correct, this may even speed
up document creation as it avoids a round-trip to the GPU process.
Test: media/iframe-load-html-as-m2ts.html
* LayoutTests/media/iframe-load-html-as-m2ts-expected.txt: Added.
* LayoutTests/media/iframe-load-html-as-m2ts.html: Added.
* Source/WebCore/dom/DOMImplementation.cpp:
(WebCore::DOMImplementation::createDocument):
*
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::getSupportedTypes):
Identifier: 305413.302@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.288@webkitglib/2.52
Commit: 437be7a446c2e3dab66f5e013396bbfa7733c4b9
https://github.com/WebKit/WebKit/commit/437be7a446c2e3dab66f5e013396bbfa7733c4b9
Author: Ruthvik Konda <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A
LayoutTests/ipc/mark-surfaces-volatile-during-prepare-for-display-expected.txt
A LayoutTests/ipc/mark-surfaces-volatile-during-prepare-for-display.html
M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.h
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
Log Message:
-----------
Cherry-pick 305413.309@safari-7624-branch (939a2f7876f3).
https://bugs.webkit.org/show_bug.cgi?id=307138
Surfaces should not be marked volatile while preparing for display
https://bugs.webkit.org/show_bug.cgi?id=307138
rdar://167565825
Reviewed by Kimmo Kinnunen.
The WebProcess can send MarkSurfacesVolatile while prepareBufferForDisplay
is still active on the GPU Process.
This is semantically invalid.
MarkSurfacesVolatile calls makeBuffersVolatile, which calls
releaseGraphicsContext() on each image buffer — destroying the graphics
context that prepareBufferForDisplay is actively using through m_context.
This leads to a dangling reference.
The only concerning path here is the
makeBuffersVolatile()->releaseGraphicsContext() path.
Since RemoteImageBufferGraphicsContext holds a strong reference to the
context's ImageBuffer,
other paths releasing the ImageBuffer and ImageBuffer destructor paths are
not of concern.
And WebProcess only local paths to releaseGraphicsContext() are also not of
concern.
To fix, we add a MESSAGE_CHECK to reject when markSurfacesVolatile is
called while drawing is ongoing.
Test: ipc/mark-surfaces-volatile-during-prepare-for-display.html
*
LayoutTests/ipc/mark-surfaces-volatile-during-prepare-for-display-expected.txt:
Added.
* LayoutTests/ipc/mark-surfaces-volatile-during-prepare-for-display.html:
Added.
* Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.h:
(WebKit::RemoteImageBufferSet::isPreparingForDisplay const):
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::markSurfacesVolatile):
Identifier: 305413.309@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.289@webkitglib/2.52
Commit: d585f651bf4c1f9b3723de29451ff308b1b8c268
https://github.com/WebKit/WebKit/commit/d585f651bf4c1f9b3723de29451ff308b1b8c268
Author: Kristian Monsen <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
Log Message:
-----------
Cherry-pick 305413.312@safari-7624-branch (3b1d5b1637bb).
https://bugs.webkit.org/show_bug.cgi?id=307843
Disable remote display list rendering mode
https://bugs.webkit.org/show_bug.cgi?id=307843
rdar://169719630
Reviewed by Said Abou-Hallawa.
This fixes the bug by aborting with MESSAGE_CHECK if
remoteSnapshottingEnabled is not true.
Missing test infrastructure
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::createImageBuffer):
Identifier: 305413.312@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.290@webkitglib/2.52
Commit: a6eb7d4ff0c3402c9f5f64986c4983f760910085
https://github.com/WebKit/WebKit/commit/a6eb7d4ff0c3402c9f5f64986c4983f760910085
Author: Kristian Monsen <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/SaferCPPExpectations/UncountedLocalVarsCheckerExpectations
M Source/WebCore/page/PageGroup.cpp
Log Message:
-----------
Cherry-pick 305413.322@safari-7624-branch (6e48549c1cfa).
https://bugs.webkit.org/show_bug.cgi?id=308104
Use WeakHashSet::forEach to iterate over set where the iterator might be
invalidated
https://bugs.webkit.org/show_bug.cgi?id=308104
rdar://170475145
Reviewed by Geoffrey Garen and Chris Dumez.
WeakHashSet::forEach handles invalidation internally
This is pretty hard to reproduce, the testcase reproduces ~16% and takes
~11 seconds
* Source/WebCore/SaferCPPExpectations/UncountedLocalVarsCheckerExpectations:
* Source/WebCore/page/PageGroup.cpp:
(WebCore::PageGroup::captionPreferencesChanged):
Identifier: 305413.322@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.291@webkitglib/2.52
Commit: c5941bda7559977e7f70c4267750b45ff6dd319f
https://github.com/WebKit/WebKit/commit/c5941bda7559977e7f70c4267750b45ff6dd319f
Author: Zak Ridouh <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WTF/wtf/StdLibExtras.h
Log Message:
-----------
Cherry-pick 305413.323@safari-7624-branch (e8a1e7ae4c99).
https://bugs.webkit.org/show_bug.cgi?id=306483
secureMemsetSpan does not use memset_s, and is likely compiled out due to
Dead Store Elimination
<https://bugs.webkit.org/show_bug.cgi?id=306483>
<rdar://problem/169132865>
Reviewed by Darin Adler (OOPS\!).
The secureMemsetSpan implementation introduced in 287670@main has two
issues:
1. It passes 3 arguments to memset_s, which actually takes 4 arguments.
This shouldn't compile, but since we gate usage behind
#ifdef __STDC_LIB_EXT1__ without the implementation defining that
macro,
the memset_s branch was never taken and we fell back to regular memset.
2. The fallback to memset provides no security guarantees since compilers
can optimize it away when the buffer is not subsequently read.
Fix by:
- Fixing the memset_s call to use the correct 4-argument signature
- Replacing the insecure memset fallback with a volatile function pointer
indirect call to memset, which prevents the compiler from recognizing
the call as a dead store and optimizing it away
The __STDC_LIB_EXT1__ configuration issue that also contributed to the
memset_s branch never being taken will be addressed separately.
* Source/WTF/wtf/StdLibExtras.h:
(WTF::secureMemsetSpan):
Identifier: 305413.323@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.292@webkitglib/2.52
Commit: f55d208fed84c1cd46a87030e1066691cdcb3942
https://github.com/WebKit/WebKit/commit/f55d208fed84c1cd46a87030e1066691cdcb3942
Author: Claudio Saavedra <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A
LayoutTests/animations/animation-apply-pending-animation-crash-expected.txt
A LayoutTests/animations/animation-apply-pending-animation-crash.html
M Source/WebCore/animation/KeyframeEffect.cpp
Log Message:
-----------
Cherry-pick [email protected] (2e52d07ce2b7).
https://bugs.webkit.org/show_bug.cgi?id=306595
[WebKit][Main+SU] [73e157cc9e45c104] ASAN_SEGV |
WebCore::WebAnimation::currentTime;
WebCore::KeyframeEffect::applyPendingAcceleratedActions;
WebCore::KeyframeEffect::applyPendingAcceleratedActions
https://bugs.webkit.org/show_bug.cgi?id=306595
Reviewed by Antoine Quint.
KeyframeEffect::applyPendingAcceleratedActions() can be called from an
asynchronous micro task scheduled from KeyframeEffect::wasRemovedFromStack()
and, while that method keeps a reference to the effect's animation, the
lambda
doesn't, so it's possible for the weak pointer that tracks it to become
nullptr
before it gets called. It's safer to check if there's still an animation
before applying anything.
Test: animations/animation-apply-pending-animation-crash.html
*
LayoutTests/animations/animation-apply-pending-animation-crash-expected.txt:
Added.
* LayoutTests/animations/animation-apply-pending-animation-crash.html:
Added.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::applyPendingAcceleratedActions):
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 305413.327@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.293@webkitglib/2.52
Commit: 0cef62778770d052c2513923b2a70289d1272dce
https://github.com/WebKit/WebKit/commit/0cef62778770d052c2513923b2a70289d1272dce
Author: Frédéric Wang <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/platform/glib/TestExpectations
A
LayoutTests/svg/dom/SVGGeometry-isPointInStroke-with-null-path-expected.txt
A LayoutTests/svg/dom/SVGGeometry-isPointInStroke-with-null-path.html
M Source/WebCore/rendering/svg/RenderSVGShape.cpp
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGShape.cpp
Log Message:
-----------
Cherry-pick [email protected] (82934b97537c).
https://bugs.webkit.org/show_bug.cgi?id=306154
Crash in shapeDependentStrokeContains() via isPointInStroke()
https://bugs.webkit.org/show_bug.cgi?id=306154
Reviewed by Darin Adler.
Ensure the path exists when calling the function with legacy and LSBE code
from isPointInStroke() (which implies pointCoordinateSpace is
LocalCoordinateSpace). This is similar to
https://commits.webkit.org/292730@main
Test: svg/dom/SVGGeometry-isPointInStroke-with-null-path.html
* LayoutTests/TestExpectations: Skip the test because it hits an assertion
failure.
* LayoutTests/platform/glib/TestExpectations: Ditto.
*
LayoutTests/svg/dom/SVGGeometry-isPointInStroke-with-null-path-expected.txt:
Added.
* LayoutTests/svg/dom/SVGGeometry-isPointInStroke-with-null-path.html:
Added.
* Source/WebCore/rendering/svg/RenderSVGShape.cpp:
(WebCore::RenderSVGShape::shapeDependentStrokeContains): Ensure path exists.
* Source/WebCore/rendering/svg/legacy/LegacyRenderSVGShape.cpp:
(WebCore::LegacyRenderSVGShape::shapeDependentStrokeContains): Ditto.
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 305413.329@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.294@webkitglib/2.52
Commit: 9b097940d49fd7b086629db51f6bc8f5dcee70b9
https://github.com/WebKit/WebKit/commit/9b097940d49fd7b086629db51f6bc8f5dcee70b9
Author: Claudio Saavedra <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
A LayoutTests/fast/reflections/reflection-removed-crash-2-expected.txt
A LayoutTests/fast/reflections/reflection-removed-crash-2.html
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Cherry-pick [email protected] (218d25f508a7).
https://bugs.webkit.org/show_bug.cgi?id=306841
[WebKit][Main] [Fuzz Blocker] [e5518f91af2befa2] WK_SEC |
WebCore::RenderLayerCompositor::repaintInCompositedAncestor;
WebCore::RenderLayerCompositor::layerWillBeRemoved;
WebCore::RenderLayer::removeChild
https://bugs.webkit.org/show_bug.cgi?id=306841
Reviewed by Simon Fraser.
When a render layer that contains a reflection layer is deleted, we first
remove that reflection layer. The code path for layer removal causes
the layer to be repainted in its composited ancestor. However, when
the compositor ancestor is the original layer that is being deleted,
we are actually dealing with a layer that is in the process of destruction.
In order to prevent this reentrancy, we can avoid going
down RenderLayerCompositor::layerWillBeRemoved() if the layer being removed
is a reflection layer, since this doesn't seem to be needed in reality (and
all tests involving -webkit-reflect-box pass after this change).
This bug was uncovered in main after 306315@main introduced a checked
pointer
for the compositedAncestor variable in
RenderLayerCompositor::repaintInCompositedAncestor(),
which fails an assertion when it goes out of scope, because the underlying
RenderLayer is already in the process of destruction. This doesn't assert
or crash before that change, but assuming that we don't want to take risks
I prefer to land this change in embargoed instead so that it's backported
wherever it's necessary before making this change public in main.
Test: fast/reflections/reflection-removed-crash-2.html
* LayoutTests/fast/reflections/reflection-removed-crash-2-expected.txt:
Added.
* LayoutTests/fast/reflections/reflection-removed-crash-2.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::removeChild):
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 305413.330@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.295@webkitglib/2.52
Commit: ea1297e174e82d37e0f7bef73518bb2aafdaae94
https://github.com/WebKit/WebKit/commit/ea1297e174e82d37e0f7bef73518bb2aafdaae94
Author: Per Arne Vollan <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp
M Source/WebKit/Shared/WebProcessCreationParameters.h
M Source/WebKit/Shared/WebProcessCreationParameters.serialization.in
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/WebProcess/WebProcess.h
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm
Log Message:
-----------
Cherry-pick 305413.335@safari-7624-branch (00906723527a).
https://bugs.webkit.org/show_bug.cgi?id=308348
The WebContent process should not prevent local file loads where the
Networking process has access by extension
https://bugs.webkit.org/show_bug.cgi?id=308348
rdar://170610201
Reviewed by Chris Dumez.
The UI process is granting the Networking process access to its temp
directory. If the UI process is performing
a load of a local file inside that directory, the WebContent process should
not block it.
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:
(WebKit::networkProcessHasAccessByExtensions):
(WebKit::NetworkResourceLoadParameters::createSandboxExtensionHandlesIfNecessary):
* Source/WebKit/Shared/WebProcessCreationParameters.h:
* Source/WebKit/Shared/WebProcessCreationParameters.serialization.in:
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::platformInitializeWebProcess):
* Source/WebKit/WebProcess/WebProcess.h:
* Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::accessibilityFocusedUIElement):
Identifier: 305413.335@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.296@webkitglib/2.52
Commit: 8fdca82aba0e7f02a5999db8be9426ad0b9b14b0
https://github.com/WebKit/WebKit/commit/8fdca82aba0e7f02a5999db8be9426ad0b9b14b0
Author: Rupin Mittal <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/UIProcess/API/APINavigationResponse.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm
Log Message:
-----------
Cherry-pick 305413.338@safari-7624-branch (816b1f464d4d).
https://bugs.webkit.org/show_bug.cgi?id=308396
Download Prompt Origin Spoofing via Back-Forward Navigation
https://bugs.webkit.org/show_bug.cgi?id=308396
rdar://153668219
Reviewed by Brady Eidson.
When a navigation occurs, WebKit calls the delegate function:
webView:decidePolicyForNavigationResponse:decisionHandler: and passes in a
WKNavigationResponse object. The client may use the
_navigationInitiatingFrame
property to show which triggered this Navigation (or is requesting a
download)
In the case where the navigation is started as a result of a back-forward
navigation, WebKit currently says the initiating frame is the frame that
is currently displayed in the WebView that is on the screen. Which means
the following sequence of events is possible:
1. Navigate to site1.com
2. Navigate to site2.com
3. Go back <--- somehow this starts a download
(maybe a malicicous script intervenes)
4. A prompt may show saying that "site2.com wants to start a download"
But site2 did not start the download. This message is misleading.
We fix this by ensuring that in a back-forward navigation, the initiating
frame information is empty, rather than being the information of the site
currently displayed in the WebView.
A second scenario is also possible:
1. Navigate to site1.com
2. User types in site2.com to navigate there <--- somehow starting a
download
(maybe a malicicous
script intervenes)
3. A prompt may show saying that "site1.com wants to start a download"
Again, the download should not be attributed to site1.
We make the same change here--for a client initiated navigation, the
initiating frame information is empty, rather than being the information of
the site currently displayed in the WebView.
This is tested by two new API tests.
A similar fix was made in https://commits.webkit.org/298732@main
* Source/WebKit/UIProcess/API/APINavigationResponse.cpp:
(API::NavigationResponse::navigationInitiatingFrame):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm:
(TEST(Navigation, NavigationInitiatingFrameInGoBackNavigation)):
(TEST(Navigation, NavigationInitiatingFrameInClientInputNavigation)):
Identifier: 305413.338@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.297@webkitglib/2.52
Commit: 3e59292b95de1c22169fc939999ddd84d746319e
https://github.com/WebKit/WebKit/commit/3e59292b95de1c22169fc939999ddd84d746319e
Author: Zak Ridouh <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteGraphicsContext.cpp
Log Message:
-----------
Cherry-pick 305413.340@safari-7624-branch (035f36c175f9).
https://bugs.webkit.org/show_bug.cgi?id=308248
Copy the glyph buffer in RemoteGraphicsContext::drawGlyphs
<https://bugs.webkit.org/show_bug.cgi?id=308248>
<rdar://169563888>
Reviewed by Simon Fraser.
Copy the glyph buffer in RemoteGraphicsContext::drawGlyphs
Slight variant of Kimmo's patch, using inline vector capacity to attempt
clawing back some performance impact when copying the buffer.
No new tests.
* Source/WebKit/GPUProcess/graphics/RemoteGraphicsContext.cpp:
(WebKit::RemoteGraphicsContext::drawGlyphs):
Identifier: 305413.340@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.298@webkitglib/2.52
Commit: 01069bf242f419c2b8138bf335f85cf2bff035f9
https://github.com/WebKit/WebKit/commit/01069bf242f419c2b8138bf335f85cf2bff035f9
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGLProgram.cpp
M Source/WebCore/html/canvas/WebGLProgram.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/platform/graphics/GraphicsContextGL.h
M Source/WebCore/platform/graphics/GraphicsContextGLActiveInfo.h
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.h
M Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.messages.in
M
Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGLFunctionsGenerated.cpp
M
Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGLFunctionsGenerated.h
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/Shared/WebGL.serialization.in
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.h
M
Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxyFunctionsGenerated.cpp
M Tools/Scripts/generate-gpup-webgl
Log Message:
-----------
Cherry-pick 65c9777a8d88. https://bugs.webkit.org/show_bug.cgi?id=300784
REGRESSION (301944@main): nio.com: car configurator is failing to render
rdar://171253212
Reviewed by Cameron McCormack.
Revert WebGL parts of 301944@main.
Keep CString std::string utilities part of the change.
* Source/WebCore/html/canvas/WebGL2RenderingContext.cpp:
(WebCore::WebGL2RenderingContext::getTransformFeedbackVarying):
(WebCore::WebGL2RenderingContext::getUniformIndices):
(WebCore::WebGL2RenderingContext::getActiveUniforms):
(WebCore::WebGL2RenderingContext::getActiveUniformBlockName):
* Source/WebCore/html/canvas/WebGLProgram.cpp:
(WebCore::WebGLProgram::getLinkStatus):
(WebCore::WebGLProgram::increaseLinkCount):
(WebCore::WebGLProgram::cacheInfoIfNeeded):
(WebCore::WebGLProgram::linkStatus): Deleted.
(WebCore::WebGLProgram::activeAttribs): Deleted.
(WebCore::WebGLProgram::attribLocations): Deleted.
(WebCore::WebGLProgram::activeUniforms): Deleted.
(WebCore::WebGLProgram::uniformLocations): Deleted.
(WebCore::WebGLProgram::uniformIndices): Deleted.
(WebCore::WebGLProgram::requiredTransformFeedbackBufferCount): Deleted.
* Source/WebCore/html/canvas/WebGLProgram.h:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::getActiveAttrib):
(WebCore::WebGLRenderingContextBase::getActiveUniform):
(WebCore::WebGLRenderingContextBase::getAttribLocation):
(WebCore::WebGLRenderingContextBase::getProgramParameter):
(WebCore::WebGLRenderingContextBase::getUniform):
(WebCore::WebGLRenderingContextBase::getUniformLocation):
(WebCore::WebGLRenderingContextBase::useProgram):
* Source/WebCore/platform/graphics/GraphicsContextGL.h:
* Source/WebCore/platform/graphics/GraphicsContextGLActiveInfo.h:
(): Deleted.
* Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp:
(WebCore::GraphicsContextGLANGLE::getActiveUniforms):
(WebCore::GraphicsContextGLANGLE::getActiveAttrib):
(WebCore::GraphicsContextGLANGLE::getActiveUniform):
(WebCore::GraphicsContextGLANGLE::getAttribLocation):
(WebCore::GraphicsContextGLANGLE::getUniformLocation):
(WebCore::GraphicsContextGLANGLE::getTransformFeedbackVarying):
(WebCore::GraphicsContextGLANGLE::getUniformIndices):
(WebCore::GraphicsContextGLANGLE::activeAttribs): Deleted.
(WebCore::GraphicsContextGLANGLE::activeUniforms): Deleted.
* Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.h:
* Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.messages.in:
*
Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGLFunctionsGenerated.cpp:
(WebKit::RemoteGraphicsContextGL::getActiveAttrib):
(WebKit::RemoteGraphicsContextGL::getActiveUniform):
(WebKit::RemoteGraphicsContextGL::getAttribLocation):
(WebKit::RemoteGraphicsContextGL::getUniformLocation):
(WebKit::RemoteGraphicsContextGL::getTransformFeedbackVarying):
(WebKit::RemoteGraphicsContextGL::getUniformIndices):
(WebKit::RemoteGraphicsContextGL::getActiveUniforms):
(WebKit::RemoteGraphicsContextGL::activeAttribs): Deleted.
(WebKit::RemoteGraphicsContextGL::activeUniforms): Deleted.
*
Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGLFunctionsGenerated.h:
* Source/WebKit/Scripts/webkit/messages.py:
(headers_for_type):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/Shared/WebGL.serialization.in:
* Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.h:
*
Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxyFunctionsGenerated.cpp:
(WebKit::RemoteGraphicsContextGLProxy::getActiveAttrib):
(WebKit::RemoteGraphicsContextGLProxy::getActiveUniform):
(WebKit::RemoteGraphicsContextGLProxy::getAttribLocation):
(WebKit::RemoteGraphicsContextGLProxy::getUniformLocation):
(WebKit::RemoteGraphicsContextGLProxy::getTransformFeedbackVarying):
(WebKit::RemoteGraphicsContextGLProxy::getUniformIndices):
(WebKit::RemoteGraphicsContextGLProxy::getActiveUniforms):
(WebKit::RemoteGraphicsContextGLProxy::activeAttribs): Deleted.
(WebKit::RemoteGraphicsContextGLProxy::activeUniforms): Deleted.
* Tools/Scripts/generate-gpup-webgl:
(main):
Identifier: 305413.388@safari-7624-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/305877.299@webkitglib/2.52
Commit: d7dcbe103d420677525cc8e88e00cd20e432d737
https://github.com/WebKit/WebKit/commit/d7dcbe103d420677525cc8e88e00cd20e432d737
Author: Zak Ridouh <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WTF/wtf/CompactRefPtrTuple.h
Log Message:
-----------
Cherry-pick 305413.284@safari-7624-branch (705b81865328).
https://bugs.webkit.org/show_bug.cgi?id=306357
[MTE] Harden WebCore::ThreadTimerHeapItem and WTF::CompactPointerTuple
<https://bugs.webkit.org/show_bug.cgi?id=306357>
<rdar://168524490>
Reviewed by Darin Adler.
With MTE tagging currently unable to tag compact ptrs, we need to manually
clear the memory to mitigate any MTE bypasses.
Do this on WTF::CompactRefPtrTuple to protect WebCore::ThreadTimerHeapItem
and related subclasses that use this type.
* Source/WTF/wtf/CompactRefPtrTuple.h:
Identifier: 305413.284@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.300@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/cd22f398cfae...d7dcbe103d42
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
