09 Jul 2026

feedPlanet Mozilla

Firefox Tooling Announcements: Engineering Effectiveness Newsletter (Q2 2026 Edition)

Welcome to the Q2 edition of the Engineering Effectiveness Newsletter! The Engineering Effectiveness org makes it easy to develop, test and release Mozilla software at scale. See below for some highlights, then read on for more detailed info!

Highlights

image

Detailed Project Updates

AI for Development

image

Bugzilla image

Build System and Mach Environment

image

Firefox-CI

image

Lint, Static Analysis and Code Coverage

image

Mozregression

image

PDF.js

image

Phabricator image, moz-phab, and Lando

image

Release Management and Engineering

image

Release Operations :wrench:

Taskcluster image

Treeherder image

Version Control

image

Other

image

Thanks for reading and see you next quarter!

1 post - 1 participant

Read full topic

09 Jul 2026 4:26pm GMT

Firefox Tooling Announcements: Firefox Profiler Deployment (July 9, 2026)

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what's changed:

Highlights:

Other Changes:

Big thanks to our amazing localizers for making this release possible:

Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel!

1 post - 1 participant

Read full topic

09 Jul 2026 1:58pm GMT

The Rust Programming Language Blog: Announcing Rust 1.97.0

The Rust team is happy to announce a new version of Rust, 1.97.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.97.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.97.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.97.0 stable

Symbol mangling v0 enabled by default

When Rust is compiled into object files and binaries, each item (functions, statics, etc) must have a globally unique "symbol" identifying it. To avoid conflicts when linking together different Rust programs, Rust mangles the original name of items to include additional context such as the module path, defining crate, generics, and more. Historically, this mangling was based on the Itanium ABI, also (sometimes) used by C++.

The new mangling scheme resolves a number of drawbacks from the previous one:

Since Rust 1.59, the compiler has supported opting into a Rust-specific mangling scheme via -Csymbol-mangling-version=v0. Since November 2025, this scheme has been enabled by default on nightly, and 1.97 is now enabling it on stable Rust. The legacy mangling scheme can only be enabled on nightly, and the current plan is to fully remove it.

See the previous blog post for more details.

Cargo support for denying warnings

It's common practice to deny warnings in CI. Historically, doing so is typically done through RUSTFLAGS=-Dwarnings. With Rust 1.97, Cargo controls how warnings interact with build success: either silencing them (via allow level), rendering without failing (default, warn), or denying them (via deny).

As a result of Cargo configuration determining the behavior, using this feature doesn't invalidate the underlying build cache, meaning that it's easy to temporarily opt-in. For example, if warnings are adding unwanted noise while working through fixing errors after a refactor, you can run CARGO_BUILD_WARNINGS=allow cargo check, temporarily silencing them.

In CI, jobs can instead set CARGO_BUILD_WARNINGS=deny to deny warnings. This can be combined with --keep-going to collect all errors and warnings rather than stopping on the first failing package.

See the documentation for more details.

Linker output no longer hidden by default

rustc invokes a linker on behalf of users. Historically, rustc has silenced linker output by default if the link completes successfully. This can mask real problems, though, so in Rust 1.97 we are enabling linker messages by default. These are emitted as a warning lint, for example:

warning: linker stderr: ignoring deprecated linker optimization setting '1'
  |
  = note: `#[warn(linker_messages)]` on by default

Common linker messages that have been diagnosed as false positives or intentional behavior are filtered out by rustc. Several defects have already been fixed as a result of no longer hiding this output on nightly.

Note that currently, linker_messages is a special lint that is not affected by the warnings lint group. This is intentional as rustc generally doesn't control linker output as precisely, and it's not uncommon for output to only appear on some platforms. If you are seeing what you think is a false positive output from the linker, please file an issue.

To silence the warning in the mean time, you can configure the lint level to allow. This can be done through Cargo.toml by adding a lints section like this:

[lints.rust]
linker_messages = "allow"

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.97.0

Many people came together to create Rust 1.97.0. We couldn't have done it without all of you. Thanks!

09 Jul 2026 12:00am GMT

08 Jul 2026

feedPlanet Mozilla

The Mozilla Blog: Wrexham AFC and Firefox announce a multi-year, front-of-kit partnership

Wrexham AFC crest beside the Firefox logo on a purple background

We don't put our name on much. So when we do, it means something.

Starting with the 2026/27 season, Firefox is Wrexham AFC's Official Web Browser Partner and front-of-kit sponsor on the men's and women's teams.

More than 160 years old and nearly lost for good, the football club was saved by the community that loved it and has been climbing ever since. Wrexham AFC built something real by doing things their own way and staying close to the community that carries them.

That's a story we recognize. Firefox has spent more than 20 years as the browser people choose - not the one they're handed. Backed by a nonprofit, we've never had to answer to shareholders, just to the people who use us. Two challengers, never the default, both here because our communities showed up for us.

Our partnership debuts this weekend on the new away kit, when Wrexham travels to Kraków for their opening pre-season fixture. And this is just the start: Expect content, product integrations and fan moments all season long.

"Both Wrexham AFC and Firefox are challenger brands that built passionate global communities by doing things differently and staying true to who they are," Mozilla CMO John Solomon said. "Firefox has approached the internet with that same philosophy - building it as it should be, with people at the center."

"We are thrilled to welcome Firefox as our new front-of-kit partner," said Rob Mac and Ryan Reynolds, co-chairmen of Wrexham AFC. "We love an underdog story and both Wrexham and Firefox know the feeling of having to battle giants. It takes inventiveness, relentlessness and a pristine browsing history. So let's effing go…"

Football needs Wrexham. The internet needs Firefox.

For more information on our partnership and upcoming 2026/27 season, follow @wrexham_afc on social media. Click here to download the independent browser that puts you first.

About Mozilla and Firefox

Mozilla is a global nonprofit backed technology organization that builds products, invests in startups, and advances policy to keep the internet open, fair, and worthy of trust. Firefox is the independent browser from Mozilla, known for strong tracking protection, open source code, and a focus on user choice, privacy and security.

About Wrexham AFC

Wrexham Association Football Club is based in Wrexham, North Wales, and after an historic, record-breaking three consecutive promotions are competing in the EFL Championship, the second tier of the English football league pyramid. Formed in 1864, they are the oldest Club in Wales and the third oldest professional team in the world. Wrexham have won the Welsh Cup a record 23 times and beaten some of the biggest clubs in the game in the English FA Cup and UEFA European Cup Winners Cup. The Racecourse Ground, home to Wrexham AFC, is the world's oldest international stadium that continues to host international games.

Wrexham AFC is owned by Rob Mac and Ryan Reynolds. The goal of the owners is to grow the team and establish Wrexham AFC as a Premier League club in front of increased attendances, and in an improved stadium, while making a positive difference to the wider community in Wrexham. For more information, please visit wrexhamafc.co.uk or follow @wrexham_afc.

The Firefox logo

Take control of your internet

Download Firefox

The post Wrexham AFC and Firefox announce a multi-year, front-of-kit partnership appeared first on The Mozilla Blog.

08 Jul 2026 1:00pm GMT

This Week In Rust: This Week in Rust 659

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
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs
Miscellaneous

Crate of the Week

This week's crate is apis-saltans, a Zigbee implementation including a coordinator API.

Thanks to Richard Neumann 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.

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.

* Protocol - Extend bit-exactness tests to f64 reconstruction targets
* Dofigen - No image tag replacement flag for the generate command

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

598 pull requests were merged in the last week

Compiler
Library
Cargo
Rustdoc
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

This week was dominated by wild swings in benchmarks of the new-solver, which is not enabled by default, yet. Apart from that, we got a very few notable changes, only one unexpected speedup from a bugfix in rustdoc.

Triage done by @panstromek. Revision range: 7dc2c162..3659db0d

Summary:

(instructions:u) mean range count
Regressions ❌
(primary)		 0.2% [0.2%, 0.2%] 3
Regressions ❌
(secondary)		 162.1% [0.2%, 1116.3%] 20
Improvements ✅
(primary)		 -1.4% [-8.4%, -0.1%] 7
Improvements ✅
(secondary)		 -1.1% [-8.4%, -0.1%] 11
All ❌✅ (primary) -0.9% [-8.4%, 0.2%] 10

1 Regression, 1 Improvement, 4 Mixed; 3 of them in rollups 17 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)

Language Reference

No Items entered Final Comment Period this week for Cargo, Language Team, Leadership Council, Rust RFCs or Unsafe Code Guidelines.

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-07-08 - 2026-08-05 🦀

Virtual
Asia
Africa:
Europe
North America
Oceania

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

if a ptr is dereferenced in a forest and nobody hears it, is it sound?

- Kornel on rust-users

Thanks to Cerber-Ursi 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

08 Jul 2026 4:00am GMT

07 Jul 2026

feedPlanet Mozilla

Thunderbird Blog: Desktop settings research: what we learned from your feedback

Black square with typography that says "Desktop Settings: User research, July 2026" with the Thunderbird Logo at the bottom.

A few weeks ago, we conducted hour-long conversations with 10 of our users to dig deep into how you manage your preferences and configurations in Thunderbird desktop. While this specific research cycle focused on the desktop experience, our ultimate goal is a holistic strategy that ensures our mobile settings feel like a natural extension of your workspace.

Here is a quick look at what we discovered, what you valued, and how your feedback is actively shaping our design roadmap.

"Key themes" is written along the top of the graphic with 6 boxes under, noting each theme: trust, reduce the clutter, settings are setup once, hard to navigate, users manage their inbox like a to-do list/workflow, and configuring settings is confusing and time consuming.

What you told us

You are incredibly passionate about customization, and appreciate Thunderbird's robust functionality. Overall, a common thread that stood out was that most of you want to set up your space once and then make small tweaks to your preferences, you want it to look modern, and navigate effortlessly without running into issues with technical jargon.

Here are the key themes that emerged from our conversations:

"Recommendations" is written along the top of the graphic with 6 boxes under, noting each theme: Demystify advanced settings, grouping one-time configurations, surface quick controls, group tasks, explain security and privacy practices, and pair with modern UI.

Improvements we want to make

We don't want to just make minor fixes, we want to design a better workflow. Based on your feedback, here are the core design actions that will be driving our next phase focusing on general and account settings:

What's next?

We are hitting the ground running with these insights. Right now, our team is actively:

  1. Finalizing our project scope to directly incorporate these research findings.
  2. Mapping out and proposing a streamlined information architecture for settings.
  3. Designing this layout holistically so that desktop preferences and mobile configurations

A massive thank you to everyone who offered their time and feedback for this study! We look forward to sharing more with you soon.

Let us know your thoughts in the comments below!

The post Desktop settings research: what we learned from your feedback appeared first on The Thunderbird Blog.

07 Jul 2026 6:56pm GMT

06 Jul 2026

feedPlanet Mozilla

Mozilla Localization (L10N): Giving Pontoon’s Editor Its Own Theme

Each year, Mozilla welcomes interns who work alongside our engineering teams on projects that ship to production and improve the experience for contributors around the world. This year, Ayush joined the Firefox Localization team to work on Pontoon, Mozilla's open source localization platform, where he already tackled several user-facing improvements while learning how large-scale open source software is built.

In this post, Ayush shares the story behind one of his first projects: giving Pontoon's translation editor its own appearance settings. From understanding long-standing design decisions to balancing accessibility with user expectations, he walks through both the technical implementation and the product thinking that shaped the feature.

You can follow Ayush's work on GitHub and connect with him on LinkedIn.

Introduction

Studying Computer Engineering with a Professional Experience Year (PEY) at the University of Toronto's Faculty of Applied Science gave me a variety of opportunities and companies to choose spending a year interning at. I chose Software Engineering at Mozilla because it's an open source company that puts people first, which matters to me a lot and allows me to equip my portfolio using snippets and examples from real code used in production.

I joined Mozilla's Firefox Localization (l10n) team as part of Mozilla Corporation's Firefox Desktop Engineering Team, based in Downtown Toronto. I officially began my internship on Friday, May 1, 2026, but I unofficially began in mid February. Since my team's flagship product's (Pontoon) codebase is entirely open source, I talked to both my manager and Pontoon owner right after signing my offer and got early access to our weekly meetings and some confidential data. I then started to learn as much as I possibly could.

Even before I started learning the codebase, just looking at the Pontoon's default translation UI was rather interesting because of our editor pane's glaring white color in dark mode/theme.

Even though I saw the issue (#4001) filed for working on that, I thought that the stark contrast was a stylistic choice because an average user would spend most of their time on said pane editing strings anyway, so I just went on with it.

However, once I officially started to work, I got my onboarding document and saw my starting set of issues. That's where I came across the very same issue (#4001) on my todo batch, which made me very happy since I could address it and I'd already looked at the surrounding context before working with it.

The Original Experience

At first, the user could only change Pontoon's appearance from their `profile menu` or Pontoon's `/settings` page. This is where they have the ability to change their appearance to `dark mode`, `light mode`, or keep the `system theme` that matches their device's preferences.

This is the view from Pontoon's Settings page.

This is the view from Pontoon's Profile menu.

Ironically, the dark appearance warrants a light themed `editor pane`.

There is also no option to change the `editor pane` appearance from the `editor menu`.

Design Considerations

In general, when a product has a large, established user base that has grown accustomed to a particular interface, it's important to approach visual changes with care. Even if a redesign is arguably more visually appealing and offers clear accessibility benefits, changing familiar workflows and appearance can still disrupt the user experience.

In fact, according to this Mozilla Research article I read, which explored browser choice design interventions, "It is important that the organizations tasked with designing and regulating current and future interventions (including browser choice screens) are mindful of the design principles we have articulated with this research."

Even though the relevance of said research is for the browser use-case, the impacts are for a user interface design like in this blog, as the article also mentions "The inertia is a strong force to overcome", and Pontoon's inertia dates back over a decade.

This meant that if we were to change the editor pane color, we would have to allow the user to have things as they currently are.

The New Experience

In the update Appearance section of the Settings page, users have the ability to change the main interface as before, but now have the ability to update editor to `dark mode`, `light mode`, or match their `main interface theme` to automatically sync the colors.

The editor theme remains light by default, regardless of the main interface theme.

This is the view from Pontoon's Settings page.

Editor appearance can also be quickly changed from the editor menu.

This UI now matches the dark theme, either by explicitly selecting it or matching the main interface theme.

Since the issue was with `dark interface mode` having a `light editor`, setting the default `editor` to `light` neatly agreed with how the UI looked before the changes were brought in.

Looking Ahead

These changes neatly allow the user to modify their theme keeping their general preferences in mind. The change is also remembered by Pontoon and stays consistent at every instance the user logs back in.

Furthermore, we now track if the user has interacted with the `editor theme` which gives us knowledge on if we want to eventually change the default editor theme, addressing the concerns of `UI inertia` brought up in Mozilla's research.

For more information and technical details, please visit: https://www.ayshush.us/mozilla/issue-notes/4001

06 Jul 2026 4:13pm GMT

About:Community: A new Firefox look, hidden features, and more

Hi Mozillians, welcome to another Mozilla community roundup!

This month, we're taking a look at what's next for Firefox. From an upcoming visual refresh and a peek behind the new design system to hidden features you may never have used before. We're also highlighting a recent Reddit AMA on the new Firefox product Roadmap and celebrating community contribution that's making collaboration in Pontoon even better.

Let's dive in!

✨ Firefox gets a fresh new look. Soon!

Firefox is evolving with a refreshed design that makes the browser feel more modern, approachable, and consistent across desktop and mobile. The refresh also extends to Firefox's voice and writing style, making product experience feel more human, direct, and unmistakably Firefox. If you're excited about these changes, make sure to keep an eye out for an upcoming foxfooding opportunity later this month!

Learn more

Firefox can do all this?

Sreenath from It's FOSS rounded up 21 Firefox features that many users never discover. From the built-in Eyedropper tool and Picture-in-Picture to vertical tabs and other productivity features, there's plenty to explore. See how many you've already used! We could even turn it into a fun bingo at our next community event.

Read more

From the Reddit Community

Fx roadmap

Firefox leaders recently joined r/firefox for a live AMA to answer questions about the newly launched Firefox Product Roadmap. Community members asked about everything from Android improvements and Containers to Project Nova, PWAs, performance, and future browser development. The conversation generated a wide range of discussions and provided valuable insight into what Firefox users are most excited, and concerned, about.

Read the full AMA

Community spotlight

Collaboration in Pontoon just got a little easier. Thanks to volunteer contributor Serah Nderi, users can now edit and delete their own comments, while project managers can remove comments for moderation purposes. This long-requested feature helps reduce clutter, improve discussions, and makes collaboration smoother for localization teams.

Read more

P.S.

Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.

06 Jul 2026 3:45am GMT

03 Jul 2026

feedPlanet Mozilla

Mozilla Privacy Blog: Mozilla Mornings comes to the UK: privacy-enhancing technologies and the questions they raise

During London Tech Week, Mozilla hosted the first UK edition of Mozilla Mornings, our breakfast-discussion series on the digital questions of the moment. We brought together technologists, policymakers, industry, civil society and researchers to ask how the UK can drive forward responsible innovation in privacy-enhancing technologies (PETs) in ways that protect people, strengthen trust and keep digital markets open.

The role of PETs in building a better internet

Protecting people's privacy has always been central to Mozilla's mission to build a better internet - one where privacy and security are fundamental, people have meaningful control over their data and online lives, and independent actors can compete on a level playing field. Privacy-enhancing technologies (PETs) are an important part of that vision. They help minimise the amount of personal data that needs to be collected and processed while enabling useful functionality. In Firefox, this work includes technologies such as Oblivious HTTP, differential privacy, the Distributed Aggregation Protocol and DNS over HTTPS.

PETs encompass a broad family of technical, architectural and product-design approaches where data analysis, measurement, collaboration, access and computation happen with lower privacy risk.

Advancing both privacy and competition together is key to a healthier internet ecosystem. Advertising illustrates both the challenge and the opportunity. It keeps most of the web free and accessible, but today's dominant model leans on hidden data collection and opaque systems that work around people rather than with them. Solutions that simply hand more data, more infrastructure or more decision-making power to a handful of large companies do not fix that.

Importantly, PETs should not be viewed as a way to bypass privacy rules. Their value lies in reducing the amount of personal data that needs to be collected, shared or processed in the first place, while preserving useful functionality where appropriate. That is why we have been investing in and building around privacy-preserving advertising, recognising that PETs are not a silver bullet but an important part of a better model.

Responsible deployment of PETs depends not only on the technical design, but also on the governance, assurance, and market context around it. PETs should be grounded in open standards and interoperable architectures. Otherwise, they risk reinforcing walled gardens, limiting choice or creating new dependencies rather than supporting a more open and competitive ecosystem.

The discussion

The event opened with remarks from the Information Commissioner's Office (ICO). This included the ICO's work on PETs, online tracking, privacy-preserving attribution and the questions raised under Regulation 6 of the Privacy and Electronic Communications Regulations (PECR). Shortly before the event, the ICO had published advice to the government on possible online advertising exceptions to Regulation 6 PECR. As we set out in our submission to the ICO's call for views on online advertising, we support reform that incentivises privacy-preserving practices while keeping consent the default for high-risk practices.

Gijs Kruitbosch, Principal Engineer at Mozilla, then gave a technical demonstration of how Mozilla uses PETs and privacy-preserving design in Firefox, including on New Tab, where relevance can be improved through approaches that reduce reliance on user identifiers and server-side user profiles.

The panel, moderated by Mozilla's Kirsten Nelson-de Búrca, widened the lens well beyond advertising. Speakers from eyeo, OpenMined, the Open Data Institute and the Information Society Law Centre discussed how PETs are governed and used across sectors, and how their deployment could affect competition as well as privacy. The discussion explored public-interest examples, including federated rare-disease and genomic research that lets analysis happen without data leaving an institution or a country, and emerging routes for external researchers to study platform data.

A recurring theme was that successful deployment depends as much on governance and public trust as it does on mathematics. PETs have the potential to reduce the competitive advantages associated with large-scale personal data collection, but they could also entrench incumbents if the relevant infrastructure is closed, proprietary or expensive to audit. The discussion complicated the familiar trade-off between privacy and competition, arguing that it eases when PETs are built in the open, on shared standards, with interoperable and auditable implementations and real routes for smaller players and new entrants to take part.

What comes next

The most important questions were the ones we left without tidy answers. Who gets to set standards, and are they set in the open? How do smaller players actually participate, rather than being told they may? What forms of assurance or audit are needed before policymakers can rely on privacy claims? And how should PETs be built into the next generation of AI, where the most sensitive data and the strongest case for protection often sit together? These are the questions we want to keep working on with those who joined us and the wider community.

The post Mozilla Mornings comes to the UK: privacy-enhancing technologies and the questions they raise appeared first on Open Policy & Advocacy.

03 Jul 2026 10:36am GMT

01 Jul 2026

feedPlanet Mozilla

This Week In Rust: This Week in Rust 658

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
Foundation
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs

Crate of the Week

This week's crate is deconvolution, a image deconvolution and restoration library.

Thanks to pbkx 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.

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

426 pull requests were merged in the last week

Compiler
Library
Cargo
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

Overall, the week was fairly neutral, with no meaningful shift on most benchmarks on any of our statistics.

Triage done by @simulacrum. Revision range: 8b6558a0..7dc2c162

2 Regressions, 1 Improvement, 7 Mixed; 5 of them in rollups 34 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)

Language Reference

Rust RFCs

Unsafe Code Guidelines

No Items entered Final Comment Period this week for Cargo, Language Team or Leadership Council.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-07-01 - 2026-07-29 🦀

Virtual
Asia
Europe
North America
Oceania

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

I do rather hope anyone using -Zllvm-target-features or any stabilized form thereof would know that they are getting a conversation with the dragon directly and they should mind their words carefully if they do not wish to be barbecued by it and served over a nice plate of iron filings.

- workingjubilee on rust zulip

Thanks to Tomáš Šedovič 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

01 Jul 2026 4:00am GMT

Firefox Tooling Announcements: Happy BMO Push Day! (20260630.1)

Github Link

The following changes have been pushed to bugzilla.mozilla.org:

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

01 Jul 2026 12:55am GMT

30 Jun 2026

feedPlanet Mozilla

The Servo Blog: May in Servo: user scripts, mp4 compat, blackboxing in DevTools, and more!

Servo 0.3.0 contains all of the changes we landed in May, which came out to 391 commits (March: 534). For security fixes, see § Security.

servoshell 0.3.0 showing several new features: the `document.execCommand()` commands ‘back­Color’, ‘create­Link’, ‘unlink’, ‘superscript’, ‘subscript’, and ‘remove­Format’, plus ‘font-kerning’ and ‘font-variant-ligatures’

We've shipped several new web platform features:

Plus a bunch of new DOM APIs:

We've also fixed some build issues on Windows (@mukilan, #45079), FreeBSD (@delan, @mrobinson, @mukilan, #44600), and for anyone building Servo on NixOS or with Nix (@freyacodes, #45051, #45135).

This is another big update, so here's an outline:

Security

Servo's JS runtime, SpiderMonkey 140.10.0, had several memory safety bugs that have been fixed in Servo 0.3.0 with the update to SpiderMonkey 140.10.1 (@jschwe, #44755). For more details, see CVE-2026-7322, CVE-2026-7323, and MFSA 2026-36.

Work in progress

We're continuing to implement document.exec­Command() for rich text editing, under --pref dom­_exec­_command­_enabled (@TimvdLippe, #44735, #44973, #44887). This release adds support for the 'back­Color', 'fore­Color', 'create­Link', 'unlink', 'superscript', 'subscript', and 'remove­Format' commands (@TimvdLippe, #44644, #44682, #44657, #44710, #44677), plus partial support for the 'insert­Paragraph' command (@TimvdLippe, #44909).

We're also working on the Sanitizer API, under --pref dom­_sanitizer­_enabled. With the feature now enabled in servoshell's experimental mode (@kkoyung, #44701), this release adds support for set­Comments(), set­Data­Attributes(), allow­Processing­Instruction(), remove­Processing­Instruction(), and remove­Unsafe() on Sanitizer (@kkoyung, #44734, #44983).

IndexedDB continues to improve, under --pref dom­_indexeddb­_enabled. This release brings a more conformant abort() on IDB­Transaction (@Taym95, #43950).

All of the features above are enabled in servoshell's experimental mode.

We've made more progress towards accessibility support, including the name from contents algorithm (@alice, @delan, @mrobinson, #44439) and several changes towards building the accessibility tree incrementally (@alice, @delan, @mrobinson, #44766, #45035, #45207, #44768, #44785, #44801, #44767, #45029). The latter is critical for performance in real-world web content.

We're now working on SharedWorker and ServiceWorker, under --pref dom­_sharedworker­_enabled and --pref dom­_serviceworker­_enabled respectively. This release adds support for new Shared­Worker() (@Taym95, #44761), and parts of the ServiceWorker API (@gterzian, @arihant2math, #45082, #44787).

Embedding API

Servo now requires Rust 1.88.0 or newer, up from the old MSRV of 1.86.0 (@sagudev, #44815). We run compile tests with the MSRV, but most of our testing is now done with Rust 1.95.0 (@simonwuelker, #44632).

Breaking changes to the cookies methods in our SiteDataManager API (@longvatrong111, #44708):

Breaking changes to our Preferences API (@Narfinger, @mrobinson, #44307):

We've also reworked our DiagnosticsLogging API (@mukilan, #44703):

For users and developers

servoshell has two new options:

When using the Debugger tab in the Firefox DevTools:

For developers of Servo itself, please note that per project policy, you must not use the output of large language models or other generative AI tools in your contributions. To help us enforce that, we now have CI checks that reject AI agents as coauthors (@SimonSapin, @delan, #44723).

We've also fixed build issues with --features vello (@Gae24, @yezhizhen, #44875, #45036).

More on the web platform

We've improved the default appearance of <dl>, <ol>, <ul>, <table>, <thead>, <tbody>, <tfoot>, <tr>, <td>, <th>, <dir>, <menu>, and <form> (@avis137, #44837, #44920).

CryptoKey is now serializable, allowing it to be used in structuredClone() and postMessage() (@kkoyung, #45163).

We've improved JS error messages in several parts of the DOM (@n0blenote, @jdm, @TG199, @PuercoPop, #44704, #45186, #44656).

We've improved the conformance of form submission (@yezhizhen, #44943, #44953, #44954, #44957), tab navigation (@mrobinson, #44684), javascript: url navigation (@jdm, @TimvdLippe, #43490), 'Refresh' headers and <meta http-equiv=Refresh> (@jschwe, @mrobinson, #45113, #45116), 'line-break: anywhere' (@mrobinson, @SimonSapin, #44609), assign() on Location (@TG199, @jdm, #44298), crypto.subtle.derive­Bits() (@kkoyung, #44706), get­Computed­Style() (@Loirooriol, #44856), performance.measure() (@shubhamg13, #44675), read­As­Data­URL() on File­Reader (@yezhizhen, #44897, #44924), stream() on Blob (@Taym95, #45133), and ML-KEM in Subtle­Crypto (@kkoyung, #45153).

We've also landed improvements to GPU­Supported­Limits (@sagudev, #45114), GPU­Texture (@sagudev, #45154), create­Bind­Group() on GPU­Device (@sagudev, #45140), and other WebGPU features (@sagudev, #45097).

We've fixed bugs related to <svg> with 'Content-Security-Policy' (@TimvdLippe, @jdm, #44974), ':active' (@SharanRP, @mrobinson, #43953), ':hover' (@SharanRP, @mrobinson, #43979), 'align-items' (@yezhizhen, #44396), 'border-image-outset' (@lumiscosity, #45039), 'padding' with 'overflow: scroll' (@stevennovaryo, #44263), 'pointerup' events (@mrobinson, #44666), 'slotchange' events (@jdm, #44688), dynamic import() (@Gae24, #44741), and clip() on CanvasRenderingContext2D (@yezhizhen, #44831).

Performance

We've built a tool that will help us improve 'about:memory' by finding untracked allocations (@jdm, @TimvdLippe, @webbeef, #44674, #44980).

Servo now requires fewer OS threads per CPU, after we combined the thread pools for the image cache, web storage, and IndexedDB (@Narfinger, @mrobinson, #44307).

We've landed a bunch of layout optimisations:

DOM attributes are much more efficient in this release:

We've eliminated a traversal of the whole DOM tree whenever an <iframe> is attached to the tree, which is especially noticeable when parsing documents with many <iframe> tags (@mrobinson, #45236).

Stylesheet locks now use AtomicRefCell, which is even more efficient than a parking_lot::RwLock (@mrobinson, #44883).

On OpenHarmony, we now have a real refresh driver for reduced idle CPU usage (@jschwe, @yezhizhen, #44927), and we now cache the font list on disk for faster startup (@RichardTjokroutomo, @d-desyatkin, #44158).

We've also reduced allocations, GC rooting steps, and other operations in many parts of Servo (@jschwe, @kkoyung, @mrobinson, @SteveSharonSam, @Narfinger, @jdm, @nodelpit, @simonwuelker, #44961, #44944, #44972, #45231, #45078, #44662, #44679, #44967, #44963, #44933, #44935, #44905).

To improve Servo's build times, we're moving more code out of our massive script crate (@Narfinger, @jdm, #44598, #44636, #44823), and reduced the size of our dependency tree (@jschwe, #44818).

Stability

Several crashes and hangs have been fixed:

We've continued our long-running effort to use the Rust type system to make certain kinds of dynamic borrow failures impossible (@Gae24, @MavenRain, @Narfinger, @SteveSharonSam, @TimvdLippe, @elomscansio, @jdm, @kkoyung, @yezhizhen, #44712, #44759, #44879, #45014, #45058, #45061, #45076, #45098, #45110, #45149, #45117, #45184, #45201, #44806, #44930, #44942, #44946, #45233, #45181, #44659, #44660, #44664, #44668, #44992, #45000, #45081, #45009, #45225, #45087, #45244, #45245, #45247, #44663, #44665, #44993, #45040, #45053, #44647, #44671, #44681, #44717, #44733, #44686, #44653).

New contributors

A special thanks to the following people for landing their first patch in Servo:

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 7659 USD/month (+4.2% from April) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, 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 35 GitHub users (+2 from April) 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.

7659 USD/month
10000

Use of donations is decided transparently via the Technical Steering Committee's public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

30 Jun 2026 12:00am GMT

The Rust Programming Language Blog: Announcing Rust 1.96.1

The Rust team has published a new point release of Rust, 1.96.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.96.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.96.1

Rust 1.96.1 fixes:

It also fixes three CVEs affecting libssh2 (which is compiled into Cargo):

Contributors to 1.96.1

Many people came together to create Rust 1.96.1. We couldn't have done it without all of you. Thanks!

30 Jun 2026 12:00am GMT

29 Jun 2026

feedPlanet Mozilla

Mozilla Security Blog: Improving Transparency and Assurance in the Web PKI: Mozilla Root Store Policy v3.1

Mozilla remains committed to maintaining a secure, trustworthy, and transparent Web PKI. Today we are announcing the publication of Mozilla Root Store Policy (MRSP) version 3.1, effective July 1, 2026.

While previous policy updates focused heavily on certificate revocation, automation, and operational resilience, MRSP v3.1 focuses on a different challenge: ensuring that Certification Authority (CA) operations are sufficiently transparent, understandable, and auditable.

Trust in the Web PKI depends not only on technical requirements, but also on the ability of Mozilla, auditors, and the broader community to understand how CA systems are designed, operated, and assessed. MRSP v3.1 introduces new requirements intended to improve the quality of CA documentation and strengthen independent assurance of the design and effectiveness of controls that protect CA systems.

Improving CP/CPS Documentation

Certification Practice Statements (CPSes) and combined Certificate Policy / Certification Practice Statement documents (CP/CPSes) are among the most important public documents published by a CA. They describe how a CA conducts its operations and meets industry requirements.

Over the years, we have seen significant variation in the quality, structure, and level of detail provided in CP/CPS documentation. Some documents provide extensive implementation detail, while others rely heavily on incorporation by reference or provide only high-level descriptions of CA practices.

The revised policy will continue to require conformance with RFC 3647, as modified by applicable CA/Browser Forum requirements. Improvements to section 3.3 in the MRSP will establish clearer expectations regarding the content and quality of CP/CPS documentation. The new requirements emphasize that documentation must be explicit, bounded, auditable, and sufficiently detailed to describe the CA operator's certificate issuance and management activities, while also establishing requirements for version control, accessibility, and ongoing maintenance. The objective is to ensure that a technically competent reviewer will be better-able to determine what commitments the CA has made, how those commitments are implemented, and whether the documented practices support technical, operational, and performance oversight.

Mozilla believes that these new CP/CPS requirements will improve transparency, reduce misunderstandings, support more effective audits, and help reduce the risk of certificate misissuance by ensuring that operational practices are documented accurately, consistently, and in sufficient detail to permit meaningful review.

Introducing Detailed Controls Reports

A second major enhancement in MRSP v3.1 is the introduction of Detailed Controls Reports (DCRs). Traditional WebTrust and ETSI audit reports provide valuable independent assurance regarding compliance with established criteria. However, they generally provide only limited visibility into the specific controls, testing procedures, and operational environments that support those conclusions.

Beginning with audit periods starting on or after July 1, 2027, CA operators with root certificates enabled for TLS website authentication will be required to obtain a DCR. The purpose of the DCR is to provide CA management, auditors, and Mozilla with greater visibility into the controls, testing, and operating effectiveness of CA systems that support compliance with the CA/Browser Forum's TLS Baseline Requirements and Network and Certificate System Security Requirements. Mozilla generally expects to review DCRs only on an as-needed basis, such as during compliance reviews, incident investigations, root inclusion evaluations, or other oversight activities.

A DCR must include:

Mozilla expects that DCRs will complement existing audit reports and strengthen transparency and assurance by providing additional detail regarding system boundaries, control implementation, testing procedures, and control effectiveness that is not typically available in traditional audit reports. Effective compliance requires more than documented policies and successful audits; it also requires management understanding, oversight, and engagement. By providing greater visibility into CA systems, controls, testing activities, and operational risks, DCRs can help reinforce a strong tone at the top regarding compliance expectations, support informed decision-making and resource allocation, enable earlier identification of weaknesses, and promote a culture of continuous improvement. The intent is not to replace existing audit reports, but to provide additional information that supports effective governance, oversight, and informed trust decisions.

Additional Clarifications and Improvements

MRSP v3.1 also includes several targeted clarifications and refinements:

Looking Forward

Mozilla recognizes that these changes will require preparation by CA operators, auditors, and other ecosystem participants. To support implementation, Mozilla is publishing accompanying wiki guidance regarding both CP/CPS Documentation and Detailed Controls Reports.

As with previous policy updates, these changes were informed by discussions with CA operators, auditors, and members of the Web PKI community. We appreciate the feedback received during the review process and look forward to continued collaboration as the ecosystem evolves.

Mozilla has a longstanding focus on building confidence in the Web PKI through transparency, accountability, and continuous improvement. By requiring higher-quality CP/CPS documentation and strengthening independent assurance, MRSP v3.1 advances Mozilla's commitment to protecting its users and maintaining their trust in the systems that help secure the web.

The post Improving Transparency and Assurance in the Web PKI: Mozilla Root Store Policy v3.1 appeared first on Mozilla Security Blog.

29 Jun 2026 11:33am GMT

Firefox Tooling Announcements: Firefox Profiler Deployment (June 29, 2026)

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what's changed:

Highlights:

Other Changes:

Big thanks to our amazing localizers for making this release possible:

1 post - 1 participant

Read full topic

29 Jun 2026 9:25am GMT

25 Jun 2026

feedPlanet Mozilla

Thunderbird Blog: Thunderbird Monthly Development Digest: June 2026

Welcome back from the Thunderbird development team!

The past few months have been exceptionally busy across the project. As we approach the midpoint of the year, we've been focused on a mixture of delivering user-facing features, investing in long-term architectural improvements, and preparing for the next ESR cycle.

A significant amount of effort has gone into modernizing Exchange support, where the team is now approaching Graph API feature parity with our existing EWS implementation. At the same time, progress has continued on the Account Hub, the Global Message Database, and improvements to the add-ons ecosystem that will help extension developers transition toward a more secure and sustainable future.

Behind the scenes, we've also continued the less visible but equally important work of maintaining a large application: adapting to upstream platform changes, improving test reliability, addressing long-standing bugs, and supporting the growing community of contributors who help move Thunderbird forward every day.

This month we'd especially like to recognize one of those contributors, Maxe, whose sustained efforts tackling decades-old MIME bugs have been making a meaningful impact across the codebase.

Exchange Email Support

One of the largest efforts underway in Thunderbird continues to be our modernization of Exchange support.

Over the past several months, the team has pushed through multiple Graph API implementation phases and is now entering the final stretch toward feature parity with our existing EWS implementation. At the time of writing, only a small number of remaining email features separate the two implementations, with completion expected imminently.

Reaching this point has involved considerably more than simply implementing new API calls. The work required substantial investment in shared understanding, protocol abstractions, automated code generation, testing frameworks, request batching, synchronization mechanisms, and interoperability between legacy and modern components. Many of these improvements will continue to benefit future protocol work long after Graph support itself is complete.

A notable development came from our ongoing engagement with Microsoft, and following discussions around Graph API permissions, Microsoft confirmed that approved mail clients such as Thunderbird will continue to be able to obtain user consent for permissions that were previously unavailable to third-party applications. This removed a significant long-term uncertainty around Graph support and helps to ensure Thunderbird users can continue connecting Exchange accounts without requiring administrator intervention.

With email functionality nearing completion, the team has already begun planning the next stage of Exchange support, including calendar integration work that will build upon the foundation established over the past year.

Keep track of our Graph API implementation here.

20+ year old MIME bugs?! - Contributor Spotlight

This month we'd like to highlight Maxe, who has been on an impressive run tackling some of Thunderbird's oldest and most stubborn MIME issues.

Open source projects often benefit from contributors who quietly and consistently improve areas of the codebase that most people would rather avoid. Over the past several months, Maxe has become one of those contributors for Thunderbird.

What began as a handful of fixes has grown into a sustained effort to tackle some of the oldest MIME-related bugs in our tracker. Many of these issues date back decades, touching parts of the mail stack that have accumulated years of edge cases, historical assumptions, and compatibility quirks.

MIME handling sits at the heart of how Thunderbird interprets messages, attachments, encodings, and content types. While users rarely think about it when everything works correctly, it is often involved when messages display incorrectly, attachments behave unexpectedly, or unusual emails expose long-standing inconsistencies. Fixing these issues requires a deep understanding of both email standards and Thunderbird's historical behavior.

What has impressed us most is not any single patch, but the consistency. Over the past few months Maxe has continued to identify issues, develop fixes, respond to review feedback, and refine solutions until they work reliably across platforms and message types. Along the way, several fixes have uncovered additional problems and improved behaviour in places that weren't originally expected.

This kind of work is rarely flashy. It involves patiently navigating decades-old code, reproducing obscure bugs, and developing enough confidence to modify systems that affect virtually every Thunderbird user. Yet these are exactly the sorts of contributions that make open source software better over the long term.

On behalf of the team, thank you Maxe for the energy, persistence, and technical skill you've brought to Thunderbird this year. Your work is making a real difference.

Add-ons, Extensions and Ecosystem

The add-ons ecosystem remains an important part of Thunderbird, and over the last few months we've continued working toward a safer and more maintainable extension platform.

One significant decision was the postponement of experiment deprecation on the Monthly Release channel for an additional year. Feedback from extension developers made it clear that many maintainers needed more time to migrate away from legacy experiment APIs, and we want to ensure that transition is successful rather than disruptive.

This extra time allows us to focus on expanding official WebExtension APIs, improve migration paths, and work directly with extension developers to understand their priorities. To support this effort, we're preparing a broader outreach initiative later this year that will gather feedback from experiment maintainers and help guide future API development.

A great deal of this work has been driven by John, who has been balancing ecosystem improvements alongside onboarding new team members and supporting several other strategic projects. Ensuring that extension developers have a sustainable path forward remains a key investment area for Thunderbird.

Authentication and OAuth

Over the past several months we've continued modernizing Thunderbird's authentication experience, with a particular focus on OAuth and account setup.

One of the most visible improvements has been the continued rollout of browser-based OAuth flows. Instead of embedding authentication within Thunderbird itself, users can now complete sign-in using their system browser, providing a more familiar experience while benefiting from the security features and account state already present in their preferred browser.

As we expanded support for these flows, we also uncovered an interesting interoperability challenge. RFC 8252, the standard commonly used by native applications, recommends the use of loopback redirects with dynamically assigned local ports. While most providers support this approach correctly, several major providers have historically handled these redirects differently. As a result, we've been working directly with providers including Yahoo!/AOL, Comcast/Xfinity, and Yandex/Mail.ru to improve compatibility and ensure Thunderbird users continue to enjoy a smooth sign-in experience as authentication requirements evolve.

We've also been simplifying account setup for users of Thunderbird's growing ecosystem of services. Recent work allows users to launch authentication for a Thundermail account directly from Thunderbird without first manually entering account details. This significantly streamlines onboarding and lays the groundwork for similar experiences with other major providers in the future.

Another important addition has been the introduction of a Thunderbird-specific protocol handler. This enables web-based account dashboards, management interfaces, and enterprise deployment tools to communicate directly with Thunderbird and complete account configuration automatically. For Thundermail users, this creates a much smoother path from account creation to a fully configured desktop client. Looking ahead, the same technology opens the door to deeper integration opportunities for enterprise deployments and other hosted services.

While much of this work happens behind the scenes, it represents an important investment in making account setup faster, more reliable, and more secure for both individual users and organizations deploying Thunderbird at scale.

Panorama - Global Message Database

Behind the scenes, work continues on one of Thunderbird's most ambitious long-term architectural projects: the Global Message Database.

Recent months have focused on strengthening the foundations needed to connect Panorama's user experience with the underlying storage architecture. Geoff has resumed significant front-end work following ESR-related priorities, while Brendan has joined the project to help accelerate development and planning efforts. At the same time, Ben has been refactoring portions of the IMAP codebase to establish cleaner interfaces that will simplify integration with the new database architecture.

While much of this work remains infrastructural and therefore less visible to users today, it represents important progress toward a more modern foundation capable of supporting future performance, search, and organizational improvements throughout Thunderbird.

Maintenance, Upstream adaptations, Recent Features and Fixes

While major features tend to attract the most attention, a significant portion of Thunderbird's engineering effort continues to be devoted to maintenance and adaptation work required to keep pace with our upstream platform.

This period is traditionally one of the busiest times of the ESR cycle. As Firefox prepares its next ESR release, large volumes of platform changes land in a relatively short period of time. While these improvements benefit Thunderbird in the long term, they can also introduce unexpected regressions, styling inconsistencies, test failures, and compatibility issues that require immediate attention.

One particularly notable example has been Mozilla's ongoing Nova initiative, which introduces substantial visual and styling changes throughout Firefox. Without intervention, many of these changes would create inconsistencies across Thunderbird's user experience. Richard (Paenglab) has done exceptional work identifying, triaging, and adapting these upstream changes to ensure Thunderbird continues to present a coherent and polished interface. Much of this work goes unnoticed when done well, which is perhaps the highest compliment for maintenance engineering.

Alongside these adaptation efforts, the team and contributor community have continued landing a steady stream of reliability, stability, and usability improvements across the application. Recent highlights include:

If you would like to see new features as they land, and help us find some early bugs, you can try running daily and check the pushlog to see what has recently landed. This assistance is immensely helpful for catching problems early.

-

Toby Pilling

Senior Manager, Desktop Engineering

The post Thunderbird Monthly Development Digest: June 2026 appeared first on The Thunderbird Blog.

25 Jun 2026 6:34pm GMT