fidzu : Mozilla

Our Community Office Hours series is all about connecting with the people behind Thunderbird and our products, and sharing the work that's happening behind the scenes. These conversations are a chance to learn more about the direction of our projects and to hear directly from the people making it happen.

In this episode, we are talking about Thundermail!

Since we first shared our plans for Thundermail, we have seen an incredible amount of excitement, curiosity, and thoughtful feedback from the community of early bird testers. In this Community Office Hours session, members of the Thunderbird team sit down to talk about the project's vision, share where things stand today, and answer some of the questions we've been getting along the way.

In this conversation, you'll hear about:

• Progress since the initial announcement of Thunderbird Pro and Thundermail
• Many of the community's questions submitted via Reddit.
• What we're working on next and what you can expect in the months ahead.

One of the best parts of Community Office Hours is the opportunity to have open conversations with our community. Your questions, ideas, and feedback help shape Thunderbird and its products, and we are excited to keep sharing updates as Thundermail continues to evolve.

Resources

Resources for Suggesting Features:

Thunderbird on Desktop and Mobile - https://connect.mozilla.org

Thundermail and Thunderbird Pro - https://ideas.tb.pro

Resources for diving into Thundermail:

Thundermail (and other services) roadmap: https://roadmaps.thunderbird.net/en-US/services/

Subreddit: https://www.reddit.com/r/ThunderbirdPro/

Thunderbird Pro addon repo that is now shipped natively in Thunderbird: https://github.com/thunderbird/tbpro-add-on

Thunderbird Accounts repo: https://github.com/thunderbird/thunderbird-accounts

Webmail client repo: https://github.com/thunderbird/stormbox

Appointment repo: https://github.com/thunderbird/appointment

Thundermail deployment repo: https://github.com/thunderbird/thundermail-deploy

SieveConnect repo: https://github.com/philpennock/sieve-connect

Resources for Getting Help with Thunderbird:

Thunderbird for Android Support Channel (Matrix) - https://matrix.to/#/#tb-android:mozilla.org

Thunderbird Desktop Support Channel (Matrix) - https://matrix.to/#/#thunderbird:mozilla.org

The post Community Office Hours: A Thundermail Update appeared first on The Thunderbird Blog.

14 Jul 2026 7:36pm GMT

Github Link

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

• Bug 2053330 - "Close and move to invalid bugs" button jumps way to the left (possibly under your mouse, asking for a mis-click) when you close a bug with another resolution.
• Bug 2052048 - Make the "Close as invalid" button a bit more targeted
• Bug 2053269 - BMO API bugzilla.login helper needs to support Bugzilla_api_token + cookie for authenication support
• Bug 2051396 - Make form.web.bounty stop adding the bounty flag and more strongly push people to HackerOne
• Bug 1355999 - Autocomplete on https://bugzilla.mozilla.org/form.web.bounty
• Bug 2049554 - Cloned security bugs should default to being secure even if they aren't in the default security group
• Bug 2036191 - Crash Signature Field Mismatch in Bugzilla REST API
• Bug 2043733 - Live Github Status for Pull Requests
• Bug 1619459 - Updated QA test to stop testing XMLRPC/JSONRPC and only test REST
• Bug 2052429 - "Show: Open/Closed/All" selects "All" incorrectly
• Bug 2052188 - "Close as Invalid" button is too close to the Attach New File button so can be confusing

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

14 Jul 2026 6:44pm GMT

Two years ago Mozilla asked two leading experts on deceptive design, Dr. Harry Brignull and Cennydd Bowles, to look at how Microsoft was treating people who tried to use a different browser on Windows. Their report, Over The Edge, documented a pattern of design choices in Windows, Edge, and Bing that nudged, pressured, and at times tricked people into using Edge.

This morning, the same researchers are publishing Over The Edge 2.0. They retested the same questions across Windows 10 and Windows 11, and added two new dimensions. First, how does Microsoft's approach change from one jurisdiction to another? They assessed Microsoft's tactics across four regions: the USA, India, the UK, and Germany, as a representative country in the European Economic Area. Second, they examined how AI features, specifically Copilot, are being used to shape the same outcomes the original report identified.

Their conclusion is short. Microsoft still does not allow users to download, set as the default, or keep using alternative browsers without harmful interference. The patterns are documented, and they meet established definitions of coercion, deception, and manipulation.

There is one bright spot. In Europe, where the Digital Markets Act applies, some harmful design tactics are gone. The Bing 'All you need is right here' panel and its trick wording. The nagging Windows 10 'You're almost done setting up your PC' journey. The Copilot data toggles that default to "On" in the US and India, by contrast default to "Off" in the EEA and the UK. Same Windows. Same Edge. Same Copilot. Different design choices, because the law required them.

That is the heart of the report. Although the EEA product still has obvious harmful design patterns, Microsoft has built a fairer user experience for browser choice. It has shipped that experience to one region. Everywhere else, including the US, the UK, India, and Brazil, harmful design patterns continue. This is an active choice - and one that can be made differently.

The findings are the researchers' own. Mozilla commissioned the work, and the report discloses that role, but the methodology, the screenshots, and the public journey database at edge.brignull.com let anyone check the evidence for themselves.

We make Firefox because we believe the web should serve people, not platforms. Firefox is independent, built by Mozilla, and designed around what is best for users, not what increases lock-in.

Read the full report here.

The post Over The Edge 2.0: what independent researchers found about browser choice on Windows appeared first on The Mozilla Blog.

14 Jul 2026 12:30pm GMT

Open source AI has crossed a threshold. For years the debate has centered around whether open models could ever compete with closed ones. This is no longer a debate we should be having. Today Mozilla is publishing its inaugural State of Open Source AI report, built on new analysis and a global survey of 950+ developers, showing that open models are no longer playing catch-up. The performance gap with top proprietary systems like ChatGPT and Claude has narrowed to just 3%, while costs have fallen up to 50x in three years.

But the report also surfaces a harder truth. Open models now power roughly a third of real-world AI usage, but capture only 4% of the revenue. So while the value is there, it just isn't flowing back into the open ecosystem that made it possible. Meanwhile, the geopolitical picture is shifting fast.

Asia is racing ahead

China and East Asia now lead the world in open source AI adoption, at 89%, far ahead of the West, treating open source as a cornerstone of national strategy. Governments elsewhere are responding, with 12 new national AI strategies launched last year, and 47 countries now restrict foreign processing for critical workloads. The EU, Canada, and India are backing open ecosystems with real public investment, treating AI infrastructure as a strategic asset.

Developers want open models, but they can't always ship them.

For developers, the appetite for open source is there, and cost and privacy rank as developers' top reasons for choosing models. But wanting to use open models and running them in production are different things. 79% of developers use open models, yet only 51% have deployed them in production, versus 63% for closed models.

As Álvaro Ruiz Cubero of SlashData, which fielded the survey for Mozilla, put it: "this gap indicates that there is not an issue purely of model quality, but of missing infrastructure. Deployment rates for open models barely increase with company size, highlighting a lack of mature tooling and support. At the same time, buyers are prioritising licensing terms (31%) and ownership (26%), signalling a clear shift toward control and flexibility over raw capability."

The real battle has moved beyond the model

Perhaps the most important finding may be the least obvious. The layer that matters most isn't the model. It's the agentic harness: the software between people and models that decides what an AI system can see, remember, and do. Changing the surrounding software can affect performance more than switching the model itself. Whoever controls that layer controls how AI behaves in the world.

Right now, that layer is being built with very few guardrails. Users approve AI agent requests by default up to 93% of the time, with so-called "consent fatigue" going largely unnoticed.

"Open source AI has reached a turning point," said Raffi Krikorian, Mozilla's Chief Technology Officer. "It's no longer about expanding access to models; it's about who has the power to shape, audit, and improve them. Without investment in the infrastructure, tooling, and governance around open models, we risk locking in a system where only restrictive, closed AI can scale - and that doesn't serve the public interest, or sovereignty over tech policy decisions."

Be owners, not renters

Open models offer what a subscription never can: owning your infrastructure instead of renting someone else's. Companies like Microsoft and Uber are already rethinking their reliance on paid, closed AI tools as the bills add up. The economics are shifting and so is the thinking.

If you're a CTO, a policymaker, a developer or an investor, this is the report for you. Read it, share it, and help build the infrastructure to make openness usable, not just possible.

Read the full Mozilla State of Open Source AI report here.

The post Mozilla's Inaugural 'State of Open Source AI' Report Is Here appeared first on The Mozilla Blog.

14 Jul 2026 12:00pm GMT

HDR video is coming to Firefox for Windows users (and has been available for some time on macOS). This blog post explains how we developed the feature and gives a retrospective on the technical choices we made.

A primer on video playback for the web:

• Video file demux and decode: A video stream generally consists of parallel image and audio streams, along with captions, HDR scene metadata, and the like. "Container" formats like MP4 or MKV specify how these streams are combined, or multiplexed, into a single byte stream for transmission. On receipt, Firefox needs to divide that byte stream back into the individual media streams; this is de-multiplexing or "demuxing". Then Firefox must uncompress the data to get images, audio samples, and so on. Firefox's media team provides the demuxers, and pulls in appropriate codecs to decode them. We prefer using hardware video decoders if they work reasonably well. Video decompression usually produces roughly a YUV 4:2:0 image in NV12 for SDR or P010 for HDR. (If you visit about:support in Firefox, and search for Codec Support Information (or one of the codec names like AV1), you can see a whole feature matrix of support details for which codecs are hardware and software on your system.)
• Gecko displaylist building: Given a demultiplexed, uncompressed frame of video, Gecko displaylist building incorporates it into a video element in the displaylist being sent to WebRender. If the frame was decoded in hardware, it is generally represented by a texture in GPU memory. Or, if it was decoded in software, then it is represented by a memory mapping holding some raw pixel data in system memory shared with Firefox's media decoder process.
• WebRender: Given the video element in the displaylist, WebRender decides whether to promote it to a desktop compositor overlay, or whether it must instead be rendered using a pathway more like an ordinary HTML element. A compositor overlay is faster and uses less power; on Windows this uses DWM with the DirectComposition API, which manages a graph of visuals. But if complex CSS is involved (rounded corners, blur filters, or similar features), Firefox must use WebRender's ordinary rendering pathway. Currently the latter is not HDR capable, so Firefox favors the desktop compositor overlay for animated elements such as video and canvas.

As we began designing Firefox's HDR support, we had to lay out some assumptions and found many complications:

• Initially, we had hoped that on a modern system, BT2100 HDR videos could be displayed on Windows by simply sending them to DirectComposition.
  • In theory, the Desktop Window Manager (DWM) honors the DXGISwapChain3::SetColorSpace1 method which should let us request either DXGI_COLOR_SPACE_YCBCR_STUDIO_G2084_LEFT_P2020 or DXGI_COLOR_SPACE_YCBCR_STUDIO_GHLG_LEFT_P2020. The former refers to SMPTE 2084, more commonly called PQ, the Perceptual Quantizer function and the latter is ARIB-STD-B67 also known as HLG, the Hybrid Log Gamma function, most commonly used on HDR TV broadcasts.
  • Unfortunately, this was a dead end. In testing with a mocked up compositor test app, calling SetColorSpace1 with this value seems to be ignored on P010 (at least in testing on AMD), so it incorrectly displays BT2100 PQ video as if it were BT709, which makes the video dull and muddy, since BT709 is a narrower gamut than BT2020, and the BT1886 transfer function used by BT709 is very different from PQ defined by BT2100. SetColorSpace1 may work on other vendors with P010, so it may be a valid optimization, but we were looking for a universal solution.
  • For the future, Windows 11 23H2 has added a new interface called IDCompositionTexture which may serve our purposes better; from what we have been told, it is universally supported for all formats and color spaces. We haven't used it for video so far, but it's an interesting future direction.
• As noted above, HDR videos must use a desktop compositor overlay. HDR video uses the BT2100 PQ colorspace with an RGB10A2 format, while WebRender can only work with images in the sRGB colorspace (appropriate for standard-dynamic-range BT709 video).
  • Until HDR came along, Gecko and WebRender only used desktop compositor overlays as a power/performance optimization. With HDR, overlays become a necessity as the pixel format and color space differ from classic sRGB.
  • Fortunately, HDR videos tend to be shown without particularly fancy CSS rendering such as clip masks and rounded corners, which would require WebRender to perform further copies. Technically, DirectComposition does support all of those features, but Firefox doesn't use that functionality much.
  • In the future, we expect to upgrade WebRender for HDR rendering, allowing us to deal with complex cases like clip masks or blur filters on video elements.
• We considered whether we could use VideoProcessorBlt, or whether we should write our own shader instead.
  • In favor of VideoProcessorBlt:
    • It uses less power on GPUs that have a video processor unit.
    • We discovered in testing (using CheckVideoProcessorFormatConversion) that while many modern GPUs support one of the needed conversions (P010 PQ -> RGB10 PQ), few support the ones we need for HLG videos (P010 HLG -> RGB10 PQ).
    • The 'video-dynamic-range' query used on the web is not fine-grained enough to be able to say "the web browser can display PQ video but not HLG video", so if we went with VideoProcessorBlt as a required feature, only about 20% of HDR desktop users would be able to use the feature.
    • In the future, we could explore using VideoProcessorBlit to save power on hardware that supports the conversions we need. But other web browsers are not using this functionality, so there may be more issues we haven't found yet.
  • In favor of writing our own shader with all of the features:
    • This would work consistently on all vendors - nothing special here.
    • This would look the same on all vendors, regardless of hardware capabilities. This is generally the aim of web standards.
    • This would support anything we want it to. HDR tonemapping can be implemented. Video orientation can be implemented (for videos recorded on phones which may be rotated 90, 180 or 270 degrees). We can support any kind of YUV->RGB conversion with a color matrix (even weird legacy formats like GBR 4:2:0). We can support conversion between color primaries (e.g. BT2020->BT709). We can convert to linear color (for scRGB using RGBA16F) or any EOTF we want (notably BT2100 PQ with RGB10A2, for our use-case).
  • In the end we went with the shader after a significant period of time experimenting with VideoProcessorBlt in our Nightly releases.
• There is a very large amount of graphics code in Gecko and WebRender that needs to be upgraded for HDR.
  • We decided that the most important code paths to upgrade first are the ones for regular video playback and DRM-protected video playback, and later canvas video import (Canvas2D, WebGL, WebGPU) which will require upgrading canvas for HDR first - another big project.
  • We had to upgrade several dozen structs to carry the transfer function for video data, as previously all code assumed video used BT1886 EOTF.
• We hope we can avoid tone mapping HDR content when viewed on HDR displays.
  • It's reasonable to expect that most displays going forward will be HDR displays (partly because of marketing momentum, partly because displays are made by a very finite set of manufacturers who are all making HDR display panels), and eventually tone mapping may become unnecessary on the web.
  • For the short-term we will have to apply a tone mapping effect when HDR content is viewed on SDR displays, likely using 'Reinhard tonemapping' which refers to the widely available paper Photographic Tone Reproduction for Digital Images by Erik Reinhard et al, and configuring it for a fixed brightness ratio of 400 cd/m^2 -> 100 cd/m^2 when used on SDR displays, and see if that fits all HDR content on the web well enough for a good user experience - and if it does not, we will iterate based on feedback from users on Firefox Nightly.
  • We are hoping that we will never have to apply tonemapping for HDR content on HDR displays, there are multiple factors in this decision:
    • Varying the brightness limit would make it a significant fingerprinting vector if not handled very carefully if the script can inspect pixels or parameters related to that. There are ways to mitigate this but they are all awkward restrictions to impose, and queries would have to get a different answer than what the rendering is using.
    • Phones and laptops with light sensors may vary the reference brightness in real time, and this changes the maximum displayable ratio (aka HDR headroom) every refresh, which is also a major battery drain if we keep redrawing all of the time.
    • Documents composed of multiple images (a gallery or some form of art composition) would apply different tonemapping to each image if the brightest pixel in each image is different brightness. We'd have to do something about that to make it controllable via CSS.
    • In general the detailed parts of an image are within a certain brightness band - see Debunking HDR for a detailed lecture on film grading and why you would not have significant difference in brightness between scene elements.
    • User feedback so far has indicated that not applying tonemapping has given them a better viewing experience on some videos.
• WebRTC is implemented using a library, common to all web browsers, which has limited support for HDR.
  • While we didn't prioritize this for an initial feature launch, we are looking at how to implement HDR support properly in libwebrtc. This is in the early assessment phase but we know this is wanted for a couple of use-cases, like video calls for meetings, or game streaming with friends watching.

In general, one of the biggest challenges in working on graphics code in a web browser is a lack of documentation for how to best use features like video playback and desktop compositing in the context of a web browser (e.g. multiple processes, sandboxing, shared memory, sharing external textures, etc). This parallels the rarity of graphics engineers with such experience. Building new features in this space requires a lot of research (and a lot of trial and error). The solution you end up with may not look at all like the one you initially imagined.

On behalf of the graphics team at Mozilla, I want to thank the people who use Firefox Nightly regularly and file bug reports when things aren't working the way they want. Comments on Experimental High Dynamic Range video playback on Windows in Firefox Nightly 148, Mozilla Connect, and Bugzilla bug reports have guided us to focus on the use-cases that matter to people using Firefox. When we succeed, it's a great feeling.

We're working on extending HDR support to photos, apps/games and general web content.

14 Jul 2026 4:15am GMT

Another six months have passed since our last development update, and the crates.io team has been busy. Here's a summary of the most notable changes and improvements made to crates.io since then.

Source Code Viewer

Crate pages now have a "Code" tab that lets you browse the contents of published crate versions directly on crates.io. This shows you the exact files that cargo downloads when you add a crate as a dependency, which might differ from the linked repository. This makes it much easier to audit your dependencies, including files that never appear in the repository, like the normalized Cargo.toml files that cargo generates.

The viewer comes with a file tree sidebar with search functionality, syntax highlighting, and GitHub-style line selection, where clicking or dragging line numbers produces shareable #L10-L20 URLs.

Under the hood, the server now builds a zip file for every published version. Since the .crate files that cargo consumes are gzipped tarballs without random access support, a background job re-packs each of them into a seekable zip archive plus a JSON manifest describing the contained files. Both are served from our static CDN. The frontend then fetches only the manifest and loads each file on demand with an HTTP range request. Because of this architecture, browsing crate sources essentially adds no load on the crates.io API servers. Existing crate versions have been backfilled, so this works for old releases too.

The rendering library behind the code viewer is a diff renderer at heart, and that's no accident: a version-to-version diff viewer built on the same infrastructure is currently in the works. This will allow you to review exactly what changed between two published versions, right on crates.io. Stay tuned!

Untangling crates.io Accounts from GitHub

At the end of May, the crates.io team accepted RFC #3946. Crates.io accounts always have been tightly coupled to GitHub: signing in means "Log in with GitHub", and your crates.io identity is your GitHub username. The RFC changes that. It introduces usernames that are native to crates.io and independent of linked GitHub accounts, as a prerequisite for eventually supporting login via other identity providers.

The implementation of crates.io usernames has started, but there is still a lot left to do, most visibly the ability to change your crates.io username. After that is complete, there will be future RFCs and implementation for signing in with identity providers other than GitHub. Since all of this touches authentication and account security, we are deliberately taking it slow and rolling these changes out in small, carefully reviewed steps.

Advisories and Suggestions

In our January update we introduced the "Security" tab, which shows security advisories from the RustSec database. We have since taken this integration one step further: crates that RustSec has flagged as unmaintained now show a warning banner directly on their crate pages, linking to the corresponding advisory for details and possible alternatives. Thanks to Dirkjan Ochtman for implementing this feature!

Related to this, some popular crates have been largely absorbed into the Rust standard library over the years, like lazy_static, which has been superseded by std::sync::LazyLock since Rust 1.80. Crate pages of such crates now show a friendly "You might not need this dependency" banner describing the standard library replacement, and superseded crates in dependency lists get a small light bulb icon with a similar hint.

The dataset behind this feature lives in the new rust-lang/std-replacement-data repository, together with a documented inclusion policy: standard library replacements only, every entry must cite the stable std, core, or alloc API and Rust version, and crate maintainers get a notice-and-comment window before an entry is added. New entries can be proposed upstream and can benefit other tools too.

Ferris

The most delightful change of this cycle: the Ferris on our error pages now follows your mouse cursor with its eyes:

Getting a 404 error on crates.io is now slightly less sad.

Svelte Frontend Migration Completed

In our January update, we announced that we were experimenting with porting the crates.io frontend from Ember.js to Svelte. This experiment has concluded successfully: the new frontend reached feature parity, went through a public testing phase in April, became the default at the beginning of May, and the Ember.js app has been removed from our repository.

We designed this change to be invisible for our users, since the new frontend is a 1:1 port of the previous design and functionality. For the team and our contributors, however, it is a big deal: the frontend is now built on a more modern framework, which should make it easier for new contributors to get started. It also allows us to iterate faster, as the source code viewer above demonstrates.

We want to thank the Ember.js team for a framework that served crates.io well for many years, and the Svelte team for making the transition so enjoyable.

Miscellaneous

These were some of the more visible changes to crates.io over the past six months, but a lot has happened "under the hood" as well:

• Search performance: Relevance-sorted search queries previously ranked every crate matching the query, which could take 1-2 seconds for short or common search terms. Ranking is now bounded to the 1,000 matching crates with the highest recent download counts.

• Reverse dependencies performance: The reverse dependencies endpoint no longer recomputes the full dependent set on every request. It is now served from a precomputed table kept in sync by database triggers, turning an expensive join into a bounded index scan and greatly reducing the chance of getting a timeout error.

• New ARCHITECTURE.md: If you've ever wondered how crates.io actually works, our ARCHITECTURE.md document got a complete rewrite. It is now organized around the high-level systems that make up crates.io and how they fit together, and includes walkthroughs of what happens when you run cargo publish, why a typical crate download never touches our API servers, and how download counts are derived from CDN access logs.

• Definition lists: READMEs now render Markdown definition lists, a widely used Markdown extension. Our markdown renderer comrak already supported them, the extension just wasn't enabled yet. Thanks to @mistaste for this contribution!

• CDN cache tags: Files uploaded to our static CDN now carry cache-tag metadata, allowing us to invalidate all cached files of a crate or a specific release in a single operation, instead of issuing one invalidation per file URL.

• Caching improvements: We removed a global Vary: Cookie response header that was preventing our CDNs from caching public API responses and frontend assets effectively. Per-user responses now use Cache-Control: no-store instead, resulting in better cache hit rates at the CDN edge.

• Accessibility: We have made crates.io friendlier to screen readers: decorative icons are now hidden from the accessibility tree, heading hierarchies have been fixed, and lists are marked up as proper lists. ARIA snapshot tests now ensure that regressions can't slip in unnoticed. We plan to continue to improve crates.io accessibility over the coming months.

• Git index performance: The background worker's local clone of the git index is now a bare and shallow repository, eliminating roughly 250,000 checked-out files and the full commit history from its disk, improving its performance as we see increased rates of crate publication. The periodic index squashing now goes through the GitHub API instead of generating large git packs locally, which had previously caused out-of-memory failures on the production worker.

Feedback

We hope you enjoyed this update on the development of crates.io. If you have any feedback or questions, please let us know on Zulip or GitHub. We are always happy to hear from you and are looking forward to your feedback!

13 Jul 2026 12:00am GMT

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

Security and privacy are core principles of Mozilla's Manifesto and remain at the heart of Firefox's development. In this edition, we highlight some of the key security and privacy initiatives from Q2 2026, grouped into the following areas:

• Firefox Product Security & Privacy, new security and privacy features, protections, and integrations in Firefox
• Core Security, platform security improvements, hardening efforts, and foundational enhancements
• Community Engagement, highlights from our security research community and bug bounty program
• Web Security & Standards, progress on web technologies and standards that help websites better protect users from online threats

Preface

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

Firefox Product Security & Privacy

Private Access Control Tokens (PACT): PACT is a cross-industry initiative designed to tackle one of the web's most urgent challenges: enabling websites to reliably distinguish legitimate users and authorized automated agents from abusive traffic without compromising user privacy. To introduce the initiative, we published a technical deep dive on Mozilla Hacks alongside a companion Mozilla blog post that explains the vision, motivation, and privacy-preserving design behind PACT.

Qualified Website Authentication Certificates (QWACs): Firefox is prepared to meet upcoming eIDAS requirements under the EU Digital Identity Framework. Qualified Website Authentication Certificates (QWACs), as required by the framework, are supported in Firefox 153 (Bug 2043399) onwards.

Hardening Firefox with Claude Mythos: In a blogpost we shared how our AI-assisted security testing pipeline, powered by Claude Mythos, uncovered and helped remediate hundreds of previously hidden vulnerabilities in Firefox, significantly strengthening the browser's security while demonstrating the transformative potential of AI to enhance defensive cybersecurity.

Visual Indications for Geolocation Access: In light of some web pages using geolocation for activities that are not related to their maps functionality, Firefox now displays a real-time visual indicator whenever a web page is accessing the user's geolocation. Starting with Firefox 153, the address bar now provides a real-time visual indicator the moment a website begins accessing a user's location, providing users with immediate awareness and greater transparency into when and how their geolocation data is being used.

Improving Website Compatibility in Private Browsing: Starting with Firefox 152, Private Browsing Mode now offers users the option to temporarily lower tracking protections for the current tab when stricter tracker blocking could be causing a website to malfunction. Previously, this may have resulted in users turning off privacy protections completely to continue using visited web page. With our new feature, users can quickly restore site functionality of the current tab, preserving users' overall privacy settings.

Instant fresh start through new Fire Button: Firefox 151 introduced the new Fire Button for Private Browsing, giving users an instant fresh start with a single click. Instead of closing and reopening a Private Window, users can immediately clear all browsing data and continue browsing in a clean session, making Private Browsing faster, more convenient, and just as private.

Advanced Anti-Fingerprinting Protections: Firefox 151 expands our default anti-fingerprinting defenses by ensuring the Available Screen Resolution, Touch Points, and Canvas APIs will provide uniform results for all of our users while also maintaining performance and compatibility. On macOS, for example, these enhancements are expected to reduce the share of users identified as unique by more than 20%, making it significantly harder for websites to uniquely identify and track users using obscure fingerprinting.

Local Network Access Protections: Firefox now requires user permission before websites can access apps and services on a user's local network or device, helping prevent unauthorized access and sneaky tracking attempts. The LNA feature is rolling out gradually, starting with Firefox Desktop 151 through 153. Android support will follow in upcoming releases.

Core Security

Firefox CA Root Program: We published Root Store Policy v3.1, introducing stricter transparency, documentation, and audit requirements for public CAs to strengthen trust in the Web PKI.

WebAuthn Related Origin Requests: This feature allows seamless passkey sign-ins across related domains e.g., the same provider using multiple top-level domains. In contrast to other browsers, Firefox UI provides transparency and choice so users are aware and can control when websites request for passkeys from other, related sites.

Community Engagement

Hosting Events: We organized and hosted multiple web tech meet-ups in the Mozilla Berlin office, bringing together the developer community to explore the latest advances in web technology, privacy, and security. If you're in the area, we'd love to have you join us at a future event.

Community Shares: Firefox tracking protection was presented at the SnooSec conference held in the Reddit NYC office. We also had a presentation about existing and upcoming protections against web tracking at the Chemnitz Linux Days conference, and a talk about the latest browser-based XSS protections at OWASP AppSec '26 in Vienna.

Web Security & Standards

Web Application Integrity, Consistency and Transparency (WAICT): We are working on WAICT, a new proposal to bring stronger integrity and transparency guarantees to web applications, helping make the web a more trustworthy platform for security-sensitive applications such as end-to-end encrypted messaging. We shared our technical vision in a Mozilla Hacks blog post, including a prototype implementation in Firefox Nightly that works with our WAICT Demo and a draft specification.

Sanitizer API: We are advancing the Sanitizer API to make robust protection against cross-site scripting (XSS) vulnerabilities more accessible. By exploring an implicit sanitizer policy that integrates with Trusted Types, we aim to prevent an entire class of XSS attacks with no application code changes, making secure-by-default web applications easier to build and deploy.

Looking Ahead

Firefox users will receive these security and privacy improvements automatically. If you're not already a user, we recommend you give it a try. Firefox helps you shape a more personal internet that puts you back in control - all while supporting the non-profit Mozilla in its mission to keep the web open, safe, and accessible for everyone.

Thank you to everyone who contributes to making Firefox and the web more secure and privacy-focused. You can have an impact too, just by reporting bugs, conducting research, contributing code, or providing feedback.

We look forward to sharing more updates in the Q3 2026 edition.

- The Firefox Security & Privacy Teams

12 Jul 2026 11:00pm GMT

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