I’ve been working at Mozilla for eleven years, my golly. I’m still on my third hardware refresh (a Dell XPS I continue to dislike), I’m up to my fourth CEO, and 76 reorgs have happened (well, I know that quite a few things that would normally have counted haven’t been counted there, so it’s probably a higher number than that).
I’m still getting Firefox Desktop to use Glean instead of Legacy Telemetry. We’re more than two-thirds of the way done with removing the legacy system, with concrete plans about what to do with the rest. I’m still not blogging as much as I’d like, but I have some honest hope that I might change that in no small part thanks to someone who mentioned in passing that they liked my posts.
Looking back at last year’s predictions, I did indeed requisition a second work monitor, which is working out well.
I was right that FOG Migration hasn’t completely removed all of Legacy Telemetry, though we’re a lot closer than I thought we’d be. I do have a little time to think about doing other things, but not all that much, so the part of the prediction where I’d do something else is a “maybe”.
My desire to push for a sensible user population measurement did not have a chance to be acted upon. We might be shifting what the business counts, but not to anything I’ve had a say in. At least one of the reorgs that happened changed the organizational distance between my team and the other parts of Data that would be involved in such a measurement, other non-work things took way too much time and resulted in slower overall work velocity, and FOG Migration kept taking priority.
I didn’t think there’d be an All Hands, and in the off-change there were, it’d be a multi-city “Summit style” affair. I was half wrong twice: there wasn’t an All Hands but there was indeed an all-Engineering Summit; it wasn’t in multiple cities but just one. I was right that Toronto finally got its chance. I enjoyed the heck out of it as it really reminded me of some of the things I really missed about the All Hands of yore. It could’ve been a day longer, it could’ve been a little more of a polished experience like Brianna-era events were… but for not having done anything like this for two years, what an accomplishment. I was initially skeptical about spending hours of the first day making small talk deliberately with people you don’t know on the subject of the work you do and how you do it, but once it was framed as an effort to scale-up and operationalize The Hallway Track I suddenly understood it.
I had wishful, hopeful thinking that the genAI bubble would have burst or a new shiny late-stage capitalist exploitation mechanism would be draining focus away from it by now. Alas neither. Though maybe things are beginning? I can dream.
I was also half-wrong about there being a new CEO but not yet sworn in. I didn’t account for the candidate coming from within the org, meaning it could be quick. We’ve had Anthony hired and active for nearly a year now and he’s… fine? So far the changes he’s made to MoCo haven’t been to any of the things I feel we need to change, so I can’t really evaluate him. (Assuming that, since he (well, his reports) are able to evaluate my performance, it’s only fair that I get to evaluate his in turn. That’s how this works, right?)
Predictions for the coming year:
We’re going to stick with Anthony as CEO, keeping my count stable
Firefox Enterprise is going to be a runaway success, finally giving MoCo that revenue diversification we’ve been aiming for
Maybe the genAI bubble will have burst? (Yes, this is a duplicate from last year)
I’ll read The Psychology of Software Teams. It will frustrate me to finally be able to name and cite sources for how badly this industry treats its workers.
FOG Migration will be “complete” (Legacy Telemetry probes will be gone, code will have been removed) and I’ll move on to working on… maybe data consent management? Developing a way to find out which metrics are unused, and removing them? I have a few ideas.
I’ll still be complaining about this Dell XPS laptop, and considering what I’ll be refreshing to the following February. Maybe I’ll finally leave Windows behind?
I will have blogged at least three times (setting my prediction deliberately and achievably low), probably mostly video game musings in my ongoing So I’ve Finished series. But I do have a draft of a work post about the history of public data tooling at Mozilla that I’ve been meaning to finish…
New print_page tool. It saves the current page as a PDF file and has optional landscape and background options. It uses print CSS, so you can use it to check print styles
Fixed
--profile-path now reuses a profile that the server created, instead of creating a new profile inside it. The server marks its profiles with a .firefox-devtools-mcp file. Paths without this marker still use the firefox_devtools_mcp_profile subfolder
list_pages, select_page, close_page, navigate_page and new_page no longer bring every tab to the front. They now read the tab list with WebDriver BiDi
select_page and close_page now act on the tab from the last tab list, even if tabs were opened or closed since then
Changed
list_pages no longer lists tabs that are not loaded yet, for example restored tabs that were never opened
If the title of a tab cannot be read within 1 second, the tab is listed with the title (unknown)
What’s the most vital asset for an AI company today? For venture backed AI business, it might be “funding” or “revenue”. But, there’s another asset that’s just as critical: trust.
At Mozilla, building technology that people and businesses can genuinely trust has been a long-standing, guiding principle. That’s why we’re supporting the launch of the Trustworthy AI Map, a market map of VC-backed companies building the infrastructure for trustworthy AI.
Supported by seven organizations, including Mozilla, the Trustworthy AI Map features 79 companies across 15 countries, from early to later-stage venture. It maps companies building products for AI deployment across seven layers of the AI stack, including identity, data control, interoperability and evaluation.
The map connects the products with the companies and capital behind them, helping investors, founders and businesses explore commercial opportunities. To be featured, trust must be baked into its product or business model through human agency, trust by design or aligned business models.
This initiative aligns with much of our work over the past year. We’ve invested in companies through Mozilla Ventures, launched Otari, an open source enterprise tool which allows you to control your LLM infrastructure from a single layer, and published landmark research in our State of Open Source AI report that’s demystifying the open source AI landscape and shows that the capability gap between open and closed models is closing.
We’ve also partnered with Mila: the Quebec AI Institute, to build an open source AI foundation layer that enables organizations and institutions to own and operate their own advanced AI systems locally, ensuring full control over their technology and data. The project has the backing of the Canadian government, and industry leaders like Hypertec.
At a time when fear and uncertainty about AI are on the rise, trust is not just a virtue; it’s a path towards profitability. Explore the Trustworthy AI Map to see how.
It all started with a question: What does Firefox sound like to you?
Over the past year, Mozilla developed a small but meaningful set of sounds to add a sonic dimension to the Firefox experience. When we started this process, we knew we wanted something warm, human, and representative of our open source identity. We also knew we didn’t want to invent these sounds in a vacuum. So we did what we’ve always done and turned to our community.
With the help of creative audio company Sounds Like These, we reached out to Firefox users, contributors, and team members across the globe asking them to send us audio and written descriptions of what Firefox sounds like to them. This feedback became our compass.
From there, we began building three new sounds that bring to life our logo, mascot Kit, and Firefox notifications. The logo and Kit sound have already begun rolling out across the Firefox brand (check them out in our new design launch announcement) – and we’re excited to bring the notification sound to the browser in a future update.
Not only did we want these new sounds to reflect Mozilla’s mission and values, we also wanted to ensure they felt connected to one another. This is the story of how they came to be.
The logo sound: A human chorus rooted in nature
Because Mozilla uses a community-based approach to create world-class open source software, we wanted Firefox’s audio logo to share this same spirit. This meant creating something built by many and rooted in real human experience.
Inspired by early community feedback that associated Firefox with nature, we started with delicate organic textures, including bird song and the thump of wood being struck to evoke the feeling of Kit moving through different environments.
We also knew we wanted to utilize the voices of real Mozilla employees, or “Mozillians.” As Sounds Like These Co-founder Sam Heath reflected, “What better way to represent the brand than the sound of the people behind it?”
At first, we considered setting up a professional recording session in a large city where multiple Mozillians could drop in to be recorded. However, we quickly realized this would limit the voices we would be able to include to one geographic location. It was then suggested: Why not just let people record wherever they are? After all, Firefox is used in family living rooms, shared offices, and really most places one can access the internet.
The final result includes the voices of 23 real Mozillians saying “Firefox!”, in which you can hear their subtle differences in accent, tone, and timing. Sam shared that some of these employee submissions included the echoes of distant chatter, families, and all the other subtle sounds of Mozillians’ real life playing out as they recorded. He explained that Sounds Like These did not deliberately edit out the entirety of this ambient sound to preserve the texture and authenticity that comes from real people living their real lives.
“That was something that was very clear from Mozilla from the start. We don’t want to be this shiny, distracting tech brand. We wanted this to feel real, natural, and human,” said Sam.
The Kit sound: Friendly, familiar, and uniquely Firefox
Kit holds the prestigious title of VP of Mascoting at Firefox, and we worked hard to ensure their sound properly reflects such an important position.
Kit’s not an AI assistant, nor a chatbot. They’re not an actual fox, or a red panda either. They’re a Firefox, its own creature not of this world. Kit may appear in your Firefox browser during moments that are meant to feel welcoming and encouraging, like when you’re getting started, trying out a new feature, or successfully making a settings change.
Our goal when creating the Kit sound was to convey Kit’s friendly, familiar, and trustworthy presence without mimicking any real animal. The sound had to be flexible enough to express movement and emotion across animations and videos, while also remaining instantly recognizable.
Early experiments ranged from pure animal sounds to abstract musical expressions. Foxes were considered, but as Sam noted, “Foxes are incredibly difficult to record, and they do make cute sounds, but never around people. You only really seem to hear them literally screaming – and we definitely didn’t want anyone screaming.”
We also explored a more feline route, specifically a cat purr. As Oli Slack, Co-Founder and Head of Audio at Sounds Like These, explains, “The cat purr was almost kind of perfect…other than the fact that it sounded just like a cat purring. So we asked, ‘How do we recreate the feeling of what the purr sounds like, without it being an actual cat purr?’”
This is where the process really got interesting. While brainstorming cat purr alternatives, the Sounds Like These team researched the psychology behind what makes certain sounds more comforting and familiar. Soft tones and warmth from other humans instinctively register as more reassuring and honest, and this also crosses over into animals, particularly animals we keep as companions. This validated our initial draw toward the cat purr, and confirmed we were heading in the right direction sonically.
The breakthrough came when Sounds Like These stopped looking at animal sounds as a starting point, instead using a human voice as the basis of a custom purr. This wasn’t someone imitating a cat or “purring” themselves, it served as a foundation vocalization that was then uniquely shaped and layered to convey Kit’s friendly and encouraging presence. And thus, the Kit sound was born.
The notification sound: A gentle whoosh of helpfulness, coming soon to Firefox
Notifications don’t have to be jarring or intrusive, and that’s exactly what we wanted to avoid when creating one for Firefox.
Our new notification sound – which we look forward to rolling out in a future Firefox update – was carefully crafted to gently alert, not interrupt. It draws inspiration from community feedback that described the feeling of using Firefox like a door opening and referenced moments of quiet discovery filled with gentle wonderment and joy.
This sense of seamless exploration is reflected in the sound’s design: a soft whoosh, like a door swinging open, followed by a subtle click, all in an airy, rounded tone to feel helpful, not demanding.
The result is a sound that softly notifies rather than disrupts or controls, staying true to the feeling of joyful curiosity that many users associate with browsing the web through Firefox.
A family of sounds shaped by community
From the very beginning of this process, we leaned into Mozilla’s values of openness and community.
We consulted our fans and team members. We used real voices. We embraced the imperfections of being human.
These sounds are now a part of Firefox’s story, and we hope every time you hear them, they remind you that you’re using a browser built by the people, for the people.
The Rust team has published a new point release of Rust, 1.99.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, getting Rust 1.99.1 is as easy as:
rustup update stable
If you don't have it already, you can get rustup from the appropriate page on our website.
What's in 1.99.1
Rust 1.99.1 fixes the following regressions from prior releases:
Missing symbol wcslen: Some Rust targets were getting link errors for missing wcslen, and that function is now present in Rust's compiler-builtins library as a fallback.
The LLVM loop-idiom-wcslen pass may introduce calls to wcslen as an optimization, and some Rust targets did not have that function readily available in libc or elsewhere. The UEFI targets in particular were broken for any project using std, as some of these calls were introduced in the precompiled standard library, but the issue was also reproducible for similar user code patterns.
Miscompilation of FFI bool return values on x86_64: Rust functions returning bool through FFI could leave bits 1-7 of the return register unspecified, causing callers to observe raw values other than 0 or 1. This return type is now marked for zero-extension again, as required by the ABI.
rust-lld failed to load libLLVM on macOS: This linker could fail to run if the compiler was invoked without the rustup proxy, as there was no direct setting for the appropriate library search path. Now rust-lld is built with an rpath entry for the directory containing libLLVM.dylib.
If you'd like to help us out by testing future releases, you might consider using the beta (rustup default beta) and nightly (rustup default nightly) channels locally and in your CI. Please report any bugs you might come across!
Contributors to 1.99.1
Many people came together to create Rust 1.99.1. We couldn't have done it without all of you. Thanks!
Me, calmly assessing the implications of LLMs for programming language design(ers).
As someone who has made a career of programming language design, I definitely have moments of existential dread about the rise of LLMs. I started coding in 5th grade on an x861 that ran at 5MHz, had something like a 5MB hard-disk and 512K of RAM2. Computers were really, really different back then. But honestly, programming wasn’t. For all the advances in IDEs and programming languages and so forth, the basic act of entering code into a file has remained surprisingly constant3 – right up until a few years ago, when everything kinda turned on its head. That’s been exciting and empowering at times4 but also scary and disorienting. Will my skills in programming matter? What about my skills in programming language design (such as they are)? This blog post is my attempt to answer those questions.
So as not to keep you in suspense, let me just give you the conclusion. In short, yes, I believe there will still be a role for humans in programming. And yes, I think that programming language design is still relevant. And, naturally, I also happen to think Rust is a really good fit for agentic development – but that’s not to say we can’t make it a better fit. And that’s what this post is ultimately about: what makes Rust and agentic development work well, and where we could double down on those strengths.
Stratospheric among the breakout languages is TypeScript, cropped from the chart and sitting currently at +1200% growth from the prior year. [..]
The second most rapid recent growth is in Rust. Meta engineers have written twice as much first-party Rust code so far this year than in the previous 9 years combined.
— David Tolnay (emphasis mine)
Some of that is because agents make it very easy to try out new things. And some of that is because Rust has a reputation for being performant and, if it’s just as easy to pick any language, why not pick one that will yield faster execution times?
But I think Rust is popular for another reason: because Rust happens to be a really good fit for agentic coding6. Of course, I would, wouldn’t I? The point of this post is (1) to argue for why that is and then (2) to discuss what we might change about Rust to make it work even better.
Foundational Software construction with agents
It seems to me that an effective “software factory” will have three pillars:
Design: figure out and specify clearly what the code is supposed to do.
Construction: author code that does what it is supposed to do.
Optimization: optimize the code so that it runs efficiently.
None of these pillars are solved, but some have made more progress than others.
Rust and optimization: fast by default, knobs when you need ’em
Rust is designed to give “good performance by default”, making the idiomatic thing typically also be the fastest thing. But another key part of Rust is that you have the knobs to eke out better performance when you need it. You control when something is stack- or heap-allocated and where pointer indirection occurs. If you want to, you can force the layout of your structs to be done in a particular way, or decide where to introduce boxing into your async stack frames. In the limit, you can put in inline assembly.
In the past, learning how to “tune the performance knobs” could be a bit of a black art: but agents are making that much easier.7 It turns out that agents are really good at fine-tuning the performance of existing code. For example, people who work on super high-performance cryptographic algorithms used to do so by hand-tuning assembly code. But those people tell me that they are now turning to agents for that same job. More prosaicly, a lot of people building network services are finding that, using a profiler like dial9, agents can quite effectively diagnose async performance pitfalls, like long polls or blocking.
Therefore, I think the task for Rust is clear. We keep on with our goal of “low-level enough for a kernel, high level enough for a GUI”. If anything, I think the shift around agents means we can tolerate a bit more “noise” in the form of explicit calls to clone() or share() – but not too much, since we still want the “happy path” of the code to be clear and evident8, even as we surface details that are important in specific scenarios (like tracking precisely how many clones you have of a channel endpoint). Combined with a profiler, you get an effective feedback loop to get your code running fast:
As usual though, while a reputation for good performance is what brings people to Rust, what makes them want to stay is a sense that using Rust “just seems to work better”. The basic theory is that Rust’s type system and guardrails help keep agents on track:
rust is a perfect language for agents, given that if it compiles it's ~correct
I think there’s truth in that: languages like Rust, Ocaml, or Haskell all share this “if it compiles, it works” feeling, and I think that agents will benefit from that.
Testing is not enough, type systems help
Testing can show the presence of bugs, but not their absence.
— Edsger W. Dijkstra, 1970
Agents presenting their work.
Writing tests has never been enough to show that your program is correct – but, with agents, it’s not even close. It happens so often that my first few tests seem great and then the next one goes completely bonkers. Usually bonkers in a way where I cannot even imagine how that bug could have come about. Then I dig in and I realize the agent completely missed the boat on the logic I was trying to express.9
This is where a type systems really shines – particularly an advanced one like Rust. Type systems give you some guardrails that keep the agent on track. In Rust, those guardrails extend beyond simple stuff like “do all fields have the correct names” and to stuff like never having to close a socket.
Type systems are not enough either
Type systems can show the absence of bugs, but not the presence of correctness.
— Me, failing to coin a phrase of equal eloquence10, 2026
So yeah, type systems are helpful! But they have inherent limits. A type system is a simple set of rules that, if you follow them, make sure that you avoid (certain kinds of) mistakes. But they don’t tell you that you do the right thing – only that you don’t do (certain kinds of) wrong things. If you want to go further, you need a proof system – something that will let you show that richer properties are actively true, not just that you’re avoiding bugs.
As it happens, there are a lot of interesting proof tools for Rust, like Verus, Creusot, Aeneas, and Kani. As a starting point, you can prove that your code is panic-free, which will eliminate a lot of bugs, though it is still fundamentally a “type-checker-like” property (i.e., you avoid doing things wrong). But you can also go further and add assertions that show your code is computing the results you expect.
Strong guardrails give better performance
Deplying proofs is not just good for getting code right – it’s good for getting code fast. This is somewhat counterintuitive, but it’s true. Earlier I mentioned how optimized cryptographic algorithms were now being written by agents. Part of what makes that possible is that cryptographic algorithms have a very clear mathematical definition. This means that you can basically tell the agent “do whatever you want, as long as you can prove that the code still computes the correct result”. These proofs can be done with theorem provers like Lean or Rocq. The blog post “Why Lean is faster than Rust” makes the point quite well.
For Rust, a good example of this would be around unsafe code. Right now, people are sometimes reluctant to deploy unsafe code even if it might make their code faster because it’s not worth the risk of getting it wrong. And I applaud that effort. But what if you could use a prover to show that your unsafe code is, in fact, safe (i.e., incapable of causing undefined behavior)? Then you’d be free to optimize to your heart’s content.
If we are going to prove things, do we need type systems?
You might wonder: if we’re deploying a proof system on our code, do we still need type systems? I think the answer is definitely yes. Type systems are infinitely simpler to work with, which is why they are much more popular. Using a type system lets you rule out all kinds of annoying bugs so that you can focus your “proof energy” only on the important stuff.
As a simple example of this, consider the following Java code:
Without seeing more code, it is impossible to prove whether this assertion is true or not! This is because there could be any number of other threads running around mutating this. In contrast, the following Rust code must be true (at least, so long as the Eq operator is reflexive for Bar):
We know this because the type system of Rust guarantees that &mut self implies a unique reference.
This is in fact exactly how Verus works. By trusting the Rust borrow checker to track uniqueness etc, it simplifies the job of the SMT solver, making proof checking must faster and more reliable than it would be otherwise.
Where I think Rust should go on reliability
So my take is that Rust should double down on if it compiles, it works. As expressive as Rust’s type system is, there are plenty of things that it cannot capture. This includes fairly common things, like this method only reads one particular field or internal references, but also fancy things like “no logging of personally identifiable information”. We should work to lift those limits, giving agents room to prove more complex properties.
We also need to improve the experience of integrating a proof tool by working towards an extensible compiler. As cool as the existing Rust-based proof tools are, using them is a janky experience involing annoying macros and pinned compiler versions. We can do better.
A north star: No more unsafe code
I’d like to propose a north star for Rust: no more unsafe code. By that, I don’t mean that we never use the unsafekeyword. Rather, I mean that we have the power to prove that all the unsafe code we write is correct and cannot cause undefined behavior. Don’t get me wrong: knowing exactly what code needs to be vetted is a huge step forward, as is normalizing the idea that libraries need to be responsible for protecting their users from undefined behavior via safe API boundaries11. But given agents’ ability to find vulnerabilities, I think we need to up-our-game if we want to stop the steady stream of CVEs.12
Design is an open problem
But before you go about proving things or optimizing them, you need to have a clear idea of what you are building. As far as I can tell the state of the art here is basically variations on “markdown-driven-development”, developing docs and hoping that agents pay attention.
I don’t know how much of a role for Rust there is in this space. I think there are some steps we might wind up taking that could be helpful here – for example, having ways to separate out interface from implementation so that it’s easier to review the interface in isolation or to see when the agent made changes there.13 Or perhaps just providing betters tools to review that.
I also think there’s space for dedicated “modeling languages”, something that let you iterate quickly with agents on the high-level designs and invariants without having to get into the weeds and read the code. I have more thoughts on this but it merits many blog posts all of its own. For the moment, I’ll start by pointing you all at this post by Kari Wilhelm, “Principles of Anchor Engineering”, which I think does a nice job of describing what it means to pull out the key elements of a design and drive the coding from there.
Conclusion
We covered a lot of ground here, so let me put this all together. What makes Rust a good choice for developing with agents?
It offers good default perf (why pay more?) and, in conjunction with a profiler, can be tuned as much as you want.
The type system gives stronger guardrails, and if you setup your agents right, you can strengthen those guardrails through techniques like new types.
And what could make it better, from a language design perspective? Overall, I think it’s very similar to what we were doing, except that the way we weight the tradeoffs is tweaked to account for agents doing the code authoring, and humans focused more on code comprehension:
If it compiles, it works – our type system is our big advantage, we need to make it more expressive and more functional so that agents don’t get stuck trying to work around it!
And as an adjunct, establish a North Star: Enable Unsafe code without unsafety by supporting proof, and see the most widely used Rust libraries proven sound.
Low-level enough for a kernel, high-level enough for a GUI – make sure we expose the knobs needed to tune for performance, while also making the code’s intent clear (but don’t worry about golfing the code down to an absolute minimum number of characters).
Extensible and versatile – one of Rust’s great strengths is that, with macros + our type system, we support DSLs and a wide variety of targets. We need to bring that spirit of extensibility into the compiler so we can target more styles of development (e.g., GPU, deep language interop, etc) and also integrate theorem provers and other tools that require more than just tokens.
As a final close, let me point you at this interesting article by Marc Brooker, “What’s easy now? What’s hard now?”. He posits that the more it is possible to clearly specify success criteria for a task, the easier it is, and that we may find that tasks we traditionally think of as ‘hard’ (e.g., building out an efficient implementation of a cryptographic algorithm) may soon become automated, whereas tasks that we have thoght of as ’easy’ (e.g., making a unique, compelling website) may become more valued.
Looking at it from a PL point-of-view, I think Marc’s point reinforces my sense that the biggest action is going to come from design languages, things that let you capture the architecture and intended behavior at a very high-level. The goal would be to let humans intuitively specify a design that gets translated into effective guardrails, whether that’s type system checks, lints, or theorems to be proven. Agents would then take on the task of translating the design into code written in a traditional PL like Rust, with humans looking at it only rarely. This doesn’t make the design of traditional PLs less interesting, but it definitely makes the tradeoffs very different than they were before.
Secretly I have always been jealous of people that coded using punchcards and stored things on gigantic rolls of tape or whatever. I just want to be world weary so badly! I am kinda delighted that I’m finally old enough that I can say things like “I remember when we had to edit CONFIG.SYS before we could play a computer game!” and younger programmers will gasp in horror.5 But I still feel like I must sound like a silly kid to folks who were around “back in the day”. ↩︎
I still remember when my dad told me he had bought me a 10MB disk and secretly he had bought a 40MB disk to surprise me. It seemed absurdly large. “I’ll never need a new disk again!” ↩︎
I mean my god, we’re even using vi again! My first editor! ↩︎
I built an electron app! And it was so easy to do! And reading weird papers and things is so much more accessible now that I can ask an LLM to translate all the math jargon for me. ↩︎
I remember once trying to tell Alex Crichton how I used to “order shareware from a paper catalog by putting a check in the mail” and he was like “I do not understand any of the nouns in that sentence”. Highlight of my life, right after Rust 1.0. Oh, and maybe the birth of my child and getting married. I guess. ↩︎
I’m not saying Rust is the only language that’s a good fit. I’m not even saying that the way that Rust is a good fit is the only way to be a good fit. I have heard for example that Go is a really good fit for agentic coding and I believe it: I think it hits a different sweet spot, one that helps agents iterate quickly (although I do suspect agents will let data races and subtle bugs slip through that Rust would have prevented). ↩︎
The fact that agentic development makes more room for knobs is good for Rust performance, but it is quite likely an even better fit for performance in other languages. Tuning a GC has traditionally been a job that really requires a GC expert, but agents can likely fill that role pretty well these days. ↩︎
On this pont, I’m even more convinced of the importance of ergonomic RC now that I work with agents. Agents are good at introducing the extra clones and things you need to deal with capturing around async tasks, but the resulting code is so annoying to read, it really hides what’s going on. ↩︎
“Claude, this is not what we talked about!” – me, all too often. ↩︎
So close though, right? I just .. couldn’t land the plane. ↩︎
All too often, C++ libraries consider it adequate to tell users “you’re holding it wrong” – i.e., that they are responsible for causing undefined behavior by misusing the API. Rust takes a clear position that a safe API has to protect its users, no matter how much they abuse it. ↩︎
To be fair, if Rust is encountering a stream of CVEs, other languages like C++ and Java are encountering a veritable flood, since they lack the protection of Rust’s type system.
st takes a clear position that a safe API has to protect its users, no matter how much they abuse it. ↩︎
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.
No Calls for participation were submitted this week.
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 significant improvements or regressions this week. Most of the PRs marked as improvements had
a similar perf. result, which was caused by codegen noise in the measurements.
There were some nice wins for memory usage though, thanks to #163915 and especially #163887.
No Items entered Final Comment Period this week for
Cargo,
Compiler Team,
Language Team or
Unsafe Code Guidelines.
Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.
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.
I think that there are a nonzero number of people who are experts in the field who would genuinely respond to "how does C work?" with "it doesn't, next question"
Bug 2079152 - Unable to select content-type when creating attachment
Bug 2079453 - Upgrade devbridge-autocomplete to 2.0.1 and fix autocomplete dropdown reopening after the field loses focus
Bug 2065173 - Migrate Group REST resource to native Mojo API
Bug 2078690 - Migrate User REST resource to native Mojo API: user objects (get, create, update, suggest, whoami, offer_account_by_email)
Bug 2079991 - When one update requests needinfo from several users , the webhook’s event.changes has a single flag.needinfo entry for the last requestee only; the others are dropped.
With the WebDriver related release notes part of the MDN developer release notes and having a 2-week cycle for new Firefox releases now we are going to stop publishing this newsletter. This one will be the last one of the series of blog posts that we did since Firefox 114.
Thank you to everyone who followed these posts and provided feedback over the past releases.
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 158 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 158, multiple WebDriver bugs were fixed by contributors:
Institutions are recalculating who controls the technology they rely on. Mozilla has an independent option to offer.
For years, organizations consolidated technology around a small number of providers to make things simpler. Fewer systems. Tighter integrations. More economies of scale. But that consolidation went well beyond technology. It consolidated dependency, too. The resulting risks have been debated, studied, and challenged along the way, but concentration continued. More work, data and critical infrastructure kept moving to the same few providers, while credible alternatives narrowed.
The deeper that dependency runs, the harder and more costly it becomes to change course. When something fails, changes or falls outside an institution’s control, that dependency becomes a risk for CIOs and CISOs to manage.
Nowhere are these stakes more visible than in Europe. Now institutions are re-assessing. Governments are pushing for greater digital autonomy, while regulated industries face growing pressure to find and manage their dependencies.
There’s a name for much of this debate about technological control: “sovereignty.”
What digital sovereignty means in practice varies. Across Europe, governments are investing in the security and resilience of critical IT infrastructure, reducing strategic dependencies and putting technological autonomy higher on national agendas. Different approaches, same underlying concern. Strip away the regional policy definitions and industry distinctions and a pretty practical, universal question emerges: how much technological dependency should we risk?
And a very specific, very important layer has been largely missing from that conversation: the browser.
The overlooked layer of modern business
The browser. Applications run there. Employees authenticate in it. Sensitive data transits through it. Files are uploaded and downloaded and AI tools are increasingly used through it. That raises the same questions of dependency and control: whose browser technology are you relying on, and who controls the infrastructure used to manage it?
Introducing Firefox Enterprise
Firefox Enterprise is built for organizations with strict security, governance, and compliance requirements. It pairs the Firefox browser, built on Mozilla’s independent Gecko engine, with a management console organizations can run on their own infrastructure. From that console, IT teams can centrally manage browser policy and access, govern how data moves through the browser and set controls around AI use.
IT and security teams get more control over their data, IT infrastructure and browser environment — helping strengthen technological independence and operational resilience.
“If all your options are built with the same technology underneath, ‘choice’ is a lie. So is control,” said Anthony Enzor-DeMeo, CEO of Mozilla. “We built Firefox differently. And we’re bringing its independent architecture to institutions that are ready to rethink their dependencies and risk.”
Bringing the browser under control
We’re starting with the browser because we see it as a key, but under-governed, layer. Firefox Enterprise gives institutions more control over the browser and the infrastructure managing it.
And because Firefox runs on Gecko, the only major browser engine developed outside Google and Apple, institutions have another path towards reducing dependence on a single architecture.
Finally, Firefox Enterprise is built to live alongside the systems that IT operations already use. Keep your identity provider. Keep your SIEM. Keep your MDM. Just add a browser whose management infrastructure you operate, so you decide where data lives and have greater visibility into how it moves.
For us, supporting the goal of technological sovereignty comes down to four things: More control. More transparency. More choice. More resilience.
We know this territory. Independence isn’t a new direction for Mozilla. We’ve spent more than 25 years building and securing browser technology that intentionally works outside of the dominant architecture of the day. Firefox is used by roughly 200 million people every month and is already deployed across thousands of organizations.
That independence has always mattered to the web. Now it has practical value for institutions looking to reduce technological concentration — and dependency — in their own environments.
This is the beginning
Our ambition is big but simple: make technology independence practical.
That means putting institutions in real control of the infrastructure and data they depend on, without asking them to rebuild or start over. Closing blind spots. Defining where policies, access and data live. Keeping core management within the institution’s environment. And bringing an overlooked layer — the browser — under institutional control.
Firefox Enterprise is unveiling across Europe with an initial sales focus on France, Germany, Austria and Switzerland, with more markets to follow. Thunderbird Enterprise is also in development, extending this customer-controlled approach to email and communications. We’ll have more to share as that work progresses.
If your organization wants greater control over its browser infrastructure, we’d like to work with you.
For this post, I wanted to talk about two different approaches to handling supertraits. I’m calling them modular proofs vs external proofs. The key idea of this post is that, if we want to have cyclic trait impls, we really need to use a modular proof strategy, where the impl establishes all supertraits hold. Previously we had considered an external strategy, where the piece of code using the impl has the obligation to prove the supertraits hold. Modular proofs always seemed better but I did not think they were workable in the past. But I have become convinced that external proofs are incompatible with Rust as designed, and hence modular proofs are really the only option1. This post dives into that reasoning, and also gives a bit of explanation of what I mean by proofs in the first place.
Traits and supertraits
So what do I mean by modular vs external proofs? Well, it all comes down to who is responsible for proving that supertrait obligations hold. Consider a trait like Magic:
traitMagic: Copy{}
The supertrait declaration means that, whenever X: Magic for some type X, it should be true that X: Copy. We make use of this in generic functions:
The trick is that the compiler has to make sure that this implication holds – i.e., for every type X that implements Magic, X also implements Copy. So how does it do it?
Modular proofs: the impl must show supertraits hold
The obvious answer is to make proving supertraits part of deciding whether an impl is valid. For any impl of Magic, we can require that the Copy supertrait holds. So an impl like this would be illegal:
// In a modular system, this impl is *illegal*
implMagicforString{}
This impl is illegal because it would require that String: Copy, and that does not hold. Seems good.
Modular proofs are a bit tricky
I am calling these proofs modular because the idea is that we can prove an entire program is valid by proving each part of it separately. In “programming language” theory, this is typically called a “modular” check, as it works by breaking up the entire program into modules that can be independently checked.
The idea with a modular proof is that we can trust impls to show that the supertrait relationships hold, we don’t have to go and re-prove them over and over. If the impl is wrong, the impl will be invalid, but our code is fine. So if we have impl Magic for String, that implies the rest of the program can prove that String: Magic:
fnstring_is_magic(){// Legal, because there is an impl for `String: Magic`:
is_magic::<String>();}
In fact, since we know that Magic implies Copy, the rest of the program can even rely on impl Magic for String to conclude that String: Copy:
fnstring_is_copy(){// Legal, because there is an impl for `String: Magic`,
// and `Magic` implies `Copy`:
is_copy::<String>();}
So long as impl Magic for String is invalid, none of this poses a problem to soundness, since the program overall doesn’t type-check.
Comparison with functions
An easy way to understand the idea of modular checks is to think of functions. Imagine you have a function like this one:
Clearly, this function is not legal. It takes two integers and promises to return a third integer, but in fact it returns a String. So the function is illegal. But if you have a call to that function from elsewhere, we consider that other call to be legal:
fnuse_sum(){letc: i32=compute_sum(2,20);// OK
}
Here, use_sum is relying on compute_sum to obey its contract. It’s not the job of use_sum to check that, it can just assume it is true.
The catch: how do we decide the impl is invalid
There is a bit of a catch though. How do we decide if the impl is invalid? The basic idea was that impl Magic for String would have to prove that String: Copy. But we just saw that it could, in fact, do that by using itself. In other words, if we aren’t careful, we can provide a proof that String: Copy like…
String: Copy because Magic implies Copy and
String: Magic because impl Magic for String exists
and then we would (incorrectly) conclude that the impl is valid. So clearly we need to do something to rule that out. We need a rule that says, when we are proving that an impl is valid, that proof cannot recursively rely on the impl itself.[^termination] I’ll come back in a future post to ways we might do that, but for now, I want to explore another alternative.
External proofs: the user of the impl must show supertraits hold
When we first looked at this problem, way back in 2018 or so, we thought of another approach. What if we said that an impl is not responsible for proving supertraits. Instead, the idea would be that impl Magic for String is not enough to say that String: Magic. It only says that Shallow(String: Magic) – i.e., String implements Magic in a shallow way, but not in a deep way that includes the full supertraits. To prove
that String: Magic, we have to show that Shallow(String: Magic)andShallow(String: Copy):2
This has the somewhat counterintuitive implication that impl Magic for String is actually legal in an “external proof” approach:
// In an external system, this impl is LEGAL
// (but unusable)
implMagicforString{}
The saving grace is that, while this impl is legal, you can’t actually use it. This function for example does not compile:
fnstring_is_magic(){// NOT legal in an external system:
// * We can prove that `Shallow(String: Magic)`
// * We CANNOT prove that `Shallow(String: Copy)`.
is_magic::<String>();}
Here, String: Magic doesn’t hold even though there is an impl of Magic for String, because the caller also has to check that String: Copy is implemented, and it is not. Huh, interesting.
Comparison to functions: external is awkward
the “external proof” approach for impls is clearly a bit awkward. If we make the comparison to functions, it’s as if the caller has to double check that the callee’s body matches its return type, it can’t actually trust the declared signature. But, awkward or not, it does resolve our problem: given impl Magic for String, we cannot prove String: Copy, and hence we cannot prove that String: Magic. We can only prove that Shallow(Magic: String), which doesn’t imply that the supertraits hold.
But external doesn’t work with unsafe traits
Based on the above, for a long time, I was working with the assumption that, weird as they are, we would go with the “external proof” approach. However, as Ralf Jung and lcnr pointed out to me recently, this is very challenging to reconcile with unsafe traits. Consider an unsafe trait like Nullable:
// A type that can be safely transmuted from `0_usize`.
unsafetraitNullWord{}
The way that Rust works, when we write an unsafe impl, it is the job of that impl to prove that the unsafe conditions hold. Other parts of the program get to trust the impl. So if I write a function like this one, it should be considered safe:3
Now imagine that I wrote an invalid impl like this one:
// INVALID: We are asserting that `Box` can be null,
// which is not true!
unsafeimpl<T>NullableforBox<T>{}
Given this program I could clearly call foo::<Box<u32>>(), but that would “go wrong” (cause “undefined behavior”). I think we would all agree that the fault lies in the impl. And yet, that is inconsistent: we say that the impl alone cannot be trusted to figure out if the supertraits are implemented, but it can be trusted to figure out if the unsafe impl is valid?
Conclusion
I definitely believe that we want to treat the “extra conditions indicated by unsafe” as a more general version of the other obligations that an impl has to establish to show that the trait holds– and therefore that we must have modular proofs. That’s kind of a relief, because something always felt wrong about external proofs, but it was hard to put my finger on a concrete problem. In the next post in this series (whenever that may be…), I expect to cover the approach to coinductive modular proofs that I landed on. Then I expect to talk about an alternative that was proposed to me that I find quite appealing.
I think this was obvious to Ralf Jung from the start. But it took me a bit. ↩︎
This notation is called an inference rule. The conditions above the line are the premises and the bottom line is the conclusion. It says that, if you know the premises are true, you can infer that the conclusion holds. ↩︎
In point of fact, I believe this will not compile because of special rules about unsafe, but that’s not relevant to the point I’m trying to make. ↩︎
Servo 0.6.0 contains all of the changes we landed in August, which came out to 417 commits!
The big news is that we’ve turned on support for CSS Grid by default (@nicoburns, #45621).
This has had a huge positive impact on the visual appearance of many websites!
PeriodicWave and createPeriodicWave on BaseAudioContext (@kevlu93, #47492)
This release also contains significant improvements to navigation, document loading, and session history, which are some of the gnarliest parts of the HTML specification. Who knew that loading about:blank was so complicated? The upshot to all this work is that pages that open additional windows or include iframes work much more reliably.
Panning gestures initiated by touch inputs now lock to the dominant axis (@yezhizhen, #46983).
This results in more predictable panning when interacting with pages in Servo.
Accessibility support in Servo continues to make great strides; it can be enabled with the --pref accessibility_enabled command line argument.
Servo now reports positions and sizes for items in the content accessibility tree (@philocalyst, @alice, @mrobinson, #46996), allowing macOS VoiceOver to work more reliably.
We also report many ARIA roles for web content elements to accessibility toolkits (@mukilan, #47318).
Full list of supported roles
alert
banner
blockquote
caption
code
complementary
contentinfo
definition
deletion
directory
document
emphasis
feed
figure
generic
insertion
list
log
main
math
navigation
none
note
paragraph
presentation
rowgroup
search
status
strong
term
time
timer
Servo’s support for Document.execCommand() is rapidly improving, and can be enabled with --pref dom_exec_command_enabled.
We fixed issues with the inserttext command (@Psychpsyo, #47224, #47306), editing uneditable content (@Psychpsyo, #47362), computing contained nodes (@TimvdLippe, #47429), adjusting selections in contenteditable (@mrobinson, #47393, #47581, #47581), and implemented the indent and insertLineBreak commands (@Psychpsyo, #47416, #47445).
We made a lot of progress on the LargestContentfulPaint performance metric, implemented behind the --pref largest_contentful_paint_enabled argument.
Servo now supports the element and loadTime attributes, (@shubhamg13, #46553, #47475), URLs for video element posters (@shubhamg13, #43376), accurate size information (@shubhamg13, #43378), and painting text nodes (@shubhamg13, #47212).
We’re continuing work on the ServiceWorker feature, which can be enabled with --pref dom_serviceworker_enabled.
This month we implemented the CookieStore interface behind the --pref dom_cookiestore_enabled command line argument (@Taym95, #47044) as well as the Cache interface (@gterzian, #47220).
Servo now supports a disk-backed HTTP cache that can be enabled with --pref network_http_disk_cache (@Narfinger, #43819).
This cache persists between runs, but there is not yet any way to clear it.
Embedding API
Breaking change:WebView::toggle_sampling_profiler has been removed (@lumiscosity, #47014).
To perform sampling profiling on Servo, follow the instructions in the book.
Building Servo now requires at least Clang 19 on all platforms (@jschwe, #47421).
Additionally, the cargo-ohos tool is now required for building for OpenHarmony (@jschwe, #47334).
Debug builds on Windows can now complete successfully (@jschwe, #47372).
Linux arm64 builds have been customized to work on Raspberry Pi 5 (@mukilan, #47113).
Any libservo embedders targeting the same platform will require a similar change if they are using jemalloc.
Meanwhile, the OpenHarmony port now supports external keyboards with US keyboard layouts (@jschwe, #47359).
Additionally, there are now better fallback font selections for CJK characters (@RichardTjokroutomo, #47116, #47664).
Setting the device_pixel_ratio_override preference is no longer ignored on Android and OpenHarmony (@jschwe, #47081).
On platforms that memory map font data (such as OpenHarmony and macOS), we can now save time that would otherwise be spent loading font files from disk (@jschwe, #47029).
Similarly, reading system fonts is no longer in the critical path of starting up the engine (@Narfinger, @jdm, #46476).
Canvas renderer worker threads can now be adjusted by the thread_pool_canvas_workers preference, allowing more performance granularity according to embedder needs. (@jschwe, #46691, #47018)
Historically, about:memory has reported all memory usage by Rust implementations of JS APIs as one undifferentiated js/malloc-heap number.
We now break it down by memory usage of nodes in document trees (@pylbrecht, #46931) and interfaces that are not part of the DOM (@jdm, #47531). We also report memory usage for the network stack’s cookie database (@Narfinger, #47248) and the canvas renderer backend (@janeoa, @jdm, #46958).
We’ve added an experimental threadboost mechanism (@jschwe, @mrobinson, #46843, #47027) that has been observed to improve Speedometer results by 50% and allow canvas rendering to reach 60 FPS.
This is initially enabled for OpenHarmony, but future expansion to other Linux-based platforms is expected.
More on the web platform
We upgraded to resvg 0.48, fixing many issues with SVG images with missing width/height attributes that specified a viewBox (@nicoburns, #46937).
Upgrading to Taffy 0.14 fixed a number of CSS grid-related crashes, support for grid names, better intrinsic sizing, and improved performance (@nicoburns, #47031, #47493).
We also fixed some issues in the Taffy grid integration for more accurate baselines (@nicoburns, #47518).
Session history traversals (i.e. navigating backwards or forwards in history) now wait for any outstanding traversal to complete (@mrobinson, #47293, #47485).
Meanwhile, navigations to about:blank are skipped if the initial about:blank document is present (@jdm, #47074).
about:blank documents no longer use the asynchronous HTML parser (@jdm, #47050), and no longer report a readyState of LOADING (@mrobinson, #47450).
Opening auxiliary windows will wait to dispatch the load event until the initial about:blank document has been replaced (@jdm, @mrobinson, #47442, #46975).
For non-about:blank content, we also made the document loading phases more reliable (@TimvdLippe, @mrobinson, #47426), improved conformance of javascript: URL evaluation and navigation target selection (@mrobinson, #47486, #47516), and addressed longstanding compatibility issues with cross-origin Window and Location objects (@mrobinson, #47549).
Our media playback has improved; we fixed several issues around canPlayType() on HTMLMediaElement that allow Servo to report that MP4 content is playable (@jdm, #47612, #47641, #47670).
Input elements with the autofocus property inside of a <dialog> now receive focus when that dialog is opened (@skyz1, @mrobinson, #45826).
Interested in helping build a web browser?
Take a look at our curated list of issues that are good for new contributors!
Donations
Thanks again for your generous support!
We are now receiving 8128 USD/month (+3% from July) 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 36 GitHub users (+1 from July) 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.
Firefox is teaming up with AEG and taking to the main stage at Berlin’s biggest and best indoor arenas. Starting this October, as the indoor music scene heats up and the basketball and ice hockey seasons are in full swing, fans flocking to the Uber Arena, Uber Eats Music Hall, and Uber Platz will see Firefox highly visible around the venue. They may even bump into our very own mascot, Kit, who will be on hand to help them skip the main queues courtesy of Firefox.
We know that the experiences people care about often begin online. The internet is the gateway to how they discover, plan, and navigate their way to concerts, sports events, and nights out before they happen in real life.
Firefox’s presence will help make every step of that journey simple and smoother, starting at the door.
People with Firefox downloaded on their phone will have access to a dedicated Firefox Fast Lane that allows them to skip the main line at the Uber Arena. To ensure the smoothest possible entry, a QR code for downloading Firefox will also be available at the Fast Lane.
“People who use Firefox tend to choose things deliberately, their browser, their music, their nights out. This partnership is for them. A first for Firefox. Most browsers want more of your time online. We want you at the show, faster. Berlin is where we are starting, right across the river from our office. See you there,” said John Solomon, Mozilla-Firefox Chief Marketing Officer.
We are excited to bring what we stand for to Berlin’s premier entertainment venue — choice, control, and a better experience to the moments that people want to enjoy and truly care about.
Today, we are very pleased to announce two new additions to the Mozilla Corporation Board of Directors: Jambu Palaniappan and David Parry-Jones.
As we build the next chapter of Mozilla, we’ve been focused on bringing people onto our Board who combine deep operating experience with a real commitment to the values Mozilla stands for. Jambu and David bring deep experience building and leading technology businesses, and each brings a unique perspective to our Board.
Jambu Palaniappan is the Chief Executive Officer of Checkatrade, where he drives the company’s mission of Powering Great Work. The home improvement platform connects consumers across the UK with quality tradespeople — every year, Checkatrade improves millions of homes and delivers billions of pounds of work to small and medium-sized businesses.
Before joining Checkatrade, Jambu was Managing Partner and Head of Europe at OMERS Ventures, where he invested in and supported high-growth technology companies. Earlier in his career, he spent several years at Uber and Uber Eats, joining as one of the first 100 employees and leading expansion across Europe, the Middle East, and Africa. Jambu holds a degree in Public Policy and Economics from Vanderbilt University.
David Parry-Jones is a board director and former Chief Revenue Officer (CRO) with more than 30 years of experience scaling technology businesses internationally. Most recently, he served as CRO at DeepL and previously held senior leadership roles at Microsoft, VMware, and Twilio. He has led large teams across diverse markets and cultures, working with both early-stage companies and global enterprises.
As a board member and adviser, he brings a practical perspective on growth, international expansion, and building strong teams that turn strategy into results.
Please join me in welcoming Jambu and David to the Mozilla Corporation Board of Directors.
One hundred days ago, Mozilla released Over The Edge 2.0, the second independent report from leading experts on deceptive design Dr. Harry Brignull and Cennydd Bowles, on how Windows, Edge, Bing, and Copilot are designed to steer people away from the browser they chose.
We published the report, and the researchers published the evidence for anyone to analyze.
Browsers are a powerful tool. So it’s no surprise that the history of the web hasmanyexamples of powerful platforms trying to deny people browser choice. Now, as AI reshapes our online experiences, the stakes couldn’t be higher. Browsers are a key distribution layer for AI tools and services, while still determining many of the privacy and security functionality people rely on every day. Steering people toward one browser can therefore shape which AI services reach users and the protections that come with it.
We also shared the report with Microsoft and talked to them about the issues raised in the report. We knew that an immediate change was unlikely, but we hoped that, when faced with independent evidence of harmful design practices impacting Windows users, they would also want better for people.
Instead, it became clear that Microsoft will respect user choice only when it is forced to. It is important to think about what that means for a company whose operating system runs on more than a billion machines. Microsoft’s standard for respecting people’s choices is legal compliance. Not what’s best for its users. Not its own published principles. Not what’s technically feasible. Not even what it already does for users in Europe.
That’s the most shocking part. Not that Microsoft engages in such tactics – we’ve seen that before. It’s the fact that a better version of Windows already exists, and it is already available today – but only if you live in the European Economic Area (EEA), where the Digital Markets Act (DMA) forced the issue. If you live in the United States, India, the United Kingdom, or most other locations around the world, your experience and your freedom to choose for yourself are worse.
One hundred days later, here is what people outside of the EEA still get:
The Windows 10 message “You’re almost done setting up your PC” uses tricky wording to pull people off the default they picked.
Windows Search and Widgets open links in Edge instead of the browser set as default.
Windows keeps Edge as the default for common browser file types like PDFs and SVG images, even after another browser has been set as default.
And people in the EEA also deserve better:
Edge remains pre-pinned to the taskbar; this seems to directly violate the “principled approach to app pinning and app defaults.”
Copilot, Microsoft’s AI tool opens web links in a side-panel instead of the browser people chose, in every region tested, Europe included.
Windows Backup, the tool Microsoft uses to guide people through the migration to Windows 11, silently tries to set Edge as the default when it restores a PC and fails to properly bring the user’s own browser along.
Most of the 2024 patterns are still there. The 2026 patterns are worse. Microsoft is using new surfaces like Copilot and the migration to Windows 11 to further undermine user choice.
Our ask has always been simple: First, give all Windows users the fairer designs that are live in the EEA – regardless of where they are located. Second, stop the remaining harmful design practices that persist in the EEA. That means:
Stopping the remaining harmful design tactics in the EEA and ship that standard worldwide.
Honoring people’s browser choice everywhere it is currently ignored, including Windows Search, Widgets, Copilot, and Windows Backup restoration.
The Mozilla-commissioned report has never been about intent. It’s about accountability and Microsoft’s responsibility to stop undermining people’s choices. The practices we documented need to change. Statements about intent are not a substitute for action.
In the past 100 days, we’ve stopped waiting for Microsoft to act. Instead, we’ve stepped up public pressure on the company to respect people’s choices.
We are also taking the report’s findings to regulators and policymakers. In Europe, the DMA is the only thing that has moved Microsoft. Everywhere else, the lesson is the same: Microsoft ships only when a regulator requires fairer design.
We hope that regulators in the US, the UK, India, and Brazil are paying attention.
Microsoft can do better. It already has, for people in the EEA.
Until it does the same in all jurisdictions, we will keep pointing out the company’s choices and the impact they have on hundreds of millions of users who want something different.
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 relatively quiet week, but a very positive one nonetheless.
Highlights are a 3.1% improvement in rustdoc speed from not using the metadata based crate_hash for rustdoc runs,
a 0.5% improvement from a new fast path in the trait solver,
and a 0.4% improvement from a cache for the parents of SpanData.
This RFC will appear in the Call for Testing section of the next issue (#) of This Week in Rust (TWiR).
You may remove the call-for-testing label. Please feel free to leave the call-for-testing label in place if you would like this RFC to appear again in another issue of TWiR.
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.
Everyone wants to be safe online, but one of the most common excuses we hear is “I don’t have the time or the money to invest in it right now.” Well, we have good news: you can improve your online security easily, for the low price of $0.
Firefox provides several free features designed to make it easier to protect your online life and harder for cybercriminals to target you.
Password manager: Use a unique password for every account
Reused passwords are one of the easiest ways attackers break into multiple accounts. If one site is breached, your login details could be tested on many others.
Firefox’s free password manager can generate and securely store a strong, unique password per site, which is the single highest-leverage fix against password stuffing. For convenience, Firefox can automatically fill in your saved login information the next time you access a previously visited site. However, you still have the option to turn off password saving for specific websites, or completely if you’re using a shared device or simply prefer to enter it each time.
You can manage your stored logins on a singular device at any time. To get a head start, you also have the option to import passwords saved on several other popular browsers. In addition, you can create a free Mozilla account to safely sync them across your signed-in devices.
VPN: Privacy built into the browser
Imagine you’re settling into a corner table at a bustling airport cafe, checking some emails on your phone before you board your flight. Or perhaps you took your laptop to the campus library to finally start that research paper you’ve been putting off. Maybe you’re polishing off that last presentation slide between sessions at an out-of-state conference.
While these moments are routine, connecting to public Wi-Fi anywhere can open a small window of risk – as your IP address, approximate location, and browsing activity can be more exposed on networks you don’t control.
That’s where Firefox’s free built-in, browser-based VPN steps in. While Firefox already encrypts your traffic with HTTPS, the built-in VPN feature routes your browsing traffic through a proxy network, hiding your IP address before it reaches a website. This means the sites you visit will see a proxy IP address instead of your own. It offers an industry-leading 50 gigabytes of free VPN-browsing each month, with no extension or extra app to install. Simply sign in, turn it on, and start browsing.
Firefox’s free built-in VPN first launched on desktop in March, later expanding to Android in July. Unlike a standalone or full-service VPN, it’s designed specifically to protect your browsing traffic within Firefox, not your entire device. This means apps, downloads, and other system traffic are not routed through the browser-based VPN. For people who need broader, device-wide VPN protection, Mozilla also offers a separate paid VPN service.
You can check the full list of regions where built-in VPN in Firefox is currently available here, and learn more about the differences between Firefox’s free built-in VPN and Mozilla VPN here.
Relay: Contain the damage of any one breach
Think about how often you give out your personal email address – for an online purchase, RSVPing to an event, or signing up to a new app. Each time, you trust the site owner will protect your information, but, spam piles up and breaches can still happen – even when you think you’re being careful.
Firefox Relay gives you a smarter way to share. Instead of handing out your real email address, this feature provides secure, random email masks to use any time a website, store, or app asks you for your information. It forwards messages to your real email, while keeping your identity hidden to senders. This means if one service gets compromised, your other accounts stay safe.
You can also use Relay in the U.S. and Canada to shield your phone number, so you can receive calls and texts through masks and reply without exposing your real number.
The best part? To make protecting your privacy even easier, Firefox increased its limit to 50 free email masks earlier this year, allowing you to shield dozens of logins at no cost.
Browse freely: Firefox protects you by default
Even if you sometimes forget to use Firefox protection tools like password manager, VPN, and Relay, there are multiple always-on features operating within the browser to help keep your session secure and private. These include enhanced tracking protection to block hidden scripts and known trackers that follow you across the web, browser fingerprinting protection to prevent sites from building a unique profile of your device, and warnings about deceptive or malicious websites.
Together, Firefox’s individual and always-on security features work to help keep your browsing safe and your data private. So, this Cybersecurity Awareness Month, take a moment to build new habits, try out our free cybersecurity tools, and make life more difficult for cybercriminals. Small steps add up, and we are here to help. Stay safe, stay smart, and keep exploring the web with confidence on Firefox.
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 157 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 157, multiple WebDriver bugs were fixed by contributors:
Sameem merged two internal helpers (remote/shared/Sync.sys.mjs and remote/marionette/sync.sys.mjs), which removed some code duplication.
Will 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/
Firefox Telemetry Engineer and Data Steward Chris H-C (:chutten) gives a talk at Ubisoft's Data Summit 2021 about how Responsible Data Collection as practised at Mozilla makes cataloguing easy, stops instrumentation mistakes before they ship, and allows you to build self-serve analysis tooling that gets everyone invested in data quality. Oh, and it's cheaper, too.
This 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.html
Leif Oines and Will Lachance introduce Glean Annotations: a process and technology for curating and communicating knowledge about the data we collect in Mozilla's products.
The 2021 SciPy conference (https://www.scipy2021.scipy.org/) involved the showcasing of the latest open source Python projects for advancement in scientific computing. Mozilla was a diversity sponsor and a few Mozillians attended and shared their experience of the event.
With Rust 1.100.0, the following changes to 32-bit Windows targets will happen:
i686-pc-windows-msvc Tier 1 with host tools target will be demoted to Tier 1 without host tools.
i686-pc-windows-gnu Tier 2 with host tools target will be demoted to Tier 2 without host tools.
Builds of the standard library will continue to be distributed, but host tools such as the compiler will be no longer available. i686-pc-windows-msvc as a Tier 1 target still undergoes CI testing.
To build 32-bit Windows binaries, cross-compiling from a still-supported host toolchain (such as a 64-bit Windows ones) will be required from now on.
Background
Desktop and Server 32-bit only x86 CPUs are no longer sold for over 15 years, and general 32-bit Windows support has ended in October 2025. This means that the development platforms these targets are meant for hardly exist these days, and even if they do exist they typically aren't capable enough for development.
Even on the modern x86_64 hardware, building i686 Windows toolchains has proven to be problematic. We have encountered compiler binaries crashing when built with the i686 MSVC target, and the GNU C++ toolchain failing with OOMs during LLVM build.
Considering all these things, cross-compiling these targets from a better supported one is what we have found to be the best solution forward. As part of that, we stopped producing host tools for these targets. For the time being, the prebuilt standard library is still available, and in case of i686-pc-windows-msvc still tested on CI.
What Changes?
After Rust 1.100, it will no longer be possible to install toolchains on 32-bit Windows hosts. We recommend cross-compiling from a still-supported host (such as a 64-bit Windows toolchain) instead. Other 32-bit platforms are not impacted by this change.
For more details about these demotions, see RFC 3999 for i686-pc-windows-msvc demotion, and MCP 1020 for i686-pc-windows-gnu demotion.
We try to be responsible with data. For example, we:
- store as little sensitive data as possible
- monitor changes in incoming data on which we've built models
But what happens when those two approaches conflict?
How do we monitor changes in incoming data that we don't want to store?
This talk explains the schema we use to monitor changes in what people are searching for in Firefox...even when we deliberately don't store some of what people are searching for.
The team has been working hard behind the scenes laying a strong foundation for the Thunderbird iOS app. Rather than leveraging existing code, we are building natively from scratch. This fresh start allows us to take everything we’ve learned from Thunderbird Desktop and Android to ensure a fast, reliable, and modern experience on your iPhone right from the start.
Our ultimate goal is seamless cross-device experience. Whether you’re sitting at your desktop computer, checking messages on the go, your workflow should feel effortless and unified.
Right now, we are focused heavily on getting the core foundations right. We are excited about the momentum because having clean architecture today means we can layer on exciting new features much faster in the future.
Below we’ve captured some of our work in progress. Nothing is final, but we wanted to share what we are cooking up so far. If you have feedback, keep reading on. At the bottom of the post we have a link to a user research study where we want to hear from you and what you want to see from Thunderbird for iOS.
Hassle-free setup
Adding account user flow with options for email services like Google and Microsoft
We know people are really busy, often doing more than one thing at a time. We’re making login fast, secure, and fully automatic, so whether you’re signing in with a single click or setting up multiple accounts, you can get to your inbox quickly.
Solid reliable connections
Thunderbird inbox
An email app is only as good as its connection. Behind the scenes, we’re building a background sync that maintains a steady connection with your provider that keeps your inbox up to date while respecting your battery life.
Core daily tools
Formatting toolbar (highlighted to show the details)
Your daily email routine should feel effortless. We’re polishing the essentials: a clutter-free, easy-to-read inbox layout paired with a clean, modern editor that lets you format messages smoothly without getting in your way.
Designed for growth
Thunderbird has always belonged to its community. We’re structuring the app with clean code and an experimental feature flag system so it’s easy for community developers to contribute. This means power users will be able to test out new experimental features early, and external contributors can easily help us extend what the app can do.
When can you try it?
Our goal is to have a first version ready for community testing in the next few months.
Building with our community, not just for people, is core to what we are trying to do. To help us decide what to build next after our first release, we’d love your input. If you had to pick the top three things that matter most to your daily email routine, what would they be?
Survey link Update: the survey has now closed. Thanks to all that responded!
A note to the community
Lastly, we know how long many of you have been asking for and waiting for Thunderbird on iOS. Whether you’ve dropped a comment on our forums, tagged us on social media, or simply kept an eye on our progress, thank you for your patience!
Bringing Thunderbird to iPhone and iPad isn’t just about building an app; it’s about doing it right so it serves you reliably for years to come. Today, we want to pop open the hood, share where we are, and work with everyone to design the best possible experience.
Following the rollout of Firefox’s Shake to Summarize feature to Android devices this May, we wanted to take a closer look at the modeling work behind the feature. In a previous blog post, we discussed our model selection process. Now that Shake to Summarize has been available on both iOS and Android for a few months, we wanted to take it a step further and outline our approach to prompt development.
This is the story of a Shake to Summarize use case that required a little extra prompt tuning: online recipes.
Framing the Problem
The first step in developing a useful prompt is clearly describing what you want the LLM to do. LLMs thrive on specificity, so the more sharply you can define your task, the better your results are likely to be.
This is especially important when using smaller LLMs (like we are here), since these little models are not as good at reading between the lines and intuiting unstated intentions as their more powerful cousins are.
For this application, we were looking to create summaries. On the face of it, this seems pretty straightforward. However, as we iterated on prompts, we quickly discovered that what constitutes a “good” summary depends largely on what one is summarizing.
For example, a useful summary of a novel should provide us with a quick overview of the plot without getting into too many specific details; we wouldn’t expect the summary to contain anything from the text verbatim.
In contrast, a summary of a recipe website should include the recipe essentially as written. If the recipe says “cook lovingly” we might be OK with shortening it to “cook,” but if it calls for 4 cups of vegetable broth, a Tbsp of oregano and a tsp of thyme, we want these details relayed to us exactly. Merely stating, “this recipe calls for some broth and some spices” would not be adequate.
Forming the Prompt
From here, it became clear that we wanted not just one “summarize” instruction, but a whole set of instructions — one for each category of webpage that we wished to summarize. We worked with the product team to compile a list of article types that we were targeting for this feature. For each article type, we then gave a brief description of what a good summary would look like:
Recipe – Ingredients as written, along with the key steps, time required, and any tips given by the author or commenters
News – Only the important details: what happened, when, and what would be the likely consequences to the reader
How-to – Start with the required materials, skills, tools, etc., along with the main steps and any specific warnings called out by the author
Review – Highlight the bottom line rating. If it is a product review, include the pros and cons, the price, and who the target audience is.
Research – Key finding and level of confidence the researchers have in their results as well as the projected real-world impact.
Opinion – The main argument, along with any key evidence cited in support
We then wrapped this list in some general instructions to ground the model in the task and came up with our initial prompt (formatted for readability) [source]:
You are a Content Summarizer. You create mobile-optimized summaries by first understanding what users actually need from each type of content.
Process:
Step 1: Identify and Adapt.
Step 2: Based on content type, prioritize:
Recipe – Servings, Total time, Ingredients list, Key steps, Tips.
News – What happened, when, where.
How-to – Total time, Materials, Key steps, Warnings.
Review – Bottom line rating, price.
Opinion – Main arguments, Key evidence.
Personal Blog – Author, main points.
Fiction – Author, summary of plot.
All other content types – Provide a brief summary of no more than 6 sentences.
Step 3: Format for mobile using concise language and paragraphs with 3 sentences maximum.
We Foxfooded the above prompt and found that it mostly worked pretty well. The summaries the model produced were concise, accurate, and informative.
The only exception was recipes.
We found that, when the prompt above was used for recipes, the model tended to summarize too much — often leaving out key ingredients, or in some cases, leaving out the recipe entirely.
The webpage provides a detailed recipe for a vegan lentil soup, which the author claims is the best they’ve ever made. The soup is made with pantry staples like lentils, diced tomatoes, vegetable broth, and spices (cumin, curry powder, thyme), along with fresh vegetables (onion, carrots, garlic) and greens (kale or collard greens). A key step is blending a portion of the soup to create a creamy texture without dairy.
The summary is accurate, so far as it goes, but it isn’t exactly useful. If our goal is to have the summary be a quick way to access the recipe itself, without having to read through the narrative preamble, this wouldn’t cut it.
Focusing the Prompt
To address this problem, we needed to be more explicit with the instructions we gave the model when summarizing recipes: we needed to tell it which information we were interested in and which it could safely discard.
Although we could have added this extra guidance directly to the prompt above, doing so risked causing the model to over-index on the recipe formatting and ignore the other article types. Instead, we developed a separate prompt which contained only the recipe instructions and directed recipe summarization requests to use it, rather than the general one [source].
To perform this routing, we used the structured data embedded in each webpage. While this categorization could have been handled by another model pass, metadata from the webpage itself allowed us to quickly and deterministically identify the page categories without additional inference overhead. To capture cases where this data is either missing or inaccurate, we also maintain some lightweight recipe guidance in the general prompt.
After this change, the summary returned by the model for the above recipe became much more usable (shortened for brevity):
Servings: 6
Total Time: 50 minutes
Prep Time: 10 minutes
Cook Time: 40 minutes
Ingredients
¼ cup extra virgin olive oil
1 medium yellow or white onion, chopped
2 carrots, peeled and chopped
…
Instructions
Warm the olive oil in a large Dutch oven or pot over medium heat.
Add the chopped onion and carrot, cooking until the onion softens and turns translucent, about 5 minutes.
…
Tips
Use an immersion blender for easier blending without transferring soup.
…
Nutrition
Calories: 320
…
With this change in place, we ran a quick test over a curated set of recipe sites and found that the new system was more than twice as likely to return a complete and accurate summary than our previous one. Success!
The system was now working as expected: summaries were useful and recipes were complete.
Reflections
From this experience we learned that the model produced the best results when it was told explicitly what we wanted it to do. When the instructions were vague or left too much up to the model, performance suffered.
To this end, we found that framing this problem as a routing problem — where the specific kinds of articles are routed to specific prompts — worked well. Since the task of summarization is not monolithic, our summarization pipeline should not be either.
Even though our current approach has only a single category-specific prompt, we hypothesize that the system would see further gains by using dedicated prompts for other page types as well.
More broadly, this experience reinforced an important lesson for us: improving AI systems is not solely about building larger or more capable models. Some of the biggest gains come from reducing ambiguity, narrowing the task, and designing systems that help the model succeed. Within the right harness, smaller, open source models can deliver great value.
While building more capable models continues to advance the field, our experience shows that thoughtful system design and solid engineering still matter.
The Rust team is happy to announce a new version of Rust, 1.99.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.99.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.99.0 stable
extern "C" variadics
Rust 1.99.0 stabilizes defining C-ABI variadic functions with "C" and
"C-unwind" ABIs. Variadic functions defined this way use a variable argument
list (...) and accept an arbitrary number of arguments. Rust could already
call externally-defined variadic functions (e.g., libc::printf). With Rust
1.99, these functions can now be written in Rust itself:
/// SAFETY: must be called with (at least) 2 i32 arguments.unsafe extern "C" fn sum(mut args: ...) -> i32 { // SAFETY: guaranteed by the caller. let a = unsafe { args.next_arg::<i32>() }; let b = unsafe { args.next_arg::<i32>() }; a + b}fn foo() -> i32 { unsafe { sum(0i32, 2i32) }}
The type of ... is VaList,
which is ABI-compatible with the C va_list type across targets. What types can be read from a VaList is guarded by the
VaArgSafe trait.
For more details on c-variadic functions, see the
Reference.
This release also stabilizes support for defining naked variadic functions with
non-"C" ABIs, which must be written via inline assembly.
Layout information from raw pointers
This release settles the safety requirements for retrieving the size and
alignment on raw pointers to both Sized (trivially safe, already possible on
stable) and non-Sized types.
Recommend against round-trip unleaking after Box::leak
While there are no changes to the language semantics in Rust 1.99, we have
updated the documentation on Box::leak to recommend against patterns that
later deallocate that memory. This was done because such code was found to have
problematic interactions with current and future potential compiler optimizations,
and is especially problematic with the upcoming stabilization of custom allocators.
Instead, Box::into_non_null or Box::into_raw should be preferred.
This guidance also applies to other leak functions in the standard library.
In this edition, we’re exploring the new Firefox design, Mozilla’s recent partnership with Mistral to expand choice in AI-powered browsing, and several ways to get involved with MozFest. You can join a livestream about the value of bringing open-source communities together in person, volunteer at MozFest in Barcelona, or take part in the latest privacy discussion from the Firefox community on Reddit.
Read on for the latest updates and opportunities to participate!
More modern. More flexible. Still Firefox.
Firefox 157 introduces a new Firefox design with updated colors, icons and themes that make the browser feel more modern while preserving the familiar Firefox experience. The release also brings back Compact Mode and adds easier theme selection, new wallpapers and more ways to customize the New Tab page. Underneath the new look, Firefox remains independent and open source, with built-in privacy protections and controls that let you decide how your browser works, including how AI features appear.
Mozilla and Mistral have announced a partnership aimed at increasing competition and preserving user choice in AI-powered browsing. As part of the collaboration, the open-source Mistral Small 4 model is coming to Firefox Smart Window Beta as a new option for users in the US and Canada. Smart Window Beta is also expanding to France with official French-language support, with additional European markets planned. Users can continue choosing from multiple AI models, reinforcing Firefox’s commitment to avoiding lock-in and keeping the web open to different technologies and providers.
Is showing up in person important for open source? Join the Owners Not Renters livestream on Tuesday, September 29, to hear the story behind MozFest and explore why gathering in person still matters for open-source communities ahead of MozFest, taking place October 28–30 in Barcelona. Kali Villarosa (MoFo), Seher Shafiq (MoFo) and Brian Behlendorf (co-founded Apache) will join host Marcus Rein for an open conversation, followed by a live Q&A. Bring your questions and your hot takes!
From 28–30 October 2026, the Mozilla Foundation will host the Mozilla Festival in Barcelona, bringing together people from diverse fields to explore how we can work collectively to “re-wild” the web. To help bring the Festival to life, we’re building a team of volunteers. By joining, you’ll help deliver a major event in support of Mozilla’s mission while also having opportunities to participate in sessions throughout the three-day Festival.
Privacy conversations are going mainstream, and Firefox has been at this for 20+ years. In light of a recent video making the rounds about the importance of privacy, the Firefox Team shared a rundown of built-in privacy features (ad blocking, tracking protection, encrypted sync, a free VPN, and more). Jump in at r/firefox and share your own privacy tips and configs!
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 was fairly positive. We had no pure regressions, and most of the results came from a few architectural improvements with mixed or mostly positive impact. Some improvements also come from addressing previously triaged regression caused by missing no_alias annotation for references in closures.
The biggest improvement this week is in rustdoc, from tackling quadratic behaviour when generating sidebar links. This was reported by a user, but the effect didn't show up in our benchmarks, so we added a special stress test for it.
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.
The community is obnoxiously helpful. I asked a simple question on the Rust community Discord server. What is the best way to read a file in Rust? I expected a straightforward response. Instead, I got back a 2,000-word essay on the inner workings of IO, buffering, error handling, and ownership, plus links to four different blog posts and three different approaches depending on file size, and a working code example.
...
The Rust community has weaponized education against me. I'm now a better engineer than I was yesterday against my will.
On September 29, Firefox 157 shipped Nova, the biggest refresh of the Firefox interface since Proton back in 2021. The browser frame is cleaner, the sidebar plays a bigger role, and vertical tabs are a first-class layout. Your theme continues to load, and most color and image properties work as they did before.
What does change is where those colors and images display, how some of them look next to each other, and a handful of properties that no longer have a visible effect. Most themes will look fine. Some, especially themes built around a background image, look different enough that you will want to take a look.
This post walks through what changed compared with the Proton interface, what to check in your theme, and what is still being worked on. If you only have five minutes, jump to the checklist.
What changed in the browser frame
The toolbar and sidebar now sit flush with the window edges, with no gaps between them.
For your theme, this means your frame color and background image have less empty space around them, and the edges where the toolbar, sidebar, and page meet are more visible.
Area
Proton
Nova (Firefox 157)
Toolbar and sidebar
Flush with the window, no gaps or floating borders
Same as before
Horizontal tabs
Theme background applied to the tab strip
Same as before
Vertical tabs
Tab bar color on the tab strip
Tab bar color also shows on the toolbar
Sidebar
Separate panel
Shares the theme background with the toolbar area
colors, accents and tabs
Accent color. The default Firefox theme uses Nova’s purple accent. Every other theme, including yours, uses the operating system’s accent color for buttons and other accented controls. Themes cannot set the accent color through the manifest, and is why your theme cannot show the purple you see in the default theme.
Focus and link colors. Firefox still applies its own blue and cyan to focus rings and some links when a theme other than the default is active.
The selected tab. Proton always drew a shadow under the selected tab, which helped it stand out even when a theme did not style it. Nova removes that shadow. If your theme relies on it, the selected tab can blend into the tab strip. Set the selected tab colors, with tab_selected and tab_line, so the selected tab stands out.
Button hover colors. Your button_background_hover and button_background_active colors also apply to buttons on the tab strip, and for buttons that sit on your frame background with vertical tabs. A solid color picked to match the toolbar can almost disappear there. Semi-transparent colors, for example rgba(0, 0, 0, 0.15) for hover and rgba(0, 0, 0, 0.3) for pressed, work on both backgrounds.
Sidebar and vertical tabs
The sidebar shares your background. The theme background now continues under the sidebar, so the sidebar and the toolbar area appear as one surface.
Set sidebar colors explicitly. Use sidebar and sidebar_text for sidebar panels. If you leave them out, Firefox picks colors for you, relevant to your theme’s color.
sidebar_border is now a separator. The sidebar splitter is gone; the property now colors the line between the sidebar and the page.
Sidebar buttons follow your text color. Buttons and icons in the sidebar are derived from your text color rather than your toolbar button colors, so they can look slightly different from the toolbar.
Vertical tabs and the toolbar. With vertical tabs, your tab bar color is also applied to the toolbar. If those two colors were chosen to contrast, check how they look together.
Expand on hover. In Firefox 157, a sidebar that expands on hover may not show your theme’s background. This is fixed in Firefox 158.
Properties that changed or no longer work
Some theme properties behave differently in Nova. Your theme still loads if it uses them; they just have no visible effect, or style something different.
Property
In Nova
ntp_text
No longer styles the new tab page search box
popup_text
No longer styles the address bar dropdown; other popups still use it
sidebar_highlight
No visible effect; the default highlight color is used
sidebar_highlight_text
No visible effect
toolbar_bottom_separator
Acts as a separator next to or below the toolbar and around the page
Themes using images are where you are most likely to see a difference. Your image can now show behind the sidebar and vertical tabs, and an image designed for a wide, short toolbar rarely looks good stretched or tiled down a vertical panel. In our testing of popular themes, the image themes that look off in the sidebar mostly did before Nova too. We did test a number of themes but we invite you to do your own testing. Nova makes the sidebar more visible, so the issues are easier to notice.
You can now choose where your images go with the backgrounds_area property, available from Firefox 156:
“auto” (the default): Firefox decides from additional_backgrounds_alignment. If any image is aligned to the vertical center or bottom, images stay in the top toolbars; otherwise they cover the whole window.
“window”: images cover the whole window, including behind the sidebar and vertical tabs.
“top_toolbars”: images stay in the toolbars at the top of the window, and the sidebar uses your frame color.
If your image was made for the toolbar only, “top_toolbars” with a frame color that suits the image is usually the quickest fix.
Also set a toolbar color, even a semi-transparent one. Without it, notification bars that appear above the page sit directly on your image and can be hard to read.
New Gradient Support
Nova’s color themes use gradients, and you can too. The Nova theme manifests are the best working example; look at how they set colors for each surface, including the sidebar. backgrounds_area applies to gradients the same way it applies to images. Older versions of Firefox ignore color properties they don’t recognize, so your theme still loads there; if you use a feature older versions reject, set strict_min_version in your manifest.
Checklist: what to check in your theme
Install your theme in Firefox 157 and look at it in each of these states:
Horizontal tabs and vertical tabs.
Sidebar closed, open, and expanded on hover. Also toggle “Customize sidebar” while the sidebar is open or expanded.
Compact density, if your users are likely to use it (under settings -> appearance density(.
A private window.
Light and dark system settings, since the accent follows the operating system.
Hover over the buttons on the tab strip.
Then, if something looks off:
Set tab_selected and tab_line so the selected tab stands out without Firefox’s old shadow.
Set sidebar and sidebar_text to colors that match your theme.
Use semi-transparent button_background_hover and button_background_active colors.
Check that your tab bar and toolbar colors work together with vertical tabs enabled.
For image themes, choose a backgrounds_area and set a toolbar color.
Remove or ignore properties that no longer have an effect.
Publish an update on AMO so your users get the changes.
What we are still working on
Nova will evolve after launch. Firefox 158 ships on October 13 with the expand-on-hover sidebar fix. We are also working on these, with no release date yet:
Focus and link colors that fit your theme instead of the fixed blue and cyan.
A popup_icons color for icons in menus and panels, separate from toolbar icons.
Theme colors for hover and selected states inside sidebar panels.
Better hover states for tab strip buttons.
We will post again when these land.
For users who prefer the old look
Some of your users may miss Proton. From September 29, Mozilla is featuring a Firefox Proton theme in the Add-ons Manager for anyone who wants the previous look. It is a normal theme, so users can switch between it and yours at any time.
Nova theme manifests: worked examples for gradients and sidebar colors; the themes themselves are on AMO, for example Nova Sun.
Questions?
We want your theme to look its best in Nova. If something looks wrong and the checklist does not fix it, tell us on Discourse and include a link to your theme and a screenshot. Those reports help us find the cases that need a Firefox fix rather than a theme change.
Thank you for making Firefox look like you and like your users.
What comes to mind when you think of Firefox? Is it our best-in-class privacy features and ad blocking capabilities? Our partnerships with Wrexham, NVIDIA or Mistral? Or maybe our adorable mascot Kit?
If you’ve been following Firefox this year, you’ve seen us add new ways to get things done while giving you more choice over how you browse. That includes browsing two pages side by side, adding an extra layer of privacy with built-in VPN, blocking trackers for smoother scrolling and faster load times, and deciding how AI shows up in Firefox.
For the past few months, many of you have also been trying out our new Firefox design in Nightly and sharing your thoughts with us as we continued to refine the experience.
Today, we’re rolling out that design with FX 157 to everyone using Firefox across desktop and mobile devices. Firefox has done a lot of growing over the last year; now it looks the part.
A more modern Firefox
When we first shared our plans to design Firefox for the future, we said we wanted Firefox to feel “current, but not generic. Warm, but still precise.”
That design ethos now carries across all of Firefox. We’ve refreshed the colors, icons and themes throughout the browser, from the tabs and toolbars you use every day to your New Tab page, Private Browsing experience and more, with no cost to your browser performance.
This shared design language across desktop and mobile gives Firefox a consistent foundation for new features and experiences, while keeping the personality that makes Firefox unique.
Make Firefox yours
We’ve added more choices for how Firefox looks and works, including the return of a feature many of you asked for:
Compact Mode is back. As people started trying the new design, we heard from many of you who wanted to fit more into your browser window. Compact Mode reduces the size of your tabs and toolbar to give more of your screen to the web, with an auto-compact option for smaller screens.
Find your look. A new theme picker makes it easier to explore different looks for Firefox, with new themes and wallpapers to choose from.
Set up New Tab your way. Choose what you want to see on your homepage. Now, you have a dedicated space to pin and organize shortcuts so sites you use all the time stay put.
Refined, not reinvented
Themes and wallpapers may change over time, but the things that made people choose Firefox in the first place are still the same. We’re still independent and open source, with privacy protections built into the browser and controls that put you in charge of how Firefox works for you.
This carries through everything we build, from the height of your toolbars and what belongs on your New Tab page to which AI features show up in your browser, which model you choose and what context you want it to have.
Today’s Firefox is a renewal, grounded in the same principles that have shaped it from the beginning, with a new design built to carry Firefox forward.
For those who have come with us on this journey, thank you for helping us shape the future of Firefox.
If you’ve been away on hiatus, welcome back. Try the latest Firefox and let us know what you think.
We spend a lot of time browsing online. Whether you are researching for work, planning a trip, paying your bills, or scrolling through social media, your browser is there for it all.
While all these tasks are very different in nature, a lot of people still tend to stick to the same window type for all their use cases. But what if there was a different way to browse? You may have noticed Firefox now has three window options for desktop. On top of the Classic and Private windows you’ve known for years, a third choice has been rolling out in beta: Smart Window. This optional AI-powered browsing experience is built to move your work forward and help finish what you started online.
Following the recent addition of several new Smart Window capabilities, we thought now would be the perfect time for a breakdown of what each of our three window options actually does, and when to use them.
Classic: Timeless and tailored to you
Classic Window is still the most customizable option of the three. While Private and Smart windows share many of the same features and capabilities as Classic, a Classic Window offers the widest range of Firefox’s standard personalization options. It gives you the broadest canvas for tailoring Firefox to the way you browse.
Classic is your home base. It’s the best place to start customizing around your browsing needs, whether that means an extension setup specifically tailored to your workflow, a special theme that matches your style, or just the familiar Firefox experience you created over years of tweaking to your personal taste. While many customizations are also available on Private and Smart window, Classic offers the most extensive line-up of optional browser features, extensions, and aesthetics to personalize your setup.
Classic is the right move for general browsing like scrolling through social media, conducting a quick Google search, or reading online articles. It’s also the best place to start if you are looking to build your browser around you.
Private Window: Browse with greater peace of mind
Private Window stays true to its name and number one priority: it’s designed to limit the information associated with your browser session. When a Private Window is closed, Firefox doesn’t retain session information, such as what you searched for, the sites you visited, or the cookies they set. What makes it Private:
Pages visited from a Private Window will not be added to the list of sites in Firefox’s History menu, the Library window’s history list, nor the address bar drop-down list.
Nothing entered into text boxes on web pages and Search bar will be saved for Form autocomplete.
Cookies set in a Private Window are kept only temporarily in memory, separate from your regular cookies, and are discarded after your last Private Window is closed.
A Private Window is recommended when you don’t want activity from a browsing session sitting in your history, such as shopping for a gift. It’s also helpful when browsing on a shared device, ensuring your history, logins, and cookies will not be saved for the next person.
You may not need a Private Window every time you open your browser, but it’s always there for you when you do.
Smart Window: Firefox’s privacy-first, AI-powered browsing experience to help get stuff done
Smart Windowis Firefox’s newest window type, currently rolling out in Beta to users in the U.S., Canada, and France. Think of it as a Classic Firefox window with a built-in AI assistant layered on top – one that you can choose to have utilize your open tabs, recent browsing, and the page in front of you, so it can help you do more without switching contexts – all with the privacy and security you expect from Firefox.
What makes it Smart:
A built-in assistant that can summarize pages, generate recommendations, compare information, and plan tasks using your open tabs.
The ability to retrieve current web information and display the sources behind its response without taking you to a separate search results page, supported by Firefox’s new partnership with Exa.
Suggested groups for related tabs.
Visual previews of pages from your browsing history, so you can surface the page you’re looking for more easily among similar results without opening each one.
The choice of three AI models to power the assistant, as well as the option to bring your own model.
Optional “memories,” built from either your Smart Window chats or your browsing activity in both Smart and Classic windows, or both. Memories help the assistant give you more helpful, personalized answers over time. They are stored locally on your device and can be deleted at any time.
When to use it:
Smart Window shines when you need a little extra help finishing what you started. Its ability to work with the context you choose to share can help you make progress on ongoing tasks that may require more than one session, like trip or event planning, comparison price shopping, or conducting research for work or personal reasons.
And with Smart Window’s optional memories, which learn your patterns and preferences over time (with your permission), Smart Window gets more useful the more you use it, keeping you from having to spell everything out from scratch each time.
Selecting the right window for the job
None of these windows is “better” than the others, they’re built for different moments.
The good news is you are never locked into one. Firefox lets you move between all three depending on what you’re doing, so you can choose the window that fits each task.
You can access Classic and Private windows at any time from the Firefox menu. As for Smart Window, it remains in beta, with current availability to people in the U.S., Canada, and France.
Greetings once more from the Thunderbird development team!
As the Northern hemisphere summer comes to an end and a slew of PTO, company holidays and projects have wrapped up, what better time to share progress and next steps on the work the Thunderbird Desktop Engineering team has on their plates!?
Exchange support moving well
The powerhouse Exchange engineering team had some great momentum over the summer and completed their work on implementation of the Graph protocol to support email accounts – well in advance of their deadline. They have since moved on to start work to support Exchange calendars using the Graph protocol which is a significant milestone given that our calendar code hasn’t had significant changes for some time.
While some team members are now juggling multiple projects, good progress has been made to wrestle the foundations into place, with calendar discovery and persistence in place, along with display of calendar items. Following a brief hiatus to focus on other priorities, the team is once again back into gear.
Since I last wrote, many of the account setup and account authentication improvements have landed (mostly in versions 156 & 157), unlocking some important security use cases which are becoming more frequently requested and mandated by organizations and legislation around the world.
While diving into the code is an enjoyable adventure, the newly-minted articles devoted to the topic of Oauth customization might be a better starting point for most: Knowledge Base – Custom OAuth for Thunderbird
UI overhauls – why just one?!
The front end engineering team has completed the rebuild of our account setup manual configuration flows to include new protocol options and security customizations, so it is time to pick up where we left off on our Calendar UI rebuild.
The majority of the front end team is now either focused on Calendar Event data write operations stemming from the Event Read dialog (delete event, RSVPs, Reminders) – or beginning the largest part of the journey, which is the implementation of a new Calendar Create/Edit dialog, along with REDUX-based state management, a new WYSIWYG editor and more reusable components such as date pickers.
While that work is underway, why not weave in some more improvements?!
After some extensive user research and testing, our design team has begun work to improve the Settings UI, starting with some updates to humanize and homogenize the various options, headings and guidance provided in that area of the application.
In the past few months, we’ve seen a wonderful increase in contributions from community members – partially thanks to our move away from Mercurial to a more familiar Git-based workflow – and partially thanks to many LLMs doing a great job of interpreting our public codebase and making it far more accessible. Or it could be that our team is just such a friendly bunch that we’ve attracted a great group of people willing to support.
Whatever the reason, we’re happy to see new names. faces and ideas in our chats and review queue!!
Having said that…We’ve reached the point where the velocity of work is beginning to pile up and clog our review queue – so I felt it might be time to share some guidance to make the process easier for both external contributors and the internal review team. Bear in mind that while we use AI workflows in several areas, our goal is to preserve a codebase which can be maintained by humans. We’re working on a policy that may word some of these points better, but from the past few months of my experience here’s what I see as being helpful:
Keep patches to a digestible size and understandable complexity – Contributions should save more development time than it takes to review. If the patch contribution creates heavy work for maintainers, it will be deprioritized – so the best approach is to break the work up into pieces that can be understood more easily and discussed together. Bear in mind that many cloud-based models aren’t primarily designed to be frugal with token usage so it’s easy for patches to grow (much) larger than they actually need to be to solve the problem. Be specific with prompts to minimize the surface area of changes so they are reviewable.
Humanize or write comments (within code and throughout the code review process) by hand – While we’ve become accustomed to interacting with a variety of automated systems in our daily lives, a good chunk of the joy involved in our work is to share knowledge with each other and refine the code so that it can be reused and understood by humans.
Be wary of license infringement – much of our work is under the MPL license and we must all take care not to introduce refactored code that originally came from licensed software which can be rewritten and translated using LLM, then relabelled under our licence.
Be transparent – it will often help to share prompts and your model when submitting code for review. Refining all aspects of our workflow is important, and we can all benefit from a collective evolution of skills and prompts that improve over time with input from the team and community.
We encourage contact with a member of the team to discuss approach and architecture in advance of spending time and tokens on a patch. Some areas of the codebase are already slated for redevelopment and it’s not always obvious what is underway and planned. Having a quick conversation to say “Hey, I’m thinking about working on this” is a great start to landing something that spends less time in review and uses less tokens, energy & the world’s natural resources.
Of course if none of these guidelines are followed, we’ll still be very happy to receive help from the wider community – the process may just take longer and be a bit less pleasant.
Enterprise
As parts of the world turn their infrastructure priorities toward digital sovereignty, we’ve seen an increase in interest from governments, institutions and organizations around the world who are looking to either improve their existing FOSS-based infrastructure or deploy for the first time. That has resulted in some focused efforts throughout Q3 to improve our Enterprise security and policy framework to bring it in line with the strides that the Firefox engineering team has made, and also roll out more Thunderbird-specific administrative mechanisms that allow granular control over end user configurations. Read more about your options and follow the work below:
Maintenance, Upstream adaptations, Recent Features and Fixes
Waves of changes from upstream Firefox have continually kept the team on their toes throughout July & August, but the small but mighty gang have kept Daily builds largely intact each day. In addition, the team and contributor community have continued landing a series of reliability, stability, and usability improvements across the application. Recent highlights include:
Nico has a series of calendar improvements in the works with several now cleared for landing: D319397, D320418, D320419
Hurtmut has again come to the rescue with a number of patches but most recently solved a widespread filtering problem introduced upstream which will need to be uplifted as a matter of urgency.
Richard pushed many patches since my last update, many related to upstream changes required after the Firefox project “Nova” was unleashed. He’s also been on the lookout for other breaking changes such as XUL attribute modifications.
Max was on fire and in constant comms with the team to deliver a large number of important changes but also helped to refine some of our processes relating to AI-driven workflows. Recently, he led an investigation into growing concerns over instability with connections with Gmail accounts in Bug 2028760.
If you would like to see new features as they land, and help us find some early bugs, you can try running daily and check the pushlog to see what has recently landed. This assistance is immensely helpful for catching problems early.
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.
If you are a feature implementer and would like your RFC to appear on the above list, add the new 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.
Thanks to Kohei for his work on the newly revised Guided Bug Entry form! If you want to check it out yourself, then click on the Switch to Bugzilla Helper link at the bottom of the enter bug product selection page. Normally users without canconfirm permissions will see the Guided Bug page by default which a large percentage of our Bugzilla users.
Firefox DevTools MCP (firefox-devtools-mcp) 0.10.4 is out on npm.
Changes
This release only contains additional hooks and configuration files to register Firefox DevTools MCP on various third-party aggregators, as well as a new task to automatically register the mcp on https://registry.modelcontextprotocol.io/ on release.
At the end of August, we announced our first Maintainers in Residence, Rust Project contributors who are funded for their upstream contributions and maintenance work from the Rust Foundation Maintainers Fund (RFMF). Since then, the Rust Leadership Council has dedicated more funds from its Project Priorities budget to RFMF, and together with AWS also providing additional funds, this allowed us to open a new full-time Maintainer in Residence (MiR) position to support the Cargo team. We would like to thank the Rust Leadership Council, AWS, and also the Rust Foundation for providing us with this opportunity! If you would like to help us hire more maintainers to improve Rust, consider donating to RFMF.
This post explains why we chose to support the Cargo team specifically, and introduces Scott Schafer, the new Cargo Maintainer in Residence.
Why Cargo?
The new MiR full-time position is dedicated to helping with the maintenance of Cargo, our build system and package manager. The Cargo project is deeply involved in many new Rust features, improvements, and Project Goals. Combined with its cross-cutting nature, where it has to support many different use-cases and integrate with several other tools, it takes a lot of work just to keep up with its maintenance needs, let alone support so many feature requests and proposed changes.
Because of that, the Cargo team has sometimes struggled with meeting its maintenance demands. You might remember that for several years, it actually held a feature freeze, to reduce Cargo's internal tech debt, perform necessary refactorings, go through the issue and pull request backlog, and come up with scalable internal development and design processes, so that they could eventually go back to even thinking about adding new features.
Recently, some changes occurred within the team, which made it more difficult for them to meet their maintenance baseline. Some members of the team left, while others lost their dedicated funding for working on Cargo maintenance and had to scale down their involvement. The Funding team thus considered it very important to support this team, given that we had an opportunity to do so. And thus we decided to hire a full-time maintainer to work on Cargo for (at least) the next 12 months.
Even though we know that a single full-time maintainer will not completely solve the maintenance struggles of the Cargo team, we hope that it will improve the situation, and provide a bit of a relief for the team.
Introducing Scott Schafer
We are very happy to welcome Scott Schafer (@muscraft) into the Maintainer in Residence role! Scott has joined the Cargo team three years ago, and apart from working on Cargo, he is also the lead of the Rust Docker team, which prepares official Docker images for every Rust version.
Apart from working on general maintenance of Cargo, Scott has implemented Cargo's Workspace inheritance feature, and has also spearheaded a complex multi-year effort to switch the rendering of diagnostics in the Rust compiler to use the annotate-snippets crate. This effort has been completed in the Rust 1.93.0 release. Thanks to it, the same diagnostics interface can now be shared between the compiler and Cargo (and also other tools), which amongst other things unblocked further development of the Cargo linting system, which has now been stabilized and will ship in the Rust 1.100.0 release.
Everyone we talked about was very excited about Scott becoming a Cargo Maintainer in Residence, and we share that feeling. We wish Scott all the best in his new role, and we are very happy that we can support his maintenance work.
Here is what Scott thinks about it:
I am incredibly excited to work on Cargo full-time! There have been so many things that I wish I could've worked on over the years, that I will now be able to get to. I hope that my efforts will bring Cargo into a more maintainable state.
Conclusion
We are incredibly happy that we keep getting more funds for the Rust Foundation Maintainers Fund, which allows us to support Rust Project contributors. The funding team will be working with the supported maintainers, and also the funders, to ensure that they are all happy with the arrangement, so that we can secure stable funding for Rust maintenance for years to come.
If you would like to help us support more Rust maintainers, consider donating to RFMF!
When it’s Monday morning and you’re on the subway, in a coffee shop, or squeezing in a few email replies after your morning workout, your phone becomes your digital office. But every time you open your browser, you risk getting struck with any combination of distracting ads, auto-playing videos, and open tabs from the previous week competing for your attention.
For many remote and on-the-go workers, your mobile browser can become a minefield of interruptions and distractions, slowing you down when you need to focus most.
Luckily, there are multiple Firefox features that can help ensure your mobile browser is a focused, productive workspace.
Reduce distractions and clutter with Ad Blocker for Firefox on iOS
Opening a link shared via text or email can save time and keep things moving when a client or coworker needs a fast response. However, once it’s actually opened, there is a lot of opportunity for various pop-ups, overlays, and ads to get in between you and what you came in to do.
Because Firefox’s strong line-up of ad-blocking and privacy extensions on desktop and Android are not available in the same way on iOS, we built Ad Blocker for Firefox directly into the browser. To decide what gets blocked, Ad Blocker uses the EasyList filter and Apple’s WebKit Content Blocker technology. It won’t impact every ad or sponsored content on a new tab, as those presented directly by host sites and displayed in search results will still be visible.
To try Ad Blocker on iOS, go to Settings > Browsing > Ad Blocker and turn it on to enjoy a cleaner browsing experience.
Get the gist faster with Shake to Summarize
When you’re on a deadline, scanning through heavy text, ads, and filler content can turn a quick scan into an infinite scroll session.
Firefox’s Shake to Summarize feature helps people get the gist in seconds on both iOS and Android. To use it, simply shake your phone on any web page under 5,000 words, and a clean summary of the page’s content will instantly appear. It can also be activated by tapping the “Summarize Page” option under “More” in the three-dot menu.
Like all Firefox features, we built Shake to Summarize with your privacy and protection in mind. This means using device-specific technology to keep your data secure. You can learn more about the AI powering this feature here.
The feature launched on iOS last September, received a strong response from users, and earned a special mention in TIME’s Best Inventions of 2025. It is now available on iOS and Android in English, German, French, Spanish, Portuguese, Italian, and Japanese.
Keep your tabs tidy with Tab Groups on Android
Just like us, our smartphones tend to live multiple lives: work, personal, and everything in between. While it can be incredibly convenient to have everything you need for all parts of your life on one device, things can get cluttered fast.
One minute you are knee-deep in a client proposal and the next you’re flicking through the countless Google searches from over the weekend. “How old is Harry Styles?” and “Movie times near me” – while pertinent when you were off the clock 24 hours ago – have absolutely nothing to do with the work you are trying to get done now.
To help make sure your prep for Thursday’s client meeting doesn’t get lost in your pop music deep dive from the weekend, you can group related tabs in Firefox for Android. Each group can be labeled and assigned a color, appearing as a single, searchable card in the tab tray rather than separate tabs, so it’s easy to locate when needed. You can open, rename, recolor, and delete these cards whenever you want. To use Tab Groups on Android, simply drag one tab onto another, or select a few and tap “Add to group.” Label the group, choose a color, and you’re all set. To try it out, download the latest version of Firefox for Android. iOS support for this feature is on the way.
Pick up where you left off across devices with Firefox Sync
Sometimes we start a task on one device and finish it on another. Maybe you found an article on your computer that you want to read on the subway on your phone. Or, perhaps you want to pull out your laptop and finish filling out that lease application you started on your tablet.
Enable Firefox Sync and you can resume tasks you paused in your browser when switching across your mobile phone, tablet, and laptop. The feature lets you access your open tabs, bookmarks, and passwords across all the devices you access Firefox on.
The best part? We put your data privacy first. Firefox Sync uses end-to-end encryption so your synced data is encrypted before it reaches Mozilla’s servers.
To take your browsing experience with you wherever you go, connect your iOS or Android phone to your Mozilla account and start syncing with your other devices.
Take back control of your focus with Firefox
For remote and on-the-go workers, focus is everything.
With Firefox features like built-in ad blocking on iOS, Shake to Summarize for instant insights, and Tab Groups on Android to keep your work and personal digital spaces organized, you can transform your phone from a distraction hub into a productive workspace.
Download the latest version of Firefox for Android or Firefox for iOS today to test out any of the above features available on your device – and take back control of your attention.
The Rust Security Response Team was notified that Miri stores all environment variables to target/, allowing secrets to persist in caches.
While not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose secrets to PRs.
Overview
GitHub Actions makes it possible to cache directories between runs. Typical setups allow CI runs on main (and other branches) to write to cache, and PRs can only read from cache (preventing cache poisoning). Rust projects tend to speed up CI by caching binaries built by cargo install and sometimes the contents of target/.
PR CI can be triggered by anyone who can open PRs on your repository. GitHub requires maintainer approval for the first PR, but future PRs will rerun CI on every push. Anyone who has previously landed a change can trigger a CI run extracting information from cached target/ and then cover their tracks by pushing a second commit to the PR.
GitHub sometimes hides overwritten commits in its UI, making this kind of attack harder to detect. CI run logs and overwritten commits are also deleted after a few months.
When cargo miri is invoked, Miri needs to retain build-relevant environment variables between runs[1]. The current code to do so achieves this by storing all environment variables to target/. This, of course, persists when target/ is cached.
If your environment contained secrets, these can now be accessed by PRs via the cache.
Our fix
Our short term fix for this is to make Miri only preserve CARGO_* environment variables (excepting CARGO_*_TOKEN) and OUT_DIR. In the longer term, Miri and cargo may figure out better ways to inform Miri of the relevant list of environment variables. Note that this patch may not be available on nightly yet.
We also performed an ecosystem scan of GitHub repositories and identified 1 repository with this issue and 7 repositories that do not appear to be vulnerable but should be cautious anyway. We have reached out to those maintainers.
Am I affected?
It is likely that our scan was imperfect, so we recommend you check your own GitHub Actions setups if you run Miri.
The cache is accessible to PRs (common and often the intended use case)
Possible quick fixes include:
Disabling cache for that job.
Scoping secrets to steps in that job that do not call Miri.
Temporarily disabling Miri.
Once done, please clear the cache. Consider rotating any secrets that might have leaked.
The Miri release in the upcoming nightly (2026-09-22) will no longer have this problem.
Even if you do not run Miri, ensure jobs that can write to public caches do not have access to secrets. Many tools do not have special handling for secrets, and assume the entire environment can be written to the filesystem.
Threat model
We consider it bad practice to have a cache that can easily be tainted by secrets.
If caching target/, it is worth making sure that the inputs to processes that create target/ (anything invoking cargo) do not have secrets available. It is generally rare for standard cargo build/test subcommands to need any secrets or tokens[2], so this is mostly a matter of being careful about having secrets exposed as environment variables to the entire job.
Cargo/Miri/Rust does not guarantee that environment variables will be safe from being copied into target/. While we are treating this as a security issue and patching it out of an abundance of caution, this is not something you should rely on in general. Beyond official Rust tooling, it is possible for build scripts to be doing things that lead to the environment being stored in compilation artifacts.
Acknowledgements
Thanks to Predrag Gruevski of OpenAI for reporting this issue to us. Furthermore, the ecosystem scan was performed using Codex access and credits donated by OpenAI, which we also thank them for.
Issue triage and remediation was performed by Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone, and Mark Rousskov.
Miri is invoked multiple times by cargo miri for complicated reasons ↩
In theory it could come up with build scripts reading from the network ↩
Firefox DevTools MCP (firefox-devtools-mcp) 0.10.3 is out on npm.
New features:
New tool: close_firefox_session — ends the browser session: it releases the connection when the server is attached to an existing Firefox, and closes the browser when the server started it.
New parameter: fullPage for screenshot_page — captures the whole scrollable document instead of the viewport.
New parameter: downloadFolder for set_download_behavior — only used when setting the “allowed” behavior, it sets the folder where downloads should be stored and defaults to ~/.firefox-devtools-mcp/output/downloads.
Bug fixes:
No longer fails to find the Firefox binary on Linux with Flatpak.
restart_firefox now rejects when used against a server started with --connectExisting, whereas it used to restart the WebDriver session without restarting the browser and silently ignored all its configuration parameters.
Other changes:
Servers started with --connectExisting now disconnect after 30 minutes without any tool call.
restart_firefox is now part of the mozilla-internal package, and should only be used in controlled environments, as it allows the agent to restart the browser with a custom configuration. Instead, the new tool close_firefox_session can be used whenever clients do not need to update the browser configuration, and will have a more consistent behavior.
Path checks for the saveTo parameters have been improved to avoid overlapping with existing profile folders
Install:
claude mcp add firefox-devtools npx @mozillamozilla/firefox-devtools-mcp@latest
For internal Firefox development, swap firefox-devtools-mcp with firefox-devtools-mcp-moz in order to benefit from additional tools, such as chrome-privileged script execution.
Special thanks to all the contributors who filed issues and submitted patches for this release: f3tch (github), shoemoney and mightykatun.
Today at ALL IN, Canada’s largest AI and technology event, Mozilla and Mila announced a new initiative and fresh investment to build an open source AI foundation layer that enables organizations and institutions to own and operate advanced AI systems locally, ensuring full control over their technology and data.
Doubling down on its commitment to open source AI, the Government of Canada announced its support for the initiative. Mila will lead the technical delivery and coordination of the project, while Mozilla contributes technical expertise. It also provided the initial $5 million investment to kick off the project. Hypertec is committing an additional $1 million in first-year funding to accelerate initial Canadian deployments of the open source AI foundation layer on Hypertec hardware.
“Canada has a choice: depend on technologies developed elsewhere, or build more of what we need here at home,” said The Honourable Evan Solomon, Minister of Artificial Intelligence and Digital Innovation and Minister responsible for the Federal Economic Development Agency for Southern Ontario. “Open source AI gives Canadian businesses and institutions greater control over their technology and data, while making powerful tools more affordable, accessible, and easier to adapt. By supporting this work, we are strengthening Canada’s capacity to build and adopt AI on our own terms.”
Mila and Mozilla will lead the work together: Mila drawing on a world-class community of close to 2,000 researchers and professionals, Mozilla as technical partner from industry, bringing 25 years of experience stewarding open infrastructure others build on. Mila and Mozilla are actively engaging new partners, inviting companies, research institutions, funders, governments, and developers to join and support this work.
What’s being built
The goal is simple: make owning your AI as easy as renting it. Using open source models was never the hard part. Turning a raw open source model into something a small business, a hospital, a local charity, or a government can run in production — secure, reliable, plugged into everything else — takes an engineering team most organizations and institutions do not have and months they can’t spare.
The goal is to offer businesses and organizations a ready-to-use AI package that they can run privately and keep under their own control, rather than having to build a complex system themselves or rely entirely on expensive, pay-per-use proprietary AI services.
For example, a small manufacturer could use the system as a private AI assistant for its employees. It could search the company’s manuals, procedures, and past project files; help staff draft reports or answer technical questions; and help its software team write and improve code. Because the system is designed to be able to run locally, the company could do this while keeping its proprietary information and data within its own environment.
That also means lower costs. For the vast majority of everyday business tasks, companies will be able to use open source AI running on open source tools instead of paying a commercial provider every time an employee makes a request. But this requires reducing the technical work and expense involved in putting open source AI into practice.
This initiative was founded to solve that problem, building the free layer that makes owning open source AI easy — the same kind of layer the web was built on. It has two halves: An open standard, published as interface contracts, so any part of the stack can be swapped for a better one. And a working “reference implementation” any organization can install on its own machines or the ones it chooses, running the models and controls it chooses against its own data, with governance and access control built in from the start. The ambition is that with the standards and foundation in place, open source AI can be built anywhere, by anyone.
“Six months ago, we announced our partnership with Mozilla to advance open source and sovereign AI. Today, we are bringing that work to a whole new level,” said Valérie Pisano, President and CEO of Mila. “By delivering an open, secure AI foundation layer, we empower organizations, from small businesses to non-profits to governments, to own their technological future so they can run, control, and maintain AI models themselves. At Mila, our research community has always believed that for AI to be trustworthy and accessible, it must be built on open standards that keep control in local hands.”
The work already underway
Over the last six months, Mila and Mozilla have been designing the architecture, deciding which open source components belong at each layer, and testing that the whole system works end to end. This investment builds on that progress.
Working alongside Mila and Mozilla, Hypertec will help move the initiative from research and reference implementation to real-world adoption by Canadian businesses and institutions, providing a practical, private, and cost-effective path to deploy AI while maintaining greater control over their data and technology.
“AI is advancing at an extraordinary pace and has the potential to transform our economy and society for the better. Canada has an important role to play in ensuring that AI is developed and adopted responsibly, said Simon Ahdoot, CEO of Hypertec Group. “Hypertec is proud to help turn open source innovation into AI that Canadian organizations can deploy securely and under their own control. This is exactly the kind of partnership between government, research, and Canadian industry needed to realize the full potential of AI.”
Why now
Mozilla’s State of Open Source AI report found that while 79% of developers adding AI functionality use open models, only 53% of teams ever reach production, stopped by cost, security, integration, and maintenance. This work aims to change that.
“AI today is at a crossroads, where it could be closed and owned by a few, or open and available to every coder, developer, enterprise, and nation,” said Mark Surman, President of Mozilla. That’s what we’re building — an open source AI ecosystem that fits together as seamlessly as the web, and that anyone, anywhere can build on. We’re so grateful to Canada for scaling this work, and call on partners across sectors — from enterprises and governments to coders and startups — to join us in building this future.”
Within six months, Mozilla and Mila expect to publish working reference implementations for enterprise, government and public-interest use cases. The two-year ambition is bigger: to have solved this problem outright, so that open source AI can be adopted fully and easily, anywhere, by anyone.
We believe that there is an ongoing campaign targeting rust-lang members and
owners of popular crates that is attempting to compromise devices and accounts
in order to use them to publish malware.
What we've seen
A video call is set up for something positive — maybe for a job, maybe for a
project, maybe for a contract opportunity — and then that's used as a vector to
either get the target to install something on their computer (such as a
purportedly missing audio codec) or execute another command (for example, via
putting a command on the clipboard).
These attackers are setting up new but legitimate seeming company profiles,
including plausible LinkedIn presences, in order to pass cursory inspection.
Please take extra care in the near term. Be appropriately suspicious of cold
outreaches, and ensure that any calls you have with new people are on platforms
you trust — ideally, try to be the one who sets up the call on a platform you
already use.
Please also re-check that your accounts look normal: MFA enabled,
no unexpected logins on platforms that can track that, and so on.
If you have any concerns about your accounts, please reach out to
help@crates.io (for crates.io account concerns) and/or
security@rust-lang.org (for any other
concerns). We're very happy to help.
Bug 2069143 - When retrieving comments for a bug(s) via REST API, remove comments that would be collapsed in the web UI unless explicitly asking for them
Bug 2070247 - Support limiting who can needinfo the Hackbot account
Bug 2061445 - Migrate Bugzilla (system info) REST resource to native Mojo API
Bug 1877201 - Post to bug/{bugid}/comment returns wrong comment_id
Bug 2072224 - Update REST API authentication documentation to reflect per-resource migration to native Mojo auth
Bug 2060932 - Support GitHub-style <details>/<summary> collapsible sections in comments
Bug 2072689 - Buglist link on My Dashboard is broken
The AI race is shifting. Again. Practically overnight, competition has expanded from “which AI model is best?” to a new high-stakes battle over which models people can access, through which products, and whether people have meaningful choice about AI at all.
In response, Mozilla and Mistral today announced a partnership built on a shared idea: a new, open-source AI model alternative to Big Tech-default browser ecosystems. The intent: a model deliberately designed to keep the web open to technological diversity, competition, and choice.
And we’re putting this idea into practice in Firefox.
Mistral Small 4 is coming to Firefox Smart Window beta (learn more about Firefox Smart Window here), becoming a new AI model for Smart Window users in the US and Canada, while expanding Smart Window beta access and French-language support to Firefox users in France. Across all markets where Smart Window beta is available, Firefox users can still choose from a multitude of other AI models.
“AI is becoming part of how people experience the web every day. We want to make sure that doesn’t mean people are chained to one company’s self-serving pipeline. With the browser sitting at the heart of the web and online experience, it should be a place where different AI providers can compete and open source has a seat at the table.
This isn’t just a product partnership. A browser shouldn’t be a one-way funnel. It should preserve what made the internet powerful to begin with: the freedom to explore, discover different ideas and tech, and decide for ourselves where to go next,” said Anthony Enzor-DeMeo, CEO of Mozilla Corporation.
Choice and competition are worth protecting
As AI integration becomes increasingly concentrated, we are in jeopardy of a handful of closed-model companies controlling the browser, the search engine, the AI model, and the surrounding services that connect them. Mozilla and Mistral are betting that independent and interoperable models can offer an alternative to global tech monopolies controlling the next digital era.
“This partnership represents two open source advocates working together to bring Mistral’s scientific innovations to Mozilla’s consumers around the world. Together, we are bringing privacy, control, and choice to AI-powered web browsing,” said Arthur Mensch, Co-founder and CEO of Mistral.
Meaningful choice isn’t confined to personal preference for one AI model over another. Web products need to be able to work with different AI providers, and people deserve the option of switching without being locked into a single company’s ecosystem. When a tech layer as far-reaching and influential as AI is controlled by a small handful of players, it risks creating closed systems and closed doors, making it harder for new ideas and better technologies to grow, reach users, and compete on merits.
Mozilla and Mistral aim to keep that door open. The combination of an independent browser with a frontier European AI company gives people and institutions greater access to useful, responsible AI, the opposite of locking them into one company’s singular technology ecosystem.
Selecting Mistral, and expanding to France
Mozilla selected Mistral Small 4 after evaluating its performance for Smart Window Beta, including multilingual performance, an important part of the fit. The companies approached multilingual and multicultural tuning as a core model feature, rather than simply adapting an English-first experience for a new market.
For Firefox users, Mistral access starts with Smart Window Beta, a browsing experience designed to turn AI into a useful assistant for the things we do online: making sense of complex search trails, finding something valuable you clicked away from, presenting data sources, and generally picking up where day-to-day internet use got left off.
France is the first new market for Smart Window with official French-language support. Mozilla is planning additional European expansion later this year.
A different kind of AI competition
Our Mistral partnership puts an ambitious new AI model approach into practice: a multilingual, globally competitive European AI company reaching people through an independent browser, leveraging openness to create more room for new technologies to compete and succeed. Mistral can reach Firefox users without owning the browser, and Mozilla can integrate and recommend Mistral without removing user choice.
It is a natural extension of the principles that have shaped Firefox and the open web, and the kind of AI ecosystem we intend to continue building.
EDIT: Updated to reference gh correctly. Thanks flod!
Sometimes on Github, I need to fetch a patch from a fork I don't typically see everyday so I can try it out locally. I use the line at the top of the patch which has a copy button next to it because it's convenient.
The common steps for this are:
Click the contributor's branch and go to their github fork repository.
Copy the repository link.
Add a new git remote with an alias (typically their username).
git fetch <alias>
git checkout <alias>/<branch>
Here is a one-liner for it that you can add to your gitconfig:
You might ask, why do all of this when the github gh CLI does this for you?
While it does simplify some tasks, I wanted a solution that was independant to a specific git host. The git@github.com remote that is used in the alias can be changed or made configurable if desired. This is something that I wouldn't be able to do with platform-dependant gh.
The fetch also works well with jj too because the fetch and checkout remain headless.
Formatted and commented, it looks less intimidating:
f() { # Get the repository name from your checkout (assuming it is the # original directory name as the remote). PNAME=$(basename `git rev-parse --show-toplevel`); # Parse out the fork's owner. # Example: `<owner>:<branch>` OWNER=$(echo $1 | cut -d':' -f1); # Parse out the branch name. # Example: `<owner>:<branch>` BRANCH=$(echo $1 | cut -d':' -f2); # Do a fetch of that particular branch using the extracted # information from above. # This assumes the remote is hosted on github. git fetch git@github.com:$OWNER/$PNAME.git $BRANCH; # Checkout using the alias `FETCH_HEAD` which git provides. git checkout FETCH_HEAD;};# Execute the function!# It's easier to build a function that holds variables and execute# rather than in-line it.f
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/117279142568496801">the original post</a> on Mastodon.</p></noscript>
<noscript>You need JavaScript to view the comments.</noscript>
Last September, the Servo project announced that long-time maintainer Josh Bowman-Matthews (@jdm) would work part-time on improving the Servo contributor experience, entirely funded by the monthly donations on OpenCollective and GitHub.
In his own words, here is a look back over the past year!
First of all, I am enormously grateful to everyone who financially supports Servo, as those donations have enabled me to devote significant time to a project that I care a lot about.
Some highlights from that funded work that I’m proud of:
On top of that, I spent time diagnosing unexpected failures in others’ PRs and fixed numerous intermittent test failures that made merging PRs more difficult for everyone.
A few pieces of work from this period that stand out to me:
supporting a large scale rewrite of Servo’s JS engine integration to address intermittent panics related to garbage collection—I reviewed lots of pull requests, but also filed many issues that enabled the work addressing the panics to be spread across many other contributors
supporting another contributor’s grant proposal to work on Servo that was approved!
This role I’ve carved out means a lot to me—I’ve found a healthy balance that allows me to spend time with my family as well as make meaningful contributions to Servo, and I get to spend a lot of time looking for ways to make the project more accessible for others.
A big thank you to everybody supporting the project and my work; each individual monthly donation makes a big difference!
I’m excited to see what’s possible in the coming year.
This is the opposite of what I wanted to write about: relocating your MOZ_OBJDIR outside of your source directory will make your IDE faster.
In mozilla-central (the firefox monorepo), a default object files directory is created within the same source directory. This is equivalent to the build/ directory you would typically see in other projects.
While this is typically fine, I've found that Android Studio indexes many of these files and that can be slow when you're not working across all the layers in Gecko and Firefox. I ended up with these build directories that grew over time:
Directory
Last touched
Size
Files
obj-aarch64-unknown-linux-android
2025-11-04
29 G
113,116
objdir-desktop
2025-11-04
19 G
41,010
objdir-frontend
2026-09-09
6.3 G
66,930
obj-aarch64-apple-darwin24.5.0
2025-06-16
4 K
1
That's a lot to index! I figured a way around this problem is to move the OBJDIRs out of the source directory and into something like ~/.mozbuild:
While this does speed up IDE indexing, it's at the cost of developer experience, because now our generated code (e.g. FxNimbus) shows up as red symbols everywhere.
[insert sad trombone sound clip]
I'm uncertain if trimming what we index in these OBJDIRs is worth a large enough performance win, so for now I'll ensure I clean-up my stale copies which I'm not actively using.
P.S. Apologies for the delay in publishing this edition on the community blog. The original newsletter was sent to subscribers on August 27.
Firefox was leveling up in August! GeForce NOW arrived on Firefox for Windows, JPEG XL support was on the way, and the Firefox + NVIDIA teams joined forces for a Reddit AMA. We also invited SUMO and Mozilla Connect contributors to share their experiences through the Mozilla Contributor Survey, which has since closed (thank you to everyone who took the time to participate!).
Read on to catch up on what you may have missed and see what the community was up to!
GeForce NOW is now available on Firefox for Windows
Firefox has joined NVIDIA GeForce NOW’s supported browser lineup, making it possible to stream more than 2,000 PC games directly from Firefox on Windows. There are no downloads, installs, or hardware upgrades required! Just a Windows PC, a GeForce NOW account, and your existing game library.
Share your voice in the Mozilla Contributor Survey 2026
We’re gathering feedback from SUMO and Mozilla Connect contributors to help shape the future of Mozilla’s contributor community. The 2026 Contributor Survey explores what motivates you to contribute, what matters most throughout your contributor journey, and how we can improve areas such as onboarding, recognition, and the upcoming Mozilla Connect migration to SUMO. The survey takes about 10 minutes to complete and is now open until September 1, 2026, end of day UTC.
Firefox plans to ship support for JPEG XL, a modern image format designed to deliver high-quality images more efficiently. With progressive rendering, images can start appearing before they have fully downloaded so it helps make pages feel faster, especially on slower connections.
The Firefox and NVIDIA GeForce NOW teams are hosting a Reddit AMA on September 2 to celebrate GeForce NOW support on Firefox for Windows. Bring your questions about the integration, share your cloud-gaming setup, and let the teams know what else you’d love Firefox to support for online play.
Our goal for this phase of work is to remove the technical jargon, use plain language, and make it effortless for everyone to make informed decisions about their settings. With over 250 blocks of settings content to untangle, we aimed for incremental improvements rather than striving for perfection.
While our previous research leaned heavily on our technical power users, this round intentionally focused on new users to make sure Thunderbird is intuitive from day one.
Summary of research
The new copy tested well: We achieved >80% comprehension across our tested copy for Notifications, Appearance, and Composition settings.
High confidence levels: Users felt confident to change settings without external help (asking someone, referencing docs, or using AI for support).
Interactions need refinement: We found spots where the interface didn’t always match expectations, like using a checkbox instead of an on/off toggle.
Using our content guidelines, we audited all 250+ content blocks to check accuracy, what was overly technical, and if anything was outdated. Our strategy was built up into steps to make it more achievable.
Step 1: Research & prioritization
User journey mapping, insights from research and user needs
Last month, we conducted research where we used a card sorting method to understand what users actually care about most and where they expect settings to live. Catch up on the Research Summary.
Step 2: Inventory audit
Content inventory with Thunderbird on the left and the content table on the right.
We mapped every piece of text in the app to build a full content inventory, assessing each piece of text for accuracy, freshness, and 8th-grade readability.
Step 3: Content redesign
Example of how we updated the notifications content
We removed any developer or system updates from the interface and replaced it with language that speaks to what the setting actually does for the user.
Our findings
We tested prototypes for Notifications, Appearance, and Composition and asked 4 questions to test the purpose of each setting category, scenario comprehension, and user confidence. Our target threshold was 80% comprehension.
Lyssna prototype displaying Appearance settings and question
Here is how the new copy tested with room for improvement around the interactions, visuals, and how the language can be even more clear and user friendly.
Settings Category
Purpose Comprehension
Scenario Accuracy
Confidence Score (out of 5)
Notifications
86%
71%
4.00
Appearance
86%
86%
4.14
Composition
100%
100%
4.43
What’s next
Improve the interactions: Aligning component types with immediate vs. batch actions so the UI behaves the way people expect.
Sharper indicators: Testers liked the visual diagrams for Threaded, Unthreaded, and Grouped messages, but they need a bit more detail to make the visual distinction instant.
Continue iterating on copy: Cleaning up remaining awkward phrasing (like Autosave 5 seconds) that still makes the experience feel slightly dated.
Next, we are taking everything we learned from this copy testing and applying it to the overall settings navigation and layout structure.
Redesigning settings isn’t always glamorous, which is why our team internally nicknamed this effort “Project Toto” inspired by high-tech Japanese toilets. Settings are something most people prefer not to think about, but when they are designed thoughtfully, the experience becomes seamless, intuitive, and surprisingly delightful.
As our new designs take shape, we’ll be reaching back out to both new and long-time users for feedback. Stay tuned for our next update, and let us know your thoughts in the comments!
One of the biggest challenges Rust developers report in our
annual surveys is a subpar debugging experience. So, back
in February, we ran our first Rust Debugging Survey,
in the hopes of identifying how Rust developers are using debuggers and what
problems they are facing when doing so. We received over 2,300 responses, and
we'd like to thank everyone who took the time to participate in the survey!
In this report, we'll go over some of the results of the survey. If you'd like,
you can also check out the complete results of the survey.
If you'd like to skip ahead to any particular section, you can do so with this
index:
The first step to making sense of the survey results is understanding who took
the survey. We asked respondents to rate their Rust expertise, from "Never used
it" to "Advanced". Over 80% reported themselves as "Advanced" or "Intermediate",
split roughly evenly between the two:
We also asked respondents if they currently use or have used debuggers in Rust.
Over 46% said they currently do, with the remaining responses split between
"have in the past" and "never have". That means that over half of respondents do
not currently use a debugger for Rust!
Categorized by expertise, the responses reveal that roughly half of "beginners"
have never used debuggers in Rust! On the other hand, nearly half of "advanced
users" currently do use debuggers in Rust:
For respondents who indicated they had previously used Rust but no longer did,
we asked if challenges with debugging support were why they stopped. For nearly
3%, the answer was "yes", with an additional 24% reporting debugging issues as
being partially responsible (though mind the small response count; most
respondents were active users of Rust):
Knowing what debuggers developers are using and how is another important part of
understanding the challenges they face. To this end, we asked respondents how
they were debugging their programs. Unsurprisingly, most developers make use of
print debugging and the dbg! macro. Excluding those, using lldb inside an
IDE was the most popular choice, followed by gdb on the command line:
We can get a more detailed breakdown of these results if we include the
operating system on which the respondents use a given debugging approach. We
examine this from two different angles. The first angle being, "On operating
system X, what percent of responses are using debugger Y?". Print debugging and
the dbg! macro are consistently the top two yet again, but looking beyond
that, things get more interesting. On Linux, using gdb on the command line was
the most popular choice by a thin margin, beating lldb in an IDE by only 0.4%.
On Windows, Windows Subsystem for Linux (WSL), and macOS, lldb in an IDE was
the top pick by at least 6%, making it a very popular choice in general. On
Windows, the three least popular choices were the command line debuggers (gdb
CLI, lldb CLI, and BugStalker), and on both Windows and macOS the third most
popular pick was, "I don't know". Those who were debugging on operating systems
not listed (Other) most frequently used some kind of special embedded debugger
or gdb:
The other angle we can look at these responses from is, "For users of debugger
X, what percent of responses are using it on operating system Y?". For most
debuggers, Linux makes up the largest portion of uses, ranging from about 45% to
about 77%, followed by Windows, then macOS. The most notable exceptions are
WinDbg and the Visual Studio debugger, which are primarily used on Windows, and
lldb, which is used more on macOS than Windows in an IDE and on the command
line:
To the 6 respondents who use WinDbg on Linux: we wish you luck!
As for how people actually use their debugger of choice, the aggregate results
are not particularly surprising. Roughly 87% of users are using debuggers for
stepping line-by-line through programs and a little over half of users are using
debuggers to obtain stack traces from hung/crashed processes. Only a quarter of
the respondents use a debugger to debug async code. That might be partially
caused by the async Rust debugging experience being clumsy and incomplete, or it
could just be that users aren't writing much async code:
If we break these results down by expertise, we can learn a bit more about usage
patterns. As users become more experienced with Rust, their use of debuggers for
learning purposes decreases, and they get more stack traces from crashed
processes:
The final bit of insight into how Rustaceans use debuggers is if they are
debugging programs that use Rust alongside other programming languages. For 44%
of respondents, the answer is "yes", which is a pretty high number!
As for which languages those are, C dominates the scene at a little over 70%,
followed by C++ at about 43% and Python at about 20%:
Instead of diving right into asking, "what problems do you face when using
debuggers?", or something to that effect, we first asked respondents why they
decide against using debuggers whenever they do, including for reasons that
aren't necessarily "problems with debuggers".
The most commonly reported reason was that it was easier or faster to use logs
or print debugging to solve problems, reported by a little over 81% of
respondents. This could partially be explained by the open responses, which
featured complaints that debuggers were too difficult to set up and/or use
(especially on Windows, when dealing with Web Assembly, or in embedded
contexts) and sentiment suggesting that small and/or simple problems just don't
really need a debugger. It does leave one wondering if the user experience could
be made convenient enough to dethrone print debugging, but it seems hard to beat
something so intuitive. This is followed by roughly 37% of respondents who write
code that Just Works. Fair enough. After that, about 26% of respondents
indicated that they've decided not to use debuggers in situations where the
language features they were working with had poor support. This is slightly more
than issues with standard library types, at about 22%, which is slightly more
than issues with external library types, at about 20%:
As stepping through code was anticipated to be one of the most common uses for
debuggers, we directly asked respondents if they faced any issues when doing so.
A little over 51% of respondents said they did! Of those who reported that they
experienced issues stepping through code, we asked when they were experiencing
issues. Async code was the most common case reported at slightly over 28%,
followed by code involving macros at about 23%. The least common case reported
was code involving function pointers, at almost 6%:
We also directly asked respondents which types in the standard library were hard
to work with, if any. This was an open-response question, and reading through
the responses, some particularly common complaints were with enums and
collections, particularly std::collections::HashMap and std::vec::Vec. This
is also visible in the word cloud in the full report.
We asked respondents to indicate which pain points, if any, they have
encountered when using debuggers with Rust. At slightly over 74%, poor
representation of values was the most common pain point by a decent margin,
followed by being unable to print variables at just over 55%:
We asked respondents to indicate if they were library authors, and if so, if
they were aware of and using the debugger_visualizer attribute. Nearly 62% of
respondents indicated that they were library authors who were not aware of this
attribute:
For those who indicated that they were library authors who knew about the
attribute but did not use it, we also asked why. This represented a much smaller
fraction of respondents, so keep that in mind! That said, half of these library
authors indicated that they didn't have the time to maintain visualizer
attributes, and just under half indicated they didn't know how to write
visualizer scripts:
For those of you who have been reading this section asking yourself what the
debugger_visualizer attribute is, you can read up on it in
The Rust Reference: Debugger Attributes. The quick
explanation is that the debugger_visualizer attribute can be applied to
modules or the crate root to embed files in the debug information which improve
the display of values with certain debuggers. The two currently supported file
types are Natvis files, used by Microsoft debuggers such as WinDbg, and GDB
"pretty printers", which are structured Python scripts used by GDB.
Closing Remarks
Thanks to your participation in this survey, we've gained some great insights
about how Rustaceans are using debuggers and what issues they are facing. For
example, knowing that such a high number of users are dealing with poor
representation of values pairs well with knowing which standard library types
are causing issues, knowing that many library authors haven't heard of the
debugger_visualizer attribute, and knowing that many of those who have but
don't use it either don't know how or don't have time to maintain visualizer
scripts.
Looking to the future, the survey results have suggested that there are a few
notable ways we could most significantly improve the debugging experience in
Rust, such as:
Fixing the way enums are represented by debuggers so they show actual
variants
Fixing the way collections (such as HashMap) are represented by debuggers so
they show their contents, rather than their implementation details
Fixing the way string types (such as String and CString) are represented
by debuggers so they render as text, rather than their implementation details
Improving the async debugging experience, particularly with stack traces
Improving stepping through certain state machines (such as iterators and
Futures)
Providing documentation on basic set up and use of some common debuggers
A common suggestion that could resolve those first three points is to use the
Debug implementation of types to display them in debuggers. There are
challenges to that approach, such as the fact that the Debug implementation is
not present in the final binary unless it is actually used somewhere in the
program, but it isn't impossible. Notably, this is already supported by the
BugStalker debugger (given the same condition that the Debug
implementation must actually be used), which some of you first heard about from
the survey! It also appears to have some support for async, with plans to
expand.
One notable way the debugger experience is currently being improved is through
the ongoing Google Summer of Code project improving how we test debug info and
visualizer scripts, making it easier to maintain and improve our own visualizer
scripts and general compatibility with visualizer scripts without silent
breakage or regressions.
Once again, we'd like to thank everyone who took the time to participate in the
survey!
Firefox DevTools MCP (firefox-devtools-mcp) 0.10.2 is out on npm.
New tools:
press_key — sends a single key, optionally with modifiers, to a snapshot element or the focused element (Return, Escape, Tab, arrows, ctrl+shift+t, …).
type_text — types text key by key into the focused element, with an optional key to press afterwards.
set_network_cache — bypass or restore the HTTP cache, for the selected tab or browser-wide. Useful before a performance measurement or when verifying a change a cached asset would otherwise hide.
Other changes:
navigate_page and new_page take an optional wait argument (none, interactive, complete), so an agent can wait for the load event before deciding a page is done.
Windows: per-user Firefox installs are now detected, instead of failing with “unable to find binary in default location”.
aarch64 Linux: geckodriver is now resolved on all platforms, fixing “Unable to obtain browser driver” when a native geckodriver is on PATH.
Several Windows path fixes for --output-file, --log-file and saveTo.
For internal Firefox development, swap firefox-devtools-mcp with firefox-devtools-mcp-moz in order to benefit from additional tools, such as chrome-privileged script execution.
Collected here are the most recent blog posts from all over the Mozilla community.
The content here is unfiltered and uncensored, and represents the views of individual community members.
Individual posts are owned by their authors -- see original source for licensing information.
Sync: l10n → main (October 13, 2026) (
Survey link
Ingredients
Instructions
Tips
Nutrition
