De Nederlandse
Mozilla-gemeenschap

Welcome to the Q1 2026 edition of the Firefox Security & Privacy Newsletter.

Security and privacy are foundational to Mozilla’s manifesto and central to how we build Firefox. In this edition, we highlight key security and privacy work from Q1 2026, organized into the following areas:

• Firefox Product Security & Privacy — new security and privacy features and integrations in Firefox
• Community Engagement — updates from our security research and bug bounty community
• Web Security & Standards — advancements that help websites better protect their users from online threats

Preface

Note: Some of the bugs linked below might not be accessible to the general public and restricted to specific work groups. We de-restrict fixed security bugs after a grace-period, until the majority of our user population have received Firefox updates. If a link does not work for you, please accept this as a precaution for the safety of all Firefox users.

Firefox Product Security & Privacy

Collaboration with Anthropic: A few weeks ago, Anthropic’s Frontier Red Team shared the results of a new AI-assisted vulnerability detection approach. Using this method, we have identified more than a dozen confirmed security issues, each supported by reproducible test cases. Learn more in our blog: Hardening Firefox with Anthropic’s Red Team. Leveraging our Firefox Security expertise, we ended up finding dozens of additional vulnerabilities that were fixed in the following Firefox updates.

YouTube coverage of Firefox at pwn2own 2025: To demonstrate Firefox’s focus on user security and Mozilla’s commitment to openness, we invited LiveOverflow to follow us during the prestigious hacking competition pwn2own last year. LiveOverflow’s four-party documentary provides behind-the-scenes coverage of our quick response to fixing two Firefox 0-day security bugs. The videos go from preparation (part 1), to exploit analysis (part 2) and disclosure (part 3), all the way to the rapid release of a Firefox update (part 4) for the 2-day event coverage.

Trustworthy JavaScript for the Open Web: Alongside partners from Meta, Proton AG, Cloudflare, and the Freedom of the Press Foundation, we presented our plans to improve the trustworthiness of JavaScript on the Web at Real World Crypto.

SafeBrowsing: Firefox 147 shipped with SafeBrowsing v5 support, allowing to protect users against malicious URLs. And starting with v149, Firefox blocks and revokes websites permissions for sites on the SafeBrowsing lists (Bug 1986300), leveling-up the built-in protection from online threats.

Stronger XSS Protection through the Sanitizer API: Starting with v148, Firefox was the first browser to add support for the Sanitizer API, helping prevent XSS attacks on the web. Learn more in our blog post, Goodbye innerHTML, Hello setHTML: Stronger XSS Protection in Firefox 148, or tune in to the ShopTalk Show podcast, where Freddy Braun discusses the details of the Sanitizer API.

2048-bit Minimum for RSA Certificates: Firefox now enforces a minimum 2048-bit RSA key size for certificates issued by Mozilla’s built-in root CAs. As publicly trusted CAs already meet this requirement, no significant impact to the broader web is expected.

Community Engagement

Bug Bounty Program Updates: As the threat landscape evolves, addressing the increasing volume of AI-assisted security bug reports, we’re evolving our security program alongside it. With continued advances in browser security architecture, our bug bounty program is refining its incentives to prioritize the highest-impact research and the most critical classes of vulnerabilities while focusing on novelty. Learn more in our blogpost: Bug Bounty Program Updates 2026. We have also just updated our Bug Bounty hall of fame, to list all people who helped us find and fix security vulnerabilities in Q1 of 2026.

Web Security & Standards

Storage-Access Headers: Firefox 147 is shipping an extension of the Storage Access API to improve both web compatibility and parity with Chrome. These Storage Access headers allow web pages to opt out of storage isolation upfront and without the need to first load a document.

Going Forward

As a Firefox user, you automatically benefit from the security and privacy improvements described above through Firefox’s regular automatic updates. If you’re not using Firefox yet, you can download it to enjoy a fast, secure browsing experience—while supporting Mozilla’s mission of a healthy, safe, and accessible web for everyone.

We’d like to thank everyone who helps make Firefox and the open web more secure and privacy-respecting.

See you next time with the Q2 2026 report.

— The Firefox Security and Privacy Teams

Firefox Telemetry Engineer and Data Steward Chris H-C (:chutten) gives a talk at Ubisoft's Data Summit 2021 about how Responsible Data Collection as practised at Mozilla makes cataloguing easy, stops instrumentation mistakes before they ship, and allows you to build self-serve analysis tooling that gets everyone invested in data quality. Oh, and it's cheaper, too.

You ever get to the end of running benchmarks, maybe a long running one, and realize… “Oh no. I forgot to set that important option, and these results are useless”

Yeah. I have. Too many times.

So I’ve added --benchmark-mode and --strict-benchmark-mode to SpiderMonkey.

These options configure the shell for benchmarking, taking the wisdom of the team and boiling multiple shell options down to a single --benchmark-mode flag, and in --strict-benchmark-mode will abort the run if the shell is configured in a way where effective benchmarking is unlikely to be possible (e.g. benchmarking a debug build!)

The nice thing about nailing this down is that this is something we can point anyone to and know that their shell is following the rules any of us would follow.

The general design philosophy of benchmark mode is to disable things you wouldn’t see enabled in Firefox in normal configuration, as well as debugging code that maybe makes sense for test suites but doesn’t make sense for a benchmark.

Hopefully this is the end of me realizing that I forgot to pass --no-async-stacks yet again.

Mozilla has joined EFF, the Alliance for Responsible Data Collection, Digital Medusa, and EleutherAI in filing an amicus brief in Amazon v. Perplexity, urging the Ninth Circuit not to stretch the Computer Fraud and Abuse Act (CFAA) far beyond its intended purpose.

We have said this before, and it remains true: laws designed to protect the security of the internet should not be used to undermine how people want to use it.

Our mission is grounded in the idea that the internet must remain open and accessible to all, and that privacy and security online are fundamental. Mozilla joined this brief because overly broad interpretations of computer crime laws can put those values at risk.

The CFAA is an anti-hacking law. It was meant to address break-ins to computer systems — not to criminalize tools that enable people to access and engage with information that is publicly available on the web. While there are no-doubt many challenging legal and policy questions around the growth and use of agentic AI tools, we believe expanding the reach of CFAA to address these issues would threaten innovation, chill the development of useful tools and services for researchers and journalists, and undermine competition online.

The post Anti-hacking laws should not be used to lock up the open internet appeared first on Open Policy & Advocacy.

Today the Servo team has released v0.1.0 of the servo crate. This is our first crates.io release of the servo crate that allows Servo to be used as a library.

We currently do not have any plans of publishing our demo browser servoshell to crates.io. In the 5 releases since our initial GitHub release in October 2025, our release process has matured, with the main “bottleneck” now being the human-written monthly blog post. Since we’re quite excited about this release, we decided to not wait for the monthly blog post to be finished, but promise to deliver the monthly update in the coming weeks.

As you can see from the version number, this release is not a 1.0 release. In fact, we still haven’t finished discussing what 1.0 means for Servo. Nevertheless, the increased version number reflects our growing confidence in Servo’s embedding API and its ability to meet some users’ needs.

In the meantime we also decided to offer a long-term support (LTS) version of Servo, since breaking changes in the regular monthly releases are expected and some embedders might prefer doing major upgrades on a scheduled half-yearly basis while still receiving security updates and (hopefully!) some migration guides. For more details on the LTS release, see the respective section in the Servo book.

In the previous post, I mentioned that buildcache has some unique properties compared to ccache and sccache. One of them is its Lua plugin system, which lets you write custom wrappers for programs that aren’t compilers in the traditional sense. With Bug 2027655 now merged, we can use this to cache Firefox’s WebIDL binding code generation.

What’s the WebIDL step?

When you build Firefox, one of the earlier steps runs python3 -m mozbuild.action.webidl to generate C++ binding code from hundreds of .webidl files. It produces thousands of output files: headers, cpp files, forward declarations, event implementations, and so on. The step isn’t terribly slow on its own, but it runs on every clobber build, and the output is entirely deterministic given the same inputs. That makes it a perfect candidate for caching.

The problem was that the compiler cache was never passed to this step. Buildcache was only wrapping actual compiler invocations, not the Python codegen.

The change

The fix in Bug 2027655 is small. In dom/bindings/Makefile.in, we now conditionally pass $(CCACHE) as a command wrapper to the py_action call:

WEBIDL_CCACHE= ifdef MOZ_USING_BUILDCACHE WEBIDL_CCACHE=$(CCACHE) endif webidl.stub: $(codegen_dependencies) $(call py_action,webidl $(relativesrcdir),$(srcdir),,$(WEBIDL_CCACHE)) @$(TOUCH) $@

The py_action macro in config/makefiles/functions.mk is what runs Python build actions. The ability to pass a command wrapper as a fourth argument was also introduced in this bug. When buildcache is configured as the compiler cache, this means the webidl action is invoked as buildcache python3 -m mozbuild.action.webidl ... instead of just python3 -m mozbuild.action.webidl .... That’s all buildcache needs to intercept it.

Note the ifdef MOZ_USING_BUILDCACHE guard. This is specific to buildcache because ccache and sccache don’t have a mechanism for caching arbitrary commands. Buildcache does, through its Lua wrappers.

The Lua wrapper

Buildcache’s Lua plugin system lets you write a script that tells it how to handle a program it doesn’t natively understand. The wrapper for WebIDL codegen, webidl.lua, needs to answer a few questions for buildcache:

• Can I handle this command? Match on mozbuild.action.webidl in the argument list.
• What are the inputs? All the .webidl source files, plus the Python codegen scripts. These come from file-lists.json (which mach generates) and codegen.json (which tracks the Python dependencies from the previous run).
• What are the outputs? All the generated binding headers, cpp files, event files, and the codegen state files. Again derived from file-lists.json.

With that information, buildcache can hash the inputs, check the cache, and either replay the cached outputs or run the real command and store the results.

The wrapper uses buildcache’s direct_mode capability, meaning it hashes input files directly rather than relying on preprocessed output. This is the right approach here since we’re not dealing with a C preprocessor but with a Python script that reads .webidl files.

Numbers

Here are build times for ./mach build on Linux, comparing compiler cachers. Each row shows a clobber build with an empty cache (cold), followed by a clobber build with a filled cache (warm):

tool cold warm with plugin none 5m35s n/a n/a ccache 5m42s 3m21s n/a sccache 9m38s 2m49s n/a buildcache 5m43s 1m27s 1m12s

The “with plugin” column is buildcache with the webidl.lua wrapper active. It shaves another 15 seconds1, bringing the total down to 1m12s2. Not a revolutionary improvement on its own, but it demonstrates the mechanism. The WebIDL step is just the first Python action to get this treatment; there are other codegen steps in the build that could benefit from the same approach.

More broadly, these numbers show buildcache pulling well ahead on warm builds. Going from a 5m35s clean build to a 1m12s cached rebuild is a nice improvement to the edit-compile-test cycle.

These are single runs on one machine, not rigorous benchmarks, but the direction is clear enough.

Setting it up

If you’re already using buildcache with mach, the Makefile change is available when updating to today’s central. To enable the Lua wrapper, clone the buildcache-wrappers repo and point buildcache at it via lua_paths in ~/.buildcache/config.json:

{ "lua_paths": ["/path/to/buildcache-wrappers/mozilla"], "max_cache_size": 10737418240, "max_local_entry_size": 2684354560 }

Alternatively, you can set the BUILDCACHE_LUA_PATH environment variable. A convenient place to do that is in your mozconfig:

mk_add_options "export BUILDCACHE_LUA_PATH=/path/to/buildcache-wrappers/mozilla/"

The large max_local_entry_size (2.5 GB) is needed because some Rust crates produce very large cache entries.

What’s next

The Lua plugin system is the interesting part here. The WebIDL wrapper is a proof of concept, but the same technique applies to any deterministic build step that takes known inputs and produces known outputs. There are other codegen actions in the Firefox build that could get the same treatment, and I plan to explore those next.

Notes

1. For a clobber build with a warm cache ↩

2. On my machine ↩

Microsoft recently announced it’s pulling back Copilot from several of its core Windows apps — Photos, Notepad, the Snipping Tool, and Widgets. Rolling back these forced AI integrations is the right move, but this is just the most recent example of Microsoft going too far without user consent. 

Copilot was pushed onto users

Over the past year, Copilot wasn’t offered to Windows users — it was installed on them. The M365 Copilot app began auto-installing on any Windows device running Microsoft 365 desktop apps, with no prompt and no consent. A new physical keyboard key was added to laptops that launched Copilot by default, with no simple way to remap it. By default, Copilot was pinned to the taskbar starting with Windows 11 PCs. And, going a step further, Microsoft planned to embed it into three of the most fundamental surfaces for the operating system: the Windows notification center, the Settings app, and File Explorer. 

Then came the user backlash. 

When Microsoft says it now wants to be “intentional” about Copilot, they’re really admitting that they made repeated choices to serve their business over their customers. 

This isn’t the first time – Microsoft has a pattern of deceptive design patterns

The pattern of behavior here isn’t new. Independent research commissioned by Mozilla has documented how Microsoft uses design and distribution tactics to override user choice — from deliberately complicated processes for changing your default browser, to UI that routes users back to Microsoft’s Edge browser even after they’ve explicitly chosen something else.

Since Mozilla published that research, Microsoft has continued to escalate its use of dark patterns to force behaviors that help the bottom line, not people’s lives. Here are a few examples from the rollout of Windows 11 that have continued to strip users of their choice: 

• The Windows Search bar, embedded in the taskbar on both Windows 10 and Windows 11, is hardcoded to only open Microsoft Edge, regardless of your default browser.
• Windows has not implemented a true device migration system, like we see with Android, iOS, and MacOS, where your apps, settings and data are all reflected on your new device when you buy a new computer. Instead, the defaults are changed back to Microsoft’s own products. 
• Microsoft Outlook and Microsoft Teams by default ignore your default browser selection and open links directly in Edge.
• Windows does not offer a simple prompt that other browsers can trigger asking to become your default browser. Instead, other browsers have to direct you to Windows settings and hope you finish the multi-step process.

The Copilot rollout followed the same playbook we’ve come to expect from Microsoft: use automatic installs, physical hardware, and default settings to force behaviors. In the most recent instance, they allowed their AI to learn and gather data as quickly as possible before people had a choice. 

What ‘genuinely useful’ AI integration actually looks like

We, like Microsoft and basically every tech company, have been asking ourselves the same question: What does it mean for AI to be genuinely useful? For us, the answer is simple. AI should work on your terms, not ours. Firefox’s goal is to create AI enhancements that are made for people, not just because they can increase profit. 

We’ve rolled out AI-enhanced features that make browsing smarter, faster, and more personalized, such as translations that stay local on your device to help you browse the web in your preferred language, alt text in PDFs to add accessibility descriptions to images in PDF pages and tab grouping which suggests related tabs and group names.

But we also know users deserve a choice. We built our answer into Firefox 148, introducing a centralized AI Controls panel in your browser settings including a single “Block AI Enhancements” switch that turns off every AI feature at once. Each option is also individually controllable. 

The premise is simple: You should decide whether AI is part of your browsing experience at all. Not Big Tech. Not Mozilla. You.

And critically, your preferences also persist across browser updates, which means AI tools won’t silently re-enable themselves after a major upgrade. No reinstalling. No opting out again after the fact. It’s designed for people who care about what’s happening on their computer but shouldn’t have to become a systems administrator to stay in control of it.

The stakes are bigger than one rollback

When a company with Microsoft’s reach continues to control users — and only walks it back when the noise gets loud enough — it shapes what people expect from technology. It tells people that their only real move is to complain until, hopefully, the company relents. It also makes it harder for alternatives to compete when a company uses its reach and control to steer people back into its own products.  

We don’t think that’s the internet we have to accept. People have been clear about what they want when it comes to this era of the internet. They want to feel like they’re in control of their own devices and their own data. That’s the internet we’re trying to build. 

The post Old habits die hard: Microsoft tries to limit our options, this time with AI appeared first on The Mozilla Blog.

Image generated by Nano Banana 2 in response to a request for a “Retro-futuristic collage of a scientist using an open-source AI scanner to analyze floating vintage tech and digital data streams.”

We’re launching across the developer and security community this week on Product Hunt and Hacker News. If you’ve been following AI security, we’d love your support and your feedback. 

At Mozilla, open source has never been just a licensing choice. It’s a conviction: the internet gets healthier when tools and knowledge circulate freely, when anyone can audit what’s running, extend what exists, and build on what came before. That’s why we built Firefox in the open. It’s why we’ve kept building that way ever since.

0DIN, Mozilla’s AI security team, is working from the same premise. This week we’re releasing the 0DIN AI Security Scanner as open source software under the Apache 2.0 license, along with 179 community probes covering 35 vulnerability families, plus six specialty probes drawn exclusively from our bug bounty library.

The scanner, and the intelligence behind it

The 0DIN Scanner isn’t another benchmark suite built from textbook examples. We’re seeding it with probes drawn directly from our bug bounty program, where security researchers compete to find novel techniques to manipulate, extract data from, and subvert AI systems. As new vulnerabilities are discovered and disclosed through that program, we’ll continue adding probes to the open-source library over time.

That loop, from researcher discovery to packaged reusable test, is what separates 0DIN Scanner from generic tooling. It’s high impact intelligence on jailbreaks, updated frequently as our researchers find new techniques.

Built on NVIDIA’s GARAK open-source framework, the 0DIN Scanner adds a graphical interface, automated scan scheduling, cross-model comparative analysis, and enterprise-grade reporting. It runs against frontier models, open source LLMs, chatbots and anything with a prompt interface. Security teams can see attack success rates, a vulnerability breakdown, and a comparison against the frontier models that attackers are also probing every day.

Six of those bug bounty probes are named here for the first time: Placeholder Injection, Incremental Table Completion, Technical Field Guide, Chemical Compiler Debug, Correction, and Hex Recipe Book. Each represents a real technique that worked against production AI systems before we closed the loop.

These probes are scored using JEF (Jailbreak Evaluation Framework), our open-source library for measuring prohibited content output, which is also seeing major updates this week.

The code is at github.com/0din-ai/ai-scanner. Fork it, extend it, build on it.

Knowing your risk before attackers do

Not every organization has a red team or the bandwidth to run adversarial testing. Many companies are deploying AI in production right now without a clear picture of where they’re exposed. To help close that gap, we’re offering free security assessments for enterprise AI deployments.

The assessment delivers an attack success rate against your systems, a breakdown across prompt injection, jailbreaks, and data extraction categories, and a benchmark comparison against major frontier models. The process takes a few minutes to setup with scan duration varying based on the number of probes chosen. If you’re actively deploying AI and haven’t tested it under adversarial conditions, this is a good place to start.

For teams that don’t want to manage the open source scanner on their own, we also offer a managed Enterprise edition with access to nearly 500 pre-disclosure probes from the bug bounty program, giving organizations advance notice of emerging techniques before they’re publicly known.

Why open source, and why now

AI is moving fast enough that no single team will solve this alone. There are too many threats, too many models, too much attack surface. Keeping our tools locked away would make 0DIN marginally stronger while leaving the broader internet weaker.

The researchers who submitted findings through our bug bounty program earned bounties for their work. We’re releasing a meaningful portion of that intelligence as open source and we’ll keep doing so as new vulnerabilities are discovered and disclosed. That’s the deal Mozilla has always offered: we build in the open, the community helps make it better, and the web gets a little healthier for it.

Get involved

• Find us on LinkedIn and X.com.
• Watch the scanner demo
• Open-source AI scanner on GitHub
• Apply for scanner access
• Request a free security assessment
• Join the 0DIN bug bounty program

The post 0DIN is open-sourcing AI security and the hard-earned knowledge behind it appeared first on The Mozilla Blog.

I’m happy to announce that buildcache is now a first-class compiler cache in mach. This has been a long time coming, and I’m excited to finally see it land.

For those unfamiliar, buildcache is a compiler cache that can drastically cut down your rebuild times by caching compilation results. It’s similar to ccache, but even more so sccache, in that it supports C/C++ out of the box, as well as Rust. It has some nice unique properties of its own though, which we’ll look at more closely in following posts.

Getting started

Setting it up is straightforward. Just add the following to your mozconfig:

ac_add_options --with-ccache=buildcache

Then build as usual:

./mach build

That’s it.

Give it a try

If you run into any issues, please file a bug and tag me. I’d love to hear how it works out for people, and any rough edges you might hit.

Bugs resolved in Moz-Phab 2.12.0:

• bug 2029015 Clean up previous_commit state tracking
• bug 2029072 Using moz-phab uplift --assessment-id shouldn’t require extra browser clicks

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

1 post - 1 participant

Read full topic

The latest version of PerfCompare is now live!

Check out the change-log below to see the updates:

[kala]

• Bug: 2020622 Updated column title from Total Runs to Total Trials #1012
• Bug 2024075 Test Version Refactor: Moved subtest columns to test version strategy and test version files #1017
• Bug 2022720 Test Version Refactor: Refactor how the expanded row’s components are rendered #1016
• Bug 2027906 Test Version Refactor: remove hard coded array in Test Version Dropdown and replace with call to label options in registry #1020
• Bug 2026342 : Replace truncated subtest names with full name #1023

[moijes12]

• Bug-2020964 Update Contributing section in README #1009
• Bug-2022758 Remove redundant Dark fonts #1011

[padenot]

• Median diff gated #1019

[mgaudet]

• Bug 2024042 - Add median diff column #1015

Thank you for the contributions!

Bugs or feature request can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Element. Come and chat!

1 post - 1 participant

Read full topic

Welcome to the Q1 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

• Suhaib Integrated Review Helper with Phabricator and moz-phab making AI-powered code review quick and simple.
• Connor Sheehan implemented ETL from Lando to STMO, which allows us to get better visibility into lando’s performance and usage.
• Firefox 150 will ship with new PDF editing features completed by Calixte, letting users delete, copy, move, and export pages to a new PDF.

Detailed Project Updates AI for Development

• Suhaib Mujahid integrated Review Helper with Phabricator, enabling AI-powered code review directly from patches by clicking a “Request AI Review” button, allowing it to analyze the patch and post comments with any findings.
• Suhaib Mujahid extended moz-phab to support requesting an AI review at patch submission time, enabling contributors to trigger Review Helper analysis directly from the command line via moz-phab --ai.

Bugzilla

• Marco trained a new model in bugbug to detect bugs that are accessibility-related and missing the “access” keyword, to bring them to the attention of the accessibility team
  • First bugs found: Bug 2026654, Bug 2026647, Bug 2025992
• Two fixes from dkl to improve the reliability of the background bot that syncs Phabricator revisions with Bugzilla bugs.
• Kohei updated the markdown comment editor now intelligently handles pasting URLs. When you paste a URL while text is selected, it automatically formats it as a markdown link “selected text”.
• Kohei has also done significant improvements to the Guided Bug Entry page for new Bugzilla pages that should be going live soon.

Build System and Mach Environment

• Better scheduling of rust dependencies through Bug 2011880 leads to ~1m saving in build time for opt build with hot cache.
• Warning flags can no longer be added directly to CFLAGS or CXXFLAGS in moz.build, they have to go in COMPILE_FLAGS[“WARNINGS_CXXFLAGS”] (resp. COMPILE_FLAGS[“WARNINGS_CFLAGS”]) (see Bug 1986258)

Firefox-CI, Taskcluster and Treeherder

• Matt Boris upgraded FxCI to use RabbitMQ quorum queues and upgraded pulse to the latest available version for performance, security, and reliability.
• Abhishek Madan migrated schema validation from Voluptuous to msgspec across taskgraph, mozilla-taskgraph, and firefox, resulting in a 30% improvement to decision task times.
  • Bug for conversion in Firefox, PR in Taskgraph, PR in Mozilla-Taskgraph
• Abhishek Madan moved Firefox from a vendored copy of taskgraph to PyPI installs at setup time, enabling support for packages that include compiled components.
  • Patch stack
• Andrew Halberstadt made lots of progress migrating CI to Github, currently being used by mozilla/enterprise-firefox:
  • Support for actions
  • Fixed index and Treeherder routes
  • Support for mach try
  • Added pull_request_number as a parameter
• Andrew Halberstadt wrote a patch implementing the ability for the Taskcluster Github service to trigger hooks listed in .taskcluster.yml files. This will pave the way to share cross-project workflows and simplify in-repo configuration.
• Cameron Dawson upgraded major frontend libraries of Treeherder

Lint, Static Analysis and Code Coverage

• New linter for header guards, through bug 2009182, triggered by mach lint --linter header-guards . It enforces our code style.
• A limited subset of clang-tidy’s static analysis is now run and enforced on our whole codebase. It is also reported during review on phabricator (see Bug 2023518 and related bugs)
• ESLint and Prettier have been updated to the latest versions.
  • This included a fix for eslint-plugin-jsdoc check-property-names rule which was raising some false-positives in firefox-main.
• eslint-env comments are being removed as ESLint v9 does not support them (use eslint-file-globals.config.mjs instead). ESLint v10 (currently in rc) will raise errors for them.
• More eslint-plugin-jsdoc rules have been enabled across the whole tree. These are the ones relating to valid-jsdoc. A few remain, but will need work by teams to fix the failur
• The “Black” python formatter has now been replaced by “Ruff”.
• Marco greatly simplified the code coverage infrastructure, getting rid of two Heroku services, a frontend service, and a lot of code. The code coverage official UI is now Searchfox.
• Marco added a new mach command (“./mach coverage-report”) to generate a coverage report from a push. The command is documented on the code coverage page in the Firefox source docs.
• Teklia added added support for Github pull requests to Code Review Bot (prototype)

PDF.js

• Calixte finished the implementation of the new reorganize and split functionality in PDF, which will ship in Firefox 150! Users will be able to delete, copy, move pages, and to export a subset of pages to a new PDF.
• Nicolò Ribaudo implemented the ability to open context menus on images in PDFs, allowing users to perform actions they are used to (such as downloading images). This was a long standing feature request (11 years!).

Firefox Translations

• Evgeny Pavlov, Jaume Zaragoza-Bernabeu, and Sergio Ortiz Rojas contributed to training both new and improved Translations models for use in Firefox.
  • Bosnian
  • Croatian
  • Norwegian Bokmål
  • Serbian
  • Thai
  • Traditional Chinese
  • Vietnamese
• Erik Nordin fixed an issue where text contained within stand-alone SVG images was not being translated (Bug 2003545).
• Erik Nordin reworked the Translations settings to be compatible with the upcoming about:settings redesign (Bug 2002127).
• Erik Nordin helped design a system to control the enablement of AI Features within Firefox, and worked to make the entire Translations feature set have the capability to be turned off and back on within the same browsing session (Bug 2010922, Bug 2010993).
• Erik Nordin reworked the about:translations page in order to get it ready for an official release with a URL-bar QuickAction entry point. (Bug 2004463, Bug 2016677, Bug 2015798, Bug 2016658, Bug 2016675, Bug 2016690, Bug 2019753, Bug 2020014, Bug 2020062, Bug2020067, Bug2022838, Bug 1814168, Bug 1814195, Bug 1841109, Bug 1869772, Bug 1879933, Bug 1970962, Bug 1990333, Bug 1991224, Bug 1992230, Bug 1992231, Bug 1992232, Bug 1992233, Bug 2000959, Bug 2004471, Bug 2004473, Bug 2019119, Bug 2019120, Bug 1970963, Bug 2004454, Bug 2010399, Bug 2023677, Bug 1836451, Bug 1999999, Bug 2004476, Bug 2004477, Bug 2004479, Bug 2004962, Bug 2007007, Bug 2007194, Bug 2007551, Bug 2008213, Bug 2008257, Bug 2010335, Bug 2019116, Bug 2019117, Bug 2019121, Bug 2019123, Bug 2020697, Bug 2020841, Bug 2024467)
  • Thank you to Dasha Andriyenko for designing the visuals and UX of the page.
  • Thank you to Kim Bryant for managing the product and release considerations.
  • Thank you to Sam Foster and Greg Tatum who reviewed a significant portion of the code.
  • Thank you to Ciprian Georgiu and Giorgia Nichita for testing quality assurance.
  • Thank you to Anna Yeddi for reviewing engineering accessibility characteristics.
  • Thank you to Dale Harvey for designing the QuickAction system that this feature plugs into.
• Leonardo Paffi improved our testing capabilities by allowing us to serve inline HTML on the fly, rather than having to add an HTML file into the repository. This eases the burden of overhead to test special-case language characteristics, and ultimately helped us release Norwegian Bokmål (Bug 1996967).
• Leonardo Paffi improved our handling of the macro language tag for Norwegian (no) to be compatible with our support for Norwegian Bokmål translations (Bug 2019123).
• Tyler Etchart removed in-code references to quality estimation models, which are not utilized during translation inference within Firefox (Bug 1889753).
• Tyler Etchart updated the generated Translations WASM JavaScript code to have explicit. comments expressing that the file is generated and should not be modified (Bug 1968038).
• Tyler Etchart removed some old dead code related to prior ideas for Translations within Firefox (Bug 1996681).
• Emilio Cobos Álvarez fixed an issue where the checkboxes within the Full-Page Translations Panel settings menu were no longer appearing (Bug 2010234).

Phabricator, moz-phab, and Lando

• Connor Sheehan implemented ETL from Lando to STMO, which allows us to get better visibility into lando’s performance and usage, e.g., the new uplift feature: Client Challenge
• Zeid continues spear-heading the GitHub PR pilot, gathering feedback and fixing usability issues as they are reported. One key focus was on supporting triggering the Code Review Bot on request, via pushes to try.
• Olivier Mehani added backward-compatible support for try pushes in the new instance of lando. It will become the default soon, but you can try it out now by setting LANDO_TRY_CONFIG=lando-prod-new in your environment prior to running `mach try .
• Olivier Mehani landed a small change to lando, to make the current Tree Status visible on main landing pages (Bug 2025629). This, with the landing queue visible on the job details pages, should help get a better understanding of why jobs sometimes seem to take longer than expected to land.
• moz-phab had several new releases:
  • Suhaib Mujahid added the --ai flag and submit.ai_review commit option to request an AI review of patches at submission time.
  • Johan Lorenzo added the --test-plan flag to enable submitting a test plan from the CLI, which is useful for working with AI agents
  • See the release notes here:
    • MozPhab 2.8.2 Released
    • MozPhab 2.8.3 Released
    • MozPhab 2.9.0 Released
    • MozPhab 2.9.1 Released
    • MozPhab 2.10.0 Released
    • MozPhab 2.11.0 Released
    • https://discourse.mozilla.org/t/mozphab-2-11-1-released/147821/1

Release Engineering and Release Management

• Ben Hearsum added new tests to verify update integrity on mozilla-central.
• Julien Cristau updated the docker images for many build and related tasks from Debian 12 to Debian 13
• Relman streamlined the release process by removing the Nightly soft code freeze and adjusting the Beta schedule to reduce end-of-cycle friction, create more effective stabilization time, and simplify release candidate workflows.
• We now ship to the Xiaomi Store.
• Delivered mid-cycle ESR dot releases to address critical security fixes ahead of the standard cadence, improving responsiveness while coordinating across multiple ESR versions and release channels.
• Andrew Halberstadt helped support and build out the Firefox Enterprise release pipeline.

Release Operations

• Mark Cornmesser improved Windows hardware management, including self-configuration and self-deployment capabilities, automated BIOS management, and standardization of BIOS settings across performance testing environments to ensure consistency and reliability.

Other

• Thanks to Bug #2013401 mozilla::Maybe<scalar_type> generates better and denser code, which led to a reduction of 300kB for libxul.so

• Thanks to A new clang-tidy pass we’ve been able to automatically add std::move in location where it could improve performance (see Bug 2012658)

Thanks for reading and see you next quarter!

1 post - 1 participant

Read full topic

Building fewer targets by default

On 2026-05-01, docs.rs will make a breaking change to its build behavior.

Today, if a crate does not define a targets list in its docs.rs metadata, docs.rs builds documentation for a default list of five targets.

Starting on 2026-05-01, docs.rs will instead build documentation for only the default target unless additional targets are requested explicitly.

This is the next step in a change we first introduced in 2020, when docs.rs added support for opting into fewer build targets. Most crates do not compile different code for different targets, so building fewer targets by default is a better fit for most releases. It also reduces build times and saves resources on docs.rs.

This change only affects:

1. new releases
2. rebuilds of old releases

How is the default target chosen?

If you do not set default-target, docs.rs uses the target of its build servers: x86_64-unknown-linux-gnu.

You can override that by setting default-target in your docs.rs metadata:

[package.metadata.docs.rs] default-target = "x86_64-apple-darwin" How do I build documentation for additional targets?

If your crate needs documentation to be built for more than the default target, define the full list explicitly in your Cargo.toml:

[package.metadata.docs.rs] targets = [ "x86_64-unknown-linux-gnu", "x86_64-apple-darwin", "x86_64-pc-windows-msvc", "i686-unknown-linux-gnu", "i686-pc-windows-msvc" ]

When targets is set, docs.rs will build documentation for exactly those targets.

docs.rs still supports any target available in the Rust toolchain. Only the default behavior is changing.

Rust's WebAssembly targets are soon going to experience a change which has a risk of breaking existing projects, and this post is intended to notify users of this upcoming change, explain what it is, and how to handle it. Specifically, all WebAssembly targets in Rust have been linked using the --allow-undefined flag to wasm-ld, and this flag is being removed.

What is --allow-undefined?

WebAssembly binaries in Rust today are all created by linking with wasm-ld. This serves a similar purpose to ld, lld, and mold, for example; it takes separately compiled crates/object files and creates one final binary. Since the first introduction of WebAssembly targets in Rust, the --allow-undefined flag has been passed to wasm-ld. This flag is documented as:

--allow-undefined Allow undefined symbols in linked binary. This options is equivalent to --import-undefined and --unresolved-symbols=ignore-all

The term "undefined" here specifically means with respect to symbol resolution in wasm-ld itself. Symbols used by wasm-ld correspond relatively closely to what native platforms use, for example all Rust functions have a symbol associated with them. Symbols can be referred to in Rust through extern "C" blocks, for example:

unsafe extern "C" { fn mylibrary_init(); } fn init() { unsafe { mylibrary_init(); } }

The symbol mylibrary_init is an undefined symbol. This is typically defined by a separate component of a program, such as an externally compiled C library, which will provide a definition for this symbol. By passing --allow-undefined to wasm-ld, however, it means that the above would generate a WebAssembly module like so:

(module (import "env" "mylibrary_init" (func $mylibrary_init)) ;; ... )

This means that the undefined symbol was ignored and ended up as an imported symbol in the final WebAssembly module that is produced.

The precise history here is somewhat lost to time, but the current understanding is that --allow-undefined was effectively required in the very early days of introducing wasm-ld to the Rust toolchain. This historical workaround stuck around till today and hasn't changed.

What's wrong with --allow-undefined?

By passing --allow-undefined on all WebAssembly targets, rustc is introducing diverging behavior between other platforms and WebAssembly. The main risk of --allow-undefined is that misconfiguration or mistakes in building can result in broken WebAssembly modules being produced, as opposed to compilation errors. This means that the proverbial can is kicked down the road and lengthens the distance from where the problem is discovered to where it was introduced. Some example problematic situations are:

• If mylibrary_init was typo'd as mylibraryinit then the final binary would import the mylibraryinit symbol instead of calling the linked mylibrary_init C symbol.

• If mylibrary was mistakenly not compiled and linked into a final application then the mylibrary_init symbol would end up imported rather than producing a linker error saying it's undefined.

• If external tooling is used to process a WebAssembly module, such as wasm-bindgen or wasm-tools component new, these tools don't know what to do with "env" imports by default and they are likely to provide an error message of some form that isn't clearly connected back to the original source code and where the symbols was imported from.

• For web users if you've ever seen an error along the lines of Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../". this can mean that "env" leaked into the final module unexpectedly and the true error is the undefined symbol error, not the lack of "env" items provided.

All native platforms consider undefined symbols to be an error by default, and thus by passing --allow-undefined rustc is introducing surprising behavior on WebAssembly targets. The goal of the change is to remove this surprise and behave more like native platforms.

What is going to break, and how to fix?

In theory, not a whole lot is expected to break from this change. If the final WebAssembly binary imports unexpected symbols, then it's likely that the binary won't be runnable in the desired embedding, as the desired embedding probably doesn't provide the symbol as a definition. For example, if you compile an application for wasm32-wasip1 if the final binary imports mylibrary_init then it'll fail to run in most runtimes because it's considered an unresolved import. This means that most of the time this change won't break users, but it'll instead provide better diagnostics.

The reason for this post, however, is that it's possible users could be intentionally relying on this behavior. For example your application might have:

unsafe extern "C" { fn js_log(n: u32); } // ...

And then perhaps some JS code that looks like:

let instance = await WebAssembly.instantiate(module, { env: { js_log: n => console.log(n), } });

Effectively it's possible for users to explicitly rely on the behavior of --allow-undefined generating an import in the final WebAssembly binary.

If users encounter this then the code can be fixed through a #[link] attribute which explicitly specifies the wasm_import_module name:

#[link(wasm_import_module = "env")] unsafe extern "C" { fn js_log(n: u32); } // ...

This will have the same behavior as before and will no longer be considered an undefined symbol to wasm-ld, and it'll work both before and after this change.

Affected users can also compile with -Clink-arg=--allow-undefined as well to quickly restore the old behavior.

When is this change being made?

Removing --allow-undefined on wasm targets is being done in rust-lang/rust#149868. That change is slated to land in nightly soon, and will then get released with Rust 1.96 on 2026-05-28. If you see any issues as a result of this fallout please don't hesitate to file an issue on rust-lang/rust.

We’re excited to highlight the work of Serah Nderi, a volunteer contributor to Pontoon who has quickly made a meaningful impact on the project. Since getting involved earlier this year, Serah has contributed a steady stream of improvements — including 10 patches in just the past two months — ranging from good-first issues to fully fledged features.

Serah joined the Mozilla community as an Outreachy intern on the SpiderMonkey team, where she demonstrated both strong technical skills and a passion for languages. That combination naturally led her to Pontoon, where she has been contributing not only as a developer but also as a localizer, exploring translations for languages like Kiswahili and Kikuyu.

Her latest contribution introduces long-awaited functionality for editing and deleting comments in Pontoon, improving collaboration and moderation workflows for translators and project managers alike.

You can follow Serah’s work on GitHub and connect with her on LinkedIn.

Last year, I earned a B1 certification in German and TOPIK I certification in Korean. This year, I decided to explore something at the intersection of technology and languages, which led me to start contributing to Pontoon.

Pontoon is Mozilla’s web-based localization platform, used by thousands of contributors to translate Firefox and other Mozilla projects into hundreds of languages.

I began by adding Kiswahili translations and exploring localization for my mother tongue, Kikuyu. While Kikuyu doesn’t yet have a project manager and presents unique challenges, it made the experience even more interesting. After working on a few good-first issues, I decided to take on a larger challenge: implementing a full feature—the ability for users to edit and delete comments.

Previously, users could only add comments. If a comment contained a typo or needed clarification, the only option was to add another comment. This often led to cluttered discussions and made collaboration less efficient. I set out to improve this experience.

Under the hood

The frontend implementation had a natural starting point. Pontoon comments already included actions like pinning, so adding Edit and Delete followed a similar interaction pattern.

One of the main challenges was handling comment content. Comments in Pontoon are stored as serialized HTML paragraphs with support for @mentions. To enable editing, I needed to deserialize this stored content back into the editor so that users would see a fully functional input field pre-populated with their original comment—including mentions. When saving, the content is serialized again before being stored.

In addition to the UI changes, I implemented the backend views for editing and deleting comments, along with the necessary tests. The final result allows users to edit and delete their own comments, while project managers can delete any comment for moderation purposes.

This feature makes discussions in Pontoon more flexible, reduces noise from duplicate comments, and improves the overall collaboration experience for localization teams.

Bugs resolved in Moz-Phab 2.11.1:

• bug 2028700 Only request AI review for updates if the --ai flag is passed

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

1 post - 1 participant

Read full topic

Bugs resolved in Moz-Phab 2.11.0:

• bug 2026935 moz-phab submit: add --test-plan flag

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

1 post - 1 participant

Read full topic

About you

My name is Cláudio Esperança, I’m from Portugal. I speak Portuguese and English. I have been contributing to Mozilla localization projects for more than 18 years.

Mozilla localization

Q: How did you first get involved in localization, and what drew you to Mozilla?

A: Curiosity has always driven me to understand how things work. Discovering open-source software, specifically Firefox and Linux, opened a world of limitless possibilities. I saw software translation not only as a way to improve my English but also as a great opportunity to start collaborating and contributing to the Mozilla mission. I began by following the community email list, contributing translations, and attending events. Before I knew it, I was leading the Portuguese translation team.

Q: You contribute across many projects in Pontoon. Is there a product that stands out to you? Have you shared with family and friends what you have been doing and promoting the products?

A: Firefox is always my favorite and the browser I use most regularly, as I trust it with my personal data. However, I contribute to all projects to provide users with more people-focused, secure, and private options, in a market often dominated by other vested interests.

I don’t actively promote my work, as I prefer when people discover Mozilla products because they are the best solution for their needs. It may seem counterintuitive, but actually, I love when I see someone using Firefox, or another Mozilla product, not because they feel pressured by something I said, but because they’ve discovered it’s the best solution for them. It is very gratifying to know that the strings I translate are used by thousands of people every day, including family, friends, coworkers, and many other people which I probably will never know.

Q: What have been some of the most rewarding or impactful projects you’ve localized?

A: Firefox is undoubtedly the most impactful due to its fundamental role on the web. I also found Firefox OS particularly interesting: the concept was great, and it had great potential, but unfortunately it didn’t go as far as I would have liked. I still hope to see it reborn in some form one day.

Q: What advice would you give to someone considering contributing to Mozilla localization today?

A: One of the best things about L10n at Mozilla is how accessible localization has become. You don’t need to be a developer to make a difference. Whether by starting with a smaller project to build up confidence or diving straight into a high-impact application, or focus on a tool you love or explore something entirely new, the choice is yours. The most important step is simply to begin. And there’s no such thing as a ‘small’ contribution — every translated word helps to build a more inclusive internet for everyone.

Community & leadership

Cláudio and Kit, celebrating 18+ years of Mozilla localization.

Q: How does the Portuguese localization community collaborate today?

A: The Portuguese community is small, and we don’t have many members with recurring contributions. One of the reasons they give for this disengagement is that they feel their help isn’t needed because our translation completion rate is high (which isn’t true at all). There are other reasons like lack of time (main reason), and the fact that a large portion of the user base are pretty comfortable using software in English, Brazilian, or Spanish.

Regarding community communication, while we previously used various discussion groups, we now primarily communicate via email and direct contact, with most of the work happening directly on Pontoon.

Q: You’ve been leading the team for many years. How do you approach mentorship and conflict resolution?

A: When I started, I didn’t have a mentor, so I had to rely on Mozilla’s resources and some reverse engineering. Today, platforms like Pontoon and SUMO make the process much easier for volunteers. Regarding conflicts, like all communities, we sometimes face significant challenges regarding personality and linguistic differences. Overall, we try to maintain a positive, constructive, and inclusive attitude, where all well-founded contributions are welcome. We use a democratic process for most decisions, with a “benevolent dictator” model as a final fallback if consensus cannot be reached.

Professional background & skills

Q: What is your professional background, and how has it influenced your localization work?

A: I have a background in software engineering (Master’s in Mobile Computing, Bachelor’s in Information Systems, technical training in TCP/IP networks, Linux, and other technologies). This experience helps me handle technical aspects of software translation like placeholder syntax, HTML tags, and technical terminology, though modern tools like Pontoon have made localization much more accessible to everyone.

Q: How has localization influenced your professional work?

A: Localization provides a unique perspective on applications by allowing a deeper understanding of how they work. We get to learn about the various options available in the software, sometimes hidden in the more obscure areas of the application. Unlike more traditional applications that rely on older technologies, applications developed within the Mozilla ecosystem are at the forefront of web innovation, allowing early exposure to the future of the Internet. As a software engineer, I incorporate these insights into my own projects to create more modern and user-friendly solutions.

Q: After 18+ years, what keeps you motivated to continue contributing?

A: Our mission remains unfinished. We have a responsibility to ensure the internet remains a global public resource that doesn’t require English as a barrier to entry. In an era where AI and massive platforms are consolidating power, the need for diverse alternatives has never been more urgent. Localizing Mozilla products into my native language is my way of practicing digital activism. It’s incredibly rewarding to know that a handful of translated sentences can improve the lives of so many people instantly. The mission continues…

Interesting facts

Q: Tell us something unexpected about yourself.

A: How someone born on an island in the Azores, who lived in half a dozen different cities in a country as small as Portugal, and who has worked as a farmer, shepherd, beekeeper, construction worker, electrician, trainer, programmer, and software engineer ended up translating world-class open-source software is a difficult story to explain. Ultimately, I think it all comes back to curiosity…

Bugs resolved in Moz-Phab 2.10.0:

• bug 2024404 Add --ai flag to moz-phab to trigger Review Helper automatically
• bug 2028164 moz-phab test failure: TypeError: Object of type AiReviewState is not JSON serializable

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

1 post - 1 participant

Read full topic

Welcome back from the Thunderbird development team!

Reflecting back, the first quarter of the year has been a mix of deep technical focus and forward-looking planning. Much of the team’s energy has gone into tackling some of the more complex, “gnarly” parts of our projects to land key milestones. In parallel, we’ve been laying the groundwork for what’s next from ongoing hiring efforts to aligning our goals with broader company initiatives that support the roadmap ahead.

Security & Hardening

We’ve continued to make good progress on improving Thunderbird’s security and privacy model, not just at a technical level, but in ways that are more usable and transparent for everyday users.

Unobtrusive Signatures

Kai recently presented his work at the IETF on Unobtrusive Signatures, which aims to make email signatures more reliable and less intrusive. The goal is to ensure message authenticity can be verified automatically and consistently, without requiring constant user attention or confusing workflows.

Improving Key Safety and Revocation

We’re also exploring better ways to handle key revocation. Today, users often have no reliable way to know when a key should no longer be trusted. A proposed revocation service aims to improve how this information is distributed, while avoiding overly centralized or privacy-invasive approaches.

Moving Beyond “Encrypted or Not”

A major shift underway is how we present trust in encrypted email.

Instead of treating encryption as a simple on/off state, we’re moving toward a graduated confidence model. Thunderbird will evaluate the strength of each recipient’s key whether it’s manually verified, CA-backed, or unverified, and present an overall confidence level to the user.

This allows encryption to work more automatically, while still giving users clear insight into how much trust they can place in a given message. Kai has worked with the design team and internal subject matter experts to refine the UX in this area and is getting close to a final UI. 

Ongoing Security Fixes and Improvements

Alongside these larger initiatives, Kai, Magnus, and Justin have been actively triaging and addressing security issues and long-standing feature gaps. Recent work includes:

• Enabling search within encrypted messages
• Fixing issues with incorrect IMAP literal size handling
• Addressing a link spoofing vulnerability (CVE-2025-13015)

Together, these efforts reflect a broader direction: making strong security more accessible, while ensuring users remain informed and in control.

Exchange Email Support

Since our last update in February, the team has been moving quickly and has now completed Phase 1 and Phase 2 of the Graph API implementation for email, with Phase 3 already underway.

These phases focused on establishing a solid foundation and delivering core functionality required for real-world usage. Highlights include:

• Graph API login with OAuth
• Connectivity checks and account validation
• Autodiscover support for Graph endpoints
• Folder synchronization (fetching and populating folder hierarchy)
• Sending messages (including support for different recipient types)
• Support for POST requests and improved request handling
• Delta query support for efficient syncing
• Support for pageable results (x-ms-pageable)
• Test infrastructure for Graph (xpcshell and mochitests)
• Continued backend refactoring and interoperability work (C++/Rust integration, shared protocol components)

With these milestones in place, Phase 3 is now underway, focusing on deeper message handling (such as fetching message headers) and continued feature expansion.

Keep track of our Graph API implementation here. 

Add-ons, Extensions and Experiments

While onboarding a new junior team member, John has also made a strong impact on the add-ons ecosystem, reaching an important milestone in the effort to move away from legacy, insecure experiments.

A key piece of this work is the VFS Toolkit, which leverages the Origin Private File System and introduces a more secure and maintainable way for WebExtensions to interact with the file system. As part of this, John developed a provider that allows extensions to access a user’s local home folder through a controlled interface.

Under the hood, this works by combining WebExtensions with a small native helper application. The extension communicates with this helper via native messaging, allowing safe, permissioned access to local files, something that modern WebExtensions cannot do directly

The current focus is to enhance the Calendar API ahead of the next ESR release with some of this work tracked here.

Linux System Tray – Contributor Spotlight

We’d like to give a special shoutout this month to Christophe Henry, who has gone above and beyond with an ambitious contribution to improve Thunderbird’s system tray integration on Linux.

This work isn’t a small patch and spans multiple parts of the codebase, including JavaScript, C++, and Rust, and even bridges into XPCOM interfaces. The goal is to unify how unread mail indicators and tray icons behave across platforms, which is a surprisingly complex problem once you account for the differences between Linux environments, Windows, and macOS.

What really stood out was the level of persistence behind this contribution. Over multiple iterations, Christophe worked through build failures, lint issues, platform quirks, and detailed review feedback, all while tackling tricky problems like image encoding, system tray APIs, and cross-language integration.

This kind of work is rarely straightforward, and often requires deep dives into unfamiliar parts of the stack. Seeing it pushed forward with this level of care and determination is exactly what makes open source collaboration so powerful.

Thank you for the dedication and effort! It truly makes a difference.

Calendar UI Rebuild – Front End Team shoutout

A huge shoutout to the Front End team, who recently met in person in London for a work week and absolutely delivered.

Getting the chance to collaborate face-to-face made a real difference. The team came together to align on priorities, cut through complexity, and focus on what mattered most – and the results speak for themselves. They successfully pushed through the Event Read and Enhancements milestones at an impressive pace, clearing the path to shift full attention onto the First Time User Experience (FTUE) work.

It’s not easy to balance quality, speed, and coordination across a distributed team, but this was a great example of what happens when everything clicks. Thoughtful planning, strong collaboration, and excellent execution all came together to move things forward in a big way.

Stay tuned to our milestones here:

• Event Read Dialog
• Event Read Enhancements
• Read Dialog inline editing
• Event Add/Edit Dialog
• Reminders UI
• Invitations Dialog
• Calendar Views

First Time User Experience (FTUE)

Following that strong push on Calendar, the front end team turned their focus to the First Time User Experience and made remarkable progress in a very short time.

In just a few weeks, the majority of the FTUE work has been completed, with only a handful of smaller items remaining in review. This included not only delivering the core experience, but also laying the groundwork for future improvements (such as early components of the “Sign in with Thundermail” flow, already available behind a preference).

Pulling together a milestone of this size on such a tight timeline is no small feat. It reflects both the clarity of planning coming out of the work week, and the team’s ability to execute quickly without losing sight of the bigger picture.

Maintenance, Upstream adaptations, Recent Features and Fixes

Over the past couple of months, the team has continued to navigate changes from upstream dependencies that occasionally impact build stability, test reliability, and CI. While this is a normal part of working in a large, shared ecosystem, it does require ongoing attention, particularly when tracking down the root cause of regressions and ensuring Thunderbird-specific changes remain on solid ground. Some days it feels like a full-time job!

Alongside this, we’ve seen strong support from both the team and the wider contributor community, with a steady stream of fixes and improvements landing across the codebase.

This collective effort has resulted in a number of impactful patches landing recently, with the following being particularly helpful:

• Fixing several bugs in our Event Read milestone
• Calendar event URL protocol handler fix
• Fix POP3 state deadlock
• and many more which are listed in release notes for beta.

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: March 2026 appeared first on The Thunderbird Blog.