Planet Mozilla2026-06-15T04:54:47ZVenusPlanet Mozilla Module Teamplanet@mozilla.orghttps://planet.mozilla.org/atom.xmlhttps://blog.mozilla.org/community/?p=2539May highlights: Contributor spotlight, Web Serial support, and more
Hi Mozillians, For years, the Mozilla Community Newsletter has served as a monthly touchpoint for contributors and community members across the Mozilla ecosystem. Coordinated by the Customer Experience (CX) team, … Read more
Hi Mozillians,
For years, the Mozilla Community Newsletter has served as a monthly touchpoint for contributors and community members across the Mozilla ecosystem. Coordinated by the Customer Experience (CX) team, it helps keep our global contributor and product communities informed, connected, and engaged through updates, contributor stories, announcements, and opportunities to get involved.
While the newsletter has traditionally been distributed directly to community members, we recognize that many of these updates are valuable to a broader audience as well. That’s why we’re bringing our content into a blog post format, making it easier for anyone interested in Mozilla’s mission, products, and community work to stay informed.
Whether you’re a longtime contributor, a Firefox enthusiast, or simply curious about what’s happening across Mozilla, we hope these updates provide useful insights into the people, projects, and initiatives shaping our community.
In this edition, we’re sharing our latest updates from May 2026. It’s packed with the latest community news, contributor highlights, project updates, and opportunities to get involved in Mozilla’s work around the world.
So, without further ado, let’s dive in!
From localizing to Firefox Enterprise
Long-time Mozillian Valery recently shared an open-source project he built to help Firefox Enterprise administrators manage Firefox deployments more easily called Browser Policy Manager or BPM. Beyond the tool itself, this story is a proof of the long-term value of investing in the community. Stories like Valery’s show how community contributions evolve over time and why fostering a strong, engaged contributor community continues to pay dividends across the Mozilla ecosystem.
Could Firefox users help grow the community by recommending Firefox to friends and family? That’s the question being explored in a recent Mozilla Connect discussion about potential referral programs. Join the conversation to share your thoughts on what would motivate you to recommend Firefox, and what a referral experience should (or shouldn’t) look like.
After years of community interest and requests dating back more than a decade, Firefox 151 now includes support for the Web Serial API. Developers can use Firefox to communicate with and manage serial-connected devices such as ESP boards, Raspberry Pi Picos, 3D printers, CNC machines, and other microcontrollers directly from the web. It’s a long-awaited milestone for the maker and hardware community, and we’re excited to finally see it land in Firefox.
In this community spotlight, we feature Baurzhan Muftakhidinov, whose work has helped bring Firefox and many other open source projects to Kazakh users. His story is a testament to the power of persistence, community, and the importance of keeping smaller languages visible online.
Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.
2026-06-12T11:28:37Z2026-06-12T11:28:37ZRizki Kelimutuhttps://blog.mozilla.org/communityNews and notes from and for the Mozilla community.about:community2026-06-13T02:38:52Zhttps://blog.mozilla.org/netpolicy/?p=2583A Handful of Companies Control the Web. AICOA Can Change That.
Mozilla Champions the Reintroduction of the American Innovation and Choice Online Act (AICOA) Today, only a handful of tech companies shape the online experience for the more than 300 million … Read more
Mozilla Champions the Reintroduction of the American Innovation and Choice Online Act (AICOA)
Today, only a handful of tech companies shape the online experience for the more than 300 million internet users in America. This concentration of power is exactly why we need legislation that advances competition and user choice. It’s all the more urgent as AI transforms not just the tools that people use, but also magnifies the competitive inequities underlying the web itself.
The American Innovation and Choice Online Act (AICOA) is bipartisan legislation designed to curb harmful gatekeeper behaviors of the biggest tech platforms. The bill does so by prohibiting dominant platforms from unfairly preferencing their own products, discriminating against tech competitors, and preventing interoperability — all practices that stop the best product winning and stifle consumer control. The goal is straightforward: companies should compete based on the quality of their products, not by leveraging anticompetitive tactics.
As the builder and operator of the Firefox browser and the browser engine Gecko, Mozilla has firsthand experience with the impact of the exclusionary practices AICOA seeks to prevent. For example, deceptive design tactics deployed by operating systems make it difficult for people to install and keep Firefox as their preferred browser. Browsers are the portal through which people access the open web, and users should define that interaction. AICOA would help limit the ability of operating systems to steer users toward affiliated products through deceptive design choices. Ensuring meaningful user choice online is not just about variety; it reflects values and individual preferences. Openness and innovation thrives when the web is built around platforms that serve people, not the other way round.
Browser engines, while lesser-known, are among the most complex and consequential pieces of infrastructure on the modern internet, impacting user-focused innovations in privacy, security, speed, and more. Gecko is one of only three widely used engines and the only independent browser engine. The importance of that competitive counterweight cannot be underestimated. When platform owners favor their own vertically integrated products, independent challengers face barriers that have nothing to do with product quality and everything to do with a monopolized market.
It’s important to recognize that antitrust reform can make the internet more private and secure than it is today, as we’ve consistently emphasized. For example, in 2021, Firefox was at the forefront of developing technology against cross-site tracking, but could not release the technology to Firefox users on iOS because of app store rules preferring Apple’s own browser engine, blocking alternatives like Gecko.
We’re champions of AICOA and look forward to working with members of Congress to push this legislation forward and tackle longstanding anticompetitive practices. Mozilla thanks Senators Grassley and Klobuchar for their leadership in advancing competition. A thriving tech ecosystem requires an open, fair, and competitive market where innovative services can compete on merit and people can control their own experiences online.
2026-06-11T14:05:07Z2026-06-11T14:05:07ZJenn Taylor Hodges and Elise Phillipshttps://blog.mozilla.org/netpolicy/Mozilla's official blog on open Internet policy initiatives and developmentsOpen Policy & Advocacy2026-06-11T14:28:25Zurn:md5:d9bc121b18dd8c2d55bd20b310baa70bSpell-checking for more Firefox users — a community effort
A while back, I stumbled onto something that turned into a rewarding side-project at Mozilla.
Firefox ships with a built-in spellchecker, but it only activates if a dictionary for your language is bundled with the browser. Coverage had grown organically over the years — driven largely by localizers and community members adding support for their own languages. Dictionary work was actually very active in the early years of the Mozilla project, but like many things in a large open-source codebase with a lot to manage, it had quietly received less attention over time, for no particularly good reason. So I decided to change that.
Taking stock
I put together a full inventory dashboard of every third-party dictionary shipped in Firefox Desktop, cataloguing sources, upstream health, and — critically — licensing.
Licensing turns out to be the main bottleneck. Firefox is open-source software, so any dictionary we ship has to carry a licence compatible with the Mozilla codebase. Some excellent dictionaries exist for languages Firefox supports, but their licences don't allow direct inclusion. In those cases, the dictionary can still reach users — but only as a Firefox extension they have to find and install manually, rather than something that just works out of the box.
The goal of the inventory wasn't to point fingers at anything. It was to make the full picture visible, so that anyone who wanted to help would know exactly where to start.
Plugging into the community
Once the inventory existed, the work was really about connecting the right people. Mozilla's localizer community already had the expertise and motivation — what was sometimes missing was a clear entry point. I took care of all the patches myself, so that localizers wouldn't have to deal with the technical side of things. This work was done in coordination with Mozilla's Localization drivers team, who own the dictionary infrastructure and reviewed and merged the changes.
The results
We expanded the number of locales shipping with a built-in dictionary from 30 to 41. This shipped last week with Firefox 151.0.3, and these improvements also benefit Thunderbird users, since both applications share the same dictionary infrastructure.
New dictionaries added: Croatian, English (UK), Georgian, Persian, Slovenian, Tajik, Tamil, Tibetan, Turkish, Welsh, and Xhosa.
Part of the reason for doing this work publicly — building the inventory, filing the bugs, making the gaps visible — was to give people with the right expertise a reason to step in themselves. That's exactly what happened.
For Turkish and Russian, the existing open-source Hunspell dictionaries had become outdated — vocabulary and linguistic rules that hadn't kept pace with how the languages are actually used today. Selim (our Turkish l10n lead) and Valentin (our Russian l10n lead) each decided to take matters into their own hands.
Selim forked the TDD Turkish dictionary and updated it with modern vocabulary, better circumflex support, and performance improvements — the result is hunspell-tr-moz, now shipping in Firefox 151.0.3. Valentin built a new modern Russian dictionary from scratch, ru-spelling-dictionary, released under MPL-2.0. It's currently available as a Firefox extension — if you use Russian, Valentin would appreciate feedback on the quality before it's integrated directly into Firefox.
Both projects are public and open-source.
What's still in the pipeline
The licence question is also quietly resolving itself for a couple more locales. The maintainers of the Kabyle and Asturian dictionaries have agreed to relicense their work to allow direct inclusion in Firefox. Once that's done, those communities will join the list too.
There are still gaps in the inventory. Some are licence issues that may resolve over time. But for many of the remaining locales, the honest answer is that we simply haven't looked hard enough yet. Dictionaries are often individual passion projects or work coming out of linguistics circles — they exist, but finding them takes investigation. If you know of a dictionary for a language Firefox doesn't currently support, that's exactly the kind of lead worth following up on.
An open invitation
Mozilla is still a place where a motivated contributor can find a corner of the project, do meaningful work, and have a real impact — without needing to be a browser engineer or a Mozilla insider.
The inventory dashboard is public. If you're a localizer, a linguist, or a dictionary maintainer and you want to help bring spellchecking to more Firefox users, the gaps are clearly documented. And if you maintain a dictionary that could be included but licensing is an obstacle, that's a conversation worth having.
See you in May 2027 for the next update.
2026-06-11T13:59:44Z2026-06-11T12:57:00ZPascal Chevrelurn:md5:df119eb286679353063d080b01104a80Pascal ChevrelCarnet de notes - Mot-clé - InEnglish2026-06-12T09:25:12Ztag:this-week-in-rust.org,2026-06-10:/blog/2026/06/10/this-week-in-rust-655/This Week in Rust 655
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social …
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social, or
send us a pull request.
Want to get involved? We love contributions.
An important step for RFC implementation is for people to experiment with the
implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
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!
Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.
If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!
A fairly noisy week, with a bunch of small regressions contained within,
leading to a slight increase on average in instruction counts. This week had a
lot of large rollups, likely due to some CI problems, but thankfully many of
those came with pre-triaged perf results by the time (thank you to those
triagers!). Roughly similar slight regressions for cycles and wall times across
the week.
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.
2026-06-09T17:28:10Z2026-06-09T17:28:10Zdkl12026-06-12T10:58:52Zhttps://blog.mozilla.org/?p=86051Browse more privately all summer with Firefox’s free built-in VPN
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 […]
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.
2026-06-09T15:58:16Z2026-06-09T15:58:16ZMozillahttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zhttps://smallcultfollowing.com/babysteps/blog/2026/06/09/only-bounds/Only Bounds
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...
fnidentity<T>(t: T)-> T{t}// ...is actually short for
fnidentity<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:
fnby_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.1
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:
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.2
Problem: ?Sized notation doesn’t scale to this hierarchy
But now we have a kind of problem. The ?Sized notation was predicated3 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 leastMetadataSized.
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
fnby_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:
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
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:
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:
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>{fnor(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:
structRc<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
fnfoo<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 SizedorForgetbut 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 SizedxorForgetbut 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:
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.
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. ↩︎
2026-06-09T09:04:17Z2026-06-09T00:00:00Zhttps://smallcultfollowing.com/babysteps/Niko Matsakisrust@nikomatsakis.combaby steps2026-06-09T11:59:13Zdiscourse.mozilla.org-topic-148601MozPhab 2.15.2 Released
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
2026-06-08T18:41:50Z2026-06-08T18:41:50Zsheehan2026-06-12T10:58:52Zhttps://blog.mozilla.org/?p=86052Make Firefox your World Cup sidekick this summer
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 […]
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.
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.
“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.
2026-06-08T15:59:22Z2026-06-08T15:59:22ZMozillahttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zhttps://bluesock.org/~willkg/blog/dev/bleach_6_4_0_final_release.htmlBleach 6.4.0 releases -- final release
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.
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.
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.
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!
Will's Blog (Posts about mozilla)2026-06-05T13:54:02Zhttps://blog.nightly.mozilla.org/?p=2076More Kit, More Control – These Weeks in Firefox: Issue 203
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 … Read more
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.
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)
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)
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)
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.
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!
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!
2026-06-03T18:27:38Z2026-06-03T18:27:38ZKatherine Pateniohttps://blog.nightly.mozilla.orghttps://blog.nightly.mozilla.org/files/2024/04/cropped-Fx-Browser-Nightly-icon-fullColor-512-32x32.pngLet's improve quality, build after build!Firefox Nightly News2026-06-03T18:27:38Ztag:this-week-in-rust.org,2026-06-03:/blog/2026/06/03/this-week-in-rust-654/This Week in Rust 654
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social …
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social, or
send us a pull request.
Want to get involved? We love contributions.
An important step for RFC implementation is for people to experiment with the
implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
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!
Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.
If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!
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).
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.
2026-06-03T04:00:00Z2026-06-03T04:00:00ZTWiR Contributorshttps://this-week-in-rust.org/This Week in Rust2026-06-10T04:00:00Zhttps://blog.rust-lang.org/2026/06/02/launching-the-rust-foundation-maintainers-fund/Launching the Rust Foundation Maintainers Fund
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 maintainers1. 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 Sponsors2. 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. ↩
2026-06-02T00:00:00Z2026-06-02T00:00:00ZFunding teamhttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zhttps://blog.nightly.mozilla.org/?p=2075Backup for a Rainy Day – These Weeks in Firefox: Issue 202
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 … Read more
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)
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.
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
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)
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.
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
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
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.
Compare that to the bucketed data. 131 distinct values.
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.
2026-06-01T17:36:00Z2026-06-01T17:36:00Zhttp://ritter.vgTom RitterPersonal weblog and homepage of Tom Ritter. A smash and grab approach to technology.ritter.vg2026-06-12T10:58:50Zhttp://fitzgeraldnick.com/2026/06/01/structure-aware-fuzzing-experiment.htmlA Structure-Aware Fuzzing Experiment
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.1 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:
fngeneration_based_fuzzing<T>(// A test-case generator.generator:implFn()->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:implFn(&T)->FuzzResult,){loop{// Generate an input.letinput=generator();// Run the input through the system under test.letresult=run_system_under_test(&input);// If the system crashed, panicked, failed an// assertion, violated an invariant, or etc...// then report that to the user.ifletErr(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:
fnmutation_based_fuzzing<T>(// A corpus of test cases.corpus:&mutCorpus<T>,// A function to pseudo-randomly mutate an existing// input into a new input.mutate:implFn(&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:implFn(&T)->FuzzResult,){loop{// Choose an old test case from the corpus.letold_input=corpus.choose_one();// Pseudo-randomly mutate that old test case,// creating a new one.letinput=mutate(old_input);// Run the input through the system under test.letresult=run_system_under_test(&input);// If the system crashed, panicked, failed an// assertion, violated an invariant, or etc...// then report that to the user.ifletErr(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.ifresult.input_was_interesting(){corpus.insert(input);}}}
The two approaches are not mutually exclusive and hybrid generation- and
mutation-based fuzzers exist.
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.
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:
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 ...)/// .../// )/// )pubstructModule{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:
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.
implModule{pubfnfixup(&mutself,mutmake_value:implFnMut()->i64){// ...// The fixed-up instructions.letmutfixed=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.letmutstack:Vec<ValType>=Vec::new();forinstinmem::take(&mutself.instructions){// Special-case `drop` because it is// polymorphic.ifmatches!(inst,Inst::Drop){ifstack.is_empty(){fixed.push(ValType::I32.make_const(make_value()),);}else{stack.pop();}fixed.push(inst);continue;}// First clamp entity indices to valid// ranges.letSome(inst)=self.fixup_inst_immediates(&mutmake_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(&mutmake_value,&mutfixed,&mutstack,&inst,);// Finally, apply the effects to the stack.letlen_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;}fnfixup_stack(&mutself,mutmake_value:implFnMut()->i64,fixed:&mutVec<Inst>,stack:&mutVec<ValType>,inst:&Inst,){letneeded=inst.operand_types(&self.globals);letn=needed.len();ifstack.len()>=n{if(0..n).all(|i|{stack[stack.len()-n+i]==needed[i]}){// All needed operands are on the stack.return;}}else{ifstack.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.fortyin&needed[stack.len()..]{fixed.push(ty.make_const(make_value()));stack.push(*ty);}return;}}// Otherwise, just make constants for all the// needed operands.fortyinneeded{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.
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.
implModule{pubfnbottom_up(u:&mutUnstructured<'_>)->Result<Self>{// ...letmax_insts=u.int_in_range(1..=MAX_INSTS)?;letmutinstructions=Vec::new();letmutstack:Vec<ValType>=Vec::new();for_in0..max_insts{ifstack==result_types&&u.ratio(3,4)?{break;}// Choose a random instruction whose operand// types match those currently on the stack.letinst=choose_inst_bottom_up(u,&stack,¶m_types,&globals,num_memories,)?;// Apply this instruction's effects to the// stack.apply_inst(&inst,&mutstack,¶m_types,&globals,);instructions.push(inst);}// ...Ok(Module{param_types,result_types,globals,num_memories,instructions,})}}fnchoose_inst_bottom_up(u:&mutUnstructured<'_>,stack:&[ValType],param_types:&[ValType],globals:&[Global],num_memories:u32,)->Result<Inst>{// Build up all the valid candidate instructions.letmutcandidates: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));}// ...lettop=stack.last().copied();letsecond=stack.get(stack.len()-2).copied();// Drop needs 1 operand of any type: [t] -> []iftop.is_some(){candidates.push(Inst::Drop);}// i32 unary: [i32] -> [...]iftop==Some(I32){candidates.push(Inst::I32Clz);candidates.push(Inst::I32Ctz);candidates.push(Inst::I32Popcnt);// ...}// i64 unary: [i64] -> [...]iftop==Some(I64){candidates.push(Inst::I64Clz);candidates.push(Inst::I64Ctz);candidates.push(Inst::I64Popcnt);// ...}// ...// i32 binary: [i32 i32] -> [...]iftop==Some(I32)&&second==Some(I32){candidates.push(Inst::I32Add);candidates.push(Inst::I32Sub);candidates.push(Inst::I32Mul);// ...}// i64 binary: [i64 i64] -> [...]iftop==Some(I64)&&second==Some(I64){candidates.push(Inst::I64Add);candidates.push(Inst::I64Sub);candidates.push(Inst::I64Mul);// ...}// ...// Choose a random instruction from the// candidates.letmutinst=*u.choose(&candidates)?;// If the instruction has immediates, generate// them here, as they were hard-coded during// candidate selection.match&mutinst{Inst::I32Const(v)=>*v=u.arbitrary()?,Inst::I64Const(v)=>*v=u.arbitrary()?,// ...Inst::GlobalGet(g)=>{*g=u.int_in_range(0..=(globals.len()asu32-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.2
implModule{pubfntop_down(u:&mutUnstructured<'_>,)->Result<Self>{// ...letmax_insts=u.int_in_range(1..=MAX_INSTS)?;letmutinstructions=Vec::new();letmutneeded=result_types.clone();for_in0..max_insts{ifneeded.is_empty()&&u.ratio(3,4)?{break;}// Choose a random instruction in a// top-down manner.letinst=choose_inst_top_down(u,needed.last().copied(),¶m_types,&globals,num_memories,)?;// Pop the result type from `needed`, if// any, as it's been satisfied.letty=inst.result_type(¶m_types,&globals,);ifty==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[*gasusize].ty);}_=>{needed.extend_from_slice(inst.operand_types(&globals),);}}instructions.push(inst);}// Fill remaining needed types with// constants.fortyinneeded.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,})}}fnchoose_inst_top_down(u:&mutUnstructured<'_>,target_ty:Option<ValType>,param_types:&[ValType],globals:&[Global],num_memories:u32,)->Result<Inst>{letmutcandidates:Vec<Inst>=Vec::new();matchtarget_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);ifglobals.iter().any(|g|g.mutable){candidates.push(Inst::GlobalSet(0));}ifnum_memories>0{candidates.push(Inst::I32Store(0));// ...}}}letmutinst=*u.choose(&candidates)?;// If the instruction has immediates, generate// them here, as they were hard-coded during// candidate selection. Same as `bottom_up`.match&mutinst{// ...}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.
uselibfuzzer_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.ifseed.count_ones()%8==0{returnfuzzer_mutate(data,size,max_size);}// Try to decode using postcard; fallback to// default input on failure.letmutmodule:Module=postcard::from_bytes(&data[..size]).ok().unwrap_or_default();// Mutate with `mutatis`.letmutsession=mutatis::Session::new().seed(seed.into()).shrink(max_size<size);ifsession.mutate(&mutmodule).is_ok(){ifletOk(encoded)=postcard::to_slice(&module,data,){returnencoded.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.
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.3
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$alocal.get$blocal.get$ci32.muli32.addlocal.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 = temp1local.get$blocal.get$ci32.mullocal.set$temp0local.get$alocal.get$temp0i32.addlocal.set$temp1local.get$temp1local.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?
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. ↩
2026-06-01T07:00:00Z2026-06-01T07:00:00Zhttp://fitzgeraldnick.com/Nick FitzgeraldNick Fitzgerald2026-06-01T16:11:24Zhttps://blog.farre.se/posts/2026/06/01/session-history-diagrams/Session History Diagrams in Firefox DevTools
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 style1, 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 instead2.
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. ↩
2026-06-01T00:00:00Z2026-06-01T00:00:00Zhttps://blog.farre.se/tags/mozillaAndreas FarrePosts tagged "mozilla" on farre's blogmozilla — farre's blog2026-06-12T10:58:16Zhttps://blog.narf.ssji.net/?p=9762Optional Docker services and dependencies
Docker compose supports the use of profiles to start services conditionally or on-demand. This is useful to mark some services as optional. The use of `required: false` `depends_on` relationships allows to retain the startup ordering if needed. Continue reading →
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.
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.
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.
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
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.
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.
2026-05-31T11:58:49Z2026-05-31T11:58:49ZOlivier Mehanihttps://blog.narf.ssji.nethttps://blog.narf.ssji.net/wp-content/uploads/sites/3/2014/04/pouce.pngThe blagosphere got me...Mozilla - Narf2026-06-01T04:36:51Zhttps://servo.org/blog/2026/05/31/april-in-servo/April in Servo: new Android UI, focus, forms, security fixes, and more!
Servo 0.2.0 contains all of the changes we landed in April, which came out to yet another record 534 commits (March: 530).
For security fixes, see § Security.
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).
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).
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).
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).
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 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.
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:
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.
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 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.
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).
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).
when shadow roots are deeply nested, or when calling attachShadow() removes elements from the flat tree (@yezhizhen, @mrobinson, #43888, #43930, #44259)
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).
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 speedyCIandbenchmarkingservers, 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.
2026-05-31T00:00:00Zhttps://servo.orgServo Teaminfo@servo.orgAll the entries in the Servo blog.Servo Blog2026-05-31T00:00:00Ztag:frederikbraun.de,2026-05-31:/the-s-in-interoperability.htmlThe S in interoperability
This is a blog post about standards, their proliferation and the issues
that may arise.
My first involvement with standards was just as a reader. To
better understand complicated code or unexpected behavior in a protocol.
After a while, I also got involved and helped clarify certain things to ensure …
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 more1.
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.
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:
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:
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.
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!
2026-05-28T00:00:00Z2026-05-28T00:00:00ZThe Rust Release Teamhttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zdiscourse.mozilla.org-topic-148488New Deploy of PerfCompare (May 27th)
2026-05-27T21:29:33Z2026-05-27T21:29:33Zcsevere2026-06-12T10:58:53Ztag:this-week-in-rust.org,2026-05-27:/blog/2026/05/27/this-week-in-rust-653/This Week in Rust 653
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social …
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social, or
send us a pull request.
Want to get involved? We love contributions.
An important step for RFC implementation is for people to experiment with the
implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
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!
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!
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.
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.
2026-05-26T15:53:32Z2026-05-26T15:53:32Zcanova2026-06-12T10:58:53Zhttps://ahal.ca/blog/2026/integrate/Your New Job is Integrating Code
You felt it. The shift. That your role has fundamentally changed thanks to
LLMs. It first entered your subconscious when you realized how easily you can
now crank out PRs. You felt it more concretely (and less enthusiastically), as
a reviewer when you opened your laptop one morning and noticed your review
queue was double what it normally is thanks to everyone else cranking out PRs.
And you feel this pervasive, general sense of friction.
It’s difficult to pinpoint exactly where this friction is coming from.
Depending on the repository size and CI setup, it will be slightly different
for everyone. It might involve longer review times or slipping review
standards. You might be noticing more merge conflicts and merge related CI
failures. Perhaps there are more failures sneaking through to main or CI is
taking longer to give you results. You almost certainly feel the grind.
People are on edge, tired; developers are pulling in opposite directions.
Here’s what LLMs shifted. The bottleneck is no longer producing code. The
bottleneck is integrating it. The friction we’re feeling is a result of more
PRs, more ideas, more reviews, more disagreements all made possible thanks
to LLMs. In short, the problem can best be summarized by Figure 1:
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.
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 … Read more
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.
2026-05-26T08:04:08Z2026-05-26T08:04:08ZSvea Windwehr and Tasos Stampeloshttps://blog.mozilla.org/netpolicy/Mozilla's official blog on open Internet policy initiatives and developmentsOpen Policy & Advocacy2026-06-11T14:28:25Zhttps://jonalmeida.com/til/auto-resolve-conflicts-with-an-agent/Auto-resolve Jujutsu conflicts with your AI agent
With Jujutsu, I've been able to work in multiple workstreams more efficiently than before. This means that if I'm working on multiple things, there is a higher likelihood of something going stale while I wait for a review or touch multiple files.
Dealing with conflicts aren't so bad these days, however if I can automate the easy ones, why not?
This is the prompt I've been using with my agent whenever I have a list of changes that have conflicts and don't need me to participate actively on it.
Using the jj version control system, fix the conflicts that are in the changesets from `<start_rev>` to `<end_rev>`. Keep trying until there are no more "(conflict)" in the changesets between those two IDs.
2026-05-25T00:00:00Z2026-05-25T00:00:00ZJonathan Almeidahttps://jonalmeida.com/tags/mozilla/atom.xmlScribblings and nonsenseJonathan Almeida - mozilla2026-05-25T00:00:00Zhttps://blog.rust-lang.org/2026/05/25/cve-2026-5223/Security Advisory for Cargo (CVE-2026-5223)
The Rust Security Response Team was notified that Cargo incorrectly handled
symlinks inside of crate tarballs downloaded from third-party registries,
allowing a malicious crate to override the source code of another crate from the
same registry.
This vulnerability is tracked as CVE-2026-5223. The severity of the
vulnerability is medium for users of third-party registries. Users of
crates.io are not affected, as crates.io forbids uploading crates containing
any symlink.
Overview
When building a crate, Cargo extracts its source code in a local cache (stored
within ~/.cargo), reusing it for any future build. Cargo includes protections
to prevent any file from being extracted outside of the crate's own cache
directory.
It was discovered that it's possible to craft a malicious tarball able to
extract files one level below the crate's own cache directory. With the way the
cache is structured, that allowed the malicious crate to override the cache of
other crates belonging to the same registry.
Mitigations
Rust 1.96.0, to be released on May 28th, 2026, will update Cargo to reject
extracting any symlink within crate tarballs, regardless of whether they come
from crates.io (which already forbids them) or third-party registries. Note that
Cargo never added symlinks when running cargo package or cargo publish, so
the impact of this should be minimal.
Users who are not able to upgrade to the most recent Rust version are
recommended to audit the contents of their registry for the presence of any
symlink, and to configure their registry to reject symlink (if such option is
available).
Affected versions
All versions of Cargo shipped before Rust 1.96.0 are affected.
Acknowledgements
We'd like to thank Christos Papakonstantinou for reporting this to us according
to the Rust security policy.
We also want to thank the members of the Rust project who helped us address the
vulnerability: Josh Triplett for developing the fix; Arlo Siemsen for reviewing
the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and
Manish Goregaokar for coordinating the disclosure; Ed Page and Eric Huss for
advising during the disclosure.
2026-05-25T00:00:00Z2026-05-25T00:00:00ZRust Security Response Teamhttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zhttps://blog.rust-lang.org/2026/05/25/cve-2026-5222/Security Advisory for Cargo (CVE-2026-5222)
The Rust Security Response Team was notified that Cargo incorrectly normalized
the URLs of third-party registries using the sparse index protocol. If a
hosting provider allowed multiple registries to be hosted with arbitrary names
within the same domain, an attacker able to publish crates in a registry could
obtain the credentials of others users of the same registry.
This vulnerability is tracked as CVE-2026-5222. The severity of the
vulnerability is low, due to the extremely niche requirements needed to
achieve the attack.
Overview
Originally Cargo only supported storing a registry's index within git
repositories. Most git hosting solutions allow accessing a git repository with
or without the .git suffix, so Cargo mirrored this behavior when normalizing
registry URLs. This allowed credentials for https://example.com/index to be
used for https://example.com/index.git.
This normalization was unintentionally applied to the new sparse indexes too.
Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with
.git as different URLs than those without the suffix.
If the following conditions apply:
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.
2026-05-25T00:00:00Z2026-05-25T00:00:00ZRust Security Response Teamhttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zyt:video:wlRaTHhctrAData Club: Jeff Silverman - Data Science & Astronomy: AAS 243 & ATDS 62026-05-24T03:48:57Z2024-02-05T15:18:38ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zyt:video:aGjrXhXNRq8Introducing Glean AnnotationsLeif 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.2026-05-24T02:56:33Z2021-04-19T18:05:52ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zyt:video:BZVugz_yzzgMonitoring Sensitive Data: How do we monitor data we don't store?We try to be responsible with data. For example, we:
- store as little sensitive data as possible
- monitor changes in incoming data on which we've built models
But what happens when those two approaches conflict?
How do we monitor changes in incoming data that we don't want to store?
This talk explains the schema we use to monitor changes in what people are searching for in Firefox...even when we deliberately don't store some of what people are searching for.2026-05-21T18:30:49Z2022-09-12T16:28:17ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zhttps://blog.mozilla.org/?p=85966Mozilla and Adafruit bring Web Serial workflows to Firefox
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 […]
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.
2026-05-21T18:00:38Z2026-05-21T18:00:38ZBrian Binghamhttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zhttps://hacks.mozilla.org/?p=48329Announcing Web Serial Support in Firefox
Support for Web Serial in Firefox 151 for Desktop Firefox can now connect directly to microcontrollers, development boards, 3D printers, power meters, and other serial-connected hardware from the web. Starting in Firefox 151 for Desktop, support for the Web Serial API allows web applications to communicate with compatible devices without requiring native software. Web Serial […]
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.
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.
2026-05-21T18:00:05Z2026-05-21T18:00:05ZHaik Aftandilianhttps://hacks.mozilla.org/hacks.mozilla.orgMozilla Hacks – the Web developer blog2026-05-21T18:30:22Zhttps://blog.mozilla.org/?p=85786Designing Firefox for the future
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 […]
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.
2026-05-21T12:55:53Z2026-05-21T12:55:53ZFirefox UX Teamhttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zyt:video:y7msgjoLjNkMozillians sharing the 2021 SciPy Conference experienceThe 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.2026-05-20T21:10:21Z2021-09-21T19:58:42ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zhttps://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjsSaying goodbye to asm.js
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
2026-05-20T17:00:00Z2026-05-20T17:00:00ZRyan Hunthttps://spidermonkey.dev/feed.xmlSpiderMonkey is Mozilla's JavaScript and WebAssembly Engine, used in Firefox, Servo and various other projects. It is written in C++ and Rust.SpiderMonkey JavaScript/WebAssembly Engine2026-05-20T11:56:51Zhttps://blog.nightly.mozilla.org/?p=2064Settings Are Getting a New Look!
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 … Read more
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
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!
2026-05-20T15:53:01Z2026-05-20T15:53:01Ztaleehttps://blog.nightly.mozilla.orghttps://blog.nightly.mozilla.org/files/2024/04/cropped-Fx-Browser-Nightly-icon-fullColor-512-32x32.pngLet's improve quality, build after build!Firefox Nightly News2026-06-03T18:27:38Ztag:this-week-in-rust.org,2026-05-20:/blog/2026/05/20/this-week-in-rust-652/This Week in Rust 652
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social …
Hello and welcome to another issue of This Week in Rust!
Rust is a programming language empowering everyone to build reliable and efficient software.
This is a weekly summary of its progress and community.
Want something mentioned? Tag us at
@thisweekinrust.bsky.social on Bluesky or
@ThisWeekinRust on mastodon.social, or
send us a pull request.
Want to get involved? We love contributions.
An important step for RFC implementation is for people to experiment with the
implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
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!
Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.
If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!
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.
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.
2026-05-20T04:00:00Z2026-05-20T04:00:00ZTWiR Contributorshttps://this-week-in-rust.org/This Week in Rust2026-06-10T04:00:00Zhttps://jonalmeida.com/blog/firefox-android-studio-setup/My Firefox for Android local build environment
The Firefox for Android app has always had a complicated build process - we're cramping a complex cross-platform browser engine and all the related components that make it work on Android into one package. In its current form, it lives in the Firefox mono-repo at mozilla-central (now mozilla-firefox using the git repository).
I wanted to document my "artifact-mode" environment here since it's worked quite successfully for me for many years with minor changes.
NOTE: After a fresh clone of the mono-repo, don't forget to first run and follow the prompts of ./mach bootstrap .
mozconfig
My mozconfig below is enabled for artifact mode, but occasionally I switch between various configurations. You can see those commented out, with these few extra notes:
I like to separate out my objdirs to avoid cache pollution between the different build types. I think you can get away without needing to specify this and an objdir for your build type and arch will be generated.
sccache speeds up the native portion of full builds after the first slow one, but it's a hit or miss if you fetch from the remote repository but don't need to rebuild as often.
I don't care to manually run the clobber step, and I don't truly appreciate why that isn't always automatically done.
# Build GeckoView/Firefox for Android:ac_add_options --enable-application=mobile/android# Targeting the following architecture.# For regular phones, no --target is needed.# For x86 emulators (and x86 devices, which are uncommon):# ac_add_options --target=i686# For newer phones or Apple siliconac_add_options --target=aarch64# For x86_64 emulators (and x86_64 devices, which are even less common):# ac_add_options --target=x86_64# sccache will significantly speed up your builds by caching# compilation results. The Firefox build system will download# sccache automatically.# This only works for non-artifact builds.#ac_add_options --with-ccache=sccache# Enable artifact builds; manager-mode.ac_add_options --enable-artifact-builds# Write build artifacts to..## Full build dir#mk_add_options MOZ_OBJDIR=./objdir-droid#mk_add_options MOZ_OBJDIR=./objdir-desktop## Artifact buildsmk_add_options MOZ_OBJDIR=./objdir-frontend# Automatic clobbering; don't ask me.mk_add_options AUTOCLOBBER=1
JAVA_HOME
Sometimes you might find yourself needing to run a (non-mach) command in the terminal. Those typically will need to invoke some parts of gradle for an Android build, so it's best to make sure those are using the same JDK as the bootstrapped one in the mono-repo. This avoids weird build errors where something that compiles in one place isn't working in another (like Android Studio).
The location for the JDKs are typically in ~/.mozbuild/jdk/, and if you've between around for ~6 months you end up with multiple versions after every JDK bump:
$ ls -l ~/.mozbuild/jdk/drwxr-xr-x@ - jalmeida 15 Apr 2025 jdk-17.0.15+6drwxr-xr-x@ - jalmeida 15 Jul 2025 jdk-17.0.16+8drwxr-xr-x@ - jalmeida 21 Oct 2025 jdk-17.0.17+10drwxr-xr-x@ - jalmeida 20 Jan 09:00 jdk-17.0.18+8drwxr-xr-x@ - jalmeida 26 Feb 15:04 mozboot
You can find some way to point your latest JDK to one location or you can be lazy like me and pick the latest version to assign as your JAVA_HOME property by adding this to your shell's RC file:
export JAVA_HOME="$(ls -1dr -- $HOME/.mozbuild/jdk/jdk-* | head -n 1)/Contents/Home"
Android Studio
UPDATE: With D286123 landed, this should no longer be necessary! 🎉
Similarly for Android Studio, let's do the same so that environment is identical. Head to, Settings | Build, Execution, Deployment | Build Tools | Gradle, and ensure that "Gradle JDK" path is set to JAVA_HOME.
Lately, the default seems to be for it to follow GRADLE_LOCAL_JAVA_HOME which is a property we can't easily override, so we have to manually set this ourselves.
Using the same Android SDK also helps speed things up and avoids source confusion. You can typically find it in ~/.mozbuild/android-sdk-macosx and update it at Settings | Languages & Frameworks | Android SDK.
Debugging
This section is for miscellaneous build error situations that come-up, but assuming mach build work and there are no known Android build changes, my solution has typically always been the same.
For example, the other day I fetched another engineers patch to test out locally1 as part of reviewing it where I faced the error message below:
Execution failed for task ':components:feature-pwa:compileDebugKotlin'.
FAILURE: Build failed with an exception.* What went wrong:Execution failed for task ':components:feature-pwa:compileDebugKotlin'.> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction > Internal compiler error. See log for more details* Try:> Run with --info or --debug option to get more log output.> Run with --scan to generate a Build Scan (powered by Develocity).> Get more help at https://help.gradle.org.* Exception is:org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':components:feature-pwa:compileDebugKotlin'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:135) at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:288) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:133) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:121) at org.gradle.api.internal.tasks.execution.ProblemsTaskPathTrackingTaskExecuter.execute(ProblemsTaskPathTrackingTaskExecuter.java:41) at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:74) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:209) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52) at org.gradle.execution.plan.DefaultNodeExecutor.executeLocalTaskNode(DefaultNodeExecutor.java:55) at org.gradle.execution.plan.DefaultNodeExecutor.execute(DefaultNodeExecutor.java:34) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:355) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:343) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.lambda$execute$0(DefaultTaskExecutionGraph.java:339) at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:84) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:339) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:328) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:459) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:376) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)Caused by: org.gradle.workers.internal.DefaultWorkerExecutor$WorkExecutionException: A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction at org.gradle.workers.internal.DefaultWorkerExecutor$WorkItemExecution.waitForCompletion(DefaultWorkerExecutor.java:289) at org.gradle.internal.work.DefaultAsyncWorkTracker.lambda$waitForItemsAndGatherFailures$2(DefaultAsyncWorkTracker.java:130) at org.gradle.internal.Factories$1.create(Factories.java:33) at org.gradle.internal.work.DefaultWorkerLeaseService.lambda$withoutLocks$2(DefaultWorkerLeaseService.java:344) at org.gradle.internal.work.ResourceLockStatistics$1.measure(ResourceLockStatistics.java:42) at org.gradle.internal.work.DefaultWorkerLeaseService.withoutLocks(DefaultWorkerLeaseService.java:342) at org.gradle.internal.work.DefaultWorkerLeaseService.withoutLocks(DefaultWorkerLeaseService.java:326) at org.gradle.internal.work.DefaultWorkerLeaseService.withoutLock(DefaultWorkerLeaseService.java:331) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForItemsAndGatherFailures(DefaultAsyncWorkTracker.java:126) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForItemsAndGatherFailures(DefaultAsyncWorkTracker.java:92) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForAll(DefaultAsyncWorkTracker.java:78) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForCompletion(DefaultAsyncWorkTracker.java:66) at org.gradle.api.internal.tasks.execution.TaskExecution$3.run(TaskExecution.java:260) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47) at org.gradle.api.internal.tasks.execution.TaskExecution.executeAction(TaskExecution.java:237) at org.gradle.api.internal.tasks.execution.TaskExecution.executeActions(TaskExecution.java:220) at org.gradle.api.internal.tasks.execution.TaskExecution.executeWithPreviousOutputFiles(TaskExecution.java:203) at org.gradle.api.internal.tasks.execution.TaskExecution.execute(TaskExecution.java:170) at org.gradle.internal.execution.steps.ExecuteStep.executeInternal(ExecuteStep.java:105) at org.gradle.internal.execution.steps.ExecuteStep.access$000(ExecuteStep.java:44) at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:59) at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:56) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:209) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53) at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:56) at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:44) at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:42) at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:75) at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:55) at org.gradle.internal.execution.steps.PreCreateOutputParentsStep.execute(PreCreateOutputParentsStep.java:50) at org.gradle.internal.execution.steps.PreCreateOutputParentsStep.execute(PreCreateOutputParentsStep.java:28) at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:68) at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:38) at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:61) at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:26) at org.gradle.internal.execution.steps.CaptureOutputsAfterExecutionStep.execute(CaptureOutputsAfterExecutionStep.java:69) at org.gradle.internal.execution.steps.CaptureOutputsAfterExecutionStep.execute(CaptureOutputsAfterExecutionStep.java:46) at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:39) at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:28) at org.gradle.internal.execution.steps.BuildCacheStep.executeWithoutCache(BuildCacheStep.java:189) at org.gradle.internal.execution.steps.BuildCacheStep.lambda$execute$1(BuildCacheStep.java:75) at org.gradle.internal.Either$Right.fold(Either.java:176) at org.gradle.internal.execution.caching.CachingState.fold(CachingState.java:62) at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:73) at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:48) at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:46) at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:35) at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:75) at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$2(SkipUpToDateStep.java:53) at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:53) at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:35) at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:37) at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:27) at org.gradle.internal.execution.steps.ResolveIncrementalCachingStateStep.executeDelegate(ResolveIncrementalCachingStateStep.java:49) at org.gradle.internal.execution.steps.ResolveIncrementalCachingStateStep.executeDelegate(ResolveIncrementalCachingStateStep.java:27) at org.gradle.internal.execution.steps.AbstractResolveCachingStateStep.execute(AbstractResolveCachingStateStep.java:71) at org.gradle.internal.execution.steps.AbstractResolveCachingStateStep.execute(AbstractResolveCachingStateStep.java:39) at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:64) at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:35) at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:62) at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:40) at org.gradle.internal.execution.steps.AbstractCaptureStateBeforeExecutionStep.execute(AbstractCaptureStateBeforeExecutionStep.java:76) at org.gradle.internal.execution.steps.AbstractCaptureStateBeforeExecutionStep.execute(AbstractCaptureStateBeforeExecutionStep.java:45) at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.executeWithNonEmptySources(AbstractSkipEmptyWorkStep.java:136) at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.execute(AbstractSkipEmptyWorkStep.java:66) at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.execute(AbstractSkipEmptyWorkStep.java:38) at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38) at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:36) at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:23) at org.gradle.internal.execution.steps.HandleStaleOutputsStep.execute(HandleStaleOutputsStep.java:75) at org.gradle.internal.execution.steps.HandleStaleOutputsStep.execute(HandleStaleOutputsStep.java:41) at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.lambda$execute$0(AssignMutableWorkspaceStep.java:35) at org.gradle.api.internal.tasks.execution.TaskExecution$4.withWorkspace(TaskExecution.java:297) at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.execute(AssignMutableWorkspaceStep.java:31) at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.execute(AssignMutableWorkspaceStep.java:22) at org.gradle.internal.execution.steps.ChoosePipelineStep.execute(ChoosePipelineStep.java:40) at org.gradle.internal.execution.steps.ChoosePipelineStep.execute(ChoosePipelineStep.java:23) at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.lambda$execute$2(ExecuteWorkBuildOperationFiringStep.java:67) at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.execute(ExecuteWorkBuildOperationFiringStep.java:67) at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.execute(ExecuteWorkBuildOperationFiringStep.java:39) at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:46) at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:34) at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:44) at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:31) at org.gradle.internal.execution.impl.DefaultExecutionEngine$1.execute(DefaultExecutionEngine.java:64) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:132) ... 30 moreCaused by: org.jetbrains.kotlin.gradle.tasks.FailedCompilationException: Internal compiler error. See log for more details at org.jetbrains.kotlin.gradle.tasks.TasksUtilsKt.throwExceptionIfCompilationFailed(tasksUtils.kt:22) at org.jetbrains.kotlin.compilerRunner.GradleKotlinCompilerWork.run(GradleKotlinCompilerWork.kt:112) at org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction.execute(GradleCompilerRunnerWithWorkers.kt:75) at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:68) at org.gradle.workers.internal.NoIsolationWorkerFactory$1$1.create(NoIsolationWorkerFactory.java:64) at org.gradle.workers.internal.NoIsolationWorkerFactory$1$1.create(NoIsolationWorkerFactory.java:61) at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:100) at org.gradle.workers.internal.NoIsolationWorkerFactory$1.lambda$execute$0(NoIsolationWorkerFactory.java:61) at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:44) at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:41) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:209) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53) at org.gradle.workers.internal.AbstractWorker.executeWrappedInBuildOperation(AbstractWorker.java:41) at org.gradle.workers.internal.NoIsolationWorkerFactory$1.execute(NoIsolationWorkerFactory.java:58) at org.gradle.workers.internal.DefaultWorkerExecutor.lambda$submitWork$0(DefaultWorkerExecutor.java:176) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runExecution(DefaultConditionalExecutionQueue.java:194) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.access$700(DefaultConditionalExecutionQueue.java:127) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner$1.run(DefaultConditionalExecutionQueue.java:169) at org.gradle.internal.Factories$1.create(Factories.java:33) at org.gradle.internal.work.DefaultWorkerLeaseService.lambda$withLocksAcquired$0(DefaultWorkerLeaseService.java:269) at org.gradle.internal.work.ResourceLockStatistics$1.measure(ResourceLockStatistics.java:42) at org.gradle.internal.work.DefaultWorkerLeaseService.withLocksAcquired(DefaultWorkerLeaseService.java:267) at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:259) at org.gradle.internal.work.DefaultWorkerLeaseService.runAsWorkerThread(DefaultWorkerLeaseService.java:127) at org.gradle.internal.work.DefaultWorkerLeaseService.runAsWorkerThread(DefaultWorkerLeaseService.java:132) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runBatch(DefaultConditionalExecutionQueue.java:164) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.run(DefaultConditionalExecutionQueue.java:133) ... 2 more
The full trace was long and didn't seem related to a code failure in the module itself. So I employed the solution, which is always the same:
./mach build
In Android Studio, File > Sync Project with Gradle Files.
Yup, that's all. Very simple and boring.
1
With Jujutsu, this is the moz-phab command I use which has made it easier to manage review patches: moz-phab patch <patch-id> --no-branch --apply-to main@origin
Comments
With an account on the Fediverse or Mastodon, you can respond to this post. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. Known non-private replies are displayed below.
Learn how this was implemented from the original source here.
<noscript><p>Loading comments relies on JavaScript. Try enabling JavaScript and reloading, or visit <a href="https://mindly.social/@jonalmeida/116197244320129422">the original post</a> on Mastodon.</p></noscript>
<noscript>You need JavaScript to view the comments.</noscript>
&>"'
2026-05-19T16:21:23Z2026-03-05T00:00:00ZJonathan Almeidahttps://jonalmeida.com/tags/mozilla/atom.xmlScribblings and nonsenseJonathan Almeida - mozilla2026-05-25T00:00:00Zhttps://blog.mozilla.org/?p=84862A free VPN you can trust, now built into Firefox
Update on May 19, 2026: Firefox’s free built-in VPN now supports location selection, giving people access to a fully comprehensive VPN experience directly within the browser. Starting today, Firefox users in the U.S., U.K., France, Germany, and Canada can choose to browse from any of the countries where we’ve launched VPN support. Browsing is subject […]
Update on May 19, 2026: Firefox’s free built-in VPN now supports location selection, giving people access to a fully comprehensive VPN experience directly within the browser. Starting today, Firefox users in the U.S., U.K., France, Germany, and Canada can choose to browse from any of the countries where we’ve launched VPN support. Browsing is subject to the local laws and content restrictions of the selected region.
Original post from March 2026:
Today we’re introducing a free built-in VPN in Firefox, a new IP-protection feature designed to keep you even more private while you browse. We’re starting by offering an industry-leading 50 gigabytes of free VPN-browsing each month.
Firefox has long focused on building privacy tools directly into the browser to protect you online. Over the years, we’ve introduced world-class protections that block known trackers, reduce fingerprinting and limit how companies can follow people across the web. Our goal has been consistent: make meaningful privacy protections accessible to Firefox users every day.
Firefox is the only major browser to include a built-in VPN like this for free — giving you more control over your privacy, right where you browse.
Privacy built into the browser
Every time you visit a website, your IP address is shared automatically. IP addresses help websites know where to send information back to your device, but they can also be used to approximate your location, link your browsing activity across sites and keep logs about your online behavior, meaning websites can track your behavior. It’s one of many ways companies track activity across the internet.
Additionally, when you’re using public Wi-Fi while at a coffee shop, in a hotel, or in your dorm, people can spy on your network traffic and see which websites you might be visiting.
At Mozilla, we believe people should have stronger protections against this kind of tracking and spying, and that those protections should be easy to use.
Introducing built-in VPN
Our free built-in VPN is designed to make IP protection simple to use in Firefox.
The built-in VPN includes an unprecedented 50 GB per month of free VPN browsing, enough to cover everyday activities like shopping, banking, and reading.
Turn it on in Firefox with a single click. No extra apps. No downloads. Once it’s on, Firefox routes your browsing traffic through a proxy network that replaces your IP address before it reaches a website. The sites you visit see the proxy’s IP address rather than your own. Firefox already encrypts your traffic with HTTPS, but masking your IP adds another layer of privacy. You can mask the URLs you’re visiting from anyone trying to spy on your network traffic on public Wi-Fi, like while you’re enjoying a latte at your favorite coffee shop.
If you reach the monthly limit, IP protection is paused until the next cycle. Firefox will require you to confirm before proceeding without the VPN so your browsing doesn’t unintentionally continue without IP protection.
Browser-level protection and full-device protection
The free built-in VPN helps secure your traffic while browsing in Firefox, making it a simple way to protect your IP address from being tracked by big tech. However, it does not offer full device protection.
For those looking for broader coverage, you can also choose protection that extends across your entire device, including other apps. The standalone Mozilla VPN subscription offers this capability with unlimited data across multiple devices. Depending on your needs, you can pick the level of privacy and protection that suits you.
We’ve heard concerns about so-called “free VPNs,” which often rely on advertising or selling user data to generate revenue. Firefox’s built-in VPN is designed differently. It does not sell your browsing data and does not inject advertising into your traffic. Instead, we offer a limited amount of browser-level protection for free, alongside Mozilla VPN, our paid, unlimited, full-device VPN service.
The free built-in VPN is currently rolling out as a beta to Firefox desktop users in the United States, the United Kingdom, Germany and France, with plans to expand to additional countries coming soon over the next several releases.
As with many Firefox features, we’re introducing it gradually starting in Firefox 149 so we can learn from user feedback and continue improving the experience.
Building a more private web
Protecting privacy online is an ongoing effort. As the web evolves, new technologies create both opportunities and challenges for keeping personal information safe.
Mozilla has spent years building privacy protections — from Total Cookie Protection to Private browsing mode to anti-fingerprinting — directly into Firefox so people have more control over how they experience the web. This built-in VPN is one more way Firefox helps you browse with less exposure and more peace of mind.
By continuing to build these protections into Firefox, we aim to make the web safer, more transparent and more respectful of the people who use it.
2026-05-19T16:12:27Z2026-05-19T16:12:27ZAdam Fishmanhttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zhttps://blog.mozilla.org/?p=85656New in Firefox 151: VPN location selection, AI controls on mobile, and expanded Shake to Summarize support
Today, Firefox is rolling out updates across desktop and mobile that give you more choice over how you browse. Here’s a look at what’s new. Adding location selection to Firefox’s free VPN Firefox now offers a fully featured VPN experience directly in the browser — for free. In just two months, over 1 million users […]
Today, Firefox is rolling out updates across desktop and mobile that give you more choice over how you browse.
Here’s a look at what’s new.
Adding location selection to Firefox’s free VPN
Firefox now offers a fully featured VPN experience directly in the browser — for free. In just two months, over 1 million users have already signed up to try it.
With the addition of location selection, one of the most requested features from the Firefox community, Firefox’s free built-in VPN now delivers all the flexibility and functionality people expect from a modern VPN.
Starting today, Firefox users in the U.S., U.K., France, Germany, and Canada can choose to browse from any of the countries where we’ve launched VPN support. Whether you want to view local news, shop regionally, or see how content appears in another country, location selection gives you more control over where your connection appears from online.
Firefox will recommend the location closest to you by default, but people can switch locations at any time. Additional locations are planned for future releases. Browsing will still be subject to the local laws and content restrictions of the selected region.
Available in Firefox 151.
More controls over AI features on mobile
You can now decide how AI shows up in your Firefox mobile browsing experience, with more control over which AI features to activate and more ways to use them across devices and languages.
After launching AI controls on desktop earlier this year, Firefox is bringing them to iOS and Android. Depending on your device and region, available controls include features like translations, voice search and Shake to Summarize. Preferences can be updated at any time, making it easy to keep only the tools you want to use as new AI-powered features arrive in Firefox.
Shake to Summarize, recognized by TIME as one of the Best Inventions of 2025, helps you cut to the chase on mobile webpages by generating a simple summary with a flick of your wrist. The feature is now expanding to Android devices, with English rolling out first and additional languages coming soon. Shake to Summarize is now available on iOS in English, German, French, Spanish, Portuguese, Italian, and Japanese, giving more people the option to use it in the language that works best for them.
AI controls are available on iOS and Android. Shake to Summarize is available on Android in English and on iOS in English, German, French, Spanish, Portuguese, Italian, and Japanese.
A one-click reset for Private Browsing
Finished shopping for a surprise gift or logging into a temporary account? A new flame-shaped “Clear Private Session” button, located to the right of the address bar, instantly clears your current private session and starts a new one without requiring you to close and reopen the browser. Cookies, browsing history, logins, and other session data from your private windows are deleted automatically. Read more in this week’s release notes.
Try it out in Firefox 151.
Coming soon in Nightly: A refreshed settings page
Firefox is previewing a redesigned settings page in Nightly that makes it easier to find the controls you’re looking for and move through settings more intuitively. The redesign introduces improved navigation, clearer organization, and updated labels and descriptions designed to make customization easier.
Existing settings and preferences will remain unchanged, and the updated search experience helps people quickly find settings that may appear in new sections.
This will be enabled by default for Nightly users starting later this week.
Download the latest version of Firefox to explore what’s new and share feedback with us on Mozilla Connect.
2026-05-19T16:06:59Z2026-05-19T16:06:59ZMozillahttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zhttps://blog.mozilla.org/?p=85624AI controls are here for Firefox mobile
Mobile browsing is personal. It’s the link you open from a group chat because someone said, “Wait, is this real?” It’s the article you read in the few quiet minutes you have to yourself. It’s the review you skim before buying something you’ve been thinking about all week. On a phone, browsing follows you through […]
Mobile browsing is personal. It’s the link you open from a group chat because someone said, “Wait, is this real?” It’s the article you read in the few quiet minutes you have to yourself. It’s the review you skim before buying something you’ve been thinking about all week.
On a phone, browsing follows you through the day, from the first thing you look up in the morning to the last tab you close at night. So when AI features are part of the experience, you should have a clear way to choose what helps and what stays off.
That’s why we’re bringing AI controls – a popular desktop feature on Firefox – to iOS and Android users. AI controls let you turn off Firefox’s AI features entirely, enable only the ones you want or adjust your choices later. The feature rolls out on mobile on May 19.
AI features you can choose on Firefox mobile
What you see may vary by device and location, but AI controls in Firefox mobile let you turn on or off features, including website translations and voice searchon Android, and translations and Shake to Summarize on iOS, where available.
As Firefox adds new features, you can come back to your settings and choose what works for you.
Mobile browsing on your terms
As AI becomes a bigger part of the web, the question isn’t just what it can do. It’s how much control people have over it.
In Firefox mobile, AI can help make browsing easier, from finding what you need to understanding pages faster. But Firefox isn’t just adding AI features. We’re adding the controls, too.
Decide how AI fits into your experience. Try the features you want. Turn off the ones you don’t. Keep browsing on your terms.
2026-05-19T16:01:58Z2026-05-19T16:01:58ZMozillahttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zhttps://fxdx.dev/?p=544Firefox WebDriver Newsletter 151Firefox 151 adds window management support, worker realms, enhanced touch pointer angle simulation, and several bug fixes for WebDriver BiDi and Marionette.
WebDriver is a remote control interface that enables introspection and control of user agents. As such, it can help developers to verify that their websites are working and performing well with all major browsers. The protocol is standardized by the W3C and consists of two separate specifications: WebDriver classic (HTTP) and the new WebDriver BiDi (Bi-Directional).
This newsletter gives an overview of the work we’ve done as part of the Firefox 151 release cycle.
Contributions
Firefox is an open source project, and we are always happy to receive external code contributions to our WebDriver implementation. We want to give special thanks to everyone who filed issues, bugs and submitted patches.
In Firefox 151, Armin Ulrich contributed a fix to WebDriver BiDi:
Implemented the browser.setClientWindowState command. This command allows clients to change the OS-level window state of a browser window, such as maximized, minimized, fullscreen, or normal. It also allows repositioning and resizing the window.
2026-05-19T14:00:00Z2026-05-19T14:00:00ZHenrik Skupinhttps://fxdx.devhttps://fxdx.dev/files/2023/04/cropped-Fx-Browser-Developer-icon-fullColor-512-32x32.pngYour Go-To Resource for Web Development & CompatibilityFirefox Developer Experience2026-05-18T10:42:51Zhttps://blog.mozilla.org/?p=85623Firefox’s Shake to Summarize expands to Android and new languages on iOS
Don’t let bloated websites slow you down. When you just need the gist, scrolling through ads and filler content can turn a quick check into an endless scroll. Firefox’s Shake to Summarize feature solves that. We first launched it on iOS in English last September, earning a special mention in TIME’s Best Inventions of 2025 […]
Don’t let bloated websites slow you down. When you just need the gist, scrolling through ads and filler content can turn a quick check into an endless scroll.
Firefox’s Shake to Summarize feature solves that. We first launched it on iOS in English last September, earning a special mention in TIME’s Best Inventions of 2025 and a strong response from users. Since then, we’ve expanded it to iOS users in German, French, Spanish, Portuguese, Italian and Japanese. Starting today, we’re bringing it to Android users in English, with more languages coming soon.
Get the gist in seconds
On any web page under 5,000 words, just shake your phone and a clean summary will instantly appear.
If you prefer tapping, you can select Summarize Page under More in the three-dot menu.
Powered by AI, protected by Firefox
To keep your data secure, Shake to Summarize uses different technology depending on your device:
On iPhone 15 Pro or later (running iOS 26+): Your summary is generated right on your device using Apple Intelligence.
On all other devices: Your text is sent securely to Mozilla’s cloud-based AI. We power this with Mistral-Small, an AI model carefully selected for its speed, efficiency, and alignment with an open internet
Your phone’s default browser leaves you stuck scrolling through cluttered pages and content overload.
The Firefox mobile team is taking a purposeful approach – with smart tools that respect your time, privacy and choices. Download Firefox today to try Shake to Summarize, and get ready for even more features designed to help you move faster and protect your focus.
2026-05-19T07:00:27Z2026-05-19T07:00:27ZMozillahttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zhttps://blog.rust-lang.org/2026/05/18/project-goals-2026-04/Project goals update — April 2026 (end of 2025H2)
The 2025H2 Project Goal period has now concluded. Over these months, the Rust Project pursued 41 Project Goals, 13 of which were designated as Flagship Goals. This post contains curated updates on our progress since the last post and the final status for each of the goals (many of which continue as part of the 2026 period). Full details for any particular goal are available in its tracking issue.
Self-reviewed Implement borrowck for &pin mut|const $place. Found that the current approach of handling pinned borrows may be incorrect, as it failed to distinguish a pinned borrow from a coercion of a normal-to-pinned reference. The latter doesn't prevent a T: Unpin type from being moved, but the former does, which breaks the pin coercion test.
At the beginning of December, we set out to answer five important questions regarding the virtual places approach. We discussed four questions and arrived at answers for three.
Earlier this month, NadrierilDing Xiang Fei and I held a meeting on autoref and method resolution in a world with field projections. This meeting resulted in a new page for the wiki on autoref.
The first pull request of the lang experiment has just been merged: rust-lang/rust#152730
This PR enables the use of the field_of! macro to obtain a unique type for each field of a struct, enum variant, tuple, or union. We call these types field representing types (FRTs). When the base type is a struct that is not repr(packed), only contains Sized fields, this type automatically implements the Field trait that exposes some information about the field to the type system. The offset in bytes from the start of the struct, the type of the field and the type of the base type.
The feature is still incomplete and highly experimental. We also want to tackle the limitations in future PRs. For the moment this is enough to give us the ability to experiment with library versions of field projections and write functions that are generic over the fields of structs. For example one can write code like this:
#![feature(field_projections)]use std::field::{Field, field_of};use std::ptr;fn project_ref<'a, T, F: Field<Base = T>>(r: &'a T) -> &'a F::Type { // SAFETY: the `Field` trait guarantees that this is sound. unsafe { &*ptr::from_ref(r).byte_add(F::OFFSET).cast() }}struct Struct { field: i32, other: u32,}fn main() { let s = Struct { field: 42, other: 24 }; let r = &s; let field = project_ref::<_, field_of!(Struct, field)>(r); let other = project_ref::<_, field_of!(Struct, other)>(r); println!("field: {field}"); // prints 42 println!("other: {other}"); // prints 24}
A very important feature of the types returned by field_of! is that you can implement traits for them if you own the base type. This allows anointing fields with information by extending the Field trait. For example, this allows encoding the property of being a structurally pinned field:
use std::pin::Pin;unsafe trait PinnableField: Field { type StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a; fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a;}fn project_pinned<'a, T, F>(r: Pin<&'a mut T>) -> <F as PinnableField>::StructuralRefMut<'a>where F: PinnableField<Base = T>,{ F::project_mut(r)}
We can then implement this extra trait for all of the fields of our struct (and automate that with a proc-macro):
unsafe impl PinnableField for field_of!(Struct, field) { type StructuralRefMut<'a> = &'a mut i32; fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a, { let base = unsafe { Pin::into_inner_unchecked(base) }; &mut base.field }}unsafe impl PinnableField for field_of!(Struct, other) { type StructuralRefMut<'a> = Pin<&'a mut u32>; // u32 is `Unpin`, so this isn't doing anything special, but it highlights the pattern. fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a, { let base = unsafe { Pin::into_inner_unchecked(base) }; unsafe { Pin::new_unchecked(&mut base.other) } }}
Now you can safely obtain a pinned mutable reference to other and a normal mutable reference to field by calling the project_pinned function and supplying the correct FRT.
We have an updated plan for this goal in 2026 consisting of three major steps:
a-mir-formality,
Implementation,
Experimentation.
Some of their subtasks depend on other subtasks for other steps. You can find the details in the updated tracking issue. Here is a short rundown of each:
a-mir-formality: we want to create a formal model of the borrow checker changes we're proposing to ensure correctness. We also want to create a document explaining our model in a more human-friendly language. To really get started with this, we're blocked on the new expression based syntax in development by Niko.
Implementation: at the same time, we can start implementing more parts in the compiler. We will continue to improve FRTs, while keeping in mind that we might remove them if they end up being unnecessary. They still pose for a useful feature, but they might be orthogonal to field projections. We plan to make small and incremental changes, starting with library additions. We also want to begin exploring potential desugarings, for which we will add some manual and low level macros. When we have that figured out, we can fast-track syntax changes. When we have a sufficiently mature formal model of the borrow checker integration, we will port it to the compiler. After further evaluation, we can think about removing the incomplete_feature flag.
Experimentation: after each compiler or standard library change, we look to several projects to stress-test our ideas in real code. I will take care of experimentation in the Linux kernel, while Tyler Mandry will be taking a look at testing field projections with crubit. Josh Triplett also has expressed eagerness of introducing them in the standard library; I will coordinate with him and the rest of t-libs-api to experiment there.
Yesterday, we held a t-lang design meeting on our current approach. Nadrieril and I authored a design document with the feedback of Tyler Mandry, Ding Xiang Fei, Alice Ryhl, and Gary Guo. In this document, we provided the motivation for this feature, what the look and feel of a solution fitting into the existing features of Rust is, and a comprehensive + compact introduction to our current approach based on virtual places.
The general reception was extremely positive. To give some concrete quotes from the meeting:
Josh:
I adore this! I love how orthogonal it is, and how impactful and universal it is. I anticipate this becoming a beloved, pervasive feature of Rust.
Places and projection seem important enough to me that they're worth giving one of our precious remaining ASCII sigils to, and @ is nicely evocative of a place (something is at a place). So to the extent the final syntax benefits from a sigil, :+1: for giving this @. (See some feedback below on the details, though.)
TC:
Love it. High concept. As I said in the last meeting:
I particularly like language features that reduce the need for library surface area, and this is one of those.
There are, of course, many details to resolve and understand further, e.g., with respect to migration issues, interaction with const, async, and other effect-like things, etc. I'm looking forward to seeing the formalization work.
tmandry:
What I love about this direction is how effectively it builds on what Rust already has. I love to see designs that reinforce our existing concepts while pushing them in directions that make them more expressive.
Jack:
Whoo boy. This is great. There's so much here that I'm not exactly sure where to begin and what to comment on. I think this is the type of thing that we will only really be able to figure out the nitty gritty details and ergonomics only after some amount of experimentation.
There are a few takeaways from this meeting:
Mark raised the concern that t-libs should be more involved in reviewing the experimental traits that we intend to add. Ensuring that we don't accidentally stabilize or expose some behavior, have sufficient documentation on our experimental traits, and that t-libs is in the loop of this feature in general.
Mark offered to review PRs and I will be tagging him in those.
Jack raised the concern that increasing the cognitive load for the 95% use-case should be avoided. Making the right choice between @ and & might be challenging for users.
We discussed this point more in the meeting and concluded with that we need to do some experimentation, possibly utilizing the user research team. We will of course keep this in mind and revisit it later when we have a partially working implementation.
TC requested that we publish our fine-grained design axioms, essentially the list of things we go through when considering a modification of our proposal.
I will write an update on this issue explaining exactly those.
Aside from the concerns and directly actionable items, the meeting also covered design questions/comments that we want to take a look at in the coming weeks/months:
PR open to get the first working version of the Reborrow and CoerceShared traits merged.
Blockers
Currently "blocked" on PR review, and of course my (and Ding's) work to fix all review issues.
The review has brought up an opportunity to replace Rvalue::Ref / ExprKind::Ref with a more generalised variant that could encompass both references and user-defined references. This would be powerful, but it would be a very big and scary change. If this turns out to be a blocking issue for reviewers, then this will block the goal for the foreseeable future as the PR then starts on a massive refactoring.
Help wanted
The PR currently does not include derive traits, but we'd really want them. Instead of these:
impl<'a> Reborrow for CustomMarker<'a> {}impl<'a> CoerceShared<CustomMarkerRef<'a>> for CustomMarker<a'> {}impl<'a, T> Reborrow for CustomMut<'a, T> {}impl<'a, T> CoerceShared<CustomRef<'a, T>> for CustomMut<'a, T> {}
If anyone feels like picking up this thread, that'd be awesome: the derive macros do not need to really perform any validity checking, as the trait itself will do that.
If the PR merges soon, then public testing and exploration of the traits will be the next big thing. Likely concurrently with that the massive refactoring to generalise Rvalue::Ref / ExprKind::Ref.
No major updates this cycle - we're still working through feedback on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and prototyping the implementation to be prepared.
Update this cycle is the same as last time - rust-lang/rfcs#3874 and rust-lang/rfcs#3875 are progressing, with feedback being addressed and checkboxes checked, and we're still working out what the implementation would look like.
rust-lang/rfcs#3874 has finished FCP and is due to be merged any day now. I'm working on resolving the remaining open comments on rust-lang/rfcs#3875 and then intend to nudge the reviewers to have a look and check their boxes or leave concerns.
Adam Gemmell has opened rust-lang/cargo#16675 with an early sketch of some of the core changes that build-std would require and is working with the Cargo team to address feedback and work out how to proceed with the implementation.
There hasn't been too much progress over the last few weeks and I've been mostly taking a Christmas break. Nicholas Nethercote has been looking into the performance of the new trait solver, cleaning up canonicalization and slightly improving its performance: PR 1 and PR 2.
Shoyu Vanilla looked into ICE from mir validation on unsizing in opendal and uncovered the underlying bug there. While this issue also affects the old solver and the proper fix for it requires where-bounds on binders, we can work around this bug in the trait solver for now and intend to do so.
We've started another crater run with all our recent changes and adwin has started to triage it, uncovering one new issue up until now. Intend to continue going through that over the next few weeks.
we discussed how to investigate and fix the remaining correctness issues in Tage's work, to be able to evaluate it more accurately: in particular around variance and bidirectional edges, and without the reliance on NLL (having computed region values / errors)
we've tried to see if it'd be possible to remove the cfg region elements
Amanda is still working on her two papers, one about the current borrow checker and one about the work on Polonius. Her major PR for the restructuring of placeholder handling during region inference is stalled due to a conflict with further trait solver developments and may have to be abandoned. Work with the larger types team is ongoing and smaller patches/refactorings/improvements are being landed in the meantime.
I've also fixed more small inefficiencies (computing boring/relevant locals on-demand in diagnostics, removed conversions between locations and points, etc) building on top of the previous PRs (so they need to be reviewed first)
I've looked at crates.io again with the alpha, to find functions that are slower than with NLLs. AFAICT the worst case there is 60% for a 5KLOC function with 42K loans, 255K statements, and 125K outlives constraints. I'll see what we can do with this. Small composable functions is still good advice.
there seem to be optimization opportunities to 1. limit propagation to the smaller number of blocks that could be affected by bidirectional edges, 2. for unifying invariant lifetimes of live locals that are assigned at most once (à la use-def chains), 3. for invalidations that are just the activation of a reservation
we discussed possible plans to gather actual statistics, using the infrastructure that was created for the Metrics project
we're also preparing the new project goal for this year, where we'll want to stabilize the alpha 🤞
We had a bit less time this month, the update will be shorter, but still meaningful I hope:
#150551 has landed, and it feels stabilizable. To me, this part of the goal is achieved.
still, "stabilizable" is not stable, and there is more work to do. We plan to stabilize this year, and the project goal proposal for 2026 tracks how.
tiif is still deep in #152051, and a-mir-formality work with Niko and I.
Amanda has opened a few cleanup PRs (#152438, and #152579), and #151863 has landed already. She also has started looking into Tage's old PR to see if we can fix it, benchmark it more accurately, and see the cool parts there that we could be using.
Jack is possibly going to have some time to work with us this year! His help will be very welcome, especially as I will have less time available myself.
we'll be tracking the opaque type region liveness soundness issue in #153215, and I've added a couple tests, in case tiif's PR or anything that impacts them lands.
some of the tiny cleanups I mentioned last time have also landed in #152587.
The Rust Foundation is opening up a short-term, approximately 3-month, contracting role to assist in our Rust/C++ Interop initiative. The primary work and deliverables for the role will be to make substantial progress on the Problem Space Mapping Rust Project Goal by collecting discrete problem statements and offering up recommendations on the work that should follow based upon the problems that you found.
If you are interested in how programming languages interoperate, are curious in understanding the problems therein, and are have a passion to think about how those problems may be resolved for the betterment of interop, then this work may be for you.
An ideal candidate will have experience with Rust programming. Having experience in C++ is strongly preferred as well. If you have direct experience with actual engineering that required interoperating between Rust and C++ codebases, that's even better.
If you are interested, please email me (email address found in my GitHub profile) or contact me directly on Zulip by Tuesday, January 27 and we can take it from there to see if there may be a potential fit for further discussion.
The effort to fill the contracting role to support this project goal is in the process winding down. The interview and discussion process is nearly complete. We expect to make a final decision for the role in early February.
Next step is prioritising a few of the use cases, then working on related problem statements in more detail.
Blockers
Nothing at the moment, still working through the high level mapping of the problem space.
Help wanted
Suggestions for more interop use cases would be very welcome, just open a discussion in t-lang/interop and I'll turn it into a ticket. Or go ahead and open a use case ticket directly.
Next step is continuing to work on overloading and build systems in more detail. If you have specific Rust/C/C++ build system blockers, please open a chat or ticket.
Blockers
Nothing at the moment, everyone has been extremely helpful, and I'm getting good feedback on use cases, problems, priorities, and Rust language experiments.
these interop user experiences are waiting for analysis, so they can be summarised in the build system and overloading problem statements
this will likely happen after RustWeek and the All Hands
Next step is continuing to work on the overloading experiment, along with RustWeek/All Hands preparation, and collecting feedback during the conference.
Blockers
Nothing at the moment. There is a steady stream of new use cases, problems, code examples and Rust language experiment feedback.
Boxy and I have established a regular time to check-in on formalizing this within a-mir-formality. Today we mostly worked on the "model" of const values, starting with this
i.e., a const value can be a scalar value (as today) or a struct literal like Foo { ... } (which would also cover tuples and things). We got the various tests passing. Huzzah!
In addition to what niko posted previously there's been a lot of other stuff happening. A lot of people have opened PRs to improve mGCA this month: León Orell Valerian LiehrNoah Lev @enthropy7 Kivooeomu001999 @Human9000-bit Redddy @Keith-Cancel @AprilNEA
A rough list of things that have been improved for mGCA:
Lots of new expressions now supported by mGCA: const constructors, tuple constructor calls, array expressions, tuple expression, literals
associated_const_equality has been merged into min_generic_const_args. the former was effectively dependent on the latter already so this just makes it nicer to use the former :)
traits can now be dyn compatible if all associated constants are type consts and are specified in the trait object (e.g. dyn Trait<ASSOC = 10>)
type consts are enforced to be non-generic
a bunch of ICEs have been fixed
camelid has been working on "non-min" version of mGCA which will allow arbitrary expressions to be used in the type system (a blog post with more detail will be published once this actually lands)
In non-mGCA updates, as niko says, we've been meeting regularly to make progress on modelling const generics in a-mir-formality. I've also been spending time thinking about the interactions between adt_const_params and ADTs with privacy/safety invariants and I think I know how to structure the RFC in this area so can make progress on that again
There's been a lot of miscellaneous fixes for mGCA this month. I've also started drafting some blog posts to explain what's going on with mGCA/oGCA as well as soliciting use cases/experience reports for them and adt_const_params. I also talked with some folks at Rust Nation this month about const generics and what features would be useful for them and why.
Late on the update :') niko and i continue to meet to discuss const generics. we've made some progress on figuring out problems around privacy/safety in const generics. we've also been discussing the big picture stuff for const generics and where we're "heading".
started running weekly meetings about const generics to make it easier to keep up to date with all the people who are working on const generics stuff. i think min_adt_const_params is now at the point of what the RFC is going to specify.
GCA is making good progress thanks to ashley's work. i also met with lcnr where we talked about whether there was some version of mGCA that is stabilizeable in the near future or not (maybe!)
since we completed the 1.94.0 release of the FLS a bit early this time, we checked into the stretch part of our goal this year to look at 1.95.0 early
we learned a bit more of the release notes process thanks to tips from Eric Huss and TC
Tshepang Mbambo and I attended the t-release meeting last week where we chatted about working a little "upstream" with them on generating the release notes a bit earlier
tomorrow in our t-fls meeting we'll discuss our interest with engaging over there; at a minimum I'll get engaged with t-release
Glossary and main-body text harmonization:
the first PR landed from Tshepang Mbambo removing IDs from the glossary
further steps planned, we have a tracking issue for it
Developer guide:
akin to how the Reference now has a developer's guide now for contributing we'll do the same in the FLS
Yesterday, we posted an MCP for our retag intrinsics. While that's in progress, we'll start adapting our current prototype to remove our dependence on MIR-level retags. Once that's finished, we'll be ready to submit a PR.
We published our first monthly blog post about BorrowSanitizer.
Our overall goal for 2026 is to transition from a research prototype to a functional tool. Three key features have yet to be implemented: garbage collection, error reporting, and support for atomic memory accesses. Once these are complete, we'll be able to start testing real-world libraries and auditing our results against Miri.
We provide detailed error messages for aliasing violations, which look almost like Miri's do!
We have two forms of retag intrinsic: __rust_retag_mem and __rust_retag_reg. We no longer require a compiler plugin to determine the permission associated with a retag, which will make it possible to use BorrowSanitizer by providing a single -Zsanitizer=borrow flag to rustc. You can check out our MCP for more detailed design updates.
We are starting to have a better understanding of how BorrowSanitizer performs in practice, but we do not have enough data yet to be certain. From one test case, it seems like we are somewhat faster but still in the same category of performance as Miri when we compare against other sanitizers. Expect more detailed results to come as we scale up our benchmarking pipeline.
We have a tentative plan for upstreaming BorrowSanitizer in 2026, starting with its LLVM components. We intend to start the RFC process on the LLVM side this spring, once our API is stable.
We added hundreds more relevant tests from Miri's test suite. At the moment, 80% pass.
We improved our cargo plugin (cargo-bsan) to better support multilanguage libraries. This will let us start to recreate the bugs from our earlier evaluation.
Our goal for April is to continue expanding our test suite, finish an initial version of the LLVM components of BorrowSanitizer, and hopefully start the RFC process on the LLVM side.
We have some exciting news: our talk on BorrowSanitizer was accepted at RustConf this year! We’re grateful for the opportunity and looking forward to sharing our results with the broader community this September.
BorrowSanitizer now uses a shadow stack to track metadata at runtime - this is a significantly different strategy than other LLVM sanitizers, and it will help us support garbage collection.
We are now ready to start sending in PRs for our retag intrinsics. It will take a little time to split our changes up into meaningful, reviewable chunks—you can expect to see these throughout the next week.
The RFC for our LLVM components is taking a little longer than expected, but it was worth taking the extra time to test out compiler changes and make sure that we had the core parts of the instrumentation pass settled. We’ll be drafting the RFC throughout the next few weeks.
std::autodiff is moving closer to nightly, and std::offload is gaining various performance, feature, and hardware support improvements.
autodiff
Jakub Beránek, sgasho, and I continued working on enabling autodiff in nightly. We have a PR up that builds autodiff in CI, and verified that the artifacts can be installed and work on Linux. For apple however, we noticed that any autodiff usage hangs. After some investigation, it turns out that we ended up embedding two LLVM copies, one in rustc, and one in Enzyme. It should be comparably easy to get rid of the second one. Once we verified that this fixes the build, we'll merge the PR to enable autodiff on both targets in nightly.
offload
A lot of interesting updates on the performance, feature, and hardware support side.
Marcelo Domínguez, @kevinsala, @jdoerfert, and I started implementing the first benchmarks, since that's generally the best way to find missing features or performance issues. We were positively surprised by how good the out-of-the-box performance was. We will implement a few more benchmarks and post the results once we have verified them. We also implemented multiple PRs which implement bugfixes, cleanups, and needed features like support for scalars. We also started working on LLVM optimizations which make sure that we can achieve even better performance.
I noticed that our offload intrinsic allowed running Rust code on the GPU, but it wasn't of much help when calling gpu vendor libraries like cuBLAS. I implemented a new helper intrinsic which allows calling those functions conveniently, without having to manually move data to or from the device. It will benefit from the same LLVM optimizations as our full offload intrinsic. It also a bit simpler to set up on the compiler and linker side, so it already works with std and mangled kernel names, something that we still have to improve for our main offload intrinsic.
A lot of work happened on the LLVM offload side for SPIRV and Intel GPU support. At the moment, our Rust frontend is tested on NVIDIA and AMD server and consumer GPUs, as well as AMD HPC and Lapotop APUs. Karol Zwolak reached out since he wants to help with with also running Rust on Intel GPUs. Offload relies on LLVM which started gaining Intel support, so hopefully we won't need much work beyond a new intel-gpu target and a new stdarch module. There is also work on a new spirv target for rustc, which we could also support if it goes through LLVM. Due to some open questions around typed pointers it does not seem clear yet whether it will, so we will have to wait.
Nikita started working on updating our submodule to LLVM 22. This hopefully does not only brings some compile and runtime performance improvements, but also greatly simplifies how we can build and use offload. Once it landed I'll refactor our bootstrapping logic, and as part of that start building offload in CI.
std::autodiff is now partly in CI, and std::offload got tested on a lot more benchmarks.
autodiff
Work continued on enabling autodiff in nightly. Since the last update, we have enabled autodiff in some Mingw and Linux runners. Users can now download libEnzyme artifacts, place them locally in the right spot for their toolchain, and then use autodiff on their nightly compiler. Once macOS is added, we will enable a new rustup component that will handle the download for users. Before enabling autodiff on macOS, however, we want to change how we distribute LLVM on this target (from static to dynamic linking). There are a lot of workflows and users of this target, not all of which can be modelled in the Rust CI. Our last two attempts sadly broke such downstream users and local contributors, so both attempts had to be reverted. Since testing here is tricky, progress here might be on the slower side; we will see.
offload
Most of the work on the offload side lately has been invisible, since we were working on implementing more benchmarks and LLVM optimizations, as well as missing features, discovered by those benchmarks. We achieved excellent performance on those benchmarks; more details will soon be presented by Marcelo Domínguez at the EuroLLVM conference in two weeks!
Beyond benchmarks, there was a lot of tinkering on smaller PRs, reviewing, and housekeeping. LLVM-22 landed, so we updated our bootrstrap code to make use of new APIs, and tried to move a few smaller PRs forward, mainly around a better user experience and for making more Rust features available. Since the focus is still on benchmarks, not many of those PRs landed. They are in a mostly ready state, so it's a good time to pick them up if you're considering contributing. Please ping me on Zulip or in any PR with the offload label if you are interested!
It seems that figuring out which functions are noreturn is at a level too low for rustc. Function signatures are not sufficient and there are cases where rustc doesn't know whether to emit noreturn. It is something we should ask the LLVM to give us that information.
Alice Ryhl opened a new issue to introduce the -Zsanitizer=kernel-hwaddress sanitizer for aarch64 targets: https://github.com/rust-lang/compiler-team/issues/975
The corresponding RFC has been discussed by the Lang team on 2026-03-11. The overall vibe was positive and TC is going to read through it and hopefully check a box on the proposed FCP.
Ding's arbitrary_self_types: Split the Autoderef chain rust#146095 is waiting on reviews. It updates the method resolution to essentially: deref_chain(T).flat_map(|U| receiver_chain(U)).
The perf run was a wash and a carter has completed yesterday. Analysis pending.
We've discovered the #[feature(arbitrary_self_types_pointer)] feature gate. As the Lang consensus is to not support the Receiver trait on raw pointer types we're probably going to remove it (but this needs further discussion). This was a remnant from the original proposal, but the Lang has changed direction since.
Ding is writing a post to describe all the open proposals including Alice's new one that she brouhght up during the LPC 2025. He'll merge it in the Beyond References wiki.
Macros, attributes, derives, etc.
Josh brought up his work on adding more capable declarative macros for writing attributes and derives. He's asked the Rust for Linux team for what they need to stop using proc macros.
Miguel noted they've just added dependency on syn, but they would like to remove it some day if their could.
Benno provided a few cases of large macros that he thought were unlikely to be replaceable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion.
The team discussed the impact of this. These hints are used in C but not yet in Rust. cold_path would be sufficient, but likely/unlikely would still be more convenient in cases where there isn't an else branch. Tyler Mandry mentioned that these can be implemented in terms of cold_path.
Niche optimizations
We discussed the feasibility of embedding data in lower bits of a pointer -- something the kernel is doing in C. This could also enable setting the top bit in the integers (which is otherwise never set) and make it represent an error in that case (and a regular pointer otherwise).
Ideally, this would be done in safe Rust, as the idea is to improve the safety of the C code in question.
Extending the niches is something Rust wants to see, but it's waiting on pattern types. There are short/medium-term options by using unsafe and wrapping it in a safe macro, but the long-term hope is to have this supported in the language.
Vendoring zerocopy
The project has interest in vendoring zerocopy. We had its maintainers Jack Wrenn and Joshua Liebow-Feeser join us to discuss this and answer our questions. The main question was about whether to vendor at all, how often should we (or will have to) upgrade, and how much of it is expected to end up in the standard library.
The project follows semver with the extended promise to not break minor versions even before 1.0.0. We could vendor the current 0.8 and we should be upgrade on our own terms (e.g. when we bring in new features) rather than being forced to.
Right now, the project is able to experiment with various approaches and capabilities. Any stdlib integration a long way away, but there is interest in integrating these to the language and libraries where appropriate.
New trait solver
There's been a long-term effort to finish the new trait solver, which will unblock a lot of things. Niko Matsakis asked about things it's blocking for Rust for Linux.
This is the list: unmovable types, guaranteed destructors, Type Alias Impl Trait (TAIT), Return Type Notation (RTN), const traits, const generics (over integer types), extern type.
2026 Project goals
This year brings in the concept of roadmaps. We now have a Rust for Linux and a few more granular Goals. We'll be adding more goals over time, but the one merged cover what we've been focusing on for now.
We spent most of the meeting going over the open Project goals, the Rust for Linux roadmap and other things we'd like to see that aren't the right shape for a goal.
Miguel Ojeda brought up the upcoming Debian 14 release (coming out probably somewhere around Q2 of 2027) and we went over each item and decided whether it's something we need to make sure is in that release or not.
Debian stable is an important milestone and the Rust version in it serves as a baseline for Rust for Linux development.
The dma_read! / dma_write! macros switched over to it. This also fixes a soundness issue 1.
Note: this is done entirely via macros and doesn't use any Field projections language features. The Field projection syntax and traits should make this more ergonomic and integrate the borrow checker so we can accept more code.
We're planning to have a design meeting with the Lang team in the last week of March.
rustfmt imports formatting and trailing slashes
We talked about the rustfmt formatting of the use statements again. While the trailing empty comment // workaround (see this update) is acceptable as a temporary measure, we need to find a long-term solution where you can configure rustfmt to accept this style.
We don't have a issue for this specific formatting yet, though it was discussed in #3361.
The next step are to create such an issue. We were hesitant to add burden to a team that's already at limit, but having the issue would let us track it from the Rust for Linux side.
Boxy asked the team for features that are most important under the const generics umbrella. This might help with prioritisation and just understanding of practical uses.
Ability to do arithmetic on const generic types: e.g. the kernel has a type Bounded which has a value and a maximum size (in bits). Both the bit width and value are const values. They want to be able to do arithmetics on these types (starting with bit shifts) that will guarantee the the result will fit within the specified size at compile time.
Argument-position const generics: right now, the const generic types must be specified in the type bound section (within the angle brackets). So for example you have to write: Bounded::<u8, 4>::new::<7>() instead of the more natural Bounded::<u8, 4>::new(7). This gets more complicated when there's const-time calculation happening rather than just a numerical constant -- in which case this also needs to be wrapped in curly brackets: { ... }.
Being generic over types other than numbers: pointers would be useful for asm_const_ptr. String literals too -- even if they're just passed through without being processed / operated on. And if going from a passthrough string makes it possible to pass through any type, that would help the team replace some typestate patterns they're using with an enum.
statx
Alice Ryhlproposed being able to create std::fs::Metadata from Linux statx syscall.
This was discussed in the Libs-API meeting and they had questions about possible evolutions of the statx ABI -- if/how it can grow in the future and how they could handle that if they wanted some of the new data available. So we discussed it in the Rust for Linux meeting.
In the end, it seems prudent to be reasonably defensive rather than relying on the syscall pre-filling default values.
Alice Ryhlproposed an opaque statx struct that would give the stdlib a way to decide on the struct's size, pre-filled contents and mask.
Miguel Ojeda suggested contacting Christian Brauner and Alexander Viro (i.e. the VFS maintainers); Josh Triplett agreed that it would be good if we can get a thread with the right people in linux-fsdevel.
zerocopy uses two traits that are both polyfills for unstable traits : KnownLayout (for ptr_metadata) and Immutable (for Freeze). It would help maintenance of zerocopy (which Rust for Linux plans to start using) if these were stabilised.
ptr_metadata is something the team wants in the kernel independently. It's possibly blocked on (or at least might have interactions with) the Sized Hierarchy work.
We also discussed the dependence/independence of the Deref and Receiver implementations, in particular whether it ever makes sense to implement Deref but notReceiver. Josh Triplett suggested gathering examples for cases like that (where you can't use the type as a Self type in the function declaration, but allow calling methods on it).
The current plan for the experiment is to have these traits separate, but have the compiler enforce that if they implement the same type, their targets are identical. This will let us open the door for any future possibilities (a supertrait / subtrait relation, or having diverging targets in the future).
We want to experiment to see where and how these traits and their possible evolution might be helpful.
null-ptr-deref
The team would like to have a (an optional) compiler guarantee, that the compiler never removes null checks on raw pointers. What can currently happen in C is that if you deref a null pointer, the compiler can do optimisations including removing any subsequent checks whether that pointer is null, because dereferencing a null pointer is undefined behaviour.
But the null check can still help prevent further bugs and in C, the kernel now disables the optimisation that would remove it.
The RFC has just been published. It has been significantly reworked since the last draft.
Notable changes:
Removed the concept of activation/de-activation. Now the semantics don't need to deal with partially allocated locals. This is less powerful optimization-wise but should still cover most cases.
Added byref/byval to call arguments to clarify how they are passed.
Added a separate section for the surface language changes to separate it from the MIR changes.
Added more details on the MIR optimization which eliminates moves.
Changed the MIR operand evaluation order to be left-to-right, except for destination places which are always evaluated last.
Added StorageLive back: we need it to mark the location where llvm.lifetime.start should be inserted, which is not the same as the location where a local is initialized. In the opsem, StorageLive doesn't actually allocate the local, that's still done when it is initialized by a write.
The prototype of this project goal is basically complete.
Current state
This project goal introduces build analysis support in Cargo, with the aim of making build behavior understandable across multiple invocations, not just a single run.
At a high level, the prototype:
Records build metadata over time, including:
rebuild reasons
timing information
relevant invocation context
Stores this data locally in a structured log format suitable for later analysis
Exposes the data via unstable cargo report subcommands, such as:
cargo report sessions - list session IDs
cargo report timings - HTML timing report
cargo report rebuilds - Why things rebuilt
See the Reference for a more thorough usage documentation
Path towards stabilization
Before this feature can be stabilized, the following unresolved questions must be answered. They might not block stabilization, but need to be evaluated if it is fine to leave for future.
cargo report commands
This is a stabilization blocker.
Currently all three report commands (sessions, rebuilds, timings)
implicitly inspect global log files when if not in a workspace.
Should this be explicit with a flag?
Should this be an error if not in a workspace?
Bikeshed on command names
Currently we have all nouns
For sessions
runs simple but ambiguous
Just log like git log
history user-friendly (docker history, shell history, though not alike)
For timings:
Not controversial, as we have --timings flag already
There is ongoing work for Adts and function pointers, both of which will land as MVPs and will need some work to make them respect semver or generally become useful in practice
Removing the 'static bound from try_as_dyn turned out to have many warts, so I'm limiting it to a much smaller subset and will have borrowck emit the 'static requirement if the other rules do not apply (instead of having an unconditional 'static requirement)
There are some known issues we'd like to address before doing a formal call for testing. Notably, improving blocking messages, fixing potential thread starvation in Cargo's job queue when locks block, and investigate increasing rlimits to reduce risk of hitting max file descriptors for large projects.
I am hopeful that these issues will be resolved over the coming month and we can do a call for testing to start gathering feedback from the community on whether the new locking strategy improves workflows.
After the initial PR from the last update was merged, we shifted our focus to resolving some of the known issues. Notably, locking blocks the Cargo job queue slowly causing thread starvation if many build units are held by another Cargo instance.
We investigated adding the ability for Cargo to "suspend" a job internally while waiting for a lock, but we felt this change was a bit invasive and did not fit well with how the job queue was designed. Instead we plan to change our design to acquire all build unit locks prior to running the job queue (see #16657).
At the same time, we have continued to refine the new build-dir to prepare it for a call for testing and eventual stabilization. (#16542, #16502, #16515, #16514)
Finally we decided to split .cargo-lock into 2 locks to allow cargo check and cargo build to run in parallel when artifact-dir == build-dir (and -Zfine-grain-locking is enabled)
I suspect this may be the last update on this goal, as the 2026 slate of goals is coming up. While I did not renew this goal for 2026, I do plan to continue work on this and eventually stabilize this within this year.
Both the MCP and the PR for the AddressSanitizer target have been merged. Next up I should prepare the MCP for the Memory- and ThreadSanitizer targets, hopefully sending out soon.
rust-lang/rust#143924 has been merged, enabling scalable vector types to be defined on nightly, and I'm working on a patch to introduce unstable intrinsics/scalable vector types to std::arch
Progress has been slow since the last update because I've been busy, but I've been working on a rebase of rust-lang/stdarch#1509, which has bitrot quite a bit. Rémy Rakic is joining me to work on the Sized Hierarchy parts of the goal.
On the scalable vector half of the goal, I've got a branch with rust-lang/stdarch#1509 rebased, though without the intrinsic-test tool having been updated - that ended up being tricky and we've agreed to do it as a follow-up. We've opened rust-lang/rust#153286 with the compiler fixes that the stdarch patch requires, which should land soon (rust-lang/rust#153653 was opened and landed in the interim).
On the sized hierarchy half of the goal, Rémy Rakic has been updating our RFC such that we can discuss it in design meetings with the language team on the 18th and 25th - we'll update rust-lang/rfcs#3729 later today. We've split out the const Sized parts as a future possibility (though one we are committed to pursuing) as that has more open design questions, and we've discussed the proposed syntax and approach to migration - which are what we intend to focus on in the design meetings. He's also been working out how we can start implementing our migration strategy and help resolve blockers in other areas.
For the sized hierarchy half of the goal, Rémy Rakic and I had two design meetings with the language team (2026/03/18 and 2026/03/25) discussing the syntax/naming and migration strategy respectively.
On syntax, the language team preferred introducing an "only bounds" syntax to control opting-out of default bounds and opting-in to alternative bounds in a family of traits (described in an alternative in the RFC), but there was an open question of whether that syntax should apply to an individual bound or all of the bounds - Niko Matsakis is investigating that.
On naming, the language team also preferred the name SizeOfVal over MetaSized, and didn't like Pointee but had no better alternatives. Rémy Rakic prepared rust-lang/rust#154374 to do that renaming and started a discussion with the library team to confirm they were happy with the name, because changing it involves an amount of churn. The library team wanted to know what other traits in the hierarchy might later be introduced, as that would help inform the naming of the currently proposed traits, so Rémy Rakicwrote up a document with that information. We're holding off on doing any name changes until we find some consensus between libs and lang - who is responsible for these traits' names is a bit unclear.
On migration, the language team were largely happy with our proposed approach, and we realised that the approach proposed by lcnr for associated types might also work for our other migrations. Rémy Rakic has had meetings with lcnr to better understand that approach and to work out the next steps for implementing it.
Opened PR (#16767(https://github.com/rust-lang/rust-clippy/pull/16767)) extending Clippy support to unsafe fields.
Blockers
Waiting for t-clippy to review #16767(https://github.com/rust-lang/rust-clippy/pull/16767).
2026-05-18T00:00:00Z2026-05-18T00:00:00ZNurzhan Sakenhttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zhttps://blog.mozilla.org/netpolicy/?p=2577Mozilla to UK regulators: VPNs are essential privacy and security tools and should not be undermined
In the context of concerns around young people’s interactions with digital technologies, the UK’s Department for Science, Innovation and Technology is consulting on additional measures to prepare young people for … Read more
In the context of concerns around young people’s interactions with digital technologies, the UK’s Department for Science, Innovation and Technology is consulting on additional measures to prepare young people for growing up in a digital world. Before the backdrop of users circumventing age assurance systems mandated under the UK’s Online Safety Act, the consultation considers age-gating virtual private networks (VPNs).
Mozilla’s mission is grounded in the belief that the internet must remain open and accessible to all, and that privacy and security online are fundamental human rights. We recognize that the protection of young people online is one of the most pressing and challenging questions of our time, and we are committed to supporting policy proposals that address the root causes of online harms. We are concerned, however, that blunt interventions like mandatory age assurance and restricting access to tools like VPNs are not effective in improving the protection afforded to young people online, while undermining the fundamental rights of all users.
VPNs serve as critical privacy and security tools for users across all ages. By hiding users’ IP addresses, VPNs help protect users’ location, reduce tracking and avoid IP-based profiling. People use VPNs for lots of different reasons: to connect to their school’s or employer’s network remotely, to avoid censorship or to simply protect their privacy and security online. While being able to access VPNs is especially important for vulnerable groups like activists, dissidents or journalists, VPNs improve everyone’s baseline protection online.
Young people are particularly vulnerable to online tracking, targeted advertising, and the risks that flow from personal data being collected and processed for commercial purposes without adequate consent or transparency. In a world in which young people are interacting with digital technologies as part of their realities from young ages onward, restricting young people’s access to privacy-protecting technologies is in tension with the goal of equipping them to navigate the internet safely and competently. In order to be able to develop agency and responsible habits in engaging with digital technologies, it is crucial for young people to be introduced to best practices and key safety and privacy tools as they engage with the online world.
Rather than age-gating technologies like VPNs, we believe that regulators should address the root causes of online harm by holding platforms to account, encouraging the responsible use of parental controls and investing in digital skills and a whole of society approach to digital wellbeing.
Read our full submission to the Department for Science, Innovation and Technology.
2026-05-15T12:23:31Z2026-05-15T12:23:31ZSvea Windwehrhttps://blog.mozilla.org/netpolicy/Mozilla's official blog on open Internet policy initiatives and developmentsOpen Policy & Advocacy2026-06-11T14:28:25Zdiscourse.mozilla.org-topic-148293MozPhab 2.15.1 Released
Bugs resolved in Moz-Phab 2.15.1:
bug 2036719 moz-phab --no-stack doesn’t work as suggested?
Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
2026-05-13T20:14:01Z2026-05-13T20:14:01Zsheehan2026-06-12T10:58:53Zhttps://blog.mozilla.org/netpolicy/?p=2567Six Million Selections Later: How the DMA Is Giving People Browser Choice
At Mozilla, we’ve long believed in giving people choice and agency over their experiences online. As power in digital markets has concentrated in a small number of large companies, there … Read more
At Mozilla, we’ve long believed in giving people choice and agency over their experiences online. As power in digital markets has concentrated in a small number of large companies, there have been efforts in the US, Japan, UK, India, Korea, Brazil and elsewhere to restore competition and put choice back in people’s hands.
These efforts are at various stages, but first among them was the EU’s Digital Markets Act. Over two years since obligations came into effect, the DMA is delivering for people in some key areas.
Not everywhere. Not perfectly. And not without enforcement. But browser choice is the clearest example.
Every 10 seconds, someone picks Firefox through a DMA choice screen
Operating systems like iOS, Android, Windows, and MacOS lean on pre-installed browsers, tricky default settings, and deceptive design to make it hard for people to exercise choice and to keep independent browsers from competing on a level playing field. But where the DMA has created opportunities for genuine browser choice, people are taking it.
New Mozilla data is clear: since the rules took effect, Firefox is selected through a DMA browser choice screen every 10 seconds. That adds up to more than six million Firefox selections. And people are sticking with us: retention is five times higher when people choose Firefox through a choice screen.
Academic analysis points the same way. Independent researchers compared Firefox daily active users in the EU with 43 non-EU countries. Comparing the 15 months before and after browser choice screens rolled out on iOS, they found that Firefox daily active users (DAU) were 113% higher in the EU than it would have been without the DMA. On Android, it was 12% higher. The smaller Android effect is due to the fact that Firefox usage there started from a much higher base, and the Android rollout has been more uneven than on iOS. The research also shows that the DMA’s effect is growing over time.
Browser choice on mobile is moving, but desktop is left behind
The DMA’s work isn’t done. There remains room for improvement on mobile (including making it easier to import your data to a new browser and switch with one click). However, desktop remains largely untouched – leaving roughly 310 million desktops and laptops in the EU without equivalent browser choice. For example, Windows users are subject to deceptive design tactics and are not given an active choice. Even where choice screens exist, they are not a silver bullet; ecosystem lock-in and interoperability barriers still hold back competition and innovation.
Still, the signal is clear: when people get real browser choice, they take it and select alternatives. It’s easy for gatekeepers to dismiss this as a couple of competitors benefiting. This ignores the range of challenger browsers also reporting huge growth in the EU. What’s more, it ignores the benefit to people. DMA browser choice screens are reaching different audiences. Mozilla analysis shows that women make up a significantly higher share of Firefox selections on iOS via a choice screen than organic downloads, suggesting that choice screens may successfully reach a demographic that reports lower confidence in manually changing browser defaults. The DMA’s effects are only starting to be felt and understood.
The road ahead
Effective enforcement of the obligations is the way forward. Gatekeepers continue to test and, in many instances, openly push back against the intent of the DMA provisions. This can take the form of implementation choices that limit real user uptake, delays in rolling out effective solutions, or sustained efforts to reinterpret, weaken, or roll back key provisions.
Most evidently, privacy and security arguments are often elevated in ways that risk diverting attention from whether compliance is delivering genuine choice and competition in practice. In reality, privacy, security, and effective competition can and should be designed to work hand-in-hand. They do not always have to be traded off.
Policymakers and enforcers should remain focused on outcomes: ensuring that the DMA delivers real-world competition and user choice, and resisting efforts to dilute its impact through partial compliance or narrative reframing.
Browser choice is just the start
Mozilla’s hope is that real browser choice will become the rule, rather than the exception. And that the lessons of browser choice screens will be applied to other areas of the DMA, including data portability and interoperability. Only with full compliance – including applying the existing DMA text to AI – can the full benefits of competition and innovation be brought to people in the EU.
2026-05-11T19:03:25Z2026-05-11T19:03:25ZGemma Petrie and Tasos Stampeloshttps://blog.mozilla.org/netpolicy/Mozilla's official blog on open Internet policy initiatives and developmentsOpen Policy & Advocacy2026-06-11T14:28:25Zhttps://blog.thunderbird.net/?p=4303Community Office Hours: Contributor Spotlight on Bogomil Shopov
If you have ever used Thunderbird in Bulgarian, the subject of this month’s office hours is one of the contributors who made that possible! Office Hours hosts Heather and Monica have been lucky enough to chat with long-time localizer Bogamil Shopov at conferences like FOSDEM. Now, they’re sitting down to talk to him about how […]
If you have ever used Thunderbird in Bulgarian, the subject of this month’s office hours is one of the contributors who made that possible! Office Hours hosts Heather and Monica have been lucky enough to chat with long-time localizer Bogamil Shopov at conferences like FOSDEM. Now, they’re sitting down to talk to him about how his contributor story started, and to hear the advice he has for anyone curious about being part of Thunderbird.
We’ll be back next time, checking in on Thunderbird Pro! It’s been almost a year since we sat down with members of our team making this possible. As we’ve slowly started opening up the service to our Early Birds from the waitlist, it seemed a great opportunity to learn what users can expect, now and in the future!
A Contributor Origin Story
Bogomil has been a contributor to Thunderbird from the start! Even if he didn’t like the UI in the early days, he loved our commitment to software freedom. He wanted people to have the software in their own language, and so he started localizing Thunderbird into Bulgarian. This was in the days before Pontoon, Mozilla’s localization platform, and so this wasn’t easy work! Another hurdle, which still happens, is that small language locales tend to have smaller numbers of contributors doing localizing work.
From Mentee to Mentor
Thankfully, Bogomil had unofficial mentors to help them find their way. On the localization side, he had a Bulgarian mentor who he, in turn, introduced to Mozilla and other open source projects. More experienced Mozilla contributors answered his questions as he expressed his interest in getting more involved. Bogomil points out that this need for both good onboarding docs and genuine human connection is still something all open source projects needs – and something we can keep improving!
Now Bogomil is the experienced mentor, and he’s had some key steps to helping grow the Thunderbird localizer community. He sends thank you notes to new translators and sends resources for specific computer and email terminology to new Bulgarian volunteers. He gives his mentees specific tasks to help focus their energy and excitement, and maybe even more importantly, he gives them encouragement.
This Speaker goes to 11
While Bogomil had given several public talks in Bulgarian before COVID, after 2020 he decided to try giving conference talks in English. His first talk was at Halfstack, sponsored by Mozilla, in Vienna, on what made him happy as a developer and IT person in general. He even brought a violin player on stage with him! His talk got a warm reception, and it encouraged him to keep talking about what brought him joy, whether it was using heavy metal to help him focus or his involvement with Thunderbird and open source. If you’ve ever considered giving a talk, especially about one of your passions, and hesitated, Bogomil would tell you to do it! People are more welcoming than you might think.
Tools and Advice
Bogomil still uses Pontoon for Thunderbird desktop translations, in addition to Weblate, where Thunderbird for Android and many other open source projects live. In addition to this localization platforms, he uses CoEdIt along with web-based tools that allow him to see how certain words were previously translated. And of course, he has three release channels of Thunderbird on his computer at all times, something most of the Thunderbird team understands!
From newer contributors, Bogomil has learned how language is changing and how to keep terms, like the Bulgarian word for “browser,” up to date, in addition to other feedback. His advice to new and potential volunteers is to be open to critique. This is especially true joining a project with a long history like Thunderbird, especially before wanting to change something. And he says don’t be afraid to do things and experiment, even if things go wrong.
2026-05-08T19:15:13Z2026-05-08T19:15:13ZMonica Ayhens-Madonhttps://blog.thunderbird.net/https://blog.thunderbird.net/files/2024/01/cropped-Thunderbird_Logo_512-32x32.pngNews, previews, and guides from the Thunderbird TeamThe Thunderbird Blog2026-05-08T19:15:15Zhttps://hacks.mozilla.org/?p=48309Behind the Scenes Hardening Firefox with Claude Mythos Preview
Two weeks ago we announced that we had identified and fixed an unprecedented number of latent security bugs in Firefox with the help of Claude Mythos Preview and other AI models. In this post, we’ll go into more detail about how we approached this work, what we found, and advice for other projects on making […]
Two weeks ago we announced that we had identified and fixed an unprecedented number of latent security bugs in Firefox with the help of Claude Mythos Preview and other AI models. In this post, we’ll go into more detail about how we approached this work, what we found, and advice for other projects on making good use of emerging capabilities to harden themselves against attack.
Suddenly, the bugs are very good
Just a few months ago, AI-generated security bug reports to open source projects were mostly known for being unwanted slop. Dealing with reports that look plausibly correct but are wrong imposes an asymmetric cost on project maintainers: it’s cheap and easy to prompt an LLM to find a “problem” in code, but slow and expensive to respond to it.
It is difficult to overstate how much this dynamic changed for us over a few short months. This was due to a combination of two main factors. First, the models got a lot more capable. Second, we dramatically improved our techniques for harnessing these models — steering them, scaling them, and stacking them to generate large amounts of signal and filter out the noise.
Ordinarily we keep detailed bug reports private for several months after shipping fixes and issuing security advisories, largely as a precaution to protect any users who, for whatever reason, were slow to update to the latest version of Firefox. Given the extraordinary level of interest in this topic and the urgency of action needed throughout the software ecosystem, we’ve made the calculated decision to unhide a small sample of the reports behind the fixes we recently shipped. We’ve attempted to draw them from a range of browser subsystems, but the selection process was still somewhat arbitrary. Nevertheless, we hope that the depth and diversity of these reports lends credence to our assessment of the capabilities and our calls for defenders to begin applying these techniques:
An incorrect equality check can cause the JIT to optimize away the initialization of a live WebAssembly GC struct, creating a fake-object primitive with potential arbitrary read/write in code that had undergone extensive fuzzing by internal and external researchers.
A 15-year-old bug in the <legend> element triggered by meticulous orchestration of edge cases across distant parts of the browser, including recursion stack depth limits, expando properties, and cycle collection.
Reliably exploits a race condition over IPC, allowing a compromised content process to manipulate IndexedDB refcounts in the parent to trigger a UAF and potential sandbox escape.
A raw NaN crossing an IPC boundary can masquerade as a tagged JS object pointer, turning double deserialization into a parent-process fake-object primitive for a sandbox escape.
An intricate testcase weaving through nested event loops, pagehide listeners, and garbage collection to trigger a UAF in the attribute setter for <object> elements.
Triggers a parent UAF by flooding WebTransport with thousands of certificate hashes to stretch a race condition in a refcount-heavy copy loop, and exploits that race condition over IPC from a compromised content process.
Simulates a malicious DNS server by intercepting glibc DNS function calls in order to reproduce a UDP->TCP fallback edge case, triggering a buffer over-read and parent-process stack memory leak during HTTPS RR & ECH parsing.
20-year-old XSLT bug in which reentrant key() calls cause a hash table rehash that frees its backing store while a raw entry pointer is still in use (one of several sec-high issues we fixed involving XSLT).
Patches the color picker to simulate otherwise non-automatable user selection, then uses a synchronous input event to spin a nested event loop that re-enters actor teardown and frees the callback while it is still unwinding, triggering a content process UAF.
A compromised content process could send an arbitrary wallpaper image to be decoded in the parent process, which could be paired with a hypothetical vulnerability in an image decoder to escape the sandbox. This entailed difficult-to-automate reasoning about the trust-level of inputs in the parent process.
Escapes our in-process sandboxing technology for third-party libraries (RLBox) by leveraging a gap in the verification logic used to copy values from the untrusted to the trusted side of the sandbox boundary.
Extremely small testcase that exploits the special rowspan=0 semantics in HTML tables by appending >65535 rows to bypass clamping and overflow a 16-bit layout bitfield, which went undetected for years by fuzzers.
Note that a number of these bugs are sandbox escapes, which would need to be combined with other exploits to achieve a full-chain Firefox compromise. These reports presume that the sandboxed process that renders site content has already been compromised with some separate bug, and is now running attacker-controlled machine code attempting to escalate control into the privileged parent process. When crafting a sandbox escape, the model is permitted to patch the Firefox source code, so long as the modified code is restricted to run only in the sandboxed process[1]. Such bugs are notoriously difficult to find with fuzzing, and while we’ve had some success developing new techniques to close this gap, AI analysis provides much more comprehensive coverage of this critical surface.
Just as interesting as what the models found is what they didn’t find — not because they didn’t try, but because they were unable to circumvent Firefox’s layered defenses. For example, in recent years we received several clever reports from security researchers that managed to escape the process sandbox by triggering prototype pollution in the privileged parent process. Rather than fixing these problems one-by-one, we made an architectural change to freeze these prototypes by default. While auditing logs from the harness, we saw many attempts to pursue this line of escape that were thwarted by this design. Observing such direct payoff from previous hardening work was even more rewarding than finding and fixing more bugs.
Harnessing Models to Build a Hardening Pipeline
We’ve experimented internally with LLM code audits over the past few years, with early attempts using models like GPT 4 or Sonnet 3.5 to statically analyze high risk code for vulnerabilities. These experiments showed some promise, but the high rate of false positives made them impractical to scale.
The introduction of agentic harnesses that can reliably detect security issues has completely changed this. These can find real bugs and dismiss unreproducible speculation. The key feature of such a harness is that, given the right interfaces and instructions, it can create and run reproducible test cases to dynamically test hypotheses about bugs in code. After fixing the initial set of issues that Anthropic sent to us in February, we built our own harness atop our existing fuzzing infrastructure.
We began with small-scale experiments prompting the harness to look for sandbox escapes with Claude Opus 4.6. Even with this model, we identified an impressive amount of previously-unknown vulnerabilities which required complex reasoning over multiprocess browser engine code. At first, we supervised the process in the terminal to observe the process in real-time and tune the prompts and logic. Once this was working well, we parallelized the jobs across multiple ephemeral VMs, each tasked to hunt for bugs within a specific target file and write its findings back to a bucket.
A discovery subsystem is necessary but not sufficient. In order to scale the effort, we needed to integrate it with our full security bug lifecycle: determining what to look for, where to look, and how to handle what it produces. This last part includes deduplicating against known issues, tracking bugs, triaging them, and getting fixes shipped. While the model is the core primitive powering the harness, this full pipeline is necessary to make it useful at scale.
While harnesses may be reusable across projects, this pipeline is inherently project-specific, reflecting each codebase’s semantics, tooling, and processes. Standing this up required significant iteration, with a tight feedback loop alongside the Firefox engineers who were fielding the incoming bugs.
Upgrading the Models
Once the end-to-end pipeline is in place, it’s trivial to swap in different models when they become available. Building this pipeline early helped us find a number of serious bugs using publicly-available models, and it also helped us hit the ground running when we had the opportunity to evaluate Claude Mythos Preview. In our experience, model upgrades increase the effectiveness of the entire pipeline: the system gets simultaneously better at finding potential bugs, creating proof-of-concept test cases to demonstrate them, and articulating their pathology and impact.
In addition to fixing the 271 bugs identified by Claude Mythos Preview in the 150 release, we’ve shipped more of these fixes in 149.0.2, 150.0.1, and 150.0.2. We also continue to find bugs with other means internally, and, similar to other projects, we’ve seen a significant uptick in external reports in the last few months.
Ultimately, every bug requires care and attention to properly fix. Staying on top of this unprecedented volume has led to a lot of work and long days over the last few months, and we’re extremely proud of how the team has stepped up to meet this challenge. Over 100 people contributed code to this effort to ship the most secure Firefox yet. In addition to writing and reviewing patches, others have been building and scaling this pipeline, triaging, testing the fixes, and managing the release process for each bug.
Takeaways
Anyone building software can start using a harness with a modern model to find bugs and harden their code today. We recommend getting started now. You will find bugs, and you will set yourself up to take advantage of new models as soon as they become available.
You can start with very simple prompting, then observe and iterate. Our initial prompts were not dissimilar from those described here. Through iteration we’ve built out a lot of orchestration and tooling to optimize and scale the pipeline, but the essence of the inner loop remains the same: there is a bug in this part of the code, please find it and build a testcase.
We haven’t bottomed on all the latent bugs in Firefox, but are quite pleased with the trajectory. Today, our scanning is largely focused on specific areas of the code (files, functions) where we instruct the system to look, based on a mix of human judgement and automated signals. In the near future, we intend to integrate this analysis into our continuous integration system to scan patches as they land in the tree. Models are quite flexible with the form of context provided, and we expect patch-based scanning to work as well or even better than file-based scanning.
The current moment is a perilous one, but also full of opportunity. Let’s work together to secure the internet.
FAQ
The announcement said “271 bugs”, but I count something different. What’s going on?
On the advisories web page we group all internally-reported bugs as “rollup” CVEs with multiple bugs underneath them. The web page is built from yaml in the foundation-security-advisories repo, the canonical location for our CVE assignments. While some browsers do not create CVE identifiers for internally-discovered issues at all, we provide this information in order to be as transparent as possible.
In Firefox 150, there were three internal rollups: CVE-2026-6784 (154 bugs), CVE-2026-6785 (55 bugs), and CVE-2026-6786 (107 bugs).
Astute readers will notice the number of bugs in those internal rollups adds up to 316, which is more than the 271 we announced finding with Claude Mythos Preview. That’s because our security team hunts for new bugs every day by attacking Firefox with a combination of (a) fuzzing systems (b) manual inspection and (c) this new agentic pipeline across a variety of models.
We fixed a total of 423 security bugs in releases in April. In addition to the 271 bugs announced two weeks ago, there were 41 externally reported bugs, with the remaining 111 discovered internally and split roughly in third between:
Bugs found using this pipeline with Claude Mythos Preview but fixed in releases other than Firefox 150
Bugs found using this pipeline with other models
Bugs found with other techniques like fuzzing
Note that we also directly credited 3 CVEs to Anthropic separate from this latest effort (CVE-2026-6746, CVE-2026-6757, CVE-2026-6758). These were fixes for bugs sent to us by the outstanding Anthropic Frontier Red team a couple months ago and we assigned unique CVEs for each as per our normal process.
What do security ratings mean?
As additional context, we apply security severity ratings from critical to low to indicate the urgency of a bug:
sec-critical and sec-high are assigned to vulnerabilities that can be triggered with normal user behavior, like browsing to a web page. We make no technical difference between these, but sec-critical bugs are reserved for issues that are publicly disclosed or known to be exploited in the wild.
sec-moderate is assigned to vulnerabilities that would otherwise be rated sec-high but require unusual and complex steps from the victim.
sec-low is assigned to bugs that are annoying but far from causing user harm (e.g, a safe crash).
Of the 271 bugs we announced for Firefox 150: 180 were sec-high, 80 were sec-moderate, and 11 were sec-low.
While we care most about critical/high bugs, it’s normal for us to prioritize moderate and low security bugs in order to fix correctness issues and as a defense-in-depth mechanism.
Is a sec-high or sec-critical bug the same as a practical exploit?
Not necessarily.
In most cases, a single critical/high bug is not actually enough to compromise Firefox. This is because Firefox has a defense-in-depth architecture, so for example exploiting a JIT bug only achieves remote code execution in a sandboxed and site-specific process. Real-world attackers generally need to chain multiple exploits together to escalate privileges through one or more layers of sandboxing along with OS-level mitigations like ASLR.
We also generally don’t build exploits to see whether a bug could be used by an attacker in the real world. We classify sec-high based on predictable crash symptoms such as use-after-free or out-of-bounds memory issues being reported by AddressSanitizer, and our threat model assumes that any of them could be exploitable with sufficient effort. This reduces the risk of a false negative during exploitability analysis, and more importantly it allows us to focus our resources on finding and fixing more vulnerabilities.
2026-05-05T16:23:33Z2026-05-05T16:23:33Zsheehan2026-06-12T10:58:53Zhttps://hacks.mozilla.org/?p=48312Trustworthy JavaScript for the Open Web
The open web is a critical platform for applications that handle highly sensitive data, from private communications to financial transactions and medical records. Traditionally, servers are trusted to deliver the appropriate code and resources for their web applications to browsers, who then provide a secure and isolated environment for their execution. In some circumstances, this […]
The open web is a critical platform for applications that handle highly sensitive data, from private communications to financial transactions and medical records. Traditionally, servers are trusted to deliver the appropriate code and resources for their web applications to browsers, who then provide a secure and isolated environment for their execution. In some circumstances, this trust model falls short.
Consider a browser-based messaging application, like Signal or WhatsApp, which uses end-to-end encryption. The browser depends on the server to provide a trustworthy javascript implementation of the app; which ensures the user’s messages and cryptographic keys are suitably protected. A malicious or compromised server could selectively serve modified code to some users, undermining their security with little risk of detection. This challenges the basic premise of end-to-end encryption: that a misbehaving server should not be able to compromise user security.
Towards Verifiable Security on the Web
For web applications to be trustworthy in the presence of malicious servers, two properties are essential:
Integrity: The code executed by the user matches what the developer committed to in a manifest.
Transparency: These manifests are publicly logged and can be independently audited.
WAICT allows websites to cryptographically bind their client-side code to a manifest and commit that manifest to a publicly auditable log. Sites which need this stronger trust model can then opt in to WAICT enforcement. If an opted-in site delivers code that has not been publicly logged, the browser rejects it and attacks that were previously invisible become observable and attributable. This ensures that the code delivered to user’s machines is consistent with the publicly available code which security researchers can inspect.
Bringing Integrity and Transparency to the Open Web
We are collaborating with partners across the ecosystem – including Cloudflare, the Freedom of the Press Foundation and Meta – to ensure the deployment model is practical, secure, and as simple as possible. You can learn more about WAICT in our joint talk at Real World Cryptography 2026.
An early prototype of WAICT is available behind a pref in Firefox Nightly to help validate the approach in real-world scenarios. You can test drive the prototype on https://waict.dev/ – including an end-to-end encrypted video calling app secured by WAICT. The implementation is a work in progress, not a finished solution, but it provides a concrete foundation for iteration and standardization. We’re developing the specifications in the open and welcome early feedback.
WAICT marks an important step toward making strong, verifiable application security a first-class property of the open web.
With special thanks to Anna Weine, Benjamin Beurdouche, Christoph Kerschbaumer, Dennis Jackson, Frederik Braun, and Tom Schuster.
2026-05-05T15:49:11Z2026-05-05T15:49:11ZFirefox Security Teamhttps://hacks.mozilla.org/hacks.mozilla.orgMozilla Hacks – the Web developer blog2026-05-21T18:30:22Zyt:video:E5j6BoxZ-7wLast Lecture: Writing the Data DocsWill Lachance gives a last lecture on writing data documentation at Mozilla.2026-05-05T11:46:43Z2021-12-20T14:58:29ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zhttps://blog.mozilla.org/netpolicy/?p=2565Mozilla calls on UK policymakers to address the roots of online harm, not undermine the open web
Mozilla has joined a coalition of 19 digital rights organizations and technology providers in a joint statement, urging UK policymakers not to undermine the open web in their efforts to … Read more
Mozilla has joined a coalition of 19 digital rights organizations and technology providers in a joint statement, urging UK policymakers not to undermine the open web in their efforts to protect young people online.
Our mission is grounded in the belief that the internet must remain open and accessible to all, and that privacy and security online are fundamental. Around the globe, we are witnessing blunt policy interventions like age gates or restrictions on VPNs that put these values at risk. Child safety is a complex and central issue to us all, and as we have said before, Mozilla supports robust, proportionate safeguards for minors. However, we are concerned that mandatory age verification or VPN restrictions undermine online privacy and security, people’s ability to express themselves and access information, and ultimately the health of the web itself.
In an attempt to address tough questions surrounding online harms, UK policymakers are currently consulting on which services and features should be placed behind age gates as part of a national consultation on online harms. A broad range of services are being considered for age restrictions, including search engines, games and VPNs. Even targeted age restrictions of certain features would require all users to submit to age assurance systems. However, existing age assurance technologies have been found to either undermine users’ privacy and data security, to be insufficiently accurate or not widely accessible across populations. Age restrictions could also entrench the dominance of gatekeepers and fragment the web into a patchwork of age-gated jurisdictions.
Beyond the significant risks associated with mandating age assurance across core internet services, we are particularly concerned about proposals to restrict the use of VPNs. VPNs and similar services are essential privacy and security tools used by millions of users for legitimate purposes. Restricting the use of privacy-preserving technologies undermines efforts to empower users to navigate the web safely and to develop digital literacy.
Rather than age-restricting a growing number of services, we believe that addressing the roots of child safety concerns, such as poor content moderation, irresponsible data practices, and deceptive design, is a more proportionate and effective way forward. We thus urge policymakers to prioritize policy interventions that centre children’s’ rights and all users’ agency and choice, and protect, not undermine, the open web.
2026-05-05T09:32:36Z2026-05-05T09:32:36ZSvea Windwehrhttps://blog.mozilla.org/netpolicy/Mozilla's official blog on open Internet policy initiatives and developmentsOpen Policy & Advocacy2026-06-11T14:28:25Zyt:video:OTe47t0gGAEAn opinionated intro to NLP (text analytics)Rebecca BurWei from Mozilla Data Science gives an introduction to Natural Language Processing.2026-05-05T03:14:33Z2021-12-20T14:59:21ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zhttps://tantek.com/2026/124/b1/may-the-focus-be-with-you-iphone-grayscaleMay the Focus Be With You!
Last weekend at IndieWebCamp I noticed
James
had setup his iPhone in grayscale.
I think I first saw that on
Jeremy’s
phone years ago.
I remember trying it on my iPod Touch for a while, eventually switching back to see color photos.
This morning while chatting with James I asked him about his grayscale setup and why. He pointed out it’s less distracting, a calmer experience, and helps him stay focused when he uses his iPhone for specific tasks.
I decided to give it another try. The setting is quite buried. Here are the items to tap, starting from your home screen, or wherever you moved your ⚙️ Settings app:
⚙️ Settings
🟦 Accessibility >
🟦 Display & Text Size >
Color Filters >
Color Filters (⚫️__) [slide this toggle to the right to turn it on]
Greyscale [tap this and you should see it checked]
James said one more setting has helped him stick with grayscale for years now.
Triple-press the side button to toggle color/grayscale modes helps quickly switch to color to view a photo or a video, actual color content, then triple-press-side-button to return to a calmer UI.
⚙️ Settings
⏺ Accessibility >
⏺ Accessibility Shortcut >
Color Filters [tap this and you should see it checked]
In addition, I have found the back-tap feature handy and personally more memorable.
Double (or triple) back-tap to toggle color/grayscale mode and toggle back.
⚙️ Settings
⏺ Accessibility >
👆🏻 Touch >
Back Tap >
Double-tap >
Color Filters [tap this and you should see it checked]
When using my phone outside in the sun, I noticed the absence of color made it hard to distinguish or even read some things. I changed a few more settings to improve sunlight readability/usability.
⚙️ Settings
⏺ Accessibility >
⏺ Display & Text Size >
Bold Text (⚫️__) [tap/slide this toggle to the right to turn it on]
Increase Contrast (⚫️__) [tap/slide this too]
Differentiate Without Color (⚫️__) [tap/slide this too]
In the absence of color on my iPhone, I have spent less time using it today, felt more focused when I used it for a specific task, and have started to feel both less compelled to check things, and less of a “rush” when interacting with iPhone apps and their user interfaces.
Color saturated apps stripped of their color are starting to feel like older apps or appliances. Switching Spotify playlists felt a bit like pressing station presets on a car radio. Discord felt like an enhanced IRC client. Even some of my rotating lock screen landscape photos have strong Ansel Adams vibes, while my urban lockscreen photos have a calmer dreamlike quality.
Perhaps the use of color in modern mobile app user interfaces is the new
chartjunk, extraneous and distracting from the task at hand, just as classic chartjunk is extraneous and distracting from the information being presented. Most mobile apps seem to be in an attention-seeking arms race against each other, ever more saturated colors to draw you in like a casino.
Using a grayscale iPhone user interface for most of the day has felt noticeably calmer. Enough for me to try it again for at least a few days and see how it goes.
Thanks again to James for his explanations and encouragement. See his write-up:
Using greyscale, when he started, why, why he continues to use it, and instructions for his setup.
Try it for yourself and see how it feels.
May the Force of your will be with you, free of distractions and dopamine conditioned impulses.
2026-05-05T02:20:00Z2026-05-05T02:20:00Zhttps://tantek.com/updates.atom?ot=articleTantekhttps://tantek.com/Tantek Çelik2026-05-05T02:20:00Zyt:video:k1cvnVKOmM8GLAM DatasetsMarina Samuel and Anthony Miyaguchi talk about the ETL pipeline created for the GLAM project (https://github.com/mozilla/glam).2026-05-04T22:44:24Z2021-01-15T16:09:41ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zyt:video:V5FgVbxm-ccData Club Lightning Talk: Jan-Erik Rediger - Your personal Glean data pipelineThis talk was given as part of the Data Club Lightning Talk Session on February 11th, 2022.
More on https://blog.mozilla.org/data/2022/02/25/this-week-in-glean-your-personal-glean-data-pipeline
Information about Glean: https://mozilla.github.io/glean/book/index.html2026-05-04T22:23:40Z2022-02-25T13:41:22ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zyt:video:nZupfJy6I0AData Club: Jan-Erik Rediger - Little Bobby Tables - from metrics.yaml to data-filled columnsA short story about Little Bobby Tables and how we know what data to fill in where.2026-05-04T18:06:43Z2024-02-05T15:18:38ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zyt:video:Y3IOY-kmk70Data Club Talk: Jan-Erik Rediger - The Glean UniFFI migration and how no one noticedGiven at the Mozilla Data Club on August 12th, 2022.2026-05-04T17:13:30Z2022-08-15T12:01:56ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zhttps://blog.rust-lang.org/2026/05/04/outreachy-2026-may/Rust is participating in Outreachy
The Rust Project has been building up a good history of participating in various open-source mentorship programs, including Google Summer of Code for three years (including this year) and previously OSPP. We're happy to announce that this year we are also participating in Outreachy starting in the May 2026 cohort.
Each of these mentorship programs has different criteria for eligibility depending on who they target and the motivations of the program. Outreachy provides internships in open source, to people from any background who face underrepresentation, systemic bias, or discrimination in the technical industry where they are living. You can learn more about the Outreachy program on their website.
What is Outreachy and how is it different than Google Summer of Code
Outreachy is similar to Google Summer of Code (GSoC) in some aspects, but different in others. First off, unlike GSoC, Outreachy interns first apply to the overall program and only then can apply to specific communities. Second, while oftentimes GSoC applicants submit various contributions prior to their application, Outreachy has a dedicated period where contributions are not just optional, but required. Finally, Outreachy applicants submit an application similar to GSoC applications and communities pick interns based on those applications and the interns' contributions. Outreachy has two internship periods per year, one running from May to August (in which we are currently participating) and one from December to March.
The other major difference between Google Summer of Code and Outreachy is the source of intern stipends. For GSoC, Google graciously covers contributor stipends and overhead. For Outreachy, communities instead cover the interns' stipends and overhead.
We are mentoring 4 interns for the May 2026 cohort
Because of limited funding availability and mentoring capacity, the Rust Project decided to select four interns for mentorship. We'll briefly share these projects below.
This project aims to implement an experimental feature for calling overloaded C++ functions from Rust, and to begin testing that feature in a few representative use cases.
This project aims to develop the workflows to run and analyze code coverage of the compiler at the scale of the entire compiler test suite and on ecosystem crates detected by crater. The hope is to be able to detect when the compiler is inadequately tested, both within the compiler and in the ecosystem, and to build tools to do continuous analysis on this.
Fuzzing the a-mir-formality type system implementation
This project aims to implement fuzzing for a-mir-formality, an in-progress model for Rust's type and trait system. The goal is to generate programs in order to identify rules with underspecified semantics in a-mir-formality.
Improve the security of GitHub Actions of the Rust Project
This project aims to improve the security of GitHub Actions workflows of the repositories owned by the Rust Project. It will develop tools and workflows, integrating with existing software, to analyze Github repositories and detect if they follow the best security practices, fix existing issues, and ensure that good security practices are followed in the future.
What's next
Over the next 3 months, the interns will work closely with their mentors to make progress on their projects. When the internship period is over, we'll write another blog post to share the results! See you then!
We also want to thank all the people that submitted applications and made contributions. It was quite tough to decide which applicants to select. Hopefully we will participate in Outreachy again in the future and there are other opportunities to participate. We also very much welcome you to stick around and continue being involved - there is a ton of places in the Rust Project with opportunities to be involved.
2026-05-04T00:00:00Z2026-05-04T00:00:00ZJack Hueyhttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zhttps://williamdurand.fr/2026/05/01/moziversary-8Moziversary #8
Today is my eighth Moziversary 🎂 I joined Mozilla as a full-time employee on
May 1st, 2018. I previously blogged in 2019, 2020, 2021, 2022,
2023, 2024, and 2025.
You might have come across this built-in data consent thing for extensions
in Firefox. I spent a good chunk of last year working on this project, from
developing a technical proposal to implementing the feature in Gecko,
Firefox for desktop and Firefox for Android.
Talking about Android, I became the module owner for
Fenix::Add-ons, a module for all the code related to
add-ons in Firefox for Android (which we call “Fenix” internally). Between the
creation of this new module, and an ever-solidifying collaboration between the
Add-ons and Android teams, the support for extensions in Firefox for Android has
a bright future! Having started my Android journey in 2023, this feels like a
noteworthy achievement.
Near the end of last year, I moved back to being a full-time AMO engineer to
support a team that was down to two engineers. I redesigned the detail page, and
started some refactoring on our security scanners, which I had originally
created back in 2019 😬
In other news, I joined the AI/LLM/vibe-coding crowd thanks to my colleague
Paul, and it took me about a month to get brain-fried… AI
fatigue is real, indeed. That said, Claude code has been somewhat useful to
me, and I don’t hate it, but I also don’t love it.
Thank you to everyone in the Add-ons team as well as to all the folks I had the
pleasure to work with so far. Cheers!
2026-05-01T00:00:00Zhttps://williamdurand.fr/William Durandwill@drnd.meMozilla // William Durand2026-05-01T13:00:04Zhttps://blog.rust-lang.org/2026/05/01/nvptx-baseline-update/Raising the baseline for the `nvptx64-nvidia-cuda` target
The nvptx64-nvidia-cuda target is a compilation target for NVIDIA GPUs. When using this target, the final output is PTX. Two version choices shape that output:
a GPU architecture (for example, sm_70, sm_80, …), which determines which GPUs can run the PTX, and
a PTX ISA version, which determines which CUDA driver versions can load (and JIT-compile) the PTX.
In Rust 1.97 (scheduled for release on July 9, 2026), the baseline PTX ISA version and GPU architecture for nvptx64-nvidia-cuda will be increased. These changes affect both the Rust compiler (rustc) and related host tooling, and they make it impossible to generate PTX artifacts compatible with older GPUs and older CUDA drivers.
The new minimum supported versions will be:
PTX ISA 7.0 (requires a CUDA 11 driver or newer)
SM 7.0 (GPUs with compute capability below 7.0 are no longer supported)
Why are the requirements being changed?
Until now, Rust has supported emitting PTX for a wide range of GPU architectures and PTX ISA versions. In practice, several defects existed that could cause valid Rust code to trigger compiler crashes or miscompilations. Raising the baseline addresses these issues and enables more complete support for the remaining supported hardware.
Removing support affects users of the architectures being removed. In this case, the most recent affected GPU architectures date back to 2017 and are no longer actively supported by NVIDIA. We therefore expect the overall impact of this change to be limited.
Maintaining support for these architectures would require substantial effort. These removals let us focus development efforts on improving correctness and performance for currently supported hardware.
What happens when I update to Rust 1.97?
If you need to target a CUDA driver that does not support PTX ISA 7.0 (CUDA 10-era drivers and older), Rust 1.97 will no longer be able to generate PTX compatible with that environment. Similarly, if you need to run on GPUs with compute capability below 7.0 (for example, Maxwell or Pascal), Rust 1.97 will no longer be able to generate compatible PTX for those GPUs.
Assuming you are targeting a CUDA driver compatible with CUDA 11 or newer and using GPUs with compute capability 7.0 or newer:
If you do not specify -C target-cpu, the new default will be sm_70, and your build should continue to work (but will no longer be compatible with pre-Volta GPUs).
If you currently specify an older -C target-cpu (for example, sm_60), you will need to either:
remove that flag and let it default to sm_70, or
update it to sm_70 or a newer architecture.
If you already specify -C target-cpu=sm_70 (or newer), there should be no behavioral changes from this update.
2026-05-01T00:00:00Z2026-05-01T00:00:00ZKjetil Kjekahttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zhttps://blog.nightly.mozilla.org/?p=2052Import-ant Updates – These Weeks in Firefox: Issue 201
Highlights Import attributes will be supported for WebExtensions, starting in Firefox 150! This allows WebExtension authors to import CSS module scripts and JSON into their JavaScript modules. Examples: import sheet … Read more
Highlights
Import attributes will be supported for WebExtensions, starting in Firefox 150!
This allows WebExtension authors to import CSS module scripts and JSON into their JavaScript modules.
Examples:
import sheet from ‘./styles.css’ assert { type: ‘css’ };
import schema from “./policies-schema.json” with { type: “json” };
Removed obsolete migration logic that forced distribution language packs to be reinstalled when upgrading from Firefox versions older than 67 – Bug 2000797
Thanks to Aloys for contributing the changes needed to cleanup this old XPIProvider migration logic
WebExtensions Framework
Fixed a regression where WebRTC permission popups were queued and suppressed while an extension popup was open – Bug 1982832
WebExtension APIs
Fixed an edge case where tabs.move would revert splitview tabs order while moving splitview tab to a new window – Bug 2028832
Fixed windows API reporting window type normal instead of popup for windows opened via window.open() – Bug 2030631
Thanks to Brandon Lucier for contributing this small but very much appreciated fix to the windows WebExtensions API!
Henrik Skupin landed support for browser.setClientWindowState, originally started by Dan and continued by Liam DeBeasi, with final fixes and improvements completed after earlier contributors were unable to continue.
This also updated some global styling for card, message bar, text input border radiuses/colors and the moz-promo component got a refactor with better support for image styling by default
Jules Simplicio has been updating variable names in the Figma Nova Components/Styles files so our design token naming is consistent between Figma and central (so we can run our import script for more Nova automation)
UX Fundamentals
Felt Privacy error pages now support more NSS errors instead of falling through to the legacy page. Updated introductory text for the denied-port-access error. – 2024150
Fixed a test in browser_aboutCertError.js that was failing on Linux opt standalone and removed the platform skip. – 2028651
Added clock skew detection to the Felt Privacy error pages. When a certificate error is caused by a wrong system clock, the Felt Privacy error pages now show the same dedicated clock-skew message that the legacy error pages had, and helps guide users to correct their system time. – 2025049
Fixed misaligned bullet points in the “What can you do?” section of Felt Privacy network error pages, restoring correct visual indentation for that list. – 2028632
2026-04-30T16:29:24Z2026-04-30T16:29:24ZKatherine Pateniohttps://blog.nightly.mozilla.orghttps://blog.nightly.mozilla.org/files/2024/04/cropped-Fx-Browser-Nightly-icon-fullColor-512-32x32.pngLet's improve quality, build after build!Firefox Nightly News2026-06-03T18:27:38Zhttps://blog.mozilla.org/?p=85605Welcoming Abigail Besdin, Mozilla’s new Chief Operating Officer
We’re delighted that Abigail Besdin has joined Mozilla as our new Chief Operating Officer. This is an incredibly exciting time for Mozilla. Our focus is to become the world’s most trusted software company by building products that let people use the internet openly, safely, and on their terms. As technology changes rapidly, we are working […]
We’re delighted that Abigail Besdin has joined Mozilla as our new Chief Operating Officer.
This is an incredibly exciting time for Mozilla. Our focus is to become the world’s most trusted software company by building products that let people use the internet openly, safely, and on their terms. As technology changes rapidly, we are working to strengthen the business foundation and infrastructure that champions our mission. Delivering on that ambition takes more than great products; it demands operational rigor. Abigail will lead this effort, demonstrating how values-driven organizations can scale with discipline, speed, and trust in the AI era.
As COO, Abigail will drive company strategy and oversee Mozilla’s Core Services teams: Business Operations, Data, Infrastructure, IT, Legal, People, Security, and Strategy. These are the functions that enable us to move quickly and scale with focus. Abigail will sharpen how we plan, prioritize, and execute across the company.
Abigail brings more than 18 years of experience building and scaling high-impact platforms. She co-founded Great Jones, a venture-backed property management startup where she raised $30M, reached $10M in ARR, and led a successful acquisition by Roofstock. At Roofstock, she served as Chief of Staff to the CEO — functioning as an internal COO — where she launched new product lines, closed and integrated two acquisitions, and led the company’s strategic planning process.
Earlier in her career, she spent six years at Skillshare, where she launched the company’s online learning platform and built its growth and content engines from the ground up.
That combination of founder’s instinct and operator’s discipline is exactly what Mozilla needs right now. Abigail will report directly to our CEO and join the executive team.
I’ve learned firsthand that ambitious product goals are only as effective as the operations underpinning them. Mozilla’s mission is as big as it gets, and I’m thrilled to lead our Core Services organization to enable rigorous, smart, and quick decision-making across the business. With a powerful execution engine, we can make sure the best of Mozilla’s mission materializes.
Abigail Besdin, Chief Operating Officer
Abigail studied Philosophy at NYU, with a focus on Ethics and Mathematical Logic. Born and raised in New York City, she still lives there with her husband and three kids.
2026-04-30T12:57:15Z2026-04-30T12:57:15ZMozillahttps://blog.mozilla.org/en/News and Updates about MozillaThe Mozilla Blog2026-06-10T17:43:34Zdiscourse.mozilla.org-topic-148154Firefox Profiler Deployment (April 28, 2026)
The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed:
Highlights:
[fatadel] Dim non-matching nodes in the stack chart when searching (#5935)
[Markus Stange] Always render the CPU-usage-aware activity graph when CPU information is available (#5918)
[fatadel] Add CounterDisplayConfig to counters in the processed profile format (#5912)
[Nazım Can Altınova] Fallback to javascript highlighting in the source view as a backup (#5936)
[fatadel] Replace 4 counter track components with a single generic TrackCounter (#5944)
[Ryan Hunt] Add a fullscreen button to the bottom box (#5605)
[Nazım Can Altınova] Add “Include idle samples” toggle to the call tree settings (#5968)
[Markus Stange] Update the hovered item when panning any viewport canvas (#5903)
[Nazım Can Altınova] Fix loading .json.gz profiles from inside zip archives (#5959)
[Markus Stange] Replace symbolicator-cli with a profiler-edit node tool (#5965)
2026-04-30T12:09:45Z2026-04-30T12:09:45Zfatadel2026-06-12T10:58:53Zyt:video:tzDQSnK45dAOutreachy Mentorship: A RetrospectiveWill Lachance does a retrospective on the Glean Dictionary outreachy internship.
See also "Linh's Outreachy Internship Highlights" https://www.youtube.com/watch?v=UJdIkHDPgGQ
To learn more about Outreachy, see https://www.outreachy.org/2026-04-30T07:37:48Z2021-03-29T20:25:24ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Zhttps://blog.mozilla.org/l10n/?p=1883L10n Report: April Edition 2026
Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and … Read more
Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.
Welcome!
Are you a locale leader and want us to include new members in our upcoming reports? Contact us!
What’s new or coming up in Firefox desktop
Firefox string deadline changes
Starting with 149, some changes in developer deadlines relating to Nightly and Beta have resulted in a slight shift in string translation deadlines, giving us 2 extra days to land strings. Previously deadlines in Pontoon were set to the Sunday ahead of the final Release Candidate but going forward they will be set to a Tuesday. For example the upcoming deadline for Firefox 151 is Tuesday, May 12.
If you’re interested to see more details on upcoming Firefox releases and milestones, https://whattrainisitnow.com has all the latest details.
UI Refresh
Behind the scenes a refresh on the visual look of Firefox has been ongoing using the internal name “Nova”. You may have seen some blog reports recently on this, or perhaps have been seeing bugs in Bugzilla with this in the title. We will start seeing new strings related to these changes here and there as development work progresses, however we don’t expect a large number of string changes stemming from this work.
That being said, these updates also bring some changes in how we communicate directly to our users within Firefox. One of these changes you may have already met: our new mascot Kit. If you missed the announcement give it a read here. You may also notice a shift voice for user directed messages — with source strings becoming more Genuine, Fiery, and Playful. See this recent update in Firefox’s brand voice for more details.
Settings redesign
Localization for the update to about:settings has been going on for some time (starting early this year) and the bulk of the translation work is behind us at this point. You may see some new strings (particularly around Privacy & Security) but many of the strings are in a viewable/testable state in Nightly 152. You can check your translations and test out the redesign by typing about:config into your URL bar, proceeding past the warning message, and searching for browser.settings-redesign.enabled and setting the value to true.
What’s new or coming up in mobile
Things have been particularly busy on mobile over the past couple of months. For example, Firefox for Android saw a significant spike in April, with the number of new strings increasing to over 200 compared to fewer than 50 in March — more than eight times the typical monthly volume*.
There are two main drivers behind this increase. First, Firefox for Android is introducing a built-in VPN feature, bringing it in line with the functionality already available in Firefox. Second, both iOS and Android teams are working on a new widget for the upcoming 2026 World Cup, allowing users to follow their team directly from the browser.
Given the short turnaround time for this feature, you will notice that many strings are intentionally kept consistent across platforms — and started landing on Desktop as well. We’re also pre-landing as many strings as possible, ahead of implementation, to give localizers more time to complete translations.
* Did you know that you can track the number of new strings in a project from the Insights page in Pontoon? Check for example Firefox for Android. In the Translation activity chart, click on New source strings in the legend to display this data. Given the difference in scale, it can also help to hide other metrics to make the chart easier to read.
What’s new or coming up in Pontoon
New documentation system. Pontoon now features a brand-new, unified documentation system. This new hub brings together previously scattered resources into a single, streamlined experience, consolidating developer, localizer, and admin documentation from three separate sites into one cohesive platform. By centralizing content, the new system makes it easier to find, navigate, and maintain documentation, ensuring contributors of all roles have quick access to up-to-date and consistent guidance.
Search. You can now set default search options directly in your profile. This allows you to tailor your search without having to adjust filters each time.
The same settings are also applied when using the recently introduced global search page, which brings a major step forward in unifying localization across Mozilla by allowing users to search for strings across all projects and locales in one place. Inspired by Transvision and designed as its successor, the feature integrates deeply with Pontoon, making it easy to filter results, compare translations across languages, and jump directly into the translation workflow.
AI integration. We’ve also refined the prompt used by the LLM-powered translation feature. The goal is not to change how the feature works, but to make its output more consistent and better aligned with the context available in Pontoon. For example, the updated prompt improves how punctuation is handled, reducing variability in suggestions.
In addition, the prompt now includes more contextual data:
String ID.
Comments, including pinned comments from project managers.
Matches from terminology.
This additional context helps the model generate more relevant suggestions. It also represents a first step toward making LLM suggestions more useful, ahead of potential experiments with displaying them by default alongside suggestions from traditional machine translation.
New contributors. We’re also excited to welcome a group of new contributors who have started making an impact on Pontoon over the past few months. MundiaNderi, nishitmistry, dannycolin, first-afk, wassafshahzad, huseynovvusal, and Peacanduck have all contributed valuable improvements across different parts of the project, helping us move faster and improve the overall experience.
A special shoutout goes to Serah (MundiaNderi), who not only made significant contributions but also shared insights into her work in a recent blog post about enhancing comment management in Pontoon—an excellent example of the kind of collaboration and knowledge sharing we love to see in the community.
Newly published localizer facing documentation
As part of the recent documentation update for Pontoon, we’ve reorganized the content around pretranslation to make it clearer and easier to navigate. There is now a dedicated page outlining the criteria required to enable pretranslation for a locale, along with guidance on how to monitor its effectiveness over time (for example, by tracking metrics like acceptance rate or time to review). If you’re a locale manager and want to try pretranslation for your locale, you can request it directly from Pontoon.
Over the past 12 months, we also ran a limited experiment using paid translation agencies for two locales. The goal was to restore the localization level of Firefox for Android in cases where the community was inactive — situations that have since improved, with both communities now active again.
Because volunteer communities remain the foundation of Mozilla’s localization model, we wanted to be transparent about when and why this approach was used, and what it means in practice. This includes clarifying how external support fits within a community-driven ecosystem, where localizers retain ownership and responsibility for quality and direction. You can find more details in this page.
Friends of the Lion
Image by Elio Qoshi
We continue the localizer spotlight series this year.
Meet Oliver from China Firefox localizer, accounting student, former Minecraft translator, and Bocchi the Rock! fan He talks about starting with a single typo, why Firefox’s independence matters to him, and how the Simplified Chinese community keeps quality high with cross-review and shared responsibility.
Marcelo from Argentina needs no introduction to the localization communities. From Phoenix 0.3 to 24 years later, he shares how he got started, what it meant to be part of the Firefox 1.0 release, his experience as an l10n manager, and why using Mozilla products in his own language — Spanish (Argentina) — continues to motivate him.
What does 18 years of volunteer localization look like? From discovering Firefox and Linux out of curiosity to leading the Portuguese translation team, Cláudio from Portugal reflects on why localization is a form of digital activism, and how every translated word helps build a more inclusive internet.
Baurzhan from Kazakhstan began his localization journey with a simple question: why wasn’t Kazakh available in widely used software? That curiosity grew into a long-term commitment to localization, leading to the successful translation of Firefox and many other open source projects. His work demonstrates the power of perseverance in making technology accessible to all.
If you enjoy the series, please help us identify the localizers you’d like to see featured filling out this nomination form. If you have stories to share, tell us in your own words.
Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!
Did you enjoy reading this report? Let us know how we can improve it.
2026-04-30T06:13:53Z2026-04-30T06:13:53ZFrancesco Lodolo [:flod]https://blog.mozilla.org/l10nUsers first, no matter where they arePlanet – Mozilla L10N2026-04-30T06:13:53Zhttps://servo.org/blog/2026/04/30/march-in-servo/March in Servo: keyboard navigation, better debugging, FreeBSD support, and more!
servoshell is now installed as servoshell or servoshell.exe, rather than servo or servo.exe (@jschwe, @mrobinson, #42958).
--userscripts has been removed for now, but anyone who uses it is welcome to reinstate it as a wrapper around UserContentManager::add_script (@jschwe, #43573).
We’ve fixed a bug where link hover status lines are sometimes not legible (@simartin, #43320), and we’re working on getting servoshell signed for macOS to avoid getting blocked by Gatekeeper (@jschwe, #42912).
crypto.subtle.deriveBits() for X25519 checking for all-zero secrets, and verify() for HMAC comparing signatures, are now done in constant time (@kkoyung, #43775, #43773).
‘Content-Security-Policy’ now handles redirects correctly (@TimvdLippe, #43438), and sends violation reports with the correct blockedURI and referrer (@TimvdLippe, #43367, #43645, #43483).
The policy in <meta> now combines with the policy sent in HTTP headers, rather than overriding it (@TimvdLippe, @elomscansio, #43063).
When checking nonces, we now reject elements with duplicate attributes (@dyegoaurelio, #43216).
The document containing an <iframe> can no longer access the contents of error pages (@TimvdLippe, #43539), and CSP violations inside an <iframe> are now correctly reported (@TimvdLippe, #43652).
We’re continuing to implement document.execCommand() for rich text editing (@TimvdLippe, #43177), under --pref dom_exec_command_enabled.
‘beforeinput’ and ‘input’ events are now fired when executing supported and enabled commands (@TimvdLippe, #43087), the ‘defaultParagraphSeparator’ and ‘styleWithCSS’ commands are now supported (@TimvdLippe, #43028), and the ‘delete’ command is partially supported (@TimvdLippe, #43016, #43082).
All of the features above are enabled in servoshell’s experimental mode.
Work on accessibility support for web contents continues under --pref accessibility_enabled.
There was a breaking change in the embedding API (@delan, @alice, #43029), and we’ve landed support for “grafting” the accessibility tree of a document into that of its containing webview (@delan, @alice, #43012, #43013, #43556).
As a result, when you navigate, separate documents can have separate accessibility trees without complicating the embedder.
<link rel=modulepreload> is now partially supported (@Gae24, #42964), though recursive fetching of descendants is gated by --pref dom_allow_preloading_module_descendants (@Gae24, #43353).
For a long time, Servo has had some support for the Web Bluetooth API under --pref dom_bluetooth_enabled.
We’ve recently reworked our implementation to adopt btleplug, the cross-platform Rust-native Bluetooth LE library (@webbeef, #43529, #43581).
We’ve landed more fixes to Servo’s async parser (@simonwuelker, #42930, #42959), under --pref dom_servoparser_async_html_tokenizer_enabled.
If we can get the feature working more reliably (#37418), it could halve the energy Servo spends on parsing, lower latency for pages that don’t use document.write(), and even improve the html5ever API for the ecosystem.
For developers
Servo’s DevTools feature now has partial support for inspecting service workers (@CynthiaOketch, #43659), as well as using the navigation controls along the top of the UI (@brentschroeter, @eerii, #43026).
In the Inspector tab, we’ve fixed a bug where the UI stops updating when navigating to a new page (@brentschroeter, #43153).
In the Console tab, you can now evaluate JavaScript in web workers and service workers (@SharanRP, #43361, #43492).
We’ve fixed some long-outstanding bugs where the DevTools UI may stop responding due to protocol desyncs (@brentschroeter, @eerii, #43230, #43236), or due to messages from multiple Servo threads being interleaved (@brentschroeter, @eerii, #43472).
For developers of Servo itself, mach can be a bit opaque at times.
To make mach more transparent and composable, we’ve added mach print-env and mach exec commands (@jschwe, #42888).
The empty default implementation of EventLoopWaker::wake has been removed, because it almost never makes sense for a new custom impl to leave the method empty (@chrisduerr, @mrobinson, #43250).
Add Cookie is now more conformant (@yezhizhen, #43690), which led to Servo developers landing a spec patch.
‘pause’ actions are now slightly more efficient (@yezhizhen, #43014), and we’ve fixed a bug where ‘wheel’ actions fail to interleave with other actions (@yezhizhen, #43126).
More on the web platform
Carets now blink in text fields (@mrobinson, #43128).
You can configure or disable blinking carets with --pref editing_caret_blink_time=0 or a duration in milliseconds.
Clicking to move the caret is more forgiving now (@mrobinson, #43238), and moving the caret by a word at a time is more conventional on Windows and Linux, with Ctrl instead of Alt (@mrobinson, #43436).
We’ve also fixed a bug where pressing the arrow keys in text fields both moves the caret (good) and scrolls the page (bad), and fixed a bug where the caret fails to render on empty lines (@mrobinson, @freyacodes, #43247, #42218).
Input has improved, with more responsive touchpad scrolling on Linux (@mrobinson, @chrisduerr, #43350).
Pointer events and mouse events can now be captured across shadow DOM boundaries (@simonwuelker, #42987), and we’ve now started working towards shadow-DOM-compatible focus (@mrobinson, #43811).
Pressing Space or Enter inside text fields no longer causes them to be clicked (@mrobinson, #43343).
The lang attribute is now taken into account when shaping, which is important for the correct rendering of Chinese and Japanese text (@RichardTjokroutomo, @mrobinson, #43447).
‘font-weight’ is now matched more accurately when no available font is an exact match (@shubhamg13, #43125).
Navigation is one of the most complicated parts of HTML: navigating can run some JavaScript that replaces the page, just run some JavaScript, or depending on the response, do nothing at all.
<iframe> makes navigation doubly complicated: the document containing an <iframe> can observe and interact with the document inside the <iframe> in various ways, often synchronously.
This has been the source of manybugsovertheyears, but we’ve recently fixed one of those major issues (@jdm, #43496).
new Worker() now supports JS modules (@pylbrecht, @Gae24, #40365), and CanvasRenderingContext2D now supports drawing text with Variation Selectors, allowing you to control things like emoji presentation and CJK shaping (@yezhizhen, #43449).
Servo now fires ‘pointerover’, ‘pointerout’, ‘pointerenter’, and ‘pointerleave’ events on web content (@webbeef, #42736), ‘scroll’ events on VisualViewport (@stevennovaryo, #42771), and ‘scrollend’ events on Document, Element, and VisualViewport (@abdelrahman1234567, @mrobinson, #38773).
We also fire ‘error’ events when event handler attributes contain syntax errors (@simonwuelker, #43178).
‘direction’ now works on grid containers (@nicoburns, #42118), SVG images can now be used in ‘border-image’ (@shubhamg13, #42566), ‘linear-gradient()’ now dithers to reduce banding (@Messi002, #43603), ‘letter-spacing’ no longer applies to invisible zero-width formatting characters (@simonwuelker, #42961), and ‘:active’ now matches disabled or non-focusable elements too, as long as they are being clicked (@webbeef, #42935).
DOMContentLoaded timings in PerformanceNavigationTiming are more accurate (@simonwuelker, #43151). PerformancePaintTiming and LargestContentfulPaint are more accurate too, taking <iframe> into account (@shubhamg13, #42149), and checking for and ignoring things like broken images and transparent backgrounds (@shubhamg13, #42833, #42975, #43475).
We’ve landed partial support for using CSS counters in ‘list-style-type’ on ‘display: list-item’ and ‘content’ on ‘::marker’, but the counter values themselves are not calculated yet, so all list items still read as 0. or similar.
In any case, you can use a <counter-style-name> or ‘symbols()’ in ‘list-style-type’, and ‘counter()’ and ‘counters()’ in ‘content’ (@Loirooriol, #43111).
We’ve also landed partial support for <marquee> and the HTMLMarqueeElement interface, including basic layout, but the contents are not animated yet (@mrobinson, @lukewarlow, #43520, #43610).
Servo now exposes several attributes that have no direct effect, but are needed for web compatibility (@lukewarlow, #43500, #43499, #43502, #43518):
noHref on HTMLAreaElement
hreflang, type, charset on HTMLAnchorElement
useMap on HTMLInputElement and HTMLObjectElement
longDesc on HTMLIFrameElement and HTMLFrameElement
Web fonts are no longer fetched more than once, and they no longer cause reflow when they fail to load (@minghuaw, #43382, #43595).
We’re also working towards better caching for shaping results (@mrobinson, @lukewarlow, @Loirooriol, #43653).
Event handler attribute lookup is more efficient now (@Narfinger, #43337), and we’ve made DOM tree walking more efficient in many cases (@Narfinger, #42781, #42978, #43476).
crypto.subtle.encrypt(), decrypt(), sign(), verify(), digest(), importKey(), unwrapKey(), decapsulateKey(), and decapsulateBits() are more efficient now (@kkoyung, #42927), thanks to a recent specupdate.
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, #42937, #42982, #43018, #43071, #43222, #43288, #43544, #43563, #43631).
Thanks again for your generous support!
We are now receiving 7167 USD/month (+2.6% from February) in recurring donations.
This helps us cover the cost of our speedyCIandbenchmarkingservers, 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 37 GitHub users (+5 from February) 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.
2026-04-30T00:00:00Zhttps://servo.orgServo Teaminfo@servo.orgAll the entries in the Servo blog.Servo Blog2026-05-31T00:00:00Zhttps://blog.rust-lang.org/2026/04/30/gsoc-2026-selected-projects/Announcing Google Summer of Code 2026 selected projects
As previously announced, the Rust Project is participating in Google Summer of Code (GSoC) 2026. GSoC is a global program organized by Google that is designed to bring new contributors to the world of open source.
A few months ago, we published a list of GSoC project ideas, and started discussing these projects with potential GSoC applicants on our Zulip. We had many interesting discussions with the potential contributors, and even saw some of them making non-trivial contributions to various Rust Project repositories before GSoC officially started!
The applicants prepared and submitted their project proposals by the end of March. This year, we received 96 proposals, which is a 50% increase from last year. We are glad that there was again a lot of interest in our projects! Like many other GSoC organizations this year, we somewhat struggled with some AI-generated proposals and low-quality contributions generated using AI agents, but it stayed manageable.
GSoC requires us to produce an ordered list of the best proposals, which is always challenging, as Rust is a big project with many priorities. Our mentors examined the submitted proposals and evaluated them based on their prior interactions with the given applicant, their contributions so far, the quality of the proposal itself, but also the importance of the proposed project for the Rust Project and its wider community. We also had to take mentor bandwidth and availability into account. Unfortunately, we had to cancel some projects due to several mentors losing their funding for Rust work in the past few weeks.
As is usual in GSoC, even though some project topics received multiple proposals1, we had to pick only one proposal per project topic. We also had to choose between proposals targeting different work to avoid overloading a single mentor with multiple projects. In the end, we narrowed the list down to the best proposals that we could still realistically support with our available mentor pool. We submitted this list and eagerly awaited how many of them would be accepted into GSoC.
Selected projects
On the 30th of April, Google has announced the accepted projects. We are happy to share that 13 Rust Project proposals were accepted by Google for Google Summer of Code 2026. That is a lot of projects! We are really happy and excited about GSoC 2026!
Below you can find the list of accepted proposals (in alphabetical order), along with the names of their authors and the assigned mentor(s):
Congratulations to all applicants whose project was selected! Our mentors are looking forward to working with you on these exciting projects to improve the Rust ecosystem. You can expect to hear from us soon, so that we can start coordinating the work on your GSoC projects.
We are excited to mentor three contributors who already experienced GSoC with us in the previous year. Welcome back, Kei, Marcelo and Shourya!
We would like to thank all the applicants whose proposal was sadly not accepted, for their interactions with the Rust community and contributions to various Rust projects. There were some great proposals that did not make the cut, in large part because of limited mentorship capacity. However, even if your proposal was not accepted, we would be happy if you would consider contributing to the projects that got you interested, even outside GSoC! Our project idea list is still current and could serve as a general entry point for contributors that would like to work on projects that would help the Rust Project and the Rust ecosystem. Some of the Rust Project Goals are also looking for help.
There is a good chance we'll participate in GSoC next year as well (though we can't promise anything at this moment), so we hope to receive your proposals again in the future!
The accepted GSoC projects will run for several months. After GSoC 2026 finishes (in autumn of 2026), we will publish a blog post in which we will summarize the outcome of the accepted projects.
The most popular project topic received fourteen different proposals! ↩
2026-04-30T00:00:00Z2026-04-30T00:00:00ZJakub Beránekhttps://blog.rust-lang.org/Maintained by the Rust Teams.https://github.com/rust-lang/blog.rust-lang.org/Empowering everyone to build reliable and efficient software.Rust Blog2026-06-11T14:20:46Zdiscourse.mozilla.org-topic-148130MozPhab 2.14.0 Released
Bugs resolved in Moz-Phab 2.14.0:
bug 2032102 Parallelize revision creation and diff property calls in submit for faster stack submission
Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
2026-04-29T04:15:13Z2026-04-29T04:15:13Zsheehan2026-06-12T10:58:53Zyt:video:B635wgZy7IwGlean Dictionary Looker DemoA quick demonstration of the Glean Dictionary's new integration with Mozilla's instance of Looker.2026-04-28T21:37:03Z2021-06-01T21:23:08ZMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_Dawyt:channel:S1zp4AVNvykWzPC-vB_DawMozilla Datahttps://www.youtube.com/channel/UCS1zp4AVNvykWzPC-vB_DawMozilla Data2020-03-03T15:46:33Z
![Screenshot of a terminal. ``` [21:25:38] ~/docker-profiles$ docker compose run main 5s [+] 2/2t 2/22 ✔ Network docker-profiles_default Created 0.1s ✔ Container docker-profiles-init-1 Started 0.3s Container docker-profiles-init-1 Waiting Container docker-profiles-init-1 Exited Container docker-profiles-main-run-17209b1867a1 Creating Container docker-profiles-main-run-17209b1867a1 Created main main main ^C [21:26:50] ~/docker-profiles$ docker compose down 33s 130 ↵ [+] down 2/2 ✔ Container docker-profiles-init-1 Removed 0.0s ✔ Network docker-profiles_default Removed 0.1s [21:26:58] ~/docker-profiles$ docker compose up 1s WARN[0000] Found orphan containers ([docker-profiles-main-run-17209b1867a1]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. [+] up 3/3 ✔ Network docker-profiles_default Created 0.1s ✔ Container docker-profiles-init-1 Created 0.1s ✔ Container docker-profiles-main-1 Created 0.0s Attaching to init-1, main-1 init-1 | init Container docker-profiles-init-1 Waiting init-1 exited with code 0 Container docker-profiles-init-1 Exited main-1 | main main-1 | main Gracefully Stopping... press Ctrl+C again to force Container docker-profiles-main-1 Stopping main-1 | main Container docker-profiles-main-1 Stopped Container docker-profiles-init-1 Stopping Container docker-profiles-init-1 Stopped main-1 exited with code 137 [21:28:26] ~/docker-profiles$ ```](https://blog.narf.ssji.net/wp-content/uploads/sites/3/2026/05/image.png)
![Screenshot of a terminal. ``` [21:36:50] ~/docker-profiles$ docker compose --profile opt up 130 ↵ [+] up 4/4 ✔ Network docker-profiles_default Created 0.1s ✔ Container docker-profiles-opt-init-1 Created 0.1s ✔ Container docker-profiles-init-1 Created 0.1s ✔ Container docker-profiles-main-1 Created 0.0s Attaching to init-1, main-1, opt-init-1 opt-init-1 | opt-init init-1 | init Container docker-profiles-opt-init-1 Waiting Container docker-profiles-init-1 Waiting Container docker-profiles-opt-init-1 Exited opt-init-1 exited with code 0 init-1 exited with code 0 Container docker-profiles-init-1 Exited main-1 | main main-1 exited with code 0 [21:36:55] ~/docker-profiles$ docker compose up 2s service "main" depends on undefined service "opt-init": invalid compose project ```](https://blog.narf.ssji.net/wp-content/uploads/sites/3/2026/05/image-1.png)
![Screenshot of a terminal. ``` [21:40:31] ~/docker-profiles$ docker compose up 4s Attaching to init-1, main-1 init-1 | init Container docker-profiles-init-1 Waiting init-1 exited with code 0 Container docker-profiles-init-1 Exited main-1 | main main-1 exited with code 0 [21:40:35] ~/docker-profiles$ docker compose --profile opt up 3s Attaching to init-1, main-1, opt-init-1 opt-init-1 | opt-init init-1 | init Container docker-profiles-init-1 Waiting Container docker-profiles-opt-init-1 Waiting Container docker-profiles-opt-init-1 Exited opt-init-1 exited with code 0 init-1 exited with code 0 Container docker-profiles-init-1 Exited main-1 | main main-1 exited with code 0 ```](https://blog.narf.ssji.net/wp-content/uploads/sites/3/2026/05/image-2.png)
![Screenshot of a terminal. ``` [21:47:53] ~/docker-profiles$ docker compose --profile opt down --remove-orphans 130 ↵ [+] down 5/5 ✔ Container docker-profiles-main-1 Removed 10.2s ✔ Container docker-profiles-init-1 Removed 0.0s ✔ Container docker-profiles-opt-init-1 Removed 0.0s ✔ Container docker-profiles-say-hello-run-c26e752b1edd Removed 0.0s ✔ Network docker-profiles_default Removed 0.1s [21:48:05] ~/docker-profiles$ docker compose run say-hello 11s [+] 3/3t 3/33 ✔ Network docker-profiles_default Created 0.1s ✔ Container docker-profiles-init-1 Exited 1.9s ✔ Container docker-profiles-main-1 Started 2.1s Container docker-profiles-say-hello-run-76efc04798b4 Creating Container docker-profiles-say-hello-run-76efc04798b4 Created hello ```](https://blog.narf.ssji.net/wp-content/uploads/sites/3/2026/05/image-3.png)
Update oxfmt to version 0.51.0 (
Sync: l10n → main (May 26, 2026) (
You can download it here: 
