It has been a busy few months for the Container Timing API. After introducing the concept of measuring web components performance and detailing the native implementation in Blink, I have an update to share.

The API is moving to the next phase: a Chromium Origin Trial. I will also be presenting a year of work at the upcoming BlinkOn 21.

The Origin Trial #

After months of development and testing in Chromium, Container Timing is ready for real-world testing. We will run an Origin Trial from Chromium 148 to 153. You can register for the trial.

Until now, developers have had to manually enable the ContainerTiming feature flag in Chromium to test the new API. With the Origin Trial, early adopters can enable the API in production for a subset of their users by including the trial token. More information on how to use origin trial tokens.

Why is this important? We have been internally testing and evolving the API, but now we need feedback from real-world users. The Origin Trial will allow web developers to use the new API in production and experiment with it.

Please provide your feedback at the WICG Container Timing issue tracker.

• Does the API design meet your needs?
• How could it be changed to be more useful?
• Any corner cases that are not working as expected?

A year in review at BlinkOn 21 #

Next week, April 20th and 21st, the Chromium community will gather for BlinkOn 21. I’ll be giving a lightning talk summarizing the updates over the last year.

I will keep a close eye on the BlinkOn Slack channels during the event, so feel free to reach out to discuss the roadmap, implementation details, or any API feedback.

Wrapping up #

The Origin Trial is a key step toward finalizing the specification. Real-world feedback from the trial itself and from BlinkOn 21 discussions will feed into the standards working group discussions, and we expect the specification to evolve from there.

If you build with Container Timing during the trial, please share what you find: what works, what does not, and what is missing. That input will shape the final API.

You can also test locally by enabling the ContainerTiming feature flag in Chromium, while you wait for your Origin Trial registration to be approved.

Thanks #

This work is part of the collaboration between Bloomberg and Igalia. Thanks!

References #

• Container Timing explainer.
• Specification draft @ WICG.
• Get started with origin trials.
• Container Timing: measuring web components performance.
• The implementation of Container Timing: aggregating paints in Blink.
• BlinkOn 21.

GstPrinceOfParser: An All-in-One Tool to Play With GStreamer on Any Platform #

Introducing gst-pop, the GStreamer Prince of Parser — a tool to make interaction with GStreamer easier, global, and remotely accessible.

What is GStreamer? #

GStreamer is an open-source multimedia framework started in 1999. It lets you build pipelines of interconnected elements to stream, encode, decode, and manipulate media. The core idea is simple: a source element produces data, passes it through one or more transform elements, and delivers it to a sink. For example, here is a pipeline that decodes an MP3 audio file:

    filesrc --> mp3dec --> audiosink

For more than 20 years, GStreamer has relied on its in-house toolbox to demonstrate the power of its pipelines. As this toolbox is used in thousands of projects and serves as a reference implementation, modifications and enhancements are deliberately kept minimal to maintain stability. gst-pop was created to go beyond these limitations.

A Unified Interface for GStreamer #

Accessible over the network, via CLI arguments, or through D-Bus, gst-pop aims to provide a multi-pipeline-capable command-line tool.

With a simple invocation of gst-pop (or its alias gst-popd), you can run a daemon that accepts multiple pipelines simultaneously, accessible through D-Bus or WebSocket via the pipeline ID. You’ll be able to control, query, and get information about each pipeline — all of that over a remote network, secured with API key authentication and origin validation to prevent unauthorized access.

As demonstrated in the blog post related to GstPipelineStudio, it will be possible to connect to a remote pipeline or launch new pipelines through the GStreamer GUI. If a GUI is not available on the platform, it will soon be possible to use a web interface to control GStreamer, offering everything GStreamer can provide and more, limited only by your imagination.

Remote Element Inspection #

gst-pop (or its alias gst-pop-inspect) is also capable of listing the elements on a local or remote host, inspecting their capabilities, and providing a remote way to interact with your GStreamer installation.

Media Discovery #

It can also provide information on a media file using GStreamer’s discovery interface using gst-pop-discovery, offering an easy and remote-capable media discovery system for your setup.

Playback #

And of course, it can serve as an alternative to the gst-play tool, with gst-pop-play, allowing you to instantiate as many playback sessions as you need, with the ability to use any sink you want.

The possibilities are vast: provide multimedia services such as transcoding, media analysis, or remote playback to your setup using the power of a remote machine, all controllable from your terminal or a GUI such as GstPipelineStudio.

Cross-Platform and Language Support #

The tool is written in Rust for memory safety and reliability and provides client libraries in both Rust and C, offering all the flexibility needed for your existing applications. It is available on Linux (deb, rpm or docker), MacOS, and Windows, see the release page.

Examples #

# Start the daemon
gst-pop

# Launch a pipeline
gst-pop launch videotestsrc ! autovideosink

# Inspect an element
gst-pop inspect videotestsrc

# Discover media info
gst-pop discover file:///path/to/video.mp4

# Play a media file
gst-pop play file:///path/to/video.mp4

# Create a pipeline with the client
gst-popctl create "videotestsrc ! autovideosink"

# List pipelines on a remote daemon
gst-popctl list

# Play the pipeline with ID 0
gst-popctl play 0

# Stop the pipeline with ID 0
gst-popctl stop 0

# Run via Docker
docker run -d -p 9000:9000 ghcr.io/dabrain34/gstpop:latest

Give it a try and let us know what ideas you might have — we have plenty coming, so stay tuned.

As usual, if you would like to learn more about gst-pop, GStreamer, or any other open multimedia framework, please contact us!

Update on what happened in WebKit in the week from March 31 to April 7.

Support for iOS dialog light dismiss, a new API to obtain page icons, WebKit nightly builds for Epiphany Canary produced by GNOME GitLab, and more conservative checks for MPEG-4 Audio object types are all part of this week's edition of the WebKit periodical.

Cross-Port 🐱

Multimedia 🎥

Infrastructure 🏗️

GstPipelineStudio 0.5.1 #

Your GStreamer Pipelines, at a Glance #

New version of GstPipelineStudio is out!

After months of improvements and intermediate releases since October 2024, it’s time for an official announcement for 0.5.1.

GstPipelineStudio provides a visual interface to GStreamer, the marvelous Swiss Army knife of multimedia pipelines. But what is GStreamer exactly?

What is GStreamer? #

GStreamer is an open-source multimedia framework started in 1999. It lets you build pipelines of interconnected elements to stream, encode, decode, and manipulate media. The core idea is simple: a source element produces data, passes it through one or more transform elements, and delivers it to a sink. For example, here is a pipeline that decodes an MP3 audio file:

    filesrc --> mp3dec --> audiosink

GStreamer is written in C, with a growing ecosystem of plugins in Rust and bindings for languages such as Python and C++. It ships with many command-line tools to build and test pipelines, but validating ideas still requires writing C/Rust/Python code or using the command line. That’s where GstPipelineStudio comes in — providing a visual interface to help newcomers discover and adopt GStreamer, and skilled developers debug their pipelines.

The Story Behind GstPipelineStudio #

The GstPipelineStudio project started in 2021 with the idea to provide the same environment that brought me to multimedia: GraphEdit on Windows with DirectShow. Indeed, DirectShow and GStreamer share the same idea of plugins sharing data. As I started to implement a DVB decoder with DirectShow, the graphical interface made it easier to validate which filters to use. But DirectShow only works natively on Windows, unlike GStreamer which can run everywhere — Linux, macOS, Windows, iOS, Android, and even low-power devices such as a Raspberry Pi.

GstPipelineStudio aims to work on all these platforms, easing GStreamer adoption where its use was not always obvious, such as on Windows. GStreamer is based on GLib, a cross-platform toolkit that abstracts system calls and provides a common base layer. For the GUI, since Rust was offering very good bindings, GTK was the natural choice to achieve cross-platform support. There was an attempt to create a GUI using Qt, named pipeviz, which has been a great inspiration for GPS, but the Qt Rust bindings were not mature enough, unlike those for GTK.

The first official release of GPS was 0.3.4, and you can read its official blog post published in 2023. Since then, we have been devoted to providing new features to bring GPS to another level.

A first revision, GPS 0.4.0, came out before Christmas 2024 with a refreshed interface — including zoom on the graph and contextual menus on any element or pad of the pipeline. The versions of GStreamer and GTK have also been updated to get the latest plugins and features from both frameworks. A new icon has also been introduced to let GPS dive into another dimension.

What’s New in 0.5.1 #

0.5.1 is here, and it brings a game changer: the dot file reader. Previously, it was possible to open a command-line pipeline or save/open pipelines with an XML-based format, but now you can also open the generated dot files, the native format in GStreamer, to display a pipeline graphically. This is still a beta version as it can only display high-level pipelines such as those described with the command line. Nevertheless this is a great improvement and allows users to see their pipeline and manipulate it.

Here is the list of other improvements you’ll find in this release:

• Open Dot Folder menu entry for loading dot files from the common GStreamer folder
• Remote pipeline introspection using the GStreamer tracers
• App ID renamed to dev.mooday.GstPipelineStudio
• Improved look and feel of the interface
• Auto-connect on node click (node-link-request)
• File selector button for location property
• Logger copy to clipboard with multi-selection support
• Auto-arrange elements on screen
• GStreamer 1.28.0
• GTK 4.20
• RPM and AppImage artifacts

Remote Pipeline Introspection #

The remote pipeline introspection is a new way to connect to the WebSocket tracer available in GStreamer, pipeline-snapshot. In addition to dot file loader, it allows you to visualize a pipeline directly in GPS from an external process running with the tracer.

As you may know, GStreamer pipelines can be very complex, so one dream was to be able to visualize them live. There is already a mini tool in GStreamer named gst-dots-viewer which creates a web server to display pipelines in a browser from the $XDG_CACHE_DIR folder, see the blog post from Thibault about it.

Now with GPS, you can directly create a WebSocket server and let the tracer connect to it and provide available dot files to be displayed.

For example, to visualize a running pipeline in GPS:

1. In GPS: Menu → Remote Pipeline → Listen…
2. Enter the WebSocket address (e.g., ws://localhost:8080)
3. Run your GStreamer pipeline with the pipeline-snapshot tracer:

GST_TRACERS="pipeline-snapshot(dots-viewer-ws-url=ws://localhost:8080)" \
  gst-launch-1.0 videotestsrc ! autovideosink

The pipeline graph will appear in GPS once the tracer connects.

These dot files are converted to GPS pipelines, making it possible to modify them. That’s a first step for real interaction with GStreamer pipelines — and there are more features coming in the pipeline.

Coming in 0.6.0 #

In parallel, a new tool named GstPrinceOfParser (gst-pop) has also been implemented. This tool allows remote control of all pipelines instantiated locally or over the network. It is a multi-pipeline daemon accessible through WebSocket or D-Bus, aiming to centralize all GStreamer options in one tool for launch, inspection, and discovery. GstPipelineStudio will be able to control this daemon, making gst-pop the backbone of the GStreamer GUI. A blog post will come soon, stay tuned…

A new tracer is under development: a WebSocket server that will allow you to inspect and interact with the current pipeline — modify the play state (pause, seek), fetch the logs, and of course see the current dot representation, all from the GstPipelineStudio interface.

In addition, more features are on the way: a new look and feel based on libadwaita on Linux/macOS/Windows, better localization, an auto-plug feature, seek and step-by-step playback, and bug fixes on demand.

We hope you’ll enjoy this new version of the tool and please feel free to propose new features with an RFC here or merge requests here.

Stay tuned for the next GStreamer Spring hackfest 2026 coming soon (end of May) where new features and deeper interaction with GStreamer pipelines will be discussed.

As usual, if you would like to learn more about GstPipelineStudio, GStreamer, or any other open multimedia framework, please contact us!

Background

Following up on my previous post, I would like to share an update on the progress of the Extension migration work that has been underway over the past few months.

To briefly recap the motivation behind this effort: Igalia’s long-term goal is to enable embedders to use the Extension system without depending on the //chrome layer. In other words, we want to make it possible to support Extension functionality with minimal implementation effort using only //content + //extensions.

Currently, some parts of the Extension system still rely on the //chrome layer. Our objective is to remove those dependencies so that embedders can integrate Extension capabilities without needing to include the entire //chrome layer.

As a short-term milestone, we focused on migrating the Extension installation implementation from //chrome to //extensions. This phase of the work has now been completed, which is why I’m sharing this progress update.

Extension Installation Formats

Chromium supports several formats for installing Extensions. The most common ones are zip, unpacked and crx.

Each format serves a different purpose:

• zip – commonly used for internal distribution or packaged deployment
• unpacked – primarily used during development and debugging
• crx – the standard packaged format used by the Chrome Web Store

During this migration effort, the code responsible for supporting all three installation formats has been successfully moved to the //extensions layer.

As a result, the Extension installation pipeline is now significantly less dependent on the //chrome layer, bringing us closer to enabling Extension support directly on top of //content + //extensions.

Patch and References

To support this migration, several patches were introduced to move installation-related components into the //extensions layer and decouple them from //chrome.

For readers who are interested in the implementation details, you can find the related changes and discussions here:

• Chromium issue tracking this work:
  https://issues.chromium.org/issues/358567092
• Related code reviews and patches:
  https://chromium-review.googlesource.com/q/myid.shin@igalia.com

These links provide more insight into the design decisions, code changes, and ongoing discussions around the migration.

Demo

Below is a short demo showing the current setup in action.

This demo was recorded using app_shell on Linux, the minimal stripped-down browser container designed to run Chrome Apps and using only //content and //extensions/ layers.

To have this executable launcher, we also extended app_shell with the minimal functionality required for embedders to install the extension app.

This allows Extensions to be installed and executed without relying on the full Chrome browser implementation, making it easier to experiment with and validate the migration work.

Next Steps

The next short-term goal is to migrate the code required for installing Extensions via the Chrome Web Store into the //extensions layer as well.

At the moment, parts of the Web Store installation flow still depend on the //chrome layer. The next phase of this project will focus on removing those dependencies so that Web Store-based installation can also function within the //extensions layer.

Once this work is completed, embedders will be able to install Extension apps from Chrome WebStore with a significantly simpler architecture (//content + //extensions).

This will make the Extension platform more modular, reusable, and easier to integrate into custom Chromium-based products.

I will continue to share updates as the migration progresses.

A while back, I wrote about Building Node.js on Windows using the new ClangCL support, which was done on an actual x64 Windows machine

Simple goal: take advantage of my home router's WireGuard support and have one of my external servers connect using this, and pass all traffic from a certain user through that interface.

Create WireGuard credentials

This part of the note won't be that useful to you unless you're using a Fritzbox router. But if you're me or someone suspiciously like me you may want to know to:

• Navigate to https://192.168.178.1/#/access/wireguard
• Click "Add WireGuard connection" and ensure "Connect a single device" is selected on the modal that appears. Then click "Next".
• Enter a unique name for the connection (I typically use $remote_host_name-wg) and click Finish. Follow request to confirm by pressing a button on the router.
• Click "Download settings" and a wg_config.conf will be downloaded.

Add user

VPN_USER=asbvpn
sudo useradd -m -g users -G wheel -s /bin/bash "$VPN_USER"
sudo passwd "$VPN_USER"

Configure systemd-networkd

First, extracting the relevant values from the wg_config.conf:

WG_CONF=wg_config.conf
PRIVATE_KEY="$(sed -n 's/^PrivateKey = //p' "$WG_CONF")"
PUBLIC_KEY="$(sed -n 's/^PublicKey = //p' "$WG_CONF")"
PRESHARED_KEY="$(sed -n 's/^PresharedKey = //p' "$WG_CONF")"
ENDPOINT="$(sed -n 's/^Endpoint = //p' "$WG_CONF")"

ADDRS="$(sed -n 's/^Address = //p' "$WG_CONF")"
IPV4_ADDR="$(printf '%s\n' "$ADDRS" | cut -d, -f1)"
IPV6_ADDR="$(printf '%s\n' "$ADDRS" | cut -d, -f2)"

What we want to do is:

• Define the wireguard interface wg0 and specify the necessary keys, IP addresses etc for it to be brought up successfully.
• Specify a routing policy so that all traffic from the given user account goes via that interface.
  • As you can see below, we specify a RouteTable called "vpn", associate that with the interface, and specify rules for that table.
  • Ideally this would "fail closed" and no traffic from the user would be routed if wg0 is down. That appears to use additional rules managed outside of systemd-networkd. I haven't tried to implement this.

The above can be achieved with:

sudo mkdir -p /etc/systemd/networkd.conf.d
sudo tee /etc/systemd/networkd.conf.d/90-vpn-table.conf >/dev/null <<'EOF'
[Network]
RouteTable=vpn:100
EOF

sudo tee /etc/systemd/network/50-wg0.netdev >/dev/null <<EOF
[NetDev]
Name=wg0
Kind=wireguard

[WireGuard]
PrivateKey=$PRIVATE_KEY
RouteTable=vpn

[WireGuardPeer]
PublicKey=$PUBLIC_KEY
PresharedKey=$PRESHARED_KEY
AllowedIPs=0.0.0.0/0
AllowedIPs=::/0
Endpoint=$ENDPOINT
EOF

sudo tee /etc/systemd/network/50-wg0.network >/dev/null <<EOF
[Match]
Name=wg0

[Network]
Address=$IPV4_ADDR
Address=$IPV6_ADDR

[RoutingPolicyRule]
User=$VPN_USER
Table=vpn
Priority=10000
Family=both
EOF

sudo chgrp systemd-network /etc/systemd/network/50-wg0.netdev
sudo chmod 0640 /etc/systemd/network/50-wg0.netdev
sudo systemctl restart systemd-networkd

Doing it this way, we've stored the secret keys in the 50-wg0.netdev file itself but restricted access to the file. It's possible to have the keys stored in a separate file, but for my setup it didn't seem worthwhile.

Then check the status with e.g.:

sudo networkctl status wg0
sudo ip rule show
sudo ip route show table 100
sudo wg show wg0
sudo -u $VPN_USER curl https://ifconfig.me/all

IPv6 does not work in this setup (curl -6 google.com will fail),

Copying authorized_keys to new user

This is more a note to myself than anything else:

sudo install -d -m 700 -o $VPN_USER -g users /home/$VPN_USER/.ssh
sudo install -m 600 -o $VPN_USER -g users "$HOME/.ssh/authorized_keys" /home/$VPN_USER/.ssh/authorized_keys

• 2026-03-31: Initial publication date.

Update on what happened in WebKit in the week from March 23 to March 30.

This week comes with a mixed bag of new features, incremental improvements, and a new release with the ever important security issue fixes. Also: more blog posts!

Cross-Port 🐱

Multimedia 🎥

Graphics 🖼️

WPE WebKit 📟

WPE Platform API 🧩

Releases 📦️

Community & Events 🤝

In part 1 of this series I talked about the beginning of this story and laid out the plan. In this post we'll start the actual work, beginning with the software part.

Problem 5: base peripheral device

I'll start with the most basic device: the peripheral. It will provide a simple BLE service to allow toggling the board LED remotely and displaying its current status.

Solution

The Zephyr samples are a good starting point for the firmware skeleton. The XIAO nRF54L15 is also well supported in Zephyr, so defining a custom BLE service and operating the on-board LED is not a challenge. A minimal sketch firmware with the basic functionality can be done reasonably quickly starting from scratch. To test the BLE service we can use a smartphone and nRF Connect for Mobile.

I probably don't need to go all the trouble of doing a custom BLE service and characteristic for this, but it's an exercise I'll need to do at some point, and it has the added bonus of giving us full freedom to define the functionalities we want.

For the BLE services and characteristics, I picked up a random 128-bit

/* LED service UUID: 46239800-1bed5-4c51-a215-9251faaae809 */
#define LED_SERVICE_UUID_VAL \
	BT_UUID_128_ENCODE(0x46239800, 0x1bed5, 0x4c51, 0xa215, 0x9251faaae809)

static struct bt_uuid_128 led_svc_uuid =
	BT_UUID_INIT_128(LED_SERVICE_UUID_VAL);

/* Characteristic UUID: 46239801-1bed5-4c51-a215-9251faaae809 */
static struct bt_uuid_128 led_char_uuid = BT_UUID_INIT_128(
	BT_UUID_128_ENCODE(0x46239801, 0x1bed5, 0x4c51, 0xa215, 0x9251faaae809));

/* Characteristic UUID: 46239802-1bed5-4c51-a215-9251faaae809 */
static struct bt_uuid_128 led_indication_char_uuid = BT_UUID_INIT_128(
	BT_UUID_128_ENCODE(0x46239802, 0x1bed5, 0x4c51, 0xa215, 0x9251faaae809));

[...]

BT_GATT_SERVICE_DEFINE(led_svc,
	BT_GATT_PRIMARY_SERVICE(&led_svc_uuid),
	BT_GATT_CHARACTERISTIC(&led_char_uuid.uuid,
			BT_GATT_CHRC_READ | BT_GATT_CHRC_WRITE,
			BT_GATT_PERM_READ | BT_GATT_PERM_WRITE,
			read_led_state, write_led_state, &led_state),
	BT_GATT_CHARACTERISTIC(&led_indication_char_uuid.uuid,
			BT_GATT_CHRC_INDICATE,
			BT_GATT_PERM_READ | BT_GATT_PERM_WRITE,
			NULL, NULL, NULL),
	BT_GATT_CCC(led_ccc_changed,
		BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),
);

/*
 * LED state characteristic read callback.
 */
static ssize_t read_led_state(struct bt_conn *conn,
                             const struct bt_gatt_attr *attr, void *buf,
                             uint16_t len, uint16_t offset) {
	const uint8_t *val = attr->user_data;
	return bt_gatt_attr_read(conn, attr, buf, len, offset, val,
				sizeof(*val));
}

/*
 * LED state characteristic write callback.
 * A write to this characteristic will trigger a LED toggle, the data
 * sent is irrelevant so we can just ignore it.
 */
static ssize_t write_led_state(struct bt_conn *conn,
                              const struct bt_gatt_attr *attr, const void *buf,
                              uint16_t len, uint16_t offset, uint8_t flags) {
	ARG_UNUSED(conn);
	ARG_UNUSED(attr);
	ARG_UNUSED(buf);
	ARG_UNUSED(offset);
	ARG_UNUSED(flags);

	/*
	 * Ignore received data (dummy): *((uint8_t *)buf)
	 * and override (toggle) the led_state here as a side-effect.
	 */
	LOG_DBG("LED toggle received: %d -> %d", led_state, led_state ? 0 : 1);
	led_state = led_state ? 0 : 1;
	gpio_pin_set_dt(&led, led_state);
	gpio_pin_set_dt(&led_board, led_state);
	if (led_indication_enabled)
		k_work_schedule(&led_indicate_work, K_NO_WAIT);

	return len;
}

/*
 * LED indication Client Characteristic Configuration callback.
 */
static void led_ccc_changed(const struct bt_gatt_attr *attr, uint16_t value)
{
	ARG_UNUSED(attr);

	led_indication_enabled = (value == BT_GATT_CCC_INDICATE);
	LOG_DBG("Indication %s", led_indication_enabled ? "enabled" : "disabled");
}

This should be good enough for now, we'll surely need to complicate it later.

Problem 6: unexpected LED behavior

The user LED in the XIAO nRF54L15 turns off with gpio_pin_set_dt(&led, 1) and on with gpio_pin_set_dt(&led, 0). Not a problem if we only want to toggle it instead of setting a specific value, but not ideal, since we also want to keep track of its current state and report it.

Solution

This one's easy. According to the schematic, this LED is active low, but the device tree for this SoC defines it as active high. Fixed and upstreamed.

Problem 7: modeling the behavior of the central device

In the BLE central-peripheral architecture proposed, the peripheral will work as an autonomous device that provides a service but does no other action except when requested by the user through a button press. Other than that, it'll sit there waiting for requests from the central (the controller device in our case), which will be the one governing the bulk of the application and, more importantly, managing the connection and doing the necessary actions to establish and monitor it.

Some of the tasks under the responsibility of the controller are:

• Scanning for peripherals.
• Connecting to peripherals.
• Service discovery.
• Keep track of the connected devices.
• Handle disconnection requests and lost connections.

We need a way to model this behavior into the controller so we can integrate these tasks with the rest of the firmware gracefully.

Solution

I'll abstract the list of tasks above in a simple state machine that will run in a separate thread taking care of handling the connections, running the necessary actions as response to specific events, interacting with the rest of the firmware and reacting to the actions triggered by the user via the board buttons or by external sources.

That way, the main thread will set up the hardware and the necessary software subsystems, and the state machine will keep track of most of the BLE-related tasks and of the connected devices.

So, when the initialization is done, the main thread will start the state machine thread and then wait for events such as button presses, managing and restarting common services, while the state machine works on its own.

For our purposes we'll only need three states:

• Event listen: the device waits for events from the user or from external sources. In the most basic scenario, it waits for a "scan" request, which will make the machine move to the "Scan" state.
• Scan: this state handles device scanning and connection. Once connected to a suitable device, the state machine will move to the "Discover" state. If no connection is done after a period of time, the machine will go back to the "Event listen" state.
• Discover: here, the firmware will run the discovery process for a connected peripheral, looking for a specific set of services and characteristics. If the process is successful, the controller will save the necessary data about the peripheral for later use and move to the "Event listen" state.

I can reuse most of this architecture as the basis for the console device as well, since it'll be a central device to the controllers (remember the controllers are both central and peripheral BLE devices at the same time), so I can start sketching the console firmware as well as a generic central device.

Problem 8: designing the UX for the controller device

We need a way for the controller to interact with the connected peripherals, and in the controller boards (nRF54L15 DK) we have as user-facing devices four LEDs and four buttons. The operations we'll need to perform are:

• Scan for peripherals.
• Disconnect from a connected peripheral.
• Toggle the LED of a connected peripheral.
• Check the status of the peripherals.

Solution

The most useful thing we could do with the board LEDs is to replicate the status of the peripheral LEDs. That way we could have a real-time overview of the state of the connected peripherals at all times.

The downside of this is that the board only has four LEDs, so if I want to show the status of the connected peripherals at a glance, I'm limited to four of them. And it'd be good to keep one LED to show the status of the controller itself, so lets start by limiting the amount of simultaneously connected peripherals to three.

Now, about the buttons, I'm going to need a way to perform at least three actions: scanning, disconnecting and toggling, and I'll probably need to make room for additional actions down the road.

One option is to assign one button to each peripheral "slot", so I could use button 0 to perform an action on slot 0, button 1 for slot 1, etc. In this case, I'd need to encode multiple actions on the same button: scanning and toggling at least.

A different approach is to use one or two buttons to select the active slot, and then the action buttons would operate on the selected slot. I feel like this method could be easier to adapt in case I need to add additional functionalities later, so this is what I'll do:

• Button 0: select the next slot as the "active slot".
• Button 1: "action button", trigger an action on the peripheral connected in the active slot. For now, the action will be to toggle the LED.
• Button 2: select the previous slot as the "active slot".
• Button 3: disconnect the peripheral in the active slot, if any, and start scanning on it.

I'll also need a way to tell which one is the selected slot. Since I'm using the LEDs to represent the slots, an easy way to do this is by briefly blink the LED of the currently active slot when we use buttons 0 or 2 to cycle through the slots. Additionally, I can use the same method to encode whether the slot contains a connected peripheral or not, since I'm using a static LED to show the status of the peripheral LED (i.e. we can't tell from a LED that's off if the connected peripheral has its LED off or of there's no peripheral connected at all): when cycling through the slots selecting the active one, the LED can do a short blink cycle to represent a disconnected slot and a long blink cycle to represent a connected one.

Problem 9: simulation and testing

During development, it's very inconvenient to run all the firmware changes we do on real hardware, even if these boards can be flashed very fast. And for debugging and testing, relying on the hardware is overkill most of the time, even if we have direct access to a serial console and we have plenty of tracing possibilities. I'd need a better way to test our changes.

Solution

Fortunately, Zephyr includes a native simulator that allows to build a firmware as a native binary that I can run on the development machine using emulated devices. For my purposes, the native bsim boards even let me simulate the specific SoC used in the boards, including most of the SoC hardware, and run the firmware natively in BabbleSim to simulate real BLE usage.

This offers many advantages over testing on hardware:

• Faster development cycles.
• Easier debugging of runtime errors.
• Triggering of specific corner cases programmatically.

Ideally, what I'd like is to configure the environment so that I can selectively build and test the firmware on the simulator, or build a release firmware for the real hardware. A way to do this is to keep two separate project config files, create the necessary device tree overlay files for the different target boards (real and simulated) and compile certain parts of the firmware conditionally, so that I can enable test code and emulated devices only on the simulator build and I can keep hardware-dependent code only for the release build:

├── boards
│   ├── nrf52_bsim.conf
│   ├── nrf52_bsim.overlay
│   ├── nrf54l15bsim_nrf54l15_cpuapp.conf
│   └── nrf54l15bsim_nrf54l15_cpuapp.overlay
├── build.sh
├── CMakeLists.txt
├── flash.sh
├── Kconfig
├── prj.conf
├── prj_sim.conf
├── sim_bin
├── sim_build.sh
├── sim_run.sh
└── src
    ├── common.h
    ├── emul.c
    ├── emul.h
    ├── main.c
    ├── peripheral_mgmt.c
    ├── peripheral_mgmt.h
    ├── sim_test.c
    ├── sm.c
    └── sm.h

Code compiled conditionally for the simulator looks like this:

[...]
int main(void)
{
	static struct gpio_callback button_cb_data;
	int log_sources = log_src_cnt_get(0);
	int ret;
	int i;

#ifdef CONFIG_BOARD_NRF52_BSIM
	/* Set all logging to INFO level by default */
	for (i = 0; i < log_sources; i++) {
		log_filter_set(NULL, 0, i, LOG_LEVEL_INF);
	}
	int id = log_source_id_get("controller__main");
	log_filter_set(NULL, 0, id, LOG_LEVEL_DBG);
#else
	/* Disable all logging by default */
	for (i = 0; i < log_sources; i++) {
		log_filter_set(NULL, 0, i, LOG_LEVEL_NONE);
	}
#endif

From now on, I can do most of the development on the simulator, and once things are the way I want I can test them on the real hardware.

Problem 10: battery-powered peripheral setup

While the peripheral devices can be powered via USB, just the same as the bigger boards, the demo would be both more realistic and more diverse if we used batteries for them. The XIAO nRF54L15 is prepared for that and has battery pads and the necessary hardware to manage a LiPo battery. I need to provide the batteries and add the appropriate battery leads to the boards, though.

Solution

Any suitable LiPo battery will do, but I'll search for batteries with an appropriate dimensions and capacity for this application.

I found this bundle containing five batteries and a charger, which should be good enough for our purposes: we can have up to 5 battery-powered peripherals and a convenient way to recharge the batteries if they're easy to detach from the devices.

The battery connectors are Molex 51005, so I'll also need to source a bunch of male and female leads. The pads are big enough to solder the leads to them with a conventional pen solder:

Problem 11: hardware unreliability

The XIAO nRF54L15 seems very flaky. In particular, after flashing it sometimes the device crashes and Zephyr reports a bus data error in the serial console. It seems to be random, it happens only after flashing some builds and it also seems to depend on timing.

Even worse, when battery-powered, the board won't boot. When powered via USB, though, it will boot, and then I can plug in the battery, unplug the USB cable and the board will keep on running.

Solution

After some investigation and tests, it looks like the crashes are related to the logging through the UART console. Why, I don't know. The kind of crashes I'm seeing right during booting are bus faults, and the first things I'd check for are null pointer dereferences and stack overflows, but in this case I'm not even getting a valid PC in the error report. Besides, there are a few signs that this will be hard to pinpoint:

• Altering the logging does cause different results.
• Different builds and flashings of the same firmware sometimes crash and sometimes don't.
• It doesn't seem related to the size of the logging stack.
• Deferred vs immediate logging causes different results.
• It doesn't fail on the simulator.
• It seems related to timing.
• There's a big randomness factor.
• The same firmware on the same SoC but on a different board design (nRF54L15 DK) works fine.

All of these hint that there's some flakiness involved in the XIAO nRF54L15, particularly related to either power management, flashing or the use of the builtin USB for UART output.

Judging by some issues raised in the Seeed Studio forums, it looks like the USB-based SWD circuitry could be the cause of these problems. Regarding the problems booting when battery-powered, after asking about it in the forums, I got a response explaining the reason: when logging is enabled, the TX line back-feeds and powers up the USB-UART chip, causing a brownout and a shutdown/reboot.

The most reasonable fix or workaround for all of this is to simply disable all logging and UART usage when the board is battery-powered¹. In order to do this, I created another build type that will be used for "production" releases. For the non-production builds (the ones I'll use for development and debugging) I'll keep logging disabled with the possibility of enabling it through shell commands. That'll reduce the chances of crashing the system at boot time.

Problem 12: network connectivity in the console device

We can take advantage of the builtin web server capabilities provided by Zephyr for the console board. Since it'll be governing the application and monitoring / controlling the connected devices, we'll need a user interface to manage it. Implementing it in the form of a web interface should be easy enough, and it'd give us a lot of freedom to design the interface. The idea would be to connect the console board to a client (a laptop, for instance) using a point-to-point Ethernet link and have the client access the web page served by the console board.

The problem is that the board doesn't have an Ethernet interface.

Solution

Everything's not lost, though. The board doesn't have an Ethernet interface but it has a general USB interface besides the one used for flashing and debugging. And, fortunately, the USB stack in Zephyr supports USB CDC NCM (Ethernet-over-USB) and we even have an example of the web server running on the same board we're using for the console device, so setting it up shouldn't be too much of an issue.

I can run the sample code on the board and check that it works, I can connect to it and see the web page published by the web server. Integrating the basic code into our sketchy console firmware is mostly painless, although I'm publishing only a placeholder web page. For now, that's good enough. I'll see what we can do with it later.

In the next post we'll continue through the rest of the software development part of the project.

Recently I landed a custom Python gdb unwinder in V8 that allows gdb to unwind through V8’s JIT-compiled frames on x64

Measuring paint performance is a balancing act: you need precision, but the measurement itself can’t slow things down.

In my previous post, I introduced Container Timing, a new web API allowing developers to measure the rendering performance of DOM subtrees. Today, I will dive into the technical details of how I implemented this in Blink, the rendering engine used by Chromium.

The Architecture: Hooking into Paint #

In Blink, the rendering pipeline goes through several stages: Style, Layout, Paint, and Composite. The Container Timing implementation relies heavily on the Paint stage.

The main idea was not reinventing the wheel. Blink already provides paint timing detection for the implementation of Large Contentful Paint (LCP) and Element Timing. However, this is targeted for specific nodes (an image, a text block). In Container Timing we care about subtrees.

So, when a paint is detected, we need to quickly decide whether the paint is relevant to Container Timing.

Is a paint interesting for Container Timing? #

As the DOM tree is built (on parsing, or because of a script), we check the value of the attribute containertiming for each Element. When found, we flag that element and all its descendants with the flag SelfOrAncestorHasContainerTiming.

We also have the attribute containertiming-ignore. When found, we will stop the propagation.

So, later, for any paint, we will immediately know if the paint should be tracked for Container Timing or not. This minimizes the impact when the element is not tracked.

Collecting Paint Updates #

When a paint is detected, we just reuse the existing implementation in the ImagePaintTimingDetector and TextPaintTimingDetector, that are also used for LCP and Element Timing for the relevant elements.

We first determine if the paint should be recorded for Container Timing. And this is fast because of the SelfOrAncestorHasContainerTiming flag.

The timing detectors give us the area of the visual rectangle, the bounding box on screen that was painted.

For Container Timing, we added a mechanism to walk up the DOM tree from the painted node. If we encounter an ancestor that is marked with the containertiming attribute (a container timing root), we report that paint event to it.

This “bubbling up” of paint events is illustrated in the diagram below.

Aggregating Regions #

One of the most interesting challenges was determining the size of the container. It is not just the size of the container timing root. It is the union of all painted content.

Two reasons for this:

• Being able to incrementally determine the updated area, in a way that is inspired by Largest Contentful Paint.
• To reduce the amount of performance events generated, we discard the paints that do not increase the area.

We maintain a PaintedRegion for each container. This is a non-overlapping union of the rectangles that cover the updated area:

1. Initial Paint: When the first child paints, we initialize the region with its visual rectangle.
2. Subsequent Paints: As more images load or text renders, we perform a union operation: CurrentRegion = Union(CurrentRegion, NewPaintRect).

So, as paints are detected, each container will aggregate the parts of the screen that have been painted by all their children.

We use cc::Region, based on SkRegion from the Skia graphics library to handle these unions efficiently.

The following diagram shows this process in action over three frames.

Buffering and Reporting #

Because a container paints over multiple frames (e.g., text renders first, then a background image, then a lazy-loaded icon), we cannot just emit one entry. We generate candidates.

For each container, when a paint that increases the painted region is detected, we schedule a new event. Right at the end of the frame presentation, we package the current state into a new performance timeline entry: a PerformanceContainerTiming object.

This object contains:

• startTime: The presentation time of the paint. In the Chromium implementation, this is set to the moment the frame was presented to the user, and matches presentationTime from PaintTimingMixin.
• firstRenderTime: the time of the first paint we detected in the container. Useful for getting a hint of how long a component has been showing updates to the user.
• The container element, in two ways. The identifier is the value of the containertiming attribute. rootElement is the actual element.
• size: The total area of the aggregated PaintedRegion.
• lastPaintedElement: the last element that triggered a paint — handy for debugging which child caused the latest candidate.

This design means the observer might receive multiple entries for the same container. This is intentional: it lets developers pick the milestone that matters to them, typically the point where size stops growing.

Handling “Ignore” #

We also implemented the containertiming-ignore attribute. When a node has this attribute, it stops the SelfOrAncestorHasContainerTiming flag from propagating further down its subtree, so paints within it are not walked up to the container timing root, and never contribute to that container PaintedRegion.

Ignoring is useful for a number of things:

• Debug overlays and instrumentation widgets, which should not inflate the measured painted area.
• Visually independent nested components: child dialogs or overlays that paint independently from the container and would affect the size metric if included.

How to test #

With flag propagation, region aggregation, candidate buffering, and selective ignoring all in place, the implementation is complete.

Container Timing is ready for test in Chromium. Just use the Blink feature flag ContainerTiming:

chrome --enable-blink-features=ContainerTiming

What’s next? #

• We are preparing an Origin Trial in Chromium, a new step towards enabling Container Timing by default. Stay tuned!
• Optimizations in the traversal. We have some ideas for avoiding the traversal of the full tree when a paint is detected, to find the container timing root.
• Support for detecting paints in other parts of the tree. Shadow DOM is specially interesting here due to its importance in web components.

Wrapping up #

Building this native implementation was a great exercise in reusing Blink’s existing performance infrastructure while extending it to support subtree-level aggregation.

The key insight: subtree-level metrics didn’t require a new paint tracking system. Only a way to aggregate and bubble up what Blink was already measuring.

The result is a native, low-overhead API for measuring the rendering performance of entire components.

Thanks! #

This has been done as part of the collaboration between Bloomberg and Igalia. Thanks!

References #

• Implementation of SelfOrAncestorHasContainerTiming: 1, 2.
• ContainerTiming aggregation at container_timing.cc.
• Paint detection in text and image paint timing detectors.
• Specification draft @ WICG.
• Related specifications: Element Timing, Largest Contentful Paint, Paint Timing Mixin.
• Explainer.
• Shadow DOM Handling discussion.
• Optimizing hierarchy traversals.
• Life of a Pixel presentation about the Blink rendering pipeline by Steve Kobes.

Recently, I landed a change that moves the Single Executable Application (SEA) build process directly into Node.js core - a hobby project I’d been tinkering with for some time

Motivation

Custom URL schemes have traditionally served as an integration bridge between the browser and external capabilities. Schemes such as mailto: and tel: allow navigation to trigger actions beyond ordinary HTTP resource retrieval. The HTML Standard formalizes this mechanism through the Custom Scheme Handlers API, which enables websites to register themselves as handlers for specific URL schemes.

While the Web API is appropriate for origin-scoped integrations, its security model imposes several structural constraints:

• Registration must be initiated from a visited website.
• It requires user activation.
• The handler URL must share the same origin as the registering site.
• Each registration is processed individually and requires explicit user approval.

These constraints are deliberate and necessary to prevent cross-origin abuse. However, they also limit legitimate integration scenarios that are better expressed outside the web-origin layer.

In collaboration with the Open Impact Foundation’s IPFS Implementations grants program, Igalia has implemented support for declaring protocol handlers directly in the Web Extension Manifest for Chromium-based browsers – achieving interoperability with Firefox. The goal is to make protocol registration a first-class extension capability, while preserving the security invariants established by the HTML Standard.

The proposal was discussed by the Web Extensions WICG back in 2023, with the support of Firefox (already implemented) and Chrome. Safari initially supported but finally changed to opposed.

This article introduces the motivation behind the feature, explains the design decisions that shaped it, and describes its internal security and lifecycle model.

The feature has been shipped behind an experimental flag in Chrome 146. To test it, just launch Chrome from the command line with this option:

--enable-features=ExtensionProtocolHandlers

Case study: IPFS Companion

IPFS introduces schemes such as ipfs://, backed by a content-addressed data model rather than traditional origin-based addressing. In Chromium’s previous extension model, IPFS Companion must request declarativeNetRequest, webRequest, webNavigation, and <all_urls> host permissions — not because it wants to monitor all browsing activity, but because intercepting an unrecognized protocol requires inspecting every navigation and network request. The browser shows users a warning like “Read and change all your data on all websites”, which is disproportionate to what the extension actually does with those protocols. Users must decide whether to trust that warning based on the extension’s reputation alone.

These broad permissions also create friction with the Chrome Web Store review process. Extensions requesting webRequest and are flagged for in-depth review, adding days to every publish cycle and occasionally triggering outright rejections that require detailed justification of each permission.

In the absence of a native mechanism, IPFS Companion resorts to detecting when the browser converts an unrecognized ipfs:// URL into a search engine query, then intercepting and redirecting that query. This works, but it depends on browser-specific URL encoding behavior, breaks silently when search providers change their format, and may not work on all platforms due to security software interfering with such hijacking.

With manifest-declared protocol handlers, the extension can register IPFS directly. Navigation dispatch becomes declarative rather than interceptive. The permission model narrows, the architecture simplifies, and the integration aligns with the browser’s native routing mechanisms. These would be an example of the Extension Manifest:

  "protocol_handlers": [
    {
      "protocol": "ipns",
      "name": "IPFS Companion: IPNS Protocol Handler",
      "uriTemplate": "https://dweb.link/ipns/?uri=%s"
    },
    {
      "protocol": "ipfs",
      "name": "IPFS Companion: IPFS Protocol Handler",
      "uriTemplate": "https://dweb.link/ipfs/?uri=%s"
    }
  ]

This example illustrates the broader principle behind the feature: protocol handling should be expressed as a first-class navigation capability, not as a side effect of request rewriting.

Broader integration scenarios

Beyond decentralized networking use cases, manifest-declared protocol handlers enable enterprise and platform-level integrations. Organizations can define custom schemes that deep-link into internal systems, communication tools, authentication flows, or secure service endpoints. Extensions can manage these schemes centrally, update them through versioned deployments, and decouple protocol routing from web application modifications.

  "protocol_handlers": [
    {
      "protocol": "irc",
      "name": "Corporate IRC client",
      "uriTemplate": "https://mycompany.com/irc/?params=%s"
    },
    {
      "protocol": "mailto",
      "name": "Corporate Email client",
      "uriTemplate": "https://mycompany.com/webmail/?params=%s"
    },
    {
      "protocol": "webcal",
      "name": "Corporate Calendar client",
      "uriTemplate": "https://mycompany.com/calendar/?params=%s"
    },
    {
      "protocol": "web+plan",
      "name": "Corporate Planning client",
      "uriTemplate": "https://mycompany.com/planning/?params=%s"
    },

This establishes a structured integration surface between browser navigation and external systems while maintaining explicit user control and security guarantees.

The limits of existing mechanisms

The HTML Standard’s navigator.registerProtocolHandler() API abides by the same-origin security model. A website may only register handlers that resolve within its own origin, and registration requires explicit user activation. This model works well when a web application intends to claim responsibility for a scheme that maps naturally to its own domain. However, extensions operate under a fundamentally different trust and lifecycle model.

Extensions are packaged artifacts installed by the user, subject to store review and explicit permission approval. Their integration surface extends beyond a single origin, and often spans navigation interception, network rewriting, operating system integration, and enterprise policy enforcement. Attempting to reuse the web-origin registration model for extension use cases introduces friction and architectural complexity.

As a result, extensions in Chromium-based browsers have historically relied on indirect mechanisms. For example, extensions such as IPFS Companion intercept navigation requests, detect custom schemes, and rewrite them into gateway-based HTTP URLs using APIs like declarativeNetRequest. Although functional, this approach moves protocol handling into request interception layers, rather than treating it as a native navigation routing concern. It increases implementation complexity, expands the required permission surface, and introduces maintenance overhead.

The absence of manifest-declared protocol handlers in Chromium created a gap between the capabilities of extensions and the needs of advanced integration scenarios.

A step forward: PWAs as “URL handlers”

Progressive Web Apps provided a partial evolution of the model by allowing protocol handlers to be declared via the Web App Manifest. This improved declarative configuration, but remained tightly coupled to the application’s origin and lifecycle. It did not address scenarios where the integration logic belongs to an extension rather than a web application.

Back in 2020, Chrome started prototyping a feature called PWAs as URL Handlers, allowing apps to register themselves as handlers for URLs matching a certain pattern. This feature has been abandoned in favor of Scoped Extensions for Web App Manifest, which precisely allows web apps to overcome some of the challenges that the same-origin policy imposes on this type of site architecture.

These lines of work did not address scenarios where the integration logic belongs to an extension rather than a web application. However, these initiatives inspired the work to implement similar capabilities in Web Extensions.

Manifest-declared protocol handlers

As a result of our work, Chromium now supports the protocol_handlers key directly in the Web Extension Manifest. This feature aligns protocol registration with the extension lifecycle instead of the web-origin lifecycle.

"protocol_handlers": [
  {
    "protocol": "ircs",
    "name": "IRC Mozilla Extension",
    "uriTemplate": "https://irccloud.mozilla.com/#!/%s"
  }
]

Handlers declared in the manifest are parsed and validated during extension installation. Registration occurs at that time, but activation is deferred: the handlers remain inactive until they are invoked by a navigation request and explicitly approved by the user.

This design introduces several important properties:

• Registration is declarative and tied to the extension artifact.
• Validation enforces HTML Standard constraints at parse time.
• Activation requires runtime user consent.
• Disabling or uninstalling the extension automatically removes its handlers.

By shifting protocol registration into the manifest, the browser gains a clearer separation between declaration, validation, and activation.

Security Model and Validation

Because protocol handlers influence navigation routing, the feature inherits strict validation rules from the HTML Standard. During manifest parsing, the browser verifies that declared schemes belong to a predefined safe list and that handler URLs use HTTP or HTTPS.

 "bitcoin", "cabal",  "dat",    "did",  "doi",  "dweb", "ethereum",
 "geo",     "hyper",  "im",     "ipfs", "ipns", "irc",  "ircs",
 "magnet",  "mailto", "matrix", "mms",  "news", "nntp", "openpgp4fpr",
 "sip",     "sms",    "smsto",  "ssb",  "ssh",  "tel",  "urn",
 "webcal",  "wtai",   "xmpp"

Given that the same-origin requirement is relaxed in this model, we need to validate explicitly that the target handler operates in a secure context. This ensures that the user doesn’t leave a trustworthy origin due to the redirection performed by the protocol handler.

The Web API model imposes a requirement of a mandatory User Activation to confirm the JavaScript registration request. The Extension API model, instead, proposes a declarative approach to perform the handler registration, so it happens silently without explicit user consent. However, this does not remove the user-gesture requirement from the security model; instead, it relocates it to the extension installation process.

Extension installation is an explicit user action that requires them to review the requested permissions and give their consent. Registration of manifest-declared protocol handlers occurs as part of this installation transaction. In this sense, the User Activation requirement is satisfied at the lifecycle level rather than at the API invocation level.

In addition, activation of a registered handler is deferred. When a matching navigation occurs, the browser prompts the user before allowing the handler to resolve the request. This introduces a second layer of consent, ensuring that protocol usage cannot occur silently.

The resulting model separates concerns:

• Installation authorizes registration.
• Runtime approval authorizes use.

This layered approach preserves the security intent of the HTML model while adapting it to the extension trust boundary.

Runtime permission flow

A key design decision was to avoid front-loading protocol permissions during installation. Modern WebExtensions APIs increasingly rely on runtime permission requests to reduce cognitive overload and improve user comprehension.

Accordingly, protocol handlers declared in the manifest remain dormant until a matching navigation occurs. When such a navigation is triggered, the browser presents a permission dialog identifying both the extension requesting activation and the destination to which navigation will be redirected. The user may approve the request once or choose to persist the decision.

This runtime gating model ensures transparency while preserving a smooth installation experience. It also aligns protocol handling with contemporary permission paradigms used across browser APIs.

Cross-origin considerations

The same-origin requirement in the HTML Standard’s Custom Scheme Handlers API is not incidental; it is central to its threat model. When a website registers itself as a handler, the specification requires that the handler URL share the same origin as the registering site. This prevents a malicious origin from silently redirecting navigation events to an unrelated third-party origin. In the Web API model, the origin boundary is the primary trust primitive.

The extension model operates under a different trust boundary. Extensions are not ephemeral web origins; they are packaged components, installed by the user, with declared permissions and a well-defined lifecycle. As a result, enforcing same-origin constraints in the extension context would artificially restrict legitimate scenarios, like the ones described in the previous sections, without materially improving security.

For example, consider decentralized protocols such as IPFS. Content addressing in IPFS does not map cleanly to traditional origin semantics. A handler may need to resolve a scheme into HTTP resources, via gateway mechanism, or local node endpoints or simply connect to the network itself; these targets do not share a single origin in the conventional sense. Imposing a strict same-origin requirement in this context would block valid architectures without offering additional protection.

Relaxing the same-origin requirement in the extension model does not eliminate safeguards. Instead, the security model shifts from origin isolation to layered controls managed by the user. These include:

• Extension store review and distribution controls.
• Explicit consent during the installation.
• Manifest-declared capabilities.
• Runtime approval before handler activation.

This layered approach ensures that a protocol handler cannot be silently introduced or activated. Even though a handler may redirect navigation to a different origin, that behavior is explicitly tied to an installed by the user from a trusted source, and subject to runtime confirmation.

It is also important to distinguish between cross-origin navigation and cross-origin data access. Protocol handler resolution affects the destination of a navigation request; it does not grant the extension arbitrary access to the target origin’s data. Standard web security boundaries—such as the Same-Origin Policy and CORS—remain fully enforced after navigation completes.

In this way, the extension model preserves the security intent of the HTML specification while adapting it to a broader integration surface. The trust anchor shifts from “origin that called the API” to “extension the user chose to install,” but the system continues to require explicit consent by the user before navigation control is delegated.

Conflict resolution across registration mechanisms

With protocol handlers now registrable through multiple mechanisms—the Web API, PWA manifests, and extension manifests—conflict resolution becomes necessary. The implementation preserves backward compatibility by prioritizing Web API registrations. If a handler has been registered via navigator.registerProtocolHandler(), it becomes the default for the corresponding scheme. PWA and extension handlers are considered lower priority and remain available if higher-priority registrations are removed.

This deterministic ordering ensures predictable behavior and avoids ambiguity when multiple registration surfaces coexist.

Why this feature matters

Adding manifest-declared protocol handlers to Chromium closes a long-standing capability gap with Firefox, which has offered such capability since 2017. This allows extension authors to ship a single manifest that works across both browsers, eliminating the need to maintain separate interception codepaths per engine.

Manifest-declared protocol_handlers replace all of this with a single, narrowly scoped declaration. The permissions surface shrink from “read and change all your data on all websites” to a runtime prompt scoped to the specific protocol: “Allow this extension to open IPFS links through dweb.link”.

The new API respects the validation rules of the HTML Standard while adapting them to the extension trust model. It aligns protocol handling with the extension lifecycle, integrates cleanly with modern runtime permission patterns, and provides deterministic conflict resolution across registration surfaces. Store reviewers can verify the declared intent directly in the manifest without auditing request interception logic.

For browser engineers, the feature introduces a cleaner architectural boundary between navigation routing and network interception. For web authors building advanced integrations, it enables robust, declarative protocol handling without relying on brittle implementation techniques. For extension developers, it means protocol handling can finally be expressed as what it is (a navigation capability) rather than being disguised as request rewriting.

With the Web Extensions CG moving toward WG status, this is a good opportunity to advance the standardization of the protocol_handlers key by proposing its inclusion in the Manifest Keys section of the Draft Community Group Report.

My colleague Kate recently demonstrated on her blog how simple it is to write a WPE Platform-based launcher, and did so by building it side-by-side with MiniBrowser, inside the WebKit tree.

This entry takes one step back, and demonstrates the same concepts assuming you are not building WPE WebKit yourself, but rather getting it from your distribution. Many of the steps below would apply if you were using a Yocto/OpenEmbedded-based image, but that can be the focus of another post.

Getting WPE WebKit

Get WPE lists a number of options to get WPE from your preferred distribution. At the moment of writing, Fedora, Debian and ArchLinux are your best choices to get a recent version of WPE:

• 2.52 on Fedora
• 2.50 on Debian Forky, 2.52 on Debian Sid
• 2.50 on ArchLinux

However, since WPE Platform hasn’t officially been released, we need to use Fedora, where my colleague Philippe maintains a Copr repository with it enabled.

sudo dnf copr enable -y philn/wpewebkit
sudo dnf install wpewebkit-devel

Alternatively, you can use a container. Here is a Containerfile based on Fedora 42:

FROM fedora:42

RUN dnf install -y \
    dnf-plugins-core \
    && dnf copr enable -y philn/wpewebkit \
    && dnf install -y \
    gcc-c++ \
    cmake \
    pkg-config \
    wpewebkit-devel

WORKDIR /src

Build and run it with:

podman build -t wpe-dev .
podman run -it -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
-e XDG_RUNTIME_DIR=/run/user/$(id -u) \
-v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/run/user/$(id -u)/$WAYLAND_DISPLAY \
-v /dev/dri:/dev/dri \
wpe-dev bash

The build system

Kate’s post builds the launcher as part of the WebKit tree using WebKit’s own CMake infrastructure. For a standalone project, we need a self-contained CMakeLists.txt that finds WPE WebKit through pkg-config:

cmake_minimum_required(VERSION 3.16)
project(wpe_sample CXX)

set(CMAKE_CXX_STANDARD 17)

find_package(PkgConfig REQUIRED)

# The Wayland WPE Platform already depends on wpe-platform-2.0
pkg_check_modules(WebKitDeps REQUIRED
    IMPORTED_TARGET
    wpe-webkit-2.0
    wpe-platform-wayland-2.0
)

add_executable(wpe_sample main.cpp)

target_link_libraries(wpe_sample
    PRIVATE
        PkgConfig::WebKitDeps
)

The launcher

Here is a minimal launcher — the smallest amount of code needed to display a web page with WPE WebKit:

#include <wpe/webkit.h>

int main(int argc, const char *argv[]) {
    g_autoptr(GMainLoop) loop = g_main_loop_new(nullptr, false);
    g_autoptr(WebKitWebView) view = WEBKIT_WEB_VIEW(g_object_new(WEBKIT_TYPE_WEB_VIEW,
        nullptr));
    webkit_web_view_load_uri(view,
        (argc > 1) ? argv[1] : "https://wpewebkit.org");
    g_main_loop_run(loop);
    return EXIT_SUCCESS;
}

This snippet relies heavily on default behaviours: it will create a default WPE view, with default top levels, with the default display selection behaviour (Wayland), default context, settings…

Again, Kate’s post does a more realistic job at showing how the various pieces are created and connected together.

Building and running

cmake -B build
cmake --build build
./build/wpe_sample https://wpewebkit.org/

Display backends

WPE WebKit can render to different display backends depending on your environment, which you can select through environment variables:

# Wayland (e.g. desktop, Weston).
WPE_DISPLAY=wpe-display-wayland WAYLAND_DISPLAY=wayland-1 ./build/wpe_sample https://wpewebkit.org/

# DRM/KMS (e.g. embedded, no compositor)
WPE_DISPLAY=wpe-display-drm ./build/wpe_sample https://wpewebkit.org/

# Headless (e.g. testing, CI)
WPE_DISPLAY=wpe-display-headless ./build/wpe_sample https://wpewebkit.org/

You can take a look at wpe_display_get_default() in WPEPlatform/wpe/WPEDisplay.cpp to understand how the automatic selection takes place in the absence of an explicit WPE_DISPLAY request.

(In our example, we are only listing Wayland as a CMake dependency. If libwpewebkit was compiled without DRM or headless support, the environment variable approach would not work.)

Next steps

This is all for now. The next entry in the series will cover classic kiosk features: preventing navigation to unwanted sites, controlling whether new windows can be opened, and intercepting requests through policy decisions.

For a more complete example that includes a custom HTML context menu and JavaScript injection, see Kate’s post.

Update on what happened in WebKit in the week from March 10 to March 18.

The big ticket item in this week's update are the 2.52.0 releases, which include the work from the last six-month development period, and come with a security advisory. Meanwhile, WPE-Android also gets a release, and a number of featured blog posts.

WPE WebKit 📟

Releases 📦️

Community & Events 🤝

Last week, Igalia finally announced Moonforge, a project we’ve been working on for basically all of 2025. It’s been quite the rollercoaster, and the announcement hit various news outlets, so I guess now is as good a time as any to talk a bit about what Moonforge is, its goal, and its constraints.

Of course, as soon as somebody announces a new Linux-based OS, folks immediately think it’s a new general purpose Linux distribution, as that’s the square shaped hole where everything OS-related ends up. So, first things first, let’s get a couple of things out of the way about Moonforge:

• Moonforge is not a general purpose Linux distribution
• Moonforge is not an embedded Linux distribution

What is Moonforge

Moonforge is a set of feature-based, well-maintained layers for Yocto, that allows you to assemble your own OS for embedded devices, or single-application environments, with specific emphasys on immutable, read-only root file system OS images that are easy to deploy and update, through tight integration with CI/CD pipelines.

Why?

Creating a whole new OS image out of whole cloth is not as hard as it used to be; on the desktop (and devices where you control the hardware), you can reasonably get away with using existing Linux distributions, filing off the serial numbers, and removing any extant packaging mechanism; or you can rely on the containerised tech stack, and boot into it.

When it comes to embedded platforms, on the other hand, you’re still very much working on bespoke, artisanal, locally sourced, organic operating systems. A good number of device manufacturers coalesced their BSPs around the Yocto Project and OpenEmbedded, which simplifies adaptations, but you’re still supposed to build the thing mostly as a one off.

While Yocto has improved leaps and bounds over the past 15 years, putting together an OS image, especially when it comes to bundling features while keeping the overall size of the base image down, is still an exercise in artisanal knowledge.

A little detour: Poky

Twenty years ago, I moved to London to work for this little consultancy called OpenedHand. One of the projects that OpenedHand was working on was taking OpenEmbedded and providing a good set of defaults and layers, in order to create a “reference distribution” that would help people getting started with their own project. That reference was called Poky.

These days, Poky exists as part of the Yocto Project, and it’s still the reference distribution for it, but since it’s part of Yocto, it has to abide to the basic constraint of the project: you still need to set up your OS using shell scripts and copy-pasting layers and recipes inside your own repository. The Yocto project is working on a setup tool to simplify those steps, but there are alternatives…

Another little detour: Kas

One alternative is kas, a tool that allows you to generate the local.conf configuration file used by bitbake through various YAML fragments exported by each layer you’re interested in, as well as additional fragments that can be used to set up customised environments.

Another feature of kas is that it can spin up the build environment inside a container, which simplifies enourmously its set up time. It avoids unadvertedly contaminating the build, and it makes it very easy to run the build on CI/CD pipelines that already rely on containers.

What Moonforge provides

Moonforge lets you create a new OS in minutes, selecting a series of features you care about from various available layers.

Each layer provides a single feature, like:

• support for a specific architecture or device (QEMU x86_64, RaspberryPi)
• containerisation (through Docker or Podman)
• A/B updates (through RAUC, systemd-sysupdate, and more)
• graphical session, using Weston
• a WPE environment

Every layer comes with its own kas fragment, which describes what the layer needs to add to the project configuration in order to function.

Since every layer is isolated, we can reason about their dependencies and interactions, and we can combine them into a final, custom product.

Through various tools, including kas, we can set up a Moonforge project that generates and validates OS images as the result of a CI/CD pipeline on platforms like GitLab, GitHub, and BitBucket; OS updates are also generated as part of that pipeline, just as comprehensive CVE reports and Software Bill of Materials (SBOM) through custom Yocto recipes.

More importantly, Moonforge can act both as a reference when it comes to hardware enablement and support for BSPs; and as a reference when building applications that need to interact with specific features coming from a board.

While this is the beginning of the project, it’s already fairly usable; we are planning a lot more in this space, so keep an eye out on the repository.

Trying Moonforge out

If you want to check out Moonforge, I will point you in the direction of its tutorials, as well as the meta-derivative repository, which should give you a good overview on how Moonforge works, and how you can use it.

Since 2022, my main focus has been working on the Wolvic browser, 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). 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.

Introduction

Some time ago, I saw myself with some extra time in my hands and I started experimenting with Zephyr as a way to reconnect with my professional past and also to see how embedded software looks like nowadays.

Initially, I had no further intentions beyond playing around a bit, gaining enough know-how to undertake typical embedded software projects and doing the occasional upstream contribution here and there, until a colleague told me "Now that you've spent some time with Zephyr, what do you think about doing a demo about it?". Not a bad idea. The goal is to have something to show at conferences and that showcases Zephyr's possibilities using a simple application.

At work, I'm not a specialist. What I do most of the time is basically one thing, and it typically doesn't fit in a specific field, area, or team: I solve problems ¹. So this is an example of how to solve a single-sentence problem ("Let's do a demo") using whatever means necessary, involving software, hardware, planning, design, logistics, decision making and improvisation. It's also a personal expression of the importance, meaning and value of human work.

The following is a non-exhaustive list of the problems faced along the way and the solutions found.

Problem 1: the idea

The starting point is just a phrase: "Why don't we do a demo?", and a deadline. Nothing more. The amount of possibilities alone can already be an obstacle if we can't find a way to limit the solution space. Obviously, we'll find limitations and constraints down the road that will shape the final solution but, right now, everything is uncertainty.

What we want to show in the demo is the possibilities offered by Zephyr for embedded development using 100% open source software, how we can undertake complex application development with Zephyr, and show a variety of development cases within the same application.

Solution

There are may approaches to a technical demo. However, having been to conferences with demo booths, it's clear that the live and interactive demos are the ones that gather the most attention of the general public by a large margin. Regardless of the technical merits displayed in the demo, people are drawn to things they can touch, blinking lights, sounds, video games.

So a hard requirement since the beginning was that the demo should be interactive. Fortunately, the nature of the technology behind it lends itself to that easily, although I've seen many Zephyr-based demos that were rather static and only for display. The intention here is to allow the public to actually use it.

Another important thing to take into account is that widespread or hot technologies and buzzwords will be more attractive than obscure or niche terms. Fortunately, I'm building the demo from scratch, so I get to decide what to show. In this case, I picked up

The goal, then, is to develop a hardware/software solution using Zephyr and its BLE stack, allowing interaction from the public and incorporating some way to display real-time information about it. The initial idea is to have small battery-powered devices in the demo booth and track their position using trilateration based on any available distance-measurement mechanism available in BLE devices, and have a central device that displays the position of the devices in real time.

Problem 2: selecting the hardware

Now that I settled on an initial idea, even if it's in a very rough and sketchy form, with no further technical details, I can start experimenting with the options. The first step is to do some research about the hardware and software possibilities to reach our goal, pick up some evaluation boards and start sketching ideas to have a better understanding of the feasibility of what I want to achieve and the limitations I can find (time, software/hardware constraints, skills, etc.)

Solution

A good option for BLE-based applications is to use some of the Nordic development kits. They're easy to source and inexpensive. Besides, the recent nRF54L15 SoC supports channel sounding, which promises precise distance estimations between devices. Just what I'm looking for.

I'll need two types of devices for this: one of them needs to be small (wearable size, if possible) and battery-powered. The other type will be at a fixed location and can have a cabled power supply. The idea is to have three devices at fixed locations in the booth measuring the distance to a number of battery-powered devices that will be moving. Then, a central device will collect the distance information from the metering devices and use it to calculate the position of each battery-powered device.
This central device will need to have some way to display the position of the devices in some kind of graphical interface, so I need to search for a device that can connect to the metering devices, that is well supported in Zephyr and that can support some kind of display out-of-the-box.

With all these requirements in mind I came up with this list of devices:

• For the battery-powered devices: Seeed Studio XIAO nRF54L15, based on the nRF54L15 SoC.
• For the metering devices: nRF54L15 DK boards from Nordic, also based on the nRF54L15.
• For the central device: nRF52840 DK board, which supports a serial SPI touchscreen like this one.

All the hardware is already supported in Zephyr, so that should eliminate a lot of the initial friction and save us time.

Problem 3: practical limitations, redefining the idea

After some initial experiments with the hardware, running sample BLE applications and getting familiar with the ecosystem, I found out that, while the nRF54L15 hardware supports Bluetooth channel sounding, the Zephyr BLE stack still doesn't support it, so in order to use it I'd need to use Nordic's SoftDevice controller instead of the upstream Zephyr controller, together with the nRF Connect BLE stack.

This is a problem because a key feature of this demo should be that it's done using 100% open source code and, preferably, upstream Zephyr code.

Another, even bigger obstacle, is that it's not clear that collecting distance data from multiple sources simultaneously for trilateration, and doing it for multiple peripherals at the same time, is practically viable. I couldn't find any examples or documentation on it, and I could be entering uncharted territory. Considering that we have a deadline for this, I'd rather find an alternative.

Solution

The immediate solution is to find a less audacious idea to develop using the same hardware that I already have, keeping it interactive but simpler, and keeping the same goals.

The idea I finally settled on is an extension of the typical BLE peripheral -- central application, where the peripheral publishes some services and the central device connects to it and issues GATT reads and writes to the peripheral characteristics, but adding a multi-level network topology instead of a simple star network, and adding real-time remote display and control of the devices using a graphical interface. So we'd have three device types: the battery-powered peripherals, which will provide the basic services, then the controller devices, which will connect to the peripherals to control them remotely, and then a console device which will connect to the controllers and can show and control the devices remotely using a graphical interface.

Zephyr supports BLE Mesh already, but we'd lose part of the challenge of implementing the networking routing ourselves, so I'm keeping things more interesting by implementing a custom tree topology that provides us with finer grained control, and which can be tailored to a specific application use case.

This means that the controller device will need to act both as a BLE central and peripheral device simultaneously, while the peripheral devices will act only as peripherals and the console will be only a central.

Problem 4: initial planning

With the development boards at hand, I can start designing and developing the firmwares for the three board types, including testing and documentation. The other certain thing I have right now is a deadline: the conference where we want to show the demo. Now I need to draw a rough plan with concrete dates.

Solution

Considering that I'll surely find a few bad surprises down the road and that there'll be uncertainty and problems that I can't yet anticipate, since it's the first time we're doing a demo with these characteristics, I set myself a personal hard deadline: one month before the real hard deadline. Ideally, the firmware should be all done and thoroughly tested one month before that, so that'd leave two full months for additional preparations and for sorting out whichever last-minute obstacles I could find in the end.

Of course, all of this rough planning is based purely on intuition. I could fall into the trap of wanting to plan everything beforehand and write a well-specified roadmap of everything that needs to be done in minute detail, but I'd be setting myself up for failure from the start, since 90% of the work ahead is a big question mark. I'm defining everything as we go, and in cases like this it's much more reasonable to plan and work based on different principles:

• Define reasonable and achievable milestones and iterate based on them.
• Iterate fast and as many times as needed.
• Re-draw the plan after an iteration if needed.
• Be ready to improvise.
• Improve incrementally and have faith in the process. Don't look at the top of the mountain, you know where it is. Focus on the next meter of path in front.

Doing this as a one-person-army has both pros and cons. Fear and uncertainty are something you have to shoulder on your own, but you're also free to take whatever decision you need whenever you need.

So, now we're ready to start developing. A rough milestones sketch for the firmware development could be:

• Base application for the peripheral: board setup and hardware handling.
• Base application for the controller device: board setup and hardware handling.
• Basic peripheral-central BLE application using the peripheral and controller devices.
• Base application for the console device: board setup and hardware handling.
• Make the controller device work as both a BLE peripheral and central device.
• Incorporate the console device to the peripheral + controller application.
• Graphical interface design and implementation.

Testing and simulation should be a part of every milestone.

In the next post we'll go through the firmware development part of the project.

WPE WebKit and WebKitGTK support async scrolling for wheel events. I landed several improvements for the upcoming 2.52 release.

• Bug 305451 – wheel event async scrolling doesn’t start while the main thread is blocked
• Bug 305560 – rendering glitches for unpainted tiles
• Bug 305561 – Paint scrollbars in the scrolling thread for async scrolling

Here are videos of before and after the changes. This is the test content.

There is still room for further improvement.

• The scrollbar hiding animation timer is still running in the main thread.
  • It can use CoordinatedPlatformLayer::setAnimations.
  • Or CoordinatedPlatformLayer::setOpacity.
• Add the showing animation and transition animations of mouse hover states like GTK Adwaita theme
• Support touch and gesture events async scrolling

WPE WebKit is a WebKit port optimized for embedded devices — think set-top boxes, digital signage, kiosk displays, and in-vehicle infotainment systems. It is developed by Igalia and powers web experiences on millions of devices worldwide, from set-top boxes to smart TVs and beyond.

WPE WebKit has recently introduced a brand-new platform API called WPEPlatform, which replaces the legacy libwpe + wpebackend-fdo stack. In this post, I will walk you through building a minimal WPE browser launcher using only the new WPEPlatform API, and demonstrate one of its newly available features: the Context Menu API — rendered entirely as an HTML overlay.

Why a New API? #

The legacy stack (libwpe + wpebackend-fdo + Cog platform plugins) had several pain points: nested Wayland compositor complexity, dependency on Mesa’s now-deprecated EGL_WL_bind_wayland_display extension, rigid C function-pointer tables, and platform code scattered across three libraries.

The new WPEPlatform API replaces all of this with a single, clean GObject-based layer — providing automatic backend creation, DMA-BUF direct buffer sharing, unified window management (fullscreen, maximize, resize, title), and easy language bindings via GObject Introspection.

Timeline: The stable release of WPEPlatform is planned for September 2026. At that point, the legacy API will be officially deprecated. We strongly recommend new projects to adopt the WPEPlatform API from the start.

WPEPlatform Launcher: A Minimal Browser in ~250 Lines #

To demonstrate the new API, I built WPEPlatformLauncher — a minimal but functional WPE WebKit browser that uses only the WPEPlatform API. No legacy libwpe, no wpebackend-fdo, no Cog — just the new API.

The full source code is available at: kate-k-lee/WebKit@aed6402

How Simple Is It? #

Here is the core of the launcher — creating a WebView with the new API:

/* WPEPlatform backend is created automatically — no manual setup needed */
auto* webView = WEBKIT_WEB_VIEW(g_object_new(WEBKIT_TYPE_WEB_VIEW,
    "web-context", webContext,
    "network-session", networkSession,
    "settings", settings,
    "user-content-manager", userContentManager,
    nullptr));

/* Get the WPEPlatform view — this is where the new API shines */
auto* wpeView = webkit_web_view_get_wpe_view(webView);
auto* toplevel = wpe_view_get_toplevel(wpeView);

/* Window management: fullscreen, resize, title — all built-in */
wpe_toplevel_fullscreen(toplevel);
wpe_toplevel_resize(toplevel, 1920, 1080);
wpe_toplevel_set_title(toplevel, "WPEPlatform Launcher");

/* Input events: just connect a GObject signal */
g_signal_connect(wpeView, "event", G_CALLBACK(onViewEvent), webView);

Compare this with the legacy API, which required:

1. Manually creating a WPEToolingBackends::ViewBackend
2. Wrapping it in a WebKitWebViewBackend with a destroy callback
3. Creating a C++ InputClient class and registering it
4. Having no window management (no maximize, minimize, title, etc.)

The new API handles backend creation, display detection, and input forwarding automatically.

Keyboard Shortcuts #

Handling keyboard events is straightforward with the WPEPlatform event system:

static gboolean onViewEvent(WPEView* view, WPEEvent* event, WebKitWebView* webView)
{
    if (wpe_event_get_event_type(event) != WPE_EVENT_KEYBOARD_KEY_DOWN)
        return FALSE;

    auto modifiers = wpe_event_get_modifiers(event);
    auto keyval = wpe_event_keyboard_get_keyval(event);

    /* Ctrl+Q: Quit */
    if ((modifiers & WPE_MODIFIER_KEYBOARD_CONTROL) && keyval == WPE_KEY_q) {
        g_application_quit(g_application_get_default());
        return TRUE;
    }

    /* F11: Toggle fullscreen via WPEToplevel */
    if (keyval == WPE_KEY_F11) {
        auto* toplevel = wpe_view_get_toplevel(view);
        if (wpe_toplevel_get_state(toplevel) & WPE_TOPLEVEL_STATE_FULLSCREEN)
            wpe_toplevel_unfullscreen(toplevel);
        else
            wpe_toplevel_fullscreen(toplevel);
        return TRUE;
    }

    return FALSE;
}

HTML-Based Context Menu: Solving the “No Native UI” Challenge #

WPE WebKit is designed for embedded environments where there is no native UI toolkit — no GTK, no Qt. This means features like context menus (right-click menus) that desktop browsers take for granted need to be implemented by the application.

The approach: intercept WebKit’s context-menu signal, read the menu items, and render them as an HTML/CSS overlay injected into the page DOM.

The Architecture #

User right-clicks
  → WebKit emits "context-menu" signal
  → onContextMenu() handler:
      1. Reads menu items via webkit_context_menu_get_items()
      2. Gets position via webkit_context_menu_get_position()
      3. Builds JavaScript that creates DOM elements
      4. Injects via webkit_web_view_evaluate_javascript()
      5. Returns TRUE (suppresses default menu)

User clicks a menu item
  → JS: window.webkit.messageHandlers.contextMenuAction.postMessage(actionId)
  → C: onContextMenuAction() receives the action ID
      → Executes: webkit_web_view_go_back(), execute_editing_command("Copy"), etc.

User clicks outside the menu
  → JS: overlay click handler removes the DOM elements

Reading Context Menu Items #

The Context Menu API provides everything we need:

static gboolean onContextMenu(WebKitWebView* webView,
    WebKitContextMenu* contextMenu, gpointer /* event */,
    WebKitHitTestResult* hitTestResult, gpointer)
{
    /* Save hit test result for link-related actions */
    savedHitTestResult = WEBKIT_HIT_TEST_RESULT(g_object_ref(hitTestResult));

    /* Iterate through menu items */
    GList* items = webkit_context_menu_get_items(contextMenu);
    for (GList* l = items; l; l = l->next) {
        auto* item = WEBKIT_CONTEXT_MENU_ITEM(l->data);

        if (webkit_context_menu_item_is_separator(item)) {
            /* Render as a horizontal line */
            continue;
        }

        const char* title = webkit_context_menu_item_get_title(item);
        auto action = webkit_context_menu_item_get_stock_action(item);
        /* Build HTML element with title and action ID */
    }

    /* Get position for menu placement */
    gint posX = 0, posY = 0;
    webkit_context_menu_get_position(contextMenu, &posX, &posY);

    return TRUE; /* Suppress default menu */
}

The HTML Menu: Dark Theme for Embedded #

The context menu is rendered with a dark theme CSS, designed for embedded/kiosk displays:

#__wpe_ctx_menu {
    position: fixed;
    min-width: 180px;
    background: #2b2b2b;
    border: 1px solid #505050;
    border-radius: 6px;
    padding: 4px 0;
    box-shadow: 0 8px 24px rgba(0,0,0,0.4);
    font-family: system-ui, sans-serif;
    font-size: 13px;
    color: #e0e0e0;
}

.__wpe_ctx_item:hover {
    background: #0060df;
    color: #ffffff;
}

Handling Actions via Script Message Handler #

Communication between the HTML menu and the C application uses WebKit’s script message handler mechanism:

/* Register message handler */
auto* ucm = webkit_user_content_manager_new();
webkit_user_content_manager_register_script_message_handler(
    ucm, "contextMenuAction", nullptr);
g_signal_connect(ucm, "script-message-received::contextMenuAction",
    G_CALLBACK(onContextMenuAction), nullptr);

// In the generated HTML menu item:
item.addEventListener('click', function() {
    window.webkit.messageHandlers.contextMenuAction.postMessage(actionId);
});

/* Handle the action in C */
static void onContextMenuAction(WebKitUserContentManager*, JSCValue* value, gpointer)
{
    int actionId = jsc_value_to_int32(value);

    switch (actionId) {
    case WEBKIT_CONTEXT_MENU_ACTION_RELOAD:
        webkit_web_view_reload(webView);
        break;
    case WEBKIT_CONTEXT_MENU_ACTION_COPY:
        webkit_web_view_execute_editing_command(webView, "Copy");
        break;
    case WEBKIT_CONTEXT_MENU_ACTION_OPEN_LINK:
        webkit_web_view_load_uri(webView,
            webkit_hit_test_result_get_link_uri(savedHitTestResult));
        break;
    /* ... more actions ... */
    }
}

Demo #

Here is the WPEPlatformLauncher in action, showing the HTML context menu with various actions:

Right-clicking shows the HTML context menu. Clicking “Reload” triggers an actual page reload.

Right-clicking a link shows link-specific actions like “Open Link” and “Copy Link Address”.

Building and Running #

I built and ran the WPEPlatformLauncher inside a container using the WebKit Container SDK, which provides a pre-configured development environment with all the dependencies needed to build WPE WebKit.

The WPEPlatformLauncher integrates into the WebKit build system:

# Build WPE WebKit with the launcher
Tools/Scripts/build-webkit --wpe --release

# Run
./WebKitBuild/WPE/Release/bin/WPEPlatformLauncher https://wpewebkit.org

# Run in fullscreen (kiosk mode)
./WebKitBuild/WPE/Release/bin/WPEPlatformLauncher --fullscreen https://your-app.com

The full source is a single main.cpp file (~600 lines including the context menu), integrated into the WebKit tree alongside MiniBrowser:

WebKit/Tools/
├── MiniBrowser/wpe/          ← Existing (supports both old + new API)
├── WPEPlatformLauncher/      ← New (WPEPlatform API only)
│   ├── main.cpp
│   └── CMakeLists.txt
└── PlatformWPE.cmake         ← Modified to add WPEPlatformLauncher

Summary #

The new WPEPlatform API makes building WPE WebKit applications significantly simpler:

• No manual backend setup — the platform is detected and configured automatically
• GObject-based — signals, properties, and ref counting instead of C function pointers
• DMA-BUF direct sharing — no dependency on Mesa’s deprecated EGL extensions
• Unified window management — fullscreen, maximize, minimize, resize, and title
• Language binding friendly — works with Python, JavaScript, and more via GObject Introspection

For embedded browser developers building kiosk UIs, set-top box interfaces, or digital signage with WPE WebKit — now is the time to adopt the new API. The stable release is coming in September 2026, and the legacy stack (libwpe, wpebackend-fdo, Cog) will be deprecated at that point.

Resources #

• WPE WebKit official site
• WPE WebKit API Reference (2.51.92)
• WebKitContextMenu API Reference
• WPEPlatformLauncher source code
• Igalia — WPE WebKit
• Cog — WPE launcher (legacy)

I built libsoup and WebKit with ASan today. It works almost out of the box. I used Clang. GCC also supports ASan, but WebKit has a problem with it. WebKit Container SDK is based on Ubuntu 20.04 LTS at the moment. It contains clang 18 by default.

Installed required packages.

sudo apt install libclang-rt-18-dev llvm-18-dev

Set env vars.

export CC=clang CXX=clang++

Passed some flags to libsoup.

--- /jhbuild/webkit-sdk-deps.modules.orig
+++ /jhbuild/webkit-sdk-deps.modules
@@ -149,7 +149,7 @@
     </dependencies>
   </meson>

-  <meson id="libsoup" mesonargs="-Dtests=false">
+  <meson id="libsoup" mesonargs="-Dtests=false -Db_sanitize=address -Db_lundef=false">
     <branch repo="github.com"
             checkoutdir="libsoup"
             module="GNOME/libsoup.git" tag="3.6.6"/>

Then, build and install libsoup.

jhbuild buildone -f libsoup

Then, build WebKit with ASan.

./Tools/Scripts/build-webkit --gtk --release --cmakeargs=-DENABLE_SANITIZERS=address

WebKit has a lot of memory leaks by design. Don’t detect leaks.

export ASAN_OPTIONS=detect_leaks=0

For run-webkit-tests, I had to modify a script a bit.

diff --git a/Tools/Scripts/webkitpy/port/driver.py b/Tools/Scripts/webkitpy/port/driver.py
index eb12801a455b..c9f74eeab4e2 100644
--- a/Tools/Scripts/webkitpy/port/driver.py
+++ b/Tools/Scripts/webkitpy/port/driver.py
@@ -482,7 +482,7 @@ class Driver(object):
         else:
             environment['DUMPRENDERTREE_TEMP'] = str(self._driver_tempdir)
         environment['LOCAL_RESOURCE_ROOT'] = str(self._port.layout_tests_dir())
-        environment['ASAN_OPTIONS'] = "allocator_may_return_null=1"
+        environment['ASAN_OPTIONS'] = "allocator_may_return_null=1:detect_leaks=0"
         environment['__XPC_ASAN_OPTIONS'] = environment['ASAN_OPTIONS']

         # Disable vnode-guard related simulated crashes for WKTR / DRT (rdar://problem/40674034).

That’s it. Enjoy.

GN Language Server for Chromium development was announced on chromium-dev. It’s very easy to install in VSCode, NeoVim or Emacs. But how can we configure it with classic Vim + YCM?

Setup

First, install the language server with Cargo.

cargo install --locked gn-language-server

Then, add this to your vimrc.

let g:ycm_language_server = [
      \ {
      \   'name': 'gn',
      \   'cmdline': [ 'gn-language-server' ],
      \   'filetypes': [ 'gn' ],
      \ }
  \ ]

That easy, right?

What’s Working

Hover Documentation

Go To Imports

Go To Dependencies

Current Limitations

The following features are not working yet. They may need more configuration or further work:

Code Folding

Classic Vim and YCM don’t support LSP-based folding, and I’m not a big fan of that feature anyway. But you can configure another plugin that supports LSP-based folding, or simply rely on indent-based folding.

Go To Definition

When I try to go to the definition of template, I get an error KeyError: 'uri'. I’m not sure whether this is caused by my local configuration, but it needs further investigation.

Update on what happened in WebKit in the week from March 2 to March 9.

As part of this week's handful of news, WebKitGTK and WPE WebKit now have support for Gamepad's "VibationActuator" property, the video decoding limit is now configurable at runtime in addition to build time, and an interesting fix that makes WebKit render fonts like other browsers by making it blend text incorrectly (!).

Cross-Port 🐱

Multimedia 🎥

Graphics 🖼️

Releases 📦️

Update on what happened in WebKit in the week from February 23 to March 2.

This installment of the periodical brings news about support for Qualcomm qtivdec2 and qtivenc2 on GStreamer, GPU texture atlas creation and replay substitution, enhancement of the scroll gesture in WPE, and two new releases: WebKitGTK 2.51.92 and WPE WebKit 2.51.92.

Cross-Port 🐱

Multimedia 🎥

Graphics 🖼️

WPE WebKit 📟

WPE Platform API 🧩

Releases 📦️

The “State of the Browser 2026” Conference was held on Saturday, the 28th of February in The Barbican Centre, London. It is a yearly conference organised by London Web Standards. This is year is the 14th Edition.

From Igalia, this year we had Luke Warlow and myself attended in person, Javier Fernández attended online. My colleague Stephanie Stimac introduced this event to Igalia a couple of years ago. Now Igalia has become one of the sponsors for this great event. Luke had participated this event previously so it’s very helpful to understand more about this event from his note.

The event is a one-day, single-track conference that is community focused. While queuing for the registrations, a couple of attendees commented that talks for this event had been very good in the past few years. I’d say, this year was not an exception. I thoroughly enjoyed the talks, and the whole experiences.

Talks throughout the day covered a wide variety of topics including CSS features, accessibility, JS footprint, playing with gaming APIs and the art of connecting to people etc.. As someone who loves food, maybe I can describe it as a feast with content, taste, depth, variety…and a bit fun factor?

The open talk was Anchor positioning by Bramus Van Damme. The walk-through on the feature with examples were pretty cool, especially the case of a popover… with a little triangle (You’ll know what I mean if you look up the talk). Igalia worked on popover for Firefox in 2024, sponsored by Google. It’s really great to see that anchor positioning is in Firefox – popover has now found its place.

It was nice to hear that Igalians’ names were mentioned in the Temporal talk by Jason Williams from Bloomberg. A big shout out to Philip Chimento, Ujjwal Sharma who have participated substantially in the discussions about standardizing Temporal over the years and my fellow Igalians who have been writing spec PRs and tests for the feature. Check on Tim Chevalier’s blog on “Implementing the Temporal proposal in JavaScriptCore” if you’d like to find out more.

The atmosphere of the event was friendly, inclusive and energetic. I was very happy bumping into some ex-colleagues and making new friends.

One final note – This event brings a range of attendees, many are web developers. There are representatives from companies and browser vendors etc.. For some web developers, “Igalia” is a new name. I had a question like “Oh, is it the company with rainbow colours in the sponsors?”. Yes, Igalia is a private, worker-owned, employee-run cooperative model consultancy focused on open source software[1]. And Igalia has been a part of the Interop Project since its inception in 2021. Here is Igalia’s “rainbowy” logo :-).

Les candidatures pour les « stages de programmation informatique » d’Igalia sont officiellement ouvertes jusqu’à début avril. Ils offrent aux étudiant·e·s l’occasion de participer au développement de logiciels libres tout en étant rémunéré·e·s 7 000 € brut pour 450 heures, réparties de juin à décembre 2026.

Comme chaque année, j’encadrerai un·e étudiant·e sur l’« Implémentation des normes Web » (Web Standards en anglais). L’objectif étant de modifier les navigateurs (Chromium, Firefox ou Safari…) afin d’améliorer le support de technologies Web (HTML, CSS, DOM…). Il faudra notamment étudier les spécifications correspondantes et écrire des tests de conformité. Notez bien que ce n’est pas un stage de développement Web mais de développement C++.

Un des objectifs de ce programme étant de lutter contre les discriminations professionnelles, tout le monde (y compris celles et ceux qui se sentent sous-représenté·e·s dans le secteur informatique) sont invité·e·s à candidater. Depuis 2016, mon équipe « Web Platform » a ainsi encadré 13 étudiant·e·s de différents pays dans le monde (Espagne, Inde, Italie, Australie, Cameroun, Chine, Vietnam, Angleterre et États-Unis) dont 7 femmes. L’année dernière, nous avions sélectionné Charlotte McCleary, une Américaine non-voyante qui a travaillé sur l’accessibilité dans Firefox au cours de son stage et a depuis rejoint Fizz Studio. J’aimerais encourager les étudiant·e·s Sourd·e·s à postuler et donne dans la vidéo ci-dessous une brève présentation du programme en LSF (en espérant que ce soit compréhensible et que vous serez indulgents avec mon piètre niveau en langue des signes 😅):

Si vous êtes intéréssé·e·s, remplissez ce formulaire en cochant la case Web Standards et en précisant éventuellement que vous avez trouvé cette offre via mon site Web. Enfin, si vous connaissez des étudiant·e·s qui pourraient participer, n’hésitez pas à partager l’annonce !

Update on what happened in WebKit in the week from February 9 to February 23.

In this week we have a nice fix for video streams timestamps, a fix for a PDF rendering regression, support for rendering video buffers provided by Qualcomm video decoders, and a fix for a font selection issue. Also notable we had a new WPE Android release, and the libsoup 3.6.6 release.

Cross-Port 🐱

Multimedia 🎥

Graphics 🖼️

Releases 📦️

This blog post is part of a series about the page_owner debug feature in the Linux memory management subsystem, related to the talk Improving page_owner for profiling and monitoring memory usage per allocation stack trace presented at Linux Plumbers Conference 2025.

• Part 1 is a quick introduction to page_owner and its debugfs files.
• Part 2 describes challenges with processing page_owner files over time and a solution with new debugfs files in Linux v6.19.

Problem: stack traces over time

As described in Part 1, page_owner’s debugfs files contain stack traces for the most part:

• /sys/kernel/debug/page_owner has one stack trace per allocated page, and
• /sys/kernel/debug/page_owner_stacks/show_stacks lists the stack traces that allocated pages.

Reading and processing a significant amount of stack traces incurs a non-trivial computational cost in CPU and memory (copying to, and processing in, userspace) and storage usage, as the total size for such long strings might become large. This shouldn’t be an issue if done only once, but it does pose a concern if done repeatedly.

Take the processing of stack traces one step further and that concern materializes into a technical problem:

How to store information (say, number of pages) per-stack trace and over time?

For that, the stack trace must become a key to be assigned values from multiple reads over time. However, keys are usually numbers or somewhat short identifiers, not such long strings as stack traces (although doable, that is computationally more expensive in CPU and memory usage).

Workaround: stack trace hashing

One possible solution to this problem is hashing the stack traces and using the resulting hash values as keys.

However, this is inefficient with page_owner since there is significant duplication of stack traces on both debugfs files:

• In the page_owner file, even on a single read, some stack traces may have tens/hundreds/thousands of duplicates; and they compound on multiple reads over time.
• In the show_stacks file, there are no duplicates on a single read, but duplicates frequently happen on multiple reads over time.

With a high ratio of duplication, the dominant component in computational cost is the hashing step, which is significantly more expensive than the remaining step that simply use the resulting keys for storing values.

Additionally, the hashing step is usually repeated with the same data set (stack traces present in previous reads), which means that most of the calculations are discarded and done again on every read – wasting time and computational resources.

For illustration purposes, compare the execution time of script page_owner-to-show_stacks.py, which parses the page_owner file hashing the stack traces (with the extremely fast XXH3_64) and accumulating the number of pages per stack trace, reporting it at the end – basically mimicking show_stacks – with just reading the equivalent file.

The single read with hashing is 38.55 times slower:

# time ./page_owner-to-show_stacks.py </sys/kernel/debug/page_owner >/dev/null

real 0m1.542s
user 0m1.486s
sys 0m0.057s

# time cat /sys/kernel/debug/page_owner_stacks/show_stacks >/dev/null

real 0m0.040s
user 0m0.000s
sys 0m0.040s

So, considering the single-read results with the page_owner file, it’s not compelling to use it for multiple reads. However, multiple reads of the show_stacks file instead should perform better, though, as it contains unique stack traces and likely a lower ratio of duplication on multiple reads than in a single read of the former file.

Check the execution time of script show_stacks-over-time.py, which parses copies of show_stacks (collected over time), similarly hashing the stack traces and storing the number of pages per stack trace over time (that is, per copy).

For 100 copies, the execution time is almost 1 second:

# time ./show_stacks-over-time.py show_stacks.{1..100} >/dev/null

real 0m0.944s
user 0m0.900s
sys 0m0.044s

That is a great improvement (comparing to processing a single read of the page_owner file), but this is just a particular case on a lightly stressed, small VM with 1 GiB RAM. There is still the computational cost of hashing, which might increase processing time in cases with more stack traces (that is, a greater number of different code paths for memory allocation were exercised in the kernel).

Solution: stack trace handle numbers

The hashing of stack traces is only required in order to obtain a unique identifier for each stack trace, so that it can be used as a key. However, if such an identifier were already available, the hashing step (and associated computational cost) could be avoided altogether.

Fortunately, that is now the case with Linux 6.19! The stack trace storage used by page_owner ( stackdepot) provides a handle number to uniquely refer to stack traces – which meets the requirement.

Linux 6.19 contains two new debugfs files with handle numbers for optimized output:

• /sys/kernel/debug/page_owner_stacks/show_handles: this lists nr_base_pages: per handle: (instead of per stack trace as in show_stacks)
• /sys/kernel/debug/page_owner_stacks/show_stacks_handles: this lists handle: per stack trace (for resolving handle numbers to stack traces)

For the example in the previous post, show_stacks contains:

# cat /sys/kernel/debug/page_owner_stacks/show_stacks
...
 get_page_from_freelist+0x1416/0x1600
 __alloc_frozen_pages_noprof+0x18c/0x1000
 alloc_pages_mpol+0x43/0x100
 folio_alloc_noprof+0x56/0xa0
 page_cache_ra_unbounded+0xd9/0x230
 filemap_fault+0x305/0x1000
 __do_fault+0x2c/0xb0
 __handle_mm_fault+0x6f4/0xeb0
 handle_mm_fault+0xd9/0x210
 do_user_addr_fault+0x205/0x600
 exc_page_fault+0x61/0x130
 asm_exc_page_fault+0x26/0x30
nr_base_pages: 9643

...

While, for the same snippet, show_handles contains:

...
handle: 27000838
nr_base_pages: 9643

...

And the handle number can be resolved to a stack trace with show_stacks_handles:

...
 get_page_from_freelist+0x1416/0x1600
 __alloc_frozen_pages_noprof+0x18c/0x1000
 alloc_pages_mpol+0x43/0x100
 folio_alloc_noprof+0x56/0xa0
 page_cache_ra_unbounded+0xd9/0x230
 filemap_fault+0x305/0x1000
 __do_fault+0x2c/0xb0
 __handle_mm_fault+0x6f4/0xeb0
 handle_mm_fault+0xd9/0x210
 do_user_addr_fault+0x205/0x600
 exc_page_fault+0x61/0x130
 asm_exc_page_fault+0x26/0x30
handle: 27000838

...

Comparison: show_stacks vs. show_handles

From the previous post, for show_stacks:

# time cat /sys/kernel/debug/page_owner_stacks/show_stacks \
 | wc --bytes | numfmt --to=iec
402K

real 0m0.042s
user 0m0.004s
sys 0m0.046s

Now, for show_handles:

# time cat /sys/kernel/debug/page_owner_stacks/show_handles \
 | wc --bytes | numfmt --to=iec
31K

real 0m0.015s
user 0m0.004s
sys 0m0.019s

That is only 7.7% of the size and 35.7% of the time! Nice improvements.

Finally, compare the execution time of script show_handles-over-time.py with the previous one; it uses handle numbers as keys for stack traces instead of hashing them.

For 100 copies, the execution time is approximately 1/3 of a second, roughly 3 times faster.

# time ./show_handles-over-time.py show_stacks_handles show_handles.ln.{1..100} >/dev/nul

real 0m0.348s
user 0m0.319s
sys 0m0.030s

Conclusion

The original debugfs files provided by page_owner consist mainly of stack traces, which isn’t an efficient format for reading and processing repeatedly.

In order to store the number of pages used per stack trace over time, the stack traces must be converted to keys for storing values over time, for which hashing can be used. However, even efficient hashing algorithms incur a significant overhead.

In order to address this issue, Linux 6.19 provides new debugfs files for page_owner with handle numbers, which are unique identifiers for stack traces and can be used as keys, instead of hashing.

This optimizes the reading and processing of page_owner information, as it reduces the amount of data copied from kernel to userspace and allows storing the number of pages per stack trace over time without the overhead of hashing.

Scripts

Script 1: page_owner-to-show_stacks.py

#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
#
# Script to parse /sys/kernel/debug/page_owner, hashing the stack trace
# of each page and accumulating the number of pages per stack trace.
# At the end, print all stack traces and their number of pages in a format
# like /sys/kernel/debug/page_owner_stacks/show_stacks.
#
# Usage: page_owner-to-show_stacks.py </sys/kernel/debug/page_owner
#
# Author: Mauricio Faria de Oliveira <mfo@igalia.com>

import re
import sys
import xxhash

re_page = re.compile('^Page allocated via order ([0-9]+)')
re_stack = re.compile('^ ')
re_empty = re.compile('^$')

pages = {} # key -> number of pages
stacks = {} # key -> stack trace

for line in sys.stdin:

 # middle lines: try stack trace first as it occurs more often
 if re_stack.match(line):
 stack = stack + line
 continue
 
 # first line
 match = re_page.match(line)
 if match:
 order = int(match.group(1));
 stack = ''
 continue

 # last line
 if re_empty.match(line):
 key = xxhash.xxh3_64_hexdigest(stack)
 nr_pages = 2 ** order

 if key in pages:
 pages[key] += nr_pages
 else:
 pages[key] = nr_pages
 stacks[key] = stack

 continue

for key in stacks.keys():
 print(" " + stacks[key].strip())
 print("nr_base_pages: " + str(pages[key]))
 print()

Script #2: show_stacks-over-time.py

#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
#
# Script to parse /sys/kernel/debug/page_owner_stacks/show_stacks in multiple
# reads, hashing each stack trace and recording the number of base pages per
# stack trace in each read.
# At the end, print all stack traces and their number of pages in each read.
#
# Usage: show_stacks-over-time.py <read1> <read2> <read3> ... <read N>
#
# Author: Mauricio Faria de Oliveira <mfo@igalia.com>

import re
import sys
import xxhash

re_pages = re.compile('^nr_base_pages: ([0-9]+)')
re_stack = re.compile('^ ')
re_empty = re.compile('^$')

stacks = {}	# key -> stack trace (all reads)
pages = {}	# key -> array of number of pages (per read)
read = 0	# number of the current read

if len(sys.argv) < 2:
	exit(1)

files = sys.argv[1:]
nr_files = len(files)

for file in files:
	with open(file, 'r') as fd:
		stack = ''
		for line in fd:
	
			# first lines
			if re_stack.match(line):
				stack = stack + line
				continue
				
			# next to last line
			match = re_pages.match(line)
			if match:
				nr_pages = int(match.group(1));
				continue
		
			# last line
			if re_empty.match(line):
				key = xxhash.xxh3_64_hexdigest(stack)
		
				if key not in stacks:
					stacks[key] = stack;

				if key not in pages:
					pages[key] = {}

				pages[key][read] = nr_pages
		
				stack = ''
				continue

		read += 1

for key in stacks.keys():
	print(" " + stacks[key].strip())

	pages_per_read = []
	for read in range(nr_files):
		nr_pages = 0
		if read in pages[key]:
			nr_pages = pages[key][read]
		pages_per_read.append(str(nr_pages))
	
	print(' '.join(pages_per_read))
	print()

Script #3: show_handles-over-time.py

#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0
#
# Script to parse /sys/kernel/debug/page_owner_stacks/show_handles in multiple
# reads, collecting handle numbers and recording the number of base pages per
# handle number in each read.
# At the end, print all stack traces and their number of pages in each read,
# resolving handle numbers with /sys/kernel/debug/page_owner_stacks/show_stacks_handles.
#
# Usage: show_handles-over-time.py <show_stacks_handles> <read1> <read2> <read3> ... <read N>
#
# Author: Mauricio Faria de Oliveira <mfo@igalia.com>

import re
import sys
import xxhash

re_pages = re.compile('^nr_base_pages: ([0-9]+)')
re_stack = re.compile('^ ')
re_empty = re.compile('^$')
re_handle = re.compile('^handle: ([0-9]+)')

stacks = {}	# handle number -> stack trace (all reads)
pages = {}	# handle number -> array of number of pages (per read)
read = 0	# number of the current read

if len(sys.argv) < 3:
	exit(1)

resolver = sys.argv[1]
files = sys.argv[2:]
nr_files = len(files)

for file in files:
	with open(file, 'r') as fd:
		for line in fd:
	
			# first line
			match = re_handle.match(line)
			if match:
				handle = int(match.group(1))
				continue
				
			# next to last line
			match = re_pages.match(line)
			if match:
				nr_pages = int(match.group(1));
				continue
		
			# last line
			if re_empty.match(line):
				key = handle
		
				if key not in pages:
					pages[key] = {}

				pages[key][read] = nr_pages
		
				continue

		read += 1

with open(resolver, 'r') as fd:
 stack = ''

 for line in fd:

 # first line
 if re_stack.match(line):
 stack = stack + line
 continue

 # next to last line
 match = re_handle.match(line)
 if match:
 handle = int(match.group(1))
 continue
 
 # last line
 if re_empty.match(line):
 stacks[handle] = stack
 stack = ''
 continue

for key in pages.keys():
	print(" " + stacks[key].strip())

	pages_per_read = []
	for read in range(nr_files):
		nr_pages = 0
		if read in pages[key]:
			nr_pages = pages[key][read]
		pages_per_read.append(str(nr_pages))
	
	print(' '.join(pages_per_read))
	print()

This blog post is part of a series about the page_owner debug feature in the Linux memory management subsystem, related to the talk Improving page_owner for profiling and monitoring memory usage per allocation stack trace presented at Linux Plumbers Conference 2025.

What is page_owner?

In the Linux kernel, page_owner is a debug feature that tracks the memory allocation (and release) of pages in the system – so as to tell the ‘owner of a page’ ;-).

For each memory allocation, page_owner stores its order, GFP flags, stack trace, timestamp, command, process ID (PID) and thread-group ID (TGID), and more. It also stores some information when pages are freed (stack trace, timestamp, PID and TGID).

With page_owner, one can find out “What allocated this page?” and “How many pages are allocated by this particular stack trace, PID, or comm”, for example.

This is struct page_owner in Linux v6.19. It stores additional information per-page, as an extension of struct page with CONFIG_PAGE_EXTENSION.

struct page_owner {
 unsigned short order;
 short last_migrate_reason;
 gfp_t gfp_mask;
 depot_stack_handle_t handle;
 depot_stack_handle_t free_handle;
 u64 ts_nsec;
 u64 free_ts_nsec;
 char comm[TASK_COMM_LEN];
 pid_t pid;
 pid_t tgid;
 pid_t free_pid;
 pid_t free_tgid;
};

Usage

In order to use page_owner, build the kernel with CONFIG_PAGE_OWNER=y (see mm/Kconfig.debug) and boot the kernel with page_owner=on.

The debugfs file /sys/kernel/debug/page_owner provides the information in struct page_owner for every page, listed per PFN (page frame number).

This example shows the entry for a page (line continuation added for clarity) – it tells “What allocated this page?”:

# cat /sys/kernel/debug/page_owner
...
Page allocated via order 0, \
 mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), \
 pid 5640, tgid 5640 (stress-ng-brk), ts 414987114269 ns
PFN 0x114 type Unmovable Block 0 type Unmovable Flags 0x200(workingset|node=0|zone=0)
 get_page_from_freelist+0x1416/0x1600
 __alloc_frozen_pages_noprof+0x18c/0x1000
 alloc_pages_mpol+0x43/0x100
 new_slab+0x349/0x460
 ___slab_alloc+0x811/0xd90
 __kmem_cache_alloc_bulk+0xb8/0x1f0
 __prefill_sheaf_pfmemalloc+0x42/0x90
 kmem_cache_prefill_sheaf+0xa9/0x240
 mas_preallocate+0x32f/0x420
 __split_vma+0xdc/0x300
 vms_gather_munmap_vmas+0xa4/0x240
 do_vmi_align_munmap+0xe9/0x180
 do_vmi_munmap+0xcb/0x160
 __vm_munmap+0xa7/0x150
 __x64_sys_munmap+0x16/0x20
 do_syscall_64+0xa4/0x310

...

One can use tools/mm/page_owner_sort to process the information in the file, or come up with custom commands, scripts, or programs.

For example: calculate the total size of pages allocated by stress-ng-brk with any order, in MiB:

# COMM=stress-ng-brk
# cat /sys/kernel/debug/page_owner \
 | awk -F '[ ,]' \
 '/^Page allocated via order .* \('${COMM}'\)/ { PAGES+=2^$5 } 
 END { print PAGES*4096/2**20 " MiB" }'
0.0429688 MiB

More information about page_owner is available in Documentation/mm/page_owner.rst.

Problem: output size

In the page_owner file, note the significant amount of text that is produced per-page: 745 bytes, in the example above.

Considering a system with 1 GiB of RAM and 4 kB pages, fully allocated, with similarly sized entries per page, the output size might reach approximately 186 MiB! (745 [bytes/page] * (2**30 [bytes of RAM] / 4096 [bytes/page]) / 2**20 [bytes/MiB])

For validation, a test VM with 1 GiB of RAM after just a warm-up level of stress (stress-ng --sequential --timeout 1) produced 125 MiB, which was not quick to read even in idle state:

# time cat /sys/kernel/debug/page_owner \
 | wc --bytes | numfmt --to=iec
125M

real 0m3.009s
user 0m0.512s
sys 0m3.542s

While this might not be a serious issue for reading and processing the file only once, it can likely impact a sequence of operations.

Alternative: optimized output

Fortunately, another debugfs file, /sys/kernel/debug/page_owner_stacks/show_stacks, provides an optimized output for obtaining the memory usage per stack trace. Even though it doesn’t address all needs as the generic output, it resembles the default operation of page_owner_sort (without PFN lines) and provides an often interesting information for kernel development or analysis.

This example shows the entry for a stack trace – it tells “How many pages are allocated by this particular stack trace?”

# cat /sys/kernel/debug/page_owner_stacks/show_stacks
...
 get_page_from_freelist+0x1416/0x1600
 __alloc_frozen_pages_noprof+0x18c/0x1000
 alloc_pages_mpol+0x43/0x100
 folio_alloc_noprof+0x56/0xa0
 page_cache_ra_unbounded+0xd9/0x230
 filemap_fault+0x305/0x1000
 __do_fault+0x2c/0xb0
 __handle_mm_fault+0x6f4/0xeb0
 handle_mm_fault+0xd9/0x210
 do_user_addr_fault+0x205/0x600
 exc_page_fault+0x61/0x130
 asm_exc_page_fault+0x26/0x30
nr_base_pages: 9643

...

The nr_base_pages field tells the number of base pages (i.e., not huge pages) allocated by a stack trace. So, this particular stack trace for readahead (page_cache_ra_unbounded()) has allocated approximately 37 MiB (9643 [pages] * 4096 [bytes/page] / 2**20 [ bytes/MiB]).

Note this file is more efficient for this particular purpose: just 402 KiB in less than 0.05 seconds. (That is 0.3% of the size and 1.7% of the time):

# time cat /sys/kernel/debug/page_owner_stacks/show_stacks \
 | wc --bytes | numfmt --to=iec
402K

real 0m0.042s
user 0m0.004s
sys 0m0.046s

Conclusion

The page_owner debug feature (enabled with CONFIG_PAGE_OWNER=y and page_owner=on) provides information about the memory allocation of pages in the system in debugfs files /sys/kernel/debug/page_owner with a generic format (dense description per-page) and /sys/kernel/debug/page_owner_stacks/show_stacks with an optimized format (number of base pages per stack trace).

Last month I wrote up a fairly long piece on per-query energy consumption of LLMs using the data from InferenceMAX (note: InferenceMAX has since been renamed to InferenceX). Much of the write-up was dedicated to exploring what you can actually conclude from these figures and how that interacts with some of the implementation decisions in the benchmark, but I feel the results still give a useful yardstick. Beyond concerns about overly-specialised serving engine configurations and whether the workload is representative of real-world model serving in a paid API host, the other obvious limitation is that InferenceMAX is only testing GPT-OSS 120b and DeepSeek R1 0528 when there is a world of other models out there. I dutifully added "run my own tests using other models" to the todo list and here we are. By "here we are" I of course mean I made no progress towards that goal but Zach Mueller at Lambda started publishing model cards with the needed data - thanks Zach!

The setup for Lambda is simple - each model card lists the observed token generation throughput and total throughput (along with other stats) for an input sequence length / output sequence length (ISL/OSL) of 8192/1024, as benchmarked using vllm bench serve. The command used to serve the LLM (using sglang or vllm depending on the model) is also given. As a starting point this is no worse than the InferenceMAX data, and potentially somewhat better due to figures being taken from a configuration that's not overly specialised to a particular query length.

The figures each Lambda model card gives us that are relevant for calculating the energy per query are: the hardware used, token generation throughput and total token throughput (input+output tokens). Other statistics such as the time to first token, inter-token latency, and parallel requests tested help confirm whether this is a configuration someone would realistically use. Using an equivalent methodology to before, we get the Watt hours per query by:

• Determining the total Watts for the GPU cluster. We take the figures used by SemiAnalysis (2.17kW for a single B200) and multiply by the number of GPUs.
• Calculate the joules per token by dividing this total Watts figure by the total token throughput. This gives a weighted average of the joules per token for the measured workload, reflecting the ratio of isl:osl.
• Multiply this weighted average of joules per token by the tokens per query (isl+osl) to get the joules per query. Then divide by 3600 to get Wh.

Collecting the data from the individual model cards we can generate the following (as before, using minutes of PlayStation 5 gameplay as a point of comparison):

data = {
    "Qwen/Qwen3.5-397B-A17B": {
        "num_b200": 8,
        "total_throughput": 11092,
    },
    "MiniMaxAI/MiniMax-M2.5": {
        "num_b200": 2,
        "total_throughput": 8062,
    },
    "zai-org/GLM-5-FP8": {
        "num_b200": 8,
        "total_throughput": 6300,
    },
    "zai-org/GLM-4.7-Flash": {
        "num_b200": 1,
        "total_throughput": 8125,
    },
    "arcee-ai/Trinity-Large-Preview": {
        "num_b200": 8,
        "total_throughput": 15611,
    },
}

# 8192 + 1024
TOKENS_PER_QUERY = 9216

# Taken from <https://inferencex.semianalysis.com/>
B200_KW = 2.17

# Reference power draw for PS5 playing a game. Taken from
# <https://www.playstation.com/en-gb/legal/ecodesign/> ("Active Power
# Consumption"). Ranges from ~217W to ~197W depending on model.
PS5_KW = 0.2


def wh_per_query(num_b200, total_throughput, tokens_per_query):
    total_cluster_kw = num_b200 * B200_KW
    total_cluster_watts = total_cluster_kw * 1000
    # joules_per_token is a weighted average for the measured mix of input
    # and output tokens.
    joules_per_token = total_cluster_watts / total_throughput
    joules_per_query = joules_per_token * tokens_per_query
    # Convert joules to watt-hours
    return joules_per_query / 3600.0

def ps5_minutes(wh):
    ps5_watts = PS5_KW * 1000
    return (wh / ps5_watts) * 60.0

MODEL_WIDTH = 31
WH_WIDTH = 8
PS5_WIDTH = 8

header = f"{'Model':<{MODEL_WIDTH}} | {'Wh/q':<{WH_WIDTH}} | {'PS5 min':<{PS5_WIDTH}}"
separator = f"{'-' * MODEL_WIDTH} | {'-' * WH_WIDTH} | {'-' * PS5_WIDTH}"

print(header)
print(separator)

for model, vals in data.items():
    wh = wh_per_query(vals["num_b200"], vals["total_throughput"], TOKENS_PER_QUERY)
    ps5_min = ps5_minutes(wh)

    wh_str = f"{wh:.2f}" if wh < 10 else f"{wh:.1f}"
    print(f"{model.strip():<{MODEL_WIDTH}} | {wh_str:<{WH_WIDTH}} | {ps5_min:.2f}")

This gives the following figures (reordered to show Wh per query in ascending order, and added a column for interactivity (1/TPOT)):

As a point of comparison, the most efficient 8 GPU deployment of fp8 DeepSeek R1 0528 from my figures in the previous article was 3.32 Wh per query.

And that's all I really have for today. Some interesting datapoints with hopefully more to come as Lambda puts up more model cards in this format. There's a range of interesting potential further experiments to do, but for now, I just wanted to share this initial look.

• 2026-02-17: Initial publication date.

shandbox is a simple Linux sandboxing script that serves my needs well. Perhaps it works for you too? No dependencies between a shell and util-linux (unshare and nsenter).

In short, it aims to provide fairly good isolation for personal files (i.e. your $HOME) while being very convenient for day to day use. It's designed to be run as an unprivileged user - as long as you can make new namespaces you should be good to go. By default /home/youruser/sandbox shows up as /home/sandbox within the sandbox, and other than standard paths like /usr, /etc, /tmp, and so on it's left for you to either copy things into the sandbox or expose them via a mount. There's a single shared sandbox (i.e. processes within the sandbox can see and interact with each other, and the exposed sandbox filesystem is shared as well), which trades off some ease of use for the security you might get with a larger number of more targeted sandboxes. On the other hand, you only gain security from a sandbox if you actually use it and this is a setup that offers very low friction for me. The network is not namespaced (although this is something you could change with a simple edit).

Usability is both subjective and highly dependent on your actual use case, so the tradeoffs may or may not align with what is interesting for you! Bubblewrap is an example of a mature alternative unprivileged sandboxing tool that offers a lot of configurability as well as options with greater degrees of sandboxing. Beyond that, look to Firecracker based solutions or gvisor. shandbox obviously aims to provide a reasonable sandbox as much as Linux namespaces alone are able to offer, but if you're looking for a security property stronger than "makes it harder for something to edit or access unwanted files" it's down to you to both carefully review its implementation and consider alternatives.

Usage example

$ shandbox run uvx pycowsay
Installed 1 package in 5ms

  ------------
< Hello, world >
  ------------
   \   ^__^
    \  (oo)\_______
       (__)\       )\/\
           ||----w |
           ||     ||
$ shandbox status
running (pid 1589364)

log:
  2026-02-11 13:02:51 stopped
  2026-02-11 13:05:06 started (pid 1589289)
$ shandbox add-mount ~/repos/llvm-project /home/sandbox/llvm-project
mounted /home/asb/repos/llvm-project -> /home/sandbox/llvm-project
$ shandbox run touch /home/sandbox/llvm-project/write-attempt
touch: cannot touch '/home/sandbox/llvm-project/write-attempt': Read-only file system
$ shandbox remove-mount /home/sandbox/llvm-project
unmounted /home/sandbox/llvm-project
$ shandbox add-mount --read-write ~/repos/llvm-project /home/sandbox/llvm-project
mounted /home/asb/repos/llvm-project -> /home/sandbox/llvm-project
$ shandbox run touch /home/sandbox/llvm-project/write-attempt

shandbox enter will open a shell within the sandbox for easy interactive usage. As a convenience, if the current working directory is in $HOME/sandbox (e.g. $HOME/sandbox/foo) then the working directory within the sandbox for shandbox run or shandbox enter will be set to the appropriate path within the sandbox (/home/sandbox/foo in this case). i.e., the case where this mapping is trivial. Environment variables are not passed through.

Functionality overview

• shandbox start: Start the sandbox, creating the necessary namespaces and mount layout. Fails if the sandbox is already running.
• shandbox stop: Stop the sandbox by killing the process holding the namespaces. Fails if the sandbox is not running.
• shandbox restart: Stop the sandbox and start it again.
• shandbox status: Print whether the sandbox is running and if it is, the pid. Also print the last 20 lines of the log.
• shandbox enter: Open bash within the sandbox, starting the sandbox first if it's not already running.
• shandbox run <command> [args...]: Run a command inside the sandbox. The current working directory is translated to an in-sandbox path if it falls within the sandbox home directory. Starts the sandbox first if it isn't already running.
• shandbox add-mount [--read-write] <host-path> <sandbox-path>: Bind-mount a host path into the running sandbox. Mounts are read-only by default; pass --read-write to allow writes. The sandbox must already be running. Both directories and individual files are supported.
• shandbox remove-mount <sandbox-path>: Remove a previously added bind mount from the running sandbox.

Implementation approach

The core sandboxing functionality is provided by the Linux namespaces functionality exposed by unshare and nsenter. The script's implementation should be quite readable but I'll try to summarise some key points here.

The goal is that:

• Within the sandbox, you appear as an unprivileged user, with uid and gid equal to your usual Linux user.
• It should be possible to expose additional files or directories to the sandbox once it's running.
• Applications running within the sandbox have no way (modulo bugs or vulnerabilities in the kernel or accessible applications) of reaching files on the host filesystem that aren't explicitly exposed.
  • To underline: This is a goal, it is not a guarantee.
• It's possible to launch multiple processes within the sandbox which can all see each other, and have the same shared sandboxed filesystem.
• This is all doable as an unprivileged user.

To implement that:

• Two sets of namespaces are used to provide this isolation: the outer 'shandbox_root' has the user mapped to root within the namespace and retains access to standard / (allowing us to mount additional paths into after the sandbox has started). The inner 'shandbox_user' represents a new user namepsace mapping our uid/gid to an unprivileged user, but other namespaces are shared with 'shandbox_root'. Sandboxed processes are launched within the namespaces of 'shandbox_user'.
• The process IDs of the initial process within 'sandbox_root' and 'sandbox_user' are saved and recalled so the script can use nsenter to enter the namespace.
• To help make it easier to tell when you're in the sandbox, a dummy /etc/passwd is bind-mounted naming the current user as sandbox.
• When shandbox start is executed, the necessary directories are bind mounted in a directory that will be used as root (/) for the user sandbox in .local/share/shandbox/root. This happens within the sandbox_root namespace, which then uses unshare again to create a new user namespace with an unprivileged user, executing within a chroot.
• 'sandbox_root' retains access to the host filesystem, which is necessary to allow mounting additional paths after the fact. Without this requirement, we could likely rewrite shandbox start to use pivot_root.

Making it your own

The script should be straight-forward enough to customise to your needs if they're not too dissimilar to what is offered out of the box. Some variables at the top provide things you may be more likely to want to change, such as the home directory location, and a list of files or directories in $HOME to always bind-mount into the sandbox home:

SANDBOX_HOME_DIR="$HOME/sandbox"
HOME_FILES_TO_MAP=".bashrc .vimrc"
HOME_DIRS_TO_MAP=".vim bin"
SB_HOME="/home/sandbox"
SB_PATH="$SB_HOME/bin:/usr/local/bin:/usr/bin"

• 2026-02-11: Initial publication date.

Over the last year, as part of the collaboration between Igalia and Bloomberg to improve web performance observability, I worked on a new web performance API: Container Timing. This standard aims to make component-level performance measurement as easy as page-level metrics like LCP and FCP.

My focus has been writing the native implementation in Chromium, which is now available behind a feature flag.

In this post, I will explain why this API is needed, how it works, and how you can experiment with it today. In a follow-up post, I will dive deep into the implementation details within the Blink rendering engine.

The problem: measuring component performance #

We currently use Largest Contentful Paint (LCP) and First Contentful Paint (FCP) to measure web page loading performance. Both metrics are page-scoped, meaning they evaluate the user perceived load speed for full page.

The Element Timing API shifts the focus to individual DOM elements. By targetting specific elements, like hero images or a headers, we can measure their specific rendering performance independent of the rest of the page.

However, modern web development is component-based. Developers build complex widgets (as grids, charts, feeds or panels) that are made of many elements. It is not trivial to understand the performance of those components:

• LCP may not be useful as another large image painting could delay it.
• Measuring a web component with Element Timing may require instrumenting all the significant elements one by one.

The solution: Container Timing #

This is where Container Timing comes in! With the new specification, a web developer can mark subtrees of the DOM as “containers”. Then, it provides performance entries aggregating the painting time of that subtree.

This way, we can answer: “when did a specific component finish painting its content?”.

Some examples:

• Breaking down the contributors to the initial page load: with Container Timing we can focus on the components that are more relevant to the user experience.
• Single page application navigation: when a soft navigation shows a new component on the screen, we can obtain painting information for it.
• Lazy-loaded components: Tracking when a widget that loads below the fold is fully visible.
• Third-party content: Monitoring the performance of ads or embedded widgets.

You just need to add, to the top element of the subtree, the new attribute containertiming. When you add it to an HTML element, the browser will track all the painting updates of that element and its descendants.

What happens under the hood? The browser will start monitoring the rendering pipeline for paints that contribute to representing the subtree. When a new frame is painted, if that paints new areas for that subtree, it reports a performance entry showing the increase in painted area. It is similar to LCP, but for a specific subtree!

How to use Container Timing? #

Using the API is straightforward. First, mark the containers you want to track in HTML:

<div id="my-widget" containertiming="widget-load">
  <img src="graph.png" />
  <p>Loading data...</p>
</div>

Then, use a PerformanceObserver to listen for container entries:

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    console.log(`Container '${entry.identifier}' painted.`);
    console.log(`Time: ${entry.startTime}`);
    console.log(`Size: ${entry.size}`); // The area painted
  });
});

observer.observe({ type: "container", buffered: true });

When the web contents load, new Performance entries will be emitted with the container updates.

Which entry will be interesting? The API lets you choose what best fits your needs! Some ideas:

• The most important entry could be the last one: the one that increased the painted area for the last time. Something similar to LCP.
• Or maybe the last one that contributed a significant size increase?
• Or the last one before a user interaction?

A native implementation for Chromium #

In the initial steps of the specification, Jason Williams wrote a polyfill that worked on top of Element Timing. This was very useful to understand and polish the kind of information the specification could provide. However, this had its own performance impact.

So I started a native implementation in Chromium. The main idea was working on top of the already existing implementation for Element Timing, and add the remaining bits.

In my next blog post I will go through the implementation details. But, for this post, it is relevant to state that the goals of this native implementation were:

• Minimizing the overhead. It should be almost zero when elements are not interesting to Container Timing, and very fast and light when paints were relevant.
• It should reuse as much as possible of the already existing logic for Element Timing.

The native implementation has landed and is available in Chromium144+, but still behind the ContainerTiming feature flag.

You can experiment with this feature locally by passing the following flag to Chromium at startup:

chrome --enable-blink-features=ContainerTiming

Or you can just enable the “Experimental Web Platform features” in chrome://flags.

Upcoming trials #

So now, it is time to collect feedback from the actual web developers.

We have already presented the specification in several conferences (as BlinkOn 20 or Performance.now() 2024). And discussions are ongoing in the Web Performance Working Group.

We just announced the Dev Trial in the blink-dev mailing list! The feature is now officially ready for testing.

What’s next? We are also preparing an Origin Trial, that will allow developers to test the specification in production for a subset of their users.

If you want to provide feedback, we are collecting it in the explainer ticket tracker.

Wrapping up #

With Container Timing, you will be able to measure paintings at the web component level, filling a significant gap in the web performance monitoring landscape.

If you struggled with finding out the ready time of your widgets, just try it! It is available, under the feature flags ContainerTiming, in Chromium Stable today.

And stay tuned! In a follow up post, I will go through the native implementation details in Chromium.

Thanks! #

This has been done as part of the collaboration between Bloomberg and Igalia. Thanks!

References #

• Container Timing explainer
• Container Timing specification draft
• Ticket tracker for specification discussion
• Chrome status feature: Container Timing
• Container Timing ready for testing announcement in blink-dev
• Container Timing native implementation Chromium issue

Update on what happened in WebKit in the week from February 2 to February 9.

The main event this week was FOSDEM (pun intended), which included presentations related to WebKit; but also we got a batch of stable and development releases, asynchronous scrolling work, OpenGL logging, cleanups, and improving the inspector for the WPE work.

Cross-Port 🐱

Graphics 🖼️

WebKitGTK 🖥️

WPE WebKit 📟

Releases 📦️

Community & Events 🤝

Hey, hey, it’s the beginning of a new year and before we sprint too far into 2026, let’s take a quick breather, zoom out, and celebrate what Igalia’s awesome compilers team got up to in 2025. Over the past year we’ve been deeply involved in shaping and shipping key Web and JavaScript standards, which includes not just participating in committees but also chairing and actively moving the proposals forward. We worked on major JavaScript runtimes and foundational ahead-of-time compilers including LLVM and Mesa, as well as JIT CPU emulation, and smaller language VMs.

Some big highlights of this year included our work on FEX and Mesa that helped Valve with their upcomimg gaming devices - the Steam Frame and the Steam Machine (we talk more about this in a dedicated blog post), our continued involvement in supporting RISC-V in contemporary compilers, and our key role in multiple WebAssembly implementations.

Standards #

In 2025, our standards work focused on parts of JavaScript developers touch every day like time, numbers, modules and more. Across TC39, WHATWG, WinterTC and internationalization ecosystems, we helped move proposals forward while turning specifications into running, interoperable code. So yep, let’s talk about our most significant standards contributions from the year!

Temporal #

It’s been an exciting year for the Temporal proposal, which adds a modern date-and-time API to JavaScript. For starters, MDN published their API documentation for it, which created a huge surge of interest.

On the shipping front: Firefox shipped their implementation of the proposal and it’s now available in Firefox 139. Chrome moved their implementation to beta in late 2025, and released it in early 2026. Meanwhile, we’ve been steadily working on getting Temporal into Safari, with support for correct duration math and the PlainMonthDay and PlainYearMonth types added during 2025/early 2026. You can read more about this in our recent post on implementing Temporal.

Alongside that, we’ve been working on the Intl Era and Month Code proposal, which has expanded in scope beyond era codes and month codes to cover other calendar-specific things that a JS engine with Intl must implement. This allows developers to make use of a number of commonly-used non-Gregorian calendars, including but not limited to the calendar used in Thailand, the Japanese Imperial calendar, and Islamic calendars.

Decimal #

A lot of our recent work around the Decimal proposal has now migrated to a newer similarly number-focused effort called Amount (formerly known as "Measure" and officially renamed in 2025). The proposal reached Stage 1 at the November 2024 TC39 plenary. We also launched a polyfill. Since then, we have iterated on the Amount API and data model a number of times in plenary. So while it started 2025 at stage 1 and remains at stage 1 heading into 2026, the design is noticeably sharper, thanks to a lot of TC39 discussions. We’re lined up to keep it pushing forward next year.

And because numerics work benefits a ton from regular iteration, in late 2024, we also kicked off a biweekly community call ("JS Numerics") for those in TC39 interested in proposals related to numbers, such as Decimal, Amount, intl-keep-trailing-zeros, etc. We still host it, and it’s turned out to be a genuinely productive place to hash things out without waiting for plenary.

Source Maps #

We implemented draft range mappings implementations on a number of systems: WebKit, Justin Ridgewell’s source map decoder, a source map validator, and more.

We also facilitated source map TG4 meetings and assisted with advancing proposals such as the scopes proposal. Throughout the year, we continued serving as editors for the ECMA-426 specification, landing a steady stream of improvements and clarifications.

Modules #

We pushed JavaScript’s module system forward on multiple fronts, especially around reducing the impact of modules on application startup:

• we advanced the import defer proposal, which allows modules to be be synchronously lazily evaluated, to Stage 3 in TC39. We are working on its implementations in V8 and WebKit, and we implemented it in Babel, webpack (together with other community members) and TypeScript.
• we presented export defer and pushed it to Stage 2 in TC39: it allows more granular lazy evaluation, as well as built-in browser support for tree-shaking of re-exports.

We are among the most active members of the "Modules Harmony" group, an unofficial group within TC39 that aims at improving the capabilities of ESM to improve native adoption, while making sure that all modules proposals are well-coordinated with each other.

AsyncContext #

And over in the AsyncContext proposal world, we spent 2025 focusing on how the proposal should integrate with various web APIs. The way AsyncContext interacts with the web platform is unusually pervasive, and more challenging to figure out than the core TC39 proposal itself.

In a first for a TC39 proposal, it is not also going through the WHATWG stages process, where it has reached Stage 1. This gives us a clearer path to iterate with direct feedback from browser engines.

Unicode standards #

We have been working on Unicode MessageFormat, which is a Unicode standard for localizable dynamic message strings, designed to make it simple to create natural sounding localized messages.

In 2025, we helped the ICU4C implementation of Unicode MessageFormat align with ongoing specification changes. We also carried out experimental work on the custom function interface to support more extensible formatting formatting capabilities, which is currently under review.

WinterTC #

In December 2024, WinterTC was formed to replace WinterCG as an official ECMA Techincal committee to achieve some level of API interoperability across server-side JavaScript runtimes, especially for APIs that are common with the web.

We started chairing (together folks from Deno), and became involved in admin tasks. Over the course of the year, we:

• Identified a core set of Web APIs that should be shared across runtimes and standardized it as the Minimum Common Web API specification, which was officially published at the ECMA General Assembly in December.
• Started identifying a subset of the WPT test suite that covers the Minimum Common Web API, and made some headway towards clarifying which parts of the Fetch specification server-side runtimes should support, and which they shouldn’t.

Additionally, if you’re curious, we gave two talks about WinterTC: one at the Web Engines Hackfest together with Deno folks, the other chair of WinterTC; and one at JSConf.JP.

Node.js #

In Node.js, our work in 2025 spanned interoperability, proxy integration, and adding support for HTTP/HTTPS proxy and shipping integration of System CA certificates across platforms.

On the module side, we delivered interoperability features and bug fixes for require(esm) and helped stabilize it (read more about it in our colleague Joyee’s blog), shipped synchronous and universal loader hooks (now promoted to release candidate), integrated TypeScript into the compile cache, and improved the portability of the cache. Check out Joyee’s talk at JSConf JP if you are interested in learning more about these new module loader features.

We also strengthened System CA certificate integration along with JavaScript APIs for reading and configuring trusted CAs globally, adding built-in HTTP/HTTPS proxy support, and expanding documentation for using Node.js in enterprise environments.

Additionally, we started migration to the new V8 CppHeap model in Node.js and improved its V8 Platform integration.

V8 #

On the V8 side of things, we worked on HeapProfiler::QueryHolders, a companion API to the QueryObjects API.

We worked on extending the HeapStatistics API to include a new field that tracks the total of bytes allocated in an Isolate since its creation. This counter excludes allocations that happen due to GC operations and it’s intended to be used to create memory regression tests. Here’s the CL highlighting these changes.

We also started working on implementation of the import defer proposal on V8. This proposal extends the syntax of ESM imports to allow a mode where the evaluation of an imported module is deferred until its first access. From our work in Node.js, we upstreamed a few improvements and bug fixes in V8’s embedder API and startup snapshot implementation. We also contributed to Node.js’s V8 upgrade and upstreamed patches to address issues discovered in the upgrade.

As part of our collaboration with Cloudflare we added v8::IsolateGroup: a new unit that owns an independent pointer-compression cage. We then also enabled multiple cages per process (“multi-cage”), so thousands of isolates aren’t forced into one < 4 GiB region. Finally, we extended this to multiple sandboxes: one sandbox per isolate group instead of a single process-wide sandbox. In the end this work helped Cloudflare to enable the sandbox in Cloudflare workers.

Babel #

Our team also helps co-maintianing Babel. The build tools area is very active nowdays, and we strongly believe that alongside the innovation happening in the ecosystem companies need to invest on ensuring that the older and widely used tools keep being actively maintained and improving over time.

LLVM #

In LLVM, we helped extend auto-vectorization to take full advantage of the RISC-V vector extension’s many innovative features.

After four years of development by contributors from multiple organizations including Igalia, we finally enabled EVL tail folding for RISC-V as an LLVM default.

This work took advantage of the new VPlan infrastructure, extending it and developing it iteratively in-tree when needed to give us the ability to model a relatively complex vectorization scheme.

We also added full scalable segmented access support and taught the loop vectorizer to make smarter cost model decisions.

Building on top of this, we achieved improvements in RISC-V vectorization. In parallel, we also worked on LLVM scheduling models for the SpacemiT-x60 RISC-V processor, scoring a whopping 16% performance improvement.

Regarding WebAssembly in LLVM we landed a number of commits that improve size and performance of generated code, and added support for a few ISD nodes that enable vectorization for otherwise sequential codegen.

Mesa/IR3 #

We continued work on improving IR3, the Mesa compiler backend for Qualcomm Adreno GPUs. We implemented support for alias instructions novel to the a7xx generation of GPUs, significantly improving register pressure for texture instructions. We also refactored the post-RA scheduler to be able to reuse the legalization logic, significantly improving its accuracy when calculating instruction delays and, consequently, reducing latency.

We also added debug tooling to easily identify the shader that causes problems, among many other optimizations, implementations of new instructions, and bug fixes.

Guile and Whippet #

This year we also made some interesting progress on Whippet, a no-dependencies embeddable garbage collector. We were able to integrate Whippet into the Guile Scheme implementation, replacing Guile’s use of the venerable Boehm-Demers-Weiser library. We hope to merge the integration branch upstream over the next months. We also wrote up a paper describing the innards of some of Whippet’s algorithms.

We think Whippet is interesting whereever a programming language needs a garbage collector: it’s customizable and easy to manage, as it is designed to be "vendored" directly into a user’s source code repository. We are now in the phase of building out examples to allow for proper performance evaluation; after a bespoke Scheme implementation and Guile itself, we also wrote a fresh ahead-of-time compiler for WebAssembly, which in the near future will gain support for the garbage collection WebAssembly extensions, thanks to Whippet. For more info on our progress, check out Andy Wingo’s blog series.

FEX #

For the FEX x86 JIT emulator for ARM64, we worked on X87 Floating-Point Emulation, implemented x87 invalid operation bit handling in F80 mode, fixed IEEE 754 unordered comparison detection, and added f80 stack xchg optimization for fast path.

Besides further fixes for instruction implementations, we also worked on memory and stability improvements, protecting the last page of CodeBuffer, and implementing gradual memory growth. Finally, we also did some infrastructure work by upgrading the codebase to clang-format-19 and adding UBSAN support.

This year’s FEX work focused on x87 floating-point correctness and 32-bit compatibility—both critical for Valve’s Steam Frame, the ARM-powered VR headset they announced in November that uses FEX to run x86 games.

The x87 improvements matter because many games and middleware still use legacy floating-point code. Subtle deviations from Intel’s behavior—wrong exception flags, incorrect comparison semantics—cause crashes or weird behavior. Fixing invalid operation exceptions, IEEE 754 comparisons, and optimizing the x87 stack pass eliminated entire classes of compatibility bugs.

The 32-bit fixes are just as important. A huge chunk of Steam’s catalog is still 32-bit, and even 64-bit games often ship 32-bit launchers. Getting fcntl and addressing modes right means these games just work without users needing to do anything.

In total, this work gave Valve confidence that the Steam Frame could ship with solid library coverage, letting them announce the device on schedule.

Alright, that’s a wrap on our 2025 retrospective! We hope you had as much fun reading it as we had writing it, and building all the things we talked about along the way. We’ll see you next year with another roundup; until then, you can keep up with our latest work on the team blog.

Last weekend I was in Brussels attending FOSDEM. A big event with lots of people and lots of things happening in parallel, where it’s impossible to be everywhere.

Browser and web platform 🌐 #

My main participation was in the Browser and web platform devroom, a new devroom (it seems it already happened back in the days, but not in the recent years) where I had the chance to speak about Servo with a talk titled The Servo project and its impact on the web platform ecosystem. My colleagues from Igalia Eri Pazos and Mario Sánchez Prada were also speaking in that devroom about Interop and MathML Core and The Web Platform on Linux devices with WebKit: where are we now? respectively. The room was fully packed a big part of the day, not unexpectedly many people are interested in the web platform.

MathML #

Eri was the first igalian talking in the room, they summarized the work Igalia has been doing for many years in MathML, on the standards side proposing the MathML Core spec, and on the implementation side bringing it back to Chromium and improving it in Gecko and WebKit.

In the talk, Eri went into deep detail about the last additions we have been adding around MathML: math-depth, math-shift, RTL mirroring, font-family: math, etc. This work is part of an agreement with the Sovereign Tech Fund, big thanks for your support.

MathML is more ready than ever for production, someone from arXiv.org in the audience mentioned that they are shipping it on millions of webpages today. Waiting for the day when Wikipedia switches to it by default, it will be a huge milestone.

WebKit on Linux #

Mario talked about the Linux ports of WebKit: WebKitGTK and WPE, both maintained by Igalia.

He explained what they are, the differences between them, reviewed their history and highlighted the big progress on the recent years, with multiple improvements in several areas: WebPlatform API, WebKit Container SDK, switch from Cairo to Skia graphics library, etc.

If you are curious about the status of things regarding them, you shouldn’t miss his talk.

Servo #

My talk started with an introduction to the Servo project and the current status of things. I showed a few demos about how Servo works and some of the things it can do already. After that introduction, I explained how Servo has been contributing to the wider web platform ecosystem.

Like for the rest of talks, slides and video are already available if you want to know all the details. Kudos to the organization for being so quick.

As an anecdote, the night before the talk a new project based on Servo was published, a browser developed fully with web technologies using Servo underneath. I couldn’t resist the urge to build it, play with it and add it to the presentation. It looks really cool what Servo can do these days.

In addition, in the same devroom there was another Servo talk, this time by Taym, one of the Servo maintainers, Implementing Streams Spec in Servo web engine, where he explained all the work behind adding Streams support to Servo.

I am also very happy to met many Servo contributors at the event: Delan Azabani (@delan), Eri Pazos (@eerii), Jonathan Schwender (@jschwe), Martin Robinson (@mrobinson), Taym Haddadi (@Taym95), Tim van der Lippe (@TimvdLippe). We had the chance to have some informal conversations about the project, discussing some technical topics and ideas about things we can do in Servo.

The feedback about Servo has been extremely positive, people are really happy with the evolution of the project and excited about the future.

Apart from that, we also had the opportunity to talk to the nice folks from NLnet and the Sovereign Tech Agency who both have ongoings collaborations around Servo. The work these organizations do is really important for the open software development, and more should learn from them and join forces to try to fix the funding issues in FLOSS (more about this later, when talking about Marga’s keynote).

Igalia #

Igalia presence in the open source community is very big, and not unexpectedly we have more talks at FOSDEM this year. This is the full list:

• WebRTC support in WebKitGTK and WPEWebKit with GStreamer: Current status and plans by Philippe Normand
• From Bookworm to Trixie: Upgrading the Raspberry Pi graphics stack by José María Casanova Crespo
• Wastrel: WebAssembly Without the Runtime by Andy Wingo
• Mesa3D: the heart of the linux graphics stack by Juan A. Suarez

Also our work in different projects was mentioned in several talks and conversations, we’re really happy regarding all the good feedback we got about Igalia contributions.

Keynote #

Marga Manterola was doing one of the keynotes talking about funding open source software: Free as in Burned Out: Who Really Pays for Open Source? . First time Igalia was doing a keynote at FOSDEM, in the year we celebrate our 25th anniversary, and in a historical auditorium where May 68 started in Brussels. 🎉

The talk was great, Marga explained many of the issues with open source software sustainability and some potential ideas about how to improve the situation. This is a recurring topic in many conversations these days, we should find a way to get this fixed somehow.

There I learnt about the Open Source Pledge, an interesting initiative to get companies donating 2,000 USD per developer to open source software maintainers. 💰

Wrap up #

All in all, it was a nice but very busy weekend in Brussels, weather was ok (a bit cold but not rainy) and waffles were delicious as usual. 🧇😋

Next big event on my calendar is the Web Engines Hackfest in June, more than 50 people have already registered and a bunch of Servo folks will be there too. If you’re interested in the web platform and willing to discuss about different topics, we would be very happy to host you there.

What if we just

What if a better answer to a question I've been struggling with for more than a decade is just... Way simpler? Sharing a potentially half-baked idea for discussion.

Back in 2013 I wrote Dropping the F-Bomb on Web Standards. The core argument was simple: the web works best when developers can invent “slang,” and standards bodies behave more like dictionary editors — watching what people actually say, then paving the cow paths that clearly matter.

It fed into the Extensible Web Manifesto (which followed) and over the years I've continued to push for study of what people are really doing. I have helped add features to the HTTPArchive crawl and built tools to analyze this data.

But it's hard. It's biased. It's incomplete. Even the best crawl misses huge swaths of the web — anything behind logins, paywalls, dashboards, internal tools, or private deployments. And all of them have limits. It requires a ton of follow-up analysis and raises almost as many questions as it answers.

So lately I've been wondering (a bit like Kramer):

What if we just... voluntarily shared this information?

We don't need a formal standard or anyone's permission, we could just... share it, and build tools to share it easily in a well known format at a well known URL.

It could give us insight into the use of custom elements behind logins and paywalls and so on too, and tell us where they come from (a git repo, for example)...

Lots of things that are common happened through community effort and adoption. Normally you get something from it - robots.txt helped your site from being aggressively scraped in problematic ways, ads.txt helped say something about monetization, feed.rss helped syndicate, and so on. What do you get out of sharing this kind of info?

Individually, I'm not sure. But, collectively the benefit is clear: We'd finally have a real, ecosystem‑wide index of custom elements and how they're used. and hopefully a way to shape useful standards on them easily.

As to what that would look like, I'm not sure.

The community defined Custom Element Manifest already has a bit of uptake and tooling - we could just publish that to a well known URL. It might be too much, or too little.. A simpler manifest of just element names and URLs of packages/repositories that supply them would even be nice.

Is it too much? Too little? Maybe.

Is it worth trying? I think so.

What do you think? Is this worth trying somehow?

Update on what happened in WebKit in the week from January 26 to February 2.

A calm week for sure! The highlight this week is the fix for scrolling not starting when the main thread is blocked.

Cross-Port 🐱

Graphics 🖼️

Maintaining the Bridges

Thoughts and analogies about infrastructure...

I live in Pittsburgh, Pennsylvania — “The Steel City,” once the beating heart of American steelmaking. In 1902, U.S. Steel’s first full year of operation, it produced 67% of all steel in the United States. By 1943, the company employed more than 340,000 people. We burned so much coal that Pittsburgh earned the nickname “Hell with the lid off.” Streetlights sometimes ran at noon because the sky was that dark.

The city’s geography didn’t make things any easier. Pittsburgh is carved by mountains, valleys, and the three rivers — the Allegheny and Monongahela merging to form the Ohio. That topography, combined with the industrial boom, meant we built a lot of bridges. It helps that when your city is literally manufacturing the materials, you get a hometown discount.

One of them, the Hot Metal Bridge — just a mile or two from my house — once carried ladle cars full of molten iron between the blast furnaces and mills of J&L Steel. During World War II, 15% of America’s steelmaking capacity crossed that bridge, up to 180 tons per hour.

These bridges were originally built by private companies with a clear profit motive: to move coal, ore, steel, or workers. Others were toll bridges, run by private companies the way you’d run a turnpike or ferry.

But more bridges meant more industry, which meant more people, which meant more bridges. You can see where this goes.

Even by the late 1800s we were beginning to publicly fund them. By the 1920s–1930s Allegheny County’s bridge program bought out many of the private bridges and replaced many of them. By the time the New Deal and Interstate era arrived, the private‑toll era was basically over - and since then over 90% of Pittsburgh's public bridges were funded by federal programs (we still have some private industry use bridges).

So what does any of this have to do with software?

Aside from giving me an excuse to talk about my city (which I enjoy), Pittsburgh’s bridges are a useful metaphor for the infrastructure we rely on in tech, in two important ways:

1. Becoming a public good Private investment built early bridges, just like private companies built much of what we've got now in terms of browser engines, search index, foundational libraries and so on - but eventually they stopped becoming optional. I think we're only now starting to really understand that we need a lot of this to be a public good in the same kind of way. These are the roads and bridges of the modern world.

2. Building something new is exciting. Maintaining it, not so much. A lot of my city's physical infrastructure is aging and some of it has been neglected. It's somehow way easier to get people to build new things than to take care of the old stuff. The public notices a new bridge! The ribbon-cutting gets a photo op and celebration. The maintenance budgets and crews struggle to even get funding.

In fact, even when things are fairly well funded, it doesn't mean they're kept up to date. While researching to write this piece I realized that a lot of the Wikipedia data about Pittsburgh (and many topics!) is actually really out of date. It's cool to write the article with these cool facts, but it's not so cool to do the work to keep it up... Or, maybe thats just not what you want to do anymore. Or maybe you were incarcerated, or you died, or you went to Mars - idk.

The point is that writing the thing in the first place is only half the battle. If most of your entry on a city was written two decades ago, a lot of what it details about the economics, population, jobs, and so on are probably not very accurate!

It's no different with software. It's cool and fun to build a new thing or add a new feature to an existing thing, but keeping them maintained is annoying. New mechanisms arrive that you might need to adapt to. Underlying code bit rots. All of it needs release teams and Q&A and reviews and fixes and updates at global scales, even if no new features were added. But very few people actually want to do that, and almost nobody wants to pay for it.

More Public Funding

I'd really love for societies around the world to come to the realization that a lot of the online things we've built are, like roads and bridges, now necessary - and figure out how we can publicly fund enough of them that important things without an obvious and direct profit motive can get done. MathML and SVG are two easy examples of this, but there are plenty more. Maybe XSLT is another example. Perhaps if we had good funding for those things, their ongoing survival wouldn't be questioned.

I feel like there is a lot of room here for improvement from the status quo. It doesn't even have to start with governments. Any ways that we expand the pool of funding avilable and diversifying, it helps.

Image source

For the past year, I've been working on implementing the Temporal proposal for date and time handling in JavaScript, in JavaScriptCore (JSC). JavaScriptCore is the JavaScript engine that's part of the WebKit browser engine. When I started, Temporal was partially implemented, with support for the Duration, PlainDate, PlainDateTime, and Instant types. However, many test262 tests related to Temporal didn't pass, and there was no support for PlainMonthDay, PlainYearMonth, or ZonedDateTime objects. Further, there was no support for the relativeTo parameter, and only the "iso8601" calendar was supported.

Duration precision (landed) #

Conceptually, a duration is a 10-tuple of time components, or a record with the fields "years", "months", "weeks", "days", "hours", "seconds", "milliseconds", "microseconds", and "nanoseconds".

One way durations are used is to represent the difference between two dates. For example, to find the length of time from a given date until the end of 2027, I could write the following JS code:

> const duration = (new Temporal.PlainDate(2026, 1, 26)).until(new Temporal.PlainDate(2027, 12, 31), { largestUnit: "years" })
> duration
Temporal.Duration <P1Y11M5D> {
  years: 1,
  months: 11,
  days: 5
}

The until method in this case returns a duration comprising one year, eleven months, and five days. Because durations can represent differences between dates, they can also be negative:

> const duration = (new Temporal.PlainDate(2027, 12, 31)).until(new Temporal.PlainDate(2026, 1, 26), { largestUnit: "years" })
> duration
Temporal.Duration <P1Y11M5D> {
  years: -1,
  months: -11,
  days: -5
}

When converted to nanoseconds, the total of days, hours, minutes, seconds, milliseconds, microseconds, and nanoseconds for a duration may be a number whose absolute value is as large as 10⁹ × 2⁵³. This number is too large to represent either as a 32-bit integer or as a 64-bit double-precision value. (If you're wondering about the significance of the number 2⁵³, see the MDN documentation on JavaScript's MAX_SAFE_INTEGER.)

To understand why we need to be able to work with such large numbers, consider totaling the number of nanoseconds in a duration. Following on the previous example’s definition of the variable duration:

> duration.total({unit: "nanoseconds", relativeTo: new Temporal.PlainDate(2025, 12, 15)})
60912000000000000

There are 60912000000000000 nanoseconds, or about 6.1e16, in a period of one year, eleven months, and five days. Since we want to allow this computation to be done with any valid start and end date, and valid years in Temporal range from -271821 to 275760, the result can get quite large. (By default, Temporal follows the ISO 8601 standard for calendars, which entails using a proleptic Gregorian calendar. Also note that this example uses a PlainDate, which has no time zone, so computations are not affected by daylight savings time; when computing with the Temporal ZonedDateTime type, the specification ensures that time zone math is done properly.)

To make it easier for implementations to fulfill these requirements, the specification represents durations internally as Internal Duration Records and converts between JavaScript-level duration objects and Internal Duration Records (which I'll call "internal durations") as needed. An internal duration pairs the date component of the duration (the years, months, weeks, and days fields) with a "time duration", which is a single integer that falls within an accepted range, and can be as large as 2⁵³ × 10⁹ - 1.

Implementations don't have to use this representation, as long as the results are observably the same as what the specification dictates. However, the pre-existing implementation didn't suffice, so I re-implemented durations in a way that closely follows the approach in the specification.

This work has been landed in JSC.

New date types #

Temporal's date types include PlainDate, PlainDateTime, Instant, ZonedDateTime, PlainMonthDay, and PlainYearMonth. The latter two represent partial dates: either a pair of a month and a day within that month, or a pair of a year and month within that year. Partial dates are a better solution for representing dates where not all of the fields are known (or not all of the fields matter) than full dates with default values for the missing bits.

Temporal's ZonedDateTime type represents a date along with a time zone, which can either be a numeric offset from UTC, or a named time zone.

I implemented PlainMonthDay and PlainYearMonth with all their operations. ZonedDateTime is fully implemented and the first pull request in a series of PRs for it has been submitted.

The relativeTo parameter #

What if you want to convert a number of years to a number of days? Temporal can do that, but there's a catch. Converting years to days depends on what year it is, when using the ISO 8601 calendar (similar to the Gregorian calendar), because the calendar has leap years. Some calendars have leap months as well, so converting years to months would depend on what year it is as well. Likewise, converting months to days doesn't have a consistent answer, because months vary in length.

For that reason, the following code will throw an exception, because there's not enough information to compute the result:

> const duration = Temporal.Duration.from({ years: 1 })
> duration.total({ unit: "days" })
Uncaught RangeError: a starting point is required for years total

The above definition of duration can still be made to work if we pass in a starting point, which we can do using the relativeTo parameter:

> duration.total({ unit: "days", relativeTo: "2025-01-01" })
365
> duration.total({ unit: "days", relativeTo: "2024-01-01" })
366

The string passed in for the relativeTo parameter is automatically converted to either a PlainDate or a ZonedDateTime, depending on which format it conforms to.

I implemented support for the relativeTo parameter on all the operations that have it; once the implementations for all the date types land, I'll be submitting this work as a series of pull requests.

Calendars #

Representing dates with non-ISO8601 calendars is still very much a work in progress. The ICU library can already do the basic date computations, but much glue code is necessary to internally represent dates with non-ISO8601 calendars and call the correct ICU functions to do the computations. This work is still underway. The Temporal specification does not require support for non-ISO8601 calendars, but a separate proposal, Intl Era Month Code, proposes a set of calendars to be supported by conformant implementations.

Testing Temporal #

The JavaScript test suite is called test262 and every new proposal in JavaScript must be accompanied by test262 tests. Not all JS implementations are required to support internationalization, so Temporal tests that involve non-ISO calendars or named time zones (other than the UTC time zone) are organized in a separate intl402 subdirectory in test262.

The test262 suite includes 6,764 tests for Temporal, with 1,791 of these tests added in 2025. Igalia invested hundreds of hours on increasing test coverage over the past year.

Status of work #

All of this work is behind a flag in JSC in Technology Preview, so to try it out, you'll have to pass the --useTemporal=1 flag.

All of the implementation work discussed above (except for non-ISO calendars) is complete, but I've been following an incremental approach to submitting the code for review by the JSC code owners. I've already landed about 40 pull requests over the course of 2025, and expect to be submitting at least 25 more to complete the work on PlainYearMonth, ZonedDateTime, and relativeTo.

Based on all the code that I've implemented, 100% of the non-intl402 test262 tests for Temporal pass, while the current HEAD version of JSC passes less than half the tests.

My colleagues at Igalia and I look forward to a future JavaScript standard that fully integrates Temporal, enabling JavaScript programs to handle dates more robustly and efficiently. Consistent implementation of the proposal across browsers is a key step towards this future. Step by step, we're getting closer to this goal.

We thank Bloomberg for sponsoring this work.

On my way to FOSDEM where tomorrow I’ll be talking about Servo in the Browser and web platform devroom. See you there!

Three years ago, I wrote a blog post about How Shadow DOM and accessibility are in conflict.

I explained how the encapsulation provided by shadow roots is a double-edged sword, particularly when it comes to accessibility. Being able to programmatically express relationships from one element to another is critical for creating user experiences which don’t rely on visual cues - but elements inside a shadow root aren’t available to be referenced from elements in the light DOM. This encapsulation, however, is what allows component authors to create accessible components which can be safely reused in any context, without necessarily requiring any particular dependencies or extra build steps.

In the year or so following, even more heroic attempts were made to square this circle, and finally one seems likely to stick: Reference Target. In this post I’ll explain how this feature works, why I like it, and what the situation is right now with the spec and implementation (thanks in part to Igalia’s NLNet funding).

A quick introduction #

referenceTarget is a new property on shadow root objects which lets you nominate an element in the shadow root’s subtree which should be the target of any attribute-based reference to the shadow host.

As an example, imagine that you have a <custom-input> component, which has an <input> tucked away in its shadow root. This is a pattern which is ubiqutous in custom element libraries, as it allows the custom element to use composition to enhance the behaviour of a built-in element.

<label for="track">Track name:</label>
<custom-input id="track">
  #shadowRoot
  | <input id="inner-input">
</custom-input>

We can set the shadow root’s referenceTarget to allow the <label> to correctly label the inner <input>:

// in the constructor for the custom-input:

const shadowRoot = this.attachShadow({mode: 'open'});
shadowRoot.referenceTarget = 'inner-input';
shadowRoot.innerHTML = '<input id="inner-input">`;

This lets the label refer to the <custom-input> just like it would refer to an <input>; the <custom-input> transparently proxies the reference through to the encapsulated <input>.

In this example, we’ve set the referenceTarget property directly on the ShadowRoot object, but it can also be set declaratively when using the <template> element to create the shadow root:

<label for="track">Track name:</label>
<custom-input id="track">
  <template shadowRootMode="open"
            shadowRootReferenceTarget="inner-input">
    <input id="inner-input">
  </template>
</custom-input>

This works equally well for any attribute which refers to other elements like this - even if you set it via a reflected property like commandForElement:

<button id="settings-trigger">Site settings</button>
<custom-dialog id="settings-dialog">
  #shadowRoot referenceTarget="inner-dialog"
  | <dialog id="inner-dialog">
  |   <button id="close" aria-label="close"
  |           commandFor="inner-dialog"
  |           command="request-close"></button>
  |   <slot></slot>
  | </dialog>
  <fieldset>
    <legend>Colour scheme:</legend>
    <label for="dark">
      <input type="radio" id="dark" name="appearance" value="dark" checked>
      Dark
    </label>
    <!-- TODO: more colour schemes -->
  </fieldset>
</custom-dialog>

// Someone probably has a good reason why they'd do it this way, right?

const settingsButton = document.getElementById('settings-trigger');
settingsButton.command = 'show-modal';
settingsButton.commandForElement = document.getElementById('settings-dialog');

This lets the <custom-dialog> behave exactly like a <dialog> for the purposes of the command and commandForElement properties.

Why I like it #

In my earlier blog post I explained that I was concerned that the Cross-root ARIA delegation and reflection proposals introduced a bottleneck problem. This problem arose because it was only possible to refer to one element per attribute, rather than allowing arbitrary cross-shadow root references.

This proposal absolutely doesn’t solve that problem, but it reframes the overall problem such that I don’t think it matters any more.

The key difference between reference target and the earlier proposals is that reference target is a catch-all for references to the shadow host, rather than requiring each attribute to be forwarded separately. This solves a specific problem, which I alluded to above: how can custom element authors encapsulate the behaviour of a given built-in HTML element while also allowing other elements to refer to the custom element as if it was the built-in element?

I believe this more narrow problem definition accounts for a significant proportion - not all, but many - cases where references need to be able to cross into shadow roots. And it makes the API make much more sense to me - if you’re using the for attribute to refer to a <custom-input>, you’re not meant to need to know that you’re actually referring to an enclosed <input>, you just want the <custom-input> to be labelled. This API makes the enclosed <input> an implementation detail. And since a shadow root can only have one host, it makes sense that it can only have one reference target.

Adjacent, as-yet unsolved problems #

Arbitrary cross-shadow root references #

As mentioned above, one adjacent problem is the problem of element references which do need to refer to specific elements within a shadow root, rather than a stand-in for the shadow host.

The explainer gives two examples of this: aria-activedescendant on a combobox element which needs to refer to an option inside of a shadow root, and ARIA attributes like aria-labelledby, aria-describedby and aria-errormessage which may need a computed name for the component which excludes some parts.

I think we need to be careful about generalising this problem, though. As I describe later in the explainer, I think we might be able to get better solutions by solving more specific problems - as we have with reference target.

If you have another example of where you need to refer to specific elements within a shadow root, you can leave a comment on this issue collecting use cases.

Attribute forwarding #

While reference target allows other elements to refer to the encapsulated element, custom element authors may also want to allow developers using their component to use standard HTML and ARIA attributes on the host element and have those apply to the encapsulated element.

For example, you might like to support popoverTarget on your <custom-button> element:

<custom-button popoverTarget="languages">Language</custom-button>
<custom-menu id="languages" popover>
  <custom-menuitem>Nederlands</custom-menuitem>
  <custom-menuitem>Frysk</custom-menuitem>
  <custom-menuitem>Vlaams</custom-menuitem>
</custom-menu>

There is an issue for the attribute forwarding idea; leave a comment there if this is an idea you’d like to see pursued.

Form association #

Custom elements can be specified as form-associated, but there’s no way to associate an encapsulated form-associated built-in element (such as <input>) with an enclosing <form>.

For example, the <custom-input> above could be nested in a <form> element, but the enclosed <input> wouldn’t be associated with the <form> - instead, you’d have to use setFormValue() on the custom element and copy the value of the <input>.

Spec and implementation status #

In brief: the spec changes seem to be in good shape, Chromium has the most feature-complete implementation and there are significantly less-baked implementations in WebKit and Firefox.

Spec changes #

There are open pull requests on the HTML and DOM specs. Since these PRs are still being reviewed, the concepts and terminology below might change, but this is what we have right now. These changes have already had a few rounds of reviews, thanks to Anne van Kesteren, Olli Pettay and Keith Cirkel.

The DOM change:

• adds the concept of a reference target
• adds the referenceTarget property to the ShadowRoot object.

The HTML change is where the actual effect of the reference target is defined.

Element reference attribute type #

One key change in the HTML spec is the addition of an attribute type for “element reference” attributes. This formalises in HTML what has previously been referred to as an ID reference or IDREF. This term isn’t currently used in HTML, and since the addition of reflected IDL Element attributes, IDs aren’t strictly necessary, either.

Before this change, whenever an attribute in the HTML spec was required to match another element based on its ID, this was written out explicitly where the attribute was defined. For example, the definition of the <label> element’s for attribute currently reads:

The for attribute may be specified to indicate a form control with which the caption is to be associated. If the attribute is specified, the attribute’s value must be the ID of a labelable element in the same tree as the label element. If the attribute is specified and there is an element in the tree whose ID is equal to the value of the for attribute, and the first such element in tree order is a labelable element, then that element is the label element’s labeled control.

Since reference target affects how this type of reference works, and is intended to apply for every attribute which refers to another element, it was simpler to have one central definition.

Reference target resolution #

For a reference target to actually do something, we need to define what effect it has. This is defined, quite straightforwardly, in the steps to resolve the reference target:

1. If element is not a shadow host, or element’s shadow root’s reference target is null, then return element.
2. Let referenceTargetValue be the value of element’s shadow root’s reference target.
3. Let candidate be the first element in element’s shadow root whose ID matches referenceTargetValue.
4. If no such element exists, return null.
5. Return the result of resolving the reference target on candidate.

These steps are recursive: if a shadow root’s reference target has its own shadow root, and that shadow root has a reference target, we keep descending into the nested shadow root.

One slightly subtle design choice here is that if a shadow root has a reference target which doesn’t refer to any element - for example, an empty string, or a value which doesn’t match the ID of any element in its subtree - the resolved reference target is null, not the shadow host.

For example, if you tried to use popoverTarget to refer to a shadow host which had a popover attribute, but had an invalid reference target on its shadow root, the popoverTarget attribute won’t actually target anything:

<button id="more-actions" popoverTarget="actions-popover" aria-label="more actions">…</button>

<!-- Even though this has a popover attribute, the button won't toggle it! -->
<custom-popover id="actions-popover" popover>
  <template shadowRootMode="open"
            shadowRootReferenceTarget="0xDEADBEEF">
    <div id="help-im-trapped-in-a-shadow-root" popover>
      <slot></slot>
    </div>
  </template>
</custom-dialog>

Resolved and unresolved attr target elements #

Like many spec concepts, this one is a real mouthful.

This lets us be very clear about whether reference target resolution has happened when we’re talking about what element an attribute refers to.

If we’re reflecting an attribute to its IDL counterpart, we now use the unresolved attr target element. For example, if we had the DOM defined in the previous example, and we wanted to get the popoverTargetElement for the "settings-trigger" button:

const moreActions = document.getElementById("more-actions");

// This will log the <custom-popover> element (!)
console.log(moreActions.popoverTargetElement);

(In spec terms: the <custom-popover> element is the unresolved popoverTarget target element for the <button>.)

This might also be a bit surprising; we spent quite a bit of time going back and forth on this, since we thought developers might want to know that the popoverTarget isn’t actually targeting anything. However, using the unresolved target lets us have a very close parallel between setting and getting the popoverTargetElement, as well as preserving the shadow root’s encapsulation.

The resolved attr target element, meanwhile, is what will be used when actually doing something with the attribute - such as triggering a popover, or computing a label’s labeled control, or determining an element’s accessible description.

In the above example, the resolved popoverTarget target element for the button is null. And, going back to the examples we’ve seen earlier:

• the resolved commandFor target element for the Settings button is the inner <dialog> - clicking the button will open the <dialog>.
• the resolved for target element for the <label> is the inner <input> - clicking the label will focus the input, and the input’s computed accessible name will be “Track name”.

“Referring to” #

For convenience, we define the concept of an attribute “referring to” an element:

A single-element reference attribute attr on an element X refers to an element Y as its target if Y is the resolved attr target element for X.

So, for example, the commandFor attribute on the Settings button refers to the inner <dialog> element.

Sets of element references #

All of the above used single element references as examples, but there are attributes which can refer to more than one element. For example, almost all of the ARIA attributes which refer to other elements refer to multiple elements in an ordered list - one such is aria-errormessage, which can refer to one or more elements which should be exposed as specifically as an error message for an element which is marked as invalid.

We define a set of element references attribute type, as well as a couple of subtypes which impose constraints such as ordering or uniqueness, as well as what it means for one of these attributes to refer to another element, and how to get the resolved and unresolved attr target elements for these attributes.

While these are slightly more complex than the single element versions, they follow the same basic logic. The only marginally significant difference is that since they produce lists of elements, if a shadow root’s reference target is invalid, no element is added to the list for that unresolved attr target, instead of returning null.

Using these concepts in the rest of the spec #

Now that we’ve defined these spec concepts, we have to update each place in the spec where we previously used the “whose ID is equal to the value of the blahblah attribute” wording.

Returning to our good friend popoverTarget, we can see a relatively straightforward example.

The definition of the popoverTarget attribute now reads:

If specified, the popovertarget attribute value must be a valid single-element reference attribute referring to an element with the popover attribute.

And now, get the popover target element determines popoverElement like this:

4. Let popoverElement be node’s resolved popovertarget target element.

<label> association is a bit more complex, since we wanted descendants of the <label> to be correctly labelled when using reference target:

To determine a label element label’s labeled control, run these steps:

1. If label’s for attribute is specified, then:
   1. If the resolved for target element is not null, and the resolved for target element is a labelable element, return that element.
   2. Otherwise, return null.
2. For each descendant descendant of label in tree order:
   1. Let candidate be the result of resolving the reference target on descendant.
   2. If candidate is a labelable element, return candidate.
3. Return null.

There is also a PR open on the ARIA spec to introduce this terminology there.

Implementation status #

Chromium has the most complete implementation, though it may not quite be up to date with the latest spec changes. Any developers wanting to try it out should get the latest build of Chrome or Edge and flip on the Experimental Web Platform Features flag. If you do try it out, I’d love to hear any feedback you might have!

WebKit and Firefox (tracking bug) each have a prototype implementation, available behind respective feature flags (ShadowRootReferenceTargetEnabled for WebKit and dom.shadowdom.referenceTarget.enabled for Firefox), which should pass at least most of the existing WPT tests - however, the WPT tests are insufficient to test all of the functionality, and the functionality which couldn’t be tested via WPTs hasn’t been implemented yet in these engines. The Chromium implementation included adding many Chromium-specific tests for the behaviour which can’t be tested via WPTs, as well as implementing that behaviour.

Currently, WPT tests can only test the computed accessible name and computed accessible role for an element, as well as testing DOM methods and user actions like clicking. However, reference target impacts the accessibility tree in many ways - not only via ARIA attributes, but via attributes like popoverTarget being exposed in the accessibility tree as an accessible relation.

And, importantly, changes to the accessibility tree can require certain notifications to be fired to assistive technology APIs - and reference target introduces several new ways to change the accessibility tree. Adding, changing, or removing a shadow root’s referenceTarget may cause changes in the resolved target elements for attributes, causing accessibility tree changes and potentially requiring notifications. Likewise, inserting an element with an ID which matches a shadow root’s referenceTarget could also cause a shadow host’s resolved reference target to change, also potentially causing the accessibility tree to change.

There are two complementary projects currently underway which will allow us to write much richer tests for accessibility tree functionality in browsers:

• support for writing WPT tests which directly test what browsers expose to accessibility APIs
• support for an “accessible properties” API.

Once we can write WPT tests which actually test the full spectrum of expected behaviour for reference target, we’ll be able to actually make it an official interop focus area.

The prototype implementation work in WebKit and Firefox, as well as the spec work done by Igalia, was generously funded by a grant from NLNet Foundation, while the implementation work in Chromium and much of the remainder of the spec work was done by Microsoft engineers on the Edge team.

Update on what happened in WebKit in the week from January 19 to January 26.

The main event this week has been the creation of the branch for the upcoming stable series, accompanied by the first release candidate before 2.52.0. But there's more: the WPE port gains hyphenation support and the ability to notify of graphics buffer changes; both ports get graphics fixes and a couple of new Web features, and WPE-Android also gets a new stable release.

Cross-Port 🐱

Graphics 🖼️

WPE WebKit 📟

WPE Platform API 🧩

Releases 📦️

Now that 2025 is over, it’s time to look back and feel proud of the path we’ve walked. Last year has been really exciting in terms of contributions to GStreamer and WebKit for the Igalia Multimedia team.

With more than 459 contributions along the year, we’ve been one of the top contributors to the GStreamer project, in areas like Vulkan Video, GstValidate, VA, GStreamer Editing Services, WebRTC or H.266 support.

In Vulkan Video we’ve worked on the VP9 video decoder, and cooperated with other contributors to push the AV1 decoder as well. There’s now an H.264 base class for video encoding that is designed to support general hardware-accelerated processing.

GStreaming Editing Services, the framework to build video editing applications, has gained time remapping support, which now allows to include fast/slow motion effects in the videos. Video transformations (scaling, cropping, rounded corners, etc) are now hardware-accelerated thanks to the addition of new Skia-based GStreamer elements and integration with OpenGL. Buffer pool tuning and pipeline improvements have helped to optimize memory usage and performance, enabling the edition of 4K video at 60 frames per second. Much of this work to improve and ensure quality in GStreamer Editing Services has also brought improvements in the GstValidate testing framework, which will be useful for other parts of GStreamer.

Regarding H.266 (VVC), full playback support (with decoders such as vvdec and avdec_h266, demuxers and muxers for Matroska, MP4 and TS, and parsers for the vvc1 and vvi1 formats) is now available in GStreamer 1.26 thanks to Igalia’s work. This allows user applications such as the WebKitGTK web browser to leverage the hardware accelerated decoding provided by VAAPI to play H.266 video using GStreamer.

Igalia has also been one of the top contributors to GStreamer Rust, with 43 contributions. Most of the commits there have been related to Vulkan Video.

In addition to GStreamer, the team also has a strong presence in WebKit, where we leverage our GStreamer knowledge to implement many features of the web engine related to multimedia. From the 1739 contributions to the WebKit project done last year by Igalia, the Multimedia team has made 323 of them. Nearly one third of those have been related to generic multimedia playback, and the rest have been on areas such as WebRTC, MediaStream, MSE, WebAudio, a new Quirks system to provide adaptations for specific hardware multimedia platforms at runtime, WebCodecs or MediaRecorder.

We’re happy about what we’ve achieved along the year and look forward to maintaining this success and bringing even more exciting features and contributions in 2026.

Welcome back to the second post in this series looking at how we can improve the performance of RISC-V code from LLVM.

Previously in part 1 we looked at how we can use LNT to analyze performance gaps, then identified and fixed a missed fmsub.d opportunity during instruction selection, giving a modest 1.77% speedup on a SPEC CPU 2017 benchmark.

In this post we’ll be improving another SPEC benchmark by 7% by teaching the loop vectorizer to make smarter cost modelling decisions. It involves a relatively non-trivial analysis, but thanks to LLVM’s modular infrastructure we can do it in just a handful of lines of code. Let’s get started.

Analysis

Just like last time, all fruitful performance work begins by analysing some workloads. In the last post we had already run some comparisons of SPEC CPU 2017 benchmarks on LNT, so we can return to those results and pick another benchmark to focus on. Here’s one that’s 12% slower than GCC:

531.deepsjeng_r is a chess engine that tied first in the World Computer Chess Championships back in 2009. It consists of a lot bitwise arithmetic and complex loops, since the state of the game is encoded in 64 element arrays: one element for each square on the board. Unlike 508.namd_r from last time, there’s no floating point arithmetic.

Drilling into the profile and its list of functions, right off the bat we can see that one function is much slower on LLVM. On GCC qsearch(state_t*, int, int, int, int) makes up 9.1% of the overall cycles, but on LLVM it’s 16.1%. And if we click in on the function and view the cumulative total of cycles spent in user mode, Clang takes 74.6 billion cycles to do what takes GCC only 37.7 billion cycles.

So there’s probably something we can improve upon here, but it’s not immediately obvious from staring at the disassembly. qsearch is a pretty big function with a couple hundred instructions, so switching to the CFG view gives us a better overview.

On LLVM’s side we see the offending loop that’s consuming so many cycles: It’s long, vectorized, and completely if-predicated: there’s no control flow inside the loop itself. This is typical of a loop that’s been auto-vectorized by the loop vectorized. If you look at the load and store instructions you can see that they are masked with the v0.t operand, stemming from the original control flow that was flattened.

But on the GCC side there’s no equivalent vectorized loop. The loop is in there somewhere, but all the loops are still in their original scalar form with the control flow intact. And if we look at the edges coming from the loop headers, we can see that most of the time it visits one or two basic blocks and then branches back up to the header. Most of the blocks in the loop are completely cold.

Unfortunately the sources for deepsjeng aren’t open source so we can’t share them in this post, but the very rough structure of the loop is something like this:

for (i = 0; i < N; i++) {
    if (foo[i] == a) {
        if (bar[i] == b) {
            if (baz[i] == c) {
                qux[i] = 123;
                // lots of work here...
            }
        }
    }
}

For any given iteration, it’s statistically unlikely that we enter the first if statement. It’s even more unlikely that the second if’s condition is also true. And even more so for the third nested if where we eventually have lots of work to compute.

In a scalar loop this doesn’t matter because if an if statement’s condition is false, then we don’t execute the code inside it. We just branch back to the start of the loop. But with a vectorized loop, we execute every single instruction regardless of the condition.

This is the core of the performance gap that we’re seeing versus GCC: Given that the majority of the work in this loop is so deeply nested in the control flow, it would have been better to have not vectorized it given that we need to if-convert it.

Cost modelling

One of the hardest problems when making an optimizing compiler is to know when an optimization is profitable. Some optimizations are a double edged sword that can harm performance just as much as they can improve it (if not more), and loop vectorization falls squarely into this category. So rather than blindly applying optimizations at any given opportunity, LLVM has detailed cost models for each target to try and estimate how expensive or cheap a certain sequence of instructions is, which it can then use to evaluate whether or not a transform will be a net positive.

It’s hard to overstate the amount of effort in LLVM spent fine tuning these cost models, applying various heuristics and approximations to make sure different optimizations don’t shoot themselves in the foot. In fact there are some optimizations like loop distribute that are in-tree but disabled by default due to the difficulty in getting the cost model right.

So naturally, we would expect that the loop vectorizer already has a sophisticated solution for the problem we’re seeing in our analysis: Given any predicated block that’s if-converted during vectorization, we would expect the scalar cost for that block to be made slightly cheaper because the scalar block may not always be executed. And the less likely it is to be executed, the cheaper it should be — the most deeply nested if block should be discounted more than the outermost if block.

So how does the loop vectorizer handle this?

/// A helper function that returns how much we should divide the cost of a
/// predicated block by. Typically this is the reciprocal of the block
/// probability, i.e. if we return X we are assuming the predicated block will
/// execute once for every X iterations of the loop header so the block should
/// only contribute 1/X of its cost to the total cost calculation, but when
/// optimizing for code size it will just be 1 as code size costs don't depend
/// on execution probabilities.
///
/// TODO: We should use actual block probability here, if available. Currently,
///       we always assume predicated blocks have a 50% chance of executing.
inline unsigned
getPredBlockCostDivisor(TargetTransformInfo::TargetCostKind CostKind) {
  return CostKind == TTI::TCK_CodeSize ? 1 : 2;
}

We’ve come across a load bearing TODO here. Either the block is executed or its not, so it’s a fifty/fifty chance.

On its own this hardcoded probability doesn’t seem like an unreasonable guess. But whilst 50% may be an accurate estimate as to whether or not a branch will be taken, it’s an inaccurate estimate as to whether or not a block will be executed. Assuming that a branch has a 1/2 chance of being taken, the most deeply nested block in our example ends up having a 1/2 * 1/2 * 1/2 = 1/8 chance of being executed.

for (i = 0; i < N; i++) {
    if (foo[i] == a) {
        // 1/2 chance of being executed
        if (bar[i] == b) {
            // 1/4 chance of being executed
            if (baz[i] == c) {
                // 1/8 chance of being executed
                // ...
            }
        }
    }
}

The fix to get the loop vectorizer to not unprofitably vectorize this loop will be to teach getPredBlockCostDivisor to take into account control flow between blocks.

It’s worth mentioning the fact that a hardcoded constant managed to work well enough up until this point is the sign of an good trade off. 1% of the effort for 90% of the benefit. A patch can go off the rails very easily by trying to implement too much in one go, so deferring the more complex cost modelling here till later was an astute choice. Incremental development is key to making progress upstream.

VPlan cost modeling

To get a better picture of how the loop vectorizer is calculating the cost for each possible loop, lets start with a simplified LLVM IR reproducer:

; for (int i = 0; i < 1024; i++)
;   if (c0)
;     if (c1)
;       p1[p0[i]] = 0; // extra work to increase the cost in the predicated block

define void @nested(ptr noalias %p0, ptr noalias %p1, i1 %c0, i1 %c1) {
entry:
  br label %loop

loop:
  %iv = phi i32 [ 0, %entry ], [ %iv.next, %latch ]
  br i1 %c0, label %then.0, label %latch

then.0:
  br i1 %c1, label %then.1, label %latch

then.1:
  %gep0 = getelementptr i32, ptr %p0, i32 %iv
  %x = load i32, ptr %gep0
  %gep1 = getelementptr i32, ptr %p1, i32 %x
  store i32 0, ptr %gep1
  br label %latch

latch:
  %iv.next = add i32 %iv, 1
  %done = icmp eq i32 %iv.next, 1024
  br i1 %done, label %exit, label %loop

exit:
  ret void
}

We can run opt -p loop-vectorize -debug on this example to see how the loop vectorizer decides if it’s profitable to vectorize the loop or not:

$ opt -p loop-vectorize -mtriple riscv64 -mattr=+v nested.ll -disable-output -debug
...
LV: Found an estimated cost of 0 for VF 1 For instruction:   %iv = phi i32 [ 0, %entry ], [ %iv.next, %latch ]
LV: Found an estimated cost of 0 for VF 1 For instruction:   br i1 %c0, label %then.0, label %latch
LV: Found an estimated cost of 0 for VF 1 For instruction:   br i1 %c1, label %then.1, label %latch
LV: Found an estimated cost of 0 for VF 1 For instruction:   %gep0 = getelementptr i32, ptr %p0, i32 %iv
LV: Found an estimated cost of 1 for VF 1 For instruction:   %x = load i32, ptr %gep0, align 4
LV: Found an estimated cost of 0 for VF 1 For instruction:   %gep1 = getelementptr i32, ptr %p1, i32 %x
LV: Found an estimated cost of 1 for VF 1 For instruction:   store i32 0, ptr %gep1, align 4
LV: Found an estimated cost of 0 for VF 1 For instruction:   br label %latch
LV: Found an estimated cost of 1 for VF 1 For instruction:   %iv.next = add i32 %iv, 1
LV: Found an estimated cost of 1 for VF 1 For instruction:   %done = icmp eq i32 %iv.next, 1024
LV: Found an estimated cost of 0 for VF 1 For instruction:   br i1 %done, label %exit, label %loop
LV: Scalar loop costs: 3.
...
Cost of 1 for VF vscale x 4: induction instruction   %iv.next = add i32 %iv, 1
Cost of 0 for VF vscale x 4: induction instruction   %iv = phi i32 [ 0, %entry ], [ %iv.next, %latch ]
Cost of 1 for VF vscale x 4: exit condition instruction   %done = icmp eq i32 %iv.next, 1024
Cost of 0 for VF vscale x 4: EMIT vp<%4> = CANONICAL-INDUCTION ir<0>, vp<%index.next>
Cost of 0 for VF vscale x 4: EXPLICIT-VECTOR-LENGTH-BASED-IV-PHI vp<%5> = phi ir<0>, vp<%index.evl.next>
Cost of 0 for VF vscale x 4: EMIT-SCALAR vp<%avl> = phi [ ir<1024>, vector.ph ], [ vp<%avl.next>, vector.body ]
Cost of 1 for VF vscale x 4: EMIT-SCALAR vp<%6> = EXPLICIT-VECTOR-LENGTH vp<%avl>
Cost of 0 for VF vscale x 4: vp<%7> = SCALAR-STEPS vp<%5>, ir<1>, vp<%6>
Cost of 0 for VF vscale x 4: CLONE ir<%gep0> = getelementptr ir<%p0>, vp<%7>
Cost of 0 for VF vscale x 4: vp<%8> = vector-pointer ir<%gep0>
Cost of 2 for VF vscale x 4: WIDEN ir<%x> = vp.load vp<%8>, vp<%6>, vp<%3>
Cost of 0 for VF vscale x 4: WIDEN-GEP Inv[Var] ir<%gep1> = getelementptr ir<%p1>, ir<%x>
Cost of 12 for VF vscale x 4: WIDEN vp.store ir<%gep1>, ir<0>, vp<%6>, vp<%3>
Cost of 0 for VF vscale x 4: EMIT vp<%index.evl.next> = add nuw vp<%6>, vp<%5>
Cost of 0 for VF vscale x 4: EMIT vp<%avl.next> = sub nuw vp<%avl>, vp<%6>
Cost of 0 for VF vscale x 4: EMIT vp<%index.next> = add nuw vp<%4>, vp<%0>
Cost of 0 for VF vscale x 4: EMIT branch-on-count vp<%index.next>, vp<%1>
Cost of 0 for VF vscale x 4: vector loop backedge
Cost of 0 for VF vscale x 4: EMIT-SCALAR vp<%bc.resume.val> = phi [ ir<0>, ir-bb<entry> ]
Cost of 0 for VF vscale x 4: IR   %iv = phi i32 [ 0, %entry ], [ %iv.next, %latch ] (extra operand: vp<%bc.resume.val> from scalar.ph)
Cost of 0 for VF vscale x 4: EMIT vp<%3> = logical-and ir<%c0>, ir<%c1>
Cost for VF vscale x 4: 17 (Estimated cost per lane: 2.1)
...
LV: Selecting VF: vscale x 4.
LV: Minimum required TC for runtime checks to be profitable:0
LV: Interleaving is not beneficial.
LV: Found a vectorizable loop (vscale x 4) in nested.ll
LV: Vectorizing: innermost loop.
LEV: Unable to vectorize epilogue because no epilogue is allowed.
LV: Loop does not require scalar epilogue
LV: Loop does not require scalar epilogue
Executing best plan with VF=vscale x 4, UF=1

First we see it work out the cost of the original scalar loop, or as the vectorizer sees it, the loop with a vectorization factor (VF) of 1. It goes through each instruction calling into TargetTransformInfo, and arrives at a total scalar cost of 3. You might have noticed though, if you went through and manually summed up the individual instruction costs you would have gotten a total cost of 4. However the load and store instructions belong to the predicated then.1 block, so they have their cost divided by 2 from getPredBlockCostDivisor.

For the vectorized loop, the loop vectorizer uses VPlan to cost the one plan for a range of different VFs¹. VPlan is an IR specific to the loop vectorizer to help represent various vectorization strategies, which is why you see all the EMIT and WIDEN “recipes” in the output. It calculates a total cost for the loop and divides it by the estimated number of lanes — we’re working with scalable vectors on RISC-V so the target needs to make an estimate of what vscale is — and arrives at 2.1 per lane. There’s no predication discount applied here because it’s a vectorized loop. 2.1 is cheaper than 3, so it ultimately picks the vectorized loop.

BlockFrequencyInfo

Computing an accurate probability that a given block will be executed is a non-trivial task, but thankfully LLVM already has an analysis we can use for this called BlockFrequencyInfo.

BlockFrequencyInfo computes how often a block can be expected to execute relative to other blocks in a function. It in turn uses another analysis called BranchProbabilityInfo to work out how likely a branch to a specific block is going to be taken. And because BranchProbabilityInfo uses profiling information when available, it can give you much more accurate block frequencies when compiling with PGO. Otherwise it will fall back to guessing the probability of a branch being taken, which is just 50/50 a lot of the time, but sometimes influenced by interesting heuristics too: like the probability of icmp eq i32 %x, 0 is 0.375 instead of 0.5, and floats have a near zero chance of being NaN.

Plugging BlockFrequencyInfo into the loop vectorizer is straightforward, all we need to do is tell the pass manager that we want to access BlockFrequencyInfo from LoopVectorizePass:

PreservedAnalyses LoopVectorizePass::run(Function &F,
                                         FunctionAnalysisManager &AM) {
   ...
   BFI = &AM.getResult<BlockFrequencyAnalysis>(F);
   ...
}

(BlockFrequencyAnalysis is the pass that computes the analysis result BlockFrequencyInfo, if you’re wondering why the names are different)

Then we can use it to lookup the relative frequencies of whatever block and work out the probability of it being executed in the loop:

uint64_t LoopVectorizationCostModel::getPredBlockCostDivisor(
    TargetTransformInfo::TargetCostKind CostKind, const BasicBlock *BB) {
  if (CostKind == TTI::TCK_CodeSize)
    return 1;

  uint64_t HeaderFreq =
      BFI->getBlockFreq(TheLoop->getHeader()).getFrequency();
  uint64_t BBFreq = BFI->getBlockFreq(BB).getFrequency();
  return HeaderFreq / BBFreq;
}

The frequencies returned from BlockFrequencyInfo are relative to the the entry block of a function. So if a block has a frequency of 50 and the entry block has a frequency of 100, then you can expect that block to execute 50 times for every 100 times the entry block is executed.

You can use this to work out probabilities of a block being taken in a function, so in this example that block has a 50/100 = 50% chance of being executed every time the function is executed. However this only works in the case that the CFG has no loops: otherwise a block may be executed more times than the entry block and we’d end up with probabilities greater than 100%.

If we want to calculate the probability of a block being executed inside a loop though, that’s fine since the loop vectorizer currently only vectorizes inner-most loops², i.e. loops that contain no other loops.

We can consider the frequencies of each block in the loop relative to the frequency of the header block. To give a brief loop terminology recap, the header is the first block inside the loop body which dominates all other blocks in the loop, and is the destination of all backedges. So the header is guaranteed to have a frequency greater than or equal to any other block in the loop — this invariant is important as we’ll see later.

Then to calculate the probability of a block in a loop being executed, we divide the block frequency by the header frequency. To work out how much we should divide the cost of the scalar block by, we return the inverse of that.

Trying out this change on our sample loop, first we’ll see the debug output from BlockFrequencyInfo as it’s computed:

$ opt -p loop-vectorize -mtriple riscv64 -mattr=+v nested.ll -disable-output -debug
...
block-frequency-info: nested
 - entry: float = 1.0, int = 562949953421312
 - loop: float = 32.0, int = 18014398509481984
 - then.0: float = 16.0, int = 9007199254740992
 - then.1: float = 8.0, int = 4503599627370496
 - latch: float = 32.0, int = 18014398509481984
 - exit: float = 1.0, int = 562949953421312

loop is the header block and then.1 is the nested if block, and with BlockFrequencyInfo’s frequency we get a probability of 8/32 = 0.25. So we would expect then.1’s scalar cost to be divided by 4:

...
LV: Found an estimated cost of 0 for VF 1 For instruction:   %iv = phi i32 [ 0, %entry ], [ %iv.next, %latch ]
LV: Found an estimated cost of 0 for VF 1 For instruction:   br i1 %c0, label %then.0, label %latch
LV: Found an estimated cost of 0 for VF 1 For instruction:   br i1 %c1, label %then.1, label %latch
LV: Found an estimated cost of 0 for VF 1 For instruction:   %gep0 = getelementptr i32, ptr %p0, i32 %iv
LV: Found an estimated cost of 1 for VF 1 For instruction:   %x = load i32, ptr %gep0, align 4
LV: Found an estimated cost of 0 for VF 1 For instruction:   %gep1 = getelementptr i32, ptr %p1, i32 %x
LV: Found an estimated cost of 1 for VF 1 For instruction:   store i32 0, ptr %gep1, align 4
LV: Found an estimated cost of 0 for VF 1 For instruction:   br label %latch
LV: Found an estimated cost of 1 for VF 1 For instruction:   %iv.next = add i32 %iv, 1
LV: Found an estimated cost of 1 for VF 1 For instruction:   %done = icmp eq i32 %iv.next, 1024
LV: Found an estimated cost of 0 for VF 1 For instruction:   br i1 %done, label %exit, label %loop
LV: Scalar loop costs: 2.
...
Cost for VF vscale x 4: 17 (Estimated cost per lane: 2.1)
...
LV: Selecting VF: 1.
LV: Vectorization is possible but not beneficial.

then.1s scalar cost is now 2/4 = 0, so the total cost of the scalar loop is now 2 and the loop vectorizer no longer decides to vectorize. If we try this out on 538.deepsjeng_r, we can see that it no longer vectorizes that loop in qsearch either. Success!

Running it again on LNT showed a ~7% speedup in execution time. Not just as fast as GCC yet, but a welcome improvement for only a handful of lines of code.

Upstreaming

Now that we know the fix we want to land, we can start to think about how we want to upstream this into LLVM.

If we run llvm-lit --update-tests llvm/test/Transforms/LoopVectorize, we actually get quite a few unexpected test changes. One of the side effects of using BlockFrequencyInfo is that tail folded loops no longer discount the scalar loop if it wasn’t predicated to begin with. A tail folded loop is a loop where the scalar epilogue is folded into the vector loop itself by predicating the vector operations:

// non-tail folded loop:
// process as many VF sized vectors that fit in n
for (int i = 0; i < n - (n % VF); i += VF)
  x[i..i+VF] = y[i..i+VF];
// process the remaining n % VF scalar elements
for (int i = n - (n % VF); i < n; i++)
  x[i] = y[i];

// tail folded loop:
for (int i = 0; i < n; i += VF)
  x[i..i+VF] = y[i..i+VF] mask=[i<n, i+1<n, ..., i+VF-1<n];

However because this block is technically predicated due to the mask on the vector instructions, the loop vectorizer applied getPredBlockCostDivisor to the scalar loop cost even if the original scalar loop had no control flow in its body. BlockFrequencyInfo here can detect that if the block had no control flow, its probability of being executed is 1 and so the scalar loop cost isn’t made cheaper than it needs to be. I split off and landed this change separately, since it makes the test changes easier to review.

Now that the remaining changes in llvm/test/Transforms/LoopVectorize looked more contained, I was almost ready to open a pull request. I just wanted to quickly kick the tyres on llvm-test-suite with a few other targets, since this wasn’t a RISC-V specific change. The plan was to quickly collect some stats on how many loops were vectorized, check for any anomalies when compared to beforehand, and then be on our way:

$ cd llvm-test-suite
$ ninja -C build
...
[222/7278] Building C object External/...nchspec/CPU/500.perlbench_r/src/pp.c.o
FAILED: External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.c.o 
/root/llvm-test-suite/build.x86_64-ReleaseLTO-a/tools/timeit --summary External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.c.o.time /root/llvm-project/build/bin/clang -DDOUBLE_SLASHES_SPECIAL=0 -DNDEBUG -DPERL_CORE -DSPEC -DSPEC_AUTO_BYTEORDER=0x12345678 -DSPEC_AUTO_SUPPRESS_OPENMP -DSPEC_CPU -DSPEC_LINUX -DSPEC_LINUX_X64 -DSPEC_LP64 -DSPEC_SUPPRESS_OPENMP -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/root/cpu2017/benchspec/CPU/500.perlbench_r/src -I/root/cpu2017/benchspec/CPU/500.perlbench_r/src/dist/IO -I/root/cpu2017/benchspec/CPU/500.perlbench_r/src/cpan/Time-HiRes -I/root/cpu2017/benchspec/CPU/500.perlbench_r/src/cpan/HTML-Parser -I/root/cpu2017/benchspec/CPU/500.perlbench_r/src/ext/re -I/root/cpu2017/benchspec/CPU/500.perlbench_r/src/specrand -march=x86-64-v3 -save-temps=obj     -O3 -fomit-frame-pointer -flto -DNDEBUG   -w -Werror=date-time -save-stats=obj -save-stats=obj -fno-strict-aliasing -MD -MT External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.c.o -MF External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.c.o.d -o External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.c.o -c /root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.c
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /root/llvm-project/build/bin/clang-19 -cc1 -triple x86_64-unknown-linux-gnu -O3 -emit-llvm-bc -flto=full -flto-unit -save-temps=obj -disable-free -clear-ast-before-backend -main-file-name pp.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64-v3 -debugger-tuning=gdb -fdebug-compilation-dir=/root/llvm-test-suite/build.x86_64-ReleaseLTO-a -fcoverage-compilation-dir=/root/llvm-test-suite/build.x86_64-ReleaseLTO-a -resource-dir /root/llvm-project/build/lib/clang/23 -Werror=date-time -w -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -vectorize-loops -vectorize-slp -stats-file=External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.stats -faddrsig -fdwarf2-cfi-asm -o External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.c.o -x ir External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.bc
1.      Optimizer
2.      Running pass "function<eager-inv>(float2int,lower-constant-intrinsics,chr,loop(loop-rotate<header-duplication;prepare-for-lto>,loop-deletion),loop-distribute,inject-tli-mappings,loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>,infer-alignment,loop-load-elim,instcombine<max-iterations=1;no-verify-fixpoint>,simplifycfg<bonus-inst-threshold=1;forward-switch-cond;switch-range-to-icmp;switch-to-arithmetic;switch-to-lookup;no-keep-loops;hoist-common-insts;no-hoist-loads-stores-with-cond-faulting;sink-common-insts;speculate-blocks;simplify-cond-branch;no-speculate-unpredictables>,slp-vectorizer,vector-combine,instcombine<max-iterations=1;no-verify-fixpoint>,loop-unroll<O3>,transform-warning,sroa<preserve-cfg>,infer-alignment,instcombine<max-iterations=1;no-verify-fixpoint>,loop-mssa(licm<allowspeculation>),alignment-from-assumptions,loop-sink,instsimplify,div-rem-pairs,tailcallelim,simplifycfg<bonus-inst-threshold=1;no-forward-switch-cond;switch-range-to-icmp;switch-to-arithmetic;no-switch-to-lookup;keep-loops;no-hoist-common-insts;hoist-loads-stores-with-cond-faulting;no-sink-common-insts;speculate-blocks;simplify-cond-branch;speculate-unpredictables>)" on module "External/SPEC/CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/root/cpu2017/benchspec/CPU/500.perlbench_r/src/pp.bc"
3.      Running pass "loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>" on function "Perl_pp_coreargs"
 #0 0x0000556ff93ab158 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/root/llvm-project/build/bin/clang-19+0x2d5c158)
 #1 0x0000556ff93a8835 llvm::sys::RunSignalHandlers() (/root/llvm-project/build/bin/clang-19+0x2d59835)
 #2 0x0000556ff93abf01 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #3 0x00007f305ce49df0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0)
 #4 0x0000556ffaa0dbfb llvm::LoopVectorizationCostModel::expectedCost(llvm::ElementCount) (/root/llvm-project/build/bin/clang-19+0x43bebfb)
 #5 0x0000556ffaa22a0d llvm::LoopVectorizationPlanner::computeBestVF() (/root/llvm-project/build/bin/clang-19+0x43d3a0d)
 #6 0x0000556ffaa36f3b llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/root/llvm-project/build/bin/clang-19+0x43e7f3b)
 #7 0x0000556ffaa413eb llvm::LoopVectorizePass::runImpl(llvm::Function&) (/root/llvm-project/build/bin/clang-19+0x43f23eb)
 ...
...

A crash when building for X86. No assertion message, but a backtrace that points to the loop vectorizer cost model. Unfortunately this did not turn out to be simple to debug and instead turned into a whole other ordeal, so I’ll leave the details of that rabbit hole to the next post. But in the meantime, here are some hints if you want to guess what went wrong:

• The crash stems from a SIGFPE signal
• It only occurs when building on X86. Building on AArch64 is unaffected, even when cross-compiling to X86
• It only occurs with LTO

Hopefully this also gives a bit of insight into the type of upstream work that we carry out at Igalia. If you have an LLVM or RISC-V project that we could help with, feel free to reach out.

In June 2025, I joined the Igalia Coding Experience program. My role was to implement the TC39 proposal Legacy RegExp Features in SpiderMonkey, the JavaScript engine in Mozilla Firefox. This wasn't my first proposal implementation. I'd already implemented the Error.isError and Iterator.range TC39 proposals in SpiderMonkey, but implementing the Legacy RegExp Features proposal involved delving deeper into the Mozilla codebase, and new challenges for me.

To begin with, I created an implementation plan with a timeline of how I was going to approach the proposal. Additionally, I added links to the codebase where I thought I was going to make changes as per the specification, which helped me have a clear starting point and path for integrating the feature. It also meant I could get feedback from SpiderMonkey developers before actually beginning the implementation.

The Legacy RegExp features proposal disables legacy static properties and RegExp.prototype.compile for instances of proper subclasses of RegExp as well as for cross-realm regexps.

The following operations are modified in SpiderMonkey:

RegExp.prototype.compile(pattern, flags) #

This method reinitializes an existing RegExp object with a new pattern and/or flags. It modifies the RegExp object in place rather than creating a new one.

Modification: The proposal modifies RegExp.prototype.compile to throw errors for objects that are not direct instances of the RegExp as well as for cross-realm mismatches. The compile() method initializes a RegExp object similar to the way a RegExp literal is created, bypassing any preprocessing of the pattern that might be done by a RegExp subclass's constructor, and potentially breaking a subclass's custom "exec" method. Thus, compile is disallowed for subclasses. It is now forbidden for a RegExp compile method to be applied to a RegExp object belonging to a different realm, as this would typically result in static properties of the incorrect realm being updated.

Example of newly restricted behaviour:

(base) $ ./mach run
 0:00.29 /Users/default/firefox/obj-aarch64-apple-darwin25.2.0/dist/bin/js
js> let g = newGlobal();
js> let re = g.RegExp("x");
js> RegExp.prototype.compile.call(re);
typein:3:26 TypeError: RegExp operation not permitted on object from different realm
Stack:
  @typein:3:26
js>

To explain each line of the JavaScript code in detail:

• let g = newGlobal() creates a new JavaScript global object in SpiderMonkey, similar to opening a new window in a browser. Each global object has its own realm. A realm is a JavaScript execution context that contains its own set of global objects and built-in functions. Every object in SpiderMonkey has a realm pointer which identifies which realm it belongs to.

• let re = g.RegExp(“x”) creates a new RegExp object from g's realm, with a distinct instance of the RegExp constructor. Although the object behaves like one created from RegExp("x"), the two are not wholly compatible with one another.

• RegExp.prototype.compile.call(re) invokes the compile() method with the regexp initialized above for a realm returned from newGlobal(). Per step 5 of the modified RegExp.prototype.compile() algorithm in the proposal, this results in a TypeError exception being thrown.

Initially, I added my changes in regexp_compile_impl(), but when testing with ./mach try auto, the feature failed test262 cross-realm tests when run with the ion eager and --more-compartments flag. Debug output showed that when invoking the RegExp.prototype.compile(re) both the receiver or (this`) of the RegExp.prototype.compile() method, and the RegExp object were in the same realm while they weren’t. In other words, the cross-realm check was passing, when it should have been failing, according to the test expectations.

By the time execution reached regexp_compile(), the CallNonGenericMethod<IsRegExpObject, regexp_compile_impl> wrapper had already processed the "receiver" or "this" of the compile method. According to the CallNonGenericMethod documentation, if args.thisv() is not of the correct type, it will attempt to unwrap this and if successful, call the implementation function on the unwrapped this. For a bit of context on this, SpiderMonkey has a concept of Wrapper objects, which decorate an object in a sort of proxy membrane to provide security boundary enforcement. For instance, ensuring that a method can be invoked or a field can be written to from the presently entered compartment. Unwrapping an object means removing that proxy membrane, to access the actual object, similar to how you’d unwrap a gift. This can be done using js::CheckedUnwrapStatic().

With --more-compartments, CallNonGenericMethod in regexp_compile() was automatically unwrapping cross-compartment proxies through CallMethodIfWrapped before calling regexp_compile_impl().

This unwrapping process also switched the JSContext to the target object's realm. This meant that by the time my realm checks executed in regexp_compile_impl(), both cx->realm() and the RegExp object's realm pointed to the same realm (the object's home realm), making them appear equal even in genuine cross-realm call scenarios where the original call came from a different realm.

So I moved the same-realm testing and [[LegacyFeaturesEnabled]] bit testing to regexp_compile(), just before CallNonGenericMethod is called and added js::CheckedUnwrapStatic() to unwrap any proxy wrappers before checking the realm. This ensures we’re checking the realm of the actual RegExp object and not the compartment wrappers around it.

Subclass Instances #

As mentioned above, the RegExp method RegExp.prototype.compile() re-initializes a RegExp using a newly created matcher for the specified pattern and flags. The proposal adds some restrictions to this which prevent oddities such as subclasses not functioning as expected (for instance, by not preprocessing the pattern and adding context used by their exec() implementation). More importantly, when applied to a cross-realm object, this would result in execution modifying the static RegExp members for the incorrect realm.

The proposal modifies the behavior so that legacy static properties are only updated when direct instances of the built-in RegExp constructor are used, not subclass instances or cross-realm objects, using similar logic to RegExp.prototype.compile():

7. If SameValue(thisRealm, rRealm) is true, then
   • i. If the value of R’s [[LegacyFeaturesEnabled]] internal slot is true, then
     • a. Perform UpdateLegacyRegExpStaticProperties(%RegExp%, S, lastIndex, e, capturedValues).
   • ii. Else,
     • a. Perform InvalidateLegacyRegExpStaticProperties(%RegExp%).

The properties are specced and implemented as accessors with a getter and no setter, except for RegExp.input (and its alias RegExp.$_), which remains writable. Inside each of the accessors, if the receiver this and the %RegExp% realm intrinsic (the standard RegExp constructor) are not the same, we throw a TypeError.

(base) $ ./mach run
 0:00.28 /Users/default/firefox/obj-aarch64-apple-darwin25.2.0/dist/bin/js
js> /a(b)c/.exec("abc"); 
["abc", "b"]
js> RegExp.$1 
"b"
js> new RegExp("a(b)").exec("ab"); 
["ab", "b"]
js> RegExp.$1                       
"b"
js> new (class extends RegExp {})("a(b)").exec("ab"); 
["ab", "b"]
js> RegExp.$1                                          
typein:6:1 TypeError: RegExp static property 'static_paren1_getter' is invalid
Stack:
  @typein:6:1
js> 

/a(b)c/.exec("abc"); RegExp.$1  // should return "b"
new RegExp("a(b)").exec("ab"); RegExp.$1  // "b"
new (class extends RegExp {})("a(b)").exec("ab"); RegExp.$1 //  throws

Normalisation of RegExp Static Properties #

RegExp static properties are now defined as configurable and non-enumerable. This is so that the associated features may be easily removed by using the JavaScript delete operator. This is important for consistency with modern ECMA262 and for allows for applications to further reduce the number of side-affect producing globals, including VM native methods.

In SpiderMonkey, the legacy static properties are defined in RegExp.cpp. To implement the proposal, I enclosed the properties with a NIGHTLY_BUILD directive, removing the JS_PROP_PERMANEN and JS_PROP_ENUMERATE flags to make them configurable and non-enumerable for the Nightly environment, where they can be tested by the community. Outside of Nightly, we continue supporting the old implementation for beta/release environments.

Then, I updated the test262 AnnexB RegExp tests to support the change and to limit the tests to Nightly.

Understanding the Implementation: Challenges and Solutions #

1. Creative Bit Packing #

Once the legacy RegExp statics were normalised, the next step was adding a LegacyFeaturesEnabled internal slot. This slot keeps a reference to its constructor and is checked whenever legacy features are accessed. If the RegExp is a subclass instance or is is associated with a different realm, the slot indicates that legacy features should throw an error.

Initially, I added the slot to the RegExpObject :

static const unsigned LEGACY_FEATURES_ENABLED_SLOT = 3; 

This presented a couple of problems for me:

• The number of reserved slots must match the allocation kind defined in FOR_EACH_OBJECT_ALLOCKIND(D). The number of reserved slots increased to 5, which meant that I had to choose between OBJECT6 or OBJECT8. During implementation, I somehow missed OBJECT6 and went with OBJECT8.

• I knew that I’d get some pushback in code review, as my changes increased the size of the RegExp Object by 32 bytes (four 8-byte slots). I could see that there was a way for Boolean flags to share a slot but I didn't know how to implement my changes without breaking the JIT.

I decided to leave the implementation as is and wait for SpiderMonkey engineers / reviewers to give me feedback and their preference on how to add the Boolean.

During code review, my reviewer Iain pointed out that since we’re only storing a single bit of information (whether legacy features are enabled or not), and the existing FLAGS_SLOT only uses 8 bits, I could store the legacy features in the unused higher bits.

The slot implementation includes a getter, bool legacyFeaturesEnabled(), that reads the bit from the FLAGS_SLOT; and a setter, setLegacyFeaturesEnabled(bool), that writes the bit to the FLAGS_SLOT.

The new approach involved defining some constants based on the size of RegExp Flags so that the code keeps working if RegExpFlags gets bigger in future:

static const size_t RegExpFlagsMask = JS::RegExpFlag::AllFlags;
static const size_t LegacyFeaturesEnabledBit = Bit(8);

static_assert((RegExpFlagsMask & LegacyFeaturesEnabledBit) == 0,
              "LegacyFeaturesEnabledBit must not overlap");

RegExpFlagsMask has a bit set to 1 if that bit is part of the RegExpFlags, and 0 otherwise. The lowest 8 bits are currently set to other RegExp flags, which leaves us with the highest bits to pack our slot in.

We perform two operations: raw & RegExpFlagsMask, which gets only the traditional RegExp flags; and raw & ~RegExpFlagsMask, which gets everything apart from the RegExp flags.Those are bits 0-7. We use bit 8 to store LegacyFeaturesEnabled. When we read the flags, we mask off any bits that are not part of the RegExpFlags.

return JS::RegExpFlags(raw & RegExpFlagsMask);

When we write to the flags, we combine the new value of the RegExpFlags bits (flags.value()) with the old value of the other bits in (raw & RegExpFlagsMask).

uint32_t newValue = flags.value() | (raw & ~RegExpFlagsMask);
setFixedSlot(FLAGS_SLOT, Int32Value(newValue));

When we read the LegacyFeaturesEnabledBit, we check if it’s set. When we write it, we take the existing raw value and either set or clear the LegacyFeaturesEnabledBit.

2. Lazy Evaluation #

The proposal specifies RegExp properties as internal slots of the RegExp Object, and the abstract operations UpdateLegacyRegExpStaticProperties (C, S, startIndex, endIndex, capturedValues) and InvalidateLegacyRegExpStaticProperties(C) were initially confusing. The confusion came from a specification detail: we need to eagerly update the properties at a specific point in time, as opposed to SpiderMonkey’s lazily evaluated implementation.

It was the first time I had come across lazy evaluation and thought, naively, that it would be possible to change the implementation to eagerly update static properties after a successful match. This didn't work for a few reasons.

First, lazy evaluation is heavily embedded in the JIT, so the idea of just changing that was… ambitious. Second, lazy evaluation is a way to defer regexp evaluation until RegExp properties are accessed. Third, there’s no observable difference to the end user whether the RegExp properties were lazily or eagerly evaluated. Lastly, internal slots are a way for ECMA262 to describe the internal state of the object.

So, UpdateLegacyRegExpStaticProperties (C, S, startIndex, endIndex, capturedValues) wasn’t needed, as it codifies already existing behaviour in SpiderMonkey. For InvalidateLegacyRegExpStaticProperties(C), my mentor suggested implementing it as a boolean flag in RegExpStatics.

When a subclass or cross-realm regexp executes, this flag is set to true, preventing legacy static properties from being accessed. The flag is cleared after normal RegExp executions, allowing legacy features to work for standard RegExp instances.

Because InvalidateLegacyRegExpStaticProperties(C) marks the values of the static properties as unavailable by setting the internal slots to empty, in step 4 of the accessors GetLegacyRegExpStaticProperty(C, thisValue, internalSlotName), we throw a TypeError if the static properties are invalidated.

Then, we add the equivalent code in the JIT path and so that when a regexp is executed, we lazily store enough information to be able to rerun the regexp later if the RegExpStatics are accessed.

3. Gating the implementation behind a preference #

The first step to implementing a TC39 proposal in SpiderMonkey is adding a preference for it. This allows the feature to be enabled or disabled at runtime, which is important in gating the feature until it has been tested enough for release.

With this proposal, it was awkward, because this was not a new syntax or library method, but behavioral modifications to the existing RegExp static properties and the compile() method.

At first, I enclosed my changes in an #ifdef NIGHTLY_BUILD directive so that they are only available in the nightly environment. But given the potential for web compatibility risks, we needed to put the changes behind a preference. That way, we can flip the feature back in case we break something.

This created an awkward situation: the static RegExp properties themselves (like RegExp.$1, RegExp.input) are defined in regexp_static_props, which is baked into the static RegExp JSClass and embedded in the binary at compile time. I ended up wrapping these property definitions in an #ifdef NIGHTLY_BUILD, meaning they only exist in Nightly builds.

But the behavior of these properties — that is, whether accessing them should throw errors for subclasses and cross-realm regexps — is gated behind a runtime preference. This is even more awkward, because it will change behaviour in Nightly even without the preference enabled.

Thus, the preference only controls whether the new throwing behavior is active. As Iain noted, there wasn't a particularly clean way to avoid this. We'd need two parallel RegExp classes and then have to switch between them at runtime based on the pref, which seemed like overkill.

The compromise was to ship the properties in Nightly, use the preference to control the new behavior, and rely on extra-careful testing.

4. Wild Goose Chase #

Around August, when I had the initial implementation working without memory optimization or centralized legacy and realm checks, I was updating legacy regexp statics in RegExpBuiltinExec() only when matches succeeded.

RegExpBuiltinExec() has two execution paths: a forTest path for RegExp.prototype.test (where we can skip allocating a result object) and a normal path for full execution. I had legacy feature validation in both paths, but only for successful matches.

My mentor suggested we needed to update the legacy regexp statics not just on success, but also on failure. That made sense from a spec perspective, so I spent the next week and a half trying to figure out how to implement this. I was looking into the execution paths, trying to understand where and how to trigger updates on failed matches.

After about a week, we realized that they had misread the proposal! Oops. Turns out, SpiderMonkey doesn't update legacy regexp properties on failure at all: it just returns the last successful result. I'd been chasing a solution to a problem that didn't actually exist in the implementation.

Next Steps and Final Thoughts #

The "Legacy RegExp features in JavaScript" proposal is, at the time of this writing, in stage 3 of the TC39 process, meaning the proposal is stable and no further changes can be made to it. There are potential backward compatibility risks and any attempt to use a disabled feature will throw a Type Error. More on that can be found in the Breaking Hazards portion of the proposal.

Before implementing this proposal I had briefly interacted with C++ on a production level codebase when working on the Error.isError proposal, but working on legacy RegExp properties was a deeper dive into C++ and browser internals, which was difficult but also very much appreciated!

Working on this proposal exposed gaps in my knowledge but also gave me confidence in navigating large C++ codebases. I’m particularly grateful to my mentor, and Daniel Minor and Iain Ireland (from the SpiderMonkey team) for pointing me in the right direction and brainstorming solutions with me.

You may also like: #

A New RegExp Engine in SpiderMonkey

Implementing Iterator.range in SpiderMonkey

Update on what happened in WebKit in the week from December 26 to January 19.

We're back! The first periodical of 2026 brings you performance optimizations, improvements to the memory footprint calculation, new APIs, the removal of the legacy Qt5 WPE backend, and as always, progress on JSC's Temporal implementation.

Cross-Port 🐱

JavaScriptCore 🐟

Graphics 🖼️

WPE WebKit 📟

WPE Platform API 🧩

This is a brief blog post to highlight the growth of the Servo community in recent years, particularly since Igalia took over the project maintenance in 2023.

Note that this doesn’t talk about the technical achievements, though there have been tons of them in the last years. A picture is worth a thousand words so just take a look at this slide from my latest Servo talk which shows how google.com was rendered with Servo at the beginning of 2023 vs September 2025.

PRs numbers #

So like we did last year, let’s take a look at the PRs merged on the main Servo repository on GitHub since 2018.

• PRs: total number of PRs merged.
• Contributors: average number of contributors per month.
• Contributors ≥ 10: average number of contributors that have merged more than 10 PRs per month.

As a clarification, these numbers don’t include PRs from bots (dependabot and Servo WPT Sync).

Checking this we can see we are close to double the numbers from last year! The numbers in 2025 are way bigger than in the previous years (even checking the numbers from 2018-2019), showing a healthy community working on Servo.

The next chart is a different view of the same data but split per month, with the number of PRs landed every month, the number of contributors and the number of contributors with more than 10 patches. It shows the evolution over the years and the high activity last year.

Number of contributors #

Now let’s focus on the last 3 years, since the project reactivation, and the numbers of contributors to the Servo project.