31 May 2026

feedPlanet Mozilla

The Servo Blog: April in Servo: new Android UI, focus, forms, security fixes, and more!

Servo 0.2.0 contains all of the changes we landed in April, which came out to yet another record 534 commits (March: 530). For security fixes, see § Security.

servoshell 0.2.0 showing several new features: better wrapping for CJK scripts, ‘tab-size’, better file pickers and `<textarea>`, `<select multiple>`, ‘::details-content::before’ and ‘::details-content::after’, and ‘color-mix()’ with any number of colors

We've shipped several new web platform features:

Plus a bunch of new DOM APIs:

Servo's support for text in Chinese, Japanese, and Korean languages has improved, with correct wrapping in the layout engine (@SharanRP, #43744), and CJK fonts now enabled in servoshell's browser UI on Windows, Linux, and FreeBSD (@yezhizhen, @CynthiaOketch, @nortti0, #44055, #44138, #44514).

Navigating to a JSON file as the top-level document now renders the JSON with an interactive pretty-printer (@webbeef, @TimvdLippe, #43702).

April was a big milestone for Servo, with some automated tests failing because they had hard-coded cookie expiry dates set to April 2016 plus ten years. Surprise! We're still here. Here's to the next 100 years of Servo (@jdm, #44341).

This is another big update, so here's an outline:

Security

Crypto­Key now zeroes buffers containing key material after use (@kkoyung, #44597).

With only a few exceptions, you can only access DOM APIs in another document if that document is in the same origin. But if that document is in the same site with a different port number, Servo currently allows these accesses even though it shouldn't. We've fixed some (but not all) of these incorrect accesses, specifically those that involve binding a Window or Location method in this document with a this from the other document (@yvt, @jdm, #28583).

We've fixed a bug where local­Storage and session­Storage were usable in sandboxed <iframe> and shared with every other sandboxed <iframe>, rather than throwing Security­Error (@Taym95, #44002).

We've fixed a bug where local­Storage and session­Storage were shared between all <iframe srcdoc> documents, rather than isolated using the origin of the containing document (@niyabits, #43988, #44038).

We've fixed a bug where IndexedDB was usable in sandboxed <iframe> and data: URL web workers (@Taym95, #44088).

We've fixed a bug where pages in some IP address origins can evict cookies from other IP address origins (@officialasishkumar, #44152). Only evicting cookies was possible, not reading or writing them.

We've fixed an out-of-bounds memory read in tex­Image3D() on Web­GL2­Rendering­Context (@simartin, #44270), and fixed some undefined behaviour in servoshell's signal handler (@Narfinger, #43891).

Work in progress

IndexedDB is now enabled in servoshell's experimental mode (@arihant2math, #44245). As always, embedders can enable it with Preferences::dom­_indexeddb­_enabled (@arihant2math, #44245, #44283).

IndexedDB now uses Servo's new "client storage" system, which is based on the Storage Standard and will allow us to have a unified on-disk format and quota management for all web platform features that persistently store data (@gterzian, #44374, #43900). We've also made key range queries more efficient (@arihant2math, #39009), landed improvements to IDB­Database, IDB­Object­Store, IDB­Cursor, IDB­Key­Range, IDB­Request, and to the handling of transactions, keys, values, and exceptions (@Taym95, #44128, #43901, #44009, #43914, #44161, #44183, #44059, #44215, #42998, #43805).

We've made more progress on the Intersection­Observer API, under --pref dom­_intersection­_observer­_enabled (@stevennovaryo, @jdm, #42204).

We're continuing to implement document.exec­Command() for rich text editing (@TimvdLippe, #44529), under --pref dom­_exec­_command­_enabled. This release adds support for the 'bold', 'font­Name', 'font­Size', 'italic', 'strikethrough', and 'underline' commands (@TimvdLippe, @jdm, @mrobinson, #44511, #43287, #44432, #44410, #44194, #44030, #44039, #44041, #44075, #44234, #44250, #44331, #44390, #44137, #44293, #44312, #44347).

All of the features above are enabled in servoshell's experimental mode.

Servo can now build a very basic accessibility tree for web contents, under --pref accessibility­_enabled (@alice, @delan, @lukewarlow, #42338, #43558, #44437, #44438). This includes text runs, plus nine other non-interactive accessibility roles (@alice, @delan, #44255). We've also fixed a crash when reloading pages with accessibility enabled (@alice, #44473), and made accessibility tree updates more efficient (@alice, #44208).

We've started implementing the Sanitizer API, under --pref dom­_sanitizer­_enabled (@kkoyung, #44198, #44290, #44335, #44421, #44452, #44481, #44585, #44594).

We've also started implementing Shared­Worker, under --pref dom­_sharedworker­_enabled (@Taym95, #44375, #44440).

We're working on the Wake­Lock API too, under --pref dom­_wakelock­_enabled (@TG199, @rovertrack, #43617, #44343).

servoshell

servoshell for Android now has a revamped browser UI, including a new history view (@espy, #43795), the apk is 30% smaller (@jschwe, #44278, #44182), and we've fixed the black screen bug when closing settings or switching back from another app (@yezhizhen, #44327). You can now close tabs on OpenHarmony too (@Narfinger, #42713).

servoshell 0.2.0 showing the revamped browser UI on Android. from left to right: viewing a web page, the settings view, the history view

As for servoshell on desktop platforms, we've fixed some focus- and IME-related bugs (@mrobinson, #43872, #43932), and on Windows, we now install a normal shortcut without the strange behaviour of an "advertised" shortcut (@yezhizhen, #44223).

For developers

When using the Inspector tab in the Firefox DevTools, the Rules panel now includes declarations in '@layer' rules (@arabson99, #43912).

When logging expressions in the Console tab, and when hovering over symbols in the Debugger tab, you can now get more information about the contents of functions, arrays, objects, and other values (@atbrakhi, @eerii, #44172, #44173, #44022, #44233, #44196, #44181, #44064, #44023, #44164, #44369, #44262).

When using the Debugger tab, you can now use the Scopes panel to inspect local and global variables (@eerii, @atbrakhi, #43792, #43791), you can now debug web worker scripts (@atbrakhi, #43981), and we've started implementing blackboxing, aka the Ignore source button (@freyacodes, #44142).

We've also landed some initial support for the Style Editor tab (@rovertrack, #44517, #44462).

We're working towards re-enabling our automated DevTools tests in CI, which should make the feature more reliable (@freyacodes, #44577), and we've landed a small build reproducibility fix too (@jschwe, #44459).

For developers of Servo itself, please note that the Cargo 'release' profile is no longer #[cfg(debug­_assertions)] (@jschwe, @mrobinson, #44177). If you've been using 'release' as a "faster 'debug' with assertions" build locally, consider switching to 'checked-release' or 'medium'.

The pull request template has been updated (@mrobinson, #44135). 'Testing' and 'Fixes' should go at the bottom of the PR description, and 'Testing' is about automated tests, not how you tested the PR locally.

We've made more progress on the new dev container, which will provide an alternative to our usual procedures for setting up a Servo build environment (@jschwe, @sagudev, #44126, #44111, #44162, #44641, #44109). Keep an eye out for that in the book!

In the meantime, did you know that you can use Lix or Nix to build Servo on Linux with a lot less hassle, even if you're not using NixOS? For now at least, head to the NixOS page in the book to learn more. We've also fixed a regression that made --debug-mozjs and MOZJS­_FROM­_SOURCE builds take much longer to complete on Linux when not using Nix (@jschwe, #44346).

We've fixed building Servo with the 'jitspew' feature in mozjs, allowing you to set IONFLAGS to enable JIT logging (@simonwuelker, #44010). We've also fixed build issues on Windows and FreeBSD (@zhangxichang, @mrobinson, #44264, #44591).

Embedding API

With this second monthly release of the Servo library, we have some quick notes about API stability and semver compatibility:

We've fixed a build failure affecting embedders with a new or updated Cargo.lock (@jschwe, #44093), and landed several other changes to help us with the Servo library release process (@jschwe, @mukilan, #43972, #44642, #43182, #43866, #44086, #43797).

Breaking changes:

You can now load a URL with custom request headers by calling Web­View::load­_request (@Narfinger, @longvatrong111, @mrobinson, #43338).

You can now retrieve cookies asynchronously by calling Site­Data­Manager::cookies­_for­_url­_async (@longvatrong111, #43794).

The synchronous version of that method, Site­Data­Manager::cookies­_for­_url, was previously not callable because Cookie­Source was not exposed to the public API, but we've fixed that now (@TG199, #44124).

You can now clear session cookies without clearing permanent cookies by calling Site­Data­Manager::clear­_session­_cookies (@longvatrong111, #44166).

When intercepting requests with Servo­Delegate:: and Web­View­Delegate::load­_web­_resource, we now include a destination and referrer­_url in the Web­Resource­Request, which can be helpful if you're implementing ad blocking (@webbeef, #44493).

You can configure Servo to write all of its storage to a unique directory for that session by enabling Opts::temporary­_storage (@janvarga, #44433). Note that these unique directories currently persist after Servo exits, so it's an isolation feature, not a privacy feature.

Window­Rendering­Context::new and Software­Rendering­Context::new now return an error if the given size is less than 1x1 (@freyacodes, @mrobinson, #44011).

We've improved our API docs for Web­View, Web­View­Builder, Web­View­Delegate, ServoDelegate, Prompt­Dialog, Web­Resource­Load, Web­Xr­Registry, Preferences, and servoshell's EXPERIMENTAL­_PREFS (@simonwuelker, @TG199, @sabbCodes, @jdm, @rovertrack, #43892, #43787, #44171, #43947).

We've also improved our API docs for Opts, Output­Options, Diagnostics­Logging, Pref­Value, servo::opts, and servo­_config (@mukilan, #43802).

More on the web platform

Tab navigation now works across <iframe> boundaries (@mrobinson, #44397), and Ctrl+Backspace (or ⌥⌫) now deletes a whole word in input fields (@mrobinson, #43940).

Tab characters are now rendered correctly in <pre> (and other elements with 'white-space: pre'), with proper tab stops (@mrobinson, @SimonSapin, #44480). Spaces are now rendered correctly in 2D <canvas>, instead of twice as wide as they should be (@mrobinson, #43899).

<a href> now correctly resolves the URL with the page encoding (@sabbCodes, #43822).

We've improved the default appearance of <input type=file> (@sabbCodes, #44496) and <textarea placeholder> (@mrobinson, #43770).

All keyboard events, mouse events, wheel events, and pointer events, other than 'pointerenter' and 'pointerleave', now bubble out of shadow roots (@simonwuelker, @webbeef, #43799, #44094). 'error' events on Window now report the correct filename (source in onerror) and lineno (@Gae24, #43632).

console.log() and friends now support printf-style formatting directives, although for now %c is ignored (@TG199, #43897).

file: URLs are now considered secure contexts, so they can now use features like crypto.subtle and crypto.random­UUID (@simonwuelker, #43989).

Exception messages have improved in Location, Static­Range, and the HTML­Element family of types (@arihant2math, @MuhammadMouostafa, @treetmitterglad, #44282, #43260, #43882).

We've improved the conformance of fetch algorithms (@yezhizhen, #43970, #43798), focus and tab navigation (@mrobinson, #43842, #44029, #44360, #43859, #44535), form submission (@TG199, #43700), JS modules (@elomscansio, @Gae24, #43741, #44179, #44042), page navigation (@TimvdLippe, #43857), <svg view­Box> (@yezhizhen, #44420), 'attr()' (@Loirooriol, #43878), ':focus' (@mrobinson, #43873), 'font' (@RichardTjokroutomo, #44061), '@keyframes' (@simonwuelker, #43461), '@property' (@Loirooriol, #43878), 'load' events (@jdm, @arabson99, #43807, #44046), fetch­Later() (@TimvdLippe, #43627), axes and buttons on Gamepad (@log101, @rovertrack, #44411, #44357), copy­Tex­Image­2D() on Web­GL­Rendering­Context (@simartin, @mrobinson, #43608), tex­Image3D() on Web­GL2­Rendering­Context (@simartin, #44367), environment­Blend­Mode on XR­Session (@msub2, #44155), mark() and measure() on Performance (@shubhamg13, @simonwuelker, #44471, #44199, #43990, #43753), and Performance­Resource­Timing (@shubhamg13, #44228).

We've fixed bugs related to console logging (@sabbCodes, #44243), 'animation' (@mrobinson, #44299), 'box-shadow' (@yezhizhen, #44474, #44457), 'display: contents' (@Loirooriol, @mrobinson, #44551, #44299), 'display: inline-flex' (@SimonSapin, #44281), 'display: table-cell' (@Loirooriol, #44550), 'display: table-row-group' (@Veercodeprog, #43674), 'overflow-x: clip' and 'overflow-y: clip' (@Messi002, #43620), 'position: absolute' on grid items (@nicoburns, #44324), 'word-spacing: <percentage>' (@sabbCodes, #44031), remove­Child() on Document (@rovertrack, #44133), and URL.revoke­Object­URL() (@simonwuelker, @jdm, #43746, #43977, #44035).

Performance and stability

We've fixed some big inefficiencies in Servo. append­Child() with nested shadow roots is no longer O ( 2 n ) (@yezhizhen, @webbeef, #44016), and we've halved the time it takes to load the ECMAScript spec by fixing the O ( whole DOM tree ) processing of 'id' and 'name' attributes (@simonwuelker, #44120, #44127, #44117).

Servo makes its first TLS connection in each session 30-60 ms faster (@jschwe, #44242), and we've instrumented the Servo and servoshell startup processes to find more opportunities for optimisation (@jschwe, #44443, #44456).

Like most browser engines, Servo is a multi-threaded (and sometimes multi-process) system requiring a great deal of IPC messages to keep everything connected. Two key components of this system are the constellation thread, which manages the engine as a whole, and the script threads (or web processes), which render the web pages. Sending these messages can be expensive though, so to reduce unnecessary IPC traffic, we've landed an optimisation that allows script threads to selectively receive only the relevant messages from the constellation (@webbeef, #43124).

We've reduced the memory usage of each Attr, Text, and Character­Data node in the DOM by 16 bytes (@mrobinson, @Loirooriol, #44074), and fixed a memory leak when deleting <video controls> or <audio controls> (@Messi002, #43983).

Our about:memory page is more accurate now too, with new tracking of libc memory allocations on macOS, improved tracking of libc memory allocations on Linux (@jschwe, #44037), and more accurate tracking of Path­Buf and types in tokio, http, data­_url, and urlpattern (@Narfinger, #43858).

Less memory usage isn't always better in browser engines though, because there are many kinds of caches and other optimisations we can do to make browsing the web faster, at the expense of increased memory usage. For example, we can greatly speed up prototype checks for DOM objects by storing a number in each object that identifies the concrete type, at the expense of making each DOM object 64 bits larger (@webbeef, #44364).

Layout can now reuse fragments in later reflows, in many cases that involve block layout or 'position: absolute' (@mrobinson, @lukewarlow, @Loirooriol, #42904, #44231). We're also working on reusing shaping results in later reflows, and making inline layout more efficient (@mrobinson, #44370, #43974, #44436).

We've landed several changes that should reduce the binary size of Servo (@rovertrack, @mrobinson, @nicoburns, @Narfinger, #44227, #44221, #44303, #44338, #44428, #44134).

We've also reduced clones, allocations, borrow checks, GC rooting steps, and other operations in many parts of Servo (@rovertrack, @Narfinger, @Loirooriol, @yezhizhen, @simonwuelker, #44008, #44544, #44271, #44279, #43826, #44052, #44139).

Several crashes have been fixed:

We fixed a crash in servoshell when pressing keys like Ctrl+2 or ⌘2 with not enough tabs open (@mrobinson, #44070).

DOM data structures (#[dom­_struct]) can refer to one another, with the help of garbage collection. But when DOM objects are being destroyed, those references can become invalid for a brief moment, depending on the order the GC finalizers run in. This can be unsound if those references are accessed, which is a very easy mistake to make if the type has an impl Drop. To help prevent that class of bug, we're reworking our DOM types so that none of them have #[dom­_struct] and impl Drop at the same time (@willypuzzle, #44119, #44501, #44513).

We've improved our static analysis for GC rooting (@officialasishkumar, #44489), and we've continued our long-running effort to use the Rust type system to make certain kinds of dynamic borrow failures impossible (@sagudev, @TimvdLippe, @Narfinger, @elomscansio, @Gae24, @rovertrack, @yezhizhen, @nodelpit, #43174, #43524, #43928, #43943, #43942, #43944, #43946, #43952, #43975, #44018, #44175, #44241, #44368, #44406, #44441, #44422, #44475, #44478, #44484, #44476, #44490, #44477, #44494, #44497, #44498, #44495, #44505, #44506, #44507, #44508, #44509, #44510, #44512, #44482, #44527, #44528, #44531, #44534, #44542, #44533, #44543, #44553, #44547, #44563, #44562, #44565, #44558, #44583, #44606, #44605, #44608, #44602, #44584, #44620, #44590, #44254, #44628, #44629, #44638, #44626, #44081).

Thanks to a wide range of people, we've also landed a bunch of cleanups and refactors (@delan, @alice, @Skgland, @atbrakhi, @eerii, @sabbCodes, @jdm, @thebabalola, @CynthiaOketch, @kkoyung, @TimvdLippe, @rovertrack, @webbeef, @arabson99, @yezhizhen, @simonwuelker, @mrobinson, @nicoburns, @longvatrong111, @niyabits, @treetmitterglad, @foresterre, @mukilan, @elomscansio, @freyacodes, @StaySafe020, @TG199, #43772, #44006, #43860, #44121, #44160, #43884, #44154, #44569, #43939, #44003, #44110, #44122, #43824, #44635, #44103, #43978, #44092, #44114, #44277, #44454, #44274, #44237, #44232, #44167, #44214, #43820, #43825, #43810, #43838, #43841, #43847, #43875, #43876, #43889, #43893, #43896, #43881, #43906, #43913, #43908, #43917, #43910, #43921, #43924, #43925, #43907, #43923, #43916, #43909, #43911, #43957, #43969, #43967, #43915, #43954, #43963, #43959, #43955, #44067, #44068, #44071, #44084, #44265, #44115, #44358, #43848).

Donations

Thanks again for your generous support! We are now receiving 7349 USD/month (+2.5% from March) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo.

Servo is also on thanks.dev, and already 33 GitHub users (−4 from March) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.

We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you're interested in this kind of sponsorship, please contact us at join@servo.org.

7349 USD/month
10000

Use of donations is decided transparently via the Technical Steering Committee's public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

31 May 2026 12:00am GMT

30 May 2026

feedPlanet Mozilla

Frederik Braun: The S in interoperability

This is a blog post about standards, their proliferation and the issues that may arise. My first involvement with standards was just as a reader. To better understand complicated code or unexpected behavior in a protocol. After a while, I also got involved and helped clarify certain things to ensure …

30 May 2026 10:00pm GMT

28 May 2026

feedPlanet Mozilla

The Rust Programming Language Blog: Announcing Rust 1.96.0

The Rust team is happy to announce a new version of Rust, 1.96.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.96.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.96.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.96.0 stable

New Range* types

Many users expect Range and related core::ops types to be Copy, but this is not the case: they implement Iterator directly, and it is a footgun to implement both Iterator and Copy on the same type so this has been avoided. RFC3550 proposed a set of replacement range types that implement IntoIterator rather than Iterator, meaning they can also be Copy. The standard library portion of that RFC is now stable, introducing:

A Rust version in the near future will also add core::range::RangeFull and core::range::RangeTo as re-exports from core::ops (these do not implement Iterator and already implement Copy), and core::range::legacy::* as the new home for the current ranges. Range syntax like 0..1 still produces the legacy types for now, but will be updated to core::range types in a future edition.

With these stabilizations, it is now possible to store slice accessors in Copy types without splitting start and end:

use core::range::Range;

#[derive(Clone, Copy)]
pub struct Span(Range<usize>);

impl Span {
    pub fn of(self, s: &str) -> &str {
        &s[self.0]
    }
}

The new RangeInclusive also makes its fields public, unlike the legacy version which avoided exposing the exhausted iterator state. This isn't a concern with the new type since it must be converted to begin iteration.

Library authors should consider making use of impl RangeBounds in public API, which accepts both legacy and new range types. If a concrete type is needed, prefer using new ranges as this will eventually become the default.

Assert matching patterns

The new macros assert_matches! and debug_assert_matches! check that a value matches a given pattern, panicking with a Debug representation of the value otherwise. These are essentially the same as assert!(matches!(..)) and debug_assert!(matches!(..)), but the printed value improves the possibility of diagnosing the failure.

These new macros have not been added to the standard prelude, because they would collide with popular third-party crates that provide macros with the same name. Instead, they should be manually imported from core or std before use.

use core::assert_matches;

/// [Random Number](https://xkcd.com/221/)
fn get_random_number() -> u32 {
    // chosen by a fair dice roll.
    // guaranteed to be random.
    4
}

fn main() {
    assert_matches!(get_random_number(), 1..=6);
}

Changes to WebAssembly targets

WebAssembly targets no longer pass --allow-undefined to the linker which means that undefined symbols when linking are now a linker error instead of being converted to WebAssembly imports from the "env" module. This change prevents modules from linking unless all linking-related symbols are defined to catch bugs earlier and prevent accidental issues with symbol naming or similar.

Undefined linking-related symbols are often indicative of build-time related bugs or misconfiguration. If, however, the old behavior is intended then it can be re-enabled with RUSTFLAGS=-Clink-arg=--allow-undefined or by editing the source code and using #[link(wasm_import_module = "env")] on the block defining the symbol.

This change was previously announced on this blog, and now takes effect in Rust 1.96.

Stabilized APIs

Two Cargo advisories

Rust 1.96 contains fixes for two vulnerabilities for users of third-party registries.

Users of crates.io are not affected by either vulnerability.

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.96.0

Many people came together to create Rust 1.96.0. We couldn't have done it without all of you. Thanks!

28 May 2026 12:00am GMT

27 May 2026

feedPlanet Mozilla

Firefox Tooling Announcements: New Deploy of PerfCompare (May 27th)

The latest version of PerfCompare is now live!

Check out the change-log below to see the updates:

[kala-moz]:

[padenot]: Use SJ bandwidth for top-level results, ISJ for subtests

[shtrom]: Bug 2014041: add support for landoInstance QueryString parameter (#1038)

Thank you for the contributions!

Bugs or feature requests can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Element. Come and chat!

1 post - 1 participant

Read full topic

27 May 2026 9:29pm GMT

This Week In Rust: This Week in Rust 653

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs
Miscellaneous

Crate of the Week

This week's crate is inline_tweak, a crate to embed tweakable constants inside your Rust application without full recompilation.

Thanks to Kill The Mule for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

352 pull requests were merged in the last week

Compiler
Library
Cargo
Rustdoc
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

This week was largely positive, with most of the improvements coming from algorithm change in visibility checking: #156228.

Triage done by @panstromek. Revision range: 281c97c3..783eb8c8

Summary:

(instructions:u) mean range count
Regressions ❌
(primary)		 0.4% [0.1%, 0.7%] 5
Regressions ❌
(secondary)		 0.5% [0.1%, 1.1%] 16
Improvements ✅
(primary)		 -0.9% [-6.6%, -0.1%] 164
Improvements ✅
(secondary)		 -0.4% [-1.3%, -0.1%] 51
All ❌✅ (primary) -0.9% [-6.6%, 0.7%] 169

2 Regressions, 2 Improvements, 5 Mixed; 2 of them in rollups 34 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Compiler Team (MCPs only)

Rust

Rust RFCs

Unsafe Code Guidelines

No Items entered Final Comment Period this week for Cargo, Language Team, Language Reference or Leadership Council. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-05-27 - 2026-06-24 🦀

Virtual
Asia
Europe
North America
South America

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

This overflows the trait solver today as well as my brain

- Nadrieril on their blog

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

27 May 2026 4:00am GMT

26 May 2026

feedPlanet Mozilla

Firefox Tooling Announcements: Firefox Profiler Deployment (May 26, 2026)

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what's changed:

Highlights:

Other Changes:

Big thanks to our amazing localizers for making this release possible:

Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel!

1 post - 1 participant

Read full topic

26 May 2026 3:53pm GMT

Andrew Halberstadt: Your New Job is Integrating Code

You felt it. The shift. That your role has fundamentally changed thanks to LLMs. It first entered your subconscious when you realized how easily you can now crank out PRs. You felt it more concretely (and less enthusiastically), as a reviewer when you opened your laptop one morning and noticed your review queue was double what it normally is thanks to everyone else cranking out PRs. And you feel this pervasive, general sense of friction.

It's difficult to pinpoint exactly where this friction is coming from. Depending on the repository size and CI setup, it will be slightly different for everyone. It might involve longer review times or slipping review standards. You might be noticing more merge conflicts and merge related CI failures. Perhaps there are more failures sneaking through to main or CI is taking longer to give you results. You almost certainly feel the grind. People are on edge, tired; developers are pulling in opposite directions.

Here's what LLMs shifted. The bottleneck is no longer producing code. The bottleneck is integrating it. The friction we're feeling is a result of more PRs, more ideas, more reviews, more disagreements all made possible thanks to LLMs. In short, the problem can best be summarized by Figure 1:

Animated clip of germs getting stuck in a door from The Simpsons

But we're living in a moment where many folks haven't realized this yet, and are still under the impression that their job is to produce code.

It's not. Your new job is to integrate it.

26 May 2026 1:50pm GMT

Mozilla Privacy Blog: Growing darkness: Against the rise of internet shutdowns

Disruptions to internet connectivity can occur in countless ways - from weather incidents, natural disasters and accidents to intentional interferences like cyberattacks and government-issued blackouts. Yet while some disruptions are unavoidable, deliberate shutdowns represent a fundamentally different and deeply concerning trend. They undermine the open, global nature of the internet and put the safety, security, and fundamental rights of millions at risk.

For over 25 years, Mozilla has worked to ensure that the internet remains a global public resource-open, accessible, and safe for all. This vision, grounded in the Mozilla Manifesto, holds that the internet must remain a shared, decentralized infrastructure that empowers individuals, supports civic participation, and enables economic opportunity. Internet shutdowns run counter to these principles by restricting access, concentrating control, and weakening the very foundations of the open web.

To help organizations study and document outages, Mozilla makes aggregated Firefox telemetry data available to help identify and understand connectivity disruptions. As 2026 progresses, this data continues to show significant outages affecting millions of people worldwide-many of them the result of deliberate restrictions.

As of late May, Iran's internet blackout had been in place for over 80 days, making it the longest shutdown since the Arab Spring. Following an earlier shutdown amid nationwide protests in January 2026, Iranian authorities have restricted access to the internet since 28 February. This has meant that, for almost three months, millions of Iranians have been cut off from news, communication, work, education, and basic services. It also means that almost no independent information about the situation in Iran is leaving the country, making it almost impossible for humanitarian organizations to assess the situation on the ground. The shutdown has also had a massive impact on the Iranian economy, severely disrupting financial activity and blocking international transactions. Although Iran's president has recently ordered an end to the shutdown, it is unclear how and when Iranians will be able to reconnect to the web.

When large numbers of Firefox users experience connection failures for any reason, this produces an anomaly in the recorded telemetry data. At the country or city level, this can provide a corroborative signal of whether an outage or intentional shutdown occurred. Our telemetry documents the magnitude of the latest outage in Iran. The graph below documents the effect of the outage in multiple ways, such as users' country location, language and timezone.

Across the globe, governments are increasingly interfering with and limiting access to connectivity. Both the number of states limiting connectivity and the amount of internet shutdowns has been growing steadily. In 2025 alone, 313 shutdowns across 52 countries have been documented, a sad record. This is a stark indication that shutdowns and restrictions are no longer a rare emergency measure, but established levers of control.

While the triggers for shutdowns are varied, access to the internet continues to be blocked especially often in times of conflict and political unrest. Especially in the context of hostilities, political tensions or public health emergencies, access to connectivity is a basic humanitarian need.

Beyond their immediate human impact, blackouts also affect the internet itself. Local networks depend on each other to form the global internet, and local restrictions affect the resilience and reliability of the web at large. When governments deliberately disrupt connectivity, they do not only isolate populations; they also contribute to the fragmentation of the global internet, undermining trust, interoperability, and the stability of shared infrastructure. Over time, this erosion risks replacing a single, open web with a patchwork of disconnected or controlled networks.

Governments should foster the health of the internet, not erode it. Access to the internet is widely recognized as essential for enjoying human rights. It is an integral part of modern life, facilitating education, communication, collaboration, business and entertainment. Preserving the open web requires sustained commitment: resisting shutdowns, promoting transparency, and reinforcing the technical and governance frameworks that keep the internet global, interoperable, and accessible. The internet's value-as a platform for opportunity, innovation, and human connection-depends on it remaining open to all.

The post Growing darkness: Against the rise of internet shutdowns appeared first on Open Policy & Advocacy.

26 May 2026 8:04am GMT

25 May 2026

feedPlanet Mozilla

The Rust Programming Language Blog: Security Advisory for Cargo (CVE-2026-5223)

The Rust Security Response Team was notified that Cargo incorrectly handled symlinks inside of crate tarballs downloaded from third-party registries, allowing a malicious crate to override the source code of another crate from the same registry.

This vulnerability is tracked as CVE-2026-5223. The severity of the vulnerability is medium for users of third-party registries. Users of crates.io are not affected, as crates.io forbids uploading crates containing any symlink.

Overview

When building a crate, Cargo extracts its source code in a local cache (stored within ~/.cargo), reusing it for any future build. Cargo includes protections to prevent any file from being extracted outside of the crate's own cache directory.

It was discovered that it's possible to craft a malicious tarball able to extract files one level below the crate's own cache directory. With the way the cache is structured, that allowed the malicious crate to override the cache of other crates belonging to the same registry.

Mitigations

Rust 1.96.0, to be released on May 28th, 2026, will update Cargo to reject extracting any symlink within crate tarballs, regardless of whether they come from crates.io (which already forbids them) or third-party registries. Note that Cargo never added symlinks when running cargo package or cargo publish, so the impact of this should be minimal.

Users who are not able to upgrade to the most recent Rust version are recommended to audit the contents of their registry for the presence of any symlink, and to configure their registry to reject symlink (if such option is available).

Affected versions

All versions of Cargo shipped before Rust 1.96.0 are affected.

Acknowledgements

We'd like to thank Christos Papakonstantinou for reporting this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us address the vulnerability: Josh Triplett for developing the fix; Arlo Siemsen for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure; Ed Page and Eric Huss for advising during the disclosure.

25 May 2026 12:00am GMT

The Rust Programming Language Blog: Security Advisory for Cargo (CVE-2026-5222)

The Rust Security Response Team was notified that Cargo incorrectly normalized the URLs of third-party registries using the sparse index protocol. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry.

This vulnerability is tracked as CVE-2026-5222. The severity of the vulnerability is low, due to the extremely niche requirements needed to achieve the attack.

Overview

Originally Cargo only supported storing a registry's index within git repositories. Most git hosting solutions allow accessing a git repository with or without the .git suffix, so Cargo mirrored this behavior when normalizing registry URLs. This allowed credentials for https://example.com/index to be used for https://example.com/index.git.

This normalization was unintentionally applied to the new sparse indexes too. Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with .git as different URLs than those without the suffix.

If the following conditions apply:

...the attacker could configure https://example.com/index.git to be a Cargo sparse registry requiring authentication for downloads, and with a download URL pointing to a server recording any credentials set to it.

When the attacker then publishes a crate foo to https://example.com/index depending on a crate bar from https://example.com/index.git, and tricks the victim into downloading foo, Cargo will think the two registries share the same credential and send the victim's Cargo token to the malicious registry.

Mitigations

Rust 1.96, to be released on May 28th, 2026, will update Cargo to only strip the .git suffix from registry URLs using the git protocol. No mitigations are available for users of older versions of Cargo.

Affected versions

All versions of Cargo shipped between Rust 1.68 (the stabilization of sparse registries) and 1.96 are affected.

Acknowledgements

We'd like to thank Christos Papakonstantinou for reporting this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us address the vulnerability: Arlo Siemens for developing the fix; Weihang Lo, Eric Huss and Emily Albini for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure.

25 May 2026 12:00am GMT

Jonathan Almeida: Auto-resolve Jujutsu conflicts with your AI agent

With Jujutsu, I've been able to work in multiple workstreams more efficiently than before. This means that if I'm working on multiple things, there is a higher likelihood of something going stale while I wait for a review or touch multiple files. Dealing with conflicts aren't so bad these days, however if I can automate the easy ones, why not?

This is the prompt I've been using with my agent whenever I have a list of changes that have conflicts and don't need me to participate actively on it.

Using the jj version control system, fix the conflicts that are in the changesets from `<start_rev>` to `<end_rev>`. Keep trying until there are no more "(conflict)" in the changesets between those two IDs.

25 May 2026 12:00am GMT

24 May 2026

feedPlanet Mozilla

Mozilla Data YouTube Channel: Data Club: Jeff Silverman - Data Science & Astronomy: AAS 243 & ATDS 6

24 May 2026 3:48am GMT

Mozilla Data YouTube Channel: Introducing Glean Annotations

Leif Oines and Will Lachance introduce Glean Annotations: a process and technology for curating and communicating knowledge about the data we collect in Mozilla's products.

24 May 2026 2:56am GMT

21 May 2026

feedPlanet Mozilla

Mozilla Data YouTube Channel: Monitoring Sensitive Data: How do we monitor data we don't store?

We try to be responsible with data. For example, we: - store as little sensitive data as possible - monitor changes in incoming data on which we've built models But what happens when those two approaches conflict? How do we monitor changes in incoming data that we don't want to store? This talk explains the schema we use to monitor changes in what people are searching for in Firefox...even when we deliberately don't store some of what people are searching for.

21 May 2026 6:30pm GMT

The Mozilla Blog: Mozilla and Adafruit bring Web Serial workflows to Firefox

Firefox and Adafruit graphic showing the Firefox mascot building hardware with colorful shapes. Text: Build it all from Firefox Adafruit recommends Firefox to connect, code, and control hardware directly from your browser.

Launching Web Serial in Firefox 151

The web is built by communities, but not all communities use the web the same way.

That philosophy shaped part of this week's Firefox 151 release, which introduced support for the Web Serial API on desktop. Most folks won't use this API, but for our community of builders and tinkerers, it unlocks the ability to use Firefox to communicate directly with compatible hardware devices like microcontrollers, development boards, and other serial-connected devices.

For developers, makers, educators, hardware enthusiasts, and embedded-device communities, browser-based hardware workflows have increasingly become part of the modern web experience. With Firefox's browser engine, Gecko, now supporting Web Serial, users can now connect, code, configure, and control compatible hardware directly from the browser in many workflows, often without additional software or complicated setup.

If you want to dive deeper into the technical details behind Web Serial support in Firefox 151, you can read our full engineering post here.

Adafruit collaboration

As part of this week's launch, Adafruit, one of the internet's most beloved open-source hardware communities, is collaborating with us to test and validate what browser-based hardware development can look like in Firefox with Web Serial support.

If you've ever spent time with CircuitPython, browser-based board programming, custom controllers, sensors, classroom kits, STEM homework assignments, or a desk covered in blinking microcontrollers-you probably already know Adafruit.

With Web Serial support in Firefox 151, Adafruit's browser-based hardware workflows now work directly in Firefox as well, with no additional software or complicated setup required for many projects. We invite you to give it a try.

Different communities care about different browser experiences. Some people want simplicity, familiarity and productivity. Others want flexibility, customization, and tools that support the way they work, build, experiment, and create. We want the web to be open, flexible, and shaped by the diversity of people building on it.

If you're wiring up your first board, experimenting with hardware projects, or dusting off an old electronics kit, give Adafruit and Web Serial in Firefox a try.

Build something amazing. Make something useful. Tell us what works. Tell us what breaks. Most of all, make it your own.

The Firefox logo

Take control of your internet

Download Firefox

The post Mozilla and Adafruit bring Web Serial workflows to Firefox appeared first on The Mozilla Blog.

21 May 2026 6:00pm GMT

Hacks.Mozilla.Org: Announcing Web Serial Support in Firefox

Support for Web Serial in Firefox 151 for Desktop

Firefox can now connect directly to microcontrollers, development boards, 3D printers, power meters, and other serial-connected hardware from the web. Starting in Firefox 151 for Desktop, support for the Web Serial API allows web applications to communicate with compatible devices without requiring native software.

Web Serial compatible devices are popular among hobbyists, hardware hackers, educators, makers, and developers with use cases ranging from home automation to hardware prototyping and 3D printing. Web Serial support makes Firefox more useful for these kinds of projects.

One of the organizations that has demonstrated the value of Web Serial is Adafruit, a leader in open-source hardware and STEM education. They've made it quick and easy to install CircuitPython on their devices by delivering firmware over Web Serial. Then it's straightforward to run Python programs on the device. Name your file code.py and, for most devices, the code can be installed by dragging-and-dropping the file onto the USB device. Your Python programs can interoperate with a web page over Web Serial using simple text-based I/O.

To install CircuitPython firmware with Firefox, we recommend using the Adafruit Web Serial Tool and not the OPEN INSTALLER method on the CircuitPython site.

Here's an example using an Adafruit ESP32-S2 based board where messages sent from web code can be directly displayed on the device over Web Serial.

A video showing an example CircuitPython Web Serial project where a message is sent from a local web page using Web Serial to a device running a CircuitPython code.py file.

We've collaborated with Adafruit to test Firefox's implementation against real hardware workflows commonly used by this community. The result: Firefox is a more practical browser for programming and interacting with hardware directly using web technology.

As an example of how you can combine Web Serial with electronics, Mozilla engineer Alex Franchuk created an amazingly fun and functional device that melds electronics and web editing. Check out the Page Playground.

The list of serial compatible devices includes Espressif ESP-based boards such as the popular ESP32 chips, Raspberry Pi Picos, 3D printers, LEGO devices, and many more. There are many tools for running your own code on these small affordable microcontroller boards, and with Web Serial it's easier than ever to connect them to a computer and interact through a web-based user interface.

What is Web Serial?

Web Serial is a web API that allows a website to read and write to serial devices using JavaScript. See the MDN documentation for the details. While modern computers don't typically include serial ports, serial devices connected to a USB port or paired via Bluetooth can advertise themselves as serial-capable devices so they appear as serial ports in the operating system.

The Web Serial API lets developers use the web platform to communicate with these devices. For example, websites can control devices or deliver firmware without requiring native applications or installers.

Mozilla's own Florian Quèze, who has experimented with many projects to measure power consumption, demonstrated how Web Serial could be used to read power data from an off-the-shelf USB power meter and display it in Firefox. Florian's code can also export the data into the Firefox Profiler, making it easy to visualize and share power data. Here's the page and GitHub repo. The screenshots below show the page in action and the data in the Firefox Profiler after recording the power usage of a light with three brightness modes.

A screenshot of Florian’s site showing a power recording of a light with three brightness modes.

A screenshot of Florian's site showing a power recording of a light with three brightness modes.The power meter used in the pictured power tests was the AVHzY C3 USB. The Joy-IT TC66C and YZXStudio USB ZY1280 were also successfully tested.

A screenshot of the Firefox Profiler displaying the imported power recording from Florian’s site.

A screenshot of the Firefox Profiler displaying the imported power recording from Florian's site.

Home Assistant is another example. It's a popular (and growing) open source project for home automation. The ESPHome project offers Home Assistant-compatible firmware for affordable ESP32 and similar devices which can be installed and configured over Web Serial in just a few clicks.

Security and Privacy

There are clear security and privacy concerns with allowing the web platform to read and write to hardware devices. Most importantly, with Web Serial, websites do not have visibility or access to serial ports until the user explicitly allows it.

Ports are allowed on a per-site and per-port basis. The Web Serial API requires websites to call navigator.serial.requestPort(), which lets the user choose which port to allow access to, or disallow all access entirely. This means websites do not receive a list of connected devices and there is no useful fingerprinting information outside of the port the user selects.

A screenshot of the Web Serial port selection prompt in Firefox.

A screenshot of the Web Serial port selection prompt in Firefox.

To help users understand when and why a site requests access to a serial port, Firefox uses add-on gating which we introduced with our Web MIDI API implementation. Compared to other web permission prompts, this gives the user a more detailed explanation of what they're allowing. The add-on gating prompts appear before the port selection prompt the first time a site requests port access.

For organizations using Firefox Enterprise Policies, Web Serial is disabled by default. Administrators can explicitly allow or disallow Web Serial functionality across their organization using the DefaultSerialGuardSetting policy setting.

Standardization

While Web Serial still resides in the Web Incubator Community Group (WICG), we're optimistic there's a path to standardization given its scope and long-running incubation. We are pursuing standardizing the Web Serial API in the WHATWG in a new Workstream proposal and are excited to work with ecosystem partners and standards bodies to help shape access to peripherals on the web.

Feedback

If you already have a Web Serial workflow with a device you can test on, give Firefox a try. We'd love to hear what you're building and which workflows matter most to you. Mozilla Connect is a great place to share projects, ask questions, and give feedback.

For technical issues, browse to support.mozilla.org or file a bug here.

The post Announcing Web Serial Support in Firefox appeared first on Mozilla Hacks - the Web developer blog.

21 May 2026 6:00pm GMT