Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 0e02310d2a2755175ddcb6ae123a7303901e707e
https://github.com/WebKit/WebKit/commit/0e02310d2a2755175ddcb6ae123a7303901e707e
Author: Rodrigo Alencar <[email protected]>
Date: 2026-05-09 (Sat, 09 May 2026)
Changed paths:
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
Cherry-pick 312779@main (c7cf80229641).
https://bugs.webkit.org/show_bug.cgi?id=314187
[Leak] Service worker fetch() retains ResourceResponses in the remote
worker DocumentLoader
https://bugs.webkit.org/show_bug.cgi?id=314187
Reviewed by Youenn Fablet.
Synthesized documents mark their FrameLoader state as Complete directly
instead of going through setState(FrameState::Complete). That bypasses the
normal DocumentLoader::stopRecordingResponses() call.
Remote worker pages used by service workers are initialized this way. When
service worker fetches go through their backing document loader,
each response can be recorded in DocumentLoader::m_responses even though the
document is already complete. This causes ResourceResponses to be retained
for
the lifetime of the remote worker page.
Call stopRecordingResponses() when initializing synthesized documents so
their
DocumentLoader matches the normal Complete state behavior.
No new automated test because this retention is only visible through native
WebContent memory inspection. The Web platform cannot observe
DocumentLoader::m_responses or m_stopRecordingResponses.
Manual test: ran a local WKWebView service worker fetch harness before and
after
this change. Before: the remote worker DocumentLoader retained 5059
responses
and had m_stopRecordingResponses=false. After: the remote worker
DocumentLoader
retained 0 responses and had m_stopRecordingResponses=true.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::initForSynthesizedDocument):
Canonical link: https://commits.webkit.org/312779@main
Canonical link: https://commits.webkit.org/305877.482@webkitglib/2.52
Commit: dcae236cd5c5c4b4786331c1e4753c6b6123b44a
https://github.com/WebKit/WebKit/commit/dcae236cd5c5c4b4786331c1e4753c6b6123b44a
Author: Adrian Taylor <[email protected]>
Date: 2026-05-09 (Sat, 09 May 2026)
Changed paths:
M Source/WebCore/platform/graphics/x11/XErrorTrapper.h
Log Message:
-----------
Cherry-pick 312878@main (959829501d2d).
https://bugs.webkit.org/show_bug.cgi?id=314395
[Swift GTK] Undefined Success
https://bugs.webkit.org/show_bug.cgi?id=314395
Reviewed by Adrian Perez de Castro.
The X11 header defines Success. This causes difficulty when this header is
transitively included in some Swift/C++ import scenarios, since the
definition
of Success causes problems interpreting the 'Success' case of other enums
across the codebase. Undefine Success since we don't currently need it.
Canonical link: https://commits.webkit.org/312878@main
Canonical link: https://commits.webkit.org/305877.483@webkitglib/2.52
Commit: 02dec333499a21f79a66430f87dd40db698b0930
https://github.com/WebKit/WebKit/commit/02dec333499a21f79a66430f87dd40db698b0930
Author: Claudio Saavedra <[email protected]>
Date: 2026-05-09 (Sat, 09 May 2026)
Changed paths:
M Source/WebCore/platform/text/hyphen/HyphenationLibHyphen.cpp
Log Message:
-----------
Cherry-pick 312894@main (f5ad6e77a2db).
https://bugs.webkit.org/show_bug.cgi?id=309589
Crash in WebCore::lastHyphenLocation
https://bugs.webkit.org/show_bug.cgi?id=309589
Reviewed by Adrian Perez de Castro.
Speculative fix. If the dictionary can't be opened for whatever reason, we
end up
with a nullptr HyphenDictUniquePtr in HyphenationDictionary. This can be
due to
broken symlinks, corrupted files, etc. Guarding this might fix the crash.
* Source/WebCore/platform/text/hyphen/HyphenationLibHyphen.cpp:
(WebCore::lastHyphenLocation):
Canonical link: https://commits.webkit.org/312894@main
Canonical link: https://commits.webkit.org/305877.484@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/4d68c4bc4669...02dec333499a
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications