fidzu : Mozilla

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

Highlights:

• [Markus Stange] Use @streamparser/json if the input is too large to fit in a V8 string (#6016)
• [Nazım Can Altınova] Include --search option in pq filter push (#6026)
• [fatadel] Translate URL track-index state through profile sanitization (#6000)
• [Nazım Can Altınova] Print also the status output right after cli load command (#6019)

Other Changes:

• [fatadel] Remove unused dependencies from package.json (#6010)
• [Nazım Can Altınova] Make profiler-cli work in sandboxed environments (#6003)
• [Markus Stange] Make profiler-edit run profile compacting before writing out the file (#6015)
• [Markus Stange] Migrate from prettier to oxfmt (#5986)
• [Markus Stange] Add a --symbolicate-wasm arg to profiler-edit. (#6008)
• [Markus Stange] Build and upload the cli artifact in PRs (#6020)
• [Nicolas Chevobbe] Update devtools-reps to 0.27.7 (#6030)
• [Markus Stange/fatadel] Make withSize use a wrapper element so that it can stop calling findDOMNode (#5988)
• [Markus Stange] Fix dhat importer (#6036)
• [Nazım Can Altınova] Annotate inlined frames in CLI call trees and stacks (#6041)
• [Nazım Can Altınova] Use proper types in cli tests instead of custom inline types (#6038)
• [Nazım Can Altınova] Fix text truncation for frames named after Object.prototype methods (#6044)
• [Nazım Can Altınova] Add missing key props to CodeErrorOverlay error list items (#6047)
• [depfu[bot]] Update oxfmt to version 0.51.0 (#6054)
• [Nazım Can Altınova] Sync: l10n → main (May 26, 2026) (#6058)
• [Nazım Can Altınova] Use URL-state symbol server for profiler-cli function annotate (#6051)
• [Nazım Can Altınova] Bump profiler-cli version to 0.2.0 (#6059)

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

• fr: YD
• sr: Марко Костић (Marko Kostić)
• tr: Ali Demirtaş
• zh-CN: Olvcpr423
• zh-CN: wxie

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

26 May 2026 3:53pm GMT

You felt it. The shift. That your role has fundamentally changed thanks to LLMs. It first entered your subconscious when you realized how easily you can now crank out PRs. You felt it more concretely (and less enthusiastically), as a reviewer when you opened your laptop one morning and noticed your review queue was double what it normally is thanks to everyone else cranking out PRs. And you feel this pervasive, general sense of friction.

It's difficult to pinpoint exactly where this friction is coming from. Depending on the repository size and CI setup, it will be slightly different for everyone. It might involve longer review times or slipping review standards. You might be noticing more merge conflicts and merge related CI failures. Perhaps there are more failures sneaking through to main or CI is taking longer to give you results. You almost certainly feel the grind. People are on edge, tired; developers are pulling in opposite directions.

Here's what LLMs shifted. The bottleneck is no longer producing code. The bottleneck is integrating it. The friction we're feeling is a result of more PRs, more ideas, more reviews, more disagreements all made possible thanks to LLMs. In short, the problem can best be summarized by Figure 1:

But we're living in a moment where many folks haven't realized this yet, and are still under the impression that their job is to produce code.

It's not. Your new job is to integrate it.

26 May 2026 1:50pm GMT

Disruptions to internet connectivity can occur in countless ways - from weather incidents, natural disasters and accidents to intentional interferences like cyberattacks and government-issued blackouts. Yet while some disruptions are unavoidable, deliberate shutdowns represent a fundamentally different and deeply concerning trend. They undermine the open, global nature of the internet and put the safety, security, and fundamental rights of millions at risk.

For over 25 years, Mozilla has worked to ensure that the internet remains a global public resource-open, accessible, and safe for all. This vision, grounded in the Mozilla Manifesto, holds that the internet must remain a shared, decentralized infrastructure that empowers individuals, supports civic participation, and enables economic opportunity. Internet shutdowns run counter to these principles by restricting access, concentrating control, and weakening the very foundations of the open web.

To help organizations study and document outages, Mozilla makes aggregated Firefox telemetry data available to help identify and understand connectivity disruptions. As 2026 progresses, this data continues to show significant outages affecting millions of people worldwide-many of them the result of deliberate restrictions.

As of late May, Iran's internet blackout had been in place for over 80 days, making it the longest shutdown since the Arab Spring. Following an earlier shutdown amid nationwide protests in January 2026, Iranian authorities have restricted access to the internet since 28 February. This has meant that, for almost three months, millions of Iranians have been cut off from news, communication, work, education, and basic services. It also means that almost no independent information about the situation in Iran is leaving the country, making it almost impossible for humanitarian organizations to assess the situation on the ground. The shutdown has also had a massive impact on the Iranian economy, severely disrupting financial activity and blocking international transactions. Although Iran's president has recently ordered an end to the shutdown, it is unclear how and when Iranians will be able to reconnect to the web.

When large numbers of Firefox users experience connection failures for any reason, this produces an anomaly in the recorded telemetry data. At the country or city level, this can provide a corroborative signal of whether an outage or intentional shutdown occurred. Our telemetry documents the magnitude of the latest outage in Iran. The graph below documents the effect of the outage in multiple ways, such as users' country location, language and timezone.

Across the globe, governments are increasingly interfering with and limiting access to connectivity. Both the number of states limiting connectivity and the amount of internet shutdowns has been growing steadily. In 2025 alone, 313 shutdowns across 52 countries have been documented, a sad record. This is a stark indication that shutdowns and restrictions are no longer a rare emergency measure, but established levers of control.

While the triggers for shutdowns are varied, access to the internet continues to be blocked especially often in times of conflict and political unrest. Especially in the context of hostilities, political tensions or public health emergencies, access to connectivity is a basic humanitarian need.

Beyond their immediate human impact, blackouts also affect the internet itself. Local networks depend on each other to form the global internet, and local restrictions affect the resilience and reliability of the web at large. When governments deliberately disrupt connectivity, they do not only isolate populations; they also contribute to the fragmentation of the global internet, undermining trust, interoperability, and the stability of shared infrastructure. Over time, this erosion risks replacing a single, open web with a patchwork of disconnected or controlled networks.

Governments should foster the health of the internet, not erode it. Access to the internet is widely recognized as essential for enjoying human rights. It is an integral part of modern life, facilitating education, communication, collaboration, business and entertainment. Preserving the open web requires sustained commitment: resisting shutdowns, promoting transparency, and reinforcing the technical and governance frameworks that keep the internet global, interoperable, and accessible. The internet's value-as a platform for opportunity, innovation, and human connection-depends on it remaining open to all.

The post Growing darkness: Against the rise of internet shutdowns appeared first on Open Policy & Advocacy.

26 May 2026 8:04am GMT

The Rust Security Response Team was notified that Cargo incorrectly handled symlinks inside of crate tarballs downloaded from third-party registries, allowing a malicious crate to override the source code of another crate from the same registry.

This vulnerability is tracked as CVE-2026-5223. The severity of the vulnerability is medium for users of third-party registries. Users of crates.io are not affected, as crates.io forbids uploading crates containing any symlink.

Overview

When building a crate, Cargo extracts its source code in a local cache (stored within ~/.cargo), reusing it for any future build. Cargo includes protections to prevent any file from being extracted outside of the crate's own cache directory.

It was discovered that it's possible to craft a malicious tarball able to extract files one level below the crate's own cache directory. With the way the cache is structured, that allowed the malicious crate to override the cache of other crates belonging to the same registry.

Mitigations

Rust 1.96.0, to be released on May 28th, 2026, will update Cargo to reject extracting any symlink within crate tarballs, regardless of whether they come from crates.io (which already forbids them) or third-party registries. Note that Cargo never added symlinks when running cargo package or cargo publish, so the impact of this should be minimal.

Users who are not able to upgrade to the most recent Rust version are recommended to audit the contents of their registry for the presence of any symlink, and to configure their registry to reject symlink (if such option is available).

Affected versions

All versions of Cargo shipped before Rust 1.96.0 are affected.

Acknowledgements

We'd like to thank Christos Papakonstantinou for reporting this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us address the vulnerability: Josh Triplett for developing the fix; Arlo Siemsen for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure; Ed Page and Eric Huss for advising during the disclosure.

25 May 2026 12:00am GMT

The Rust Security Response Team was notified that Cargo incorrectly normalized the URLs of third-party registries using the sparse index protocol. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry.

This vulnerability is tracked as CVE-2026-5222. The severity of the vulnerability is low, due to the extremely niche requirements needed to achieve the attack.

Overview

Originally Cargo only supported storing a registry's index within git repositories. Most git hosting solutions allow accessing a git repository with or without the .git suffix, so Cargo mirrored this behavior when normalizing registry URLs. This allowed credentials for https://example.com/index to be used for https://example.com/index.git.

This normalization was unintentionally applied to the new sparse indexes too. Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with .git as different URLs than those without the suffix.

If the following conditions apply:

• https://example.com/index is a sparse index.
• https://example.com/index allows crates to depend on crates from any other registry.
• The attacker is able to publish crates on https://example.com/index.
• The attacker is able to upload arbitrary files to https://example.com/index.git.

...the attacker could configure https://example.com/index.git to be a Cargo sparse registry requiring authentication for downloads, and with a download URL pointing to a server recording any credentials set to it.

When the attacker then publishes a crate foo to https://example.com/index depending on a crate bar from https://example.com/index.git, and tricks the victim into downloading foo, Cargo will think the two registries share the same credential and send the victim's Cargo token to the malicious registry.

Mitigations

Rust 1.96, to be released on May 28th, 2026, will update Cargo to only strip the .git suffix from registry URLs using the git protocol. No mitigations are available for users of older versions of Cargo.

Affected versions

All versions of Cargo shipped between Rust 1.68 (the stabilization of sparse registries) and 1.96 are affected.

Acknowledgements

We'd like to thank Christos Papakonstantinou for reporting this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us address the vulnerability: Arlo Siemens for developing the fix; Weihang Lo, Eric Huss and Emily Albini for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure.

25 May 2026 12:00am GMT

With Jujutsu, I've been able to work in multiple workstreams more efficiently than before. This means that if I'm working on multiple things, there is a higher likelihood of something going stale while I wait for a review or touch multiple files. Dealing with conflicts aren't so bad these days, however if I can automate the easy ones, why not?

This is the prompt I've been using with my agent whenever I have a list of changes that have conflicts and don't need me to participate actively on it.

Using the jj version control system, fix the conflicts that are in the changesets from `<start_rev>` to `<end_rev>`. Keep trying until there are no more "(conflict)" in the changesets between those two IDs.

25 May 2026 12:00am GMT

24 May 2026 3:48am GMT

Leif Oines and Will Lachance introduce Glean Annotations: a process and technology for curating and communicating knowledge about the data we collect in Mozilla's products.

24 May 2026 2:56am GMT

We try to be responsible with data. For example, we: - store as little sensitive data as possible - monitor changes in incoming data on which we've built models But what happens when those two approaches conflict? How do we monitor changes in incoming data that we don't want to store? This talk explains the schema we use to monitor changes in what people are searching for in Firefox...even when we deliberately don't store some of what people are searching for.

21 May 2026 6:30pm GMT

Launching Web Serial in Firefox 151

The web is built by communities, but not all communities use the web the same way.

That philosophy shaped part of this week's Firefox 151 release, which introduced support for the Web Serial API on desktop. Most folks won't use this API, but for our community of builders and tinkerers, it unlocks the ability to use Firefox to communicate directly with compatible hardware devices like microcontrollers, development boards, and other serial-connected devices.

For developers, makers, educators, hardware enthusiasts, and embedded-device communities, browser-based hardware workflows have increasingly become part of the modern web experience. With Firefox's browser engine, Gecko, now supporting Web Serial, users can now connect, code, configure, and control compatible hardware directly from the browser in many workflows, often without additional software or complicated setup.

If you want to dive deeper into the technical details behind Web Serial support in Firefox 151, you can read our full engineering post here.

Adafruit collaboration

As part of this week's launch, Adafruit, one of the internet's most beloved open-source hardware communities, is collaborating with us to test and validate what browser-based hardware development can look like in Firefox with Web Serial support.

If you've ever spent time with CircuitPython, browser-based board programming, custom controllers, sensors, classroom kits, STEM homework assignments, or a desk covered in blinking microcontrollers-you probably already know Adafruit.

With Web Serial support in Firefox 151, Adafruit's browser-based hardware workflows now work directly in Firefox as well, with no additional software or complicated setup required for many projects. We invite you to give it a try.

Different communities care about different browser experiences. Some people want simplicity, familiarity and productivity. Others want flexibility, customization, and tools that support the way they work, build, experiment, and create. We want the web to be open, flexible, and shaped by the diversity of people building on it.

If you're wiring up your first board, experimenting with hardware projects, or dusting off an old electronics kit, give Adafruit and Web Serial in Firefox a try.

Build something amazing. Make something useful. Tell us what works. Tell us what breaks. Most of all, make it your own.

The post Mozilla and Adafruit bring Web Serial workflows to Firefox appeared first on The Mozilla Blog.

21 May 2026 6:00pm GMT

Support for Web Serial in Firefox 151 for Desktop

Firefox can now connect directly to microcontrollers, development boards, 3D printers, power meters, and other serial-connected hardware from the web. Starting in Firefox 151 for Desktop, support for the Web Serial API allows web applications to communicate with compatible devices without requiring native software.

Web Serial compatible devices are popular among hobbyists, hardware hackers, educators, makers, and developers with use cases ranging from home automation to hardware prototyping and 3D printing. Web Serial support makes Firefox more useful for these kinds of projects.

Here's an example using an Adafruit ESP32-S2 based board where messages sent from web code can be directly displayed on the device over Web Serial.

We've collaborated with Adafruit to test Firefox's implementation against real hardware workflows commonly used by this community. The result: Firefox is a more practical browser for programming and interacting with hardware directly using web technology.

As an example of how you can combine Web Serial with electronics, Mozilla engineer Alex Franchuk created an amazingly fun and functional device that melds electronics and web editing. Check out the Page Playground.

The list of serial compatible devices includes Espressif ESP-based boards such as the popular ESP32 chips, Raspberry Pi Picos, 3D printers, LEGO devices, and many more. There are many tools for running your own code on these small affordable microcontroller boards, and with Web Serial it's easier than ever to connect them to a computer and interact through a web-based user interface.

What is Web Serial?

Web Serial is a web API that allows a website to read and write to serial devices using JavaScript. See the MDN documentation for the details. While modern computers don't typically include serial ports, serial devices connected to a USB port or paired via Bluetooth can advertise themselves as serial-capable devices so they appear as serial ports in the operating system.

The Web Serial API lets developers use the web platform to communicate with these devices. For example, websites can control devices or deliver firmware without requiring native applications or installers.

Mozilla's own Florian Quèze, who has experimented with many projects to measure power consumption, demonstrated how Web Serial could be used to read power data from an off-the-shelf USB power meter and display it in Firefox. Florian's code can also export the data into the Firefox Profiler, making it easy to visualize and share power data. Here's the page and GitHub repo. The screenshots below show the page in action and the data in the Firefox Profiler after recording the power usage of a light with three brightness modes.

Home Assistant is another example. It's a popular (and growing) open source project for home automation. The ESPHome project offers Home Assistant-compatible firmware for affordable ESP32 and similar devices which can be installed and configured over Web Serial in just a few clicks.

Security and Privacy

There are clear security and privacy concerns with allowing the web platform to read and write to hardware devices. Most importantly, with Web Serial, websites do not have visibility or access to serial ports until the user explicitly allows it.

Ports are allowed on a per-site and per-port basis. The Web Serial API requires websites to call navigator.serial.requestPort(), which lets the user choose which port to allow access to, or disallow all access entirely. This means websites do not receive a list of connected devices and there is no useful fingerprinting information outside of the port the user selects.

To help users understand when and why a site requests access to a serial port, Firefox uses add-on gating which we introduced with our Web MIDI API implementation. Compared to other web permission prompts, this gives the user a more detailed explanation of what they're allowing. The add-on gating prompts appear before the port selection prompt the first time a site requests port access.

For organizations using Firefox Enterprise Policies, Web Serial is disabled by default. Administrators can explicitly allow or disallow Web Serial functionality across their organization using the DefaultSerialGuardSetting policy setting.

Standardization

While Web Serial still resides in the Web Incubator Community Group (WICG), we're optimistic there's a path to standardization given its scope and long-running incubation. We are pursuing standardizing the Web Serial API in the WHATWG in a new Workstream proposal and are excited to work with ecosystem partners and standards bodies to help shape access to peripherals on the web.

Feedback

If you already have a Web Serial workflow with a device you can test on, give Firefox a try. We'd love to hear what you're building and which workflows matter most to you. Mozilla Connect is a great place to share projects, ask questions, and give feedback.

For technical issues, browse to support.mozilla.org or file a bug here.

The post Announcing Web Serial Support in Firefox appeared first on Mozilla Hacks - the Web developer blog.

21 May 2026 6:00pm GMT

Crafted with care. Built for speed. Ready for what's next.

A great browser is so intuitive that you often forget you're using it. Yet today the internet is changing faster than ever, and your browser needs to keep up. Firefox is still the only browser built for people, not platforms: independent, customizable, private and firmly in users' control.

Keeping Firefox the best browser for being online today is what motivated our recent work to update Firefox's design and design system. We're aiming to deliver a more cohesive foundation for Firefox: making the browser feel cleaner, warmer, faster and more adaptable.

Internally, we've been calling this work Project Nova. The name fits: A nova can look like a new star, yet it comes from existing matter - a renewal, not a replacement. When it rolls out later this year, you can just call it Firefox. Here's what it's all about:

Privacy at the center

A good default matters. When you choose Firefox, privacy and clear data practices are there from the start. Our new design pulls privacy features forward, making it easier to find and use tools like our free, built-in VPN and private browsing.

We're also redesigning Settings so choices about your data are easier to understand and act on. That includes controls for turning off AI features entirely, plainer language throughout, as well as tuning Enhanced Tracking Protection to match your preferred balance of protection and usability.

Speed you can feel

Privacy and speed aren't trade-offs. When Firefox blocks trackers, pages load faster, too. We also prioritize the most important parts of a page before the optional stuff around the edges. In the last year, we've improved load times for key page content by 9%.

The new design can speed up your workflows, too. It's easier to access tab groups, split view, and vertical tabs - putting these productivity features at your fingertips, but not in your face.

And we're bringing back compact mode. People told us that they missed it, and we listened. If you want your browser controls as condensed as possible, this one's for you.

Balancing the new and familiar

When it came to design, we wanted Firefox to feel current, but not generic. Warm, but still precise. More expressive, but never louder than the web itself. You'll see the change first in the fundamentals:

• Tabs have a softer shape, with a subtle gradient that gives the active tab more presence and creates a sense of light around the browser chrome.
• Components are more rounded and consistent, so panels, menus, settings and browser controls feel like part of the same system.
• Icons have been updated to feel cleaner and more balanced across light and dark themes, supporting quick recognition without adding visual noise.
• Spacing is rebalanced across the interface with the knowledge that every pixel matters when the browser is where you spend your day.
• The refreshed color palette is inspired by the feeling of fire: the glow around your active tab, deep smoky purples and lighter tones that add warmth.

The voice is warming up, too. Firefox copy is becoming more direct, more human, and sometimes more playful or fiery. Always genuine… because that's what sets Firefox apart.

The effect is distinctly Firefox: approachable and energetic, while still easy to scan. Under the hood, reusable tokens, components, patterns, and a shared design language make Firefox easier to evolve over time, so new features feel integrated instead of bolted on.

The redesign is most visible on desktop, but the work extends to mobile, too. Shared colors, icons, copy and design foundations help Firefox feel more consistent across devices.

Yours to shape

Firefox has long been the most customizable browser. It's in our open source DNA. Now we're adding more ways to make Firefox feel like yours, including new themes and wallpapers. And we're exploring more customization over time, like controls for the shape of the interface - tabs, components, and related visual treatments.

Accessibility is a key part of customization. Firefox is being designed with attention to contrast, readability, focus states, keyboard behavior, target sizes, system settings, visual comfort, and how the interface works across themes and windows.

Dark mode, for example, is not just a preference for many people. It is their default environment. For some, it helps reduce eye strain. For others, it is part of a broader system setup.

Building in public

Firefox has always been built in the open, and with the help of a global community of contributors and supporters. You help us build the browser, test, extend and improve it. You tell us when something doesn't feel right. That relationship is part of what makes Firefox different.

While the new design system for Firefox is still being shaped, keep telling us what feels right, and what gets in your way. We're listening.

The post Designing Firefox for the future appeared first on The Mozilla Blog.

21 May 2026 12:55pm GMT

The 2021 SciPy conference (https://www.scipy2021.scipy.org/) involved the showcasing of the latest open source Python projects for advancement in scientific computing. Mozilla was a diversity sponsor and a few Mozillians attended and shared their experience of the event.

20 May 2026 9:10pm GMT

Axe-time, sword-time, shields are sundered,
Wind-time, wolf-time, ere the world falls.
- Völuspá, Poetic Edda

As of Firefox 148, SpiderMonkey's asm.js optimizations are disabled by default, and we plan to remove the code entirely in a future release.

If you maintain a site that uses asm.js, nothing will break. asm.js is just a subset of plain JavaScript, so the code keeps running through our regular JIT just like any other script. That said, recompiling to WebAssembly will get you faster execution and smaller binaries.

History

asm.js was Mozilla's response to the question posed by NaCl and PNaCl: how can the web run code at native speeds?

The idea was clever: pick a strict, statically-typed subset of JavaScript that an engine could recognize on the fly and compile down to native code. We could get performance similar to NaCl/PNaCl and still have code live inside web content and use web API's (no separate sandbox, IPC, or alternative API's).

asm.js shipped in Firefox 22 back in 2013 and was a success. It let projects like Unity and Unreal ship C/C++ codebases to the web for the first time, using just standard web technologies. The Epic Citadel demo was ported to the web in just four days. It was a landmark achievement, and a fond memory for the original asm.js team.

asm.js proved that we could run code at near-native speed on the web using just web technologies. This opened the door to WebAssembly, which shipped several years later in Firefox 52. Without asm.js, we likely wouldn't have WebAssembly.

Why now?

So why turn it off? WebAssembly has succeeded, and asm.js usage has mostly migrated over. Keeping the asm.js path alongside WebAssembly costs us maintenance time and gives us extra attack surface in the VM.

If you are shipping asm.js content, please consider recompiling to WebAssembly! Our WebAssembly pipeline is significantly more advanced than the asm.js one ever was. You should see faster execution and smaller binaries.

Ragnarök

The asm.js compiler is called OdinMonkey. As was foretold long ago, OdinMonkey must meet his fated doom. The bug Ragnarök tracks the "Twilight of OdinMonkey".

All is not lost however, for born of OdinMonkey is BaldrMonkey, our WebAssembly optimizing compiler. OdinMonkey may be swallowed whole by the wolf, Fenrir, but BaldrMonkey will rule over the reborn world alongside RabaldrMonkey ("commotion"), our WebAssembly baseline compiler.

On this Odin's day (Wednesday) we thank OdinMonkey for thirteen years of service. Skål!

Then fields unsowed bear ripened fruit,
all ills grow better, and Baldr comes back;
Baldr and Hoth dwell in Hropt's battle-hall. - Völuspá, Poetic Edda

20 May 2026 5:00pm GMT

The redesign of Firefox Settings is now enabled by default in Nightly! With this change, we are making it easier for people to customize Firefox and discover the controls that matter most to them. The redesign improves navigation and organization, updates labels and descriptions, and uses a new underlying architecture that will make Settings easier to update over time.

Firefox Settings have grown a lot over the years. Our research showed that some areas had become crowded and more difficult to navigate, and that important controls could be hard to discover. Some terminology and layouts had also become inconsistent over time. Internally, the existing structure also made Settings harder to maintain and evolve over time.

Here are some of the changes you'll notice:

• More pages within Settings, with less content per page
• Clearer grouping and better flow between related controls
• Improved labels and helper text
• Consistent use of our design system throughout

The new Settings navigation and layout

While the organization of Settings has changed, all your existing choices and preferences remain in place. You can always use the search bar to jump straight to what you're looking for.

We plan to ship the redesign to the Release channel in Firefox 152. You will continue to see changes in Nightly, and we welcome feedback, especially in Mozilla Connect.

Customization has long been a core part of Firefox, and this redesign is intended to continue improving how people discover and manage their browser settings. We appreciate all of the feedback from the community so far on this project and look forward to refining the experience with your input!

20 May 2026 3:53pm 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

• Project goals update - April 2026 (end of 2025H2)
• Program management update - April 2026

Newsletters

• This Month in Rust OSDev: April 2026

Project/Tooling Updates

• Tonic is joining the gRPC project
• Toasty 0.6.0 - What is new?
• ex_ratatui: Elixir bindings for ratatui via Rustler NIFs
• OmniScope: A Cross-Language LLVM IR Static Analyzer Targeting Unsafe/FFI Boundaries:
• citum: a new Rust citation processor and associated tools.
• cargo-crap: Finding Untested Complexity in AI-Generated Rust Code
• What the Graph Owes: Connectors That Drive Outputs
• swpui: a TUI for case-aware search and replace
• kache 0.3.0: zero-copy efficient worktree compilation
• ghr: a Rust TUI for managing GitHub pull requests, issues, notifications, and reviews

Observations/Thoughts

• Scaling Rust codebases: Lessons learned organizing large projects and managing errors
• Migrating from Go to Rust
• Why I built wrkflw
• [video] Rust's God Mode
• [video] How Rust engineered the perfect async runtime

Rust Walkthroughs

• 5× faster fast_blur in image-rs
• Finding the Time Part 2 - Rust Async and the Arm Generic Timer
• Parsing Godot .tres files and walking the resource graph
• Rust x GBA: Setup and Pixels
• Learn Rust Lifetimes by Building a Generic LRU Cache
• How to benchmark Rust code with Gungraun
• Book: An Introduction to Programming, using ECS & EBP in Rust

Crate of the Week

This week's crate is cargo-crap, a cargo subcommand to calculate the Change Risk Anti-Patterns metric for a crate.

Despite a lamentable lack of suggestions, llogiq is pleased with his choice.

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

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

CFP - Events

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

• Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10

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

369 pull requests were merged in the last week

Compiler

• add Swift function call ABI
• implement pinned drop sugar

Library

• map_try_insert changes
• implement OsStr::split_at
• implement into_array for Vec<T>
• move std::io::Cursor to core::io
• move std::io::util to core::io
• widen the result of widening_mul

Cargo

• clean: respect build.target config for clean -p
• diag: Consolidate verify/run diagnostics passes
• diag: Report deferred diagnostics like other diagnostics
• diag: Pull in the parse pass
• lints: Avoid compiling where possible
• drop -Zunstable-options for rustdoc --emit

Rustdoc

• stabilize --emit flag
• correctly handle associated items in rustdoc macro expansion
• correctness & perf improvements to link-to-definition
• properly support macros with multiple kinds

Clippy

• fix duration_suboptimal_units for small literals
• fix arithmetic side effects false positive

Rust-Analyzer

• add diagnostic for E0029
• add diagnostic for E0614
• add diagnostic for E0638
• add handler for E0040
• encode the name instead of index in EnumVariantId
• fix assist qualify_path loses path segment
• add param on result methods for replace_method_eager_lazy
• complete ref_match in macro
• fully support pattern types
• handle usages in macro for extract_function
• no complete module colons before exists colons
• no lint unsized adt self_ty missing bounded assoc
• not complete same name inherent deref methods
• only ref match non-unknown value items
• show Run lens for fn main in bench targets
• handle TyKind::{Pat,UnsafeBinder} in has_drop_glue
• implement pattern_type macro
• method-resolution: emit error for method calls with illegal Sized bound
• migrate inline_call assist to SyntaxFactory
• perf: provide access to RootDatabase's LineIndex for the proc macro protocol
• show const in the signature help if applicable
• show unsafe in the signature help if applicable

Rust Compiler Performance Triage

Fewer than usual PRs merged, mostly due to a shorter week than normal and some CI trouble. Overall a slightly positive week for performance.

Triage done by @simulacrum. Revision range: 29b75901..281c97c3

0 Regressions, 0 Improvements, 4 Mixed; 1 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:

• Cargo RFC for min publish age

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

Compiler Team (MCPs only)

• Removing the unstable ptx linker flavor
• Create a new Tier 3 target: powerpc64le-unknown-none
• Optimize repr(Rust) enums by omitting tags in more cases involving uninhabited variants.
• Proposal for a dedicated test suite for the parallel frontend
• Promote tier 3 riscv32 ESP-IDF targets to tier 2
• Proposal for Adapt Stack Protector for Rust

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

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

New and Updated RFCs

• Documentation interpolation

Upcoming Events

Rusty Events between 2026-05-20 - 2026-06-17 🦀

Virtual

• 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Mouse Control with Rust
• 2026-05-20 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • May, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-05-21 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-05-21 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Tock OS Part #4 - Capsule coding in QEMU!
• 2026-05-26 | Virtual (Cardiff, GB) | Rust and C++ Cardiff
  • Hybrid event with Rust Dortmund!
• 2026-05-26 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-05-26 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: Seeing Into Your Code - A Practical Guide to Tracing in Rust
• 2026-05-27 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-02 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-06-04 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-06-10 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-16 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-06-02 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-06-17 | Virtual (Girona, ES) | Rust Girona
  • Weekly coding session
• 2026-06-17 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out

Asia

• 2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com)
  • AI Agents and Open Source LLM (Call for Speakers)

Europe

• 2026-05-18 - 2026-05-23 | Utrecht, NL | RustWeek 2026
  • RustWeek 2026
• 2026-05-21 | Amsterdam, NL | RustNL
  • RustWeek Hackathon
• 2026-05-22 | Amsterdam, NL | RustNL
  • Walking Tour around Utrecht
• 2026-05-22 | Amsterdam, NL | RustNL
  • Bike tour around Utrecht
• 2026-05-26 | Dortmund, DE | Rust Dortmund
  • Rust Dortmund Meetup - Agentic Programming - May
• 2026-05-26 | Manchester, UK | Rust Manchester
  • Rust Manchester May Code Night
• 2026-05-26 | Trondheim, NO | Rust Trondheim
  • Motorized blinds, and replacing Docker, in Rust!
• 2026-05-28 | London, UK | Rust London User Group
  • LDN Talks May Community Showcase
• 2026-05-29 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-06-03 | Dublin, IE | Rust Dublin
  • Join us live and INPERSON for Rust 261
• 2026-06-03 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 06 2026
• 2026-06-11 | Switzerland, CH | PostTenebrasLab
  • Rust Meetup Geneva
• 2026-06-16 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig
  • Interactive: Everything is Open Source

North America

• 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Mouse Control with Rust
• 2026-05-20 | San Francisco, CA, US | Bay Area Rust Meetup
  • Bay Area Rust Meetup
• 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • May, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-05-21 | New York, NY, US | Rust NYC
  • Rust NYC: "Boring File Storage" & "Indie News Feed Optimization"
• 2026-05-21 | Nashville, TN, US | Music City Rust Developers
  • Community Meetup
• 2026-05-23 | Boston, MA, US | Boston Rust Meetup
  • Allston Rust Lunch, May 23
• 2026-05-27 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-05-28 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-05-28 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA
• 2026-05-28 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-05-30 | Boston, MA, US | Boston Rust Meetup
  • Central Cambridge Rust Lunch, May 30
• 2026-06-04 | Saint Louis, MO, US | STL Rust
  • Testing, Coverage, Tracey & Mutations
• 2026-06-06 | Boston, MA, US | Boston Rust Meetup
  • Boston Common Rust Lunch, June 6
• 2026-06-11 | Lehi, UT, US | Utah Rust
  • Utah Rust June Meetup
• 2026-06-11 | San Diego, CA, US | San Diego Rust
  • San Diego Rust June Meetup - Back in person!
• 2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person

Oceania

• 2026-05-26 | Barton, ACT, AU | Canberra Rust User Group
  • May 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

Posts like this are useful for those of us who like to help, and who work on rustc to make it more helpful, by letting us learn about what kinds of mistakes people make.

- Kevin Reid on rust-users

Thanks to firebits.io 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

20 May 2026 4:00am GMT