Mozilla

Some of you may have heard about this change from the announcement the team shared in early July, but Firefox is moving to a two-week release cycle. The first release on the new cadence is Firefox 155 on September 1, 2026, two weeks earlier than the originally planned September 15 release.

Why this is happening

If you've been following recent Firefox releases, you may have noticed that we've shipped multiple dot releases for several versions (up to six for Firefox 152). This new release cadence is designed to get bug fixes and completed features into users' hands sooner, while making the release process more predictable.

It's important to note that this doesn't mean Firefox will ship twice as many features. Instead, we'll be releasing updates more frequently, using a two-week rhythm instead of the current four-week cadence. For contributors, the biggest benefit is predictability: rather than waiting for an unpredictable series of dot releases, we'll have a more consistent release schedule to plan around.

That said, it doesn't mean dot releases will disappear entirely. They may still happen when needed, albeit not as often.

Here's what to expect, how we're preparing, and how you can help.

What it means for SUMO

Community Forum

On a typical Firefox release, we see an average of 30% increase in incoming support questions during the first 10 days. Under the new two-week release cadence, we expect these waves of questions will arrive more frequently.

The good news is that we've observed a consistent pattern after each release. Most questions fall into a handful of common categories, including UI changes ("Where did this go?"), lost data after updating, and crashes. We expect to see the same types of questions, just on a more frequent schedule, which gives us an opportunity to prepare ahead of each release.

Knowledge Base & Localization

A faster release cadence also means a faster content cycle. We expect that content requests will arrive on a more distributed timeline instead of every 4 weeks. But of course, this will also have a downstream impact on localization, as new and updated KB articles become available for translation more frequently. We recognize the additional pressure this could put on localization communities, and we'll be monitoring the transition closely to make sure we're mindful of contributor capacity.

Release preparation

We'll be preparing a release wiki page every two weeks instead of every four. For now, our monthly Community Call will remain on its existing monthly schedule, though we'll revisit that if the new release cadence creates a need for more frequent community updates.

How we're preparing and how you can help

Here's what we're doing:

Community Forum: We'll be adding and updating canned responses related to the most common post-release questions, including UI changes, lost data after updating, crashes, and other recurring issues. We'll also continue to prepare the release wiki before each Firefox release so you'll know what's changing and what to expect.
Knowledge Base: The CX team is updating the Bugzilla content request template and collaborating with the product folks to make it easier for them to submit content requests and provide the information needed to create the content. We've also introduced a sumo-contributors keyword in Bugzilla to categorize requests that are open for contributors, making them easier to find and track.
Localization: We know the SUMO localization dashboard doesn't currently have a priority indicator, so please use the release wiki as a guide to identify which content may need attention first. We'll also explore ways to provide better visibility into upcoming content changes, giving localization communities more time to plan their work around the new release cadence.

Here's how you can help:

Be extra active during the first 10 days after each release. That's when we see the biggest wave of support questions, and your contributions have the greatest impact.
Use our common forum responses. They'll help you reply more quickly and consistently. If you spot opportunities for improvement, please let us know in this thread! Your feedback will help make them even better for future releases.
Get involved in the KB content request process. With content requests arriving more frequently, we'll need more contributor participation to help create, update, and review support content. Keep an eye on Bugzilla requests tagged with sumo-contributors for opportunities to get involved.
Keep an eye on the release calendar for localization work. Localization work will likely arrive on a more distributed schedule rather than being concentrated every four weeks. Following the release calendar can help you anticipate when new or updated content may be ready for localization. But of course, be sure to contribute at a pace that works for you.

Looking after each other

We also want to acknowledge that contributor burnout is a real risk when the quieter periods between releases become shorter. We'll be monitoring the transition closely and adjusting as we learn. Most importantly, you should never feel like you have to be "on" all the time. Every contribution, no matter how big or small, makes a difference.

The first major test of this new cadence will likely come with Firefox 157, when Project Nova is expected to roll out more broadly. We'll treat that release as an opportunity to learn what works, identify where we need to improve, and fine-tune our approach together.

Thank you for everything you do to support Firefox users. This transition is only possible because of our contributor community. If you have any questions, concerns, or ideas, we'd love to hear them. Join our Community Call where we'll also discuss more about this change.

19 Aug 2026 4:07pm GMT

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

Experiment in reducing target directory size on nightly

Newsletters

The Embedded Rustacean Issue #78

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Research

GPU Offload in Rust: Portable, Safe, and Fast

Miscellaneous

Zerocopy with Joshua Liebow-Feeser

Crate of the Week

This week's crate is tokio_with_wasm, a crate that lets a single tokio codebase run both natively and in web browsers.

Thanks to Kim Dong-Hyun for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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.

Cargo

Tracking Issue for -Zembed-metadata

No calls for testing were issued this week by Rust, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

613 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

There were almost no regressions this week, while the next trait solver saw several significant performance improvements!

Triage done by @kobzol. Revision range: 771916f9..8fa1c96c

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.5%]	6
Regressions ❌ (secondary)	0.6%	[0.2%, 1.0%]	17
Improvements ✅ (primary)	-0.5%	[-1.7%, -0.2%]	166
Improvements ✅ (secondary)	-2.3%	[-16.0%, -0.1%]	219
All ❌✅ (primary)	-0.5%	[-1.7%, 0.5%]	172

0 Regressions, 6 Improvements, 7 Mixed; 4 of them in rollups 50 artifact comparisons made in total

Full report here.

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

RFC: Refactor the libs team

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Cargo

Compiler Team (MCPs only)

Expose target_abi = "v8plus" on sparc-unknown-linux-gnu

No Items entered Final Comment Period this week for Rust RFCs, Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

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.

Upcoming Events

Rusty Events between 2026-08-19 - 2026-09-16 🦀

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

ass-bind is peak

- Clar Fon on rust-zulip discussion "assumptions on binders" abbreviations

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

19 Aug 2026 4:00am GMT

Bugs resolved in Moz-Phab 2.17.0:

bug 2036748 submit: parallelise per-commit upload + creatediff across the stack
bug 2036749 git: skip restoring git checkout in cleanup/finalize when HEAD already on branch
bug 2060484 " Phabricator Error: Validation errors" should display the revision

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

1 post - 1 participant

Read full topic

18 Aug 2026 9:16pm GMT

Leia a versão em inglês aqui.

A concorrência é o ponto forte da internet. Com a possibilidade de as pessoas escolherem navegadores, mecanismos de pesquisa e aplicativos livremente, a concorrência entre das empresas se baseia no mérito. No entanto, os mercados digitais estão concentrados em "guardiões" que controlam a descoberta, dificultando o alcance de usuários por desenvolvedores independentes. A fiscalização tradicional acabou se tornando ineficaz, normalmente sendo muito tardia. Agora, governos do mundo todo estão adotando novas ferramentas para garantir um mercado aberto e contestável.

O projeto de lei (PL) 4675/2025 é um passo importante nessa direção. Baseando-se na DMA (Digital Markets Act) da União Europeia e na DMCCA (Digital Markets, Competition and Consumers Act) do Reino Unido, esse projeto de lei aborda questões de concorrência sistêmica voltadas à realidade do mercado brasileiro. A Mozilla é a favor dessa legislação, que visa criar uma estrutura segmentada de concorrência para os mercados digitais brasileiros.

A concorrência possibilita produtos melhores e liberdade de escolha

Há vinte anos, a Mozilla desenvolve o Firefox como um navegador independente, priorizando a privacidade, a segurança e a escolha. Operamos no Gecko, um dos três mecanismos de navegador existentes no mundo. A independência é essencial para evitar dominância no mercado e garantir que os usuários tenham liberdade de escolha. A inovação não é suficiente. Os produtos precisam de oportunidades justas de concorrência sem barreiras de pré-instalação ou interoperabilidade.

O PL 4675/2025 trata dessa questão por meio de uma estrutura ex ante, permitindo que a autoridade relevante mitigue os riscos antes de se tornarem irreversíveis. O anteprojeto mais recente contém melhorias importantes dessa estrutura. Ele determina as obrigações de acordo com produtos ou serviços específicos, em vez de aplicá-las automaticamente a todo um grupo corporativo; define proteções processuais durante todo o processo de designação; e traça limites mais claros sobre a capacidade da autoridade de fazer algo as obrigações além daquelas estabelecidas na legislação. De forma mais notável, ele determina uma arquitetura de escolha "isonômica e não discriminatória", incluindo telas de opções para selecionar, instalar ou definir produtos de terceiros como padrão.

A experiência da Mozilla com telas de escolha de navegador, em conformidade com a DMA da União Europeia, mostra que essas disposições funcionam. O Firefox foi o navegador de escolha mais de seis milhões de vezes. A probabilidade de as pessoas que escolheram o Firefox nessas telas continuarem usando o navegador é cinco vezes maior. Ao tornar a estrutura segmentada e previsível, o PL 4675/2025 estabelece a base para um ecossistema de concorrência em que a inovação impulsiona o sucesso.

Qual é o benefício da concorrência para as pessoas

A política de concorrência defende as pessoas. Mercados abertos permitem a liberdade de escolha e o sucesso de empresas menores. Críticos argumentam que essas propostas prejudicam a inovação, mas nossa experiência sugere o contrário. O Gecko, mecanismo de navegador do Firefox, continua sendo o maior mecanismo não controlado por uma operadora dominante de sistema operacional. Essa independência nos permite priorizar inovações voltadas aos usuários, como proteções avançadas de privacidade e segurança.

Decisões de design, como padrões pré-instalados e barreiras de interoperabilidade, moldam significativamente a experiência de usuários. A pesquisa Over the Edge 2.0 da Mozilla destaca como essas práticas afetam a liberdade de escolha. Startups também se beneficiam, pois podem alcançar usuários e concorrer com base no mérito, em vez de depender de decisões de plataformas dominantes. O projeto de lei brasileiro promove essas condições ao proporcionar ao Cade (Conselho Administrativo de Defesa Econômica) as ferramentas para tratar de práticas anticoncorrenciais, garantindo que a concorrência de plataformas dominantes ocorra por meio de melhoria da qualidade do produto, não por controle da infraestrutura.

De olho no futuro

Os mercados digitais evoluem, mas os princípios de concorrência justa (abertura, liberdade de escolha, interoperabilidade e transparência) continuam iguais. O PL 4675/2025 transforma esses princípios em normas aplicáveis. Seu modelo ex ante segmentado e suas proteções processuais posicionam o Brasil entre os países que visam restaurar o equilíbrio do mercado. Por fim, o sucesso da estrutura será medido por sua capacidade de proporcionar uma mudança significativa para os usuários.

A Mozilla é a favor desse projeto de lei e se dispõe a colaborar com o poder legislativo, o Cade e todas as partes interessadas. Com alterações segmentadas, o PL 4675/2025 pode se tornar uma estrutura duradoura a favor da concorrência, da inovação e da liberdade de escolha.

The post Brasil dá um passo importante para a promoção de mercados digitais abertos e competitivos appeared first on Open Policy & Advocacy.

18 Aug 2026 8:59pm GMT

Read the Portuguese version here.

Competition is a strength of the internet. When people freely choose among browsers, search engines, and apps, companies compete on merit. However, digital markets have concentrated around 'gatekeepers' that control discovery, making it harder for independent developers to reach users. Traditional enforcement has proven ineffective, often arriving too late. Governments worldwide are now adopting new tools to ensure open, contestable markets.

Brazil's Bill 4,675/2025 is a critical step in this direction. Drawing lessons from the EU's Digital Markets Act and the UK's Digital Markets, Competition and Consumers regime, the bill addresses structural competition concerns with an approach calibrated to Brazil's market realities. Mozilla strongly supports this legislation, which aims to establish a tailored competition framework for Brazil's digital markets.

Competition unlocks better products and meaningful choice

For over twenty years, Mozilla has built Firefox as an independent browser prioritizing privacy, security, and choice. We operate on Gecko, one of only three browser engines worldwide. Maintaining independence is critical to preventing market dominance and ensuring users have genuine choices. Innovation alone isn't enough; products need fair opportunities to compete without being hindered by preinstallation or interoperability barriers.

Bill 4,675 addresses this via an ex ante framework, allowing Brazil's competition authority to mitigate risks before they become irreversible. The latest draft improves this framework in several important ways. It tailors obligations to specific products and services rather than automatically applying them across an entire corporate group, strengthens procedural safeguards throughout the designation process, and places clearer limits on the authority's ability to expand obligations beyond those established in legislation. Most notably, it requires "neutral and non-discriminatory" choice architecture, including choice screens, for selecting, installing, or setting third-party products as defaults.

Mozilla's experience with browser choice screens under the EU Digital Markets Act proves these provisions work. Firefox has been selected more than six million times, and users who select Firefox through these screens are five times more likely to continue using it. By making the framework targeted and predictable, Bill 4,675 establishes a foundation for a competitive ecosystem where innovation drives success.

How competition delivers for people

Competition policy is about people. Open markets provide genuine choice and allow smaller players to thrive. Critics argue these proposals harm innovation, but our experience suggests the opposite. Gecko, Firefox's browser engine, remains the only major engine not controlled by a dominant OS operator. This independence enables us to prioritize user-focused innovations like advanced privacy and security protections.

Design decisions, like preinstalled defaults and interoperability barriers, significantly shape the user experience. Mozilla's Over the Edge 2.0 research highlights how these practices undermine choice. Startups similarly benefit when they can reach users and compete on merit rather than relying on dominant platform decisions. Brazil's bill can foster these conditions by providing CADE with tools to address anti-competitive practices, ensuring dominant platforms compete by improving product quality rather than leveraging infrastructure control.

Looking ahead

Digital markets evolve, but healthy competition principles (openness, choice, interoperability, and transparency) remain constant. Bill 4,675 translates these into enforceable rules. Its tailored ex ante model and procedural safeguards position Brazil among jurisdictions restoring market balance. Ultimately, the framework's success will be measured by its ability to deliver meaningful change for users.

Mozilla supports this bill and looks forward to collaborating with lawmakers, CADE, and stakeholders. With targeted refinements, Bill 4,675 can become a durable framework that promotes competition, supports innovation, and empowers people with greater choice.

The post Brazil is Taking an Important Step Toward More Open & Competitive Digital Markets appeared first on Open Policy & Advocacy.

18 Aug 2026 8:59pm GMT

Gamers have asked for GeForce NOW support for years. Today, NVIDIA made it official, opening up GeForce RTX-powered play to Firefox on Windows.

Firefox users can now stream more than 2,000 PC games from virtually anywhere, no downloads, installs, or hardware upgrades required, just a Windows PC and a browser.

Gaming: one of the web's toughest tests

Cloud gaming pushes a browser in ways most websites never do. Every click and frame matters. Behind today's announcement is months of collaboration and engineering between Mozilla and NVIDIA to deliver GeForce NOW on Firefox for Windows.

Now, players can jump into high-performance PC gaming directly from Firefox, no waiting on lengthy game downloads, installs, or updates. The experience delivers GeForce RTX-powered performance at up to 1440p and up to 120 frames per second for GeForce NOW Ultimate members.

"Firefox earned its place on our list of supported browsers by delivering the first-class experience GeForce NOW players expect. We set a high bar for browser support, and we're excited to welcome Firefox - giving millions of Firefox fans a new way to stream the games they love," said Andrew Fear, Director of NVIDIA GeForce NOW.

Versatility and customization baked into your gaming rig

Gamers put real effort into making their rigs their own, and Firefox gets that. Users can choose themes, custom colors, and tab settings to customize their setup, instead of sitting there like just another window.

We also know online gaming doesn't happen in just one window. It's social and sometimes spontaneous. With Firefox, you can have a Discord call running in Split View, a guide open in another tab, or Reddit pulled up between matches. Then go full screen when you're ready to play, no need to switch browsers to stream games.

"Teaming up with NVIDIA to bring GeForce NOW to Firefox is a milestone moment - one of the world's leading cloud gaming services, now running on a browser built for privacy, control and flexibility. This is a big win for the Firefox community and for NVIDIA's gaming community - and a sign of even bigger things ahead," said Ajit Varma, Head of Firefox.

If Firefox is already your browser of choice, online gaming and your PC game library can join the party. Whether your library lives on Steam, Epic Games Store, GOG, Xbox PC Game Pass, or Ubisoft Connect, you can sign in, open your library, and start streaming the games you already own. For all the gamers returning to Night City in Cyberpunk 2077, jumping into Halo: Campaign Evolved, or dropping in for a quick round of Fortnite, Firefox users can now play where you want.

Try it today

Update to the latest version of Firefox, go to play.geforcenow.com, and sign in with your GeForce NOW account.

Join us August 25 as NVIDIA heads to Gamescom, where we'll have more to share about what this partnership means for gamers.

The post The wait is over. NVIDIA GeForce NOW adds Firefox to its supported browser lineup. appeared first on The Mozilla Blog.

18 Aug 2026 2:58pm GMT

Firefox users were choosing Startpage long before today - to the tune of more than a billion searches a year, every one of them required some assembly: an extension, a manual setting, a workaround.

Today, starting with Firefox 154, that choice becomes as easy as head to the drop-down menu, hit 'select,' and start searching. Startpage is now a built-in search option for Firefox users on desktop in Germany, France, Austria, Switzerland, and the Netherlands. Android and iOS are coming soon. Whether you want to search with Startpage, or another preferred search engine, it's as easy as opening your search settings, picking a default, and done.

And if you're happy with your current search engine, nothing about your setup changes.

Why Europe first

This launch starts in Startpage's home markets: a Netherlands-based search engine, now built into the browser for some of the most privacy-conscious users in the world. At a moment when so much of the web experience is decided by a handful of very large companies, a search option that's private by design and European by origin isn't a small thing.

What Startpage delivers

Startpage delivers full, high-quality search results without the privacy trade off. Queries aren't stored or linked to you, and there are no AI answers pushed above your search results. In fact, there's no AI at all. Based in the Netherlands, Startpage built its product around a simple idea: great search and personal privacy can go hand in hand.

"So much of your web experience is prescribed before you ever open a browser. We'd rather you decide how you want to search. Adding Startpage puts a genuinely private search engine option - real results, zero profiling, AI-free - one click away for millions of people in Europe," said Ajit Varma, Head of Firefox.

Users asked with one billion searches

Startpage ranks among the most-requested search engines in the Firefox community. When demand is this clear, our job is to remove the friction.

"More and more of what people use online comes from a handful of very large companies, and search is where that concentration gets felt most directly. Firefox has always been the browser for people who want to make their own decisions about the web, which makes it a natural home for private search. Firefox users already run over a billion Startpage searches a year. Now Startpage is built in for everyone in these markets," said Stewart Marlborough, President of Startpage.

That's the pattern we want: people who use Firefox every day tell us what they need, and we ship it.

Search is a choice. Firefox treats it like one.

Most browsers have already decided how you're going to search. Firefox hasn't. Pick your search engine, control what happens to your queries, decide who sees data about you, even turn AI on or off. It should always be your call. Not everyone wants the same thing from search, and a browser shouldn't pretend they do.

Try it out

If you're in Germany, France, Austria, Switzerland, or the Netherlands, update to Firefox 154 and you'll find Startpage in your search settings.

The post A billion searches a year, now built in: Startpage comes to Firefox appeared first on The Mozilla Blog.

18 Aug 2026 2:57pm GMT

Browsers make it easy to start things, but picking them back up is another story.

We start planning a trip or researching a purchase, and before long we're comparing options and chasing ideas across dozens of tabs. That work rarely happens in one sitting. When we come back after an interruption, we have to figure out where we were, what we'd already found, and what we were trying to do in the first place.

Smart Window is Firefox's privacy-first, AI-powered browsing experience designed to help people finish what they start online. It works with the context you choose to share, such as your open tabs and relevant browsing history, so you can get back to what you were doing without retracing your steps.

We've spent the last several months building and testing Smart Window in beta with our community. Today, we're adding new capabilities that help you check answers without losing your place, make sense of open tabs and get back to things you've seen before. Together, they help keep a task moving across tabs, searches, and time.

"The browser already has much of the context around what you're trying to do - the research in your tabs, the pages you've visited, the things you've found along the way," said Ajit Varma, Head of Firefox. "With Smart Window, we're exploring how to make more of that context useful while keeping you in control."

What's new in Smart Window

Check answers without losing your place

When you have a question in the middle of a task, getting an answer shouldn't take you out of your flow or require you to track down the sources separately.

Through our new partnership with Exa, Smart Window can now retrieve current web information and show the sources behind its response without taking you to a separate search results page. Learn more about why we chose Exa and what the partnership means for Firefox in our companion post.

Group tabs that belong together

It doesn't take long for a quick search to turn into a browser full of tabs. Once they pile up, keeping track of everything becomes even more work.

Smart Window can now suggest groups for related tabs, making it easier to organize what you have open and return to it later. It can also spot duplicate tabs and close them with a click.

Find your spot again

Sometimes you remember what was on a page better than you remember what it was called or how you got there. Smart Window can now show visual previews of pages in your browsing history, making it easier to spot the page you're looking for among similar results without opening each one to figure out which is which.

Behind the evolution

Last November, we shared an early concept called "AI Window," exploring what it could look like to give people a user-controlled space where they could chat with an AI assistant to get help while browsing. We shared it early because we wanted our community to help shape where it went next.

Over the months that followed, we watched how people used the experience, listened to feedback, and tested new ideas. A consistent theme emerged: people were increasingly using it as part of their everyday browsing - searching, navigating, and working through the things they'd come online to do. The value of the AI assistant came through in how it helped them make progress on those tasks.

We saw the same idea in feedback from beta users. One described using Smart Window to keep track of their "train of thought." Another used it to find something they'd looked at before without remembering exactly where they'd seen it.

Those learnings helped us shape Smart Window into a broader browsing experience that helps people make progress on what they came online to do.

While the product is evolving, the principles we started with remain the same: choice, privacy, and transparency. Smart Window is optional. You choose when to use it, what browsing context it can use to help with a task, and which AI model you want to use. Firefox's AI Controls gives you one place to manage Smart Window, including turning it off entirely, so you can easily choose the browsing experience you want.

What's next

We're continuing to explore ways Smart Window can help carry a task forward, especially when you leave it and come back later.

Soon, Smart Window will be able to surface recent browsing journeys and pull together related tabs and history, giving you a starting point when you return to something you were working on. We're also working on ways for Smart Window to use relevant information to help fill out online forms, so you don't have to re-enter the same details again and again. You'll stay in control of what Smart Window can access, including which tabs you choose to share with it.

Smart Window remains in beta, and we'll keep learning from our community as these experiences develop. It's currently available in English to people in the U.S. and Canada. If it's not available where you are yet, you can sign up to be notified when it is.

To try Smart Window, visit https://www.firefox.com/smart-window.

The post Smart Window: Finish what you start online appeared first on The Mozilla Blog.

18 Aug 2026 1:06pm GMT

AI has changed how we browse. Full stop. The real question is whether AI leads to one browser experience for everyone, or gives people more ways to make the browser work for them.

Firefox was always built to give users an alternative to the status quo, and our approach with AI is no different. Much of the industry is going in another direction: Company A builds the browser → and the search engine → and the AI model → and all the surrounding services. The seduction lies in how effortless every layer feels, but it also means one company has total influence over what tech you can use and what AI delivers.

We aim to deliver users a different model: one where AI makes your browser empowering and helpful, with visible citations and with a zero-data-retention commitment, all powered by an independent browser engine. To get there, we're partnering with people who align with the same open, choice-first thinking that's shaped Firefox from day one.

Today, that starts with Exa.ai, a search and retrieval company built for the AI era.

Going forward, Exa will help power Smart Window on desktop and Quick Answers on iOS, giving people a way to get current, source-backed answers without leaving the page. More on our related Smart Window announcement here.

But our Exa news isn't about one feature or product. It's about model choice and how people find things online.

An independent AI model

Mozilla has always believed the web is strongest when it encourages technology competition and variety, and we think the same principle should apply to AI. We want to create an AI ecosystem that is open, diverse, and grounded in the same values we champion for the web. So, instead of building our own closed AI stack, Firefox is investing in partnerships with companies like Exa.ai to bring deep expertise in specific areas while sharing our commitment to user choice, privacy, and transparency.

As Ajit Varma, Head of Firefox, puts it, "Firefox's philosophy is straightforward: the open internet is a critical resource and people should be able to shape it to their needs and preferences - even as new entry points like AI emerge. AI should be responsible. It should stay transparent and under your control. AI shouldn't be an-all-or nothing offering, but rather built so users can pick and choose the model or system that works for them."

The idea is simple: Mozilla builds the browser people trust, and partners like Exa.ai bring the specialized pieces that make it better. That lets us move faster without asking people to give up what made Firefox different in the first place.

Adds Will Bryk, Co-founder and CEO of Exa.ai, "Search built for the AI era doesn't work if it's locked inside one company's stack. Firefox is one of the last browsers that isn't trying to own the model, the search, and the browser all at once. That's why this partnership makes sense to us. We're building the information layer for an agentic web, where trust and transparency are paramount. We share those values with Firefox, making this partnership a very easy call."

AI should make the web more useful, not replace it

AI is only as useful as your ability to check its work.

That's the point of building Exa's retrieval into Firefox: when you get an answer, you can see the source it came from. Nothing is buried in a 'citations' menu, but sitting right there so a two-second glance tells you whether to trust it or read more. We're not forcing you 'just trust us' that it's right.

It's a small design choice, but it matters. It's the difference between an AI that tells you things and one that shows you where to look. It also means the people who actually wrote that content don't disappear from the picture, the way they often do when AI summarizes and moves on.

Looking ahead

This won't be the last partnership like it. We're picking partners for the same reason each time: people who think AI in a browser should work for you, not the other way around.

The post Firefox and Exa: Building AI search around people, not platforms appeared first on The Mozilla Blog.

18 Aug 2026 1:05pm GMT

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

Firefox 154, one WebDriver bug was fixed by a contributor:

Devin Rousso updated the emulation.setLocaleOverride command to allow overriding the Accept-Language header for fetch and WebSocket requests in workers.

WebDriver code is written in JavaScript, Python, and Rust, so any web developer can contribute! Read how to set up the work environment and check the list of mentored issues for Marionette or the list of mentored JavaScript bugs for WebDriver BiDi. Join our chatroom if you need any help to get started!

All Changes

A complete list of developer-facing changes included in this Firefox release is available in the MDN Firefox 154 Release Notes.

18 Aug 2026 10:00am GMT

Bugs resolved in Moz-Phab 2.16.1:

bug 2063077 Run tests in parallel with pytest-xdist
bug 2063810 Obscure error installing MozPhab

Bugs resolved in Moz-Phab 2.16.0:

bug 2050987 moz-phab self-update fails when installed via uv tool: "No module named pip"

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

1 post - 1 participant

Read full topic

18 Aug 2026 3:18am GMT

A bug comes in, or someone shows me a page doing something surprising, and the question is always the same one. Is that what the spec says? Not what we all assume it says, and not what Gecko happens to do, but what the algorithm actually does when you follow it step by step. So I open html.spec.whatwg.org, find the entry point, and start reading. Twenty tabs later I have usually lost the thread.

This isn't an occasional chore. I do it when I'm implementing something new, when I'm working out whether a Gecko bug is a bug in Gecko or a bug in the spec, when I'm reviewing a spec change someone else has proposed, and when I'm trying to design something that has to fit alongside everything that already exists. Four fairly different jobs, and every one of them comes down to the same mechanical work. Start at an algorithm, follow the calls, keep track of where you've been.

The specs are built for exactly this, in principle. Every step that invokes another algorithm is a hyperlink, and the whole thing is one large call graph spread across HTML, DOM, Fetch, URL and Infra. The trouble is that walking that graph by hand is slow, and it's the kind of slow a machine should be doing on your behalf.

Two tools have changed how I do this. One answers questions about the graph, and the other helps me walk it. If you'd rather install them first and read afterwards, they're both at the end.

webspec-index trace

webspec-index is Jan Jaeschke's tool for querying web specifications from the command line. It indexes the specs, on demand as it needs them, and lets you ask about definitions, references and IDL. In August it gained a trace subcommand, and that's the one I keep reaching for.

You give it two anchors and it finds the routes between them. It answers in JSON by default, which is the right choice for feeding it into something else but not for reading, so add --format markdown when the audience is you. Say I want to know how a navigation can end up firing navigateerror:

$ webspec-index trace HTML#navigate HTML#event-navigateerror \
    --format markdown

# trace: `HTML#navigate` -> `HTML#event-navigateerror`

Max depth 6, kind `step`. Found 11 trace(s).

## Trace 1 (5 hop(s))

1) [`HTML#navigate` step 20](…#beginning-navigation:set-the-ongoing-navigation)
   calls `HTML#set-the-ongoing-navigation`
   > Set the ongoing navigation for navigable to navigationId.

2) [`HTML#set-the-ongoing-navigation` step 2](…#aborting-navigation:inform-the-…)
   calls `HTML#inform-the-navigation-api-about-aborting-navigation`
   > Inform the navigation API about aborting navigation given navigable.

3) [`HTML#inform-the-navigation-api-…` step 3.1](…#ongoing-navigation-tracking:…)
   calls `HTML#abort-the-ongoing-navigation`
   - under: While navigation's ongoing navigate event is not null:
   > Abort the ongoing navigation given navigation.

4) [`HTML#abort-the-ongoing-navigation` step 7](…#ongoing-navigation-tracking:…)
   calls `HTML#abort-a-navigateevent`
   > Abort event given error.

5) `HTML#abort-a-navigateevent` step 6 calls `HTML#event-navigateerror`
   > Fire an event named navigateerror at navigation using ErrorEvent, with
     additional attributes initialized according to errorInfo.

I've wrapped those lines and shortened the URLs to fit; in the real output each hop is one long line and every link is a full deep link to that exact call site.

Every hop names the exact step number, quotes the step text, and tells you the condition it sits under. That last part matters more than it looks. Step 3.1 only runs while the ongoing navigate event is non-null, and knowing that is the difference between a path that exists on paper and a path your case actually took.

Eleven routes, though¹. Reading eleven of these back to back is not much better than the twenty tabs.

Three zoom levels

This is where webspec-index trace gets genuinely nice, and it's the part I want to draw attention to, because it's easy to miss in the help text. The --detail flag changes how much of each route you get, and the three levels turn out to be three different ways of working rather than just three verbosity settings.

Ask the same question again with --detail edges and the prose falls away, leaving the skeleton:

$ webspec-index trace HTML#navigate HTML#event-navigateerror \
    --detail edges --format markdown

# trace: `HTML#navigate` -> `HTML#event-navigateerror`

Max depth 6, kind `step`. Found 11 trace(s).

## Trace 1 (5 hop(s))

1) `HTML#navigate` step 20 calls `HTML#set-the-ongoing-navigation`

2) `HTML#set-the-ongoing-navigation` step 2 calls `HTML#inform-the-navigation-api-about-aborting-navigation`

3) `HTML#inform-the-navigation-api-about-aborting-navigation` step 3.1 calls `HTML#abort-the-ongoing-navigation`

4) `HTML#abort-the-ongoing-navigation` step 7 calls `HTML#abort-a-navigateevent`

5) `HTML#abort-a-navigateevent` step 6 calls `HTML#event-navigateerror`

## Trace 2 (5 hop(s))

1) `HTML#navigate` step 22.4 calls `HTML#fire-a-push/replace/reload-navigate-event`

2) `HTML#fire-a-push/replace/reload-navigate-event` step 2 calls `HTML#inform-the-navigation-api-about-aborting-navigation`

...

Now you can read all eleven at once, and a shape appears that I could not see in the verbose output at all. There are five places inside navigate where a route starts:

step	calls
15.1	`#navigate-fragid`
20	`#set-the-ongoing-navigation`
21.1	`#navigate-to-a-javascript:-url`
22.4	`#fire-a-push/replace/reload-navigate-event`
24.1	`#checking-if-unloading-is-canceled`

And all eleven finish on the same line:

`HTML#abort-a-navigateevent` step 6 calls `HTML#event-navigateerror`

There are exactly two ways into that step, from HTML#abort-the-ongoing-navigation step 7 and from HTML#process-navigate-event-handler-failure step 5. Eleven routes exist because three of the five entry points re-enter the same navigate event firing machinery from different directions, not because there are eleven genuinely different things going on.

That's a useful thing to know before you start debugging. If a navigation is firing navigateerror and you want to find out why, you don't instrument eleven places. You instrument the one step they all pass through and work backwards from there.

So the way I use it now is to start at --detail edges to find the shape, then drop back to the default once I know which route I care about and want to read the reasoning. The third level, --detail compact, drops the prose but keeps every anchor as a deep link to the exact call site, which is the form you want when you're pasting a route into a bug report for someone else to follow.

WebSpec Tracer

webspec-index trace answers a specific kind of question, and it's worth being precise about which kind. You have to know both ends. That's fine when you're asking whether one thing can reach another, but a lot of the time I only know where I'm standing. I have a starting point, a bug in front of me, and no idea yet where the algorithm goes.

There's also something webspec-index trace can't do for you in principle. It finds routes through the spec text, statically. It doesn't know which branch your case took, because that depends on what actually happened at runtime, and only you have that information.

So I wrote WebSpec Tracer, a Firefox extension that walks the specs with you rather than ahead of you. You give it a starting anchor and it shows you that algorithm with every linked term highlighted. Click one and it becomes the next hop in the trace, and the panel moves you into it. Click the wrong one and Back undoes it.

The WebSpec Tracer sidebar showing the navigate algorithm, with the linked terms in each step highlighted, next to a GitHub issue form containing the trace so far as markdown

The screenshot is a walk that started at location.assign and has arrived inside navigate. Step 15 is the interesting one. It runs only if four things are all true, that there's no document resource, no response, the URL matches the current entry's URL ignoring fragments, and the fragment is non-null. If all four hold, it navigates to a fragment and returns. Otherwise the algorithm keeps going into the full navigation path below.

No tool can decide that for me. Whether my bug went left or right at step 15 depends on the page and on what the user did. But the extension puts the decision in front of me with the alternatives visible, which is precisely what I was failing to do for myself with twenty tabs open.

The trace builds up in the panel underneath as markdown, with every anchor pointing at the exact call site. That box is a display rather than a text field, so there are buttons for getting the trace out of it. Copy does what you'd expect. Insert is the one I actually use, and it's the reason the extension lives in the sidebar: it writes the markdown straight into whichever field you have focused on the page, so you can have a spec issue open next to the panel and drop the trace into it without going near the clipboard. Reset clears everything and starts over.

The same panel, with the GitHub issue switched to the Preview tab, showing the two hops rendered as linked spec anchors

Switch the issue over to Preview and there are the same two hops, rendered, each one a link into the spec. That's most of the reason I built the thing. Explaining a route through an algorithm in prose is miserable, and the version you retype by hand is always slightly wrong. This way what I hand over is exactly what I walked.

One more thing worth knowing, about the anchors themselves. The starting one has to say which spec it's in, so HTML#dom-location-assign rather than just dom-location-assign, but after that the extension works it out as it goes. Anything that turns up in the trace without a prefix is in the spec you started from, and a prefix appears when the trace crosses a boundary:

The panel showing WebIDL's wait for all algorithm, with a six hop trace whose last line ends in WEBIDL#wait-for-all

That's the same walk carried a few hops further. Hop 3 is that step 15 decision, taken, and the last line is WEBIDL#wait-for-all. Somewhere in the navigate event firing the trace left HTML entirely, and the prefix is the only thing that tells me so. The panel on the left has stopped showing me HTML too, and is now sitting in WebIDL. That's easy to lose track of when you're clicking through by hand, and it's usually the moment a question stops being about HTML and starts being about something else.

When one call happens twelve times

Sometimes an algorithm invokes another one from many different places, and a trace has to say something sensible about that. This was in the design from the start, and the answer it arrived at is to do what the spec already does. Start at HTML#update-the-image-data and follow it to HTML#abort-the-image-request:

The panel showing the abort the image request algorithm, with a single trace line listing twelve numbered call sites

HTML#abort-the-image-request is invoked from twelve separate places inside HTML#update-the-image-data. The extension doesn't make me choose one, and it doesn't flatten them into a single link either. It records the hop once and hangs all twelve call sites off it as numbered links, so the line reads #update-the-image-data calls #abort-the-image-request, [2], [3] and onwards to [12], each number pointing at its own anchor.

The numbering isn't invented. It's the spec's own scheme for repeated references: the anchors run #abort-the-image-request, then -2, -3, and so on up to -12. All the trace does is carry that through, so a hop in the output identifies call sites the same way the spec identifies them, and the numbers mean the same thing in both places.

That also keeps the trace honest. The hop happened, and that's true whichever of the twelve fired, but the fact that there are twelve is worth knowing on its own, and anyone reading can go and check any one of them. Writing this out by hand you would link the first and lose the other eleven without ever noticing. The same thing is visible in the previous screenshot, where hop 3 reads #navigate calls #navigate-fragid, [2], [3].

webspec-index trace deals with the same situation the other way round. Ask it the same question and you get twelve separate one hop traces, each naming its own step number, step 2, then 7.4.2, then 11.1, and so on down the algorithm. Neither is wrong. The command line is telling you which steps, and the extension is keeping your trace to one line while preserving every place it could have come from.

Which one, when

They divide up cleanly enough that I don't think about it much any more. If I know both ends and want to know what's between them, or how many different routes there are, that's webspec-index trace. If I know where I'm starting and want to find out where it goes, that's the extension.

The one I underused at first was --detail edges. Asking a broad question and then zooming out far enough to see the answer's shape is a different move from following a single path carefully, and it's the one that has surprised me most often, usually by showing me that several things I thought were separate all funnel through the same step.

Getting them

webspec-index is on crates.io:

cargo binstall webspec-index

It builds its index as it goes, so the first trace into a corner you haven't visited before pauses briefly to fetch and index the specs the route touches. After that it's fast.

WebSpec Tracer is on addons.mozilla.org, and the source is on GitHub. It lives in the sidebar, toggled with Ctrl+Shift+U, so you can keep it open next to whatever you're reading.

Both are worth a try if you spend any time at all reading specs, whether you're implementing them, arguing with them, or just trying to find out whether the browser is wrong or you are.

Notes

Eleven is what you get at the default maximum depth of six hops. Raise it and there are more. ↩

17 Aug 2026 12:00am GMT

We have tokens that are added to official builds when a CI server is building the production-ready application. These tokens are added to the BuildConfig.java by using the buildConfigField function in a build.gradle.

While testing, you want to quickly regenerate just this file to see changes occur with a new value. Instead of using the more expensive assembleDebug task for your debug variant, you can use generateDebugBuildConfig.

In the Firefox monorepo world for the Fenix module, the fully-qualified task name would look like this:

./mach gradle :fenix:generateDebugBuildConfig

14 Aug 2026 3:49pm GMT

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.

Welcome!

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

Changes to the localization team

A lot has changed in the team this year. Delphine and Peiying left Mozilla a few months ago, and we're now happy to welcome three new members:

Camila (parker) will focus on our mobile projects (Android and iOS), while also helping with Spanish localization.
Eda (edie) will focus on our web projects (mozilla.org, firefox.com, AMO, etc.), while also helping with Turkish localization.
Eric (ewerybody) will work alongside Eemeli and Matjaž to support and improve our localization infrastructure, including the moz-l10n library that powers several features in Pontoon.

For both Camila and Eda, contributing directly in Pontoon will also be an important part of getting to know our localization community. By working as localizers themselves, they'll experience firsthand the challenges contributors encounter and gain a better understanding of how our communities organize and work together.

In the coming months, we'll publish a series of blog posts to introduce our new team members - and reintroduce some familiar faces, since it's either been a while or we never got around to introducing them when they joined.

What's new or coming up in Firefox desktop

Firefox 155 Beta

Today marks the beginning of the Beta cycle for Firefox 155 and the start of the shift to Firefox's 2-week release cycle. You can find more information on this change and how it affects you in our update here: Firefox Release Changes and Localization.

Themes

A new part of the upcoming Firefox redesign is a number of built-in themes a user can select for their profile. The theme-picker.ftl strings are landing in Firefox 155 and include a number of theme names which are short, evocative names in English. We have generated a reference document to help with creating localized names in your languages, it includes both testing instructions and screenshots.

What's new or coming up in SUMO

We would love more helping hands to bring the following locales across the finish line:

Spanish - 48% remaining
Japanese - 19% remaining
Portuguese (Brazil) - 11% remaining
Portuguese (Portugal) - 17% remaining

If you're a contributor in one of these locales, now is a great time to jump in. Every translated string brings us one step closer to shipping a better experience for users around the world!

What's new or coming up in Pontoon

Editor theme. The translation editor can now follow your theme choice. You can set the editor theme independently of the main interface - Light, Dark, or Main to match the rest of Pontoon. The change comes from Ayush (ayshushus), who is interning with the L10n team and wrote about the work on this blog back in July.

Copy from another locale. A new batch action lets you copy translations from another locale into the strings you've selected. It's especially handy for closely related languages, or for locales that share terminology and want to bootstrap from an existing translation as a starting point. The feature was contributed by Serah (MundiaNderi), a volunteer contributor who wrote about her work on Pontoon earlier this year.

Copy from another locale

Community health. Teams can now follow their Community Health Score over time in a new chart on the team Insights tab, alongside the existing activity charts. The L10n team also gets a cross‑locale overview to spot communities that may need support. The dashboard was built by Jamie (functionzz), who is interning with the L10n team. See his previous blog post on translation search unification.

Composed Machinery suggestions. Fluent messages with attributes or selectors used to require copying each field separately, one match at a time. Machinery now offers a single suggestion that covers the entire message: every field is filled from a perfect translation memory match, falling back to machine translation, and one click copies all of them into the editor at once.

Composed Machinery suggestions

Automatic LLM suggestions. Until now, getting an LLM suggestion meant opening the AI menu on a machine translation result and picking an option. The suggestion is now generated automatically and shown as its own entry in the Machinery panel. We're starting with a limited rollout - signed‑in users, strings without an approved translation, and a small set of locales - so we can evaluate quality and cost before expanding. The AI menu keeps working as before, in every locale.

Other improvements. A number of more focused changes also landed, thanks to our contributors:

Notifications about new strings now link only to the strings that were actually added, instead of the full resource - by flodolo (#4185).
A year selector was added to the chart on profile pages - by flodolo (#4205).
The list of translations on a Search page is now more compact and easier to scan - by functionzz (#4157).
Search boxes now look and behave consistently across the entire app - by MundiaNderi (#4301).
A clear "String not found" page is now shown when the active filters don't match the string you're opening - by ayshushus (#4281).
Profile images from Mozilla accounts are now supported - by wassafshahzad (#4215).
String counts in the translate interface are now formatted using your locale's own conventions instead of a hardcoded en‑GB - by ewerybody (#4127).

New contributors. We're happy to welcome another group of contributors who made their first patches to Pontoon in the past few months: Kasturijadhav14 (6 patches), eshu3104 (2), jbuck, troypsierrallc-dot, msranjana, and denyshon. Their work spans notifications, contributor profiles, documentation, UI polish, the API, and infrastructure - thank you all!

Friends of the Lion

Image by Elio Qoshi

Know someone in your l10n community who's been doing a great job and should appear here? Contact us and we'll make sure they get a shout-out!

Useful Links

Questions? Want to get involved?

If you want to get involved, or have any question about l10n, reach out to:

Bryan - Project Manager (Firefox, Mozilla Accounts)
Camila - Project Manager (Firefox for Android, Firefox for iOS)
Eda - Project Manager (Web projects)
Francesco (flod) - Project Manager, L10n Team Manager
Francis - Project Manager (Common Voice, Mozilla Foundation)
Théo - Project Manager (Mozilla Foundation)
Kiki - Project Manager (SUMO)
Eemeli - Developer (Pontoon, Infrastructure)
Eric - Developer (Pontoon, Infrastructure)
Matjaž (mathjazz) - Developer (Pontoon)

Did you enjoy reading this report? Let us know how we can improve it.

13 Aug 2026 8:38pm GMT

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

Call for testing: Restricting trait implementability and field mutability

Foundation

Newsletters

This Month in Rust OSDev: July 2026

Project/Tooling Updates

We are making changes to the Project/Tooling Updates Section - see here for more details

Observations/Thoughts

Rust Walkthroughs

Research

Rust Coreutils: Rebuilding Unix Foundations in a Modern Language

Miscellaneous

Crate of the Week

This week's crate is literator, a crate for efficiently displaying the items of an iterator without temporary allocations.

Thanks to Nora for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

698 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

This week so many new performance improvements landed that we needed to roll 10 of them up together to keep the bors queue manageable, great work! Also new is the LLVM 23 update which caused massive compile-time, run-time, bootstrap time and artifact size improvements. These improvements are reduced by the merge of Polonius Alpha on nightly causing a 3.0% regression. There still seems to be some potential to mitigate this regression.

Triage done by @JonathanBrouwer. Revision range: 65dd30fb..771916f9

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	4.6%	[0.2%, 12.8%]	24
Regressions ❌ (secondary)	4.3%	[0.2%, 14.3%]	30
Improvements ✅ (primary)	-3.3%	[-16.4%, -0.2%]	251
Improvements ✅ (secondary)	-5.2%	[-34.8%, -0.2%]	308
All ❌✅ (primary)	-2.6%	[-16.4%, 12.8%]	275

1 Regression, 4 Improvements, 7 Mixed; 5 of them in rollups 25 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Compiler Team (MCPs only)

Leadership Council

No Items entered Final Comment Period this week for Rust RFCs, Language Reference, Cargo, 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.

New and Updated RFCs

RFC: Support External Linkers

Upcoming Events

Rusty Events between 2026-08-12 - 2026-09-09 🦀

Virtual

2026-08-13 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-08-13 | Virtual (Nürnberg, DE) | Rust Nuremberg
- Rust Nürnberg online
2026-08-14 | Virtual (Girona, ES) | Rust Girona
- Sessió setmanal de codificació / Weekly coding session
2026-08-16 | Virtual (Bangalore, IN) | Embedded Rust
- Silicon Sundays #2
2026-08-18 | Virtual (Washington, DC, US) | Rust DC
- Mid-month Rustful
2026-08-19 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Dealing with Dependencies
2026-08-20 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- August, 2026 SRUG (Seattle Rust User Group) Meetup
2026-08-20 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
- Tock OS Part #5 - Wireless Communication with the IEEE 802.15.4 protocol
2026-08-21 | Virtual (Girona, ES) | Rust Girona
- Sessió setmanal de codificació / Weekly coding session
2026-08-25 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Fourth Tuesday
2026-08-27 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-08-28 | Virtual (Girona, ES) | Rust Girona
- Sessió setmanal de codificació / Weekly coding session
2026-08-31 | Virtual (Global) | Rust Maven
- Workshop: Add tests to an open source Rust project
2026-09-01 | Virtual (Global) | Rust Maven
- Tauri: Cross-Platform desktop applications with Rust and web technologies
2026-09-02 | Virtual (Indianapolis, IN, US) | Indy Rust
- Indy.rs - with Social Distancing
2026-09-04 | Virtual (Girona, ES) | Rust Girona
- Sessió setmanal de codificació / Weekly coding session
2026-09-08 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Second Tuesday
2026-09-08 | Virtual (London, UK) | Women in Rust
- 👋 Community Catch Up

Africa

2026-09-08 | Johannesburg, ZA | Johannesburg Rust Meetup
- Rust's extended standard library

Asia

2026-08-22 | Bangalore, IN | Rust Bangalore
- August 2026 Rustacean Meetup
2026-08-22 | Delhi, IN | Rust Delhi
- Rust Delhi X SciPy India Meetup
2026-08-22 | Noida, IN | SciPy India
- Scientific Computing in Rust and Python
2026-08-29 | Pune, IN | Rust Pune
- Rust Pune Meetup: August 2026

Europe

2026-08-13 | Switzerland, CH | PostTenebrasLab
- Rust Meetup Geneva
2026-08-18 | Aarhus, DK | Rust Aarhus
- Hack Night: Trust but verify the LLM
2026-08-18 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
- Topic TBD
2026-08-20 | Frankfurt, DE | Rust Rhein-Main
- Building an acoustic camera with egui and embassy
2026-08-27 | Manchester, UK | Rust Manchester
- Rust Manchester August Talks

North America

2026-08-13 | Lehi, UT, US | Utah Rust
- Utah Rust August Meetup
2026-08-13 | San Diego, CA, US | San Diego Rust
- San Diego Rust August Meetup - Back in person!
2026-08-15 | San Francisco, CA, US | Flower
- BOG-A-THON 3
2026-08-18 | San Francisco, CA, US | San Francisco Rust Study Group
- Rust Hacking in Person
2026-08-19 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- Dealing with Dependencies
2026-08-19 | San Francisco, CA, US | Bay Area Rust
- Bay Area Rust August Meetup
2026-08-20 | Mountain View, CA, US | Hacker Dojo
- RUST MEETUP at HACKER DOJO
2026-08-20 | New York, NY, US | Rust NYC
- Rust NYC: 'Data Shapes Your Memory' and 'Rust in Peace'
2026-08-20 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- August, 2026 SRUG (Seattle Rust User Group) Meetup
2026-08-26 | Austin, TX, US | Rust ATX
- Rust Lunch - Fareground
2026-08-26 | Los Angeles, CA, US | Rust Los Angeles
- Rust LA August! Rust in Quantum Computing
2026-08-27 | Atlanta, GA, US | Rust Atlanta
- Rust-Atl
2026-09-03 | Saint Louis, MO, US | STL Rust
- Cryptography + Quantum Computers
2026-09-08 | Montreal, QC, CA | Rust Foundation
- Rust Teams Health Summit
2026-09-08 - 2026-09-11 | Montreal, QC, CA | RustConf 2026
- RustConf 2026, Hosted by the Rust Foundation
2026-09-09 | Montreal, QC, CA | Women in Rust
- RustConf Coffee Break Meetup

Oceania

2026-08-27 | Melbourne, AU | Rust Melbourne
- Rust Melbourne Meetup

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

The AI discussion was already put to bed as off topic and derailing. Do not summon the Mods so carelessly, as they are wroth, and filled with cruel vengeance.

- Simon Buchan on rust-users

Thanks to Jonas Fassbender for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

12 Aug 2026 4:00am GMT

Hello, Thunderbird community and followers of the blog! This is Jesse from the design team. Today's post is about our recent journey in redesigning the calendar portion of Thunderbird, and what you can expect us to deliver in the near future.

The calendar is a key part of any productivity toolset, from your PC Desktop to your office wall. There has been a calendar in Thunderbird since early in the project, and like all parts of the application, it's evolved on its own terms, for better or for worse. It has many layers of functionality, but the experience has lost parity with current UI standards - at this point, it feels stylistically dated and functionally convoluted.

So, with the help of the design team and the developers and the community, we have taken on the task of modernizing and streamlining the calendar. This is my account of the designers' part of that journey.

The Big Picture

Here are some of our guiding principles for this redesign:

First, we are here to serve the entire user base, not just the technical experts, or the productivity enthusiasts, or the brand new adoptees. For this reason, the dialog with the community is critical: we need to understand as many of the use cases and interaction patterns as possible, and we want to support them broadly, and efficiently, and effectively. Our ideal solution is open and flexible, respecting the broad range of users who rely on Thunderbird.

Second, a key point: Thunderbird is aiming higher than being simply "the other email client." We are all committed to creating an experience that meets and exceeds expectations, and competes directly with the oliphaunts in the room: the Google Calendars, the Apple and Microsoft application suites, and the many targeted productivity apps that jockey for this space.

And as always, we will do this transparently, with an open source philosophy, in collaboration with our users and contributors.

The Journey

This design journey has been ramping up for several years now, in parallel with other company initiatives (Mobile! Web! Accessibility!). As our design practice has evolved, we have worked on the project from several directions, redesigning dialogs and rethinking patterns and collecting insights. For a while, this meant a lot of partial designs, but without a guiding vision.

Among these early designs, one of our success stories was a visual and functional update of the Event Details dialog, to replace the existing, rather archaic event details window ("archaic" both visually and in terms of code). These were one of the first redesigns to reach a point where it could be implemented - prioritized partly because it's a self-contained element, able to be tested without reworking the whole calendar code base.

If you use Thunderbird Daily, you may recognize this:

We've followed this pattern for several other bits and bobs, including the dialog for editing an event, and the notification for unanswered invitations. In all cases, these changes will create better contrast and visual hierarchy, and improve the visibility and organization of controls:

This alone could provide enough work for several release cycles. But designing isolated elements creates inconsistency and debt, both for design and development. As the design process on Calendar increased in velocity, it became clear that we needed to articulate a unifying vision.

Bringing it together

With these designs setting a direction, we had to step back and decide how all the pieces would fit together. In order to do that, we still had to answer three more questions:

How does the actual calendar grid look, set to view a day, a week, a month, or a year?
How does the user change their view and navigate forward and backward?
How does the user connect to their calendars, and manage them all in one place?

These considerations led us to a lean design, with screen space broken up into three main sections. First is the grid, which provides the main element at the center of the layout - the user's primary workspace. Second is the navigation bar, directly above the grid. Third is a sidebar for managing calendars - the nerve center for your calendars and data sources. This design, focused on the most important functional areas, provided a great foundation for all the necessary functionality, with low friction and strong fundamentals.

The blueprint for our design (called a "wireframe" in the UX design world) ended up looking like this:

The grid acts as the user's main workspace, and the header and navigation provide their basic controls.

Here is a final design mock-up, which will provide the basis for development (this one is showing a week view in the main grid):

Given the wide range of our users' scheduling needs, we decided the calendar sidebar should be collapsible, and useful at both large and small sizes, so that users could decide how much of a footprint they needed to manage their calendar list.Here is the screen with the sidebar in a collapsed state, showing a Month view in the main grid:

And here is this screen after the user has pressed "New Event," showing the Create Event window over the interface:

Where we go from here

As these elements came together, we also turned outward and looked to our community for more feedback. Through the various stages of design, we published two TopicBox posts (here and here), and we ran a short but informative survey, looking for initial reactions to the direction we were taking.

This feedback has been very encouraging, and also enlightening: we have seen a positive response to our designs, and we've also gathered lots of insights on what you cite as most important (task integration, platform interoperability, and a re-assessment of agenda, mini-month, and multi-week views, to name a few).

These discussions gave us some additional confidence, but more so, they reminded us that we are still at the beginning of a longer arc. After we develop version 1 of our new calendar design, we will follow signals from our users as we plot a path forward. The new calendar design will clean up and simplify many aspects of the experience, but it will only be a promising first step (sort of the Rivendell stage of the epic). We will have many more cycles of design and iteration to bring our users the toolset they deserve.

For now, we venture forth, from design to implementation, and then from implementation to feedback and engagement. The new calendar will be released gradually, via proper channels, so users can try it and provide feedback - and feedback will be appreciated! We will be looking for usability testers and survey participants as we keep refining the roadmap.

The future of calendar is wide open, and much brighter and less gray than the bygone era. We appreciate all the support we've gotten from the community so far, and we hope you'll continue with us as we keep making Thunderbird awesome.

The post Desktop Calendar: A Design Journey appeared first on The Thunderbird Blog.

10 Aug 2026 6:59pm GMT

fidzu : Mozilla

19 Aug 2026

Why this is happening

What it means for SUMO

How we're preparing and how you can help

Looking after each other

18 Aug 2026

Gaming: one of the web's toughest tests

Versatility and customization baked into your gaming rig

Try it today

Why Europe first

What Startpage delivers

Users asked with one billion searches

Search is a choice. Firefox treats it like one.

Try it out

What's new in Smart Window

Check answers without losing your place

Group tabs that belong together

Find your spot again

Behind the evolution

What's next

An independent AI model

AI should make the web more useful, not replace it

Looking ahead

Contributions

All Changes

17 Aug 2026

webspec-index trace

Three zoom levels

WebSpec Tracer

When one call happens twelve times

Which one, when

Getting them

Notes

14 Aug 2026

13 Aug 2026

Welcome!

Changes to the localization team

What's new or coming up in Firefox desktop

Firefox 155 Beta

Themes

What's new or coming up in SUMO

What's new or coming up in Pontoon

Friends of the Lion

Useful Links

Questions? Want to get involved?

12 Aug 2026

10 Aug 2026

The Big Picture

The Journey

Bringing it together

Where we go from here

fidzu channels