Update on what happened in WebKit in the week from March 23 to March 30.<\/p>\n
\nThis week comes with a mixed bag of new features, incremental improvements,\nand a new release with the ever important security issue fixes. Also: more\nblog posts!\n<\/p>\n
Implemented<\/a> initial support for\n Added<\/a> the remaining values for the\nexperimental MiniBrowser now has<\/a> a\n GStreamer-based multimedia support for WebKit, including (but not limited to)\nplayback, capture, WebAudio, WebCodecs, and WebRTC.<\/p>\n<\/div>\n Video decoding limits had been enforced on Fixed<\/a> several OpenGL state\nrestoration bugs in The New, modern platform API that supersedes usage of libwpe and WPE backends.<\/p>\n<\/div>\n The new A new WebKitGTK\n2.52.1<\/a> and\nWPE WebKit 2.52.1<\/a> have\nbeen released. On top of a small corrections typical of the first point\nreleases in a new stable series, this one includes a number of fixes for\nsecurity issues, and it is a recommended update. The corresponding security\nadvisory, Sim\u00f3n Pena wrote a blog post showing how to create a minimal WPE\nlauncher<\/a>,\nwhich uses a Fedora Podman container with pre-built WPE WebKit libraries and a\nlauncher with barely 10 lines of code to display a web view. This complements\nKate Lee's custom HTML context menu blog\npost<\/a>\nfrom last week.<\/p>\n <\/div>\n That\u2019s all for this week!<\/p>\n<\/div> ","pubDate":"Mon, 30 Mar 2026 21:46:57 +0000"},{"title":"Igalia WebKit Team: WebKit Igalia Periodical #60","guid":"https:\/\/blogs.igalia.com\/webkit\/blog\/2026\/wip-60\/","link":"https:\/\/blogs.igalia.com\/webkit\/blog\/2026\/wip-60\/","description":"\n Update on what happened in WebKit in the week from March 10 to March 18.<\/p>\n \nThe big ticket item in this week's update are the 2.52.0 releases, which\ninclude the work from the last six-month development period, and come with\na security advisory. Meanwhile, WPE-Android also gets a release, and a number\nof featured blog posts.\n<\/p>\n Last week we added support<\/a> to WPE\nMiniBrowser to load settings<\/a> from a key file. This extended the existing\n WebKitGTK\n2.52.0<\/a> and\nWPE WebKit 2.52.0<\/a> are\nnow available. These include the results of the effort made by the team during\nthe last six months, including rendering improvements and performance\noptimizations, better security for WebRTC, a more complete WebXR\nimplementation, and a second preview of the WPEPlatform API for the WPE\nport\u2014among many other changes.<\/p>\n More information about the changes and improvements brought by these major\nreleases can be found at the blog post about WebKitGTK\n2.52<\/a>, and the\ncorresponding one for WPE WebKit\n2.52<\/a>.<\/p>\n Accompanying these releases there is security advisory Bug reports are always welcome at the WebKit\nBugzilla<\/a>.<\/p>\n <\/div>\n WPE Android 0.3.3<\/a> has been released, and prebuilt packages are available at the Maven Central repository<\/a>. This is a maintenance release which updates the included WPE WebKit version to 2.50.6 and libsoup to 3.6.6, both of which include security fixes.<\/p>\n <\/div>\n Kate Lee wrote a very interesting blog\npost<\/a>\nshowing how to create a small application using the WPEPlatform API to\ndemonstrate one of its newly available features: the Context Menu API. It is\nrendered entirely as an HTML overlay, enabling richer and more portable context\nmenu implementations.<\/p>\n <\/div>\n WebXR support for WebKitGTK and WPE has been reworked and aligned with the\nmodern multi-process architecture, using OpenXR to enable XR device integration\non Linux and Android. Sergio Villar wrote a blog post that explains all the\nwork done<\/a> in the\nlast months around it.<\/p>\n <\/div>\n That\u2019s all for this week!<\/p>\n<\/div> ","pubDate":"Wed, 18 Mar 2026 19:46:56 +0000"},{"title":"WPE WebKit Blog: WPE WebKit 2.52 highlights","guid":"https:\/\/wpewebkit.org\/blog\/2026-03-18-wpewebkit-2.52.html","link":"https:\/\/wpewebkit.org\/blog\/2026-03-18-wpewebkit-2.52.html","description":"\n The WebKit team at Igalia is happy to announce a new release series of WPE WebKit. This is a summary of the most noteworthy changes from the latest release cycle.<\/p>\n WPE\u2019s graphics support has seen numerous improvements with a positive impact in rendering performance, resource usage, and better rendering. Let\u2019s have a look at some of the most significant changes:<\/p>\n On top of this, as usual, many rendering issues have been fixed, making this release of WPE one of the best in terms of graphics support.<\/p>\n When using Having WebRTC network access in the network process is a security improvement, as it reduces the surface of attack in other more sensitive processes.<\/p>\n WebXR support through OpenXR has seen substantial development this cycle:<\/p>\n The traditional This means that it is the perfect time to test the WPEPlatform API and provide feedback, as it\u2019s still possible to make changes to it to better suit users\u2019 needs.<\/p>\n New platform APIs include:<\/p>\n The public API has received the following changes, which might require changes to existing platform implementations:<\/p>\n The WPEPlatform API can now be used on Android.<\/p>\n The legacy As usual, this list is not exhaustive as WebKit continuously progresses in its support for new standards. Some of the highlights for this release are:<\/p>\n The Flatpak-based development SDK has been removed. Developers are encouraged to use the\nWebKit Container SDK<\/strong><\/a> instead.<\/p> ","pubDate":"Wed, 18 Mar 2026 00:00:00 +0000"},{"title":"Sergio Villar: Implementing WebXR in WebKit for WPE","guid":"https:\/\/blogs.igalia.com\/svillar\/post\/wpe-webxr\/","link":"https:\/\/blogs.igalia.com\/svillar\/post\/wpe-webxr\/","description":"\n Since 2022, my main focus has been working on the Wolvic browser<\/a>, still the only open source WebXR-capable browser for Android\/AOSP devices (Meta, Pico, Huawei, Lenovo, Lynx, HTC…) out there. That’s an effort that continues to this day (although to a much lesser extent nowadays<\/a>). In early 2025, as a consequence of all that work in XR on the web, an opportunity emerged to implement WebXR support in WebKit for the WPE port, and we decided to take it.<\/p> ","pubDate":"Tue, 17 Mar 2026 08:46:59 +0000"},{"title":"Kate Lee: Building a Custom HTML Context Menu with the New WPEPlatform API","guid":"https:\/\/blogs.igalia.com\/klee\/building-a-custom-html-context-menu-with-the-new-wpeplatform-api\/","link":"https:\/\/blogs.igalia.com\/klee\/building-a-custom-html-context-menu-with-the-new-wpeplatform-api\/","description":"\n WPE WebKit<\/a> is a WebKit port optimized for embedded devices \u2014 think set-top boxes, digital signage, kiosk displays, and in-vehicle infotainment systems. It is developed by Igalia<\/a> and powers web experiences on millions of devices worldwide, from set-top boxes to smart TVs and beyond.<\/p>\n WPE WebKit has recently introduced a brand-new platform API called WPEPlatform<\/strong>, which replaces the legacy The legacy stack ( The new WPEPlatform API<\/strong> replaces all of this with a single, clean GObject<\/a>-based layer \u2014 providing automatic backend creation, DMA-BUF direct buffer sharing, unified window management (fullscreen, maximize, resize, title), and easy language bindings via GObject Introspection.<\/p>\n Timeline<\/strong>: The stable release of WPEPlatform is planned for September 2026<\/strong>. At that point, the legacy API will be officially deprecated. We strongly recommend new projects to adopt the WPEPlatform API from the start.<\/p>\n<\/blockquote>\n To demonstrate the new API, I built WPEPlatformLauncher<\/strong> \u2014 a minimal but functional WPE WebKit browser that uses only the WPEPlatform API. No legacy The full source code is available at:\nkate-k-lee\/WebKit@aed6402<\/a><\/strong><\/p>\n Here is the core of the launcher \u2014 creating a WebView with the new API:<\/p>\nclosedby=any<\/code> on dialog elements, which adds light dismiss behaviour. This is\nbehind the ClosedbyAttributeEnabled<\/code> feature flag.<\/p>\n <\/div>\n closedby<\/code> attribute implementation.<\/p>\n <\/div>\n --profile-dir=DIR<\/code> command line option that can be used to specify a custom\ndirectory where website data and cache can be stored, to test, for example,\nbehavior in a clean session.<\/p>\n <\/div>\nMultimedia \ud83c\udfa5<\/h3>\n
HTMLMediaElement.canPlayType()<\/code> so\nfar, but they are now also enforced in MediaCapabilities\nqueries<\/a>.<\/p>\n <\/div>\nGraphics \ud83d\uddbc\ufe0f<\/h3>\n
BitmapTexture<\/code> . These could cause a mismatch between the\nGL state assumed by Skia and the actual one, leading to rendering artifacts\nwith certain GPU drivers and configurations.<\/p>\n <\/div>\n SKIA_DEBUG<\/code> CMake option has been\nenabled<\/a> for Debug<\/code> builds, enabling\nSkia's internal assertions, debug logging, and consistency checks (e.g. bounds\nchecking, resource key diagnostics). It remains off by default for Release<\/code>\nand RelWithDebInfo<\/code> builds, and can still be explicitly configured via\n-DSKIA_DEBUG=ON|OFF<\/code>.<\/p>\n <\/div>\nWPE WebKit \ud83d\udcdf<\/h2>\n
WPE Platform API \ud83e\udde9<\/h3>\n
WPE_SETTING_OVERLAY_SCROLLBARS<\/code> setting is now\navailable<\/a>, and disabling it will use a\nmore traditional, always visible scrollbar style.<\/p>\n <\/div>\nReleases \ud83d\udce6\ufe0f<\/h2>\n
USE_GSTREAMER<\/code> build option may now be\nused<\/a> to toggle the features that\nrequire GStreamer at once. This can be used to effectively disable all\nmultimedia support, which previously needed toggling four CMake options.<\/p>\n <\/div>\n WSA-2026-0002<\/code>\n(GTK<\/a>,\nWPE<\/a>) has been published as\nwell.<\/p>\n <\/div>\nCommunity & Events \ud83e\udd1d<\/h2>\n
WPE WebKit \ud83d\udcdf<\/h2>\n
--config-file=FILE<\/code> feature, which previously only loaded WPEPlatform\nsettings under the [wpe-platform]<\/code> group. Now the feature uses\nwebkit_settings_apply_from_key_file()<\/a>\nto load properties such as user-agent<\/code> or enable-developer-extras<\/code>\nfrom the [websettings]<\/code> group as well.<\/p>\n <\/div>\nReleases \ud83d\udce6\ufe0f<\/h2>\n
WSA-2026-0001<\/code>\n(GTK<\/a>,\nWPE<\/a>), with information\nabout solved security issues. As usual, we encourage everybody to use the most\nrecent versions where such issues are known to be fixed.<\/p>\nCommunity & Events \ud83e\udd1d<\/h2>\n
Graphics improvements<\/h2>\n
\n
Multimedia improvements<\/h2>\n
WebRTC<\/h3>\n
GstWebRTC<\/code>, WebRTC network access has been moved to the network process. This also requires librice, and building with the CMake USE_LIBRICE<\/code> option. When this is enabled, it is still possible to choose the older libnice-based implementation at runtime by setting WEBKIT_GST_DISABLE_WEBRTC_NETWORK_SANDBOX=1<\/code> in the environment.<\/p>\nOther multimedia improvements<\/h3>\n
\n
ExposeSpeakers<\/code>, ExposeSpeakersWithoutMicrophone<\/code>, and PerElementSpeakerSelection<\/code> feature flags<\/a>.<\/li>\nWebXR<\/h2>\n
\n
--features=+WebXRHitTestModule<\/code>) or at build time passing -DENABLE_WEBXR_HIT_TEST=ON<\/code>.<\/li>\n<\/ul>\nAPI Changes<\/h2>\n
The future of the WPE API<\/h3>\n
libwpe<\/code>-based API remains in WPE for this release cycle, but we are planning to sunset it starting with the following one (2.54). This applies to Cog<\/a>, which is no longer in active development and won\u2019t have any more stable releases beyond the 0.18.x series. While both libwpe<\/code> and Cog will remain available, we encourage developers to transition to the new WPEPlatform API, which will be considered stable by then.<\/p>\nWPEPlatform API changes<\/h3>\n
\n
wpe_display_create_toplevel()<\/code><\/a>. This way it\u2019s possible to create a toplevel using the common API which allows the inspector to work when the application is handling toplevels.<\/li>\nWPEDisplay::disconnected<\/code><\/a> signal has been added, which allows platform implementations to notify when the native display gets \u201cdisconnected\u201d and thus no longer usable. Applications can handle it to attempt recovery, or to know when they may free resources.<\/li>\nWPEView::buffers-changed<\/code><\/a> signal, alongside the associated WPEViewClass.buffers_changed<\/code><\/a> virtual function, have been added. These may be used to know in advance which graphics buffers will be used for rendering the content for a given web view. This feature is mainly useful for platform implementations which may need to perform additional setup in advance, before updated web view contents are provided in the buffers configured by WebKit.<\/li>\nwpe_clipboard_content_get_text()<\/code><\/a> and wpe_clipboard_content_get_bytes()<\/code><\/a>, allow applications to obtain the contents held in the clipboard.<\/li>\n<\/ul>\n\n
WPEScreenSyncObserver<\/code>, the API has changed from wpe_screen_sync_observer_set_callback()<\/code> to a pair of wpe_screen_sync_observer_add_callback()<\/code><\/a>\/_remove_callback()<\/code><\/a> functions. The functions to start\/stop the observer are no longer available, and instead the observer will be activated automatically when there are one or more callbacks attached to it.<\/li>\n<\/ul>\nLegacy API<\/h3>\n
libwpe<\/code>-based API can be disabled at build time, by toggling the ENABLE_WPE_LEGACY_API<\/code> CMake option. This allows removal of uneeded code when an application is exclusively using the new WPEPlatform API.<\/p>\nNew WebKit API<\/h3>\n
\n
Web Standards support<\/h2>\n
\n
Other notes<\/h2>\n
libwpe<\/code> + wpebackend-fdo<\/code> stack. In this post, I will walk you through building a minimal WPE browser launcher using only the new WPEPlatform API<\/strong>, and demonstrate one of its newly available features: the Context Menu API<\/strong> \u2014 rendered entirely as an HTML overlay.<\/p>\nWhy a New API? #<\/a><\/h2>\n
libwpe<\/code> + wpebackend-fdo<\/code> + Cog platform plugins) had several pain points: nested Wayland compositor complexity, dependency on Mesa\u2019s now-deprecated EGL_WL_bind_wayland_display<\/code> extension, rigid C function-pointer tables, and platform code scattered across three libraries.<\/p>\n\n
WPEPlatform Launcher: A Minimal Browser in ~250 Lines #<\/a><\/h2>\n
libwpe<\/code>, no wpebackend-fdo<\/code>, no Cog \u2014 just the new API.<\/p>\nHow Simple Is It? #<\/a><\/h3>\n
\/* WPEPlatform backend is created automatically \u2014 no manual setup needed *\/<\/span>
auto<\/span>*<\/span> webView =<\/span> WEBKIT_WEB_VIEW<\/span>(<\/span>g_object_new<\/span>(<\/span>WEBKIT_TYPE_WEB_VIEW,<\/span>
\"web-context\"<\/span>,<\/span> webContext,<\/span>
\"network-session\"<\/span>,<\/span> networkSession,<\/span>
\"settings\"<\/span>,<\/span> settings,<\/span>
\"user-content-manager\"<\/span>,<\/span> userContentManager,<\/span>
nullptr<\/span>)<\/span>)<\/span>;<\/span>
\/* Get the WPEPlatform view \u2014 this is where the new API shines *\/<\/span>
auto<\/span>*<\/span> wpeView =<\/span> webkit_web_view_get_wpe_view<\/span>(<\/span>webView)<\/span>;<\/span>
auto<\/span>*<\/span> toplevel =<\/span> wpe_view_get_toplevel<\/span>(<\/span>wpeView)<\/span>;<\/span>
\/* Window management: fullscreen, resize, title \u2014 all built-in *\/<\/span>
wpe_toplevel_fullscreen<\/span>(<\/span>toplevel)<\/span>