Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: b33979e7f5b250fe10c11836ce2cff8cd0a39108
https://github.com/WebKit/WebKit/commit/b33979e7f5b250fe10c11836ce2cff8cd0a39108
Author: Nikolas Zimmermann <[email protected]>
Date: 2026-09-29 (Tue, 29 Sep 2026)
Changed paths:
M Source/WebCore/platform/graphics/PlatformDisplay.cpp
M Source/WebCore/platform/graphics/PlatformDisplay.h
M Source/WebCore/platform/graphics/egl/GLContext.cpp
M Source/WebCore/platform/graphics/egl/GLDisplay.cpp
M Source/WebCore/platform/graphics/egl/GLDisplay.h
M Source/WebCore/platform/graphics/skia/PlatformDisplaySkia.cpp
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.h
M Source/WebKit/GPUProcess/GPUProcess.h
M Source/WebKit/GPUProcess/glib/GPUProcessGLib.cpp
M Source/WebKit/Shared/AuxiliaryProcess.cpp
M Source/WebKit/WebProcess/WebProcess.cpp
M Source/WebKit/WebProcess/WebProcess.h
M Source/WebKit/WebProcess/glib/WebProcessGLib.cpp
Log Message:
-----------
Cherry-pick 321775@main (e0b1fddaa468).
https://bugs.webkit.org/show_bug.cgi?id=305909
[GTK][WPE] Crash on exit in PlatformDisplay::terminateEGLDisplay
https://bugs.webkit.org/show_bug.cgi?id=305909
rdar://problem/168564545
Reviewed by Carlos Garcia Campos.
The EGL display was terminated in an atexit handler while other threads
could
still use it. In the GPU process, the WebGL thread could still be using the
sharing context when the handler destroyed it. In the web process, a thread
that exits destroys its Skia context at the same time, and because Mesa
frees
the display in its own atexit handler, that thread writes into freed memory
and corrupts the heap, which is bug 315577.
Destroy the display on the main thread before exiting instead, after the GPU
process has closed its web process connections and stopped the WebGL thread,
and after the web process has closed its pages. The display is terminated
before it is deleted, so that the native display of a subclass, like the
libwpe backend, is still alive when EGL terminates. A thread that destroys
its
context while the display is terminated now waits for it, and does nothing
once the display is gone.
* Source/WebCore/platform/graphics/PlatformDisplay.cpp:
(WebCore::PlatformDisplay::setSharedDisplay):
(WebCore::PlatformDisplay::sharedDisplayIfExists):
(WebCore::PlatformDisplay::destroySharedDisplay):
(WebCore::PlatformDisplay::PlatformDisplay):
(WebCore::PlatformDisplay::terminateEGLDisplay):
(WebCore::PlatformDisplay::~PlatformDisplay): Deleted.
* Source/WebCore/platform/graphics/PlatformDisplay.h:
* Source/WebCore/platform/graphics/egl/GLContext.cpp:
(WebCore::GLContext::~GLContext):
* Source/WebCore/platform/graphics/egl/GLDisplay.cpp:
(WebCore::GLDisplay::terminate):
(WebCore::GLDisplay::runIfNotTerminated):
* Source/WebCore/platform/graphics/egl/GLDisplay.h:
* Source/WebCore/platform/graphics/skia/PlatformDisplaySkia.cpp:
(WebCore::SkiaGLContext::~SkiaGLContext):
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.h:
(WebKit::GPUConnectionToWebProcess::close):
* Source/WebKit/GPUProcess/GPUProcess.h:
* Source/WebKit/GPUProcess/glib/GPUProcessGLib.cpp:
(WebKit::GPUProcess::stopRunLoop):
* Source/WebKit/Shared/AuxiliaryProcess.cpp:
(WebKit::AuxiliaryProcess::didClose):
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeConnection):
* Source/WebKit/WebProcess/WebProcess.h:
* Source/WebKit/WebProcess/glib/WebProcessGLib.cpp:
(WebKit::WebProcess::stopRunLoop):
Canonical link: https://commits.webkit.org/321775@main
Canonical link: https://commits.webkit.org/317695.368@webkitglib/2.54
Commit: 735b06718a72f39a410d6259275e1ed02188e324
https://github.com/WebKit/WebKit/commit/735b06718a72f39a410d6259275e1ed02188e324
Author: Fujii Hironori <[email protected]>
Date: 2026-09-29 (Tue, 29 Sep 2026)
Changed paths:
M Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp
M Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp
Log Message:
-----------
Cherry-pick 322026@main (4cca1a6fbd86).
https://bugs.webkit.org/show_bug.cgi?id=325395
[GLib][Flatpak] Web processes are silently spawned without a sandbox if the
app's working directory is not visible in the flatpak-spawn sub-sandbox
https://bugs.webkit.org/show_bug.cgi?id=325395
Reviewed by Patrick Griffis.
flatpak-spawn uses the caller's current working directory by default,
but the --sandbox sub-sandbox doesn't have the app's filesystem
permissions. If the app was started from such a directory,
isFlatpakSpawnUsable() failed with "bwrap: Can't chdir to ...", and
all web processes were spawned without a sandbox.
Pass --directory=/ to flatpak-spawn --sandbox both in
isFlatpakSpawnUsable() and flatpakSpawn(). --directory is supported
since flatpak-xdg-utils 1.0.1, which we already require.
Also log a warning when flatpak-spawn --sandbox is not usable.
* Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp:
(WebKit::flatpakSpawn):
* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:
(WebKit::isFlatpakSpawnUsable):
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Canonical link: https://commits.webkit.org/322026@main
Canonical link: https://commits.webkit.org/317695.369@webkitglib/2.54
Commit: 5aa9856275e9420808bf186af899fe6cf0dd61e7
https://github.com/WebKit/WebKit/commit/5aa9856275e9420808bf186af899fe6cf0dd61e7
Author: Nikolas Zimmermann <[email protected]>
Date: 2026-09-29 (Tue, 29 Sep 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/backdrop-filter-over-earlier-backdrop-filter-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/backdrop-filter-over-earlier-backdrop-filter-ref.html
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/backdrop-filter-over-earlier-backdrop-filter.html
M Source/WebCore/platform/graphics/skia/SkiaCompositingLayer.cpp
Log Message:
-----------
Cherry-pick 322150@main (bab8a55628ba).
https://bugs.webkit.org/show_bug.cgi?id=325626
[GTK][WPE] backdrop-filter misses the backdrop-filter of earlier elements
https://bugs.webkit.org/show_bug.cgi?id=325626
Reviewed by Carlos Garcia Campos.
The Skia compositor paints the backdrop of a layer by painting the subtree
of
its backdrop root again, without any of the backdrop filters in it. An
earlier
layer with a backdrop filter of its own, which is not an ancestor of the
filtered layer, therefore showed up in the backdrop without its filter.
Only skip the backdrop filter of the layer whose backdrop is being painted.
The backdrop of an earlier layer is painted the same way, and stops at that
earlier layer, so the recursion ends there and never comes back to the later
layer.
Add a new WPT test to cover this scenario.
Test:
imported/w3c/web-platform-tests/css/filter-effects/backdrop-filter-over-earlier-backdrop-filter.html
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/backdrop-filter-over-earlier-backdrop-filter-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/backdrop-filter-over-earlier-backdrop-filter-ref.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/backdrop-filter-over-earlier-backdrop-filter.html:
Added.
* Source/WebCore/platform/graphics/skia/SkiaCompositingLayer.cpp:
(WebCore::SkiaCompositingLayer::paintWithMaskAndBackdrop):
Canonical link: https://commits.webkit.org/322150@main
Canonical link: https://commits.webkit.org/317695.370@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/23666af38314...5aa9856275e9
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
