fidzu : Mozilla

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.

09 Apr 2026 5:03pm GMT

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.

09 Apr 2026 4:35pm GMT

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.

09 Apr 2026 12:00am GMT

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

08 Apr 2026 6:04pm GMT

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

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

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• docs.rs: building fewer targets by default
• Changes to WebAssembly targets and handling undefined symbols
• Leadership Council update - March 2026

Foundation

• What's Next for the Rust Innovation Lab?
• Rust Foundation Interop Initiative Update: From Research to Implementation

Newsletters

• This Month in Rust OSDev: March 2026

Project/Tooling Updates

• Surelock
• Rust for CPython Progress Update April 2026
• RustRover 2026.1: Professional Testing With Native cargo-nextest Integration
• Toasty, an async ORM for Rust, is now on crates.io
• slopc: The cursed macro Rust maintainers never anticipated
• Processing 1M Chess Games in 15 Seconds with Rust
• Dumap v1.1: Cross-platform disk usage treemap visualization
• Proxelar 0.4.0: Intercept & Modify Traffic
• amoxide: composable, context-aware shell aliases
• Ply 1.1: Building Polished UIs in Rust
• Myth Engine: A compiler-style RenderGraph for cross-platform rendering
• selinux-explain

Observations/Thoughts

• Callgraph analysis
• Fixing our own problems in the Rust compiler
• 800 Rust terminal projects in 3 years
• What We Learned Building a Rust Runtime for TypeScript
• Supply chain nightmare: How Rust will be attacked and what we can do to mitigate the inevitable
• Building an SSA-Based Declarative Render Graph in Rust
• [audio] Protocol Shorts: TLS Encrypted Client Hello

Rust Walkthroughs

• Learn Rust Basics By Building a Brainfuck Interpreter
• How uv Works Under the Hood
• Building Postgres compatibility in Rust: pgwire and DataFusion
• [video] impl Rust: WAV noise generator

Miscellaneous

• [video] Rust/C++ Interop Challenges - Victor Ciura - CppCon 2025

Crate of the Week

This week's crate is aimdb-core, a type-safe and platform-agnostic data pipeline where the Rust type system is the schema and trait implementations define its behavior.

Thanks to sounds.like.lx 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.

• Wild Almonds - Shared Audio Player library for flutter and Tauri

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.

• NDC Techtown | CFP open until 2026-04-14 | Kongsberg, Norway | 2026-09-09 - 2026-09-12.
• EuroRust | CFP open until 2026-04-27 | Barcelona, Spain | 2026-10-14 - 2026-10-17

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

479 pull requests were merged in the last week

Compiler

• compute the result of a projection type with region errors
• make layout_of cycles fatal errors
• properly generalize unevaluated consts

Library

• add integer truncation and extension methods
• debugger visualizers: optimize lookup behavior
• impl Step for NonZero<u*>
• introduce #[diagnostic::on_move] on Arc
• make substr_range and subslice_range return the new Range type
• more informative Debug for vec::ExtractIf
• stabilize new Range type and iterator

Cargo

• lints: Emit unused_dependencies lint
• compile: Don't hide hard warnings with build.warnings=allow
• compile: build.warnings=allow should not hide denied diagnostics
• install: Ignore resolver.lockfile-path
• add frame-pointers profile option
• set CARGO env var during rustc -vV probe
• send Content-Type header with cargo publish requests
• simplified build script bin names in new layout
• split out cargo-util-terminal
• warn on invalid jobserver file descriptors

Clippy

• unsafe_removed_from_name: skip linting when renaming to '_'
• unnecessary type cast causing a compile error
• multiple fixes to false negatives of question_mark
• perf: disable nonminimal_bool by default
• rework expr_use_ctxt into an iterator over successive use sites
• unneeded wildcard improvement

Rust-Analyzer

• add support for folding ranges for chained expressions
• implement thin-arrow completion in fn return position
• offer on tail-expr with else-branch for if_let_to_guarded assist
• support labeled block for convert_to_guarded_return
• support macro expansion in #[doc = ...] attributes
• fix extract function invalid self param
• add semicolon for postfix format unit like snippets
• fix a cycle in bounds lowering
• fix extract variable on arg with comma
• fix indent for convert_let_else_to_match
• fix param inlayHints on empty expr and comma
• fix stale diagnostics when a custom check command is configured
• fix SyntaxEditor upmapping of nodes with mapped ancestor that aren't mapped themselves
• improve inserted order for trait_impl_redundant_assoc_item
• load rust-analyzer.toml for virtual workspaces
• not suggest name in nested type in variant
• offer 'type_mismatch' some fixes inside macro
• offer on empty else block for 'convert_let_else_to_match'
• report expected type, found { in parser
• silence type mismatch diagnostic when type is unknown
• support cfg-ing array elements
• support filesystems that don't send Create events
• support multiple snippet placeholders in VS Code extension
• unconditionally pass --include-ignored for test runnables
• use the correct project root when there are multiple workspaces
• wrap parentheses on guard for replace_if_let_with_match
• impl Display type hint inlay hints at the end of the line
• implement feature(more_qualified_paths)
• make matching brace work when cursor not at bracket
• move mutability responsibility from caller to edit_algo
• move syntax editor initialization invariants to its constructor
• publish no-server to Code Marketplace and OpenVSX
• replace add trait assoc items to impl with its factory variant

Rust Compiler Performance Triage

A shorter week than normal (probably due to later perf triage last week). Overall fairly small changes scattered across various PRs, though the net effect was slightly positive (-0.5% avg change). All changed ended up either mixed or improvements this week.

Triage done by @simulacrum. Revision range: cf7da0b7..e73c56ab

0 Regressions, 3 Improvements, 8 Mixed; 5 of them in rollups 26 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:

• No RFCs were approved 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

• report the varargs_without_pattern lint in deps
• Partially stabilize LoongArch target features
• Never break between empty parens

Cargo

• No Cargo Tracking Issues or PRs entered Final Comment Period this week.

Compiler Team (MCPs only)

• cargo clean: Add target directory validation

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

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

New and Updated RFCs

• Propose the concept of a crates.io username for identity
• RFC: Inheriting of default-features in Cargo
• Add Bitbucket Cloud OAuth login for crates.io
• MIR move elimination

Upcoming Events

Rusty Events between 2026-04-08 - 2026-05-06 🦀

Virtual

• 2026-04-09 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-04-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-04-14 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-04-14 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Web development using axum in Rust - part 3
• 2026-04-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Nushell
• 2026-04-15 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-04-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • April, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-04-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-04-21 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-04-22 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-04-23 | Virtual (Amsterdam, NL) | Bevy Game Development
  • Bevy Meetup #13
• 2026-04-23 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-04-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-04-28 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: From Protobuf to Production - A Guide to gRPC in Rust
• 2026-04-29 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-05-01 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Hacker's Hike 0x1
• 2026-05-02 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-05-03 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-05-06 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing

Asia

• 2026-04-11 | Bangalore, IN | Rust Bangalore
  • April 2026/Pre-Conference Rustacean meetup
• 2026-04-17 | Bangalore, IN | Rust India
  • Rust India Workshop
• 2026-04-18 | Bangalore, IN | Rust India
  • Rust India Conference

Europe

• 2026-04-08 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 04 2026
• 2026-04-09 | Geneva, CH | Rust Meetup Geneva
  • Rust Meetup Geneva
• 2026-04-09 | Oslo, NO | Rust Oslo
  • Rust talks @ AutoStore - "Patterns for Event Driven Systems" and "Rust + WASM"
• 2026-04-21 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Native GUIs with Rust
• 2026-04-23 | Aarhus, DK | Rust Aarhus
  • Talk Night and Birthday Party at MFT Energy
• 2026-04-24 - 2026-04-26 | Augsburg, DE | Rust Meetup Augsburg
  • Future Week Augsburg: Road to Game Jam - Spielend Bevy und Rust lernen bei Tuxedo Computers
• 2026-05-02 | Augsburg, DE | Rust Munich and Rust Augsburg
  • Augsburger Linux-Infotag 2026: Gemeinschaftsstand Rust Augsburg und Rust München
• 2026-05-04 | Frankfurt, DE | Rust Rhein-Main
  • Writing a stock portfolio simulation in Rust with Leptos

North America

• 2026-04-09 | Chicago, IL, US | Chicago Rust Meetup
  • Rust Happy Hour
• 2026-04-09 | Lehi, UT, US | Utah Rust
  • Utah Rust April Meetup
• 2026-04-09 | Montréal, QC, CA | Rust Montréal
  • April Monthly Social
• 2026-04-09 | Portland, OR, US | PDXRust
  • Hexadecimal Floating Point? Why? How?
• 2026-04-09 | San Diego, CA, US | San Diego Rust
  • San Diego Rust April Meetup - Back in person!
• 2026-04-11 | Boston, MA, US | Boston Rust Meetup
  • Brookline Rust Lunch, Apr 11
• 2026-04-14 | Charlottesville, VA, US | Charlottesville Rust Meetup
  • Sharpening Your Rust Skills for Job Interviews
• 2026-04-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Nushell
• 2026-04-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • April, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-04-16 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-04-16 | Nashville, TN, US | Music City Rust Developers
  • Community Meetup
• 2026-04-18 | Boston, MA, US | Boston Rust Meetup
  • Harvard Square Rust Lunch, Apr 18
• 2026-04-20 - 2026-04-22 | Portland, OR | Tokio
  • TokioConf 2026
• 2026-04-21 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-04-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-04-22 | New York, NY, US | Rust NYC
  • Rust NYC: Formally Verified Rust & SAT Solvers
• 2026-04-23 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA April!
• 2026-04-25 | Boston, MA, US | Boston Rust Meetup
  • South Station Rust Lunch, Apr 25
• 2026-04-30 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl

Oceania

• 2026-04-09 | Brisbane City, QL, AU | Rust Brisbane
  • Rust Brisbane Apr 2026

South America

• 2026-04-11 | Buenos Aires, AR | Oxidar Org
  • Oxidar.org Hackaton - Snakear - ¡Veni a hackear con Rust!
• 2026-04-17 | Rio de Janeiro, BR | Meetups Rust RJ
  • Meetup Rust RJ

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

Rust tried to have polymorphic generics in the early pre-1.0 days, and they quite reasonably gave up because it was too much work. For real Swift, great fucking working for getting all of this to work!

- Aria Desires on her blog

llogiq thanks himself for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

08 Apr 2026 4:00am GMT

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

07 Apr 2026 10:05pm GMT

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

07 Apr 2026 3:37pm GMT

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.

04 Apr 2026 12:00am GMT

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.

04 Apr 2026 12:00am GMT

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.

03 Apr 2026 10:00am GMT

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

02 Apr 2026 8:26pm GMT

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

01 Apr 2026 4:33pm GMT

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

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

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Announcing Rust 1.94.1
• Program management update - February 2026

Foundation

• Rust Foundation Joins Datadog's Open Source Program

Project/Tooling Updates

• Ntpd-rs: it's about time!
• octopos: OS for risc-v in rust
• Building a guitar trainer with embedded Rust
• blogr v0.5.0 - blog without leaving your terminal
• feedr v0.7.0 - terminal-based RSS/Atom feed reader
• mdterm v2.0.0 - terminal-based Markdown browser
• RustGrep: simple search for 114 Rust blogs
• Rust's next-generation trait solver
• Portable Async Rust
• jsongrep faster than {jq, jmespath, jsonpath-rust, jql}
• SeqPacker: 11 bin-packing algorithms in Rust
• flodl v0.2.2: PyTorch parity in Rust

Observations/Thoughts

• filtra.io | Breaking The AI Infra Monopoly With Rust- Tracel AI
• Rust: Memory safety in kernel space | OSHub
• Fixing our own problems in the Rust compiler
• Bugs that the Rust compiler catches for you: The revolution of compiler-enforced correctness
• I ported the OpenAI Python SDK to Rust in 5 days with Claude Code
• [video] 🦀 Rust (mir) compiler bites: Closures - thou shalt not name this struct
• [video] How C++ Finally Beats Rust at JSON Serialization

Rust Walkthroughs

• Adding WASM Plugins to Your App
• ZK snarks for rust developer part 3/8
• Building a Crash-Safe Email Queue in Rust
• Adding a Scripting Engine to a Rust CLI with Rhai

Crate of the Week

This week's crate is tsastat, a high-resolution Thread State Analysis (TSA) tool for Linux.

Thanks to Ankur Rathore 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.

• NDC Techtown | CFP open until 2024-04-14 | Kongsberg, Norway | 2024-09-09 - 2026-09-12.
• EuroRust | CFP open until 2026-04-27 | Barcelona, Spain | 2026-10-14 - 2026-10-17

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

487 pull requests were merged in the last week

Compiler

• add x86_64-unknown-linux-gnu{m,t}san target which enables {M,T}San by default
• add -Zsanitize=kernel-hwaddress

Library

• constify Step trait and all of its implementations
• constify comparisons and Clone for core::mem::Alignment
• constify const Fn*: Destruct
• don't drop arguments' temporaries in dbg!
• don't fuse in MapWindows
• implement unchecked_funnel_{shl,shr}
• reimplement hash_map! macro
• make PinCoerceUnsized require Deref
• stabilize new RangeFrom type and iterator
• trim_prefix for paths

Cargo

• resolver: better match rustc in error styling
• build: cover more behavior of build.warnings
• build: make it easier to review build.warnings behavior

Rustdoc

• rustdoc rejects html emits with json output

Rustfmt

• prevent panic when rewritng associated item delegations

Clippy

• add manual_option_zip lint (a.and_then(|x| b.map(|y| (x, y))))
• impl manual_noop_waker lint
• explicit_counter_loop: suggest .take(n) for for _ in 0..n co…
• iter_kv_map: handle identity map for map and flat_map
• manual_pop_if: lint more cases, even if we do not provide a suggestion
• fix collapsible_if false positive when the inner if contains cfg
• preserve parentheses in suggestion in presence of cascaded casts
• perf: reduce matching_root_macro_call usage (23b → 22.24b)

Rust-Analyzer

• fix not applicable on ambiguous ident pat for merge_match_arms
• complete envs in nested env!()
• correct type_or_const param index bound in debug_assert
• correct missing-args messages for sched_getaffinity and getenv shims
• don't panic unmerge arm on trailing pipe
• fix block lowering in ast id map
• keep comments for 'Fill match arms'
• postfix completions include nots prefix-expr
• skip usages inside macro expansions in destructure struct/tuple binding
• turn back TyLoweringContext.store to self after lowering parent defaults
• wrap Option<> for desugar_try_expr_let_else
• wrap Result<> for desugar_try_expr_let_else
• wrap ty-anchor in non-path type constuctor
• fully implement VariantFields expression support
• hookup Signature Inference in more places
• only allocate item blocks if they actually contain items or statement macros
• remove Arc from GenericParams and AstIdMap
• remove generate trait impl text intransitive from utils

Rust Compiler Performance Triage

We had some infrastructure troubles this week which prevented some rollup PRs from generating their "unrolled" builds, which made rollup regression investigation more complicated, although we were able to locate and revert the largest rollup regressions in the end. #154304 brought some nice improvements by optimizing the query system.

Triage done by @kobzol. Revision range: 6f22f613..cf7da0b7

Summary:

3 Regressions, 4 Improvements, 2 Mixed; 2 of them in rollups 35 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:

• Mitigation enforcement
• Add homogeneous_try_blocks

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

• Tracking Issue for isolate_most_least_significant_one
• Tracking Issue for int_lowest_highest_one
• Tracking Issue for uint_bit_width
• Tracking Issue for #138068: Add Result::map_or_default and Option::map_or_default
• Do not use non-wf input expectations from fudge when checking function calls
• Syntactically reject equality predicates
• Tracking Issue for tcp_deferaccept
• stabilize s390x vector registers
• Replacing self overwriting with proper resolution

Rust RFCs

• build-std: always

No Items entered Final Comment Period this week for Cargo, Compiler Team (MCPs only), Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines.

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

New and Updated RFCs

• RFC: Associated traits
• Add *be present* contribution policy
• initial draft for 2026 project goals

Upcoming Events

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

Virtual

• 2026-03-26 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-03-31 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Web development using axum in Rust - part 1
• 2026-04-01 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-04-01 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-04-02 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-04-04 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-04-05 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-04-07 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Web development using axum in Rust - part 2
• 2026-04-09 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-04-14 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Web development using axum in Rust - part 3
• 2026-04-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-04-14 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-04-15 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-04-15 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Nushell
• 2026-04-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • April, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-04-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-04-21 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-04-22 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-04-23 | Virtual (Amsterdam, NL) | Bevy Game Development
  • Bevy Meetup #13
• 2026-04-23 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-04-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-04-28 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: From Protobuf to Production - A Guide to gRPC in Rust
• 2026-04-29 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session

Asia

• 2026-04-11 | Bangalore, IN | Rust Bangalore
  • April 2026/Pre-Conference Rustacean meetup
• 2026-04-17 | Bangalore, IN | Rust India
  • Rust India Workshop
• 2026-04-18 | Bangalore, IN | Rust India
  • Rust India Conference

Europe

• 2026-04-01 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-04-01 | Edinburgh, UK | Rust and Friends
  • Rust and Friends (evening pub)
• 2026-04-01 | Köln, DE | Rust Cologne
  • Rust in April: From Zero to Rust
• 2026-04-01 | Oxford, UK | Oxford ACCU/Rust Meetup.
  • It came from another dimension!
• 2026-04-02 | London, UK | Rust London User Group
  • LDN Talks Spring Community Showcase
• 2026-04-02 | Toulouse, FR | Rust Toulouse
  • Rust Toulouse Meetup - Release, Servers & Ray Tracing Demystified
• 2026-04-03 | Edinburgh, UK | Rust and Friends
  • Rust and Friends (daytime coffee)
• 2026-04-07 | Basel, CH | Rust Basel
  • Rust Meetup #15 @ letsboot
• 2026-04-07 | Frankfurt, DE | Rust Rhein-Main
  • Building a drone from scratch with Rust (and some hardware)
• 2026-04-08 | Virtual (Girona, ES) | Rust Girona
  • Rust Girona Hack & Learn 04 2026
• 2026-04-09 | Geneva, CH | Rust Meetup Geneva
  • Rust Meetup Geneva
• 2026-04-09 | Oslo, NO | Rust Oslo
  • Rust talks @ AutoStore - "Patterns for Event Driven Systems" and "Rust + WASM"
• 2026-04-21 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Native GUIs with Rust
• 2026-04-23 | Aarhus, DK | Rust Aarhus
  • Talk Night and Birthday Party at MFT Energy

North America

• 2026-04-02 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-04-02 | Saint Louis, MO, US | STL Rust
  • SIUE Cruft Crawler with LLM
• 2026-04-04 | Boston, MA, US | Boston Rust Meetup
  • Winter Hill Rust Lunch, Apr 4
• 2026-04-07 | New York, NY, US | Rust NYC
  • Rust NYC: The Open Source Special
• 2026-04-09 | Chicago, IL, US | Chicago Rust Meetup
  • Rust Happy Hour
• 2026-04-09 | San Diego, CA, US | San Diego Rust
  • San Diego Rust April Meetup - Back in person!
• 2026-04-11 | Boston, MA, US | Boston Rust Meetup
  • Brookline Rust Lunch, Apr 11
• 2026-04-14 | Charlottesville, VA, US | Charlottesville Rust Meetup
  • Sharpening Your Rust Skills for Job Interviews
• 2026-04-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Nushell
• 2026-04-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • April, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-04-18 | Boston, MA, US | Boston Rust Meetup
  • Harvard Square Rust Lunch, Apr 18
• 2026-04-20 - 2026-04-22 | Portland, OR | Tokio
  • TokioConf 2026
• 2026-04-21 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-04-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-04-23 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA April!
• 2026-04-25 | Boston, MA, US | Boston Rust Meetup
  • South Station Rust Lunch, Apr 25

Oceania

• 2026-04-09 | Brisbane City, QL, AU | Rust Brisbane
  • Rust Brisbane Apr 2026

South America

• 2026-04-11 | Buenos Aires, AR | Oxidar Org
  • Oxidar.org Hackaton - Snakear - ¡Veni a hackear con Rust!
• 2026-04-17 | Rio de Janeiro, BR | Meetups Rust RJ
  • Meetup Rust RJ

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

When you do cursed things, problems find you.

- Folkert de Vries on the trifecta tech blog

We have gone four weeks bare of suggestions for quotes. llogiq is still fine with his choice, but he'd be much more happy if any of you would help him in his search.

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

01 Apr 2026 4:00am GMT

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…

01 Apr 2026 3:32am GMT

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

31 Mar 2026 8:30pm GMT

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.

31 Mar 2026 11:30am GMT