fidzu : Mozilla

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

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

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

Introduction

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

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

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

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

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

The Original Experience

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

Design Considerations

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

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

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

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

The New Experience

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

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

Looking Ahead

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

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

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

06 Jul 2026 4:13pm GMT

Hi Mozillians, welcome to another Mozilla community roundup!

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

Let's dive in!

✨ Firefox gets a fresh new look. Soon!

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

Learn more

Firefox can do all this?

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

Read more

From the Reddit Community

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

Read the full AMA

Community spotlight

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

Read more

---

P.S.

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

06 Jul 2026 3:45am GMT

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

The role of PETs in building a better internet

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

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

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

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

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

The discussion

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

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

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

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

What comes next

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

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

03 Jul 2026 10:36am GMT

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.96.1 | Rust Blog
• The many journeys of learning Rust | Rust Blog

Foundation

• Rust Foundation Trusted Training Program Launches, Giving Learners a Mark of Quality to Trust

Newsletters

• Scientific Computing in Rust #19 (June 2026)

Project/Tooling Updates

• Slint 1.17 Released
• rustc_codegen_gcc: Progress Report #42
• Introducing Test That!
• Introducing Test That!: A rich test assertion library for Rust from the original author of GoogleTest Rust
• Inside RSSH: one Rust crate, three binaries, and the Tauri lessons along the way
• Rustty 1.38 - accessibility & keyboard nav
• GuardianDB 0.17.0: Secure namespaces, Iroh 1.0, and the arrival of the ODM
• Building a real-time voice-agent runtime in Rust: no GIL, one binary, 2,000 calls a box
• AimDB: Bring Your Own Connector
• kache 0.8.0: zero-copy restores on Windows (ReFS)
• Warbell - a castle-defense action-RPG built with Bevy 0.19
• I built a macOS FTP client entirely in Rust - no Electron, no webview

Observations/Thoughts

• Hoisting Expressions
• The Unglamorous Side of Rust Web Development
• How I Found Out 52% of My Knowledge Graph Was Duplicates (and What I Did About It)
• A Novel Approach to Rust Error Handling
• We put a Redis server inside our runtime
• High-performance Rust: Understanding and eliminating memory fragmentation
• AI and worktrees are filling our disks: kache storage, measured
• Designing a cross-platform terminal memory visualizer in Rust
• Your Rust Service Isn't Leaking - It Could Be the Allocator

Rust Walkthroughs

• Measure, Don't Guess: Building viser, a Content-Adaptive Video Encoding Optimizer in Rust
• Learn SQL and SQLx by Building a Book Library CLI in Rust
• [series] Reasoning About Async Rust with State Machines
• The C to Rust Migration Book

Crate of the Week

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

Thanks to pbkx for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

multicalc - good first issues

• AimDB - Add minimal example: hello-single-latest
• AimDB - Wire .transform() and .transform_join() into stage profiling
• edid-info - Increase test coverage with real EDID data
• edid-info - Finalize CTA-861 extension implementation
• edid-info - Support additional EDID extension block types

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

CFP - Events

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

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

Updates from the Rust Project

426 pull requests were merged in the last week

Compiler

• drop the full-crate AST walk in check_unused
• make stable_crate_ids reads lock-free after crate loading
• rework lint pass running
• simplify some proc_macro things

Library

• add io::ErrorKind::TooManyOpenFiles
• expand OptionFlatten's iterator methods
• move std::io::Error into core
• optimize network address parser

Cargo

• add -Zhint-msrv flag

Clippy

• filter_map_next: clean-up, overhaul suggestions
• chunks_exact_to_as_chunks: Prevent syntactically invalid suggestions
• chunks_exact_to_as_chunks: Use correct method name in message
• chunks_exact_to_as_chunks: Pick iter method depending on mut-ness
• non_ascii_literal, invisible_characters: don't suggest a fix on raw strings
• create a single ConstEvalCtxt in expr_eagerness
• detect new range types in higher::Range
• do not trigger manual_option_zip when map receiver is a lazy evaluated expression
• enhance needless_late_init to cover grouped assignments
• fix: borrow_as_ptr is triggered on generated code

Rust-Analyzer

• add diagnostic for E0596
• add fixes add '.await' for type_mismatch
• crash on lowering consts with associated types
• crash when hovering on anonymous consts
• only run Drop::drop when implemented
• mark inline_convert_while_ascii() as unsafe
• switch out lsp-types for gen-lsp-types

Rust Compiler Performance Triage

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

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

2 Regressions, 1 Improvement, 7 Mixed; 5 of them in rollups 34 artifact comparisons made in total

Full report here

Approved RFCs

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

• 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

• Tracking Issue for LocalKey/Cell::update
• Tracking Issue for {str, [T], Path}::trim_prefix and {str, [T]}::trim_suffix
• Stabilize c-variadic function definitions
• Tracking Issue for layout information behind pointers
• Fix feature gate for repr(simd)
• reat no_mangle_generic_items as hard error instead of lint warning
• Lint against invalid POSIX symbol definitions
• Fix overflowing_literals lint with repeated negation
• stabilize extern "custom"
• Don't escape U+FF9E and U+FF9F in escape_debug_ext

Compiler Team (MCPs only)

• Decouple BackendRepr from ABI alignment
• MCP: Stabilization strategy for rustc parallel frontend

Language Reference

• Fields must fit in the type, even for repr(Rust)

Rust RFCs

• RFC: Associated const underscore
• Add extern "custom"

Unsafe Code Guidelines

• Opsem extension proposal: atomic volatile accesses

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

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

New and Updated RFCs

• Method chain as item
• Add extern "custom"

Upcoming Events

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

Virtual

• 2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-07-02 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-02 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Learning Game Development the Hard Way with Rust and Bevy
• 2026-07-02 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-07-04 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-07-05 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-07-07 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-07-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-16 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-07-21 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: Learning Rust as First Programming Language
• 2026-07-21 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-07-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday

Asia

• 2026-07-18 | Bangalore, IN | Rust Bangalore
  • July 2026 Rustacean Meetup

Europe

• 2026-07-01 | Köln, DE | Rust Cologne
  • Rust in July: Vecs and Strings and Slices, Oh My!
• 2026-07-01 | Manchester, UK | Rust Manchester
  • Rust Manchester June Talks
• 2026-07-01 | Oxford, UK | Oxford ACCU/Rust Meetup.
  • Building a file system from scratch
• 2026-07-02 | Edinburgh, UK | Rust and Friends
  • Bevy, Bits, & Cats (Rust July Talks)
• 2026-07-02 | Enschede, NL | Baseflow Tech Meetups
  • AI Summit
• 2026-07-08 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 262
• 2026-07-09 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva
• 2026-07-21 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Supercharge Rust funcs with implicit arguments and context-generic programming
• 2026-07-23 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-07-23 | London, UK | London Rust Project Group
  • Rama modular service framework for Rust
• 2026-07-23 | Paris, FR | Rust Paris
  • Rust meetup #87

North America

• 2026-07-02 | Saint Louis, MO, US | STL Rust
  • Git is easy?
• 2026-07-04 | Boston, MA, US | Boston Rust Meetup
  • Boston University Rust Lunch, July 4
• 2026-07-09 | Lehi, UT, US | Utah Rust
  • Utah Rust July Meetup
• 2026-07-11 | Boston, MA, US | Boston Rust Meetup
  • MIT Rust Lunch, July 11
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-18 | Boston, MA, US | Boston Rust Meetup
  • North End Rust Lunch, July 18
• 2026-07-21 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-07-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Distributed Systems with Flight Science!
• 2026-07-25 | Brooklyn, NY, US | Flower
  • BOG-A-THON 2

Oceania

• 2026-07-21 | Barton, AU | Canberra Rust User Group
  • July Meetup
• 2026-07-23 | Perth, AU | Rust Perth Meetup Group
  • Rust Perth: July Meetup!

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

Jobs

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

Quote of the Week

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

- workingjubilee on rust zulip

Thanks to Tomáš Šedovič for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• 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 Jul 2026 4:00am GMT

Github Link

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

• Bug 1726931 - New issues should displayed on "My Dashboard" for first time users instead of assigned bugs
• Bug 1834454 - [WEBHOOKS] Webhooks for a product change don't fire if product is changed away from the target product
• Bug 1684509 - Have a single button to mark a bug as abusive/spam

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

01 Jul 2026 12:55am GMT

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

We've shipped several new web platform features:

• 'font-kerning: none' (@simonwuelker, #44634)
• 'font-variant-east-asian' (@simonwuelker, #44989)
• 'font-variant-ligatures' (@simonwuelker, #44903)
• 'font-variant-numeric' (@simonwuelker, #44950)
• 'font-variant-position' (@simonwuelker, #45142)
• mp4 files without fast start in <video> (@calvaris, #45084)
• <form enctype="multipart/form-data"> (@yezhizhen, #45028)
• <form enctype="text/plain"> (@yezhizhen, #45111)
• <![CDATA[]]> layout (@mrobinson, #44791)

Plus a bunch of new DOM APIs:

• onslotchange property on Shadow­Root (@jdm, #44688)
• screen­Left and screen­Top on Window (@TG199, #45128)
• new Blob() with {endings: "native"} (@yezhizhen, #44803)
• new Performance­Mark() (@shubhamg13, #44702)
• parse­HTML() on Document (@kkoyung, #44952)
• read­As­Binary­String() on File­Reader (@yezhizhen, #44858, #44921)
• performance.measure() with mark values 'redirect­Start', 'redirect­End', 'secure­Connection­Start', and 'response­End' (@shubhamg13, #44673, #44624, #44850, #44739)

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

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

• Security
  - memory safety fixes

• Work in progress
  - execCommand(), Sanitizer, IndexedDB, accessibility, workers

• Embedding API
  - MSRV, cookies, preferences, diagnostics

• For users and developers
  - --host-file, --userscripts, DevTools Debugger

• More on the web platform
  - focus, forms, navigation, SubtleCrypto, WebGPU

• Performance
  - about:memory, threads, layout, DOM, build times

• Stability
  - crashes, hangs, static analysis

Security

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

Work in progress

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

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

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

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

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

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

Embedding API

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

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

• Site­Data­Manager::clear­_cookies now takes an additional callback argument, allowing it to be called async - to continue calling it sync, pass None as the callback

• Site­Data­Manager::clear­_session­_cookies now takes an additional callback argument, allowing it to be called async - to continue calling it sync, pass None as the callback

• Site­Data­Manager::set­_cookie­_for­_url now takes an additional callback argument, allowing it to be called async - to continue calling it sync, pass None as the callback

• Site­Data­Manager::set­_cookie­_for­_url­_async has been removed in favour of set­_cookie­_for­_url - to migrate, replace set­_cookie­_for­_url­_async(​callback) with set­_cookie­_for­_url(​Some(​Box::new(​callback)))

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

• threadpools­_image­_cache­_workers­_max, threadpools­_indexeddb­_workers­_max, and threadpools­_webstorage­_workers­_max have been removed in favour of a combined thread­_pool­_workers­_max

• threadpools­_fallback­_worker­_num has been renamed to thread­_pool­_fallback­_workers

• threadpools­_async­_runtime­_workers­_max has been renamed to thread­_pool­_async­_runtime­_workers­_max

• threadpools­_webrender­_workers­_max has been renamed to thread­_pool­_webrender­_workers­_max

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

• You can now set options with DiagnosticsLogging::toggle­_option, and check if they are enabled with DiagnosticsLogging::is­_enabled

• Each option is a variant of DiagnosticsLoggingOption, a new type that also has useful methods for exposing these options in embedder UI

• (Breaking change) DiagnosticsLogging no longer has pub fields representing each option - to migrate, replace field writes and field reads with toggle­_option and is­_enabled respectively

• (Breaking change) DiagnosticsLogging::extend­_from­_string no longer accepts a help option - this option only existed to support servoshell's -Z help / --debug=help option, so the code implementing it has been moved to servoshell

For users and developers

servoshell has two new options:

• You can now configure the path to a hosts file with --host-file= (singular), as an alternative to the HOST_FILE (singular) environment variable (@jschwe, #44880).

• You can now provide a directory of user scripts to run in every document with --userscripts= (@jdm, #44754).

When using the Debugger tab in the Firefox DevTools:

• You can now "blackbox" a script by clicking Ignore source (@freyacodes, #44359). This prevents breakpoints from being hit inside that script, and it should also allow you to step through execution in the debugger without pausing inside that script.

• The Scopes panel is more accurate now (@atbrakhi, @eerii, #44765).

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

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

More on the web platform

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

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

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

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

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

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

Performance

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

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

We've landed a bunch of layout optimisations:

• The fragment tree is now immutable for the most part, with small pockets of interior mutability where mutability is needed. This means that most fragment tree accesses no longer have to incur the runtime cost of borrowing an AtomicRefCell (@mrobinson, @Loirooriol, #44849).

• Two steps in the layout process, calculating containing blocks and building the stacking context tree, require traversing the fragment tree. This can be expensive, but we've now combined them into a single fragment tree traversal in most cases (@SimonSapin, @mrobinson, #44911, #45210).

• Another step in the layout process, calculating scrollable overflow, used to require traversing the entire fragment tree. We've effectively eliminated that traversal, by making the calculation both lazy and incremental (@mrobinson, @Loirooriol, #44854).

• We've improved the caching of fragments, shaping results, and other layout results between reflows (@mrobinson, @Loirooriol, @SimonSapin, #45038, #44769).

• We've made incremental fragment layout more precise (@Loirooriol, @mrobinson, #44925).

• We've reduced the memory usage of text shaping (@mrobinson, @SimonSapin, #44609).

DOM attributes are much more efficient in this release:

• When scripts write attribute values, we avoid serialising them until the attribute is read back by a script (if ever), speeding up frequent writes to inline styles by up to 25% (@mrobinson, #44931).

• When we parse attributes in HTML or read attribute values internally, we avoid constructing Attr nodes until a script actually needs them, reducing memory usage and making garbage collection less likely (@webbeef, @TimvdLippe, @mrobinson, #44209, #45023, #45031, #45060).

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

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

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

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

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

Stability

Several crashes and hangs have been fixed:

• in 'content' (@mrobinson, @Loirooriol, @SimonSapin, #45227, #44762)
• in Media­Stream (@jdm, #44781)
• in item() on attributes on Element (@webbeef, #44721)
• in append­Rule() on CSS­Keyframes­Rule (@mrobinson, #45173)
• in init­Event() on Focus­Event (@mrobinson, #44870)
• in stop() on Window (@TimvdLippe, #44804)
• in document.exec­Command(​"delete") (@TimvdLippe, #44748)
• in --debug-mozjs builds (@Gae24, @SharanRP, #44745, #45001)
• when evaluating scripts in DevTools while paused (@atbrakhi, #45050)
• when previewing some JS values in DevTools (@eerii, @atbrakhi, #45054)
• when shaping zero-width spaces in layout (@mrobinson, #45176)
• when toggling servoshell's experimental mode at runtime (@mrobinson, @Loirooriol, #45226)

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

New contributors

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

• AbdAlRahman Gad (@AbdAlRahmanGad, #45213)
• Onyeka Obi (@MavenRain, #44806)
• Steve Sharon Sam (@SteveSharonSam, #45030)
• avis137 (@avis137, #44837)
• Xabier Rodríguez (@calvaris, #45084)
• June (@kimjune01, #44816)
• Matt Van Horn (@mvanhorn, #44740)
• nicole (@n0blenote, #44704)
• panxt8 (@panxt8, #44991)

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

Donations

Thanks again for your generous support! We are now receiving 7659 USD/month (+4.2% from April) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo.

Servo is also on thanks.dev, and already 35 GitHub users (+2 from April) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.

We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you're interested in this kind of sponsorship, please contact us at join@servo.org.

7659 USD/month

10000

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

30 Jun 2026 12:00am GMT

The Rust team has published a new point release of Rust, 1.96.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.96.1 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website.

What's in 1.96.1

Rust 1.96.1 fixes:

• Missing retries / timeouts in Cargo's HTTP client
• Miscompilation in a MIR optimization

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

• CVE-2025-15661
• CVE-2026-55199
• CVE-2026-55200

Contributors to 1.96.1

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

30 Jun 2026 12:00am GMT

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

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

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

Improving CP/CPS Documentation

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

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

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

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

Introducing Detailed Controls Reports

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

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

A DCR must include:

• The scope and boundaries of the audited CA systems;
• Applicable audit criteria;
• Controls implemented by the CA;
• The auditor's testing procedures;
• Results of control testing; and
• Information regarding control exceptions or deficiencies.

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

Additional Clarifications and Improvements

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

• aligns Mozilla's mass revocation planning requirements with the corresponding CA/Browser Forum Baseline Requirements, helping ensure consistency across compliance frameworks;
• clarifies audit expectations for root inclusion requests, including requirements relating to audit continuity and root key generation ceremonies;
• requires root CA key pairs submitted for inclusion to have been generated within the previous five years, helping ensure that newly included roots are based on contemporary cryptographic practices and controls; and
• clarifies expectations when ownership or operational control of a CA changes, helping ensure that Mozilla receives timely notice and can evaluate the impact of acquisitions or organizational changes on continued compliance.

Looking Forward

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

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

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

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

29 Jun 2026 11:33am GMT

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

Highlights:

• [Markus Stange] First typed array: Allow profile.shared.stackTable.frame to be an Int32Array (#6087)
• [Nazım Can Altınova] Show more user friendly errors for unsupported profile version in both the frontend and the cli (#6107)
• [fatadel] Expose counter information in profiler-cli (#6084)

Other Changes:

• [Nazım Can Altınova] Bump profiler-cli version to 0.3.0 (#6104)
• [Markus Stange] Split getSelfAndTotal. (#6113)
• [Markus Stange] Add missing transform shortcut key handling for S (focus-self) (#6117)
• [Markus Stange] Remove unused isInverted prop from FlameGraphCanvas. (#6116)
• [Markus Stange] Change sidebar splitter CSS to only apply to the sidebar, not to all splitters under .DetailsContainer (#6114)
• [Markus Stange] Pass callNodeInfo to handleCallNodeTransformShortcut. (#6115)
• [Markus Stange] Move column declarations out into a separate file (#6119)
• [fatadel] Keep menu panels above the selected-marker tooltip (#6125)
• [Nazım Can Altınova] Make sure to always sanitize source contents even when no PII sanitization is requested (#6127)
• [Markus Stange] Compute FlameGraphTiming rows lazily (#6126)
• [Markus Stange] Create a non-connected FlameGraph component (#6118)
• [Nazım Can Altınova] Sync: l10n → main (June 29, 2026) (#6130)

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

• de: Michael Köhler
• el: Jim Spentzos
• en-GB: Ian Neal
• es-CL: ravmn
• fr: Théo Chevalier
• fur: Fabio Tomat
• fy-NL: Fjoerfoks
• ia: Melo46
• it: Francesco Lodolo [:flod]
• nl: Mark Heijl
• ru: Valery Ledovskoy
• sv-SE: Luna Jernberg
• zh-TW: Pin-guang Chen

1 post - 1 participant

Read full topic

29 Jun 2026 9:25am GMT

Welcome back from the Thunderbird development team!

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

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

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

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

Exchange Email Support

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

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

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

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

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

Keep track of our Graph API implementation here.

20+ year old MIME bugs?! - Contributor Spotlight

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

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

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

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

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

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

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

Add-ons, Extensions and Ecosystem

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

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

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

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

Authentication and OAuth

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

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

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

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

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

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

Panorama - Global Message Database

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

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

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

Maintenance, Upstream adaptations, Recent Features and Fixes

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

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

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

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

• Improvements to threaded message handling and sorting behaviour.
• Fixes for long-standing IMAP synchronization and data integrity issues.
• Improvements to POP3 reliability, including protections against queue deadlocks.
• Multi-monitor and mixed-DPI fixes for mail notifications.
• Continued migration work to Fluent as part of our localization modernization efforts.
• 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: June 2026 appeared first on The Thunderbird Blog.

25 Jun 2026 6:34pm GMT

Bugs resolved in Moz-Phab 2.15.3:

• bug 2049293 [moz-phab] Init errors get swallowed by Jujutsu backend
• bug 2049296 [moz-phab] Add jj util backend name check for Jujutsu integration

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

1 post - 1 participant

Read full topic

25 Jun 2026 5:11pm GMT

This is another post in our series covering what we learned through the Vision Doc process. We previously described the overall approach and what we learned about doing user research, we explored what people love about Rust, dug into what it takes to ship safety-crticial Rust, and described some of the major challenges that people face when using Rust.

In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

Many paths to needing Rust

The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.

"Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO

Rust learning resources

Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

"I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

"The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

"Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

"We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

Beginner stumblings and unlearning habits

It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.

"There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)

"In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT

We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.

"I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab

Learning to work with the borrow checker

We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.

The compiler as teacher

Rust's diagnostics did the teaching on their own, especially around lifetimes.

"If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs

"Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer

Learning by doing

Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.

"I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust

"Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider

Letting go of "clone guilt"

Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.

"On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university

The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.

We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.

Multi-paradigm, but not the OOP some are used to

The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.

"Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM

"I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company

Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.

"My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries

"The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO

Teaching Rust in academia

We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.

"I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust

The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.

What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.

Learning using LLMs

Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.

"I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate

"I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust

For some learners, an LLM is just another way to find answers, no different than a search engine.

"So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space

One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.

"At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company

We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.

Organizational considerations for Rust learners

We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.

"[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)

"So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider

"We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation

Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.

"They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM

The community and helping each other aspect seems to grow bonds as organizations mature.

"Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company

Silent attrition

We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.

"All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -- A second University Professor

There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.

"We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)

We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.

"Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust

While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.

"People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider

Feedback on near-bounces from survey

We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:

"I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A

Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.

One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.

Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.

Need more focused work on silent attritrion

The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.

Conclusions

Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.

That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.

What seems worth trying

Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.

Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.

Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.

Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.

How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.

Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.

What we still don't know

The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

25 Jun 2026 12:00am 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

Foundation

• Rust Foundation Welcomes OpenAI As Platinum Member
• Rust Commercial Network Launches to Unite Commercial Users of Rust
• Mainmatter Is Bringing Hands-On Rust Training

Newsletters

• The Embedded Rustacean Issue #74

Project/Tooling Updates

• Bevy 0.19
• Rust PNG crate gets even faster, used by GNOME and Chromium
• kache 0.7.0: caching real-world C/C++ trees
• New Feature in GuardianDB: Introducing the ODM (Object Document Mapper) Layer
• Safe SIMD in Rust, even on the inside
• Ratatui 0.30.2 is released - a Rust library for cooking up terminal user interfaces
• Adding a post-quantum hybrid handshake to a Rust VPN
• From Julia to Rust: a differentiable tensor stack for scientific computing in the agentic AI era
• hotpath-rs 0.18: Profiling Async and Concurrent Rust - Channels and Lock Contention

Observations/Thoughts

• How we found a bug in the hyper HTTP library
• ClickHouse with Alexey Milovidov and Austin Bonander
• Deep dive into iroh: A replacement for WireGuard or a peer-to-peer layer for your application?
• Optimizing #[sqlx::test] rebuild time
• Rewriting the world in Rust

Rust Walkthroughs

• Migrating LiteLLM to Rust - Building the Fastest and Litest AI Gateway
• Safe SIMD in Rust, even on the inside
• Learn Rust Async/Await, Tokio, and TCP Networking by Building an HTTP/1.1 Server
• Building Breakout in Bevy: Step by Step
• Porting 300,000 Lines of C++ and Perl to Rust: A Dual-Oracle Media Metadata Engine
• A data race that doesn't compile
• [video] RustCurious lesson 9: Traits are Interfaces
• [Video] BAML: a new programming language (created in Rust)
• [Video] The Future of Version Control
• [Video] Borrowing Beauty: My Beginner's Quest to Create Approachable Bevy & Rust Code

Crate of the Week

This week's crate is cargo-rdme, a cargo command to create your README from your crate's documentation.

Thanks to Diogo Sousa 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.

• AimDB - Non-blocking fallible try_produce for bounded / non-overwriting buffers
• AimDB - Add minimal example: hello-mailbox-async

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

CFP - Events

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

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

Updates from the Rust Project

515 pull requests were merged in the last week

Compiler

• implement #[diagnostic::on_unknown] for modules
• outline part of evaluate_goal_raw into its own #[cold] function
• preserve track_caller for by-value dyn vtable shims

Library

• add io::Read::read_le and io::Read::read_be
• constify TryFrom<Vec> for array
• impl [const] Default for BTreeMap
• stabilize str_from_utf16_endian
• stabilize strip_circumfix
• stabilize substr_range and subslice_range

Cargo

• diag: Support build.warnings for cargo lints
• add: list too-new versions and how to override
• host-config: dont apply target config to host artifacts
• install: Run cargo lints like rustc lints
• resolver: hint how to resolve too-new versions
• test: skip dwp uplift test without packed debuginfo
• add Solaris fcntl file locking
• -Zmin-publish-age (RFC #3923)
• improved the test error messages when 'rustc -V' fails
• remove windows-sys dependencies older than 0.61

Clippy

• add lint to suggest as_chunks over chunks_exact with constant
• new unnecessary_unwrap_unchecked: lint
• extra_unused_type_parameters: don't suggest an autofix
• let_underscore_future: skip bindings with an explicit type annotation
• avoid ICE when evaluating constants containing unsized type args
• avoid map_unwrap_or fix when default is adjusted
• do not check for unused lifetimes in expanded code
• don't trigger unnecessary_box_returns when the size depends on generics
• find a shared context for the format string and the format! call
• fix OOM panic for large types on uninit check
• fix std_instead_of_core: false positives for core::io/MSRV
• manual_slice_fill detect for in loops over &mut [T; N] slices
• merge comment and cfg checking in matches lint pass
• perf: check the method name first in or_fun_call
• perf: compare method names before type queries in three lint passes
• perf: run structural checks before const context queries in question_mark, manual_clamp and ranges
• perf: skip match_same_arms work when the lint is allowed
• perf: skip tokenizing in span_contains_cfg when no '#' is present
• treat ! the same as - in unnecessary_cast

Rust-Analyzer

• assists/replace_match_with_if_let: don't parenthesize if-let guards
• implements_trait_unique_with_infcx: only forbid the self type from being an error type
• bye bye ted
• do not visit nodes in GC multiple times
• MIR eval mixed bit and byte sizes
• check for #[cfg]s in tail expression macros
• crash on static constants in array length positions
• don't complete .await on receivers of unknown type
• don't panic on out-of-range integer literals in const positions
• migrate merge imports to editor

Rust Compiler Performance Triage

This week had a lot of big swings, with two significant perf regressions that are accepted because they unlock future features and perf improvements. We also saw large improvements in the next trait solver due to the performance optimization work happening there.

Triage done by @JonathanBrouwer with help from @Kobzol. Revision range: b5d46ecb..8b6558a0

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.9%	[0.2%, 2.7%]	184
Regressions ❌ (secondary)	1.0%	[0.1%, 4.2%]	160
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.2%]	2
Improvements ✅ (secondary)	-11.8%	[-69.9%, -0.2%]	25
All ❌✅ (primary)	0.8%	[-0.3%, 2.7%]	186

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

• rustc_lint: Allow scoped non_ascii_idents lint levels
• Stabilize #[my_macro] mod foo; (part of proc_macro_hygiene)
• Implement IntoIterator for [&[mut]] Box<[T; N], A>
• Tracking Issue for string_from_utf8_lossy_owned
• Infer all anonymous lifetimes in assoc consts as 'static
• consider subtyping when checking if an infer var is sized
• remove box_patterns
• enable eager param_env norm in new solver
• Lint against iterator functions that panic when N is zero

Leadership Council

• Start a t-project-structure/t-comprehensibility

No Items entered Final Comment Period this week for Cargo, Compiler Team (MCPs only), Language Reference, Language Team, Rust RFCs 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

• No New or Updated RFCs were created this week.

Upcoming Events

Rusty Events between 2026-06-24 - 2026-07-22 🦀

Virtual

• 2026-06-25 | Virtual (Girona, ES) | Rust Girona
  • Rust Girona Weekly Session
• 2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-07-02 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-02 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Learning Game Development the Hard Way with Rust and Bevy
• 2026-07-02 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-07-04 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-07-05 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-07-07 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-07-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-16 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-07-21 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: Learning Rust as First Programming Language
• 2026-07-21 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful

Asia

• 2026-07-18 | Bangalore, IN | Rust Bangalore
  • July 2026 Rustacean Meetup

Europe

• 2026-06-24 | Manchester, UK | Rust Manchester
  • Rust Manchester June Talks
• 2026-06-24 | Trondheim, NO | Rust Trondheim
  • The Chaos of Time and Time Intervals
• 2026-06-25 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-06-25 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #69
• 2026-06-25 | Toulouse, FR | Rust Toulouse
  • Rust Toulouse Meetup - Bevy & ESP32
• 2026-06-27 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #27
• 2026-07-02 | Edinburgh, UK | Rust and Friends
  • Bevy, Bits, & Cats (Rust July Talks)
• 2026-07-02 | Enschede, NL | Baseflow Tech Meetups
  • AI Summit
• 2026-07-08 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 262
• 2026-07-09 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva

North America

• 2026-06-24 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-06-24 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies
• 2026-06-25 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-06-25 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-06-26 | New York, NY, US | Rust NYC
  • Rust NYC's Big Summer Social
• 2026-06-27 | Boston, MA, US | Boston Rust Meetup
  • Somerville Union Square Rust Lunch, June 27
• 2026-07-02 | Saint Louis, MO, US | STL Rust
  • Git is easy?
• 2026-07-04 | Boston, MA, US | Boston Rust Meetup
  • Boston University Rust Lunch, July 4
• 2026-07-09 | Lehi, UT, US | Utah Rust
  • Utah Rust July Meetup
• 2026-07-11 | Boston, MA, US | Boston Rust Meetup
  • MIT Rust Lunch, July 11
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-18 | Boston, MA, US | Boston Rust Meetup
  • North End Rust Lunch, July 18
• 2026-07-21 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-07-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Distributed Systems with Flight Science!

Oceania

• 2026-06-25 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne June 2026
• 2026-07-21 | Barton, AU | Canberra Rust User Group
  • July Meetup

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

Jobs

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

Quote of the Week

I think this is the wrong decision, and I wish the lang team had stabilized the Late type instead. Better Late than Never.

- /u/CouteauBleu on /r/rust

Thanks to Theemathas 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

24 Jun 2026 4:00am GMT

Earlier this month, we officially stood up Mozilla.org: a new 501(c)(3) nonprofit created to steward the long term success of the Mozilla Project.

Over the last year or so, I've said a lot about how AI is reshaping the web - and how we need to simultaneously stand up for the open internet Mozilla helped build and shape what the internet is becoming in the AI era. This is a huge and urgent challenge.

Mozilla has evolved and grown a great deal in order to step up to this challenge.

We are still a high impact philanthropic foundation and a browser company focused on user choice. But we are also: an email company built around privacy; an open source AI startup focused on developers; a place for people to create and share data on their own terms; and an investor in responsible tech startups.

These are all pieces of Mozilla today, and are all important levers as we try to shape where the internet is headed for the better.

We have created Mozilla.org to pull all of the different pieces of Mozilla together. It will act like a strategic endowment - allocating funding, managing our brands and shaping long term strategy - to ensure every part of Mozilla is well set up to advance the vision outlined in the Mozilla Manifesto. And, if we're successful, it will help all of the pieces of Mozilla add up to more than the sum of their parts.

This is an important milestone for Mozilla. The challenge of fusing the values of the Mozilla Manifesto into this next era of the internet is huge. This updated structure will make it easier to nimbly direct our resources and orchestrate our actions to step up to this challenge.

At the same time, what we love about Mozilla stays the same. All of Mozilla's organizations remain under the umbrella of the 501(c)(3) Mozilla Foundation, with the new non-profit operating the Mozilla portfolio of organizations on its behalf. Our mission - and our commitment to nonprofit ownership at the top - remain steadfast.

For more information on the new Mozilla.org non profit including an FAQ, see wiki.mozilla.org/mozilla_org

The post The web is evolving. So are we. appeared first on The Mozilla Blog.

23 Jun 2026 5:59pm GMT

Over the past several weeks, we have been welcoming early users from our waitlist into Thundermail, a few waves at a time. Many of you are now setting up your accounts, trying things out, and sharing your thoughts with us.

Naming updates

You may have noticed that we are now saying Thundermail more often, and Thunderbird Pro less.

Thunderbird Pro started as the name for our subscription services, including Thundermail, Appointment, and Send. But early feedback made two things clear: people cared most about Thundermail, and "Pro" created confusion about whether Thunderbird itself was becoming a paid or limited product.

So, to clarify things, Thunderbird Pro is now simply Thundermail: the email service from Thunderbird, with features like Appointment and Send included.

The Thunderbird Desktop and Mobile apps remain exactly what they are today: powerful, compatible with any email service, and free.

What we learned so far

Every day, members of our team are reading through your survey responses, your messages in the Thundermail Early Bird community chat, your support requests, and every new idea and vote on the board. We discuss what we are hearing, and we sort it into what we can address right away and what we want to plan for. Then we keep working in the open, where you can see what we are up to and tell us when something is not quite right.

Here are some of the things we've learned so far:

• Custom domains matter a lot. Many called this out directly, along with support for unlimited custom domain aliases. Several responses said these features stood out compared to other email providers.
• Multi-factor Authentication saw a lot of requests on the ideas board, and we listened. This is now in progress and will be available soon.
• Users appreciate that Thundermail is open and works with any email app. It has always been our intention to stick to open standards so Thundermail stays easy and open to use with Thunderbird or any other app.
• A bit of surprise that calendar and contacts are included. Apparently we should probably talk about that more.
• DNSSEC and DANE support picked up a lot of votes and is now on the roadmap.
• Requests for more pricing tiers and plans were frequently mentioned, which we will be adding once Thundermail is out of beta and open to the general public.
  • https://ideas.tb.pro/p/additional-pricing-tiers
  • https://ideas.tb.pro/p/a-la-carte-pricing

However, there was one request which came through louder than any other…

Webmail

Webmail was, by a wide margin, the most requested idea from our community, and whereas we had it in the plans for down the road, many people expected this to be a feature available from day one.

We moved webmail to the top of the list, shifted resources into the work behind it and we are excited to share that an early alpha version of it is coming next month. As with most early releases, it will have some rough edges, but will also allow for a much more interactive user experience for our beta testers. Everyone will have a vote in how it's shaped for the future.

A look at what is coming next

• Webmail! Arriving soon.
• Two factor authentication is now in progress.
• More reliable email, as we keep fine tuning things behind the scenes, training global mail servers and spam filters.
• Onboarding improvements for a smoother first time sign-up flow.

Send and Appointment

Our scheduling and secure file sharing tools are still here, and they are still part of your subscription. Our main focus right now is Thundermail and webmail, but we are continuing to care for both with steady improvements along the way.

• Send: Improved Thundermail integration, providing end-to-end encrypted file attachments without the need for a separate add-on. Users on our Daily version can already test this feature today.
• Appointment: Streamlined the sign up flow, added an easy one click connection with the Thundermail calendar, and refreshed the calendar view design.

We're looking for more ideas

If you are an Early Bird, we would love for you to visit our ideas board to share your suggestions and vote on the ones you would most like to see. We really do read every single one.

And if you have not been invited yet, you can join the waitlist. More waves are going out soon, and we are looking forward to welcoming you onboard.

Thank you for helping us build Thundermail.

The post Thundermail June 2026 update: what we learned after the first few waves of invites appeared first on The Thunderbird Blog.

23 Jun 2026 5:24pm GMT

If you've been running into endless CAPTCHAS or website login requests lately, you're not imagining things.

Websites, facing a rising tide of abusive traffic from bots, are adopting increasingly aggressive countermeasures, damaging user's experience of the web, their privacy and open access to the web.

In this post, we'll talk about a new initiative we're launching with Cloudflare, other web browsers, and web stakeholders to address this challenge while keeping the web anonymous by default.

Privacy and access in tension

The fight for privacy on the web has made real progress. Browsers that put privacy first are eliminating third-party cookies, restricting fingerprinting, and hiding IP addresses, pushing back against the trackers.

But every step forward has come with a cost.

Users are seeing more CAPTCHAs, more demands to log in, and more outright block pages than ever before. Building privacy into the browser means dismantling the passive signals, like IP addresses and browser fingerprints that are used to profile users, but are also relied on by anti-abuse systems.

At the same time, sites are facing large increases in bot traffic. The response from websites is understandable; volumetric abuse like credential stuffing and spam can do real damage. But the result is a lose-lose: users face mounting friction and reduced privacy, while sites drive away the legitimate visitors they wanted to serve.

If nothing changes, users will increasingly be forced to choose between their privacy and their access to the web.

Proposals have been made to tackle this dilemma, by asking users to prove to sites that their devices and software are 'trusted'. These proposals, such as Web Environment Integrity (WEI), transfer control of devices away from users and to a small handful of operating system and hardware vendors. This deprives users of choice and control and gives those gatekeepers control over which devices and software can access the web, the opposite of the open web, which Mozilla is working to protect.

Finding a better way forward

We think there's a better way forward. It starts from a simple observation: bots cause harm because they operate at scale. To stop that kind of abuse, a site doesn't need to know who you are, or that your device is restricted to running approved software. It only needs to know whether you're staying within a reasonable rate limit.

To make a rate limit work, it must be hard for attackers to create new identities and reset their allowance. That's one reason why sites demand an email address, a federated login or a device fingerprint: obtaining a new one is just costly enough to make the rate limit stick. The challenge is whether we can make rate limits work, without giving sites access to hard-to-change identifiers that also enable tracking.

Some sites naturally have a relationship with their users, like a subscription or a long-standing account. What if one of those existing relationships could quietly vouch for you elsewhere, so a site you've never visited could trust that you're a real person within its limits, without learning who you are or even where the vouch came from?

For example, consider a VPN service. Many websites block VPN traffic entirely due to the high rates of abusive traffic blended with legitimate traffic. What if a VPN service could vouch for each of its subscribers? This would let sites manage a per-subscriber rate limit, meaning users get fewer roadblocks and sites get more of the legitimate traffic they want. Of course, this requires that the vouching system doesn't enable sites to track VPN users, which would otherwise defeat the very purpose of using the VPN.

Enabling this kind of privacy-preserving vouching is already possible in a limited sense. Apple's Private Access Tokens, built on a cryptographic protocol called Privacy Pass, let Apple devices receive single use tokens they can later present to websites without those visits being linked together.

However, Private Access Tokens have some critical shortcomings. First, like WEI, they rely on device attestation, the very hardware gatekeeping we are determined to avoid. Second, there's no easy way to open up the system to let more parties vouch for users without compromising on user privacy, which means concentrating control in the hands of a few. To keep the web open, we need a system where any site can vouch for users, and where other sites can decide who they trust to vouch for users responsibly.

This is a much harder problem, but we think the cryptographic foundations exist to deliver it. Anonymous credentials let one party issue you a credential that you can later present to a site a limited number of times, whilst preventing sites and issuers from tracking its use. It's even possible to hide which party issued it, proving only that it came from a set of trusted issuers.

A fix is both essential and possible

Building this into a system for the open web, where any site could vouch and any site could set its own limits is challenging, but we believe it's both possible and essential in order to defuse the tension between privacy and access, while avoiding centralising control in a small number of gatekeepers.

Working with other web stakeholders, including Cloudflare and other browsers, we've started designing such a system. For a deeper dive, read our post on Hacks, which goes into more detail about the problem space and the approach we're working on.

Our goal is simple: fewer CAPTCHAs, fewer unnecessary blocks and fewer demands to identify yourself, without compromising on privacy. This is the kind of web that Mozilla built Firefox to offer: easy to use, private and open to all.

The post Keeping the web open and private in the bot era appeared first on The Mozilla Blog.

23 Jun 2026 3:56pm GMT