Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: e38a7cfe5f93bec26d99e4134b702c8b02bcdbe0
https://github.com/WebKit/WebKit/commit/e38a7cfe5f93bec26d99e4134b702c8b02bcdbe0
Author: Chris Dumez <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
A
LayoutTests/http/tests/websocket/tests/hybi/handshake-fail-with-200-ok_wsh.py
A
LayoutTests/http/tests/websocket/tests/hybi/worker-handshake-failure-cleanup-expected.txt
A
LayoutTests/http/tests/websocket/tests/hybi/worker-handshake-failure-cleanup.html
M Source/WebCore/page/SocketProvider.h
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
M Source/WebKit/WebProcess/Network/WebSocketChannel.cpp
M Source/WebKit/WebProcess/Network/WebSocketChannel.h
M Source/WebKit/WebProcess/Network/WebSocketProvider.cpp
M Source/WebKit/WebProcess/Network/WebSocketProvider.h
Log Message:
-----------
Cherry-pick 313770@main (f391b9f442fc).
https://bugs.webkit.org/show_bug.cgi?id=315342
NetworkSocketChannel leaks when a worker WebSocket is closed by the server
https://bugs.webkit.org/show_bug.cgi?id=315342
rdar://130167032
Reviewed by Youenn Fablet.
When a worker-scoped WebSocket is closed by the peer, the
WebProcess-side WebKit::WebSocketChannel never sends the Close IPC to
the network process, so NetworkSocketChannel sits in State::Closing
forever and its underlying NSURLSessionWebSocketTask leaks.
The chain on a peer-initiated close (network process delivers DidClose):
WebSocketChannel::didClose (main thread)
-> client->didClose, where client is
WorkerThreadableWebSocketChannel::Peer
-> Peer::didClose sets m_mainWebSocketChannel = nullptr
(drops the only strong ref to WebKit::WebSocketChannel)
-> WebSocketChannel::didClose returns
-> protectedThis goes out of scope, last ref drops
-> ~WebSocketChannel runs (currently does not send Close)
The path that *would* send the Close IPC is
Peer::~Peer -> m_mainWebSocketChannel->disconnect(), but
m_mainWebSocketChannel was already nulled in Peer::didClose, so ~Peer
is a no-op. The worker-side WebSocket::didClose handler eventually
calls socket.m_channel->disconnect(), but in the worker case
m_channel is the WorkerThreadableWebSocketChannel, whose Bridge::disconnect
only nullifies local state and does not send any IPC.
The document-scoped path is unaffected because there
WebSocket::m_channel is the WebKit::WebSocketChannel directly, and
WebSocket::didClose's task does m_channel->disconnect() against it,
which sends the IPC explicitly.
Fix this by sending the Close IPC from ~WebSocketChannel when none of
the explicit close/disconnect paths sent it. A new m_needsToCallClose
flag is set to true in WebSocketChannel::connect() once the
CreateSocketChannel IPC has actually been sent (so connect() failures
that returned early don't leave a stale flag), and is cleared whenever
close()/fail()/disconnect() send a Close IPC. The destructor then
sends Close only when the flag is still set, ensuring a single Close
IPC per network-process channel and none for channels the network
process never knew about.
TEST: http/tests/websocket/tests/hybi/worker-handshake-failure-cleanup.html
*
LayoutTests/http/tests/websocket/tests/hybi/handshake-fail-with-200-ok_wsh.py:
Added.
(web_socket_do_extra_handshake):
(web_socket_transfer_data):
*
LayoutTests/http/tests/websocket/tests/hybi/worker-handshake-failure-cleanup-expected.txt:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/worker-handshake-failure-cleanup.html:
Added.
* Source/WebCore/page/SocketProvider.h:
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::numberOfWebSocketChannelsInNetworkProcess):
* Source/WebCore/testing/Internals.h:
* Source/WebCore/testing/Internals.idl:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::countWebSocketChannelsForTesting):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Source/WebKit/WebProcess/Network/WebSocketChannel.cpp:
(WebKit::WebSocketChannel::~WebSocketChannel):
(WebKit::WebSocketChannel::connect):
(WebKit::WebSocketChannel::close):
(WebKit::WebSocketChannel::fail):
(WebKit::WebSocketChannel::disconnect):
* Source/WebKit/WebProcess/Network/WebSocketChannel.h:
* Source/WebKit/WebProcess/Network/WebSocketProvider.cpp:
(WebKit::WebSocketProvider::countWebSocketChannelsForTesting):
* Source/WebKit/WebProcess/Network/WebSocketProvider.h:
Canonical link: https://commits.webkit.org/313770@main
Canonical link: https://commits.webkit.org/305877.674@webkitglib/2.52
Commit: 97e256a6203b8988e621d735da301b5dc1db8cc8
https://github.com/WebKit/WebKit/commit/97e256a6203b8988e621d735da301b5dc1db8cc8
Author: Timothy Hatcher <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M Source/WebKit/UIProcess/API/APIHTTPCookieStore.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPICookies.mm
Log Message:
-----------
Cherry-pick 313745@main (0148d3419af1).
https://bugs.webkit.org/show_bug.cgi?id=315310
Web Extensions: cookies.get() and cookies.getAll() have empty results on
first launch.
https://webkit.org/b/315310
rdar://177380008
Reviewed by Brian Weinstein.
When the network process hasn't launched yet — as is common on the first
cookie query after
app launch — the two cookie-reading methods silently returned empty
results. They now launch
the network process on demand, consistent with the write and observer
methods in the same class.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WKWebExtensionAPICookies.mm
* Source/WebKit/UIProcess/API/APIHTTPCookieStore.cpp:
(API::HTTPCookieStore::cookies): Use `networkProcessLaunchingIfNecessary()`
to launch the network
process on demand rather than silently returning empty results when it
isn't running.
(API::HTTPCookieStore::cookiesForURL): Ditto.
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WKWebExtensionAPICookies.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPICookies,
GetAllAfterNetworkProcessTermination)):
Added. Verifies `browser.cookies.getAll()` returns persisted cookies after
the network process is
killed, simulating a cold-start scenario.
Canonical link: https://commits.webkit.org/313745@main
Canonical link: https://commits.webkit.org/305877.675@webkitglib/2.52
Commit: 69676a7d341e3c7bdc01d7f4a85d835b9fa68220
https://github.com/WebKit/WebKit/commit/69676a7d341e3c7bdc01d7f4a85d835b9fa68220
Author: Sihui Liu <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
Log Message:
-----------
Cherry-pick 313427@main (113cf2c7cf54).
https://bugs.webkit.org/show_bug.cgi?id=314963
Check m_closed in NetworkStorageManager::donePrepareForEviction
https://bugs.webkit.org/show_bug.cgi?id=314963
rdar://177256813
Reviewed by Per Arne Vollan.
donePrepareForEviction is dispatched to the work queue from an async
callback on the main thread. Between the m_closed
check in the callback and the execution on the work queue, close() can be
called, setting m_closed and scheduling
cleanup of m_originStorageManagers. Add the same m_closed early return that
donePrepareForTimeBasedEviction already has
for consistency and safety.
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::donePrepareForEviction):
Canonical link: https://commits.webkit.org/313427@main
Canonical link: https://commits.webkit.org/305877.676@webkitglib/2.52
Commit: 329f5aac08ad84a7bb7298b5102385428d2f96ae
https://github.com/WebKit/WebKit/commit/329f5aac08ad84a7bb7298b5102385428d2f96ae
Author: Philippe Normand <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp
M Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.h
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
Log Message:
-----------
Cherry-pick 313830@main (cb7ccd0d2919).
https://bugs.webkit.org/show_bug.cgi?id=315459
[GStreamer] Possible pipeline leak when the owning media element id is
updated
https://bugs.webkit.org/show_bug.cgi?id=315459
Reviewed by Xabier Rodriguez-Calvar.
Keep track of the initial player pipeline name and use it for storage in
the global pipelines
hashmap.
Driving-by, clean-up some more GstElement smart pointers during tear-down
and avoid one string copy
when logging media element id updates.
* Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp:
(WebCore::registerActivePipeline):
(WebCore::unregisterPipeline):
* Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.h:
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::tearDown):
(WebCore::MediaPlayerPrivateGStreamer::elementIdChanged const):
(WebCore::MediaPlayerPrivateGStreamer::createGSTPlayBin):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
Canonical link: https://commits.webkit.org/313830@main
Canonical link: https://commits.webkit.org/305877.677@webkitglib/2.52
Commit: c6455697e7908d6b46ffc81741dabee2c7e349f5
https://github.com/WebKit/WebKit/commit/c6455697e7908d6b46ffc81741dabee2c7e349f5
Author: Simon Pena <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M
LayoutTests/compositing/clipping/border-radius-async-overflow-stacking.html
M LayoutTests/svg/compositing/svg-poster-circle.html
M Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp
Log Message:
-----------
Cherry-pick 312802@main (74a41b5f4ec4).
https://bugs.webkit.org/show_bug.cgi?id=314201
[TextureMapper] Round-clip shader needs highp on PowerVR B-Series
https://bugs.webkit.org/show_bug.cgi?id=314201
Reviewed by Miguel Gomez.
The GLSL helpers used by applyRoundedRectClip (ellipsisDist,
ellipsisCoverage, roundedRectCoverage) compute corner coverage as
(dot(p0,p0) - 1.0) / length(p1). On some proprietary GLES drivers this
form is miscomputed under mediump (fp16). Reproduced on PowerVR
B-Series (Imagination DDK 24.1@6554834): ellipsisCoverage returns 0
for fragments well inside the inscribed ellipse, so descendants under
a 'border-radius + overflow:hidden' ancestor render as solid
coverage=0 (silent black) instead of being correctly clipped.
The fix here is to promote precision on the round-clip path only:
* v_nonProjectedPosition varying (vertex + fragment templates)
* u_roundedRect, u_roundedRectInverseTransformMatrix uniforms
* parameters and locals in ellipsisDist, ellipsisCoverage,
roundedRectCoverage
* locals in applyRoundedRectClip (fragCoord, bounds, *Radii)
This keeps mediump for the rest of the fragment shader (filters,
blur, tone-map) so the cost is confined to the round-clip path.
Tested on device, glitch is gone. The same issue can be reproduced using
WebGL, so a separate bug to Imagination might need to be raised.
Updated layout tests to add a bit more leeway due to the changes in the
shader (no visual difference at plain sight).
*
LayoutTests/compositing/clipping/border-radius-async-overflow-stacking.html:
* LayoutTests/svg/compositing/svg-poster-circle.html:
* Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp:
Canonical link: https://commits.webkit.org/312802@main
Canonical link: https://commits.webkit.org/305877.678@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/f08217b73040...c6455697e790
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
