Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 6dd10a05129d283ee3ec5e79bcf19d3830c3852e
https://github.com/WebKit/WebKit/commit/6dd10a05129d283ee3ec5e79bcf19d3830c3852e
Author: Kristian Monsen <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
A
LayoutTests/navigation-api/navigation-navigate-state-clone-exception-crash-expected.txt
A
LayoutTests/navigation-api/navigation-navigate-state-clone-exception-crash.html
A
LayoutTests/navigation-api/navigation-reload-state-clone-exception-crash-expected.txt
A
LayoutTests/navigation-api/navigation-reload-state-clone-exception-crash.html
M Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp
Log Message:
-----------
Cherry-pick 318836@main (37cfccb3c6c9).
https://bugs.webkit.org/show_bug.cgi?id=321250
Fix crash from double-consuming the pending exception in
DeferredPromise::reject() during Navigation reload()/navigate() error handling
https://bugs.webkit.org/show_bug.cgi?id=321250
rdar://183911429
Reviewed by Rupin Mittal.
Navigation::createErrorResult() rejects both the committed and finished
promises with the same Exception. When that exception carries
ExceptionCode::ExistingExceptionError — the
sentinel meaning "the real JS exception is already sitting on the VM's
exception scope" — DeferredPromise::reject() pulled the value straight off
scope.exception() and called
scope.clearException() as a side effect. That works for the first reject()
call, but clears the exception before the second call runs, so it finds nothing
there: an assert in
debug/ASan builds, a null-pointer read of Exception::m_value in release
builds — either way, a crash on every reload()/navigate() whose state argument
throws during
structured-clone.
The fix reuses the exceptionObject out-parameter that's already threaded
through both reject() calls (the same parameter the plain-ExceptionCode branch
a few lines below already
uses to build the DOMException once and share it across calls). On the
first call, if exceptionObject is still empty, it extracts the value from the
exception scope, clears it, and
caches the result in exceptionObject; on the second call, exceptionObject
is already populated, so it skips touching the exception scope entirely and
just rejects with the cached
value. This matches the pattern already used elsewhere in Navigation.cpp
(rejectFinishedPromise, which precomputes a DOMException once and passes it to
both promise rejections),
and it satisfies the spec requirement that committed and finished reject
with the identical error value — which a "swallow and fall back to a generic
error" fix would not have.
Tests: navigation-api/navigation-navigate-state-clone-exception-crash.html
navigation-api/navigation-reload-state-clone-exception-crash.html
*
LayoutTests/navigation-api/navigation-navigate-state-clone-exception-crash-expected.txt:
Added.
*
LayoutTests/navigation-api/navigation-navigate-state-clone-exception-crash.html:
Added.
*
LayoutTests/navigation-api/navigation-reload-state-clone-exception-crash-expected.txt:
Added.
*
LayoutTests/navigation-api/navigation-reload-state-clone-exception-crash.html:
Added.
* Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp:
(WebCore::DeferredPromise::reject):
Canonical link: https://commits.webkit.org/318836@main
Canonical link: https://commits.webkit.org/317695.74@webkitglib/2.54
Commit: abd16f7c6829960df159123fedd823eabacd4594
https://github.com/WebKit/WebKit/commit/abd16f7c6829960df159123fedd823eabacd4594
Author: Carlos Garcia Campos <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
M Source/WebCore/SaferCPPExpectations/UncheckedCallArgsCheckerExpectations
M Source/WebCore/accessibility/AccessibilityMenuListPopup.cpp
Log Message:
-----------
Cherry-pick 318692@main (e04f9dd61dc4).
https://bugs.webkit.org/show_bug.cgi?id=321077
Crash in AccessibilityMenuListPopup::menuListOptionAccessibilityObject
https://bugs.webkit.org/show_bug.cgi?id=321077
Reviewed by Tyler Wilcock.
Null check AXCache we get from document and return early if it's nullptr.
* Source/WebCore/accessibility/AccessibilityMenuListPopup.cpp:
(WebCore::AccessibilityMenuListPopup::menuListOptionAccessibilityObject
const):
* Source/WebCore/SaferCPPExpectations/UncheckedCallArgsCheckerExpectations:
Canonical link: https://commits.webkit.org/318692@main
Canonical link: https://commits.webkit.org/317695.75@webkitglib/2.54
Commit: 206d9afe94771a46e91eaeacf8ce44d14ff8cd14
https://github.com/WebKit/WebKit/commit/206d9afe94771a46e91eaeacf8ce44d14ff8cd14
Author: Carlos Alberto Lopez Perez <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
M Source/cmake/WebKitCommon.cmake
M Tools/Scripts/make-dist
Log Message:
-----------
Cherry-pick 318773@main (aa6c61fcb002).
https://bugs.webkit.org/show_bug.cgi?id=321266
Unreviewed backport.
[GTK][WPE][CMake] Do not allow to build with make, require ninja instead.
https://bugs.webkit.org/show_bug.cgi?id=321266
Reviewed by Carlos Garcia Campos.
Currently for building GTK or WPE there are two ways: use the build-webkit
script
or use CMake directly. The build-webkit script is only intended for webkit
developers, for production releases or users of webkit the idea is to use
cmake
directly.
The problem is that we have a split on how WebKit is built. With
build-webkit
ninja is used by default, but when using cmake directly it uses whatever
cmake
generator has as default (make usually) and that is causing issues because
of
build errors due to dependencies between targets, ninja has its own
dependency
graph, but plain makefiles don't.
And this causes issues when someone tries to use make because no one usually
tests the make build.
This patch makes ninja mandatory for GTK and WPE ports and also changes the
make-dist script to use it.
* Source/cmake/WebKitCommon.cmake:
* Tools/Scripts/make-dist:
(Distcheck.configure):
(Distcheck.build):
(Distcheck.install):
Canonical link: https://commits.webkit.org/318773@main
Canonical link: https://commits.webkit.org/317695.76@webkitglib/2.54
Commit: 552a4d6d6d1c9e5b36b2474c30d6cb4e25ffcbff
https://github.com/WebKit/WebKit/commit/552a4d6d6d1c9e5b36b2474c30d6cb4e25ffcbff
Author: Fujii Hironori <[email protected]>
Date: 2026-08-09 (Sun, 09 Aug 2026)
Changed paths:
M Source/cmake/WebKitMacros.cmake
Log Message:
-----------
Cherry-pick 318630@main (4bfeff8c67ad).
https://bugs.webkit.org/show_bug.cgi?id=321081
[CMake 4.4][WPE] _WEBKIT_TARGET_LINK_FRAMEWORK reports "Unknown arguments
specified" error
https://bugs.webkit.org/show_bug.cgi?id=321081
Reviewed by Adrian Perez de Castro.
CMake 4.4 reports the following error for WPE.
> -- Using platform-specific CMakeLists:
/run/build/webkitwpe/Source/JavaScriptCore/shell/PlatformWPE.cmake
> CMake Error at Source/cmake/WebKitMacros.cmake:554 (if):
> if given arguments:
>
> "(" "NOT" "_linked_into" ")" "OR" "(" "JavaScriptCore" "STREQUAL" ")"
"OR" "(" "NOT" "IN_LIST" "jsc_FRAMEWORKS" ")"
>
> Unknown arguments specified
> Call Stack (most recent call first):
> Source/cmake/WebKitMacros.cmake:756 (_WEBKIT_TARGET_LINK_FRAMEWORK)
> Source/JavaScriptCore/shell/CMakeLists.txt:126 (WEBKIT_EXECUTABLE)
Replaced `${_linked_into}` with `_linked_into`.
* Source/cmake/WebKitMacros.cmake(_WEBKIT_TARGET_LINK_FRAMEWORK):
Canonical link: https://commits.webkit.org/318630@main
Canonical link: https://commits.webkit.org/317695.77@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/c6d83c190967...552a4d6d6d1c
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
