Bugs resolved in Moz-Phab 2.22.1:
- bug 2078299 Allow overriding base url and repo call sign for development purposes
Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.22.1:
Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.22.0:
Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
Niko Matsakis
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.
This is a kind of “blog post companion version” of a talk I gave this week at REBASE, part of SPLASH. You might also enjoy the slides from the talk I gave at IWACO, IWACO and Rust: hidden links revealed, which was a bit more of a retrospective (no soundtrack for those, though). In any case, this turned out to be a great conference! Jack Huey presented on the Rust Vision Doc and, quite to my surprise, Steve Klabnik and Dorian Scheidt presented “LLMs as Collaborators in Language Specification and Design”, talking about their process in building out Rue. It was fun to see Steve again. On top of that, there was a ton of great research presented at IWACO in particular. I was particularly taken by the work on Reachability Types and Information Borrowing. I also really liked learning about Hylo Lang, particularly their approach to projections. Clever and cool.
Rust is popular right now. Very popular:
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.
It seems to me that an effective “software factory” will have three pillars:
None of these pillars are solved, but some have made more progress than others.
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:
flowchart LR
Code -- Benchmark --> Profile
Profile -- Analyzed by --> Agent
Agent -- Propose --> PR
PR -- Improve --> Code
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
— Greg Brockman (@gdb) January 2, 2026
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 can show the presence of bugs, but not their absence.
— Edsger W. Dijkstra, 1970
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 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.
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.
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:
voidsetFoo(Barbar){this.foo=bar;assertthis.foo==bar;}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):
fn set_foo(&mutself,bar: Bar){self.foo=bar;assert_eq!(self.foo,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.
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.
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 unsafe keyword. 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
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.
We covered a lot of ground here, so let me put this all together. What makes Rust a good choice for developing with agents?
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:
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. ↩︎
The revenge of .h files? ↩︎
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
event.changes has a single flag.needinfo entry for the last requestee only; the others are dropped.Discuss these changes in the BMO Matrix Room
1 post - 1 participant
Firefox Developer Experience
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.
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:
WebDriver code is written in JavaScript, Python, and Rust, so any web developer can contribute! Read how to set up the work environment and check the list of mentored issues for Marionette or the list of mentored JavaScript bugs for WebDriver BiDi. Join our chatroom if you need any help to get started!
A complete list of developer-facing changes included in this Firefox release is available in the MDN Firefox 158 Release Notes.
Firefox Tooling Announcements
The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed:
Highlights:
Other Changes:
Big thanks to our amazing localizers for making this release possible:
Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel!
1 post - 1 participant
The Mozilla Blog
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 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?
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.”
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.
Learn more about Firefox Enterprise.
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.
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.
The post Mozilla introduces Firefox Enterprise appeared first on The Mozilla Blog.
Niko Matsakis
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.
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:
fn is_copy<T: Copy>(){}fn is_magic<T: Magic>(){// Legal, because `T: Magic` implies `T: Copy`
is_copy::<T>();}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?
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.
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:
fn string_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:
fn string_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.
An easy way to understand the idea of modular checks is to think of functions. Imagine you have a function like this one:
fn compute_sum(a: i32,b: i32)-> i32 {format!("{a} + {b}")// <-- Error
}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:
fn use_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.
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 existsand 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.
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) and Shallow(String: Copy):2
Shallow(String: Magic)
Shallow(String: Copy)
---------------------------- Magic fully implemented
String: Magic
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:
fn string_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.
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.
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
fn foo<T: NullWord>()-> T{std::mem::transmute(0_usize)}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?
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. ↩︎
Firefox Tooling Announcements
New release of Firefox DevTools MCP. Available on npm at https://www.npmjs.com/package/@mozilla/firefox-devtools-mcp
set_firefox_prefs and get_firefox_prefs work again. They now use WebDriver BiDi to run in the privileged contextlist_pages no longer fails when the URL or title of a tab cannot be read. That tab is listed with (unknown) values insteadtake_snapshot and the UID-based input tools now use WebDriver BiDi instead of WebDriver Classicplugin.json and mcp.json files from the Agent Plugins 1.0 standard, which cursor.directory readsFull changelog: Release v0.10.5 · mozilla/firefox-devtools-mcp · GitHub
Repository and issues: GitHub - mozilla/firefox-devtools-mcp: Model Context Protocol server for Firefox DevTools - enables AI assistants to inspect and control Firefox browser through WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org
1 post - 1 participant
Mozilla Open Policy & Advocacy Blog
Encryption is woven into everyday digital life. It protects our messages and passwords, but also banking and payments, health data, government services and the digital infrastructure societies rely on every day. Yet across jurisdictions, governments are increasingly considering laws that expand lawful access to data for law enforcement and national security purposes. In practice, this can mean requiring companies to create new ways to access encrypted data, introduce technical capabilities that bypass existing protections, or make otherwise secure systems insecure. These measures can weaken the very security encryption is designed to provide, with consequences for cybersecurity, privacy, fundamental rights and the wider economy. Canada’s Bill C-22 is the latest example of this trend, raising serious concerns about the security and privacy consequences of expanding government access to data.
For Mozilla, protecting that security is fundamental to both the products we build and the principles we advocate for. One of the foundational principles that guide Mozilla’s mission and work holds that individuals’ security and privacy on the internet are fundamental and must not be treated as optional. Protecting people’s privacy and security is not an aspiration for us, but shapes the products we build every day: Firefox blocks trackers, protects you from profiling via cookies and fingerprinting, comes with malware protection and a built-in VPN, offers HTTPs-only mode and protects your passwords and credit card information by encrypting them.
Some of these protections are being threatened by Canada’s Lawful Access Act, also known as bill C-22. Part two of the bill, the “Supporting Authorized Access to Information Act” (SAAIA) would introduce sweeping new powers to require electronic service providers to build and maintain capabilities that facilitate government access to information. If passed in its current form, companies could be asked to introduce vulnerabilities, build backdoors, bypass, weaken or otherwise defeat encryption, access data before encryption or decrypt encrypted data to provide access to law enforcement. Service providers could also be compelled to retain and access data they have purposefully chosen not to collect.
Let us be clear: there is no safe way to create exceptional access to encrypted data that only the intended actor can use. An access mechanism created for law enforcement can also be discovered, exploited or abused by potentially bad actors.
Such vulnerabilities and backdoors do not only undermine people’s fundamental rights to privacy and data protection, but also the trust and security premises societies everywhere depend on. The same encryption that protects a private conversation also protects financial transactions, sensitive health information, business systems and critical digital services.
Expanding capabilities of AI systems are only exacerbating these risks – governments should encourage the disclosure and patching of vulnerabilities, not compel companies to introduce insecurities deliberately. Only trustworthy and transparently governed digital infrastructures can be the basis for digitally sovereign societies.
We are also concerned by C-22’s scope, which does not stop at Canadian services or users. C-22 expansive surveillance capabilities and data retention obligations would undermine people’s privacy and security everywhere, and the bill’s confidentiality requirements would make it impossible for services to inform their users about security breaches or backdoors introduced.
Guided by our Surveillance Principles for a Secure, Trusted Internet, we call on Canadian policymakers not to rush the legislative process to take experts’ feedback into account in amending C-22 to protect everyone’s security and privacy. Canada’s interests are best served by regulation that protects encryption, strengthens cybersecurity and emphasizes transparency, checks and balances.
The post Canada’s bill C-22 threatens encryption, users’ privacy and the security of digital economies appeared first on Open Policy & Advocacy.
The Mozilla Blog
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.
The post Firefox partners with Anschutz Entertainment Group at the Uber Arena and Uber Eats Music Hall in Berlin appeared first on The Mozilla Blog.
The Mozilla Blog
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.
The post Jambu Palaniappan and David Parry-Jones join the Mozilla Corporation Board of Directors appeared first on The Mozilla Blog.
The Mozilla Blog
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 has many examples 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:
And people in the EEA also deserve better:
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:
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.
The post 100 days later: Microsoft still steers Windows and Copilot users to Edge, everywhere the law lets it appeared first on The Mozilla Blog.
This Week In Rust
Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.
Want TWIR in your inbox? Subscribe here.
&This week's crate is karatepe, a statically typed localisation language and library.
Thanks to miro for the self-suggestion!
Please submit your suggestions and votes for next week!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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!
653 pull requests were merged in the last week
SpanData cachemul_add_relaxed methods for floating-point typesstd::fs::{Home|Media}DirsRc::is_uniqueCStr::displaydebug_closure_helpers-Zmem-statsconfig: Proper dotted tuple support with legacy fallbacklint: Making the lint name a terminal hyperlink to docstrim-paths: stabilize profile.trim-pathsrustc_allow_incoherent_impl on primitive methodsenum variants with "jump to def"Deref items are handleditems: format comments after where using clause_shape budgetadjust_max_widthmanual_range_patterns: support char and byte literallet_unit_value bail out if initializer is cfg-dependentneedless_borrowed_reference to lint mutable ref patternshas_non_owning_mutable_access_inneritems_after_test_module: don't let derive expansions hide trailing itemsunnecessary_as_sliceunicode-ident, take 2opaques_with_sub_unified_hidden_type for the next-sol…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.
Triage done by @JonathanBrouwer. Revision range: c1070d69..cc9a14f7
Summary:
| (instructions:u) | mean | range | count |
|---|---|---|---|
| Regressions ❌ (primary) |
0.6% | [0.4%, 1.0%] | 12 |
| Regressions ❌ (secondary) |
0.4% | [0.1%, 0.9%] | 26 |
| Improvements ✅ (primary) |
-1.1% | [-6.2%, -0.2%] | 212 |
| Improvements ✅ (secondary) |
-1.9% | [-15.7%, -0.1%] | 208 |
| All ❌✅ (primary) | -1.0% | [-6.2%, 1.0%] | 224 |
4 Regressions, 3 Improvements, 1 Mixed; 5 of them in rollups 33 artifact comparisons made in total
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported.wide-arithmetic featureVaArgSafeptr::try_cast_alignedhir::Params from Body of functions to FnDecl.No Items entered Final Comment Period this week for Rust RFCs, Cargo, Language Team, Leadership Council or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.
required-targets for workspace package selectionglobal_asmCopy closure capturesThis 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.
Rusty Events between 2026-10-07 - 2026-11-04 🦀
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.
Please see the latest Who's Hiring thread on r/rust
There ain't no rules here in Quote of the Week - it's survival of the wittest
Thanks to Jonas Fassbender for the suggestion!
Please submit quotes and vote for next week!
This Week in Rust is edited by:
Email list hosting is sponsored by The Rust Foundation
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
Discuss these changes in the BMO Matrix Room
1 post - 1 participant
The Mozilla Blog
Every October, Cybersecurity Awareness Month reminds us the importance of protecting our digital lives.
The theme for 2026 is ‘Don’t Make It Easy for Them,’ with the National Cybersecurity Alliance (NCA) and the Cybersecurity and Infrastructure Security Agency (CISA) providing simple, actionable steps users can take to make it harder for cybercriminals to attack.
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.
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.
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.
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.
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.
The post Strengthen your online security for free with Firefox appeared first on The Mozilla Blog.
Ryan Hunt
WebAssembly stack switching in SpiderMonkey is the most complex feature I’ve ever implemented.
It’s one of those projects where you get lost and start rethinking the basics, like “what is the stack even really?”
It was fun to give a talk on it. Check out the recording below, or on YouTube.
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Firefox Developer Experience
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.
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:
WebDriver code is written in JavaScript, Python, and Rust, so any web developer can contribute! Read how to set up the work environment and check the list of mentored issues for Marionette or the list of mentored JavaScript bugs for WebDriver BiDi. Join our chatroom if you need any help to get started!
A complete list of developer-facing changes included in this Firefox release is available in the MDN Firefox 157 Release Notes.
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
The Rust Programming Language Blog
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.
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.
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.
Mozilla Data YouTube Channel
Thunderbird Blog
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.
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.
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.
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.
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.
The post Thunderbird for iOS: A First Look at the Native iPhone Email App in Development appeared first on The Thunderbird Blog.
Mozilla Data YouTube Channel
The Mozilla Blog
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.
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.
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.
Bold critical details (numbers, warnings, key terms).
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.
For example, when asked to summarize a lentil soup recipe the model returned:
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.
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
Instructions
Tips
Nutrition
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.
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 post Under the Hood: Prompt tuning Shake to Summarize for recipes appeared first on The Mozilla Blog.
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
The Rust Programming Language Blog
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:
$ rustup update stable
If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.99.0.
If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!
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.
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.
This is done by stabilizing three functions:
Box::leakWhile 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.
IntoIterator for Box<[T; N]>IntoIterator for &Box<[T; N]>IntoIterator for &mut Box<[T; N]>VecDeque::retain_backcore::ffi::VaListBox::into_non_nullBox::from_non_nullVec::into_partsVec::from_partscore::mem::size_of_val_rawcore::mem::align_of_val_rawcore::alloc::Layout::for_value_rawString::from_utf8_lossy_ownedstring::FromUtf8Error::into_utf8_lossyFusedIterator for StepBy<I>std::fs::set_timesstd::fs::set_times_nofollowCheck out everything that changed in Rust, Cargo, and Clippy.
Many people came together to create Rust 1.99.0. We couldn't have done it without all of you. Thanks!
About:Community
Hi Mozillian,
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 partner to expand AI choice
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.
Does open source need IRL? The case for MozFest
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!
MozFest call for Volunteers
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.
From the Reddit Community
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!
P.S.
Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.
This Week In Rust
Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.
Want TWIR in your inbox? Subscribe here.
This week's crate is ying-profiler, a native Rust sampling memory profiler.
Thanks to Evan Chan for the self-suggestion!
Please submit your suggestions and votes for next week!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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.
mw argumentsmw --help outputScoreBounds::dimension_scores docs still list estimated key counts as unboundedfinished event under-counts rows when a row cap stops the incremental engineIf 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!
546 pull requests were merged in the last week
crate_hash from metadata encoding instead of HIR (implements #94878)k#)Div and Mul for Complex<{float}>AllocatorNonZero conversions'static) lifetimes in thread_local!PartialEq<VecDeque<U>> for Vec<T>, &[T], &mut [T], [T; N], &[T; N] and &mut [T; N]Box::takeResult::into_{ok,err}funnel_shifts (including const)mem::conjure_zstvec_try_removefrom_str_radixbuiltin-deps: add builtin dependencies manifest syntaxconfig: add build.profile, install.profilemetadata: mirror package features in features_v2builtin-deps: fix builtin dependencies manifest validationdiag: Don't report unused normal deps when static libs are skippedpackage: preserve feature metadata in normalized manifestsdoc(hidden) with --generate-link-to-definition#[rustc_allow_incoherent_impl] is involvedwhile_let_loop: detect the pattern when the loop has a labeltry_from_instead_of_from_str lintBox::leak in nonnull_unchecked_on_box_ptrcollapsible_match consuming/mutation checkingmatch_str_case matching str inside or patternstype_match relevance for type-aliasenumenumThis 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.
Triage done by @panstromek. Revision range: 3670d253..c1070d69
Summary:
| (instructions:u) | mean | range | count |
|---|---|---|---|
| Regressions ❌ (primary) |
0.6% | [0.2%, 0.8%] | 8 |
| Regressions ❌ (secondary) |
1.4% | [0.1%, 5.8%] | 30 |
| Improvements ✅ (primary) |
-0.6% | [-1.7%, -0.2%] | 192 |
| Improvements ✅ (secondary) |
-1.5% | [-82.5%, -0.1%] | 101 |
| All ❌✅ (primary) | -0.6% | [-1.7%, 0.8%] | 200 |
0 Regressions, 2 Improvements, 6 Mixed; 3 of them in rollups 26 artifact comparisons made in total
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
ptr::try_cast_alignedrustc_allowed_through_unstable_modules itemsVisibleForLeakCheck in RegionOutlives fast pathdebug_closure_helpers#[panic_handler] on unsafe fn.optimize attribute#[inline(always)] + #[target_feature(enable = "....")] #2CStr::display(use<…>)+)No Items entered Final Comment Period this week for Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.
Rusty Events between 2026-09-30 - 2026-10-28 🦀
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.
Please see the latest Who's Hiring thread on r/rust
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.
Thanks to MusicalNinjaDad for the suggestion!
Please submit quotes and vote for next week!
This Week in Rust is edited by:
Email list hosting is sponsored by The Rust Foundation
Mozilla Addons Blog
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.
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 |
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 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.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 |
The theme manifest reference on MDN is being updated with these changes.
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:
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.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.
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.
Install your theme in Firefox 157 and look at it in each of these states:
Then, if something looks off:
tab_selected and tab_line so the selected tab stands out without Firefox’s old shadow.sidebar and sidebar_text to colors that match your theme.button_background_hover and button_background_active colors.backgrounds_area and set a toolbar color.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:
popup_icons color for icons in menus and panels, separate from toolbar icons.We will post again when these land.
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.
Resources
backgrounds_area.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.
The post Nova is here: what changes for your Firefox theme appeared first on Mozilla Add-ons Community Blog.
The Mozilla Blog
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.
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.
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.
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.
The post More modern. More flexible. Still Firefox. appeared first on The Mozilla Blog.
Firefox Nightly
browser.newtabpage.activity-stream.newtabWallpapers.customWallpaper.library.enabled to true, starting in Firefox 157.
Script to find new contributors from bug list
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.21.0:
moz-phab submit could load reviewers and review groups in parallel with revisions and diffsmoz-phab submit should display the revisionDiscuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
The Mozilla Blog
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 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.
What makes it Classic:
When to use it:
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 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:
When to use it:
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 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:
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.
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.
To try Smart Window, visit https://www.firefox.com/smart-window. Or, if it’s not available in your region yet, you can sign up to be notified when it is.
The post Classic, Private, or Smart? Choose the right Firefox window for every task appeared first on The Mozilla Blog.
Thunderbird Blog
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!?
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.
Keep track of our Graph API Calendar implementation here.
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
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.
Follow the Calendar Event Create/Edit work here
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.
Read more about that journey here
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:
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:
Thunderbird Enterprise Policies and Relevant Preferences
Thunderbird Enterprise PoC Work Items
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:
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.
Toby Pilling
Senior Manager, Desktop Engineering
The post Thunderbird Monthly Development Digest: September 2026 appeared first on The Thunderbird Blog.
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.20.0:
moz-phab submit is getting the file size from hg/git even if it could infer it from the blob itselfDiscuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
This Week In Rust
Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.
Want TWIR in your inbox? Subscribe here.
This week's crate is fastlogging-rs, a fast logger which supports 8 different programming languages.
Thanks to brmmm3 for the self-suggestion!
Please submit your suggestions and votes for next week!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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!
618 pull requests were merged in the last week
tainted_by_error in LateLintrustc_builtin_macrosDir::try_cloneCommandExt::show_windowfeature(trim_prefix_suffix) ({str,[T], Path}::trim_prefix and {str, [T]}::trim_suffix)windows_process_extensions_main_thread_handlebuild-rs: make unstable compilebuild.warnings='deny'dyn trait methods linking for jump to def featuremust_use_without_reason lintconst_trait_impl related infinite loop in needless_borrows_for_generic_argsextend_with_drain to VecDeque and BinaryHeapsuboptimal_flops for mul_add, custom_abs and radians in const contextformat_args! for uninlined argscfg!()Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
repr(C) ZSTs from others in ABI compatibility ruleswide-arithmetic featurethread_local!mem::conjure_zstCommandExt::exec and opt to use execve and resolve path manuallydebug_closure_helpersfunnel_shifts (including const)Result::into_{ok,err}trusted-contributors marker teamNo Items entered Final Comment Period this week for Rust RFCs, Language Team, Language Reference or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.
Rusty Events between 2026-09-23 - 2026-10-21 🦀
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.
Please see the latest Who's Hiring thread on r/rust
operational pedantics
Thanks to Jules Bertholet for the suggestion!
Please submit quotes and vote for next week!
This Week in Rust is edited by:
Email list hosting is sponsored by The Rust Foundation
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
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.
Discuss these changes in the BMO Matrix Room
1 post - 1 participant
Firefox Tooling Announcements
The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed:
Highlights:
--with-samply to “profiler-cli load” (#6339)Other Changes:
Big thanks to our amazing localizers for making this release possible:
Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel!
1 post - 1 participant
Firefox Tooling Announcements
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.
Full changelog: Release v0.10.4 · mozilla/firefox-devtools-mcp · GitHub
Repository and issues: GitHub - mozilla/firefox-devtools-mcp: Model Context Protocol server for Firefox DevTools - enables AI assistants to inspect and control Firefox browser through WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org
1 post - 1 participant
The Rust Programming Language Blog
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.
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.
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.
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!
The Mozilla Blog
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.
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.
Ad Blocker for Firefox on iOS was built to reduce distractions and screen clutter while you browse, so you can stay focused on the task at hand. It’s a built-in, optional feature that blocks many intrusive ad formats, third-party ad networks, and ad-related trackers. That means no separate extension required, and you decide if and when to use it.
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.
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.
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.
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.
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 post Stay focused wherever you work with Firefox mobile browsers appeared first on The Mozilla Blog.
The Rust Programming Language Blog
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.
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 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.
It is likely that our scan was imperfect, so we recommend you check your own GitHub Actions setups if you run Miri.
You are vulnerable if:
cargo miri in CIcargo miri has access to secrets as an environment variable:
env for the workflowtarget directory, usually done via actions/cache or swatinem/rust-cachePossible quick fixes include:
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.
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.
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.
Firefox Tooling Announcements
Firefox DevTools MCP (firefox-devtools-mcp) 0.10.3 is out on npm.
New features:
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.fullPage for screenshot_page — captures the whole scrollable document instead of the viewport.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:
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:
--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.saveTo parameters have been improved to avoid overlapping with existing profile foldersInstall:
claude mcp add firefox-devtools npx @mozillamozilla/firefox-devtools-mcp@latest
codex mcp add firefox-devtools – npx @mozilla/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.
Full changelog: Release v0.10.3 · mozilla/firefox-devtools-mcp · GitHub
Repository and issues: GitHub - mozilla/firefox-devtools-mcp: Model Context Protocol server for Firefox DevTools - enables AI assistants to inspect and control Firefox browser through WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org
1 post - 1 participant
The Mozilla Blog
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.
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.”
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.”
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.
The post Mila and Mozilla announce new initiative to build trustworthy open source AI for everyone, with Canadian government support appeared first on The Mozilla Blog.
Firefox Nightly
Script to find new contributors from bug list
Mozilla Open Policy & Advocacy Blog
This is the second part of a two-part series in which we explore approaches to protecting children online while safeguarding privacy, security and the open web. Part one covers our concerns regarding age gates, and suggests alternative policy proposals that address the root causes of online harms. Part two explores better ways to build age assurance architectures that respect users’ rights and autonomy.
Across the world, legislation to introduce age gates and social media bans is proliferating. Many governments are still considering age restrictions a straight-forward and cost-effective tool to achieve their child safety goals. However, evidence is mounting that age assurance mandates pose risks to users’ privacy, security, free expression and access to information, threaten the open web and competition, and undermine policymakers’ goals: enabling young people to have safe and trustworthy experiences online, while enabling the digital economy to grow.
As we have said before, we believe that blunt tools like social media bans are overly broad, undermine users’ rights and do not address the root causes of online harm. Reducing risks to young people online requires a holistic, privacy-first approach to online harms emphasizing enforcement of existing rules, addressing harmful design, and equipping all users with better defaults, more choice and granular controls over their experiences online.
Age gates alone are insufficient to address online harms, but age signals can contribute to more holistic approaches by helping achieve age-appropriate experiences online. Where age assurance obligations are considered as one tool out of many to foster age-appropriate experiences, their potential benefits must be balanced against their negative implications for users’ privacy and security, access to services, and the openness of the web.
Implementing age assurance is not a single intervention, but a series of steps. A user’s age is first assessed, which can happen through a variety of sources of age information and with varying degrees of accuracy. That signal is secondly shared with the actor responsible for age-appropriate experiences, and thirdly acted upon or enforced by that actor.
Dominant approaches to age assurance obligations focus on online platforms – given that this is where many risks encountered by young people unfold. In practice, this has led to online services – websites or apps – turning to third-party age assurance providers to perform age assurance, whether through biometric age estimation, age inference based on users’ behavioral data, ID-based checks, or other methods.
In this model, third-party age assurance companies both assess users’ ages and share that signal with the platforms responsible for implementing it. To retain access to social media platforms, messaging services and many other online offerings, users are thus forced to surrender their sensitive personal data to these age brokers, often a different one for each service.
Once in the hands of these providers, peoples’ data is at risk of being sold, repurposed or accessed by law enforcement. The recent data breach of a ID and age verification provider that exposed more than 153 million IDs underscores that this is not a theoretical concern, but a significant risk for anyone asked to prove their age online. Rather than being asked to trust companies, some of which have already been exposed for their harmful data practices, people deserve verifiable guarantees that their data is safe and secure.
Emerging regulatory models are considering the role that device intermediaries, like operating systems, device manufacturers, and app stores, can play in age assurance. In such models, these actors are either required to communicate an age signal to the actor responsible for acting on it, or to restrict access to services themselves, based on an age signal created at the device level.
Device intermediary focused approaches, too, come with significant challenges: Given the significant concentration of power among (mobile) operating systems and app stores, such a legislative design can easily further entrench the dominance of Apple and Google, disadvantage open source competitors, and undermine users’ privacy and control, including over their devices. These implications must be carefully mitigated.
Every approach to age assurance comes with important trade-offs, and we maintain that there is no age assurance system that mitigates all risks to users’ fundamental rights, access to services, competition and the open web, while being effective in avoiding every instance of under-age access. However, we do believe that better age assurance architectures are possible. In many situations, unverified age signals may be sufficient to provide age -appropriate experiences without undermining fundamental rights. Where stronger assurances are considered necessary, zero knowledge architectures can help protect users’ privacy.
Better age assurance architectures must be private, secure, accessible to all users, and, crucially, must provide them with autonomy, choice and control. Designing age assurance obligations that live up to these values is a question of governance, not technology. Hence, policymakers have a crucial role to play in defining requirements for rights-respecting age assurance systems.
1. Assign responsibilities deliberately.
From people’s devices, to operating systems, app stores and websites or apps, many actors can be involved in age assurance processes. Some of these actors will be better suited to be responsible for certain steps of age assurance processes than others to avoid negative outcomes for fundamental rights and the open web.
Given that websites and apps know most about their services, their features and content hosted, we argue that they are in the best place to act on age signals to provide age-appropriate experiences. Implementing age signals at this level allows for more granular choices for creating age appropriate experiences. Other actors, like network operators or device vendors, simply do not have the necessary information.
While websites or apps are best placed to create age appropriate experiences, device intermediaries like operating systems are well-placed to facilitate the privacy-preserving sharing of age signals created locally. Moving age assessments to the device-level allows users to interact with an age provider once, rather than having their age assessed by a different age provider for every service they use. If such approaches are pursued, strong protections need to be in place for open source operating system providers, as well as mandates for the development of open and free standards to avoid fragmentation and competition harms, and to strengthen transparency and user consent
2. Ensure choice, equity and accessibility.
Age can be attested to, approximated or verified in many ways. Every age assessment method comes with important trade-offs, but people should not be forced to take risks on their personal data and safety to retain access to services and information. Users should thus always have a choice between multiple age providers that are privacy-preserving, non-discriminatory and accessible. This is especially important for young people who often don’t have access to more privacy-preserving age assurance methods, and are expected to hand over their biometric data to stay online.
The question of which providers are deemed trustworthy enough to participate in such a system is a crucial one. Policymakers must ensure that the options available to people protect their privacy and security, and that a diverse list of providers prevents people from being locked out. Only if everyone has the ability to access age assurance systems through privacy-preserving and rights-respecting providers, will the web remain accessible and open. People should be able to rely on a plurality of institutions, government or private, that can either attest to their age, including face-to-face, or have existing knowledge of their ages that they can share through the use of anonymous credential technology. Examples might be banks, public health and educational institutions, libraries, or services like phone providers, ISPs, subscription services or other services that are able to attest to a user’s age.
3. Put people in control.
We should always be in control over what information is shared about us, and to whom. Once an age signal is created, age assurance architectures should empower users to hold that signal – in the form of a credential – on their device. Whether an age signal is shared with an app or website by the operating system or the browser, users must be in control of the decision whether and to whom that information is shared with.
Users must also retain control over – and trust in – their devices. Digital devices are the interface through which we all navigate increasingly large parts of our lives; they are our trust anchors. Enforcing restrictions at the device level on what people can or cannot do online would undermine the already fragile trust relationship between the two — pushing people toward less secure workarounds, rather than addressing the underlying policy concern.
This means that it is best when responsibility for sharing the results of age assessments is performed by users and their devices.
4. Assess risks end-to-end.
Many jurisdictions require age assurance systems to be “highly effective”. We believe that the effectiveness of an age assurance system should be considered end-to-end, and not be limited to the assessment step: After all, where an older relative or friend is willing to help a child circumvent a block, no technical mechanism can be effective.
Given these considerations, we think there is value in considering age assurance approaches that empower parents to attest to their child’s age when setting up their device. Coupled with barriers to resetting the age once set, such an age signal would provide a high degree of confidence without requiring invasive proofs of age through biometric analysis or ID document checks. As noted above, such approaches need to ensure that age attestation is not another factor cementing the dominance for a few actors, and that open source projects are meaningfully protected from being locked out of participating in a market.
Despite those challenges, we believe that it is crucial to not only consider the potential risks young people could encounter online, but also the risks flowing from age assurance systems themselves. Given those risks, parental age attestation can be a lower-risk approach suitable in many contexts.
5. Leverage zero-knowledge architectures.
Where high-assurance age credentials are used, zero-knowledge architectures are the right step towards sharing age signals in a privacy preserving way. Such approaches allow users to verify the truth of a statement about them, like their age or age range, without having to reveal the information on which the statement is based.
While zero-knowledge architectures are promising, they do not solve every issue. Beyond limiting disclosure of information about people (such as attributes other than their age), hiding the issuer of age credentials (like a bank, public service or educational institution) is key to preserving users’ privacy and choice of assessment methods. This prevents discrimination against users of smaller or less common age providers.
Likewise, the issuer of an age credential should not know which service or feature someone is accessing with an age proof. The example of Spain’s Catera Digital, or “porn passport”, shows why: The Spanish age verification system created tokens that the verifying authority could use to infer a user’s browsing history, undermining users’ privacy, trust, and ultimately the adoption of the system.
Zero-knowledge proofs themselves also do not prevent abuse of age information, such as by using age data in ad targeting. Beyond strict prohibitions on repurposing age data, we believe that any age assurance system should be open source to facilitate trust, accountability and transparency.
To prevent the sharing of age tokens, we believe rate limits, which restrict how often an age token can be used, are the best and most effective solution. We strongly caution against linking tokens to attested hardware, such as trusted platform modules (TPMs). Hardware-bound tokens force users to use specific, approved hardware. Hardware attestations can leak details about the device’s configuration and location, thus enabling tracking or unjustified discrimination at the moment of certification issuance. Attestations undermine users’ freedom over their own devices, including what software they can install and run. People who run older or unsupported devices might be excluded as old, weak hardware is routinely found to be compromised, such that it needs to be revoked. Rate limits offer a far simpler and more robust answer to these challenges.
6. Don’t break the internet.
The open internet – and the web built on top of it – is a global public resource that millions depend on every day, and that has become a cornerstone of our societies. This openness thrives on open standards, shared protocols, and interoperability. Age checks risk fragmenting the web in more ways than one: Incompatible requirements will create a patchwork of age-gated communities, and age gates in the hands of a few will push people further into closed ecosystems, undermining the wider digital competition and the decentralization that gives the internet its strength.
To avoid the hollowing out of fundamental rights online, and the undermining of the open internet, international collaboration and free and open standards are urgently needed to govern age assurance across borders.
***
We believe the principles set out above can help mitigate the large-scale erosion of privacy, security, and agency that the first wave of age assurance laws and social media bans has introduced.
But improved legislative mandates and technical fixes alone are not enough to improve young people’s online experiences in a rights-respecting way. Enabling young people to develop positive relationships with digital technologies is foremost a societal issue, not a technical one. Changing norms around how we engage with technology, what we ask of companies seeking our attention, and how we have conversations about what safety means beyond abstinence and control will require a whole-of-society approach to digital well-being.
The post Pragmatic principles for more rights-respecting age assurance architectures appeared first on Open Policy & Advocacy.
The Rust Programming Language Blog
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.
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.
A previous attack of this form targeted many prominent Rust developers in
June, and, last month, the arrayref crate was briefly compromised through similar
attacks. At this moment we do not know if these are all a part of the same
campaign.
This attack style is known to be used by the DPRK, and has been seen outside of the Rust community as well.
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.
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
bug/{bugid}/comment returns wrong comment_idDiscuss these changes in the BMO Matrix Room
1 post - 1 participant
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.19.1:
Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
The Mozilla Blog
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.
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.
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.
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.
The post Mozilla and Mistral: Partnering to expand AI competition and preserve user choice appeared first on The Mozilla Blog.
Jonathan Almeida
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:
git fetch <alias>git checkout <alias>/<branch>Here is a one-liner for it that you can add to your gitconfig:
[alias]
co = "!f() { PNAME=$(basename `git rev-parse --show-toplevel`); OWNER=$(echo $1 | cut -d':' -f1); BRANCH=$(echo $1 | cut -d':' -f2); git fetch git@github.com:$OWNER/$PNAME.git $BRANCH; git checkout FETCH_HEAD; }; f"
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.
fWith 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.
This Week In Rust
Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.
Want TWIR in your inbox? Subscribe here.
This week's crate is zenjpeg, a pure Rust JPEG encoder and decoder.
Thanks to Kornel for the suggestion!
Please submit your suggestions and votes for next week!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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!
523 pull requests were merged in the last week
rustc_builtin_macrosDenseBit for drop_live_at in liveness tracingBox<[Word]> for word storage in DenseBitSetBoxThread::os_idExtend implementationsVec::from_fncore::mem::DropGuardunsafe_cell_accessfix(git): For git cli, tell users what config we aren't forwarding on errorfix(install): use packaged lockfile by defaultmanual_readme and non_kebab_case_bins to allow--edition in messages testsmax_width within macrosconst when formatting inline const blocksmap_clone: avoid suggestions after type-changing coercionscollapsible_match suggesting wrongly for conditional compiled codemanual_swap in const contextshir::Type owner mismatches between anon constsimpls_trait for self type of builtin derive impls for generic typesThere were almost no regressions this week, and several performance improvements! Though some of them were reverts of regressions from a previous week. #162422 improved the performance of Polonius, whose performance is getting closer to the previous NLL borrow checker.
Triage done by @Kobzol. Revision range: 656a9da1..20d35a3a
Summary:
| (instructions:u) | mean | range | count |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
0.4% | [0.1%, 0.9%] | 3 |
| Improvements ✅ (primary) |
-0.7% | [-4.4%, -0.1%] | 199 |
| Improvements ✅ (secondary) |
-0.9% | [-2.7%, -0.1%] | 222 |
| All ❌✅ (primary) | -0.7% | [-4.4%, -0.1%] | 199 |
0 Regressions, 5 Improvements, 5 Mixed; 2 of them in rollups 40 artifact comparisons made in total
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
debug_closure_helpersthread_local!funnel_shifts (including const)mem::conjure_zstResult::into_{ok,err}wide-arithmetic featureCommandExt::exec and opt to use execve and resolve path manuallyAllocatorNo Items entered Final Comment Period this week for Rust RFCs, Compiler Team, Language Team, Language Reference or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.
Rusty Events between 2026-09-16 - 2026-10-14 🦀
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.
Please see the latest Who's Hiring thread on r/rust
Every so often I am told about some maths fact that I can only assume someone went to prison for discovering
Thanks to Chayim Refael Friedman for the suggestion!
Please submit quotes and vote for next week!
This Week in Rust is edited by:
Email list hosting is sponsored by The Rust Foundation
The Servo Blog
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:
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.
Firefox Nightly
Script to find new contributors from bug list
Jonathan Almeida
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:
mk_add_options MOZ_OBJDIR="$HOME/.mozbuild/objdir-frontend"
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.
About:Community
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.
JPEG XL is coming to Firefox
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.
From the Reddit Community
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.
P.S.
Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
Discuss these changes in the BMO Matrix Room
1 post - 1 participant
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.19.0:
moz-phab patch --apply-to here should apply to the original base revision and rebase, rather than applying the raw diff on HEADmoz-phab list subcommandDiscuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
Thunderbird Blog
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
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.
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.
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.
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.
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
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!
The post Desktop Settings: Removing technical jargon appeared first on The Thunderbird Blog.
Firefox Nightly
Script to find new contributors from bug list
The Rust Programming Language Blog
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.
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:
enums are represented by debuggers so they show actual
variantsHashMap) are represented by debuggers so
they show their contents, rather than their implementation detailsString and CString) are represented
by debuggers so they render as text, rather than their implementation detailsasync debugging experience, particularly with stack tracesFutures)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 Tooling Announcements
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.Install:
claude mcp add firefox-devtools npx @mozilla/firefox-devtools-mcp@latest
codex mcp add firefox-devtools – npx @mozilla/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: freema, f3tch (github), jasonanovak and shoemoney.
Full changelog: https://github.com/mozilla/firefox-devtools-mcp/releases/tag/v0.10.2
Repository and issues: GitHub - mozilla/firefox-devtools-mcp: Model Context Protocol server for Firefox DevTools - enables AI assistants to inspect and control Firefox browser through WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org
1 post - 1 participant
Firefox Tooling Announcements
The latest version of PerfCompare is now live! This includes the launch of PerfCompare’s Simple View. Read the following blog post, Introducing PerfCompare’s Simple View, to learn more.
Check out the change-log below to see the updates:
Highlights:
[kala-moz]
Other changes:
[kala-moz]
[gopar]
[bug-2021092] Update light/dark toggle wording to be less ambiguous (#1073)
Thank you for the contributions!
Bugs or feature requests can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Matrix. Come and chat!
1 post - 1 participant
Mozilla Performance Blog
We heard you. You don’t want to open your PerfCompare performance comparison and feel like you need a background in statistics to interpret the Mann-Whitney-U results. Cliff’s Delta, CLES, and normality tests, oh my! It should not feel like you’ve blindly walked into a college stats exam, unless of course, you love statistics. For the rest, all you want is an easy answer to the question: Did my changes make things faster or slower?
So we fixed that. PerfCompare now shows the bare essentials by default and tucks the heavy statistics one click away.
The results table now leads with the platform, the Base and New values, how far the median moved and its direction, the status (which includes the option to filter out noise) and the size of the change. To create a more advanced view, a single “Advanced options” dropdown allows you to add the expert columns (Cliff’s Delta, CLES, Significance) and the info-rich expanded row details below the full-width graph. A small help section at the top of the results provides a quick explanation of the columns. The purpose is to serve a diverse audience while preserving your selections in the URL so a shared link reproduces your view.
The “Advanced options” dropdown lets you add the precise statistics columns:
Each one toggles on independently, so you can surface only Significance or the whole trio.
Expand a result and you get a clean panel: a full-width graph of how your Base and New runs are spread out, a quick summary (platform, app, which direction is “better”), and a little “how to read this graph” tool-tip for anyone who hasn’t stared at a distribution curve before. You can still poke at the graph’s mode controls if you want to dig in.
You can access the extra expanded row details such as effect size and confidence intervals or the full stats table in the “Advanced options” dropdown. Turn on what you need, and the expanded extras lay out in neat two-column rows. If you turn on mode analysis and there aren’t multiple modes to show, we now say “No mode analysis available” instead of a blank space.
Lastly, the advanced columns and expanded-row details you’ve switched on, along with your filters and sorting, are all encoded in the URL. Paste it to a coworker and they’ll land on the same result you were looking at; for filters and sorting, the shared link takes precedence over whatever they had saved locally. (One exception: the “How to read the results” panel is a personal per-browser preference, so it stays with you rather than tagging along on the link.)
Several follow-ups on the way:
We want PerfCompare to work for all users, whether you’re chasing your first regression, or you’re an expert who doesn’t want to lose their favorite metrics to a cleaner view. Our answer is separating the simple view from the power user view, and making the toggle obvious and shareable.
The great news is it’s live now! Go expand a Mann-Whitney-U result, click around the Advanced options, and tell us what you think. Please share your feedback, suggestions, or comments on the #perfcompare channel on Matrix. If you’ve encountered a bug or have a feature request, please file them in Bugzilla. We’re listening.