<a href="/proxy?url=https%3A%2F%2Fplanet.mozilla.org%2F" title="Back to home page">Planet Mozilla

Deny todo!() in tidy

Leadership Council

Rust All Hands 2027

No Items entered Final Comment Period this week for Rust RFCs, Cargo, Language Team, Language Reference or Unsafe Code Guidelines.

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

RFC for convenient, explicit closure capture using move($expr) expressions

Upcoming Events

Rusty Events between 2026-06-10 - 2026-07-08 🦀

South America

2026-06-18 | Florianópolis, BR | Rust SC
- Rust Floripa

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

It's a footgun, yes, but it's a sound footgun.

– Prof. Dr. Ralf Jung on github

Thanks to Theemathas for the suggestion!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Firefox Tooling Announcements

Happy BMO Push Day! (20260609.1)

By dkl1 on June 09, 2026 05:28 PM

Github Link

The following changes have been pushed to bugzilla.mozilla.org:

Bug 2043429 - Selenium test 1_test_bug_edit.t intermittently fails when attemtping to click on comment reactions
Bug 1995467 - Show dependency tree on meta bugs by default
Bug 2043322 - text/html attachments are downloaded instead of viewing in-browser
Bug 2038298 - Render Phabricator revisions stack fork in the parent’s row
Bug 2045855 - phab-bot attempts to set approval flags for disabled flags
Bug 2044471 - Add loading indicator to embedded dependency tree
Bug 2034051 - Update Bugzilla Etiquette with guidance about AI usage
Bug 2033409 - Pasting a link from the clipboard after using the Link button inserts additional markdown into the link

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

The Mozilla Blog

Browse more privately all summer with Firefox’s free built-in VPN

By Mozilla on June 09, 2026 03:58 PM

For a limited time, where the VPN is available, users can get unlimited VPN bandwidth in Firefox – up from the 50 gigabytes monthly limit — plus access to over 25 country locations to browse from. Don’t have Firefox yet? Try it now.

Firefox’s free built-in VPN usually gives eligible users 50 GB of free bandwidth each month. From now through Aug. 31, we’re making that unlimited, so you have more room to browse privately while you travel, work from public Wi-Fi or connect from somewhere new. Not only will users get unlimited bandwidth, but we’re also unlocking access to 28 country locations to browse from during this period. The VPN returns to its standard 50 GB monthly limit and a standard location set on Sept. 1.

Whether you’re using the airport Wi-Fi, booking a last-minute flight or trying to access websites away from home, here are a few ways Firefox’s VPN can help while you travel:

Stay protected on public Wi-Fi at the airport, train station or hotel

When you’re traveling, public Wi-Fi is often part of the deal. But those networks can make it easier for others to spy on your traffic and see which websites you’re visiting. Firefox’s built-in VPN adds another layer of privacy by helping mask your IP address and makes it harder for others on the network to see your browsing activity.

Browse like you’re back home

The web can feel a little funky when you go abroad. Sites may load in another language, show a different local version or have trouble recognizing where you usually browse from. Maybe you need to schedule your monthly pharmacy prescription, but the site isn’t loading the way it normally does from home. Or maybe you’re trying to order a new dress to your apartment but the address isn’t registering properly.

With Firefox’s built-in VPN, you can switch your browsing location back to your home country so the sites and services you rely on feel a little more familiar while you’re away.

Or choose where you browse from

Firefox can recommend a VPN location based on what’s fastest and most convenient. But you can also choose from more available locations, whether you want to browse closer to home or see how the web looks somewhere else.

The full set of countries available during this summer period include: Australia, Austria, Belgium, Bulgaria, Canada, Chile, Colombia, Denmark, Finland, France, Germany, Ireland, Italy, Malaysia, Mexico, Netherlands, New Zealand, Portugal, Singapore, Spain, Sweden, Thailand, Norway, South Africa, United Kingdom and United States.

Turn off VPN for specific sites

Some sites don’t always work smoothly with VPNs. If one is giving you trouble, you can turn the VPN off for that website right from the panel. You can also add sites to a list in advanced settings if you don’t want them to connect through the VPN.

Free VPN for wherever summer takes you

Wherever you’re logging on this summer, Firefox’s built-in VPN gives you an easy way to add another layer of protection while you browse. More control for summer browsing, right where you need it. As it should be.

Take control of your internet

Download Firefox

The post Browse more privately all summer with Firefox’s free built-in VPN appeared first on The Mozilla Blog.

Niko Matsakis

Only Bounds

By Niko Matsakis on June 09, 2026 09:04 AM

only bounds are going to be the most impactful change to Rust that you’ve never heard of. They are currently being designed and developed by the Arm team (David Wood, Rémy Rakic, et al.) as part of the Sized Hierarchy and Scalable Vector Extension project goal. This post explores the feature and aims to answer a particular question about the design (the scope of bounds, I’ll explain). But before I dive in, I want to give a bit of context.

Rust generics have a `Sized` bound by default today

In today’s Rust, every type parameter (except for Self) has a default bound called Sized:

// So this function...
fn identity<T>(t: T)-> T{t}// ...is actually short for
fn identity<T>(t: T)-> TwhereT: Sized,// <-- Added by default!
{t}

A type T implements Sized if the compiler can compute the size of a T value at compilation time. This is true for almost every type, with a few notable exceptions. Consider [u32], which refers to “some number of u32 instances”. We know that a single u32 is 4 bytes, but without knowing how many u32 there are, you can’t know the size of [u32]. This means you can’t have a value of type [u32] on the stack (how big should the stack frame be?).

You opt out with `?Sized`

However, if you have a function like by_ref, that just takes the value by reference (i.e., by pointer), you shouldn’t need to know how big the [u32] value is, because you’re not manipulating it directly. You can have a type parameter U that doesn’t require Sized, but you have to explicitly “opt out” from the default bound:

fn by_ref<U>(t: &U)whereU: ?Sized,// <-- Opt out from the default
{}

As a fun bit of historical trivia, this system was introduced way back in 2014 to accommodate Dynamically Sized Types. Before that, &[u32] was actually a built-in, indivisible type; we even wrote it like [u32]/& for a time.¹

But `Sized` vs `?Sized` isn’t enough for everything we need

The Sized vs ?Sized design has served us reasonably well but it is also showing its limits. It turns out that “value has a statically computable size” vs “each value has a distinct size computable at runtime” doesn’t cover all the things you might want. For example, extern types are types whose values have no known size, even at runtime. And then Arm’s Scalable Vector Extension want to describe SIMD types where every value of the type has the same size (unlike str and [T], where each value can have a different length) but where that size is not known until runtime.

A richer `Sized` hierarchy

Rather than just Sized or ?Sized, what we really want is to have a richer hierarchy. The current plans look something like this:

flowchart TD
  subgraph S["Sizedness traits"]
      Sized[["Sized (default)"]] -- extends --> MetadataSized
      MetadataSized -- extends --> MaybeSized
  end

where

trait Sized means that all values have the same size and that size can be computed knowing only the type.
trait MetadataSized means that values can have different sizes and that size can be computed given the metadata attached to a reference to the value. Examples include [T] or dyn Trait.
trait MaybeSized is implemented for all values and tells you nothing about the value’s size.

Two caveats:

I’m excluding the way that Arm’s Scalable Vector Extension fit into this, because it’s orthogonal.
The trait names aren’t settled. I’m using the names I understand the libs-api team to prefer; they’re not my favorites, but that’s ultimately the team who owns stdlib bikesheds, so I defer to them.²

Problem: `?Sized` notation doesn’t scale to this hierarchy

But now we have a kind of problem. The ?Sized notation was predicated³ on the idea that users should specify the default bound they are opting out of – i.e., the ? is meant to say “I don’t know if this is Sized or not” (unlike the default, where you know it is Sized). But “opting out” from a bound doesn’t work so well with a multi-level hierarchy. When you write ?Sized, does that correspond to T: MetadataSized (but not T: Sized)? And what if we want to insert another level in between T: MetadataSized and T: Sized later? Then we either have to change what T: ?Sized means (to refer to the new bound) or we have to have T: ?Sized drop two levels down the hierarchy. Even more annoying, what do we do while that middle rung is unstable? Surely T: ?Sized shouldn’t refer to an unstable trait… what if we decide to remove it

Solution: `only` bounds

The new proposal is to write T: only MetadataSized or T: only UnknownSized instead of T: ?Sized. An only bound combines two things:

Like any bound, it includes a “minimum requirement” – i.e., T: only MetadataSized means that T must implement at least MetadataSized.
It additionally disables some default bounds – i.e., we will not add the default T: Sized bound.

The name only comes from the fact that T: Sized implies T: MetadataSized. So the default of T: Sized already means that T: MetadataSized for free; but when you write only MetadataSized, you are saying “I don’t need the full hierarchy, just MetadataSized will do”.

`only` bounds work like normal bounds: ask for what you need

A nice feature of only bounds is that they work more like a regular bound. Whereas a ? bound is saying “I don’t need this”, an only bound is saying what you do need. So e.g. if you are writing a function that just has references to values of type T does not care what their size is, you can write

fn by_ref<U>(u: &U)whereU: onlyMaybeSized,{}

If you are writing a function that does need to compute the size of values of type V, you can ask for that capability:

fn checks_size<V>(v: &V)whereV: onlyMetadataSized,{std::mem::size_of_val(v)}

`only` bounds allow for new levels to be added later

A nice feature of only bounds is that, later on, we can add new levels to the hierarchy, and they work normally. For example, suppose we wish to add something like Aligned where the size is not known at compilation time but the alignment is. We could change the hierarchy to

traitSized: AlignedtraitAligned: MetadataSized// <-- new!
traitMetadataSized: MaybeSizedtraitMaybeSized

and functions with U: only MaybeSized (like by_ref) and with V: only MetadataSized (with checks_size) would continue to have the same requirements. But new functions could be written with T: only Aligned that would use the new bound. And there is no conflict with stabilization; code that writes T: only Aligned can be considered unstable until that middle hierarchy is finalized.

`only` bounds compose normally

Like any other bound, only bounds are combined with other bounds to form the overall requirements. So it is possible to write e.g. T: only MetadataSized + Sized. This is equivalent to T: Sized and therefore equivalent to the default and therefore kind of pointless, but you can write it. Similarly, given that trait Clone: Sized, if you write T: only MetadataSized + Clone, that is kind of pointless too: you might as well write T: Clone, which would be equivalent. We plan to have a warn-by-default lint for that.

Scaling `only` to other “default bound families” (speculative)

The final strength of only bounds is that they allow us to introduce whole new families of default bounds. One example is the idea of introducing a Move bound. Note that this is a distinct feature and is not covered under the current RFC.

All types in Rust today are “movable” and “forgettable”, meaning that you can memcpy the value from place to place so long as you stop using the previous location and you can recycle the memory where it is stored without running the value’s destructor. There is one notable exception – when you pin a value, you it can no longer be moved, and you must run its destructor before its memory is reused – but otherwise this is a hard-and-fast rule. And that’s annoying!

The problem is that not being able to guarantee that a destructor runs blocks a lot of unsafe code patterns. For example, scoped tasks a la rayon depend on a destructor for safety. In sync code, this works because we’ve decided it’s UB to unwind a stack frame without running the destructors of values stored there, and so if you put a local variable on the stack, you can be sure its destructor will run. But that doesn’t work in async code! And there are times when unwinding without running destructors would be nice.

The solution is to introduce a second family of default traits. Unlike the Sized family we saw before, this family defines fine-grained capabilities about how values of that type can be used:

flowchart TD
  subgraph A["Accessability traits"]
      Forget[["Forget (default)"]] -- extends --> Leak
      Leak -- extends --> Destruct
      Destruct -- extends --> Access
      Move[["Move (default)"]] -- extends --> Access
  end
  Copy -- extends --> Move

The meaning of the traits are as follows:

Forget, the default, says that you can recycle the memory for a value without running its destructor.
Leak says that you can skip running a destructor for a value, but only if you never reuse the memory where the value resides.
Destruct says that if you have a value of this type, you can reuse the memory where it resides by running its destructor.
Copy, which already exists, says that you can memcpy the place and keep using the original place; it’s not really a default, but I included it because it is relevant.
Move, another default, says that you can memcpy the value to a new place if you stop using the original.
Access is the root of this family. It indicates a value that can be “accessed in place” (basically, any value at all).

This introduces new checks into the compiler:

When you move a value (i.e., a = b where b is not used later), we will check that the type implements Move (whereas today, it is always allowed).
When you exit a scope, we will check that the values in each local variables have either been moved or have a type that implements Destruct.

Some implications:

If your function owns a value of type T: only Destruct, then you must destruct it before your function returns. You can’t move it (because you don’t know if it implements Move) and you can’t leak or forget it either.
If your function owns a value of type T: only Move, then the only thing you can do with it is move it somewhere else. You can’t drop it (because you don’t know if it implements Destruct).
No function can own a value of type T: only Access, because you wouldn’t be able to move it nor drop it, and hence you could not return. But you could have such a value (say) in a static.

How `only` bounds could work in the presence of multiple families

The spur for writing this blog post was a question in a lang team meeting on how only bounds ought to work given the existence of multiple “families” of default traits, as I described above. Although the current RFC is looking only at the Sized traits, we expect to look at the “access family” in a future RFC, so we want to be sure we are not making any decisions that won’t scale to cover both.

The way I imagine it working is like this. Each default traits is associated with one or more “families”. When you have an only bound, it “opts out” from all default traits in each family that the trait is associated with:

T: only Move opts out from Forget, Leak, Destruct – but not Sized.
T: only Destruct opts out from Forget, Leak, and Move – but not Sized.
T: only MetadataSized opts out from Sized – but not Forget or Move.
T: only MaybeSized opts out from Sized – but not Forget or Move.

You may also want to “opt back in” to some defaults. For example, T: only Move + Destruct is a sensible thing to do. It means values that can be moved and destructed but not leaked or forgotten.

Examples

`Option::map` requires `only Move`

map is an example of a function that only needs Move. You need to be able to destructure self (which moves the optional value out into a local variable v and then invoke the closure op, which again moves the wrapped value v:

impl<T: onlyMove>Option<T>{fn map<U: onlyMove>(self,op: implFnOnce(T)-> U,)-> Option<U>{matchself{Some(v)=>Some(op(v)),None=>None,}}}

One interesting thing is the result type U. Using only the stuff I wrote in this blog post, it needs to be only Move, because the result will be moved into the Some value and so forth. But in-place-init would allow for this definition to omit the U: only Move bound because we could statically guarantee that the Option will be constructed in place and never moved after that.

`Option::or` requires `only Move + Destruct`

The a.or(b) method on Option returns a if it is Some and otherwise returns b. This is an interesting one because the value b may not be used and therefore requires only Move + Destruct bounds.

impl<T: onlyMove>Option<T>{fn or(self,alternate: Option<T>,)-> Option<T>whereT: Destruct,// <-- because it may be dropped
{matchself{Some(v)=>Some(v),// drops `alternate`
None=>alternate,// moves `alternate`
}}}

`Rc` requires `MaybeSized + Leak`

The Rc type is an example where we would want to relax bounds from both families:

struct Rc<T: onlyMaybeSized+onlyLeak>{}

I believe the proper minimum bounds for Rc are:

only MaybeSized because while it can store MetadataSized or Sized things, it doesn’t have to, it can also store things of an non-computable size (although it does raise the question of how they would be freed, but that’s an allocator concern).
only Leak because Rc values can form cycles and thus we can’t ever guarantee the destructor will be run. Interestingly, Rc<T> can implement Forget even its contents don’t.

Frequently asked questions

What is actually under RFC today?

The post may be a bit confusing here. The current RFC is looking only at the proposed “Sized” traits. The Access family is a speculative future extension that we are exploring but at a much earlier stage.

Can I use `only` with any trait?

In the beginning, the plan would be that only can only be used for well-known, default traits (e.g., Move, Sized, etc). In the future though there are some thoughts to generalizing it.

Why not opt out from all defaults at once?

An alternative that was proposed is to have the opt-out be per-type-parameter. So you might write something like

fn foo<T: MetadataSized+?default>

which would “opt out” from all defaulted bounds. Obviously we’d have to bikeshed the syntax, but ignore that for now. The question is whether opting out of all defaults is better than opting out of a single family. I prefer the per-family option for two reasons:

First, things like T: only Move demonstrate that you might very reasonably which to opt out from a single family but retain the default Sized bound. I think it’s likely that there will be many functions that want to opt out of Sized or Forget but not both.
- You might think that we could make Move: Sized to get the same effect, but I think that would be a mistake. The fact that a value’s size must be computed dynamically doesn’t inherently mean it can’t be moved.
Second, it makes it harder to introduce new families later, if we decide there are other orthogonal properties of values that we’d like to relax.

Why do you think it’s likely that people want to opt out of being `Sized` xor `Forget` but not both?

Because the Forget, Move, and similar traits mostly apply to owned values. The examples we saw with Option<T> were quite typical. And when you are moving values of type T around, you need that T to be Sized.

But we saw that `Rc` wanted to opt out of both families with `only Leak + only MetadataSized`, right?

Yes, that’s true, and I think that particular combo will be common. I don’t think that’s an argument for the ?default approach on its own, though, particularly since that case would not be much cleaner or shorter…

impl<T: ?default+Leak+MetadataSized>Rc<T>{}

…what I think that argues for is actually trait aliases and shorthands.

Wait, trait aliases and shorthands? Can you elaborate?

Yes! I think that a future RFC could extend only bounds to allow you to define trait aliases with “only bounds” as supertraits:

traitRefCountable=onlyLeak+onlyMetadataSized;// Equivalent to:
// trait RefCountable: only Leak + only MetadataSized {}
// impl<T> RefCountable for T where T: only Leak + only MetadataSized {}

You could then use an only RefCountable bound to define Rc<T>:

impl<T: onlyRefcountable>Rc<T>

Without the only, T: Refcountable would just be a regular trait bound and would not opt-out from any defaults.

Can we use a “root” trait to opt out of all defaults?

Yes, we could! You could define an alias like Value:

traitValue=onlyAccess+onlyMaybeSized;

Since Access and MaybeSized are both implemented for all types, this effectively becomes part of both families:

flowchart TD
  subgraph All["All default families"]
  subgraph A["Access family"]
    Forget[["Forget (default)"]] -- extends --> Leak
    Leak -- extends --> Destruct
    Destruct -- extends --> Access
    Move[["Move (default)"]] -- extends --> Access
  end

  subgraph S["MaybeSized family"]
    Sized[["Sized (default)"]] -- extends --> MetadataSized
    MetadataSized -- extends --> MaybeSized
  end

  Access -- extends --> Value
  MaybeSized -- extends --> Value
  end

Then you can do T: only Value and opt out from both families at once.

If we did that, what would happen if we wanted to add a new family in the future?

Ay, there’s the rub. If we wish to add a new family in the future, let’s say for values that don’t live in the same memory space (T: only Distributed…?), then Value would be “out of date” because code written against Value would still be assuming uni-memory-space values. But we could make Value into an edition-dependent alias or something like that, as has been discussed.

Can we decide whether we want `Value` later?

Yes! We can introduce a root trait at any time. So we can add the Sized-ness family first, then the Access family, and then see how we feel. Maybe we find people are very commonly opting out of both– in which case, some aliases are useful, or perhaps a Value variant.

The only way we might “regret” it is if, in practice, people usually just opted out of both and then opted back in to what they want specifically. But we already know that T: only Move will be common and clearly T: only Value + Move + Sized is more awkward in that case, so I don’t consider that very likely.

Why the name `Destruct` and not `Drop`?

That name comes from the const trait RFC. There are a few reasons to move away from Drop. The first is that it is possible to have a destructor even if you don’t implement Drop: Drop really refers to user-provided logic in the destructor, but the compiler adds its own logic (“drop glue”, it’s sometimes called) to drop all the fields in the value. The second reason is that the Drop trait itself needs some revision, so moving away from that name lets us have other ways to specify custom logic (e.g., pinned self, or by-value, etc etc).

How does this interact with `const` traits anyway?

Quite beautifully! In fact, the proposal from Arm for SVE is to introduce the idea of T: const Sized being “a type whose size can be computed at compilation time”, which I find quite elegant. Similarly T: const Destruct was proposed by the const RFC as a way to say that a value has a constant destructor.

It’s annoying to write `T: only Move + Destruct`. Couldn’t we have `Destruct` imply `Move` so that I can just write `T: only Destruct`?

My original proposal for introducing linear types had Destruct extending Move. This would mean that the Option::or proposal could simply do U: only Destruct and not U: only Move + Destruct. However, Alice Ryhl and others pointed out that there are immovable types that must nonetheless be destructed, so it doesn’t make sense to combine those.

Where can I learn more?

The Project Goal has a lot of details. The latest updates are available on the tracking issue. If you like watching videos, I recommend David Wood’s Rust Nation talk.

Conclusion

I want to close with a meta-observation and a big shout-out to the Arm team. I think they are showing how awesome open-source can be. The Arm team’s primary motivation is adding support for Scalable Vector Extension. This helps Rust make full use of Arm processors. This is, in and of itself, a laudable goal, and valuable to Rust: One of Rust’s assets, in my view, is that it gives you access to all the power your processor has to provide, and that should include unique extensions.

But rather than add the feature as a kind of special-case extension to Rust, the Arm team is going further and driving a general purpose improvement, one that will unlock a bunch of other features (extern types and, to some extent, guaranteed destructors; guaranteed destructores themselves unlock scoped async threads and better Wasm integration). I love that.

In fact, I recall that in one of my blog posts I proposed writing "" as the way to spell &str. I kinda wish we had done that just for the sheer wackiness of it (fn foo(name: "")). ↩︎
I prefer names that refer to the operations that can be performed on the values, so e.g. instead of MetadataSized I would prefer SizeOfVal, since it means that you can invoke the std::mem::size_of_val function on it. ↩︎
Little logic pun there for you. ↩︎

Firefox Tooling Announcements

MozPhab 2.15.2 Released

By sheehan on June 08, 2026 06:41 PM

Bugs resolved in Moz-Phab 2.15.2:

bug 2004368 moz-phab patch -a here with jj says there is no source tree if jj config is broken
bug 2035900 Investigate setting up CodSpeed.io for moz-phab
bug 2044857 patch --raw leaks a global logger level, causing order-dependent test failures

Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.

1 post - 1 participant

https://bleach.readthedocs.io/en/latest/changes.html#version-6-4-0-june-5th-2026

The Mozilla Blog

Make Firefox your World Cup sidekick this summer

By Mozilla on June 08, 2026 03:59 PM

Your browser tabs say a lot about your life: work projects, vacation plans, shopping carts and all the rabbit holes in between.

Add the world’s biggest soccer tournament to the mix, and your browser is suddenly juggling scores to check, streams to watch, lineups to scan and group chats to keep up with. And since many matches kick off during the workday, there will be lots of temptation to just sneak a peek at the action between meetings.

Firefox is built to be your ultimate second screen. When the tournament is on, keep Firefox open to follow the action, keep up with the conversation, and stay on top of everything else happening online – whether you’re watching from the couch or checking in on your mobile device on the go.

You’ll find a World Cup widget, custom wallpapers, and game-day multitasking tools. Plus, Firefox is teaming up with Trevor Noah, a soccer superfan, as he hosts live watch parties for the tournament moments everyone will be talking about.

Your second screen for every match

When the action is happening fast, keeping up should be as easy as opening a new tab.

Firefox’s World Cup widget gives you the latest tournament updates every time you open a new tab (and you can turn it off anytime). With key match information always within easy reach, it’s easy to stay on top of the action without bouncing between apps or having to browse around.

You can follow your favorite teams and even customize Firefox with wallpapers that bring big fan vibes to every new tab. To get started, open a new tab and click the Customize icon at the bottom of the page.

Game-day pro moves

Pin the picture

With picture-in-picture in Firefox, you can detach a video from its tab and pin it anywhere on your screen so you can keep watching while working on other stuff.

Split the view

Open two tabs side by side in one window with split view. That way, you can keep live updates on one half and stats, searches or chats on the other.

Calm the chaos

Remember what we said about your tabs representing your life? While 99 tabs of fandom can make it feel more chaotic, your browser doesn’t have to.

With tab groups in Firefox, you can create separate groups for:

soccer matches and live scores
travel plans and itineraries
work or school projects
summer shopping and event planning
weekend inspiration and future adventures

Hang out with Trevor Noah – World Cup and Firefox superfan

Match days are better with good company. This summer, Firefox is teaming up with Trevor Noah to be his second screen sidekick for his World Cup watch party on YouTube.

Hosted live throughout the tournament, the series will feature Trevor alongside some of his best friends plus celebrity guests as they react to matches, highlights and the internet moments coming out of each day’s games.

Trevor is a longtime Firefox user whose comedy and commentary have explored how technology shapes everyday life. That makes this collaboration feel especially fitting for Mozilla, a company built around the idea that the internet should work better for everyone.

“I’m grateful to our incredible brand partner Firefox for helping make this series possible and for believing in the power of sport to bring people together,” said Noah.

“Events like this are some of the biggest shared experiences on the internet,” said John Solomon, Chief Marketing Officer at Mozilla. “While many people stop their lives for the World Cup, those that can’t follow them while working, traveling, connecting with friends and family, and doing everything else they need to do online. Firefox is built for moments like this, and Trevor is a fitting partner. He’s a longtime Firefox user who believes, like we do, that technology should work for people, helping them stay connected to the moments, information and communities they care about most.”

Make Firefox your World Cup sidekick this summer. Follow the tournament with the World Cup widget, multitask like a pro with picture-in-picture, split view and tab groups, and get into the spirit with custom wallpapers, all in the browser that helps you get more out of every match.

Are you game-day ready?

Download Firefox now

The post Make Firefox your World Cup sidekick this summer appeared first on The Mozilla Blog.

Will Kahn-Greene

Bleach 6.4.0 releases -- final release

Will Kahn-Greene on June 05, 2026 01:00 PM

What is it?

Bleach is a Python library for sanitizing and linkifying text from untrusted sources for safe usage in HTML.

Bleach v6.4.0 released!

Bleach 6.4.0 includes two security fixes, a fix to tinycss2 dependency requirements, and some other things.

See the changes here:

Bleach v6.4.0 is the final release

I haven't used Bleach on a project in years, but I still had some time to maintain it. That changed about a year ago when I got re-orged into a new role and I haven't had time to do any Bleach work since then.

To recap, Bleach sits on top of html5lib which hasn't been actively maintained in years. It is dangerous to maintain Bleach in that context.

We vendored html5lib so we could make adjustments to the library to keep Bleach going. This is not a sustainable approach, but it was ok for the short term.

Over the years, we've talked about other options:

find another library to switch to
take over html5lib development
fork html5lib and vendor and maintain our fork
write a new HTML parser
etc

None of those are feasible for me.

Bleach has been a solo-maintained project for a while now. The world is crazy and it's much harder to build a team of trusted maintainers now than it was (or at least, it sure feels that way). I don't see any possibility of increasing the maintenance team or passing it to someone else responsibly.

Switching contexts from my regular work to Bleach is really hard. Bleach is complicated, the problem domain is complicated, and there's a lot of nuanced context. I can't just switch gears, spend 15 minutes on Bleach to do something, and then switch back to the rest of my day. I periodically get nag messages about this which are entirely valid, but there's nothing I can do about it. It doesn't feel great.

Then in 2025, Emil, a long-time Bleach contributor, built justhtml which gives us an easy migration path off of Bleach. He even took the time to write a migration guide.

Thoughts and statistics

In 2019, when I stepped down the first time, I wrote a post on stepping down.

In 2023, when I deprecated the project, I wrote a post on Bleach 6.0.0 and deprecation.

From the first commit on 2010-02-18 to today's final commit on 2026-06-05, the Bleach project lasted 16 years, 3 months — 5,951 days, or about 16.29 years.
There were 64 releases.
There were roughly 960 commits.
- From 80 roughly contributors
- Top 3:
  - Will Kahn-Greene: 462
  - James Socol: 182
  - Greg Guthe: 133
Roughly 5,040 lines of Python code excluding the vendored html5lib.
I was maintainer from October 2015 to now--that's a little under 11 years.

It feels weird to end a project that's outlived many of the Mozilla sites and Python web frameworks it was designed to protect.

What happens now?

This is the end of the project.

Bleach. Last release.

If you're still using Bleach, I think you have three options:

End your project. Maybe you don't need to be maintaining your thing anymore? Use Bleach as your reason to exit and do something different with your time on Earth.
Switch to the sanitizer API. Rework your project to use the sanitizer API.
- Spec: https://wicg.github.io/sanitizer-api/
- Docs: https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML
Swap Bleach out for justhtml. Emil provided a migration guide for switching from Bleach to justhtml.

Good luck with whatever option you choose!

Thanks!

Many thanks to James who created Bleach and gave it a set of first principles that guided our choices for 16 years.

Many thanks to Greg who I worked with on Bleach for a long while and maintained Bleach for several years. Working with Greg was always easy and his reviews were thoughtful and spot-on.

Many thanks to Emil who was a contributor to Bleach for a long while and created justhtml providing Bleach users a migration path.

Many thanks to Jonathan who, over the years, provided a lot of insight into how best to solve some of Bleach's more squirrely problems.

Many thanks to Sam who was an indispensible resource on HTML parsing and sanitizing text in the context of HTML.

Many thanks to all the users and contributors of Bleach!

Where to go for more

For more specifics on this release, see here: https://bleach.readthedocs.io/en/latest/changes.html#version-6-4-0-june-5th-2026

Documentation and quickstart here: https://bleach.readthedocs.io/en/latest/

Source code and issue tracker here: https://github.com/mozilla/bleach/

Firefox Nightly

More Kit, More Control – These Weeks in Firefox: Issue 203

By Katherine Patenio on June 03, 2026 06:27 PM

Highlights

James enabled adaptive autofill in Nightly for testing, which we believe should provide better results in the URL bar when doing autocomplete!
Jack updated the illustrations shown on some of our error pages to match the latest approved designs, giving users more polished artwork when the browser encounters connection or security errors!

Controls for the Memories feature can now be set during Smart Window onboarding

We’ve disabled the CSS filter implicitly applied to WebExtension pageAction SVG icons across all release channels starting in Firefox 152, completing the deprecation
- NOTE: The blog post published at WebExtensions API changes in Firefox 149-152 provides to extensions developers more details about this deprecation and links to the related MDN docs.

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

Amin Amir
Pranjali Srivastava
Sam Johnson

New contributors (🌟 = first patch)

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

Fixed long-standing regression on the autocomplete and datalist popups for extension inline options pages on about:addons (introduced in Firefox 68 by Bug 1532724, fix shipping in Firefox 152) – Bug 1595158

WebExtensions Framework

Fixed access to web-accessible resources declared with <all_urls> from sandboxed documents (null-principal URLs), restoring extension redirects from the context-menu search flow, starting in Firefox 152 – Bug 2033905

WebExtension APIs

Added exhaustive test coverage for tabs.move() against additional edge cases related to split-view tabs – Bug 2029092

DevTools

Andreas Farre improved the Session History tab in the Application panel (still behind devtools.application.sessionHistory.enabled)
- added support for remote debugging (#2014064, #2016121)
- made sure that calls to History.replaceState are reflected in the UI (#2037359)
Julian Descottes [:jdescottes] fixed the most frequent DevTools crash we were observing in Telemetry, adding a guard against IDBTransaction errors when retrieving breakpoints in the Debugger (#2030260)
Nicolas Chevobbe [:nchevobbe] fixed the image preview tooltip for relative URLs images in constructed stylesheet (#2035503)
Julian Descottes [:jdescottes] reduced the overhead we had because of network requests monitoring by only decoding response content when the user actually want to see the response (#2026228)

WebDriver

Amin Amir cleaned up an incorrect variable assignment in our browsingContext module.
Logan Rosen updated stale references and broken links in our documentation about Marionette.
Sameem improved the Marionette and WebDriver BiDi screenshot commands to enforce maximum allowed dimensions.
Leo McArdle fixed the regression in the “log.entryAdded” event, which lacked an error message in the “text” field for the messages of type “error”.
Henrik Skupin fixed an issue in Marionette where WebDriver:Navigate and WebDriver:Refresh did not handle errors when the underlying navigation failed.
Henrik Skupin improved geckodriver to detect an early Firefox exit during startup on Android, avoiding up to 60 seconds of unnecessary connection attempts.
Henrik Skupin updated the geckodriver CI build job to produce a universal macOS binary supporting both x64 and aarch64.

Lint, Docs and Workflow

Sylvestre ported some linters (e.g. file-whitespace, test-manifest-toml, license, file-perm, rejected-words & more) to Rust to help improve the runtime of the code review bot.
Dale has been working on migration to moz-src for customkeys, dom/quota and odom/geolocation
- https://arewemozsrcyet.com/

New Tab Page

We did our first region-specific trainhop on May 11th (just 15% of the US), and turned on HNT Nova (and sometimes Widgets) for those clients to get some advance-data of its behaviour in the wild! A note that HNT Nova gets turned on for everybody when Firefox 151 ships on May 19th.
- We’ll be launching a similar experiment in the DE, probably on May 12th, also at 15% population.
Most of the team is heads down building out a sports-tracking widget, attempting to get that ready in time to be generally available for the upcoming World Cup event.
Dre landed a new world clock widget, which is currently off by default, but pretty snazzy!

Search and Urlbar

Nova (URL Bar Design Refresh)
- Drew and Daisuke continued their work on Nova styling for the Address bar (input and view).
Search and Suggest
- Drew finalized two bugs for World Cup and sports suggestions, which were landed and uplifted: one to update the localization string for scheduled games and another to show both teams’ icons in suggestions. Drew also landed and uplifted a fix for rich search suggestion icons being forced into a square aspect ratio.
- Standard8 updated Ecosia favicons to the latest branding, including QA testing and publishing.
Settings Redesign (SRD)
- Stephanie landed a test to ensure search suggestion settings are hidden when quicksuggest is disabled, as well as a patch to resolve TypeScript issues in search.mjs, and is adding test coverage to confirm removed search engines are not displayed in the default engines dropdown.
General URL Bar and Component Updates
- Daisuke landed implementation of the context menu on URL bar results, and a fix to show the loading URL in the URL bar when starting up with a homepage.
  - Marco is working on several tasks, including a PDF download / focus stealing issue and allowing arrays to be bound in Sqlite.sys.mjs. Marco also worked on fixes related to Places, such as avoiding replacing the favicons database if it is not corrupt.
- Standard8 finalized the URL bar test manifest split. Standard8 also upgraded us to TypeScript 6.
- Moritz landed a fix for URL bar abandonment telemetry being recorded when clicking an engine in the unified search button popup (Bug 2032973), which was also uplifted. Moritz also simplified search mode switcher item activation in tests, and made it so that the unified search button popup closes when installing an open search engine.

Smart Window

natural language starting with tab close/undo 2035343 with expandable action log 2031508

assistant rendering feedback up/down 2032994 and markdown table 2027029
nova styling blur 2027877 and suggestions 2026823
accessibility screen reader 2028676 and keyboard focus 2037565
optimize conversation starters extra requests 2030005 and caching 2033430

Storybook/Reusable Components/Acorn Design System

Nova token updates occasionally, focused on SRD

UX Fundamentals

Added support for the “SEC_ERROR_CA_CERT_INVALID” certificate error to the Felt Privacy error pages. – 2035942

Settings Redesign

Settings redesign is being tested and will hopefully go out in Firefox 152!

This Week In Rust

This Week in Rust 654

By TWiR Contributors on June 03, 2026 04:00 AM

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

Foundation

Help Fund the People Who Build Rust - The Rust Foundation

Official

Launching the Rust Foundation Maintainers Fund

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Research

Counterfactuals via the Causal Monad in Rust

Crate of the Week

This week's crate is remyx, a framework for building TUIs on top of Ratatui.

Thanks to Manuel Garcia de la Vega for the self-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.

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.

Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10

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

500 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

This week we saw nice wins across the board thanks to merging several compiler queries together (#155678), and also substantial improvements in doc performance thanks to doing less work when sorting trait impls (#157179).

Triage done by @Kobzol. Revision range: 783eb8c8..4804ad7e

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.7%]	14
Regressions ❌ (secondary)	0.4%	[0.1%, 0.9%]	39
Improvements ✅ (primary)	-0.9%	[-6.8%, -0.2%]	111
Improvements ✅ (secondary)	-1.1%	[-2.9%, -0.1%]	53
All ❌✅ (primary)	-0.8%	[-6.8%, 0.7%]	125

3 Regressions, 1 Improvement, 2 Mixed; 4 of them in rollups 35 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:

No RFCs were approved 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

Rust

Unsafe Code Guidelines

Can references to uninhabited types ever be valid?

No Items entered Final Comment Period this week for Rust RFCs, 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-06-03 - 2026-07-01 🦀

Virtual

2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust
- Indy.rs - with Social Distancing
2026-06-04 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg
- Rust Nürnberg online
2026-06-04 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
- Exploring FalkorDB - Learning to use a Graph Database in Rust
2026-06-06 | Virtual (Kampala, UG) | Rust Circle Meetup
- Rust Circle Meetup
2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Rust Deep Learning: First Sunday
2026-06-08 | Virtual (Cardiff, UK) | Rust and C++ Cardiff
- RustWeek Reflections
2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Second Tuesday
2026-06-09 | Virtual (London, UK) | Women in Rust
- 👋 Community Catch Up
2026-06-10 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-16 | Virtual (Washington, DC, US) | Rust DC
- Mid-month Rustful
2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Rust Study/Hack/Hang-out
2026-06-17 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- June, 2026 SRUG (Seattle Rust User Group) Meetup
2026-06-18 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Rust Deep Learning: Third Sunday
2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Fourth Tuesday
2026-06-23 | Virtual (London, UK) | Women in Rust
- Lunch & Learn: What the heck are monads - and how do we fake them in Rust
2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust
- Indy.rs - with Social Distancing

Africa

2026-06-09 | Johannesburg, ZA | Johannesburg Rust Meetup
- Rust by Example - Lifetimes

Europe

2026-06-03 | Dublin, IE | Rust Dublin
- Join us live and INPERSON for Rust 261
2026-06-03 | Girona, ES | Rust Girona
- Rust Girona Hack & Learn 06 2026
2026-06-10 | München, DE | Rust Munich
- Rust Munich 2026 / 2 - Hacking Evening
2026-06-11 | Switzerland, CH | PostTenebrasLab
- Rust Meetup Geneva
2026-06-12 - 2026-06-14 | Kraków, PL | Rustmeet
- Rustmeet
2026-06-16 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
- Interactive: Everything is Open Source
2026-06-16 | Milano, IT | Rust Language Milan
- Real-time planning in Rust: SolverForge & SERIO
2026-06-18 | Aarhus, DK | Rust Aarhus
- Talk Night at Danske Commodities
2026-06-23 | Paris, FR | Rust Paris
- Rust meetup #86
2026-06-25 | Berlin, DE | Rust Berlin
- Rust Berlin Talks: The next generation

North America

2026-06-04 | Chicago, IL, US | Chicago Rust Meetup
- Rust Happy Hour
2026-06-04 | Saint Louis, MO, US | STL Rust
- Testing, Coverage, Tracey & Mutations
2026-06-06 | Boston, MA, US | Boston Rust Meetup
- Boston Common Rust Lunch, June 6
2026-06-11 | Lehi, UT, US | Utah Rust
- Utah Rust June Meetup
2026-06-11 | Mountain View, CA, US | Hacker Dojo
- RUST MEETUP at HACKER DOJO
2026-06-11 | San Diego, CA, US | San Diego Rust
- San Diego Rust June Meetup - Back in person!
2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group
- Rust Hacking in Person
2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group
- Rust Hacking in Person
2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Rust Study/Hack/Hang-out
2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- June, 2026 SRUG (Seattle Rust User Group) Meetup
2026-06-24 | Austin, TX, US | Rust ATX
- Rust Lunch - Fareground
2026-06-24 | Los Angeles, CA, US | Rust Los Angeles
- Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies
2026-06-25 | Atlanta, GA, US | Rust Atlanta
- Rust-Atl
2026-06-26 | New York, NY, US | Rust NYC
- Rust NYC's Big Summer Social

Oceania

2026-06-25 | Melbourne, AU | Rust Melbourne
- Rust Melbourne June 2026

South America

2026-06-18 | Florianópolis, BR | Rust SC
- Rust Floripa

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

If memory safety bugs were Waldo (Wally): finding them in C programs is a "Where's Waldo?" game, and Rust's unsafe simplifies it to "Is this Waldo?"

– kornel on rust-users

Thanks to Moy2010 for the suggestion!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Script to find new contributors from bug list

The Rust Programming Language Blog

Launching the Rust Foundation Maintainers Fund

By Funding team on June 02, 2026 12:00 AM

If you want to financially support the development of Rust, please consider donating to the Rust Foundation Maintainers Fund.

A few months ago, the Rust Foundation announced the Rust Foundation Maintainers Fund (RFMF). Since then, the Rust Project has been closely cooperating with the Rust Foundation to determine how exactly this fund will be used to support Rust maintainers. This resulted in the acceptance of RFC #3931, which established the Funding team and the Maintainer in Residence program.

The primary goal of the Funding team is to ensure that maintainers who work on Rust and its toolchain will be properly supported. We will talk to Rust Project members to figure out their funding situation, meet Rust team leads to learn about their maintenance needs, approach companies to find opportunities for them to invest into Rust by supporting Rust maintainers, coordinate various funding efforts and ensure that the beneficial effects of funded maintenance are visibly promoted, with the help of the Content team.

Maintainer in Residence is a new program dedicated to financially supporting existing Rust Project maintainers¹. Each Maintainer in Residence will be funded to maintain one or more critical parts of Rust, such as the compiler, the standard library, Cargo, Clippy or one of many other projects that the Rust Project develops and maintains. The funded work will include activities such as performing large-scale refactorings, code reviews, unblocking new features, issue triaging, mentoring other contributors and more, and will be split between priorities guided by the teams they are supporting and priorities of their own choosing within the Project. Where applicable, Maintainers in Residence are also encouraged to propose, champion, and drive forward Rust Project Goals.

The goal of this program is to provide stable and long-term funding so that maintainers can focus on important work that ensures the long-term health of Rust. The funding team will select Maintainers in Residence based on funding availability and maintenance needs within the Rust Project, and help ensure that they are successful. We expect that this will usually be a (near) full-time position, but that will depend on the nature of the work and the area of maintenance.

This program extends our existing support for Rust maintainers, such as the program management program and the compiler-ops program. An important development is that we now have a centralized mechanism for gathering donations from both individuals and companies, and a dedicated team that will help direct those funds to specific maintainers. You can find more details about the funding team and the Maintainer in Residence program in the RFC.

We expect to hire the first Maintainer in Residence in the upcoming months and announce it on this blog, so stay tuned!

How to contribute funds

If you are an individual who wants to help Rust succeed and thrive, you can donate to the RFMF through GitHub Sponsors². Companies who would like to invest in better maintenance of Rust can also donate through GitHub Sponsors or they can contact the Rust Foundation directly.

The important thing is that all proceeds from this fund will be directly used to support Rust Project maintainers. We currently expect that to happen primarily through the Maintainer in Residence program, but it can also be done in the form of smaller-scale grants or other mechanisms, as determined by the Funding team. We will figure this out on the go, as this is also quite new for us.

We really appreciate each donation, however small, because with more money we can hire more maintainers to ensure that we can continue to develop Rust and that important improvements are not blocked on maintenance tasks. This is especially important at this time, where Rust is starting to get used more and more in the industry in various application areas, which increases the need for sustained maintenance. The importance of multiple funding sources is underscored by an unfortunate trend we currently observe, where key Rust maintainers are losing their funding for Rust work due to budget shifts. The Rust Foundation Maintainers Fund is designed to provide stable funding for Rust maintainers that is less dependent on sudden shifts in the job market and the IT industry.

As with most things, there is no one-size-fits-all solution, so there are multiple ways to support Rust financially. The RustNL Maintainers Team recently hired several Rust Project maintainers. Previously, we wrote about how you can support specific individuals working on Rust. And there are also Rust Project Goals in search of funding. We welcome all efforts that can help support Rust Project maintainers, who often do work that is near invisible and thankless, while at the same time incredibly important and necessary, on a volunteer basis.

Thank you for considering sponsoring the development and maintenance of Rust! You can find more information about funding Rust on our Funding page.

This program was inspired by the Developer in Residence concept used by the Python Software Foundation (PSF), with which we led several helpful discussions. Thank you, PSF! ↩
Note that the fact that GitHub Sponsors is currently enabled on the rustfoundation GitHub organization, and not the rust-lang organization, is an implementation detail that might change in the future. All donations raised on this Sponsors page will be routed to the Rust Foundation Maintainers Fund and will be spent on directly supporting Rust Project maintainers. ↩

Firefox Nightly

Backup for a Rainy Day – These Weeks in Firefox: Issue 202

By Mike Conley on June 01, 2026 06:15 PM

Highlights

The profile backup mechanism has been enabled by default for all desktop platforms in Nightly, as well as Beta! The current plan is to have this ride out to Firefox 151 for Windows, macOS and Linux on May 18th!
- This feature, when enabled, will create a copy of your profile data in the background and store it in a single file on your file system that you can restore from.
- You will be able to manage this feature in Settings under Sync (for now)
- You can read more about the feature here
As followups to the recent addition to the WebExtension tabs API to support the new SplitView tabs feature, tabs.group() and tabs.ungroup() have been fixed to work correctly with split view tabs, and fixed split views being prepended instead of appended to tab groups when adopted into a new window – Bug 2029099 / Bug 2029534
Adaptive autofill has been enabled on Nightly.
- Previously, autofill only completed domains (e.g. typing red autofilled reddit.com). Now it can also complete full URLs for pages you visit often (e.g. red → reddit.com/r/firefox), learning from what you actually click in the address bar. If a suggestion isn’t helpful, you can now dismiss it so autofill learns what not to show you too.
  - If you run into issues or have feedback, you can file a bug here!
Markus Stange [:mstange] implemented dynamic toolbar on top in RDM (#1978145), but also implemented some static skeleton UI so it’s closer to what we actually have in Firefox for Android
- dynamic toolbar is behind a pref: devtools.responsive.dynamicToolbar.enabled
- it can be put on top by setting devtools.responsive.dynamicToolbar.onTop, otherwise it’s at the bottom

Friends of the Firefox team

Resolved bugs (excluding employees)

Volunteers that fixed more than one bug

Amin Amir
aoia7rz7l
Chukwuka Rosemary
DrSeed
Frédéric Wang Nélar
japandi
John Iweh
jonathancabera
Josh Aas
Keji Bakare
kofoworola shonuyi
konyhéa
liz
Mathew Hodson
Okhuomon Ajayi
Oluwatobi
ROSHAAN
Sam Johnson

New contributors (🌟 = first patch)

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

In preparation for the Project Nova restyling of the about:addons page, we have refactored about:addons into separate per-component ES modules, splitting the monolithic aboutaddons.js and aboutaddons.html into 16 dedicated component files under components/ (with no behavior or UI changes) – Bug 2032014
- NOTE: if you have working on patches with changes to about:addons internals it is very likely you’ll need to rebase and solve merge conflicts hit on top of this refactoring, the internals are still largely the same as before but don’t hesitate to reach out to the Addons team if you have doubts / questions or need help to figure out how to adapt your patch of top of these changes

WebExtensions Framework

Fixed exportFunction to preserve the constructibility of the wrapped function instead of unconditionally making all exported functions implicitly as constructors – Bug 2033173
- Thanks to Gregory Pappas for contributing this improvement to the Content Scripts’ Xray Wrappers helpers!
Fixed a Firefox 151 regression where extension content scripts accessing location.ancestorOrigins caused subsequent page script reads of the same property to fail with “Permission denied”, breaking sites like Gmail – Bug 2034329
- Thanks to Simon Farre for promptly investigating and fixing this recent regression!

WebExtension APIs

Updated sessions.getRecentlyClosed() to remove the hardcoded cap when maxResults is omitted – Bug 1392125
- Shoutout to Amine Zroual for contributing this enhancement to the sessions WebExtensions API!

DevTools

Artem Manushenkov fixed an issue where autosuggestion popup was removing overridden indicators from properties in the Inspector (#1983408)
Andrea Marchesini [:baku] fix DevTools cookie header serialization for long cookies, which could lead to cookies not being visible in Netmonitor (#2031299)
Julian Descottes [:jdescottes] fixed a toolbox crash that was happening we couldn’t find a localization file (e.g. when using a language pack on Nightly) (#2028930)
Nicolas Chevobbe [:nchevobbe] improved @container tooltip so it show the value of variables used in style()(#2030239), has enough contrast in dark mode (#2033782) and contains a link to select the container (#2031688)
Hubert Boma Manilla (:bomsy) is making good progress on migrating the Console to CodeMirror 6 (#2032758, #2026569)

Fluent

We’re now at over 72% of our strings being Fluent! Got a component still using .properties? Convert when you can!

Migration Improvements

Thanks to dao for fixing a recent alignment issue in the migration wizard dropdown
Thanks to volunteer contributor Anthony Mclamb for his patch that disables the legacy EdgeHTML Edge migrator! Once that finishes rolling out, presuming no surprises, we’ll go ahead and remove the migrator entirely.

New Tab Page

Nova for New Tab has ridden the trains to Beta! It will be enabled by default, globally, when Firefox 151 goes out to release on May 19th
- It’s possible that we’ll do a train-hop coupled with an experiment to enable HNT Nova for a few clients a bit earlier.
Maxx Crawford enabled Nova designs for New Tab, rolling out the updated layout, widgets, and customization panel behind HNT Nova flags.
Maxx Crawford fixed the Nova content feed to render the intended four‑column layout by correcting CSS grid breakpoints.
Maxx Crawford resolved a first‑load failure in the Weather widget by fixing init order and fetch timing, eliminating the “Oops” error.
Maxx Crawford synchronized the Weather toggle between about:preferences#home and the panel via the shared showWeather pref to prevent desync.
Maxx Crawford updated Nova grid focus order to align tab flow with visual order for keyboard users.
Maxx Crawford fixed critical UI issues in Lists and Timer widgets covering overflow, controls, and layout stability.
Maxx Crawford guarded document.dir access in Nova render paths to avoid startup cache worker errors and improve startup stability.
Rolf added a new normalization method for the inferred interest vector to stabilize topic relevance across sessions.
Rolf prevented unnecessary content refreshes during Pocket New Tab experiments, reducing jank and bandwidth.
Sameeksha defined the Customize button’s expanded/collapsed state programmatically using aria-expanded for better a11y.
liz clarified follow/unfollow/blocked button names with topic context so screen readers announce clear actions.
Vector marked the Delete from History control as opening a dialog via aria-haspopup=dialog for assistive tech.
Scott Downe fixed a regression that flipped the Wallpapers pref off, restoring user selections.
Irene Ni corrected privacy link color and focus styles for contrast and keyboard visibility.
Reem Hamoui added a wallpaper toggle reset in the Nova customization panel so users can quickly restore default wallpapers without extra steps.
Reem Hamoui fixed the Customize pencil button to match the Nova spec, aligning placement and iconography for visual consistency.
Dre updated the ‘Fresh new’ wallpapers copy to a clearer, localized message for better comprehension.
Irene Ni fixed Nova privacy link color and focus styles to meet contrast and focus ring guidelines, improving accessibility on New Tab.
Irene Ni adjusted Sponsored tile character limits to prevent truncation/overflow, yielding cleaner titles across grid and wide tiles.
Scott Downe fixed a regression that flipped the Wallpapers user pref to false, restoring wallpapers for affected users and preventing unintended disablement.
Reem Hamoui hooked the wallpaper check into the new toggle logic so the Customization Panel accurately reflects wallpaper availability and state.
Irene Ni landed Nova UI updates for the Daily Briefing 3-pack card, improving spacing, type scale, and tap targets.
Reem Hamoui added a wallpaper toggle reset in the Nova customization panel so users can quickly restore default wallpapers without extra steps.
Reem Hamoui fixed the Customize pencil button to match the Nova spec, aligning placement and iconography for visual consistency.
Dre updated the ‘Fresh new’ wallpapers copy to a clearer, localized message for better comprehension.
Irene Ni fixed Nova privacy link color and focus styles to meet contrast and focus ring guidelines, improving accessibility on New Tab.
Irene Ni adjusted Sponsored tile character limits to prevent truncation/overflow, yielding cleaner titles across grid and wide tiles.
Scott Downe fixed a regression that flipped the Wallpapers user pref to false, restoring wallpapers for affected users and preventing unintended disablement.
Reem Hamoui hooked the wallpaper check into the new toggle logic so the Customization Panel accurately reflects wallpaper availability and state.
Irene Ni landed Nova UI updates for the Daily Briefing 3-pack card, improving spacing, type scale, and tap targets.

Search and Urlbar

Marco has fixed a couple of issues with the places databases to try and improve stability. This should help with avoiding users losing bookmarks or favicons.
Work continues on the new separate search bar to improve the functionality, e.g. allowing middle click to perform a search in a new tab, avoiding performing a search when adding a search engine.
Work also continues on the new Nova layouts.

Smart Window

uplifted 10 bugs to 150.0.1 dot release addressing initial user feedback from diary study and Connect
- jump to bottom of conversation 2028692
- stop streaming button 2029204
- back/forward navigation from assistant 2029229
- dark mode for various chips 2024499
search engine switching from smart bar 2021973
Nova styling within smart window 2026794

Storybook/Reusable Components/Acorn Design System

Dustin converted moz-breadcrumb-group variables into JSON design tokens Bug 2029181 – Convert moz-breadcrumb-group variables into JSON design tokens
Dustin converted moz-box-* variables into JSON design tokens Bug 2029180 – Convert moz-box-* variables into JSON design tokens
Dustin converted moz-promo variables to JSON design tokens Bug 2029190 – Convert moz-promo variables into JSON design tokens
Dustin converted moz-reorderable-list variables to JSON design tokens Bug 2029191 – Convert moz-reorderable-list variables into JSON design tokens
Dustin converted moz-visual-picker variables to JSON design tokens Bug 2029193 – Convert moz-visual-picker-item variables into JSON design tokens
Dustin updated browser-shared.css so it passes use-design-tokens Bug 2022985 – Update browser-shared.css so it passes use-design-tokens
Dustin updated popup.css so it passes use-design-tokens Bug 2022979 – Update popup.css so it passes use-design-tokens
Jon added opacity tokens and added opacity to use-design-tokens stylelint rule Bug 1955325 – Create opacity tokens
Jon converted toolbar design tokens to JSON Bug 2017970 – Convert toolbar design tokens to json
Anna fixed moz-select with panel-list drop-down size inconsistency Bug 2032365 – Applications Action drop-down menus sometimes have a different size when opened
Anna fixed issue with the disabled state of moz-radio component Bug 2027123 – moz-radio disabled state cannot be changed while the moz-radio-group is disabled
Anna updated moz-button and moz-box-button components to prevent label corruption when accesskeys are present and the label changes. Bug 2022326 – moz-button with accesskey label becomes corrupted when l10nId updates dynamically

UX Fundamentals

The error pages shown when a server sends back an invalid response header or an unsupported content encoding now display accurate, context-specific messages. The invalid response header page also gained a helpful list of next steps. – 2027209
In progress: The error page illustrations are being replaced with new artwork, and the system now supports per-illustration size configuration, giving each image the ability to define its own appropriate dimensions. – 2031837

Settings Redesign

Tim converted settings related to Accessibility page to config-based pane Bug 1968116 – Convert settings related to Accessibility page to config-based settings
Benjamin converted Privacy & Security page to the config-based pane Bug 1968112 – Convert settings related to Privacy & Security page to config-based settings
Finn integrated Firefox Labs page into setting-pane config Bug 2021047 – Integrate Firefox Labs page into setting-pane config
Anna converted Firefox Updates section to config-based prefs Bug 1990961 – Convert Firefox Updates section to config-based prefs
Mark Kennedy added moz-promo, that is welcoming users to the redesigned settings Bug 2015093 – Add a moz-promo to welcome users to the redesign
Anna added possibility to search for actions in the redesigned “Applications” section Bug 2020370 – It’s no longer possible to search for actions in the new “Applications” section
Anna fixed the Settings navbar layout breakage

Tom Ritter

webgl renderer privacy

By Tom Ritter on June 01, 2026 05:36 PM

WebGL exposes the details of your graphics hardware (specifically, the string that describes the rendering engine) in 2 ways. There are three levels of protection that browsers have taken to protect this data.

gl.getParameter(gl.VENDOR) and gl.getParameter(gl.RENDERER) - these are the 'simple' names. At some point in the past, someone argued that it wasn't enough information, and therefore we have a second API
let ext = gl.getExtension('WEBGL_debug_renderer_info'); and then gl.getParameter(ext.UNMASKED_VENDOR_WEBGL) and gl.getParameter(ext.UNMASKED_RENDERER_WEBGL)

The unmasked values are intended to be the more detailed ones, so always make sure you're comparing apples to apples. Another axis is that WebGL can render with Hardware or Software. This isn't a guarentee which one you'll get, but you can hint towards one or the other and the browser may or may not respect it. Here are your values:

Alright, now let's talk about what browsers do about it. There's no point in talking about Vendor, Renderer, and Unmasked Vendor - they don't really show as much detailed info, it's all about Unmasked Renderer. There are three levels:

Give a constant value. (Or don't return anything at all.)
'Round' the values into buckets
Give the exact value back

Safari and Tor Browser give constant values.

Firefox 'rounds'.

Chrome (and Brave, and I assume all-ish other Chrome-based browsers) give the exact value.

Firefox actually is purusing constant values, this week. I wrote this document for our QA team to test it. (You can get a sense of the internal sausage making it takes to launch a privacy feature from it.) I don't know if you can see the dates but I made it May 20th. The problem is this - websites use this data legitimately to adjust behavior so that users get the best experience possible. I found one example where they detect a buggy graphics stack; and a couple of examples where they adjust rendering so things are more performant for users with lower end machines - a problem Apple has less to worry about because they only support certain machine models!

A common response to this seems to be ambivalence, and I would suggest that is a bit elitist. Yes, if you're caring about the details reveal by a particular Web API you probably have a computer where you don't need to worry, but making the web work well for everyone is important for equitable access to improving everyone's human condition.

We have been bucketing WebGL Renderer since 2021. While many of our (supported, on-by-default) fingerprinting protections are part of Enhanced Tracking Protection - rolling out first in PBM/ETP Strict before making it to ETP Standard/Normal Browsing Mode - the bucketing is on by default, for everyone, and is not disabled if ETP is disabled.

How much of a difference does it make? A lot! Here is the distribution of the raw values. 83,705 distinct values.

WebGL Renderer Value Distribution, before bucketing

Compare that to the bucketed data. 131 distinct values.

WebGL Renderer Value Distribution, after bucketing

Now this data is from Firefox, so I cant say conclusively what the distribution of data is in other browsers, but... yeah. To claim Chrome (of all browsers!) is doing this better than us is pure FUD. We're making a big impact in how fingerprintable you are today and we're trying to improve it even further.

Nick Fitzgerald

A Structure-Aware Fuzzing Experiment

By Nick Fitzgerald on June 01, 2026 07:00 AM

Structure-aware fuzzing can better exercise the system under test (SUT) by crafting inputs in the format expected by the SUT, rather than throwing pseudorandom bytes against it. That is, it avoids “shallow” inputs that the SUT will reject early (for example, syntactically invalid source text when fuzzing a programming language’s compiler) and only produces inputs that go “deep” into the SUT (e.g. programs that type-check and exercise the mid-end optimizer and backend code generator). The Rust fuzzing ecosystem is largely built around cargo-fuzz and the libfuzzer-sys crate, which provides two methods for structure-aware fuzzing:

Generating structured inputs from scratch with the arbitrary crate
Mutating existing inputs from the fuzzer’s corpus in a structure-aware manner, thereby producing new structured inputs, via the fuzz_mutator! hook

While the two methods are not technically mutually exclusive, combining the two can be difficult and engineering resources are finite. So:

If we are only implementing one approach, is generation or mutation better?

To help answer this question, I implemented structure-aware generation and mutation of guaranteed-valid WebAssembly (Wasm) instruction sequences. This task is small enough to be easily understandable but large enough and real enough to (hopefully) be representative and applicable to other domains, or, at the very least, interesting.¹ To evaluate their effectiveness, I used Wasmtime as the SUT, libfuzzer-sys as the fuzzing engine driving everything, and then compared code coverage over time when using mutation-based fuzzing versus generation-based fuzzing.

Additionally, there are many ways we can generate pseudorandom WebAssembly instruction sequences. In this experiment, I’ve evaluated three methods:

Unconstrained instruction sequence generation followed by a fixup pass to ensure validity
Generating valid instructions in a forwards, bottom-up manner (from operands to operators)
Generating valid instructions in a backwards, top-down manner (from operators to operands)

In contrast, while there are surely many ways to mutate a given WebAssembly instruction sequence into a new, valid instruction sequence, I’ve only implemented one method: perform an arbitrary instruction insertion, deletion, or replacement, producing a new but probably-invalid instruction sequence, and then run the same fixup pass mentioned previously to ensure validity. This is the direct mutation-based equivalent of the first generation-based method.

Before continuing further, I want to disclose that I am the author of wasm-smith and mutatis, and a maintainer of Wasmtime, arbitrary, libfuzzer-sys, and cargo-fuzz. That is, while I am familiar with Wasm, fuzzing, fuzzing Wasm, and both the arbitrary and mutatis crates, I may also be propagating my own biases into these implementations.

Background

Generation-Based and Mutation-Based Fuzzing

A generation-based fuzzer uses a generator to create a pseudo-random test cases from scratch, feeds these into the system under test, and reports any failures to the user:

fn generation_based_fuzzing<T>(
    // A test-case generator.
    generator: impl Fn() -> T,
    // A function to run the system under test with a
    // generated test case, returning a result that
    // describes whether the run was successful or
    // not.
    run_system_under_test: impl Fn(&T) -> FuzzResult,
) {
    loop {
        // Generate an input.
        let input = generator();

        // Run the input through the system under test.
        let result = run_system_under_test(&input);

        // If the system crashed, panicked, failed an
        // assertion, violated an invariant, or etc...
        // then report that to the user.
        if let Err(failure) = result {
            report_to_user(&input, failure);
        }
    }
}

On the other hand, mutation-based fuzzers are given an initial corpus of inputs and create new inputs by mutating existing corpus members. They run each new input through the SUT, report failures the same as before, and if the new input was “interesting” (for example, exercised new code paths in the SUT that weren’t previously covered in any other input’s execution) then the new input is added into the corpus for use in future test iterations:

fn mutation_based_fuzzing<T>(
    // A corpus of test cases.
    corpus: &mut Corpus<T>,
    // A function to pseudo-randomly mutate an existing
    // input into a new input.
    mutate: impl Fn(&T) -> T,
    // A function to run an input in the system under
    // test, returning a result that describes whether
    // the run was successful or not.
    run_system_under_test: impl Fn(&T) -> FuzzResult,
) {
    loop {
        // Choose an old test case from the corpus.
        let old_input = corpus.choose_one();

        // Pseudo-randomly mutate that old test case,
        // creating a new one.
        let input = mutate(old_input);

        // Run the input through the system under test.
        let result = run_system_under_test(&input);

        // If the system crashed, panicked, failed an
        // assertion, violated an invariant, or etc...
        // then report that to the user.
        if let Err(failure) = result {
            report_to_user(&input, failure);
        }

        // If the input was interesting, for example if
        // it executed previously-unknown code paths,
        // then add it into the corpus for use in a
        // future iteration.
        if result.input_was_interesting() {
            corpus.insert(input);
        }
    }
}

The two approaches are not mutually exclusive and hybrid generation- and mutation-based fuzzers exist.

More resources:

Structure-Aware Fuzzing

Structure-unaware fuzzing will generate pseudorandom byte sequences and pass them directly to the SUT. If the SUT expects some sort of structured input, e.g. the source text for a programming language, it is likely that these byte sequences are invalid and will be rejected early by the SUT’s frontend. For example, when fuzzing a compiler, the input is rejected as syntactically invalid by the parser or rejected as semantically invalid by the type checker. This can be useful when hardening a tokenizer, parser, or type checker, but is less useful when hunting for misoptimization in the mid-end or bad instruction encoding in the backend because the inputs are unlikely to make it that far through the compiler’s pipeline.

Structure-aware fuzzing will produce inputs that match the SUT’s expected input format. Returning to the compiler-fuzzing example, structure-aware fuzzing lets us generate valid programs for the compiler, so we can exercise more of the mid-end and backend, rather than just the frontend.

Structure-aware fuzzing is often generation-based: for example using grammar-based fuzzing to generate pseudorandom strings from a given language grammar or language-specific tools like csmith and wasm-smith that generate C and WebAssembly programs respectively. But structure-aware fuzzing can also be mutation-based: libFuzzer’s custom mutator example implements a structure-aware mutator for zlib-compressed strings, where the raw input is decompressed, the decompressed data is mutated, and then the mutated data is recompressed to provide the new raw input. The mutator is aware of the SUT’s zlib-compressed input structure.

More resources:

The `arbitrary` Crate

The arbitrary crate helps Rust developers write custom structure-aware generators for fuzzing. It provides building blocks and abstractions for translating a raw byte sequence (usually from a fuzzing engine) into a structured type, effectively interpreting the raw bytes as a “DNA string” or set of predetermined choices for its decision tree. The library also provides a derive(Arbitrary) macro to automatically implement its functionality for a given type.

Because arbitrary is effectively implemented by combining decision trees, it is extremely easy to create imbalanced trees and unintentionally bias the distribution of generated test cases.

The `mutatis` Crate

The mutatis crate is, at a high-level, performing the same role for authoring structure-aware mutators that arbitrary plays for generators. That is, it provides Rust developers with abstractions and combinators for creating custom structure-aware mutators. It also provides a derive(Mutate) macro to automatically implement its functionality for a given type.

mutatis is designed to resist bias via a two-phase design: first, it enumerates all of the candidate mutations that could be applied to a test case, and only afterwards chooses a particular random mutation from the candidate set to actually apply.

WebAssembly

WebAssembly is a virtual instruction set designed to be safe, portable, and fast. It is a stack machine where an instruction’s operands are popped off a stack during execution and results pushed. It has sandboxed linear memories, global variables, and local variables (the latter two effectively being two kinds of virtual registers). The following instruction sequence computes a * 3 and stores the result into memory at address p:

;; []
local.get $p
;; [p]
local.get $a
;; [p, a]
i32.const 3
;; [p, a, 3]
i32.mul
;; [p, a*3]
i32.store
;; []

Generator and Mutator Implementation

The range of all three generators and the mutator is the same universe of WebAssembly programs. They are all implemented on top of the same Module and Inst types, and, given enough time, none is capable of producing an instruction sequence that another cannot. This helps ensure that our comparison is apples-to-apples. However, due to their different implementation techniques, they do produce different distributions of WebAssembly programs within that universe, and produce test cases at different speeds from one another, which ultimately affects how efficiently they exercise the SUT.

All of the generators are built on top of the arbitrary crate. The mutator is built on top of the mutatis crate.

The Module type is our structured fuzzing input. It describes a WebAssembly module containing a variable number of linear memories, a variable number and type of globals, and one function with a variable number and type of parameters and results and a variable instruction sequence:

/// A WebAssembly module of the shape:
///
///     (module
///       (memory ...)
///       (memory ...)
///       ...
///
///       (global ...)
///       (global ...)
///       ...
///
///       (func (export "run") (param ...) (result ...)
///         ...
///       )
///     )
pub struct Module {
    num_memories: u32,
    globals: Vec<Global>,
    param_types: Vec<ValType>,
    result_types: Vec<ValType>,
    instructions: Vec<Inst>,
}

The Inst type is an enum of all the WebAssembly instructions the implementations support, which is all of the integer, float, SIMD, memory, local, and global instructions. Control-flow, threading, table, and GC instructions are not supported. Here is a subset of Inst’s definition:

/// A WebAssembly instruction.
pub enum Inst {
    Drop,
    LocalGet(u32),
    GlobalGet(u32),

    // ...

    I32Const(i32),
    I32Add,
    I32Sub,
    I32Mul,

    // ...

    I64Const(i64),
    I64Add,
    I64Sub,
    I64Mul,

    // ...

    F32Const(f32),
    F32Add,
    F32Sub,
    F32Mul,

    // ...

    F64Const(f64),
    F64Add,
    F64Sub,
    F64Mul,

    // ...

    I32WrapI64,
    I64ExtendI32S,
    I64ExtendI32U,

    // ...

    V128Const(i128),
    I8x16Add,
    I8x16Sub,

    // ...

    I32Load(u32),
    I64Load(u32),

    // ...

    I32Store(u32),
    I64Store(u32),

    // ...

    MemorySize(u32),
    MemoryGrow(u32),
}

There is an Inst::operand_types method that returns the types that the instruction pops from the stack, and an Inst::result_type method that returns the type of the value that the instruction pushes onto the stack, if any. Finally, the Module::to_wasm_binary method encodes the module into WebAssembly’s binary format, so it can be fed into Wasmtime. These methods are used, directly or indirectly, in every generator and mutator implementation.

`arb`

The arb generator leverages derive(arbitrary::Arbitrary) on our structured input types to generate a pseudorandom instance of Module, unconstrained by validity. The module’s instruction sequence is almost certainly not valid at this point: it likely is missing operands for instructions, producing more results than the function’s signature describes, producing results of types that don’t match the function signature, accessing globals and locals that don’t exist, etc… Having produced an instance of Module, it next calls the Module::fixup method to mutate the Module so that it is valid.

The fixup method works by abstractly interpreting the instruction sequence to track the types of each value on the stack at every program point. Whenever an instruction’s operand types don’t match the types on top of the stack, it generates dummy values of the correct type. When the instructions produce more values than the function’s signature proscribes, it emits drop instructions.

impl Module {
    pub fn fixup(&mut self, mut make_value: impl FnMut() -> i64) {
        // ...

        // The fixed-up instructions.
        let mut fixed = Vec::with_capacity(
            self.instructions.len(),
        );

        // The types on the stack at any given program
        // point. Similar to the Wasm spec's appendix's
        // validation algorithm.
        let mut stack: Vec<ValType> = Vec::new();

        for inst in mem::take(&mut self.instructions) {
            // Special-case `drop` because it is
            // polymorphic.
            if matches!(inst, Inst::Drop) {
                if stack.is_empty() {
                    fixed.push(
                        ValType::I32.make_const(make_value()),
                    );
                } else {
                    stack.pop();
                }
                fixed.push(inst);
                continue;
            }

            // First clamp entity indices to valid
            // ranges.
            let Some(inst) = self.fixup_inst_immediates(
                &mut make_value,
                has_mutable_global,
                inst,
            ) else {
                continue
            };

            // Then make sure that the stack has
            // operands of the correct types for this
            // instruction.
            self.fixup_stack(
                &mut make_value,
                &mut fixed,
                &mut stack,
                &inst,
            );

            // Finally, apply the effects to the stack.
            let len_operands = inst.operand_types(
                &self.globals,
            ).len();
            stack.truncate(stack.len() - len_operands);
            stack.extend(inst.result_type(
                &self.param_types,
                &self.globals,
            ));

            fixed.push(inst);
        }

        // ...

        self.instructions = fixed;
    }

    fn fixup_stack(
        &mut self,
        mut make_value: impl FnMut() -> i64,
        fixed: &mut Vec<Inst>,
        stack: &mut Vec<ValType>,
        inst: &Inst,
    ) {
        let needed = inst.operand_types(&self.globals);
        let n = needed.len();

        if stack.len() >= n {
            if (0..n).all(|i| {
                stack[stack.len() - n + i] == needed[i]
            }) {
                // All needed operands are on the stack.
                return;
            }
        } else {
            if stack.iter().enumerate().all(|(i, ty)| {
                *ty == needed[i]
            }) {
                // A prefix of needed operands are on the
                // stack; make constants for the tail that
                // are missing.
                for ty in &needed[stack.len()..] {
                    fixed.push(ty.make_const(make_value()));
                    stack.push(*ty);
                }
                return;
            }
        }

        // Otherwise, just make constants for all the
        // needed operands.
        for ty in needed {
            fixed.push(ty.make_const(make_value()));
            stack.push(*ty);
        }
    }

    // ...
}

The fixup method also makes sure that for all instructions that have an immediate referencing some entity, the referenced entity is valid. For example, for a local.get $l instruction, it ensures that local $l actually exists or else rewrites the local to one that does exist.

impl Module {
    // ...

    fn fixup_inst_immediates(
        &mut self,
        mut make_value: impl FnMut() -> i64,
        has_mutable_global: bool,
        mut inst: Inst,
    ) -> Option<Inst> {
        match &mut inst {
            Inst::LocalGet(l) => *l %= self.param_types.len() as u32,

            // ...

            Inst::I32Load(m)
            | Inst::I64Load(m)
            | Inst::F32Load(m)
            | Inst::F64Load(m)
            | Inst::V128Load(m) => {
                if self.num_memories == 0 {
                    return None;
                }
                *m %= self.num_memories;
            }

            // ...

            _ => {}
        }

        Some(inst)
    }
}

After calling fixup, the arb generator invokes Module::to_wasm_binary to get the encoded Wasm program.

`bottom_up`

The bottom_up generator also uses abstract interpretation to track the types of values on the stack. It generates instructions in forwards order, from operands to operators. It begins with an empty stack, filters candidate instructions down to just those that would be valid given the types currently on the stack, randomly chooses one, updates the stack types accordingly, and repeats the process. This is the same approach that wasm-smith uses. After generating instructions this way, it then makes sure that the final types on the stack match the function signature’s results, similar to the end of fixup.

impl Module {
    pub fn bottom_up(u: &mut Unstructured<'_>) -> Result<Self> {
        // ...

        let max_insts = u.int_in_range(1..=MAX_INSTS)?;
        let mut instructions = Vec::new();
        let mut stack: Vec<ValType> = Vec::new();

        for _ in 0..max_insts {
            if stack == result_types && u.ratio(3, 4)? {
                break;
            }

            // Choose a random instruction whose operand
            // types match those currently on the stack.
            let inst = choose_inst_bottom_up(
                u,
                &stack,
                &param_types,
                &globals,
                num_memories,
            )?;

            // Apply this instruction's effects to the
            // stack.
            apply_inst(
                &inst,
                &mut stack,
                &param_types,
                &globals,
            );
            instructions.push(inst);
        }

        // ...

        Ok(Module {
            param_types,
            result_types,
            globals,
            num_memories,
            instructions,
        })
    }
}

fn choose_inst_bottom_up(
    u: &mut Unstructured<'_>,
    stack: &[ValType],
    param_types: &[ValType],
    globals: &[Global],
    num_memories: u32,
) -> Result<Inst> {
    // Build up all the valid candidate instructions.
    let mut candidates: Vec<Inst> = Vec::new();

    // Producers are always okay: [] -> [t]
    candidates.push(Inst::I32Const(0));
    candidates.push(Inst::I64Const(0));
    candidates.push(Inst::F32Const(0.0));
    candidates.push(Inst::F64Const(0.0));
    candidates.push(Inst::V128Const(0));
    if !param_types.is_empty() {
        candidates.push(Inst::LocalGet(0));
    }

    // ...

    let top = stack.last().copied();
    let second = stack.get(stack.len() - 2).copied();

    // Drop needs 1 operand of any type: [t] -> []
    if top.is_some() {
        candidates.push(Inst::Drop);
    }

    // i32 unary: [i32] -> [...]
    if top == Some(I32) {
        candidates.push(Inst::I32Clz);
        candidates.push(Inst::I32Ctz);
        candidates.push(Inst::I32Popcnt);
        // ...
    }

    // i64 unary: [i64] -> [...]
    if top == Some(I64) {
        candidates.push(Inst::I64Clz);
        candidates.push(Inst::I64Ctz);
        candidates.push(Inst::I64Popcnt);
        // ...
    }

    // ...

    // i32 binary: [i32 i32] -> [...]
    if top == Some(I32) && second == Some(I32) {
        candidates.push(Inst::I32Add);
        candidates.push(Inst::I32Sub);
        candidates.push(Inst::I32Mul);
        // ...
    }

    // i64 binary: [i64 i64] -> [...]
    if top == Some(I64) && second == Some(I64) {
        candidates.push(Inst::I64Add);
        candidates.push(Inst::I64Sub);
        candidates.push(Inst::I64Mul);
        // ...
    }

    // ...

    // Choose a random instruction from the
    // candidates.
    let mut inst = *u.choose(&candidates)?;

    // If the instruction has immediates, generate
    // them here, as they were hard-coded during
    // candidate selection.
    match &mut inst {
        Inst::I32Const(v) => *v = u.arbitrary()?,
        Inst::I64Const(v) => *v = u.arbitrary()?,
        // ...
        Inst::GlobalGet(g) => {
            *g = u.int_in_range(0..=(globals.len() as u32 - 1))?;
        }
        // ...
        Inst::I32Load(m)
        | Inst::I64Load(m)
        | Inst::F32Load(m)
        | Inst::F64Load(m)
        | Inst::V128Load(m)
        | Inst::I32Store(m)
        | Inst::I64Store(m)
        | Inst::F32Store(m)
        | Inst::F64Store(m)
        | Inst::V128Store(m)
        | Inst::MemorySize(m)
        | Inst::MemoryGrow(m) => {
            *m = u.int_in_range(0..=(num_memories - 1))?;
        }
        _ => {}
    }

    Ok(inst)
}

After constructing a Module via bottom_up, we don’t need to call fixup because the module is already valid by construction, so all that’s left is invoking Module::to_wasm_binary to get the encoded Wasm program.

`top_down`

The top_down generator is very similar to bottom_up, but instead of generating instructions forwards, from operands to operators, it generates them backwards, from operators to operands. Instead of maintaining a stack of the types of values generated thus far by the instruction sequence prefix, it maintains a stack of the types of values expected by the instruction sequence suffix. This is the approach that rgfuzz by Park, Kim, and Yun takes.²

impl Module {
    pub fn top_down(
        u: &mut Unstructured<'_>,
    ) -> Result<Self> {
        // ...

        let max_insts = u.int_in_range(1..=MAX_INSTS)?;
        let mut instructions = Vec::new();
        let mut needed = result_types.clone();
        for _ in 0..max_insts {
            if needed.is_empty() && u.ratio(3, 4)? {
                break;
            }

            // Choose a random instruction in a
            // top-down manner.
            let inst = choose_inst_top_down(
                u,
                needed.last().copied(),
                &param_types,
                &globals,
                num_memories,
            )?;

            // Pop the result type from `needed`, if
            // any, as it's been satisfied.
            let ty = inst.result_type(
                &param_types,
                &globals,
            );
            if ty == needed.last().copied() {
                needed.pop();
            }

            // Add operand type demands.
            match &inst {
                Inst::Drop => {
                    // `drop` is polymorphic; choose
                    // a random type.
                    needed.push(u.arbitrary()?);
                }
                Inst::GlobalSet(g) => {
                    needed.push(globals[*g as usize].ty);
                }
                _ => {
                    needed.extend_from_slice(
                        inst.operand_types(&globals),
                    );
                }
            }

            instructions.push(inst);
        }

        // Fill remaining needed types with
        // constants.
        for ty in needed.iter().rev() {
            instructions.push(
                ty.make_const(u.arbitrary()?),
            );
        }

        // Instructions were generated backwards, so
        // reverse.
        instructions.reverse();

        Ok(Module {
            param_types,
            result_types,
            globals,
            num_memories,
            instructions: prefix,
        })
    }
}

fn choose_inst_top_down(
    u: &mut Unstructured<'_>,
    target_ty: Option<ValType>,
    param_types: &[ValType],
    globals: &[Global],
    num_memories: u32,
) -> Result<Inst> {
    let mut candidates: Vec<Inst> = Vec::new();
    match target_ty {
        Some(I32) => {
            candidates.push(Inst::I32Const(0));
            candidates.push(Inst::I32Add);
            candidates.push(Inst::I32Sub);
            candidates.push(Inst::I32Mul);
            // ...
        }
        Some(I64) => {
            candidates.push(Inst::I64Const(0));
            candidates.push(Inst::I64Add);
            candidates.push(Inst::I64Sub);
            candidates.push(Inst::I64Mul);
            // ...
        }
        Some(F32) => {
            candidates.push(Inst::F32Const(0.0));
            candidates.push(Inst::F32Add);
            candidates.push(Inst::F32Sub);
            candidates.push(Inst::F32Mul);
            // ...
        }
        // ...
        None => {
            // Nothing needed. `drop`, `global.set`, and
            // stores add demand.
            candidates.push(Inst::Drop);
            if globals.iter().any(|g| g.mutable) {
                candidates.push(Inst::GlobalSet(0));
            }
            if num_memories > 0 {
                candidates.push(Inst::I32Store(0));
                // ...
            }
        }
    }

    let mut inst = *u.choose(&candidates)?;

    // If the instruction has immediates, generate
    // them here, as they were hard-coded during
    // candidate selection. Same as `bottom_up`.
    match &mut inst {
        // ...
    }

    Ok(inst)
}

Similar to bottom_up, after we’ve constructed a Module via top_down, we don’t need to call fixup because the module is already valid by construction. All that’s left is invoking Module::to_wasm_binary to get the encoded Wasm program.

`mutate`

mutate is, as the name implies, a mutator rather than a generator. It is the direct equivalent of the arb generator, but for mutation: it uses derive(mutatis::Mutate) on Module and Inst to automatically generate custom mutators for these types, rather than authoring them by hand. After producing a new Module by mutating an old Module, that new Module probably represents an invalid Wasm program, in the same way that derive(arbitrary::Arbitrary) produces Modules that are probably invalid. And mutate also uses the same approach that arb does to resolve this problem: the fixup method.

But first, a mutator-specific wrinkle is that fuzz_mutator! gives us a mutable byte slice to mutate, not a Module. We address this gap by deriving the serde crate’s Serialize and Deserialize traits on Module and Inst, deserializing a Module from the mutable byte slice, mutating that deserialized Module with mutatis, and then reserializing it back into the mutable byte slice. We use the postcard crate here, but could just as easily use bincode, JSON, or protobuf.

use libfuzzer_sys::{fuzz_mutator, fuzz_target, fuzzer_mutate};

fuzz_mutator!(|
    data: &mut [u8],
    size: usize,
    max_size: usize,
    seed: u32,
| {
    // With probability of about 1/8, use default
    // mutator.
    if seed.count_ones() % 8 == 0 {
        return fuzzer_mutate(data, size, max_size);
    }

    // Try to decode using postcard; fallback to
    // default input on failure.
    let mut module: Module =
        postcard::from_bytes(&data[..size])
            .ok()
            .unwrap_or_default();

    // Mutate with `mutatis`.
    let mut session = mutatis::Session::new()
        .seed(seed.into())
        .shrink(max_size < size);
    if session.mutate(&mut module).is_ok() {
        if let Ok(encoded) = postcard::to_slice(
            &module,
            data,
        ) {
            return encoded.len();
        }
    }

    // Fallback to the default libfuzzer mutator if
    // serialization or mutation fails because, for
    // example, `data` doesn't have enough capacity.
    fuzzer_mutate(data, size, max_size)
});

Finally, the fuzz target itself deserializes the Module from the raw bytes, calls fixup, encodes it to a Wasm binary via Module::to_wasm_binary, and then passes that into Wasmtime.

fuzz_target!(|data: &[u8]| {
    let Ok(mut module) = postcard::from_bytes::<Module>(data) else {
        return;
    };
    module.fixup(|| 0);
    let wasm = module.to_wasm_binary();

    // ...
});

Benchmarking

Methodology

We pair each of our generators and mutator with libfuzzer-sys and feed the resulting test cases into Wasmtime. All fuzzers start with an empty corpus.

The most important metric for a fuzzer is its bug-finding ability, but that can be difficult to measure directly. For example, Wasmtime is actively fuzzed 24/7 with more-complete fuzzers than those implemented here, so, as expected, I have not found any bugs via these benchmarks. Therefore, instead of reporting a found-bugs count, the benchmark harness reports two alternative metrics:

Coverage over time: Coverage is the cumulative code paths exercised by the fuzzer. A fuzzer cannot find bugs in code paths it does not cover. This is the most important metric reported.
Executions over time: An execution is one iteration of the fuzzing loop. This is basically measuring how fast the fuzzer can produce test cases. All else being equal, more executions is better, but all else is rarely equal. It is easy to generate poor test cases very quickly: just return an empty sequence of Wasm instructions every time. Unfortunately, that exclusively leads to useless executions. Therefore, this metric is really only useful when comparing two implementations of the same algorithm, and I’ve omitted its results in the next section.

Additionally, I report results for both 24 hours of fuzzing and 5 minutes of fuzzing. The expected behavior of long-term fuzzing, e.g. 24/7 fuzzing in OSS-Fuzz, can be extrapolated from the 24-hour results. The 5-minute results show the expected behavior of short-term fuzzing, e.g. when using mutatis::check or arbtest.

Discussion of short-term fuzzing is somewhat rare, so I feel its motivation deserves explanation. I find short-term fuzzing useful in the following scenarios, for example:

Running a quick fuzzing session locally, to catch bugs that avoid detection in the traditional unit- and integration-test suites, before opening a pull request.
Running some quick fuzzing in CI before allowing a pull request to merge, for similar reasons.

That is, short-term fuzzing is useful for the same reasons and in the same scenarios as property-based testing.³

As recommended in Evaluating Fuzz Testing by Klees, Ruef, Cooper, Wei, and Hicks and adopted in Fuzz Bench: An Open Fuzzer Benchmarking Platform and Service by Metzman, Szekeres, Simon, Sprabery, and Arya, the benchmark harness tests the statistical significance of its results with a Mann-Whitney U-test. The harness performs 20 trials per fuzzer, the same number of trials as Fuzz Bench.

Results

24 Hours of Fuzzing

arb has 1.00 ± 0.00 times more coverage than bottom_up (p = 0.01)
mutate has 1.01 ± 0.00 times more coverage than arb (p = 0.00)
top_down has 1.00 ± 0.00 times more coverage than arb (p = 0.00)
mutate has 1.02 ± 0.00 times more coverage than bottom_up (p = 0.00)
top_down has 1.01 ± 0.00 times more coverage than bottom_up (p = 0.00)
mutate has 1.01 ± 0.00 times more coverage than top_down (p = 0.00)

5 Minutes of Fuzzing

bottom_up has 1.01 ± 0.01 times more coverage than arb (p = 0.04)
mutate has 1.47 ± 0.02 times more coverage than arb (p = 0.00)
top_down has 1.06 ± 0.02 times more coverage than arb (p = 0.00)
mutate has 1.45 ± 0.01 times more coverage than bottom_up (p = 0.00)
top_down has 1.05 ± 0.02 times more coverage than bottom_up (p = 0.00)
mutate has 1.38 ± 0.02 times more coverage than top_down (p = 0.00)

Conclusion

The mutate fuzzer performs best. It vastly outperforms all the others at 5 minutes of fuzzing (36-49% more coverage), and while the rest narrow that gap after 24 hours of fuzzing, mutate maintains its lead (1-2% more coverage).

The comparison between arb and mutate is as apples-to-apples of a comparison as it gets between idiomatic test-case generation and mutation in Rust: derive(Arbitrary) and derive(Mutate). They use the same fixup method to ensure that the resulting Wasm instructions are valid. The fuzzer built with mutatis and test-case mutation provides better coverage over time than the fuzzer built with arbitrary and test-case generation. When writing structure-aware fuzzers, I used to reach for arbitrary; in the future, I will reach for mutatis instead.

The top_down fuzzer performs second-best, and is best of the generation-based fuzzers. This aligns with results from the rgfuzz paper, which found that top-down Wasm instruction generation resulted in better instruction diversity than bottom-up generation. This result is intuitive, they point out, because Wasm instructions tend to have more operands than results, which means that more candidates are filtered out from consideration when generating instructions in forward order from operands to results (bottom-up) than when generating them in backward order from results to operands (top-down).

Subjectively, none of the approaches feel significantly more-complicated nor easier to implement than the others. All approaches require a stack of types, representing the generated Wasm’s operand stack, at some point in their implementation. Some require it during instruction generation (top_down and bottom_up) while others require it during fixup (mutate and arb). Adding support for new Wasm instructions is roughly the same in all of them: add a new variant to enum Inst and define its operand and result types. top_down and bottom_up additionally require adding a line for the new instruction in their choose_inst_{top_down,bottom_up} functions, but this could be avoided with some targeted macro_rules! sugar.

The fixup method fixes instructions in a forwards order; as future work, it would be interesting to implement a backwards_fixup method that fixes instructions in a backwards order and see if mutate and backwards_fixup outperforms the current mutate and forwards fixup the same way that backwards generation (top_down) outperforms forwards generation (bottom_up).

fixup makes an attempt to reuse stack operands when it can, rather than synthesize dummy constants or drop already-computed values, but the attempt is somewhat half-hearted. Dropping operands introduces dead code, which is not very interesting for exercising deep into the compiler pipeline. Dummy constants are not that interesting either. Therefore, another potential line of follow-up work would be to investigate ways to maximize operand reuse and minimize drops and dummy constants inserted while ensuring validity. That could include storing values to memory or globals instead of droping them when possible. It could even include liberating ourselves from the stack-focused paradigm we’ve had thus far.

WebAssembly is a stack-based language and so it is natural that our approaches have focused on producing stack-y code. But, in practice, optimizing WebAssembly compilers like Wasmtime’s use a static single-assignment intermediate representation, and erase the operand stack early in their compilation pipelines. Therefore, from these compilers’ point of view, the following two WebAssembly snippets are identical:

;; `x = a + (b * c)` in a "stack-y" encoding and
;; without temporary locals.
local.get $a
local.get $b
local.get $c
i32.mul
i32.add
local.set $x

;; `x = a + (b * c)` in a "non-stack-y" encoding
;; that uses temporary locals for every operation.
;;
;; Equivalent of
;;
;;     temp0 = b * c
;;     temp1 = a + temp0
;;     x = temp1
local.get $b
local.get $c
i32.mul
local.set $temp0
local.get $a
local.get $temp0
i32.add
local.set $temp1
local.get $temp1
local.set $x

Producing code that uses many temporaries in this manner might be easier than code that doesn’t, but, more importantly, it may enable better reuse of already-computed subexpressions, emit less dead code, and ultimately produce more interesting data-flow graphs that better exercise the deep innards of the compiler.

A final vein of interesting follow-up work to mine would be comparing arbitrary-based generators and mutatis-based mutators for structured inputs that are not programming languages and when the SUT we are fuzzing is not a compiler. Do we see these same results when, for example, producing PNG images to fuzz an image-transformation library?

Here is the source code for this experiment, including the three generators, one mutator, raw benchmark data, and benchmarking harness. The README includes instructions on running the benchmarks yourself.

WebAssembly’s stack-based instructions encode an expression tree — local.get $a; local.get $b; local.get $c; i32.add; i32.mul is isomorphic to a * (b + c) — so the experiment should be relevant and applicable to any other generator or mutator for a programming language with expressions, even if it might not appear so at first glance. ↩
Ignoring its rule-guided bit, which is orthogonal and could be applied to bottom_up as well. ↩
Structure-aware fuzzing and property-based testing are basically the same: convergent evolution from different communities. ↩

Andreas Farre

Session History Diagrams in Firefox DevTools

By Andreas Farre on June 01, 2026 12:00 AM

I’ve spent a lot of time at Mozilla working on session history, the machinery that keeps track of where you’ve been so the back and forward buttons do something sensible. It’s one of those parts of the browser that sounds simple from the outside and turns out to be anything but. Once you add iframes, nested iframes, and the subtle rules about when a navigation creates a new entry versus replacing the current one, the state you’re reasoning about gets large and hard to hold in your head.

For years my main tool for understanding that state was reading code and printing things to a log. That works, but it’s slow, and it never quite shows you the shape of the thing. So I built a way to see it: a new DevTools panel in Firefox Nightly called Session History Diagrams.

Enabling it

The panel is available in Firefox today, behind a pref. It’s been there in some form since Firefox 150, growing more stable with each release. To turn it on, set devtools.application.sessionHistory.enabled to true in about:config, then reload DevTools. The new panel lives under the Application tab, next to Service Workers and Manifest, and it draws the browser’s session history as a diagram that updates as you navigate.

Since Firefox 153 it also works over remote debugging. Connect to a device from about:debugging and you can watch the session history of a page running on Android, the same as you would on the desktop.

Jake diagrams

I didn’t invent the idea of drawing this. The HTML spec already has a notation for it, called a Jake diagram after Jake Archibald, and that’s where I started. It’s a tabular notation where columns represent steps in session history, and rows represent navigables (the top-level browsing context plus any iframes). Background colors identify documents, a fresh color marking a new document loaded in that navigable, and the current step is shown in bold. It’s a genuinely useful way to capture multi-navigable interactions that are otherwise hard to describe in prose.

These diagrams don’t have to be drawn by hand. Domenic Denicola, one of the HTML spec editors, built a Jake diagram generator that turns a description of a navigation sequence into a rendered diagram. That’s where I first started playing with a more dynamic approach to the visualization. The thing I missed the most was being able to build a history up step by step rather than describe a finished sequence all at once. So I wrote rejake, a small tool that draws diagrams in the same style¹, but lets you construct the history one step at a time.

But rejake, like the spec’s diagrams and Domenic’s generator before it, was stuck with a limitation the spec itself admits to, that they only work with a single level of nesting. That was exactly my problem. Real pages nest iframes inside iframes, and the bugs I was chasing usually lived down in that deeper nesting, precisely where the diagram stops being able to help. And however I drew them, I was still typing the history out by hand. It’s a short step from there to wanting the diagram to draw itself from the browser’s actual session history instead².

Firefox Session History Diagrams

So the panel extends Jake diagrams to handle arbitrary nesting. Every column is a step in the session history. Every row is a frame, listed in pre-order from the frame tree: top-level document first, then its first iframe, then that iframe’s children, and so on. The current entry is highlighted in blue, and the diagram updates live as you navigate.

The recording above is an ordinary bit of browsing, a handful of pages visited one after another. The top row tracks the page you’re actually looking at, and the current position is the one in blue. The interesting part is everything underneath that top row.

Some of those pages didn’t just load a single document. They pulled in nested frames of their own, and the diagram stacks those below the page that owns them. None of that is visible in the address bar or anywhere in the page chrome, and the frames come and go as you move through the history. Normally you’d have no way of knowing they were ever there. Here you can read straight off the diagram which frames a given step carried, when each one entered, and when it dropped away again.

Who else might want this

I built this for myself, working on Gecko’s session history internals, where being able to watch the diagram change while reproducing a bug turns opaque state into something I can point at. But it turns out I’m not the only one who hits this wall. Plenty of people working elsewhere in Gecko, anywhere near navigation, end up reasoning about the same state, and now we all share one picture of it.

If you build single-page applications, or work with the History API or Navigation API, you’ve probably run into the same kind of confusion from the other side. A push where you expected a replace, a missing history entry, an iframe that accumulated entries unexpectedly. These are hard to reason about without seeing the state directly, and that’s exactly what the diagram gives you.

Session history isn’t a Firefox-specific problem either. Every engine implements the same part of the HTML spec, and Jake diagrams come from that shared spec. The panel only ever shows Firefox’s state, but the rules are the same everywhere, so if you work on another engine it can still be a useful reference for how one implementation behaves. It’s often the only practical way to surface an interoperability difference, which might be a bug in any of the engines, but stays hidden until you can actually see it.

Thanks

A big thanks to Nicolas Chevobbe, whose assistance was invaluable in getting the DevTools integration right. The work, including what’s still to come, is tracked in Bug 2015726. There’s a fair bit still on that list, like marking whether a step was a push or a replace, surfacing back/forward cache state, tying the diagram into the Network and Inspector panels, and more, all heading toward fuller DevTools support for Navigation and Session History.

Notes

Which, naturally, meant re-implementing the whole of Session History along the way. ↩
Getting nerd-sniped by Jan Jaeschke definitely contributed as well. ↩

Olivier Mehani

Optional Docker services and dependencies

By Olivier Mehani on May 31, 2026 11:58 AM

Like many, docker and and compose have become my go-to tool to create software that can be conveniently deployed to production with a limited amount of headache. However, many tasks, and sometimes whole services, pertain only to the development side of the workflow, and need to stay there.

Moreover, some tasks, such as time-consuming provisioning tasks, are only on-demand one-offs. They shouldn’t run at all most of the time, but they should slot into the dependency graph correctly when needed.

tl;dr: I realised that docker compose supports profiles, which allows services to be enabled conditionally, along with the depends_on.[].required option, to ignore them when they are disabled. Profiles are also useful to package actions and triggers to run on demand, so they are not started by default.

We can start with a simple setup where our long-running main service depends on an init service to perform preliminary steps. This can be setup with depends_on the compose.yaml.

services:
  main:
    image: debian:latest
    command: "sh -c 'while : ; do echo main; sleep 10; done"
    depends_on:
      init:
        condition: service_completed_successfully

  init:
    image: debian:latest
    command: sh -c 'echo init; sleep 10'

Even when run ning the main container, we get the right dependency (and delay). So far so good (though up will show the output from all containers.

But what if we have another, much more time consuming, initialisation step?

services:
   [...]
   opt-init:
    image: debian:latest
    command: sh -c 'echo opt-init; sleep 100'

Perhaps we are lucky, and while it needs to run once, we don’t need it to run everytime (think: database setup).

Docker compose can use profiles to select when services are started. It will then only be started when this profile is selected. Services without explicit profile will always be started, but any service with one or more profile listed will only get started iff that profile is selected.

We can make the opt-init service part of the opt profile. We can also make the main service dependent on it, so it is started beforehand.

services:
  main:
    [...]
    depends_on:
      [...]
      opt-init:
        condition: service_completed_successfully

  opt-init:
    [...]
    profiles:
      - opt

This works well enough when the opt profile is specified but… Oh no! If the profile is not specified, the dependency on the opt-init isn’t resolvable, and none of the stack can spin up with just docker compose up

Fortunately, this is easily solved with the required attribute of the depends_on objects.

services:
  main:
    [...]
      opt-init:
        condition: service_completed_successfully
        required: false

And that’s really all there is to it: with the right profile, the optional dependency is started in the desired order, but its absence is otherwise transparently ignored. Both docker compose up and docker compose --profile opt work as desired.

Profiles afford us another useful trick: on-demand tasks not started by default. This can be handy for maintenance tasks (data cleanup, garbage collection, …) or test scripts (running test workload, sending message, …). Those are handy during development, but would not be necessary, or take a different form, in other deployments.

services:
  [...]
  say-hello:
    image: debian:latest
    profiles:
      - hello
    command: echo hello
    depends_on:
      main:
        condition: service_started

Conveniently, when explicitly running a service, it is not necessary to request a matching profile, keeping the command line lean: docker compose run say-hello.

So here we are. Compose profiles allow us to control which services get started, and mark some as conditional. This, coupled with the ability to mark some depends_on rules as not required is a good way to seamlessly prevent heavy or otherwise time consuming services from starting when not needed, while retaining proper dependency ordering when enabled.

For completeness, the full, final, compose.yaml looks as follow.

services:
  main:
    image: debian:latest
    command: "sh -c 'while : ; do echo main; sleep 10; done'"
    depends_on:
      init:
        condition: service_completed_successfully
      opt-init:
        condition: service_completed_successfully
        required: false

  init:
    image: debian:latest
    command: sh -c 'echo init; sleep 10'

  opt-init:
    image: debian:latest
    profiles:
      - opt
    command: sh -c 'echo opt-init; sleep 100'

  say-hello:
    image: debian:latest
    profiles:
      - hello
    command: echo hello
    depends_on:
      main:
        condition: service_started

The post Optional Docker services and dependencies first appeared on Narf.

The Servo Blog

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

By Servo Team on May 31, 2026 12:00 AM

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.

We’ve shipped several new web platform features:

<select multiple> (@lukewarlow, @mrobinson, #43189)
<template shadowrootslotassignment> (@simonwuelker, #44246)
<video> playback on OpenHarmony (@rayguo17, #43208)
‘minimum-scale’ and ‘maximum-scale’ values in <meta name=viewport> (@shubhamg13, #40098, #43715)
‘color-mix()’ with any number of <color> values (@Loirooriol, #43890)
‘&::before’ and ‘&::after’ in ‘::details-content’ (@Loirooriol, #43878)
‘revert-rule’ (@Loirooriol, #43878)
‘tab-size’ (@mrobinson, @SimonSapin, #44480)
‘text-align: match-parent’ (@TG199, #44073)
new Worker() with blob URLs (@jdm, #44004)
getContext("webgl") on OffscreenCanvas (@niyabits, #44159)
the detail property on PerformanceMark and PerformanceMeasure (@shubhamg13, #44289, #44272)

Plus a bunch of new DOM APIs:

‘selectionchange’ events on <input> and <textarea> (@TimvdLippe, #44461)
StorageManager, in experimental mode (@Taym95, #43976)
activeElement on Document and ShadowRoot (@mrobinson, #43861)
crypto.subtle.supports() (@kkoyung, #43703) – Servo is the first major browser engine to support this!
cellPadding, cellSpacing, and align properties on HTMLTableElement (@mrobinson, #43903) – previously supported in HTML only
relatedTarget on ‘focus’ and ‘blur’ events (@mrobinson, #43926)
transferFromImageBitmap() on ImageBitmapRenderingContext (@Messi002, #43984)

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

CryptoKey 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 localStorage and sessionStorage were usable in sandboxed <iframe> and shared with every other sandboxed <iframe>, rather than throwing SecurityError (@Taym95, #44002).

We’ve fixed a bug where localStorage and sessionStorage 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 texImage3D() on WebGL2RenderingContext (@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 IDBDatabase, IDBObjectStore, IDBCursor, IDBKeyRange, IDBRequest, 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 IntersectionObserver API, under --pref dom_intersection_observer_enabled (@stevennovaryo, @jdm, #42204).

We’re continuing to implement document.execCommand() for rich text editing (@TimvdLippe, #44529), under --pref dom_exec_command_enabled. This release adds support for the ‘bold’, ‘fontName’, ‘fontSize’, ‘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 SharedWorker, under --pref dom_sharedworker_enabled (@Taym95, #44375, #44440).

We’re working on the WakeLock 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).

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:

The ‘servo’ package follows Cargo’s rules for semver compatibility. 0.1.1 is compatible with version 0.1.0, but 0.2.0 is a breaking update.
Until we integrate semver analysis into our release process, each monthly release will have a breaking version number, while non-breaking version numbers may be used for LTS updates.
In general, dependencies of ‘servo’, like ‘servo-base’ and ‘servo-script’, do not use semver. Any release may include breaking changes.

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:

WebView::animating now takes &self instead of self, so you can call it without cloning the handle (@JavaDerg, #44253)
Servo::site_data_manager now returns &SiteDataManager instead of Ref<'_, SiteDataManager> (@sabbCodes, #44116)
WebViewDelegate::play_gamepad_haptic_effect and stop_gamepad_haptic_effect have been removed (@mrobinson, #43895), but they have not worked since February 2026 – use GamepadDelegate instead

You can now load a URL with custom request headers by calling WebView::load_request (@Narfinger, @longvatrong111, @mrobinson, #43338).

You can now retrieve cookies asynchronously by calling SiteDataManager::cookies_for_url_async (@longvatrong111, #43794).

The synchronous version of that method, SiteDataManager::cookies_for_url, was previously not callable because CookieSource 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 SiteDataManager::clear_session_cookies (@longvatrong111, #44166).

When intercepting requests with ServoDelegate:: and WebViewDelegate::load_web_resource, we now include a destination and referrer_url in the WebResourceRequest, 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.

WindowRenderingContext::new and SoftwareRenderingContext::new now return an error if the given size is less than 1x1 (@freyacodes, @mrobinson, #44011).

We’ve improved our API docs for WebView, WebViewBuilder, WebViewDelegate, ServoDelegate, PromptDialog, WebResourceLoad, WebXrRegistry, Preferences, and servoshell’s EXPERIMENTAL_PREFS (@simonwuelker, @TG199, @sabbCodes, @jdm, @rovertrack, #43892, #43787, #44171, #43947).

We’ve also improved our API docs for Opts, OutputOptions, DiagnosticsLogging, PrefValue, 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.randomUUID (@simonwuelker, #43989).

Exception messages have improved in Location, StaticRange, and the HTMLElement 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 viewBox> (@yezhizhen, #44420), ‘attr()’ (@Loirooriol, #43878), ‘:focus’ (@mrobinson, #43873), ‘font’ (@RichardTjokroutomo, #44061), ‘@keyframes’ (@simonwuelker, #43461), ‘@property’ (@Loirooriol, #43878), ‘load’ events (@jdm, @arabson99, #43807, #44046), fetchLater() (@TimvdLippe, #43627), axes and buttons on Gamepad (@log101, @rovertrack, #44411, #44357), copyTexImage2D() on WebGLRenderingContext (@simartin, @mrobinson, #43608), texImage3D() on WebGL2RenderingContext (@simartin, #44367), environmentBlendMode on XRSession (@msub2, #44155), mark() and measure() on Performance (@shubhamg13, @simonwuelker, #44471, #44199, #43990, #43753), and PerformanceResourceTiming (@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), removeChild() on Document (@rovertrack, #44133), and URL.revokeObjectURL() (@simonwuelker, @jdm, #43746, #43977, #44035).

Performance and stability

We’ve fixed some big inefficiencies in Servo. appendChild() 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 CharacterData 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 PathBuf 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:

in compressedTexSubImage2D() on WebGLRenderingContext (@thebabalola, #44050)
in console.log() (@thebabalola, #43844)
in getData() on DataTransfer (@SimonSapin, #44607)
in remove() on Element (@SimonSapin, #44435)
in replaceWith() on Element (@yezhizhen, #44503)
in --debug-mozjs builds (@jdm, #44386, #44573, #44581)
in flex and grid layout (@mrobinson, @nicoburns, #44424, #44203)
in layout queries like offsetHeight (@mrobinson, #44560)
in the devtools Debugger tab, when stepping and when inspecting nested values (@atbrakhi, @eerii, #44024, #43995)
when removing <colgroup> from the DOM (@Loirooriol, #43846)
when running garbage collection (@drasticactions, #43933)
when running servoshell with a u64 --pref (@yezhizhen, #44079)
when shadow roots are deeply nested, or when calling attachShadow() removes elements from the flat tree (@yezhizhen, @mrobinson, #43888, #43930, #44259)
when web storage features fail to write to disk or encounter SQLite errors (@arihant2math, @sabbCodes, #43918, #43949)

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.

Frederik Braun

The S in interoperability

By Frederik on May 30, 2026 10:00 PM

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 implementations align on the same behavior in edge cases. Eventually, I found myself co-editing a specification - Subresource Integrity (SRI) which was published as a W3C Recommendation in 2015. The core idea behind SRI is that you include third-party JavaScript combined with a SHA2 digest of the expected file. If the browser does not find the downloaded URL to match the expected digest, the script will not execute. This allows using a fast CDN for JavaScript without giving them full control over the scripts on your page - essentially reducing the security risks.

The standard format for these digests is e.g., sha(size)-(base64 encoding of the digest). While computing the hash digest is rather straightforward, base64 comes in two encoding alphabets: First, a-zA-Z0-9/+ and secondly the url-safe variant which uses a-zA-z0-9_-. The specification examples all used the former.

Only approximately ten years after publication, in 2025, we still found a bug. As part of a compatibility report against Firefox not properly supporting a website, we found that the core issue was actually with a different browser. The other browser liberally accepted both types of encoding, which resulted in websites expecting support for base64 and base64url interchangeably. The page did not work in Firefox, because it did not accept all hashes a website wanted the browser to check, revealing a minor security issue.

The real fix would have been that the standard clarifies that the base64url variant is incorrect and the other browser engine changes their behavior.

But due to (somewhat unrelated) issues around proliferation of standards, web compatibility and the unfortunate market dominance of certain browsers, we went the other road. To support existing web content, we changed the standard to acknowledging that both types of encoding are considered valid representations.

This example shows, that it can take multiple years for subtle differences to appear. Interoperable specifications can establish a shared understanding along a "happy path", but not necessarily in adversarial settings. In addition, standards need to continuous maintenance and active stakeholders who ensure that implementations remain interoperable and secure over time.

From specification to standard

Originally, a specification is at first just a write-up, an idea how something could be better: How it should behave, how it works, what the data structures, the algorithms and the interactions of them look like. Anyone can come up with a grammar, a parser and a resulting data structure.

For a standard, this specification needs a shared agreement that is also widely and consistently implemented. This will work best with iterative co-design of the spec, the implementations and intense discussions of corner cases. Some may go further and use shared test suites.

This will lead to Interoperability (interop), but still requires constant maintenance and observation of the ecosystem beyond individual implementations. While interop is asymptotic and requires a shared agreement over time, security demands understanding - a broader reach that requires the inspection of limitations and subtle boundaries.

This deeper level of understanding is often missing when implementations consider syntax "simple enough" without reading the spec. The base64 SRI example is just one example, but there are more:

Many people have written their own parsers for text-based languages. You may have seen code that parses HTML with regular expressions. Other great examples of "easily" parsed languages are maybe XML, JSON, or YAML.

But these implementations often make different assumptions, leading to subtle incompatibilities or even security flaws.

Parser Differentials

More practical, let's look at an issue with JSON, to demonstrate the impact of handling input that is ostensibly simple. Let's examine this JSON string and the resulting data structure:

{
"test":0,
"test":1
}

When parsed into an object obj, what do you think will obj.test return? Most JSON parsers are so liberal that they will happily consume two dictionary keys with the same name "test". One implementation may simply assign obj.test twice: First with 0 and then overwrite it with 1. Another one might check for existing keys and reject the second "test" key silently, keeping the first one.

The lack of rigor in the original description of JSON as a "subset of JavaScript" was already acknowledged and raised as problematic in the JSON RFC (which came much later in 2017). But still to this day, many implementations allow input with duplicate dictionary keys and show divergent behavior.

While the examples with SRI and JSON are relatively harmless, real parser differential bugs were leading to code execution, authentication bypasses and more¹.

What do we learn from this?

Perfect interoperability is not created through a specification, it needs constant maintenance. The ambiguity can only be removed through long-term commitment and regular feedback from implementations and users.

The same is true for security: The SRI bug persisted for ten years and nobody noticed how implementations disagreed and corner cases were overlooked. They only aligned due to a real, user-facing issue.

But these examples are not a warning sign, they are scar tissue that shows how the internet is made. Standards can only mature through vigilant maintenance.

The bug reports, the spec issues being filed, the shared test cases, sometimes even the random forum complaints. All of these help to remove ambiguity and allow internet standards to mature.

In the end, standards are not secure because they are written down. They are secure because people continue to question, understand, and maintain them.

JSON, YML, XML, and more ↩

The Rust Programming Language Blog

Announcing Rust 1.96.0

By The Rust Release Team on May 28, 2026 12:00 AM

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:

core::range::Range
core::range::RangeFrom
core::range::RangeInclusive
Associated iterators

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.

CVE-2026-5223 is a medium severity vulnerability regarding extraction of crate tarballs with symlinks.
CVE-2026-5222 is a low severity vulnerability regarding authentication with normalized URLs.

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!

Firefox Tooling Announcements

New Deploy of PerfCompare (May 27th)

By csevere on May 27, 2026 09:29 PM

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

Please submit your suggestions and votes for next week!

This Week In Rust

This Week in Rust 653

By TWiR Contributors on May 27, 2026 04:00 AM

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

Scientific Computing in Rust #18 (May 2026)

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Miscellaneous

Content-addressed Rust builds (or, what kache actually caches)

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!

Calls for Testing

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

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.

rust cookbook - Expand Command Line section with clap derive, subcommands, and env vars

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.

No Calls for papers or presentations were submitted this week.

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

stabilize --remap-path-prefix in 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:

Propose the concept of a crates.io username for identity

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

Rust

Rust RFCs

Avoid linting unreachable_code on todo!()

Unsafe Code Guidelines

What are the values of a union type? (in particular, what is the validity invariant of a union)

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

No New or Updated RFCs were created this week.

Upcoming Events

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

Virtual

2026-05-27 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-02 | Virtual | libp2p Events
- rust-libp2p Open Maintainers Call
2026-06-02 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV
- ‎שיחה חופשית ווירטואלית על ראסט
2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust
- Indy.rs - with Social Distancing
2026-06-04 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg
- Rust Nürnberg online
2026-06-04 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
- Exploring FalkorDB - Learning to use a Graph Database in Rust
2026-06-06 | Virtual (Kampala, UG) | Rust Circle Meetup
- Rust Circle Meetup
2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Rust Deep Learning: First Sunday
2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Second Tuesday
2026-06-10 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-16 | Virtual (Washington, DC, US) | Rust DC
- Mid-month Rustful
2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Jiff
2026-06-17 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- June, 2026 SRUG (Seattle Rust User Group) Meetup
2026-06-18 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Rust Deep Learning: Third Sunday
2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Fourth Tuesday
2026-06-23 | Virtual (London, UK) | Women in Rust
- Lunch & Learn: What the heck are monads - and how do we fake them in Rust

Asia

2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com)
- AI Agents and Open Source LLM (Call for Speakers)

Europe

2026-05-28 | Copenhagen, DK | Copenhagen Rust Community
- Rust meetup #68
2026-05-28 | London, UK | Rust London User Group
- LDN Talks May Community Showcase
2026-05-29 | Berlin, DE | Rust Berlin
- Rust Berlin Talks: The next generation
2026-05-30 | Stockholm, SE | Stockholm Rust
- Ferris' Fika Forum #26
2026-06-02 | Frankfurt, DE | Rust Rhein-Main
- gRPC with Rust and Tonic
2026-06-03 | Dublin, IE | Rust Dublin
- Join us live and INPERSON for Rust 261
2026-06-03 | Girona, ES | Rust Girona
- Rust Girona Hack & Learn 06 2026
2026-06-10 | München, DE | Rust Munich
- Rust Munich 2026 / 2 - Hacking Evening
2026-06-11 | Switzerland, CH | PostTenebrasLab
- Rust Meetup Geneva
2026-06-12 - 2026-06-14 | Kraków, PL | Rustmeet
- Rustmeet
2026-06-16 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
- Interactive: Everything is Open Source
2026-06-16 | Milano, IT | Rust Language Milan
- Real-time planning in Rust: SolverForge & SERIO
2026-06-18 | Aarhus, DK | Rust Aarhus
- Talk Night at Danske Commodities

North America

2026-05-27 | Austin, TX, US | Rust ATX
- Rust Lunch - Fareground
2026-05-28 | Atlanta, GA, US | Rust Atlanta
- Rust-Atl
2026-05-28 | Los Angeles, CA, US | Rust Los Angeles
- Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA
2026-05-28 | Mountain View, CA, US | Hacker Dojo
- RUST MEETUP at HACKER DOJO
2026-05-30 | Boston, MA, US | Boston Rust Meetup
- Central Cambridge Rust Lunch, May 30
2026-06-04 | Saint Louis, MO, US | STL Rust
- Testing, Coverage, Tracey & Mutations
2026-06-06 | Boston, MA, US | Boston Rust Meetup
- Boston Common Rust Lunch, June 6
2026-06-11 | Lehi, UT, US | Utah Rust
- Utah Rust June Meetup
2026-06-11 | Mountain View, CA, US | Hacker Dojo
- RUST MEETUP at HACKER DOJO
2026-06-11 | San Diego, CA, US | San Diego Rust
- San Diego Rust June Meetup - Back in person!
2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group
- Rust Hacking in Person
2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Jiff
2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- June, 2026 SRUG (Seattle Rust User Group) Meetup
2026-06-24 | Austin, TX, US | Rust ATX
- Rust Lunch - Fareground
2026-06-24 | Los Angeles, CA, US | Rust Los Angeles
- Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies

South America

2026-06-18 | Florianópolis, BR | Rust SC
- Rust Floripa

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!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Firefox Tooling Announcements

Firefox Profiler Deployment (May 26, 2026)

By canova on May 26, 2026 03:53 PM

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

Highlights:

[Markus Stange] Use @streamparser/json if the input is too large to fit in a V8 string (#6016)
[Nazım Can Altınova] Include --search option in pq filter push (#6026)
[fatadel] Translate URL track-index state through profile sanitization (#6000)
[Nazım Can Altınova] Print also the status output right after cli load command (#6019)

Other Changes:

[fatadel] Remove unused dependencies from package.json (#6010)
[Nazım Can Altınova] Make profiler-cli work in sandboxed environments (#6003)
[Markus Stange] Make profiler-edit run profile compacting before writing out the file (#6015)
[Markus Stange] Migrate from prettier to oxfmt (#5986)
[Markus Stange] Add a --symbolicate-wasm arg to profiler-edit. (#6008)
[Markus Stange] Build and upload the cli artifact in PRs (#6020)
[Nicolas Chevobbe] Update devtools-reps to 0.27.7 (#6030)
[Markus Stange/fatadel] Make withSize use a wrapper element so that it can stop calling findDOMNode (#5988)
[Markus Stange] Fix dhat importer (#6036)
[Nazım Can Altınova] Annotate inlined frames in CLI call trees and stacks (#6041)
[Nazım Can Altınova] Use proper types in cli tests instead of custom inline types (#6038)
[Nazım Can Altınova] Fix text truncation for frames named after Object.prototype methods (#6044)
[Nazım Can Altınova] Add missing key props to CodeErrorOverlay error list items (#6047)
[depfu[bot]] Update oxfmt to version 0.51.0 (#6054)
[Nazım Can Altınova] Sync: l10n → main (May 26, 2026) (#6058)
[Nazım Can Altınova] Use URL-state symbol server for profiler-cli function annotate (#6051)
[Nazım Can Altınova] Bump profiler-cli version to 0.2.0 (#6059)

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

fr: YD
sr: Марко Костић (Marko Kostić)
tr: Ali Demirtaş
zh-CN: Olvcpr423
zh-CN: wxie

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

Please submit your suggestions and votes for next week!

Andrew Halberstadt

Your New Job is Integrating Code

Andrew Halberstadt on May 26, 2026 01:50 PM

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:

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.

Mozilla Privacy Blog

Growing darkness: Against the rise of internet shutdowns

By Svea Windwehr and Tasos Stampelos on May 26, 2026 08:04 AM

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.

Jonathan Almeida

Auto-resolve Jujutsu conflicts with your AI agent

By Jonathan Almeida on May 25, 2026 12:00 AM

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.

The Rust Programming Language Blog

Security Advisory for Cargo (CVE-2026-5223)

By Rust Security Response Team on May 25, 2026 12:00 AM

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.

The Rust Programming Language Blog

Security Advisory for Cargo (CVE-2026-5222)

By Rust Security Response Team on May 25, 2026 12:00 AM

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:

https://example.com/index is a sparse index.
https://example.com/index allows crates to depend on crates from any other registry.
The attacker is able to publish crates on https://example.com/index.
The attacker is able to upload arbitrary files to https://example.com/index.git.

...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.

Mozilla Data YouTube Channel

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

By Mozilla Data on May 24, 2026 03:48 AM

Mozilla Data YouTube Channel

Introducing Glean Annotations

By Mozilla Data on May 24, 2026 02:56 AM

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.

Mozilla Data YouTube Channel

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

By Mozilla Data on May 21, 2026 06:30 PM

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.

The Mozilla Blog

Mozilla and Adafruit bring Web Serial workflows to Firefox

By Brian Bingham on May 21, 2026 06:00 PM

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.

Take control of your internet

Download Firefox

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

Hacks.Mozilla.Org

Announcing Web Serial Support in Firefox

By Haik Aftandilian on May 21, 2026 06:00 PM

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.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.

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.

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.

The Mozilla Blog

Designing Firefox for the future

By Firefox UX Team on May 21, 2026 12:55 PM

Crafted with care. Built for speed. Ready for what’s next.

A great browser is so intuitive that you often forget you’re using it. Yet today the internet is changing faster than ever, and your browser needs to keep up. Firefox is still the only browser built for people, not platforms: independent, customizable, private and firmly in users’ control.

Keeping Firefox the best browser for being online today is what motivated our recent work to update Firefox’s design and design system. We’re aiming to deliver a more cohesive foundation for Firefox: making the browser feel cleaner, warmer, faster and more adaptable.

Internally, we’ve been calling this work Project Nova. The name fits: A nova can look like a new star, yet it comes from existing matter — a renewal, not a replacement. When it rolls out later this year, you can just call it Firefox. Here’s what it’s all about:

Privacy at the center

A good default matters. When you choose Firefox, privacy and clear data practices are there from the start. Our new design pulls privacy features forward, making it easier to find and use tools like our free, built-in VPN and private browsing.

We’re also redesigning Settings so choices about your data are easier to understand and act on. That includes controls for turning off AI features entirely, plainer language throughout, as well as tuning Enhanced Tracking Protection to match your preferred balance of protection and usability.

Speed you can feel

Privacy and speed aren’t trade-offs. When Firefox blocks trackers, pages load faster, too. We also prioritize the most important parts of a page before the optional stuff around the edges. In the last year, we’ve improved load times for key page content by 9%.

The new design can speed up your workflows, too. It’s easier to access tab groups, split view, and vertical tabs – putting these productivity features at your fingertips, but not in your face.

And we’re bringing back compact mode. People told us that they missed it, and we listened. If you want your browser controls as condensed as possible, this one’s for you.

Balancing the new and familiar

When it came to design, we wanted Firefox to feel current, but not generic. Warm, but still precise. More expressive, but never louder than the web itself. You’ll see the change first in the fundamentals:

Tabs have a softer shape, with a subtle gradient that gives the active tab more presence and creates a sense of light around the browser chrome.
Components are more rounded and consistent, so panels, menus, settings and browser controls feel like part of the same system.
Icons have been updated to feel cleaner and more balanced across light and dark themes, supporting quick recognition without adding visual noise.
Spacing is rebalanced across the interface with the knowledge that every pixel matters when the browser is where you spend your day.
The refreshed color palette is inspired by the feeling of fire: the glow around your active tab, deep smoky purples and lighter tones that add warmth.

The voice is warming up, too. Firefox copy is becoming more direct, more human, and sometimes more playful or fiery. Always genuine… because that’s what sets Firefox apart.

The effect is distinctly Firefox: approachable and energetic, while still easy to scan. Under the hood, reusable tokens, components, patterns, and a shared design language make Firefox easier to evolve over time, so new features feel integrated instead of bolted on.

The redesign is most visible on desktop, but the work extends to mobile, too. Shared colors, icons, copy and design foundations help Firefox feel more consistent across devices.

Yours to shape

Firefox has long been the most customizable browser. It’s in our open source DNA. Now we’re adding more ways to make Firefox feel like yours, including new themes and wallpapers. And we’re exploring more customization over time, like controls for the shape of the interface — tabs, components, and related visual treatments.

Accessibility is a key part of customization. Firefox is being designed with attention to contrast, readability, focus states, keyboard behavior, target sizes, system settings, visual comfort, and how the interface works across themes and windows.

Dark mode, for example, is not just a preference for many people. It is their default environment. For some, it helps reduce eye strain. For others, it is part of a broader system setup.

Building in public

Firefox has always been built in the open, and with the help of a global community of contributors and supporters. You help us build the browser, test, extend and improve it. You tell us when something doesn’t feel right. That relationship is part of what makes Firefox different.

While the new design system for Firefox is still being shaped, keep telling us what feels right, and what gets in your way. We’re listening.

Take control of your internet

Download Firefox

The post Designing Firefox for the future appeared first on The Mozilla Blog.

Mozilla Data YouTube Channel

Mozillians sharing the 2021 SciPy Conference experience

By Mozilla Data on May 20, 2026 09:10 PM

The 2021 SciPy conference (https://www.scipy2021.scipy.org/) involved the showcasing of the latest open source Python projects for advancement in scientific computing. Mozilla was a diversity sponsor and a few Mozillians attended and shared their experience of the event.

Spidermonkey Development Blog

Saying goodbye to asm.js

By Ryan Hunt on May 20, 2026 05:00 PM

Axe-time, sword-time, shields are sundered,
Wind-time, wolf-time, ere the world falls.
– Völuspá, Poetic Edda

As of Firefox 148, SpiderMonkey’s asm.js optimizations are disabled by default, and we plan to remove the code entirely in a future release.

If you maintain a site that uses asm.js, nothing will break. asm.js is just a subset of plain JavaScript, so the code keeps running through our regular JIT just like any other script. That said, recompiling to WebAssembly will get you faster execution and smaller binaries.

History

asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds?

The idea was clever: pick a strict, statically-typed subset of JavaScript that an engine could recognize on the fly and compile down to native code. We could get performance similar to NaCl/PNaCl and still have code live inside web content and use web API’s (no separate sandbox, IPC, or alternative API’s).

asm.js shipped in Firefox 22 back in 2013 and was a success. It let projects like Unity and Unreal ship C/C++ codebases to the web for the first time, using just standard web technologies. The Epic Citadel demo was ported to the web in just four days. It was a landmark achievement, and a fond memory for the original asm.js team.

asm.js proved that we could run code at near-native speed on the web using just web technologies. This opened the door to WebAssembly, which shipped several years later in Firefox 52. Without asm.js, we likely wouldn’t have WebAssembly.

Why now?

So why turn it off? WebAssembly has succeeded, and asm.js usage has mostly migrated over. Keeping the asm.js path alongside WebAssembly costs us maintenance time and gives us extra attack surface in the VM.

If you are shipping asm.js content, please consider recompiling to WebAssembly! Our WebAssembly pipeline is significantly more advanced than the asm.js one ever was. You should see faster execution and smaller binaries.

Ragnarök

The asm.js compiler is called OdinMonkey. As was foretold long ago, OdinMonkey must meet his fated doom. The bug Ragnarök tracks the “Twilight of OdinMonkey”.

All is not lost however, for born of OdinMonkey is BaldrMonkey, our WebAssembly optimizing compiler. OdinMonkey may be swallowed whole by the wolf, Fenrir, but BaldrMonkey will rule over the reborn world alongside RabaldrMonkey (“commotion”), our WebAssembly baseline compiler.

On this Odin’s day (Wednesday) we thank OdinMonkey for thirteen years of service. Skål!

Then fields unsowed bear ripened fruit,
all ills grow better, and Baldr comes back;
Baldr and Hoth dwell in Hropt’s battle-hall. – Völuspá, Poetic Edda

Firefox Nightly

Settings Are Getting a New Look!

By talee on May 20, 2026 03:53 PM

The redesign of Firefox Settings is now enabled by default in Nightly! With this change, we are making it easier for people to customize Firefox and discover the controls that matter most to them. The redesign improves navigation and organization, updates labels and descriptions, and uses a new underlying architecture that will make Settings easier to update over time.

Firefox Settings have grown a lot over the years. Our research showed that some areas had become crowded and more difficult to navigate, and that important controls could be hard to discover. Some terminology and layouts had also become inconsistent over time. Internally, the existing structure also made Settings harder to maintain and evolve over time.

Here are some of the changes you’ll notice:

More pages within Settings, with less content per page
Clearer grouping and better flow between related controls
Improved labels and helper text
Consistent use of our design system throughout

New Settings navigation and layout in Nightly

The new Settings navigation and layout

While the organization of Settings has changed, all your existing choices and preferences remain in place. You can always use the search bar to jump straight to what you’re looking for.

We plan to ship the redesign to the Release channel in Firefox 152. You will continue to see changes in Nightly, and we welcome feedback, especially in Mozilla Connect.

Customization has long been a core part of Firefox, and this redesign is intended to continue improving how people discover and manage their browser settings. We appreciate all of the feedback from the community so far on this project and look forward to refining the experience with your input!

This Week In Rust

This Week in Rust 652

By TWiR Contributors on May 20, 2026 04:00 AM

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

Official

Newsletters

This Month in Rust OSDev: April 2026

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Crate of the Week

This week's crate is cargo-crap, a cargo subcommand to calculate the Change Risk Anti-Patterns metric for a crate.

Despite a lamentable lack of suggestions, llogiq is pleased with his choice.

Calls for Testing

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

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.

Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10

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

369 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

Fewer than usual PRs merged, mostly due to a shorter week than normal and some CI trouble. Overall a slightly positive week for performance.

Triage done by @simulacrum. Revision range: 29b75901..281c97c3

0 Regressions, 0 Improvements, 4 Mixed; 1 of them in rollups 17 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:

Cargo RFC for min publish age

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

No Items entered Final Comment Period this week for Rust, Rust RFCs, Cargo, Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines.

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

Documentation interpolation

Upcoming Events

Rusty Events between 2026-05-20 - 2026-06-17 🦀

Virtual

2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Mouse Control with Rust
2026-05-20 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- May, 2026 SRUG (Seattle Rust User Group) Meetup
2026-05-21 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-05-21 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
- Tock OS Part #4 - Capsule coding in QEMU!
2026-05-26 | Virtual (Cardiff, GB) | Rust and C++ Cardiff
- Hybrid event with Rust Dortmund!
2026-05-26 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Fourth Tuesday
2026-05-26 | Virtual (London, UK) | Women in Rust
- Lunch & Learn: Seeing Into Your Code - A Practical Guide to Tracing in Rust
2026-05-27 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-02 | Virtual | libp2p Events
- rust-libp2p Open Maintainers Call
2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust
- Indy.rs - with Social Distancing
2026-06-04 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg
- Rust Nürnberg online
2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Rust Deep Learning: First Sunday
2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Second Tuesday
2026-06-10 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-16 | Virtual (Washington, DC, US) | Rust DC
- Mid-month Rustful
2026-06-02 | Virtual | libp2p Events
- rust-libp2p Open Maintainers Call
2026-06-17 | Virtual (Girona, ES) | Rust Girona
- Weekly coding session
2026-06-17 | Virtual (Vancouver, BC, CA) | Vancouver Rust
- Rust Study/Hack/Hang-out

Asia

2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com)
- AI Agents and Open Source LLM (Call for Speakers)

Europe

2026-05-18 - 2026-05-23 | Utrecht, NL | RustWeek 2026
- RustWeek 2026
2026-05-21 | Amsterdam, NL | RustNL
- RustWeek Hackathon
2026-05-22 | Amsterdam, NL | RustNL
- Walking Tour around Utrecht
2026-05-22 | Amsterdam, NL | RustNL
- Bike tour around Utrecht
2026-05-26 | Dortmund, DE | Rust Dortmund
- Rust Dortmund Meetup - Agentic Programming - May
2026-05-26 | Manchester, UK | Rust Manchester
- Rust Manchester May Code Night
2026-05-26 | Trondheim, NO | Rust Trondheim
- Motorized blinds, and replacing Docker, in Rust!
2026-05-28 | London, UK | Rust London User Group
- LDN Talks May Community Showcase
2026-05-29 | Berlin, DE | Rust Berlin
- Rust Berlin Talks: The next generation
2026-06-03 | Dublin, IE | Rust Dublin
- Join us live and INPERSON for Rust 261
2026-06-03 | Girona, ES | Rust Girona
- Rust Girona Hack & Learn 06 2026
2026-06-11 | Switzerland, CH | PostTenebrasLab
- Rust Meetup Geneva
2026-06-16 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig
- Interactive: Everything is Open Source

North America

2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Mouse Control with Rust
2026-05-20 | San Francisco, CA, US | Bay Area Rust Meetup
- Bay Area Rust Meetup
2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- May, 2026 SRUG (Seattle Rust User Group) Meetup
2026-05-21 | New York, NY, US | Rust NYC
- Rust NYC: "Boring File Storage" & "Indie News Feed Optimization"
2026-05-21 | Nashville, TN, US | Music City Rust Developers
- Community Meetup
2026-05-23 | Boston, MA, US | Boston Rust Meetup
- Allston Rust Lunch, May 23
2026-05-27 | Austin, TX, US | Rust ATX
- Rust Lunch - Fareground
2026-05-28 | Atlanta, GA, US | Rust Atlanta
- Rust-Atl
2026-05-28 | Los Angeles, CA, US | Rust Los Angeles
- Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA
2026-05-28 | Mountain View, CA, US | Hacker Dojo
- RUST MEETUP at HACKER DOJO
2026-05-30 | Boston, MA, US | Boston Rust Meetup
- Central Cambridge Rust Lunch, May 30
2026-06-04 | Saint Louis, MO, US | STL Rust
- Testing, Coverage, Tracey & Mutations
2026-06-06 | Boston, MA, US | Boston Rust Meetup
- Boston Common Rust Lunch, June 6
2026-06-11 | Lehi, UT, US | Utah Rust
- Utah Rust June Meetup
2026-06-11 | San Diego, CA, US | San Diego Rust
- San Diego Rust June Meetup - Back in person!
2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group
- Rust Hacking in Person

Oceania

2026-05-26 | Barton, ACT, AU | Canberra Rust User Group
- May Meetup

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

Posts like this are useful for those of us who like to help, and who work on rustc to make it more helpful, by letting us learn about what kinds of mistakes people make.

– Kevin Reid on rust-users

Thanks to firebits.io for the suggestion!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation