fidzu : Mozilla

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

Highlights

• Improved mach startup overhead by 30-50%, as well as a 75% improvement for mach test on Windows and 10s faster configure for subsequent runs

• Moved to weekly scheduled dot releases and faster rollouts, allowing us to deliver fixes and uplifts to users faster and more reliably

• Created a huge number of dashboards to help developers dig into Mochitest and XPCShell tests

• Stood up MacOS worker pools that can run multiple tasks at once using VMs, greatly improving our Mac capacity issues

• Can now navigate to about:pdf in Nightly to open and edit arbitrary PDF files, including the ability to set Firefox as your default PDF editor on MacOS

Detailed Project Updates

AI for Development

• Suhaib Mujahid deployed the initial version of Hackbot, a platform for building and running AI agents to automate parts of the Firefox development workflow.

• Evgeny Pavlov ported the "Build Repair Agent" to Hackbot and deployed it for testing. It now monitors Firefox build failures and triggers the agent. When an analysis and a proposed patch are ready developers can be notified by email.

Bugzilla

• David Lawrence added a new GitHubPullRequests extension that renders a live status panel in the bug modal for any attachment whose content type is text/x-github-pull-request. A new REST endpoint fetches PR metadata (state, author, labels, latest review per reviewer) from the GitHub REST API on demand, and a client-side script populates a table with a "show closed/merged" toggle.[image]

• Xavier L'Hour improved the user experience for developers, adding shortcuts to buglist.cgi for all, open, or closed bugs (1764713)

• Xavier L'Hour added a new shortcut button to the bug page that allows users to quickly move spam bugs to the Invalid Bugs product (1684509).

Build System and Mach Environment

• Alex Hochheiden has been moving build system logic out of make to pave the way for a new build system backend (coming soon). See Bug 2038789.

• Alex Hochheiden landed a 30%-50% (platform dependent) speedup for mach startup. See Bug 1775197.

• Alex Hochheiden sped up subsequent configure runs by ~10s by adding caching to the mach taskgraph toolchain step. See Bug 2017746.

• Alex Hochheiden reduced mach test startup overhead on Windows by 75%. See Bug 2018327.

• Alex Hochheiden has achieved significant code deduplication and simplification by consolidating the Android Gradle configuration into convention plugins. There were also various Gradle configure-cache improvements. See Bug 2007013, Bug 1950099, Bug 2013417, Bug 2017752, and Bug 2017753.

Firefox-CI

• Julien Cristau added support for interactive tasks (aka one click loaners) on Windows and macOS

• Andrew Halberstadt implemented mach try support with Github, being used in mozilla/enterprise-firefox-try and coming to Firefox soon.

• Andrew Halberstadt implemented the machinery to start making Gecko CI tasks clone from Github.

• Ryan Curran brought Firefox CI's Apple Silicon VM infrastructure into production. Building on the MacOS CI image pipeline established last year, he migrated test suites onto virtual machines and grew the macosx1500-aarch64-vms pool so Taskcluster now routes eligible jobs to VMs alongside physical hardware. This reduces reliance on physical Macs, increases CI capacity, and supports the ongoing migration off of older Intel-based macOS infrastructure

• Jonathan Moss migrated Firefox CI's cloud-based Windows testing from Windows 11 24H2 to 25H2, moving the bulk of Firefox's Windows test coverage to Microsoft's latest platform and keeping CI aligned with the Windows version most commonly used by Firefox Desktop users

• Florian Quèze created many dashboards to help dig into Mochitests and XPCShell tests

• Ryan VanderMeulen landed a set of improvements to mach try chooser. The update adds an exclude filter, a clearer preview pane with removable job rows, an artifact-builds toggle, and a warning when a selection exceeds task-prioritization thresholds. It also fixes a bug where choosing Firefox for Android jobs would unintentionally clear selections for other platforms.

Lint, Static Analysis and Code Coverage

• Valentin Rigal and Bastien Abadie created a Code Review Bot prototype for publication of review comments using various source linters on Github

• Morgan Rae Reschenberg added support for accessibility review to Code Review Bot

Mozregression

• Zeid fixed a bug in mozregression-gui on macOS, where the camera and microphone capture request was getting rejected (released in 7.3.0). Thanks to bug report + tip from Andreas Pehrson.

PDF.js

• Calixte added about:pdf to use an entrypoint for opening and editing arbitrary PDF files[image]

• Calixte added support for playing videos/sounds embedded in PDF files

Phabricator , moz-phab, and Lando

• Connor Sheehan improved the uplift experience by leveraging Lando to manage the assessment forms, train selection, and automatic application, so conflicts are detected earlier. The number of uplifts via Lando has out-paced those via Moz-Phab, and sailed through the rise in uplift numbers (likely due to more sec-bugs getting fixed and uplifted).

• Zeid added support for private GitHub repositories in Lando, allowing security patches to be implemented in a private clone of a repo, and pushed to the public one.

• Olivier Mehani finalized support for using the new Lando instance for try-pushes. This brings a host of QoL improvements which weren't backported to the old instance: better UTF-8 support, smarter conflict resolution and improved security and authentication. It is now processing about 1500 pushes / week (old Lando still processes about 50 / week).

• Magnolia Liu implemented automatic pushes to Try for uplift requests, for faster feedback in case of issues.

• Olivier Mehani added a view of a user's current and recent jobs on the landing page of Lando when authenticated.

• Zeid identified and fixed the causes of some stability and reliability issues in Lando, which were causing increased downtime during deployments and on an ongoing basis.

• Olivier Mehani deployed a PoC of reviewer selection on the GitHub pilot, allowing Herald-like mechanisms to GitHub PRs.

• Olivier Mehani and Connor Sheehan (with Corey Bryant and Daniel Darnell) migrated the COMM project to GitHub https://github.com/thunderbird/thunderbird-desktop, sharing Firefox's syncing model.

Release Management and Engineering

• Donal Meehan drove the Release Management team's move to a weekly scheduled dot release cadence for Desktop and Android, starting with Firefox 151. This allows us to deliver fixes and approved uplifts to users faster and more predictably. This change is expected to reduce unplanned releases, improve release flexibility, and create a more consistent release rhythm across teams.

• Dianna Smith drove the update to the Release Management team's Desktop major release rollout process, starting with Firefox 152. Instead of throttling to 0% on day 2, it will remain at 25% rollout for two days before moving to 100%, unless any issues arise. This should help us collect uptake and stability signals earlier while still allowing time to catch problems before full rollout.

• Pascal Chevrel completed the update to the dictionaries shipped with Firefox Desktop. The update added eleven new dictionaries, covering Croatian, English (UK), Georgian, Persian, Slovenian, Tajik, Tamil, Tibetan, Turkish, Welsh, and Xhosa, and refreshed nine others. This expanded the number of locales with a built-in spellchecker from 30 to 41 beginning in Firefox 152. Special thanks to Francesco Lodolo, Bryan Olsson, and the localization community for reviewing the patches and helping assess the quality of the dictionaries.

• Pascal Chevrel delivered a range of improvements to WhatTrainIsItNow, including expanded it to cover weekly dot releases and ESR planned dot releases, added new uplift views including a dot-release uplifts page and a beta uplift graph, and published new APIs that surface train-selection and uplift guidance inside Lando. He also made performance improvements and a steady stream of fixes across the site.

• At Pwn2Own 2026, Firefox came through with no successful exploits, thanks to preparation across many teams and individuals. Within Release Management, Ryan VanderMeulen drove pre-event patch readiness and Dianna Smith coordinated the releases during the event, including the 150.0.3 dot release, which mitigated the root cause behind several of the contest entries.

• Dianna Smith built out release-health monitoring and alerting in Bigeye, giving Release Management a growing set of automated alerts that surface data anomalies earlier to aid in release health and regression detection. To make the capability easy to extend, she also created a guide for other teams to add monitoring and alerts for the areas they know best. Teams that want an earlier signal on their own metrics are encouraged to use the guide and help grow the coverage.

Release Operations

• Ryan Curran built Hangar, a live dashboard for monitoring Firefox CI's worker pools. It consolidates fleet data from several systems into one view, giving Release Operations a single place to check fleet health and catch problems such as missing or quarantined workers early.

• Ryan Curran created the iOS version of BuildWatch, and Andrew Erickson ported it to Android. BuildWatch lets you monitor Firefox CI try pushes from your phone, including live per-platform build status, failure summaries, and one-tap retriggers. It uses only public APIs, so no VPN is required.

• Andrew Erickson and Mark Cornmesser developed Fleetbench, a tool for benchmarking Firefox CI workers. It currently measures CPU and ADB/USB I/O performance, helping Release Operations identify slow or outlier hosts before they skew performance test results such as Speedometer and trigger noisy or false regressions.

• Andrew Erickson built Pool Classifier, a web app for viewing per-worker success rates across Taskcluster worker pools. It classifies newly completed tasks every 15 minutes, giving Release Operations a continuously updated view of worker health and helping surface problematic workers proactively.

• Andrew Erickson created Fleetroll, a command-line tool Release Operations uses to manage and monitor long-running Linux, macOS, and Windows hardware hosts in Firefox CI Taskcluster. It deploys Puppet branch overrides and Vault secrets, audits what is actually applied, and surfaces each host's Puppet and Taskcluster state in a live dashboard.

• Mark Cornmesser built out a set of new worker-metrics dashboards in Yardstick, giving Release Operations clearer real-time visibility into the health of the Firefox CI hardware fleet. These include Linux worker status, Windows worker CPU and disk metrics, and a Windows job pickup and wait timeline, with alerting on key thresholds. The full set lives in the FXCI Hardware Workers folder in Yardstick.

• Jonathan Moss expanded cloud cost reporting in Looker, adding Azure support alongside the existing GCP data and a cloud-provider filter on the FXCI task overview dashboard. The team can now break down Firefox CI compute costs by cloud provider, making it easier to track and compare spend across Azure and GCP.

Taskcluster

• Yaraslau Kurmyza added Azure fast deprovision taskcluster#8790 and concurrency taskcluster#8815 to improve worker scanner performance. This shows ~2x-4x scan time improvements already.

• Contributor nitishagar and Yaraslau Kurmyza added patches taskcluster#8514, taskcluster#8784 to support compression in Taskcluster services API and Yarik worked with Fastly to resolve broken brotli support on the WAF edge side. Now services transmit significantly less data.

• Yarik added a dedicated service account to log with read only permissions webservices-infra#11197. This allows tc-logview to be used safely by untrusted agents inside containers with narrow short-lived access tokens.

• Yarik published queue forecasting dashboard experiments that continuously collects task events and trains models to enable and improve predictions on a task level (how long will it run, and when will it start). With future plans including extending it to the whole task group (mach try)

Treeherder

• Florian Quèze added treeherder#9540 "Show task group profile" item to the push action menu

• Cameron Dawson, juungo and moijes12 implemented various Treeherder API performance improvements

• Heitor Neiva added Git branch labels to pushes in Treeherder

• Andrew Halberstadt implemented the ability for Treeherder to display multiple Git branches at once, enabling support for "try like" repositories in Github

Version Control

• Upgrade hg.mozilla.org to Mercurial 7.2.2

• Created the mozilla-esr153 and comm-esr153 repositories.

Other

• Sylvestre converted our documentation from reStructuredText to MyST flavored Markdown

Thanks for reading and see you next quarter!

1 post - 1 participant

Read full topic

09 Jul 2026 4:26pm GMT

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

Highlights:

• [Florian Quèze] Add "/" and "f" keyboard shortcuts to focus the panel filter box (#6025)
• [Markus Stange] Change profile.shared.stackTable.prefix to prefixOffset (delta from current index) (#6089)
• [Markus Stange] Implement column sorting in the marker table (#6083)
• [cathaysia] feat: invert call stack in flame graph to render as icicle graph (#6090)

Other Changes:

• [Sky Ning] Add workflow to insert PR preview links (#6133)
• [Markus Stange] Make it easier to create upside-down flame graphs (#6128)
• [Markus Stange] Use appropriate highlighter dialects for ts + jsx (#6141)
• [cathaysia] style: add .editorconfig (#6142)
• [Nazım Can Altınova] Prevent long source URLs from overflowing the code error overlay (#6147)
• [Nazım Can Altınova] Extract a runCommand helper for profiler-cli command handlers (#6148)
• [cathaysia] feat(theme): add color-scheme meta (#6150)
• [Nazım Can Altınova] Add an early throw for the this.querier and remove the non-null asserts in the cli codebase (#6145)
• [skylarkning] Improve preview link discovery (#6149)
• [Nazım Can Altınova] Sync: l10n → main (July 9, 2026) (#6155)

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
• fy-NL: Fjoerfoks
• ia: Melo46
• it: Francesco Lodolo [:flod]
• nl: Fjoerfoks
• ru: Valery Ledovskoy
• tr: Nazım Can Altınova
• zh-TW: Pin-guang Chen

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

1 post - 1 participant

Read full topic

09 Jul 2026 1:58pm GMT

The Rust team is happy to announce a new version of Rust, 1.97.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.97.0 with:

$ rustup update stable

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

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

What's in 1.97.0 stable

Symbol mangling v0 enabled by default

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

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

• Generic parameter instantiations preserve their values, rather than being tracked solely behind a hash
• Inconsistencies: not all parts used the Itanium ABI, meaning that custom demangling was still necessary

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

See the previous blog post for more details.

Cargo support for denying warnings

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

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

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

See the documentation for more details.

Linker output no longer hidden by default

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

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

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

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

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

[lints.rust]
linker_messages = "allow"

Stabilized APIs

• Default for RepeatN
• Copy for ffi::FromBytesUntilNulError
• Send for std::fs::File on UEFI
• <{integer}>::isolate_highest_one
• <{integer}>::isolate_lowest_one
• <{integer}>::highest_one
• <{integer}>::lowest_one
• <{uN}>::bit_width
• NonZero<{integer}>::isolate_highest_one
• NonZero<{integer}>::isolate_lowest_one
• NonZero<{integer}>::highest_one
• NonZero<{integer}>::lowest_one
• NonZero<{uN}>::bit_width

These previously stable APIs are now stable in const contexts:

• char::is_control

Other changes

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

Contributors to 1.97.0

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

09 Jul 2026 12:00am GMT

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

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

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

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

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

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

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

Football needs Wrexham. The internet needs Firefox.

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

---

About Mozilla and Firefox

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

About Wrexham AFC

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

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

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

08 Jul 2026 1:00pm GMT

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

• Maintainer spotlight: Gen Li (@rami3l)
• Together for a healthier Clippy

Newsletters

• The Embedded Rustacean Issue #75

Project/Tooling Updates

• copper-rs v1.0.0: the open source deterministic robotics OS is now stable.
• Rayfish: Your own private network. No servers, no setup.
• rama v0.3.0 - network service framework ready to be used by the wider Rust community
• kache 0.9.0: supply-chain hardening + read-only CI cache
• GuardianDB - PostgreSQL and P2P/Local-First Together
• Nectar: a Rust-like language that compiles your whole web app to WebAssembly
• logdrain: Fast, Embeddable Log-Template Mining in Rust
• sheathe: Packaging the World's Video in Pure Rust
• wickra: streaming-first technical indicators
• Xcelerator Solver v0.1.0 -- deterministic symbolic regression
• dlt-tui 1.1.0 - a fast TUI viewer for automotive DLT (AUTOSAR Diagnostic Log and Trace) files
• RSSH v0.2.11 - terminal workflows, safer SSH key import, and observable AI ops
• k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob
• M-vis v0.5.0-rc1 update
• FlareDB: An Apache Beam Native Streaming Database built in Rust
• mqtt-typed-client 0.2: a type-safe async MQTT client on rumqttc
• RootAsRole: v4.0.0 Major release, secure execution, new logo
• A Cross-Platform Rust UI Framework via Qt's Bridging Technology
• Jam Programming Language
• Sōzu 2.1.0: UDP load balancing for the programmable edge
• b0nker: a minimal container runtime written in Rust

Observations/Thoughts

• [video] Rust Berlin Meetup 25/06/2026 Livestream
• [video] How do you rewrite C/C++ projects to Rust? - JetBrains interview with Luca Palmieri, Mainmatter
• Investigating why RustCrypto is slow: Deep dive into SIMD instructions and hardware acceleration
• bool as u32
• A Rust-to-Lean Verification Pipeline with AI Provers: An Experience Report
• Work In Progress Rust
• [video] OpenAI just spent $600k on Rust
• [audio] Rising Academies with Dylan Brown - Rust in Production Podcast

Rust Walkthroughs

• [series] Bevy Tutorial: Build Your First 3D Editor - Create a 3D Space on an Infinite Grid
• Learn Axum Basics and Routing by Building a URL Shortener
• [series] Rama 101.1: HTTPS clients and layers of abstraction

Miscellaneous

• Clickable euler diagram of all the Rust week talks

Crate of the Week

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

Thanks to Richard Neumann for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

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

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

CFP - Events

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

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

Updates from the Rust Project

598 pull requests were merged in the last week

Compiler

• enable eager param_env norm in new solver
• lint on core::ffi::c_void as a return type
• polish some macro parsing code
• resolve: no allocation in resolve_ident_in(_local)_module_*
• simplify option-iterator flattening in the compiler
• stabilize #[my_macro] mod foo; (part of proc_macro_hygiene)

Library

• add std::io::cursor::WriteThroughCursor
• implement Box::as_non_null()
• implement DoubleEndedIterator::next_chunk_back
• implement IntoIterator for [&[mut]] Box<[T; N], A>
• implement ptr::{read,write}_unaligned via repr(packed)
• move SizeHint and IoHandle to core::io
• move std::io::Seek to core::io
• optimize ArrayChunks::try_rfold with DoubleEndedIterator::next_chunk_back
• stabilize feature(atomic_from_mut)

Cargo

• bindeps: register transitive artifact targets
• avoid cloning parsed TOML manifest in ManifestErrorContext
• avoid extra clone of parsed TOML manifest
• remove unneeded cloning when parsing package index
• change HashMaps and HashSets in Cargo to use Fxhasher
• do not pass lint rustflags when --cap-lints=allow is set
• fixed Compilation::deps_output only taking the last dep
• pre-allocate a few vectors
• stabilize build-dir layout v2
• use a set when checking visited workspace members

Rustdoc

• fix crash when trying to inline foreign item which cannot have attributes
• show use-site paths for unevaluated const array lengths

Clippy

• chunks_exact_to_as_chunks: Don't report expressions with const parameters
• chunks_exact_to_as_chunks: Don't report expressions with type params
• missing_trait_methods: MSRV/unstable awareness
• vec_init_then_push: don't lint pushes from a macro expansion
• inline_modules: ignore cfg(test) modules in test builds
• match_same_arms: keep arm-level expectations working under an outer allow
• unnecessary_operation: avoid bad ! suggestions
• unnecessary_unwrap_unchecked: don't trigger inside the _unchecked fn
• add required parentheses when the needless_bool suggestion is an operand
• fix ICE when resolving local in unnecessary_unwrap_unchecked
• fix infinite_loop false positive inside gen blocks
• fix manual_c_str_literals suggestion when the trailing backslash is escaped
• fix strlen_on_c_strings incorrect suggestion logic
• fix suspicious_operation_groupings duplications
• lint bit width
• optimize Msrv::meets calls
• bail out of unicode lint scans when the snippet is pure ASCII
• skip the HIR parent walk in is_in_test_function when there are no test items
• place generated impl block after the existing impl block
• refactor StringAdd lint pass
• refactor suspicious_xor_used_as_pow
• remove lower_ty in uninhabited_reference
• respect the configured MSRV in manual_is_variant_and's map() == Some(_) rewrite
• rewrite mut_mut
• rewrite redundant_else as a late pass
• rewrite tuple_array_conversions

Rust-Analyzer

• SCIP: exclude leading/trailing trivia in definition ranges
• SCIP: remove dead inlay_hints field
• feat(ide-diagnostics): add diagnostics for invalid union patterns (E0784)
• internal(query-group-macro): remove the arity test
• add tree top method to Syntax node
• add handler for E0627
• supports multi arms for replace_match_with_if_let
• fix UB in smol_str borsh_non_utf8 test cases
• fix generic param for generate_default_from_enum_variant
• walkthrough_create_project file not packaged
• assertion failure on closure with unbound function
• avoid panic in convert_tuple_struct_to_named_struct on nested pattern usage
• configuration syntax for nvim-lsp
• correct resolution to value when it shares the same name with type
• exclude impls on the error type from impl enumeration
• fix crash on extract_variable when selecting unresolved macro call
• fix crash on completion inside macros
• fix handling of params of coroutine fns
• handle more cases of cfgs in expr store lowering
• no generate with default assoc item
• panics in unwrap_return_type, remove_underscore, and promote_local_to_const
• hoist attribute qualifier segment collection
• reduce parser joint-token allocation
• project-model: don't pass metadata extra args to sysroot
• project-model: introduce cargo.configPath
• provide startup time to ready log point and associated benchmark

Rust Compiler Performance Triage

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

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

Summary:

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

1 Regression, 1 Improvement, 4 Mixed; 3 of them in rollups 17 artifact comparisons made in total

Full report here

Approved RFCs

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

• 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

• Lint against invalid POSIX symbol definitions
• Document NonNull layout guarantees
• Tracking Issue for slice_split_once

Compiler Team (MCPs only)

• Let the OS handle stack growth
• Add target_feature_available_at_call_site

Language Reference

• Empty repr(Rust) enums are ZSTs

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

New and Updated RFCs

• Update RFC template
• RFC: Store registry tokens in the OS credential store by default

Upcoming Events

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

Virtual

• 2026-07-08 | Virtual (Cardiff, GB) | Rust and C++ Cardiff
  • Operating Systems Book Club: Introduction + Processes
• 2026-07-08 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-09 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-07-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-07-15 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 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-22 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-07-29 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-30 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-08-02 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-08-04 | Virtual (London, GB) | Women in Rust
  • 👋 Community Catch Up
• 2026-07-29 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-05 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing

Asia

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

Africa:

• 2026-07-14 | Johannesburg, ZA | Johannesburg Rust Meetup
  • Debugging a production grade Open Source Rust crate

Europe

• 2026-07-08 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 262
• 2026-07-09 | Berlin, DE | Rust Berlin
  • Rust Berlin on location 🏳️‍🌈 - Edition 015
• 2026-07-09 | Frankfurt, DE | Rust Rhein-Main
  • Building Cross Platform Applications with Ply
• 2026-07-09 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva
• 2026-07-15 | Dortmund, DE | Rust Dortmund
  • Teach and Hack at Projektspeicher
• 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
• 2026-07-30 | Manchester, GB | Rust Manchester
  • Rust Manchester July Code Night

North America

• 2026-07-09 | Lehi, UT, US | Utah Rust
  • Utah Rust July Meetup
• 2026-07-09 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 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 | Boston, MA, US | Boston Rust Meetup
  • Porter Square Rust Lunch, July 25
• 2026-07-25 | Brooklyn, NY, US | Flower
  • BOG-A-THON 2
• 2026-07-30 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-08-01 | Boston, MA, US | Boston Rust Meetup
  • Chinatown Rust Lunch, Aug 1
• 2026-08-04 | Boston, MA, US | Boston Rust Meetup
  • Evening Boston Rust Meetup at Red Hat, Aug 4

Oceania

• 2026-07-09 | Brisbane City, QL, AU | Rust Brisbane
  • Rust Brisbane • July 2026
• 2026-07-21 | Barton, AU | Canberra Rust User Group
  • July Meetup
• 2026-07-23 | Perth, AU | Rust Perth Meetup Group
  • Rust Perth: July Meetup!
• 2026-07-30 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne July 2026

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

Jobs

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

Quote of the Week

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

- Kornel on rust-users

Thanks to Cerber-Ursi for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

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

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

08 Jul 2026 4:00am GMT

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

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

What you told us

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

Here are the key themes that emerged from our conversations:

• Ecosystem trust: Your commitment to Thunderbird is rooted in a deep trust for open-source software, the Mozilla brand, absolute transparency, and reliability.
• Set and forget: You customize extensively during your initial setup, followed only by minor tweaks to get your workspace just right.
• Clutter & noise: There is a strong desire to reduce workspace clutter and the cognitive "noise" within dense configuration menus.
• Search to navigate: While deep navigation menus can feel hard to find your way through, an in-app search function is your go-to for finding what you need quickly.
• The "inbox as a to-do list" workflow: Many of you don't just read mail, you actively treat your unread inbox as a task list or interactive to-do queue.
• Terminology barriers: Even for advanced users, many settings feel overly technical, which causes hesitation when you're trying to explore your options.

Improvements we want to make

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

• Demystify the language: We are planning to replace confusing technical terminology with plain, clear language, so you always know exactly what each function does.
• Streamline information architecture: We are regrouping settings into logical, task-oriented categories to make manual navigation smooth and intuitive.
• Bring context to privacy & security: Instead of a flat list of checkboxes, we want to add clear explanations around data security and defaults so you can make confident, informed decisions.
• Functionality meets modern UI: Thunderbird's robust functionality is its superpower, but a dated interface shouldn't be a barrier to entry for newer users.
• Accessibility update: Based on a community member's recent audit, we are also taking this opportunity to improve the overall accessibility of the settings experience.

What's next?

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

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

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

Let us know your thoughts in the comments below!

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

07 Jul 2026 6:56pm GMT

Well, that went by quick!

I joined Mozilla as an intern in 2016. I wouldn't believe you if you told me I'd still be here in 2026, working on their WebAssembly engine and contributing to the WebAssembly standards process.

Ten years at one company is a long time in this industry. I'm feeling a bit sentimental, so I thought I'd share how that happened, and why I'm still here.

07 Jul 2026 3:00pm GMT

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!
• 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