Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 77c629c048ea6b430a7bebdb675dec803b313208
https://github.com/WebKit/WebKit/commit/77c629c048ea6b430a7bebdb675dec803b313208
Author: Simon Pena <[email protected]>
Date: 2026-06-29 (Mon, 29 Jun 2026)
Changed paths:
M Source/WebKit/Shared/glib/ArgumentCodersGLib.cpp
Log Message:
-----------
Cherry-pick 315892@main (ac70e863fb9d).
https://bugs.webkit.org/show_bug.cgi?id=317922
Regression(278316@main): [GLIB] IPC encoder desyncs on certificate
extraction failure
https://bugs.webkit.org/show_bug.cgi?id=317922
Reviewed by Claudio Saavedra.
ArgumentCoder<GRefPtr<GTlsCertificate>>::decode() unconditionally reads
a vector of cert data as its first field. The encoder, however, fails to
write anything if the certificate fails to produce its DER data. This
means that the decoder will go out of sync, reading subsequent elements
as if they were the certificate, which in turn can cause intermittent
crashes afterwards.
This is a regression from 278316@main. Before its refactoring, the
certificate size was unconditionally written, and when 0 the decoder
would handle it appropriately. After the refactoring, empty certificates
are skipped, and the 0 size is not communicated. This ensures an empty
vector is encoded on the failure path, so that decoder and encoder are
kept in sync.
No new tests: this would probably require IPC API tests to run for GLib
platforms.
* Source/WebKit/Shared/glib/ArgumentCodersGLib.cpp:
(IPC::ArgumentCoder<GRefPtr<GTlsCertificate>>::encode):
Canonical link: https://commits.webkit.org/315892@main
Canonical link: https://commits.webkit.org/305877.796@webkitglib/2.52
Commit: 6f0310c3848c0264644c5f66b6fa92aa0feb7c97
https://github.com/WebKit/WebKit/commit/6f0310c3848c0264644c5f66b6fa92aa0feb7c97
Author: Lauro Moura <[email protected]>
Date: 2026-06-29 (Mon, 29 Jun 2026)
Changed paths:
M Tools/MiniBrowser/wpe/main.cpp
Log Message:
-----------
Cherry-pick 315631@main (e81367bfcb6f).
https://bugs.webkit.org/show_bug.cgi?id=317567
[WPE] Make MiniBrowser exit cleanly on SIGTERM and SIGINT
https://bugs.webkit.org/show_bug.cgi?id=317567
Reviewed by Carlos Garcia Campos.
Instrumenting with `-fprofile-generate` dump the collected data through
atexit handlers. Currently, MiniBrowser do not install any handler on
the catchable signals SIGTERM/SIGINT to exit its mainloop, making it
hard to properly instrument it.
* Tools/MiniBrowser/wpe/main.cpp:
(main):
Canonical link: https://commits.webkit.org/315631@main
Canonical link: https://commits.webkit.org/305877.797@webkitglib/2.52
Commit: c067e9ff28d1d1d9c9bc7463d0ef68308000df82
https://github.com/WebKit/WebKit/commit/c067e9ff28d1d1d9c9bc7463d0ef68308000df82
Author: Michael Catanzaro <[email protected]>
Date: 2026-06-29 (Mon, 29 Jun 2026)
Changed paths:
M Source/WebKit/Shared/glib/JavaScriptEvaluationResultGLib.cpp
M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
Log Message:
-----------
Cherry-pick 315630@main (449035bdfe62).
https://bugs.webkit.org/show_bug.cgi?id=298066
[WPE][GTK] Fix leaks when using g_variant_iter_loop()
https://bugs.webkit.org/show_bug.cgi?id=298066
Reviewed by Patrick Griffis.
Milan pointed out that if we break out of a g_variant_iter_loop() loop,
then it cannot free the key or value for us. In these cases, we have to
free it manually.
The easiest solution is to just not use g_variant_iter_loop() in these
cases, to ensure we cannot mess up. g_variant_iter_next() is basically
the same thing, except it requires that we handle the ownership.
* Source/WebKit/Shared/glib/JavaScriptEvaluationResultGLib.cpp:
(WebKit::JavaScriptEvaluationResult::GLibExtractor::toValue):
(WebKit::isSerializable):
* Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:
(parseAsyncFunctionArguments):
Canonical link: https://commits.webkit.org/315630@main
Canonical link: https://commits.webkit.org/305877.798@webkitglib/2.52
Commit: bd214b43c980d69eec6c00ffd19699f430de9563
https://github.com/WebKit/WebKit/commit/bd214b43c980d69eec6c00ffd19699f430de9563
Author: Simon Pena <[email protected]>
Date: 2026-06-29 (Mon, 29 Jun 2026)
Changed paths:
M Source/WebCore/platform/network/soup/SoupNetworkSession.cpp
Log Message:
-----------
Cherry-pick 315741@main (db4d5fc97b32).
https://bugs.webkit.org/show_bug.cgi?id=316990
[GTK][WPE] Increase the libsoup idle connection timeout to 115 seconds
https://bugs.webkit.org/show_bug.cgi?id=316990
Reviewed by Patrick Griffis.
Raise the libsoup session idle-connection timeout from the 60s default
to 115s. Keeping idle connections in the pool longer avoids a full
TCP+TLS reconnect when navigating back to a recently-used origin within
a browsing session. This matches Firefox's default
(network.http.keep-alive.timeout = 115); Chrome keeps used idle sockets
for 300s.
No new tests, behavior change is a timeout tuning value.
* Source/WebCore/platform/network/soup/SoupNetworkSession.cpp:
(WebCore::SoupNetworkSession::SoupNetworkSession):
Canonical link: https://commits.webkit.org/315741@main
Canonical link: https://commits.webkit.org/305877.799@webkitglib/2.52
Commit: 087748fb24107905a790a2d5b90a617582947fb8
https://github.com/WebKit/WebKit/commit/087748fb24107905a790a2d5b90a617582947fb8
Author: Nikolas Zimmermann <[email protected]>
Date: 2026-06-29 (Mon, 29 Jun 2026)
Changed paths:
M Tools/Scripts/webkitdirs.pm
Log Message:
-----------
Cherry-pick 315809@main (b74c6193c14d).
https://bugs.webkit.org/show_bug.cgi?id=317782
[GTK][WPE] Regenerate CMake cache when .wkdev-sdk-version changes
https://bugs.webkit.org/show_bug.cgi?id=317782
Reviewed by Adrian Perez de Castro.
A new wkdev-sdk image can ship a different toolchain and dependencies,
which can influence the generated CMake cache. Invalidate the cache in
shouldRemoveCMakeCache() when .wkdev-sdk-version is newer than
CMakeCache.txt, mirroring the existing mtime-based check for *.cmake
files under Source/cmake.
* Tools/Scripts/webkitdirs.pm:
(shouldRemoveCMakeCache):
Canonical link: https://commits.webkit.org/315809@main
Canonical link: https://commits.webkit.org/305877.800@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/a8c7fc7d1b73...087748fb2410
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
