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