Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 1ea829ecfcf7acc0504a8a9441eafce60482f312
https://github.com/WebKit/WebKit/commit/1ea829ecfcf7acc0504a8a9441eafce60482f312
Author: Thomas Klausner <[email protected]>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M Source/WTF/wtf/glib/FileSystemGlib.cpp
Log Message:
-----------
Cherry-pick 312615@main (4bbc7d631326).
https://bugs.webkit.org/show_bug.cgi?id=313992
Adapt for procfs differences between NetBSD and other operating systems.
https://bugs.webkit.org/show_bug.cgi?id=313992
Reviewed by Claudio Saavedra.
NetBSD does support procfs, but there are some differences. One is
that the link to the executable is not `/proc/curproc/file` but
`/proc/curproc/exe`. This causes an error message on the console.
This error also showed an off-by-one - glib2 doesn't like creating
file names from strings of length zero - fixed as well.
* Source/WTF/wtf/glib/FileSystemGlib.cpp:
(WTF::FileSystemImpl::currentExecutablePath):
Canonical link: https://commits.webkit.org/312615@main
Canonical link: https://commits.webkit.org/305877.476@webkitglib/2.52
Commit: c68cfbfe29ab04c5e3ffc5001b9ef7cc955a118e
https://github.com/WebKit/WebKit/commit/c68cfbfe29ab04c5e3ffc5001b9ef7cc955a118e
Author: Simon Pena <[email protected]>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp
Log Message:
-----------
Cherry-pick 312599@main (f8fc733a908e).
https://bugs.webkit.org/show_bug.cgi?id=313824
[GLib] webkit://gpu: Guard GL queries against missing EGL context
https://bugs.webkit.org/show_bug.cgi?id=313824
Reviewed by Patrick Griffis.
On embedded devices without libGL.so.1 or libOpenGL.so.0, calling
openGLAPI() triggers libepoxy to dlopen those libraries to probe the GL
type when no EGL context is current, resulting in an abort.
Guard the openGLAPI() call behind the same eglGetCurrentContext() check
already used for addEGLInfo(), and show "Not available" when no context
exists. The render process section still displays GL info from its own
context via IPC.
Tested on device without these libraries.
* Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp:
(WebKit::WebKitProtocolHandler::handleGPU):
Canonical link: https://commits.webkit.org/312599@main
Canonical link: https://commits.webkit.org/305877.477@webkitglib/2.52
Commit: c85fc2cbfcf7b4d5552cafe71f4875f2c798d74c
https://github.com/WebKit/WebKit/commit/c85fc2cbfcf7b4d5552cafe71f4875f2c798d74c
Author: Simon Pena <[email protected]>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M Source/WTF/wtf/FileSystem.cpp
M Source/WTF/wtf/PlatformHave.h
Log Message:
-----------
Cherry-pick 312611@main (15b0198087a9).
https://bugs.webkit.org/show_bug.cgi?id=313815
[Linux] Handle ENOSPC on NetworkProcess cache mmap writes
https://bugs.webkit.org/show_bug.cgi?id=313815
Reviewed by Adrian Perez de Castro.
If the filesystem runs out of space when the NetworkProcess is writing
into its cache, BlobStorage::add will get SIGBUS when memcpy'ing into a
MAP_SHARED mapping.
By using fallocate immediately after ftruncate, we attempt to reserve
the blocks needed. This allows us to handle ENOSPC, returning an empty
MappedFileData, something already handled by skipping caching the entry.
If EOPNOTSUPP is received, we keep the existing behaviour and progress
-- which might or might not lead to a later SIGBUS.
Doing this exposed a latent leak in createMappedFileData, where files
would survive early returns on error scenarios. A scope guard now
ensures that files are unlinked in error scenarios, which ensures that
the corresponding read paths avoid reading from leftover orphan files.
A new HAVE(FALLOCATE) has been added, defined only in Linux. Darwin or
other systems would probably want their own analogous operation.
Tested manually by creating a small tmpfs, then pointing --profile-dir to
it and navigating. Before the fix, this would consistently trigger a
SIGBUS. After the fix, this logs an error mmapping but continues
unaffected.
* Source/WTF/wtf/FileSystem.cpp:
(WTF::FileSystemImpl::createMappedFileData):
* Source/WTF/wtf/PlatformHave.h:
Canonical link: https://commits.webkit.org/312611@main
Canonical link: https://commits.webkit.org/305877.478@webkitglib/2.52
Commit: e4a0bf93ddf7ccf94417c6da111397e009d93de9
https://github.com/WebKit/WebKit/commit/e4a0bf93ddf7ccf94417c6da111397e009d93de9
Author: Vitaly Dyachkov <[email protected]>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M Source/WebKit/WPEPlatform/wpe/wayland/WPEWaylandSeat.cpp
Log Message:
-----------
Cherry-pick 312604@main (13af2406270c).
https://bugs.webkit.org/show_bug.cgi?id=313976
[WPE] Send touch cancel event on losing touch capability
https://bugs.webkit.org/show_bug.cgi?id=313976
Reviewed by Carlos Garcia Campos.
Currently, when touch capability is lost, we reset all related data, but
do not notify the page. This may cause some UI elements, such as
buttons, to appear "stuck" in pressed state.
This change sends a touch cancel event for each touch point to let the
page update its state.
* Source/WebKit/WPEPlatform/wpe/wayland/WPEWaylandSeat.cpp:
Canonical link: https://commits.webkit.org/312604@main
Canonical link: https://commits.webkit.org/305877.479@webkitglib/2.52
Commit: 8da736e1c95bd1398a89a0ac6b818cc1d9d7a857
https://github.com/WebKit/WebKit/commit/8da736e1c95bd1398a89a0ac6b818cc1d9d7a857
Author: Vivienne Watermeier <[email protected]>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
A
LayoutTests/media/media-source/content/test-h264-bframes-lowfps-manifest.json
A LayoutTests/media/media-source/content/test-h264-bframes-lowfps.mp4
A
LayoutTests/media/media-source/media-source-h264-bframes-lowfps-expected.txt
A LayoutTests/media/media-source/media-source-h264-bframes-lowfps.html
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp
Log Message:
-----------
Cherry-pick 312603@main (a3dfc3da7f4d).
https://bugs.webkit.org/show_bug.cgi?id=309824
[GStreamer][MSE] Some Youtube videos don't play
https://bugs.webkit.org/show_bug.cgi?id=309824
Reviewed by Philippe Normand.
We currently don't apply MP4 edit lists, so in the case of b-frames,
we may not have a starting presentation time of 0.
This would break playback, so to work around this we try to
extend the first sample to fill this gap, if necessary.
However, if such a gap is present, we can never know for sure which
sample is truly the first one in presentation order, since appends
may happen out-of-order - so we may always see an earlier sample in
the next append. This means we need to make a best-effort guess
how much of a gap we reasonably expect to see before the first sample,
which is a bit of a tightrope act:
- set the threshold too high, and we might fall for an out-of-order append,
and end up extending the wrong sample,
- set it too low, and we might not recognize larger gaps.
Currently, this threshold is at 100ms, the idea being that this
fits 2 frames at 24 FPS, which you may consider the lowest "commonly"
used framerate.
The video in question here [1] is a podcast, and is thus only encoded
at 6 FPS, i.e. about 167ms per frame.
To fix this, I've increased the threshold to 1 second, based on the
assumption that segments will usually not have a duration lower than that.
In return, this should fix playback for media with lower framerates,
down to 1-2 FPS.
[1]: https://youtu.be/fr5na1EZbtk?si=OKyfxUm2J_YbO44K
Test: media/media-source/media-source-h264-bframes-lowfps.html
*
LayoutTests/media/media-source/content/test-h264-bframes-lowfps-manifest.json:
Added.
* LayoutTests/media/media-source/content/test-h264-bframes-lowfps.mp4:
Added, short file at 6 FPS, using bframes.
*
LayoutTests/media/media-source/media-source-h264-bframes-lowfps-expected.txt:
Added.
* LayoutTests/media/media-source/media-source-h264-bframes-lowfps.html:
Added, just tests playback.
* LayoutTests/platform/mac-wk2/TestExpectations: Flag the new test for
mac-intel-wk2.
* Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
(WebCore::AppendPipeline::appsinkNewSample): Increase threshold.
Canonical link: https://commits.webkit.org/312603@main
Canonical link: https://commits.webkit.org/305877.480@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/85e528121e39...8da736e1c95b
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
