fidzu : Mozilla

The web should be a place where people can choose how they connect, which tools they use, and who they trust. At Mozilla, we live these values, prioritizing products that ensure users can control their experience and that the web remains a global public resource.

Challengers across the tech ecosystem provide these competitive opportunities, but they contend with structural barriers imposed by tech giants leveraging market dominance. A healthy internet depends on ensuring that independent companies have a fair opportunity to innovate and compete on merit. That's why Mozilla and many others support key legislation like AICOA.

So how do we promote proposals like AICOA and ensure that challengers can thrive in markets controlled by powerful gatekeepers? We explored these questions and more at the recent Mozilla Meetup, "How Challengers Thrive: Why Competition Matters for AI, Security, and the Open Internet." Across panel events, a lightning discussion, and a networking happy hour, we discussed promoting an innovative, secure internet.

Partnering with Internet Works, Mozilla invited leading minds in tech policy to explore the importance of Middle Tech, AI's impact on security and competition, and new research on deceptive design practices. Below are some highlights.

On today's competition landscape, and Middle Tech as a user-first alternative:

Peter Chandler, Executive Director, Internet Works:

"Less competition equals less innovation equals less choices for consumers. It's that simple."

Charlotte Slaiman, Principal, Charlotte Slaiman Impact Advising:

"There are all sorts of reasons that competition is not just a click away. There are lock-in effects. There is gatekeeper power. Those things are protecting incumbents and making it much harder for consumers to switch to an alternative."

On the impact of deceptive design tactics:

Gemma Petrie, Principal Researcher, Competition & Regulation, Mozilla:

"For independent browsers like Firefox, dominant operating systems are both the gateway to consumers and the direct competitor. When these platforms use harmful design to undermine free choice, this is not simply inconvenient. It can create consumer harm by overriding informed choice, social harm by eroding public trust in technology, and market harm by undermining competition and innovation."

On the role of AI in competition and security:

Helen Toner, Executive Director, Georgetown's Center for Security and Emerging Technology (CSET):

"It is really notable that in open source software, if you have more eyes on software and you can identify vulnerabilities, that makes it easier and quicker to patch those vulnerabilities to solve the problem. With AI, often we actually don't have very good solutions when we identify problems, when we identify security risks, and so I think that can change some of the dynamics."

Chris Lewis, President & CEO, Public Knowledge:

"We have an opportunity. It's not too late in the AI era to not only design for competition through open technology, open source AI, model weights, some of the things we heard in the introduction, but also to set policies that promote competition."

Avery Gardiner, Director of Global Competition Policy, Spotify:

"A big part of what I'm thinking about with AI is how quickly it allows us to innovate as an app developer, right, and how quickly we can speed up our coding, bring more features to consumers, bring more things to market, and be better at innovating for the consumer. And all of our competitors can do the same thing. So there's this remarkable thing where the AI opportunities, the AI services, are getting better every passing day."

There's a reason we convene this community. As the web becomes both more complex and even more integral to our lives, competition offers people the ability to make meaningful choices about privacy, security, and control. Competition fosters innovation and spurs better products and services. Now is a particularly important moment to advance these priorities.

The post How Challengers Thrive and Competition Survives In Today's Ecosystem appeared first on Open Policy & Advocacy.

31 Aug 2026 6:16pm GMT

Hello everyone! It's Jamie. My internship at Mozilla is quite unfortunately coming to an end, after which I will be heading back to study at the University of Toronto. In this post, I want to share a rundown of my story working on the Localization (L10N) team, break down the projects I built, and reflect on what made this experience so special.

The First Day

Before joining Mozilla I was quite a bit nervous, as I had never worked at such a large organization before. The first day shattered this perception, as getting an office tour and having a live Q&A with VPs of Engineering really set the expectations of what working at Mozilla would be like.

The Toronto office became the go-to place for connecting with passionate, mission-oriented people across different teams. After getting my computer set up, I immediately got to work on Pontoon, Mozilla's Translation Management System (TMS). Since Pontoon's codebase relies on React and Django - frameworks I've worked with before - I was able to set up my local environment running smoothly and ship code early on. Over time, I had the opportunity to meet my fellow interns, each on their own teams, and we had chances to bond over our shared experiences and different problems.

Spending my break time in the lounge with my fellow interns.

Since Mozilla is a remote-first company, the L10N team is distributed across Europe and North America. Working with them was an absolute highlight. To put it simply, they are a brilliant group of people of engineers, project managers and open-source contributors who keep Mozilla, and by extension, the wider web open and accessible.

Group photo with the L10N team! Taken August 2026

So, what was working at Mozilla like?

Working at Mozilla, I had the opportunity to contribute to a variety of features involving Pontoon, associated localization workflows and other cool projects. During the duration of my internship, a great deal of localization related work was centralized and continues to be that way, which significantly influenced the projects that I worked on, and more generally, how the L10N team will continue to operate when I am gone.

This work unfolded against the backdrop of an ever changing technological landscape, particularly involving industry adoption of AI tools for code generation. In 2025 and 2026, agentic coding assistants like Claude Code and Cursor began to achieve mass adoption in software development. At Mozilla, I was introduced to Claude Code as a tool later in my internship, which was excellent, as it allowed me to gain a broad understanding of how the codebase worked without the use of AI. After the introduction of Claude Code to my workflow, I was able to push code and conduct code reviews on a much greater scale. I appreciate that Mozilla does not shy away from the practical uses of AI, especially in the realm of improving engineer and localizer workflows, and importantly, making it a choice.

The Work

Here is a shortlist of the varying projects I had the opportunity to work on at my time with the L10N team.

GraphQL Deprecation and REST API Implementation

The first task I was assigned to primarily revolved around the deprecation of Pontoon's public-facing GraphQL API endpoints in favor of a Django REST Framework implementation. The motivations for this project included a preference for simplicity, desire for faster API response times and consistency with existing vanilla Django REST endpoints. The new public facing API lives here.

Personal Access Tokens

The next project I was given was to devise a new personal access token (PAT) implementation in Pontoon in order to gate permissions to the newly created REST API endpoints. I was inspired by the way that GitHub did their Classic personal access tokens so I tried to model my design around their implementation as much as possible.

Pontoon Translation Search

The next project I took up was to reduce the feature gap between Pontoon and Transvision. For context, Transvision was and is used for searching available translations of strings across certain Mozilla products. It uses GitHub as its primary source, which is why it is limited only to the big projects. Thus the motivation was to create a similar service directly on Pontoon that has the most up to date strings with all Mozilla products, with data manipulation and access being a non-issue due to existing on Pontoon directly. Translation Search lives here.

Pontoon's Translation Search, which searches for strings across Mozilla's localized projects.

Taking responsibility for Pontoon Add-on

The Pontoon Add-on was a community maintained browser extension that enabled localizers to keep track of their locale's progress and receive any notifications from Pontoon directly in the browser. As part of the Pontoon API rework mentioned earlier, we needed to refactor the add-on code in order to maintain functionality. The main contributor had limited availability to continue maintaining the add-on anymore, so Mozilla assumed ownership of the extension, and we managed to clean up some of the backlog and redeploy.

Firefox for Android localization workflow changes

For years, Firefox Desktop and Firefox for Android used to operate under different localization workflows. Firefox for Android's workflow was written such that Android developers needed to maintain deprecated strings to prevent previous versions of localizations of Firefox for Android breaking. Firefox Desktop does not have this issue due to different logic, so I rewrote the whole Firefox for Android workflow to be closer in substance to Firefox Desktop's localization process. This subsequently deprecated the need for Android engineers to maintain the string deprecation process needed, which was great.

Insights Project Manager Dashboard and Alert system

The last main feature set I worked on was the Insights dashboard and accompanying alert system. For context, the Project Managers on the L10N team needed to calculate a score assigned to locales each month for community health analysis purposes using a mish mash of spreadsheets and Python scripts. This project automated the capture and calculation of these statistics to the first of each month and displayed them on a dashboard along with other useful information. The alert system was also implemented which notifies admins of significant changes of scores for specific locales, so certain locales can get increased focus.

Insights dashboard, which enables our Project Managers to track locale health over time.

Final Thoughts

Working at Mozilla has undoubtedly been an enriching experience. I have met a great number of incredible people who have guided me, encouraged me and shaped me into a better engineer and a better person. It has certainly widened my perspective on localization as a global effort, where peoples across different languages, cultures and creeds can work together to build a better web. I leave with sharper technical skills, amazing memories, and zero regrets, only immense gratitude for the opportunity to contribute to software that empowers millions. 🙂

Acknowledgements

To Matjaž (engineer and mentor): Your presence has been invaluable, both as a mentor and a friend. Thank you for your patience with my 10 PM deployment requests, endless questions, and edge-case bugs.

To Flod (manager): You are as always the backbone of the team, and have certainly taught me many lessons regarding leadership, professionalism and dependability. Thank you for reminding me about my deadlines and being the go-to for questions and feedback.

To Eemeli (engineer): Your Zoom call escapades have always been inspiring to me, from burning detritus, cooking random stuff, remote data lag spikes and such much more. I truly wish to become like you with such a vast and bottomless knowledge for so many facets of software engineering, before AI completely rots my brain.

To Ayush (fellow intern): I hope my mentorship was as helpful to you as your camaraderie was to me. You are going to accomplish great things, my friend.

To Eric (engineer): I very much enjoyed your unique German humor, your kindness and passion for building cool technologies.

To Camila (PM): Your personality is incredibly energetic, and I'm sure you will continue to bring so much positive energy to the team. I hope that you continue to be ambitious in everything that you do.

To Eda (PM): I really hope you enjoy working as part of the L10N team. I hope that you continue to make an excellent contribution to Mozilla!

Thank you for reading about my time at Mozilla! If you would like to learn more or wish to connect, feel free to contact me on LinkedIn.

Fin.

31 Aug 2026 6:07pm GMT

Servo 0.5.0 contains all of the changes we landed in July, which came out to 488 commits, and we now publish binaries for Linux aarch64 (@mukilan, #46760)!

DOM text selections are now visible (@mrobinson, @SimonSapin, #46698, #46864, #46742, #46889, #46126). Interactive selection is coming soon!

For security fixes, see § Security.

We've shipped several new web platform features:

• 'Cache-Control: stale-while-revalidate' (@arayaryoma, #46060)
• 'text-decoration-thickness' (@nicoburns, #46592)
• 'box-decoration-break', for the most part (@Psychpsyo, #45492)
• '@font-feature-values', for the most part (@simonwuelker, #45308)
• 'font-language-override', for the most part (@simonwuelker, #46618)
• 'font-variant-alternates', for the most part (@simonwuelker, #45308)

Plus a bunch of new DOM APIs:

• Ed448, X448, and KMAC algorithms in Subtle­Crypto (@kkoyung, #46402, #46141, #46180, #46583, #46606, #46622, #46334, #46376)
• 'insert­Horizontal­Rule', 'insert­Image', 'insert­Text', and 'forward­Delete' commands in document.exec­Command() (@Psychpsyo, #46608, #46597, #46538, #46838)
• Animation­Effect (@simonwuelker, #46677)
• new Touch() (@yezhizhen, #46741)
• duplex property on Request (@Taym95, #46858)
• effect property on Animation (@simonwuelker, #46677)
• get­Keyframes() and set­Keyframes() on Keyframe­Effect (@simonwuelker, #46118)
• id property on Largest­Contentful­Paint (@shubhamg13, #46828)
• read-only CSS­Font­Feature­Values­Rule (@simonwuelker, #46728)

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

• You can help!

• Security

• Real world compat

• Work in progress

• Embedding API

• For users and developers

• More on the web platform

• Performance and stability

• New contributors

You can help!

If you're working on a pull request that you think might be interesting for the next monthly update, even if you're not 100% sure, tell us about it by following the steps below:

1. You add the monthly update label to your pull request, or comment @servo-highfive monthly update

2. Highfive posts a comment asking you some questions

3. You answer those questions in a comment containing @servo-highfive monthly update answer

Security

Servo was potentially affected by vulnerabilities in quick-xml and crossbeam-epoch that have been fixed in Servo 0.5.0 (@atouchet, @Loirooriol, #46737, #46324). For more details, see RUSTSEC-2026-0194, RUSTSEC-2026-0195, and RUSTSEC-2026-0204.

We've updated ANGLE from a version based on Firefox 115.x ESR (02755361e26d8) to a version based on Firefox 140.12.0 ESR (f8025617e815f), which likely includes many security fixes (@jschwe, @sagudev, #46455, mozangle#100).

Real world compat

The duck on the DuckDuckGo (duckduckgo.com) landing page now renders in v0.5.0, after we fixed a preload bug that affected SVG images (@jdm, #46668).

v0.4.0

v0.5.0

Most of Gumroad (gumroad.com), except for the landing page, did not render at all in v0.4.0, but as of v0.5.0, pages like the Discover page or this product page render almost perfectly.

v0.4.0

v0.5.0

v0.4.0

v0.5.0

We're interested to hear how well your favourite websites run in Servo! Report successes in this Zulip thread, and failures in our GitHub issues.

Work in progress

The upgrade to Stylo 2026-07-01 brings several changes to built-in CSS functions (@Loirooriol, #46129):

• 'alpha()' is now supported, under --pref layout­_css­_alpha­_color­_function­_enabled

• 'progress()' is now supported, under --pref layout­_css­_progress­_function­_enabled

• 'ellipse()' values 'closest-corner' and 'farthest-corner' are no longer stable due to spec uncertainty, but they are still experimental, under --pref layout­_css­_ellipse­_corners­_enabled

• 'attr()' is more conformant, under --pref layout­_css­_attr­_enabled

Web­GPU content can now enjoy better conformance and use GPU­External­Texture and import­External­Texture() on GPU­Device, under --pref dom­_webgpu­_enabled (@sagudev, #45873, #46178, #46286).

Indexed­DB content can now use the name property on IDB­Index, under --pref dom­_indexeddb­_enabled (@skyz1, #45512).

document.fonts now includes a Font­Face for each valid '@font-face', under --pref dom­_fontface­_enabled (@simonwuelker, #46509, #46537).

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

We've started implementing WebVTT for native subtitles and captions, enabled by default (no --pref). While they don't render just yet, we can now fetch each <track src>, parse the WebVTT, and expose cues via the track property on HTML­Track­Element (@TimvdLippe, #46289, #46383).

July was a big month for accessibility in Servo, under --pref accessibility­_enabled. The focus for this month has been on performance, with the accessibility tree now supporting incremental updates (@alice, @delan, #45578, #45971, #46589, #46691, #46385), requiring fewer HashMap lookups and tree walks (@alice, @delan, #45798, #46740, #46348), and allowing for faster DOM mutations (@alice, #46348, #46530).

We've also started working on the File and Directory Entries API, to allow users to select and upload entire directories via <input type=file> and drag-and-drop. To that end, we now have webkit­Get­As­Entry() on Data­Transfer­Item, plus minimal support for File­System­Entry, File­System­Directory­Entry, and File­System­File­Entry, under --pref dom­_entries­_api­_enabled (@yezhizhen, #46456, #46879, #46832).

Embedding API

We've improved the docs for the servo crate, and for Web­View­Delegate (@mukilan, #46193).

Breaking change: Servo­Builder::webxr­_registry() has been removed. Instead use the new Servo::register­_webxr­_registry, which is a lazy design that has allowed servoshell to halve its startup time (@Narfinger, #46494).

For users and developers

servoshell for Android now runs on Android 10+ (91% market share), not just Android 13+ (68% market share), improving adaptability and reducing waste (@jschwe, #46142, #46308). We've also fixed a problem with building for Android on macOS (@jschwe, #46128).

servoshell for Windows is now better behaved when run in a console window, making the command prompt wait until servoshell exits (@yezhizhen, #43010).

When using the Firefox DevTools, the Console tab now supports some basic autocomplete (@freyacodes, #46382).

We've finished modernising servoshell for Android to use Compose UI (@veyndan, #46085, #46164, #46253, #46257, #46317, #46353, #46565, #46612, #46626, #46666, #46663, #46700), and we're now migrating Servo as a library to use Kotlin (@veyndan, #46817, #46895, #46772).

More on the web platform

Inline SVG can now use web fonts defined in the containing page (@yodalee, #45979). We're also implementing the SVG DOM, starting with stub interfaces for SVG­Element, SVG­Circle­Element, SVG­Defs­Element, SVG­Ellipse­Element, SVG­Line­Element, SVG­Linear­Gradient­Element, SVG­Path­Element, SVG­Polygon­Element, SVG­Polyline­Element, SVG­Radial­Gradient­Element, SVG­Stop­Element, SVG­Rect­Element, SVG­Symbol­Element, and SVG­Use­Element (@mu-mostafa98, #46558).

<button> now vertically centers its contents (@Loirooriol, @mrobinson, #46590), and behaves better with 'display: block' and 'display: inline' (@Loirooriol, #46536).

We've improved the conformance of <form> without <form action> (@kevlu93, #46860), <color> values (@Loirooriol, #46129), Gamepad­Event (@log101, #46788), document.execCommand("delete") (@Psychpsyo, #46539), the selector­Text property on CSS­Style­Rule (@simonwuelker, #46687), and Set Window Rect in WebDriver (@janeoa, #46475, #46477).

We've fixed bugs related to <iframe> (@jschwe, @jdm, #46587), <img> (@yodalee, #46892), <textarea> (@SimonSapin, @mrobinson, #46309), custom properties (@Loirooriol, #46129), '::before' and '::after' (@Loirooriol, #46640), 'flex-direction: column' (@simonwuelker, #46697), 'float' (@Loirooriol, @mrobinson, #46407, #46500, #46505), '@font-face' (@simonwuelker, #46568, #46271, #46436), 'position: absolute' (@simonwuelker, #46358, #46637), Blob (@jdm, #46881), IDB­Database and IDB­Object­Store and IDB­Index (@mrobinson, #46615), the adopted­Style­Sheets property on Shadow­Root (@simonwuelker, #46738), delete() on Font­Face­Set (@simonwuelker, #46634), move­Before() on Element (@mrobinson, #46599), resize­To() on Window (@janeoa, #46477), the selected property on HTML­Option­Element (@rhit-kapilaar, #46386), and the value property on HTML­Select­Element (@simonwuelker, #46230).

Performance and stability

2D canvas rendering is now multithreaded, improving frame rates by up to 55% and power consumption per frame by up to 42% (@yezhizhen, #46410), and should use a lot less memory too (@jschwe, @sagudev, #46786).

Text rendering is up to 10x faster for cases with the same text and different 'font-size' (@Loirooriol, #46129).

Flex layout benchmarks are up to 3% faster, and an improvement to get­Elements­By­Class­Name() has made some websites up to 1% faster (@Narfinger, @jdm, #46563, #46595, #46594).

We've also reduced memory usage, allocations, GC rooting steps, and other operations in many parts of Servo (@mrobinson, @jdm, @yezhizhen, @Narfinger, @Gae24, @SimonSapin, @Taym95, @cychronex-labs, @arayaryoma, #46499, #46411, #46659, #45974, #46377, #45758, #46440, #46762, #46301, #46349, #46419, #46418, #46420, #46460, #46633, #46638, #46690, #46745, #46726, #46564, #46144, #46664, #46462, #46139, #46430, #46446, #46498, #46548, #46598, #46632, #46656, #46678, #46718, #46722, #46238, #46072, #46408, #46438, #46437, #46528, #46124, #46330, #46412, #46807).

We've fixed a crash regression with memory corruption (@mrobinson, #46316), several dynamic-borrow-related crashes (@Narfinger, @SharanRP, @Taym95, @agrawalx, @amittenak47, @sungmen, #46381, #46384, #46405, #46684, #46452, #46770, #46830, #46763), plus crashes related to:

• <area> without <area href> (@simonwuelker, #46341)
• <progress> or shadow DOM (@mrobinson, @simonwuelker, #46188)
• <table> layout (@mrobinson, #46775)
• <td rowspan> (@mrobinson, #46841)
• <svg> without <svg viewBox> (@Narfinger, @mrobinson, #46199)
• <use> in SVG (@mrobinson, @Loirooriol, #46261)
• 'animation' (@mrobinson, @Loirooriol, #46689)
• 'content' (@Loirooriol, @mrobinson, #46314)
• 'mix-blend-mode' (@mrobinson, #45624)
• Array­Buffer (@jdm, #46504)
• adopted­Style­Sheets on Document (@TimvdLippe, #46373)
• exec­Command("delete") on Document (@TimvdLippe, #46265)
• removing DOM nodes (@SimonSapin, #46866)

We've continued our long-running effort to use the Rust type system to make Servo's integration with SpiderMonkey safer and more reliable (@Gae24, @Narfinger, @TimvdLippe, @jdm, @kunalmohan, @lumiscosity, @simonwuelker, #46191, #46777, #46890, #46243, #46248, #46246, #46310, #46312, #46333, #46147, #46150, #46151, #46229, #46262, #46375, #46374, #46529, #46584, #46585, #46593, #46693, #46166, #46156, #46254, #46267, #46268, #46269, #46270, #46284, #46285, #46318, #46435, #46461).

New contributors

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

• Umut Cevdet Koçak (@UMCEKO, #46256)
• Yash Agrawal (@agrawalx, #46770)
• amittenak47 (@amittenak47, #46743)
• Apoorva Pendse (@apoorvapendse, #46739)
• dDostalker (@dDostalker, #46181)
• Oisín Ó Maolchathail (@eachra-bawn, #46478)
• Kevin Lu (@kevlu93, #46860)
• Mohamed Mostafa (@mu-mostafa98, #45405)
• SeongMan Jeon (@sungmen, #46763)
• Yoda Lee (@yodalee, #45979)

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

Donations

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

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

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

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

31 Aug 2026 12:00am GMT

Bugs resolved in Moz-Phab 2.18.0:

• bug 1898339 moz-phab incorrectly uploads symlinks as text files when using Mercurial
• bug 2063674 Consider reminding people of their review queue when they push to try or moz-phab
• bug 2064223 Add pyrefly type checking to moz-phab test suite

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

1 post - 1 participant

Read full topic

27 Aug 2026 6:43pm GMT

Unified builds (also know as Jumbo Builds) is a build techniques that aims at improving build time through the concatenation of several sources as a single unified source before compilation.

The goal is obtained through implicit caching of header instantiation, although it implies a trade-off with parallelism.

Let's illustrate this behavior through a simple example, two codes that implement variation of the same approach:

/* algo0.cpp */
#include <iostream>
#include <string>
#include <vector>
void translate(std::vector<std::string>& w, void (&t)(std::string&));
void translate(std::vector<std::string>& w_out, std::vector<std::string> const & w_in, void (&t)(std::string&)) {
    std::cout << "[log] through transform\n";
    w_out = w_in;
    translate(w_out, t);
}

/* algo1.cpp */
#include <algorithm>
#include <iostream>
#include <string>
#include <vector>
void translate(std::vector<std::string>& w, void (&t)(std::string&)) {
    std::cout << "[log] through for_each\n";
    std::for_each(w.begin(), w.end(), [&t](std::string& s) { t(s); });
}

Compiling individual files take the following times:

% hyperfine --warmup 5 "/usr/bin/clang++ -O2 algo0.cpp -c"
Benchmark 1: /usr/bin/clang++ -O2 algo0.cpp -c
  Time (mean ± σ):     267.7 ms ±   7.4 ms    [User: 234.6 ms, System: 30.4 ms]
  Range (min … max):   259.7 ms … 277.3 ms    11 runs

% hyperfine --warmup 5 "/usr/bin/clang++ -O2 algo1.cpp -c"
Benchmark 1: /usr/bin/clang++ -O2 algo1.cpp -c
  Time (mean ± σ):     173.6 ms ±  46.3 ms    [User: 149.6 ms, System: 22.1 ms]
  Range (min … max):   130.4 ms … 231.6 ms    13 runs

Creation of the unified file is just a matter of invoking cat, let's benchmark the compilation of the unified source:

% cat algo{0,1}.cpp > unified_algo.cpp
% hyperfine --warmup 5 "/usr/bin/clang++ -O2 unified_algo.cpp -c"
Benchmark 1: /usr/bin/clang++ -O2 unified_algo.cpp -c
  Time (mean ± σ):     223.8 ms ±  64.5 ms    [User: 193.0 ms, System: 28.4 ms]
  Range (min … max):   160.8 ms … 301.8 ms    10 runs

In that simple case, the weight of headers with respect to actual user code is such that compilation of the unified file takes almost the same time as the max compilation time among each individual file. That's roughly a 1.97x speedup on compilation time.

That's the promise given by unified builds. And it's a promise held.

Now let's have a look at the consequences of that deal.

Beforehand, we still need to introduce another parameter tied to unified builds: the unification parameter, say P. That parameter bounds the number of files that are unified together. Let's imagine we have a hundred of individual source files compiled with exactly the same compilation flags. Setting P to 5 leads to the generation of 20 unified sources compiled independently.

Remember the parameter P.

% /usr/bin/clang++ -O2 algo0.cpp -c -fPIC
% /usr/bin/clang++ -O2 algo1.cpp -c -fPIC
% /usr/bin/clang++ -shared algo{0,1}.o -fPIC -o algo.so

% /usr/bin/clang++ -O2 unified_algo.cpp -c -fPIC
% /usr/bin/clang++ -shared unified_algo.o -fPIC -o unified_algo.so

/* pi0.cpp */
#define PI 3.141593
constexpr double pi() { return 3.141593; }

/* pi1.cpp */
#define PI 3.14159265
constexpr double pi() { return 3.14159265; }

/* overload0.cpp */
static float doit(float f) { return f;}
const float f = doit(1);

/* overload1.cpp */
static double doit(double d) { return d;}
const double d = doit(1);

/* using.h */
#pragma once
namespace a {
    namespace a {}
}

/* using0.cpp */
#include "using.h"
using namespace a;

/* using1.cpp */
#include "using.h"
using namespace a;

/* namespace0.cpp */
namespace a0 {
    int var;
}
using namespace a0;
int foo = var;

/* namespace1.cpp */
namespace a1 {
    int var;
}
using namespace a1;
int bar = var;

% tail -n +1 *.h *.cpp
==> header0.h <==
#ifndef H0
#define H0
namespace mozilla::dom {

class Lock final {};

}
#endif

==> header1.h <==
#ifndef H1
#define H1

#include "header0.h"

class Lock {};

class AutoUnlock {
    Lock *lock_;
};
#endif

==> src0.cpp <==
#include "header1.h"

==> src1.cpp <==
#include "header0.h"

==> src2.cpp <==
namespace mozilla::dom {};
using namespace mozilla::dom;
using namespace mozilla;


==> src3.cpp <==
#include "header1.h"

% for perm in 0,1 2,3 0,1,2 1,2,3 0,1,2,3; do printf "unifying $perm... " ; cat `eval echo src{$perm}.cpp` | clang++ -xc++ - -fsyntax-only 2>/dev/null && echo ok || echo ko ; done
unifying 0,1... ok
unifying 2,3... ko
unifying 0,1,2... ok
unifying 1,2,3... ko
unifying 0,1,2,3... ok

/* silent0.cpp */
#include <cstdio>
static int doit(int f) { putchar('0'); return f;}
const int f = doit(1);

/* silent1.cpp */
#include <cstdio>
static double doit(double d) { putchar('1'); return d;}
const double d = doit(1);

26 Aug 2026 10:00pm GMT

Following the symbolication work from Part 1, I undertook two more efforts to improve performance profiles for the Performance team.

Native Profiling (Bugs 2030161, 2030166, 2047451, and 2030423)

The first effort was to use platform-specific profilers to generate profiles in CI of browsers running the Speedometer 3 benchmark, the industry-leading benchmark for browser performance. These 'native' profiles provide rich, system-wide insight into how browsers handle Speedometer 3, helping developers analyze and diagnose behaviour. They also provide us with profiles we can use to generate comparison reports for patches. We needed Raptor to generate native profiles for all of our platforms, namely Windows, macOS, Linux, and Android.

At a high level, the pipeline to generate native profiles is as follows:

1. Start the system profiler.
2. Run Speedometer 3 on Firefox or Chromium as Release using Raptor and Browsertime.
3. Stop the system profiler.
4. Symbolicate the profiles using samply and the corresponding build symbols.
5. Post-process the symbolicated profiles using profiler-edit (formerly symbolicator-cli) and create compact and labelled variants of the profiles.
6. Upload the processed profiles as artifacts.

To run tests with native profiling, you can use ./mach try fuzzy --full or ./mach try perf --full and run any test that has the -native-profiling suffix.

On Windows, we produced profiles using xperf, a tracer that uses the Event Tracing for Windows framework (ETW) to capture system-level data on applications running on Windows. To use xperf with our CI machines, scheduled tasks to run the tracer were configured in Puppet (see our ronin_puppet repository).

After adding support to Raptor to trigger these xperf tasks, we can start a trace and run the Speedometer 3 benchmark on Firefox or Chromium as Release (our custom Chromium build configured with release flags) using Browsertime. The Speedometer 3 benchmark runs 20 times, with each run in a separate browser cycle, to ensure we collect enough samples before stopping the trace.

Once completed, xperf provides a user trace and a kernel trace, which are combined into a full trace. We can then use samply to convert and symbolicate these traces into Firefox Profiler profiles, complete with markers and JIT information (Figure 1 and Figure 2).

Figure 1: Native profile of Speedometer 3 running on Firefox on Windows

Figure 2: Native profile of Speedometer 3 running on Chromium as Release on Windows

On macOS, we took a similar approach. We used samply to collect and symbolicate profiles. After implementing a workaround to allow samply to profile across multiple browser cycles and sorting out permission issues in CI, samply could profile Speedometer 3 on Firefox with minimal CI configuration and symbolicate the profiles afterwards.

On Linux, we ran perf with elevated privileges to collect profiling data system-wide before using samply to symbolicate and convert the data into a Firefox Profiler profile. Other than enabling our CI machines to run sudo perf, no additional machine configuration or workarounds were needed.

For Android, we took a slightly different approach. We used simpleperf to collect profiles on our mobile devices in CI (Samsung A55, Google Pixel 6, and Samsung S24) and samply to symbolicate them.

Initially, we wanted to profile 20 Speedometer 3 runs in a single simpleperf session, matching our desktop profiling workflow, but this proved unreliable during testing, as the on-device profiling appeared to be resource-intensive and would intermittently fail or crash.

We decided to use our simpleperf support introduced in Browsertime in Part 1 to profile the 20 individual test suites that make up a single Speedometer 3 run separately, which proved to be more stable (Figure 3). In the long term, we plan to support profiling complete Speedometer 3 runs with simpleperf on Android, bringing the workflow closer to what we currently use for desktop profiling (Bug 2032007). We will introduce native profiles for Chromium as Release (mobile) on Android in Bug 2067157.

Figure 3: Native profile of the TodoMVC-Vue Speedometer 3 test running on Fenix (Firefox for Android)

To make our Speedometer 3 profiles clearer and more helpful, we post-process them with profiler-edit, which adds labels (groupings of JS frames) to the profile (Figure 5) and also provides a more compact version (Figure 4) where all runs are placed on the same process track.

Figure 4: Compact Speedometer 3 native profile

Figure 5: Labelled Speedometer 3 native profile

In CI, we routinely generate Firefox profiles on autoland (Figure 6) and Chromium as Release profiles on mozilla-central. These native profiles have already been used to produce Speedometer 3 comparison reports (Figure 7) and investigate incidents in CI. Currently, profiles for Chromium as Release on macOS and Linux are works in progress (see Bug 2050869 and Bug 2065970, respectively).

Figure 6: Native profiles running routinely on autoland

Figure 7: Comparison reports using native profiles (preview courtesy of Markus Stange)

Modernizing mozgeckoprofiler (Bug 1992000)

The second effort was to fully modernize symbolication in mozgeckoprofiler, the module responsible for symbolication across four performance testing frameworks: Raptor, Talos, XPCShell, and Mochitest. This mainly involved phasing out Eliot, an older symbolication API service scheduled to sunset in the near future, and fully transitioning the module's symbolication workflow to use samply and profiler-edit.

In Part 1, we added support that allowed Raptor and Talos to symbolicate their profiles using our new approach. This left two main cases that were still handled by Eliot: XPCShell and Mochitest symbolication, and local profile symbolication.

Implementing XPCShell and Mochitest profile symbolication (Bug 1998767) was relatively straightforward. We followed the same approach used for Talos and Raptor by adding our new symbolication dependencies to XPCShell and Mochitest taskgraph configurations. Since these tests and their profiles (Figure 8) can be generated in parallel, we made sure to perform symbolication only after all profiles had been generated. You can try these jobs by running ./mach try fuzzy --profiler and selecting any XPCShell and/or Mochitest job (Figure 9).

Figure 8: Symbolicated Mochitest profile

Figure 9: Mochitest tests running in CI produce symbolicated profiles

Originally, when generating profiles locally from one of our performance frameworks, Eliot was used to symbolicate those profiles. To replace it with our new approach, we needed to bootstrap samply and profiler-edit onto local developer machines. Now, when you run ./mach bootstrap, the latest builds of samply and profiler-edit available in CI for your platform are automatically installed under the local .mozbuild/ directory. With this change, the use of Eliot in PerfTest has been completely replaced by our new symbolication approach, and Eliot can safely be retired from mozgeckoprofiler!

What's Next

These patches are part of an ongoing effort to make performance profiling easier, more standardized, and more useful for Firefox developers. Here are a few related bugs to keep an eye on:

• In Bug 2050869, Bug 2065970, and Bug 2067157, we'll add Chromium-as-Release profiling support for macOS, Linux, and Android, respectively.
• In Bug 2066906, we'll officially remove Eliot as mozgeckoprofiler's fallback symbolication service.
• In Bug 2032007, we'll add support for profiling full Speedometer 3 runs with simpleperf, rather than producing a profile for each test suite.
• In Bug 2036104, we'll continue developing reports that compare native profiles across patches, making it easier for developers to investigate performance differences and regressions.

26 Aug 2026 7:28pm GMT

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

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

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Announcing our first Maintainers in Residence
• Enabling the next-generation trait solver on nightly
• Supply chain attack on arrayref
• Rust Function Overloading - Call for Experimentation

Project/Tooling Updates

• Intent to Ship: JPEG XL - Mozilla Hacks - the Web developer blog

Observations/Thoughts

• Scaling Memory Safety: AI-Assisted Rewrites of C/C++ Dependencies to Rust
• Replacing a Rust Enum with a 64-bit Word Made My Interpreter 17% Faster
• 3 Seconds of compilation shaved by metadata analysis
• Your E-Paper Panel Isn't Broken: How Retained State Makes Drivers Look Buggy
• To Async or Not to Async: Building a Rust MCP Server for rust-analyzer
• One trie, three jobs, zero benchmarks won
• Fixing Rust's supply chain security: The good, the bad and the ugly

Rust Walkthroughs

• Rust errors every beginner hits
• Build a Scientific Calculator in Rust - Understanding Variables and Types
• Proving SQLx's Statement Cache with bpftrace
• Beyond WASI: Rust applications in-browser

Miscellaneous

• JetBrains Partners with the Rust Foundation for an AI Livestream

Crate of the Week

This week's crate is swift-topomap, a microarchitectural observability tool.

Thanks to Ankur Rathore for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

Rust

• Tracking Issue for --remap-path-scope in rustdoc

Cargo

• Tracking Issue for -Zembed-metadata

No calls for testing were issued this week by 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.

• sysknife - Split the Ubuntu-only actions out of DEBIAN_ONLY_ACTIONS
• sysknife - Make Debian eligible: a version floor of 12, and a reason in is_supported
• sysknife - Debian's default firewall is nftables, and the catalogue has no nftables vocabulary

• stomatopod - Add a Docker Compose healthcheck on /health
• stomatopod - Add a custom GitHub social preview image
• stomatopod - Document the v0.1.0 GHCR tag next to :latest

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

593 pull requests were merged in the last week

Compiler

• add a cache to the WfPredicates visitor
• allow self in const generics
• eliminate some buggy unreachable!()s in expand_(option_)env()
• enable -Znext-solver on nightly by default
• optimize DeepRejectCtxt

Library

• add Arc/Rc::strong_count_from_raw
• add Default implementation for std::sync::Once
• add symmetric PartialEq impls for Vec, &[T], &mut [T] versus Cow<'_, [T]>
• core: implement float conversion methods
• make BorrowedCursor<'a, T> covariant in 'a and drop an indirection
• rework div_ceil for nonzero integers
• stabilize bool::toggle
• stabilize never type

Cargo

• config: Add build.fingerprint
• fix git gc with safe.bareRepository=explicit
• install cargo tools with locked dependencies

Rustdoc

• add new invalid_markdown_table rustdoc lint
• only generate search DOM elements if the search is actually needed
• enable scrolling only on table/code
• fix issue preventing "read more" links from generating

Rustfmt

• fix ICE on for await loops with separated keyword tokens
• fix brace placement for multiline control flow
• fix comments rewritten too long
• correct the span used when rewriting ast::TyKind::FnPtr
• correct visibility and defaultness order on associated impl type alias
• inconsistent formatting of doc comments in macros

Clippy

• optimize Clippy with PGO
• unnecessary_fold: lint folding over an Option's iterator
• unused_trait_names: make the suggestion nicer
• avoid manual_assert_eq for byte slice-like types
• don't fire manual_contains when both sides use the slice element
• fix large_futures ICE with the next solver
• avoid double_must_use in macro-generated code
• make needless_bool less aggressive for chained ifs
• perf: check first_node_in_macro before the root macro walk in useless_format
• remove broken suggestion for blocks_in_conditions
• suggest hypot for x.mul_add(x, y * y).sqrt()
• suggest is_ok/is_err for boolean Result mappings
• trigger integer_division_remainder_used on DivAssign/RemAssign

Rust-Analyzer

• hir: Use expression store of parent body if available
• adds-arrow unmap ranges when fn inside macro
• allow asm! label blocks to diverge
• prevent stack overflow for recursive ADT layouts
• optimize the heck out of the storage of token trees
• use Cargo build directory for flycheck logs

Rust Compiler Performance Triage

A busy week, with a continued stream of improvements to the next trait solver and next borrow check implementations. Other than those changes, the week was pretty quiet for performance.

Triage done by @simulacrum. Revision range: 8fa1c96c..9a4ad59a

2 Regressions, 4 Improvements, 2 Mixed; 2 of them in rollups. 28 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

• make target feature ABI check a hard error on ARM
• stabilize smart pointer map functions
• volatile: allow accesses to non-AM memory to trap
• Stabilize the supertrait_item_shadowing feature
• Add intrinsics for integer minimum and maximum
• Always escape grapheme extenders in str::escape_debug

Rust RFCs

• Change i686-pc-windows-msvc from Tier 1 with host tools => Tier 1 without host tools

Cargo

• feat(resolver): Stabilize min-publish-age

Compiler Team (MCPs only)

• Add codeview_annotation intrinsic

Leadership Council

• Update PD election process based on 2025 feedback
• Create an LLM policy team

No Items entered Final Comment Period this week for Language Team, Language Reference 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

• Add core::ffi::c_longdouble
• RFC: add freeze operation

Upcoming Events

Rusty Events between 2026-08-26 - 2026-09-23 🦀

Virtual

• 2026-08-26 | Virtual (Cardiff, UK) | Rust and C++ Cardiff
  • Operating Systems Book Club: Lottery and Multi-CPU Scheduling
• 2026-08-27 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-08-28 | Virtual | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-31 | Virtual | Rust 🦀 Maven
  • Workshop: Add tests to an open source Rust project
• 2026-09-01 | Virtual | Rust 🦀 Maven
  • Tauri: Cross-Platform desktop applications with Rust and web technologies
• 2026-09-02 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-09-02 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-09-04 | Virtual | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-09-06 | Virtual | Rust 🦀 Maven
  • Facts: Curated Knowledge for Humans and Agents
• 2026-09-06 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-09-08 - 2026-09-11 | Hybrid (Montreal, CA) | RustConf 2026
  • RustConf 2026
• 2026-09-08 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-09-08 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-09-10 | Virtual | Rust 🦀 Maven
  • Solving Real-World Planning Problems in Rust with SolverForge
• 2026-09-10 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-09-10 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-09-15 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-09-16 | Hybrid (Vancouver, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2026-09-17 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • September, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-09-18 | Virtual | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-09-20 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-09-22 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday Rust Bookclub

Africa

• 2026-09-08 | Johannesburg, ZA | Johannesburg Rust Meetup
  • Rust's extended standard library

Asia

• 2026-08-29 | Pune, IN | Rust Pune
  • Rust Pune Meetup: August 2026

Europe

• 2026-08-26 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #71 Sponsored by Factbird
• 2026-08-26 | Dresden, DE | Rust Dresden
  • Third Meetup
• 2026-08-27 | London, UK | Rust London User Group
  • LDN Talks August Community Showcase
• 2026-08-27 | Manchester, UK | Rust Manchester
  • Rust Manchester August Talks
• 2026-08-29 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #29
• 2026-09-08 | Paris, FR | Rust Paris
  • Rust meetup #87
• 2026-09-14 - 2026-09-16 | Berlin, DE | Oxidize 2026
  • Oxidize 2026
• 2026-09-15 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Reproducing scientific papers - with Rust & "AI"
• 2026-09-22 | Prague, CZ | Rust Prague
  • Rust Meetup Prague @ Rockwell Automation

North America

• 2026-08-26 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-08-26 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA August! Rust in Quantum Computing
• 2026-08-27 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-09-03 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-09-03 | Saint Louis, MO, US | STL Rust
  • Cryptography + Quantum Computers
• 2026-09-08 - 2026-09-11 | Hybrid (Montreal, CA) | RustConf 2026
  • RustConf 2026
• 2026-09-09 | Montreal, CA | Women in Rust
  • RustConf Coffee Break Meetup
• 2026-09-10 | Lehi, UT, US | Utah Rust
  • Hands-on Embedded Rust
• 2026-09-10 | San Diego, CA, US | San Diego Rust
  • San Diego Rust September Meetup - Back in person!
• 2026-09-15 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-09-16 | Hybrid (Vancouver, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2026-09-17 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • September, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-09-17 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-09-23 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground

Oceania

• 2026-08-27 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne August 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

I care about this community, including its human and social nature. I want others to appreciate those qualities, and I don't want to see them compromised and replaced by excessive machine-generated content.

- Quine Dot on rust-users

Thanks to Jonas Fassbender 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

26 Aug 2026 4:00am GMT

We are very happy to announce the Rust Project's first round of Maintainers in Residence: Gen Li (@rami3l), Chris Denton (@ChrisDenton), Alejandra González (@blyxyas), León Liehr (@fmease), and Maintainer Grant recipients: Jason Newcomb (@Jarcho) and Jonas Böttiger (@joboet). These contributors will be funded for their rust-lang maintenance activities for (at least) the following 12 months!

The funding of the Maintainer in Residence (MiR) and Maintainer Grantee roles is possible thanks to generous donations to the Rust Foundation Maintainers Fund (RFMF) from Google, AWS, OpenAI, the Rust Project Leadership Council and also individual sponsors. We also want to thank the people who advocated for maintainer funding within their companies; Tyler Mandry from Google, Niko Matsakis and Jess Izen from AWS and Predrag Gruevski from OpenAI, and also the whole Rust Leadership Council and our funding advisors. If you would like to help us support even more Rust contributors, consider donating to RFMF.

The Rust Foundation has published a press release and a blog post, where you can learn more about the sponsors and the supported contributors.

Read more below to learn about the MiR program, how we chose the funded contributors, and of course who they are!

Background

The Maintainer in Residence program, established in RFC 3931, is designed to provide stable financial support for Rust contributors, so that they can truly focus on crucial maintenance activities. Currently, there are three categories of support that we offer:

• Full-time MiR: funded for 5 days/week of Rust Project work
• Half-time MiR: funded for ~2.5 days/week of Rust Project work
• Maintainer Grant: funded for ~1 day/week of Rust Project work

Funding for this program comes from the Rust Foundation Maintainers Fund, which was launched recently, and the whole program is managed by the Rust Funding team.

When deciding who to fund, we took a systematic approach. First, we looked at Rust teams to understand their maintenance baseline (the smallest number of maintainers they need to ensure a healthy long-term status of the given project or repository), and how far they currently are from that baseline. From there, we identified and prioritized Rust teams who were both critically underfunded, and have a high impact on the language and its users. These teams (in no particular order) were rustdoc, rustup, cargo, compiler, libs, clippy, rustfmt, rust analyzer and mods.

The next step was pairing these teams with maintainers looking for funding. And it turns out that finding such maintainers for some teams turned out to be much more difficult than we originally assumed! For example, some maintainers are already employed, some do not want to be funded, and while we did our best to promote our funding efforts, not everyone looking for funding actually asked us for it. We also realized that some teams on our list have essentially no active members, which makes it tricky to onboard new contributors, even if they would like to help out.

In the end, we decided to start by supporting six contributors, who will help maintain several critical Rust projects and teams and who could start immediately. However, we are not stopping there. Our funding efforts are ongoing, so stay tuned for more MiR announcements in the near future! If you would like to learn more about our process, check out our recent post.

And now, without further ado, let's meet our newly funded maintainers!

Gen Li (@rami3l)

Gen Li (@rami3l) is a full-time MiR focusing on Rustup.

He has been a Rustup team member since 2023 and its lead since 2025. He deeply cares about the facets of Rust that many might have taken for granted, and embodies all attributes we were looking for in a MiR: he wants to take on complex issues, continue mentoring, and work on important Rustup features, among many other things.

Turning volunteering into an actual job has really been an empowering experience so far! I finally have the bandwidth to take a careful look at my inbox and can actually read each message without the fear of missing crucial details while rushing prompt replies, which has really helped me retain the essential compassion as a maintainer. I also get to interact with regular contributors a lot more often. Finally, I can't wait to see what I can come up with in terms of Project Goals :)

Chris Denton (@ChrisDenton)

Chris Denton (@ChrisDenton) is a half-time MiR focusing on the standard library, compiler, Rustup and anything Windows-related.

For the past five years Chris has been bringing his deep knowledge of Windows to help Rust sustain and improve its great cross-platform support. He will be unblocking other contributors in various Windows use cases, performing refactoring and code reviews and implementing new features across several areas of the Project.

Even though it is still early days, I'm feeling pretty optimistic about the health of the Rust Project going forward, thanks to the recent funding efforts.

Alejandra González (@blyxyas)

Alejandra González (@blyxyas) is a half-time MiR focusing on Clippy.

She is a Clippy team member always keen on improving performance and helping new contributors. She will focus on making Clippy faster and also reviewing its pull requests, to help get the ~300 pull request backlog down. Additionally, she is excited to mentor people from the Rust for Linux project to work on Clippy, and fine tune the open peer review system that Clippy started using earlier this year.

Funding is the system that helps me pour my heart into a project without worrying about making ends meet. Having those needs met is a game-changer and boosts my productivity. One of the areas where I want to focus my efforts is mentoring new contributors. If new people coming is the lifeblood of a project, I want to be the cardiologist!

León Liehr (@fmease)

León Liehr (@fmease) is a half-time MiR focusing on rustdoc and the compiler.

He is a member of the rustdoc and compiler teams, who is usually working on the Rust type system or issues related to parsing. He will continue working on complex features that he started a few years ago, and also focus on general maintenance, code reviews, refactoring and mentoring.

Being funded to work on Rust means I can sustainably focus my time and energy on a project I call a passion of mine.

Jonas Böttiger (@joboet)

Jonas Böttiger (@joboet) is a maintainer grantee focusing on the standard library.

He is a musicology student from Germany. When he is not playing the Cello or reading about Fanny Hensel, he applies his research skills to ensure that programs written in Rust run quickly and soundly on all platforms, no matter how quirky the operating system may be. He loves helping contributors write excellent code that they can be proud of; and considers it to be just as much fun as writing it himself.

Getting funding for my work is a dream come true. It will allow me to continue doing the thing I love instead of worrying about whether I should rather invest all that time in a money-earning job with much less positive impact on the world around me.

Jason Newcomb (@Jarcho)

Jason Newcomb (@Jarcho) is a maintainer grantee focusing on Clippy.

He is primarily working on fixing bugs and making it easier to develop and contribute to Clippy. He is also focusing on making the review process as smooth as possible.

Being funded allows me to work on something I care about and want to work on instead of what will get me paid. I'm looking forward to seeing how this will impact Clippy and the Rust project in general.

Conclusion

The contributors presented above will be funded for the next 12 months, though of course we hope that we will be able to extend their support going further, as this program is designed to be for long-term stable maintenance funding. We are very excited about them; each one of them has been with the Project for years, and we are very glad that we can support their maintenance work! All of them have already signed their contracts, so they are already being funded as we speak.

While there are many other Rust contributors who are doing awesome work, and who would also deserve to get proper funding for it, we think that this is a great start. We hope that the awesome work done by the funded maintainers will allow us to promote this program, so that we can fund even more Rust contributors!

We would like to once again sincerely thank everyone who made this possible, especially our sponsors. If you would like to help us fund more maintainers, consider donating to RFMF. You can also sponsor individual Rust contributors directly.

26 Aug 2026 12:00am GMT

Highlights

• Starting in Firefox 154, we've added a new capability for changing the default browser icon for Windows (Windows-only, for now, and not MSIX / Store installs) in about:settings#appearance!

• • Notice any bugs? File them here!
• Hubert Boma Manilla continued his work to handle CSS files in the Debugger (#2036376, #2037041). The feature can now be enabled from the Settings panel (#2051876)

• The Picture-in-Picture WebAPI is now available, starting with release version Firefox 153!
  • This does not replace the built-in Picture-in-Picture mechanism, and is in fact powered by it.

Friends of the Firefox team

Resolved bugs (excluding employees)

Volunteers that fixed more than one bug

• japandi

New contributors (🌟 = first patch)

• 🌟 Luiz Henrique Vieira helped remove some dead CSS from our tabbrowser code!

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

• As part of Project Nova work:
  • Added moz-promo cards to the about:addons extensions list recommendations footer and empty state, and updated the openAmoInTab helper to support a custom UTM content value - Bug 2043615 / Bug 2050880
  • Introduced the building blocks for the Nova Themes Picker in about:addons: a shared Firefox Themes list source of truth, a light/dark/device theme-mode switcher, a reusable theme-preview webcomponent, and Nova-styled theme previews - Bug 2051554 / Bug 2051559 / Bug 2051564 / Bug 2051573
  • Updated the Extensions panel empty state illustration and toolbar item icon for Project Nova - Bug 2030715
    • Thanks to Michael Hynson for driving this.
• Removed the legacy AddonManager Glean metrics used for mirroring legacy telemetry events, along with the corresponding legacy telemetry test checks - Bug 1923949 / Bug 1981822
  • Thanks to Chris H-C for collaborating with us on this.
• Fixed themes installed through the distribution mechanism not fetching their AMO metadata, which was resulting in distribution installed themes left without a preview image in about:addons - Bug 1917279
  • Thanks to Mike Kaply for the fix to the distribution themes metadata handling.
• Fixed amContentHandler to verify that a system triggeringPrincipal genuinely originated from the parent process, a regression introduced in Firefox 153 and fixed in Firefox 154 (with a beta 153 uplift requested) - Bug 2048964

WebExtensions Framework

• Fixed a startup performance regression by avoiding an NSS-initializing crypto.getRandomValues() call during extension startup, a regression introduced in Firefox 153 and fixed in Firefox 154 (with a beta 153 uplift requested) - Bug 2050882
• Enabled tier 3 TypeScript typecheck linting for the extensions framework code - Bug 2050124
• Implemented the WebExtensions manifest sandbox key, letting extensions keep using string-based code execution in unprivileged sandboxed extension documents - Bug 1685123
  • Thanks to Robin for the implementation of the manifest sandbox support.

WebExtension APIs

• Enabled storage.local database auto-reset on detected corrupted IndexedDB storage on all channels, starting in Firefox 154 - Bug 1992973
• Simplified registerTraceableChannel to make it synchronous again, removing the delay before blocking webRequest listeners can register a traceable channel - Bug 2044518
• Restored the contextualIdentities iconUrl container icons to their intrinsic 32×32 size, fixing a regression introduced earlier in the Firefox 154 cycle - Bug 2048599
  • Thanks to Andrea Marchesini for the fix to the contextualIdentities container icons.
• Fixed the MV2 userScripts API failing with an Xrays TypedArray access error due to a missing isWebExtensionContentScript flag - Bug 2054083
  • Thanks to erosman for the fix to the MV2 userScripts API.

DevTools

• Emilio Cobos Álvarez fixed the Inspector highlighters for SVG documents (#1850539)
• Andreas Farre made the Session History table header clickable to navigate the content page to given entry (#2018878)
• Sylvestre Ledru added Browser and Content filter to the Browser Toolbox Console and the Browser Console (#2048893)
• Adel Fatkhutdinov adapted the about:debugging Performance dialog for Nova (#2049348, #2053817)

• Nicolas Chevobbe about:debugging is now using moz-page-nav for its left sidebar (#2048544), thanks to Mark making it possible to disable collapsing that occurs on narrow screen (#2050907)
  • (not all items were migrated to moz-page-nav-button though, see #2050746 for remaining work)
• Alexandre Poirot made it possible to control the request and response body size limit from the Settings panel (#2040892)

• Alexandre Poirot added a notification when DevTools are open and the user navigate to a file:// document to promote Local Mode (#2044464), and added documentation for the feature (#2045987)

• Nicolas Chevobbe improved Inspector performance for elements with lots of Rules (reported bug was causing a crash on Penpot) (#2034445)
• Alexandre Poirot made the Ruler to remain visible after reloading the page (#1247553)
• Nicolas Chevobbe made the DevTools splitter keyboard accessible (#2015949)
• Nicolas Chevobbe fixed pretty printing in Debugger for sources using Regex with the v flag (#2053574)

WebDriver

• Devin Rousso enhanced the emulation.setLocaleOverride command to allow overriding the Accept-Language header for fetch and WebSocket requests in Workers.
• Nazım Can Altınova created the moz:profiler module (mozilla-only!), allowing clients to control the Firefox Profiler from WebDriver BiDi.
• Julian Descottes fixed a bug in geckodriver which prevented connecting to a non-rooted device.
• Alexandra Borovova implemented the "browsingContext.startScreencast" and "browsingContext.stopScreencast" commands, which will record a browsing context and save the result as a video file.
• Alexandra Borovova added download id to "browsingContext.downloadWillBegin" and "browsingContext.downloadEnd" events" to make it easier to identify which events belong to the same download.
• Henrik Skupin fixed a bug in WebDriver BiDi where same-document navigations or loading error pages in frames caused the browsingContext.navigate command to return prematurely.
• Henrik Skupin released geckodriver 0.37.1, including a fix for Android. See the release page for details.

Credential Management

• The new Rust-based storage mechanism for logins has been enabled by default, starting in Firefox 154. This component is an application-services component that can be shared with iOS and Android.

Migration Improvements

• We recently updated the Passwords import instructions for Safari to be up-to-date with macOS Sequoia and up.

New Tab Page

• That's a wrap for the World Cup! We're powering down the Sports widget today.
  • Some folks might see a survey about the Sports widget, to get feedback from the wild on whether or not it provided any user value (Telemetry points to "yes", but it's good to get qual data too)
  • We're replacing it with some new widgets. If you're in an English-speaking region, you will probably see it replaced with a Daily Crossword widget. Otherwise, it'll be replaced with a Picture of the Day widget.
• Sections have rolled out to 100% in France! We're now doing 10% Sections experiments in Spain, Italy, Austria, Switzerland and Belgium.
• Shout out to volunteer Sameeksha who added an accessible name to the Task list widget ••• button, adding an aria-label/accessible-name so NVDA/VoiceOver announce the control and keyboard navigation/activation works correctly on New Tab.
• Joel added WebNotifications to the newtab state, allowing New Tab widgets to observe and reflect WebNotification events (affects the notification-driven widget lifecycle and UI state updates).
• Reem Hamoui adjusted the New-Tab Widgets 3-dot menu layout to vertically center menu entries inside the hover-granted colorful stripe, removing visual misalignment and small hit-area offsets on touch and pointer inputs.
• Dre implemented the show less/show more transition animation for New Tab expand/collapse, smoothing layout shifts with a CSS transition to reduce perceived jank during widget list changes.
• Scott Downe fixed New Tab Page drag-and-drop so widgets no longer jump or keep moving during drags (2049472).
• Reem Hamoui rendered the Daily Crossword in a sandboxed iframe to isolate its scripts/CSP on the New Tab Page (2049489).
• Reem Hamoui added the Crossword option to about:preferences and wired the New Tab Page crossword widget into prefs (2050340), so users can enable or disable the crossword via the standard Preferences UI rather than about:config.
• Dre set up the Picture of the Day boilerplate, including prefs and basic New Tab UI components (2050969), which exposes a configurable PoD surface for users to opt into and customize.
• Dre added a dismiss control and persisted dismissal state to the daily photo UI (2050972), allowing users to remove the current picture from their New Tab and avoid immediate reappearance.
• Dre added a "set as wallpaper" action and hooked it into New Tab wallpaper storage/prefs (2050973), enabling users to promote a PoD image to their custom New Tab wallpaper persistently.
• Dre connected the Picture of the day widget to the Merino endpoint to set the background of the widget to the current picture (2050976). He also added telemetry for the Picture of the day widget on the New Tab Page to capture impressions and clicks for usage analysis (2050977).
• Nina Pypchenko [:nina-py] added a small size variant for the Focus Timer widget in Nova so the timer can render compactly in narrow/new tab layouts and reduce vertical space usage (2051179).
• Maxx Crawford created a DevTools 'controls' area on the New Tab Page to enable and configure the widget, exposing toggles and settings that let developers and experimenters flip the widget without changing prefs, which reduces friction when reproducing NTP widget behaviors during debugging and testing.
• Irene Ni switched the New Tab 'inferred personalization' checkbox to the platform moz-checkbox control, restoring native checkbox semantics (role/keyboard focus/visual state) so users toggling inferred personalization see consistent a11y behavior and platform rendering across Windows/macOS/Linux.
• Scott Downe fixed an intermittent visual reload/flicker of sponsored tiles and the Add Shortcut button when pinning/unpinning shortcuts, preventing momentary tile DOM reflows and layout thrash that caused perceived data loss or longer perceived latency during shortcut edits.
• Scott Downe ensured custom image URLs persist on manually added Top Site tiles after edit, so users' uploaded or external thumbnails no longer revert to the site's homepage preview when saving edits and their custom thumbnails are correctly cached and displayed.
• Dre introduced two variants of the World Cup widget survey message, changing the copy delivered in the widget to support an A/B/message-variant experiment and altering what users see when the World Cup widget surfaces survey prompts on their New Tab Page.
• Nina Pypchenko [:nina-py] introduced a default state for Medium and Large Stocks widget sizes on the New Tab Page to surface placeholder content and avoid blank tiles when the Stocks feed is empty or slow to load.
• Nina Pypchenko [:nina-py] added an error state to the Stocks widget on the New Tab Page to show an explicit failure UI when quote fetches or network requests fail, reducing user confusion.
• Alexandre Hanot migrated AdsFeed to fetch New Tab ads through the MozAdsClient, changing the ad retrieval path (AdsFeed -> MozAdsClient) which affects ads loading behavior and telemetry for users who see New Tab Page ads.
• Irene Ni fixed the New Tab add-pin flow that was creating extra rows when grouped pins was off by changing the insertion logic to append into the existing grid, which eliminates unexpected row creation and layout shifts for users managing many pins (2053251).
• Scott Downe updated New Tab section rendering to hide cards that don't fill their row by adjusting layout logic/CSS, removing orphaned placeholders and reducing blank space on narrow viewports or low-item sections for a cleaner grid appearance (2053264).
• Reem Hamoui added a context menu to the Crossword widget using a postMessage integration between the iframe and parent page, enabling right-click actions (copy/hint/theme) and making the embedded crossword more interactive and accessible to users who rely on context menus (2053311).
• Reem Hamoui added a visible "New" badge plus interaction handlers and state tracking to the Crossword widget on the New Tab Page to improve discoverability and make tapping/clicking behave reliably when launching puzzles (2053667).
• Irene Ni removed unused Add Shortcut OMC artifacts from the New Tab Page (2053843); this is a cleanup of obsolete assets/templates and has no direct runtime user impact.
• Maxx Crawford added author and license attribution to the Picture of the Day widget (2053933); this surfaces photographer credit and license metadata on the New Tab Page for users who want provenance information.
• Maxx Crawford applied UX refinements to the Picture of the Day widget (2054109); users will see improved layout, spacing, and touch targets in the POTD area for clearer interactions.
• Maxx Crawford added a pref and trainhopConfig gate to toggle the POTD "Set as wallpaper" feature (2054111); rollout and availability of the wallpaper action are now controllable via pref and remote trainhopConfig.
• Maxx Crawford added a dedicated trainhopConfig.widgetPictureOfTheDay payload for POTD feature config (bug 2054112) so the New Tab Page train-hop widget can be controlled server-side - this delivers image URLs, attribution and display params remotely which lets us enable/disable POTD per cohort without ship-side changes and reduces rollout latency for users who see the Picture‑of‑the‑Day widget.
• Irene Ni updated the Shortcuts Add/Edit dialog for Nova (bug 2054175) to improve the add/edit UX on the New Tab Shortcuts surface - the patch adjusts dialog layout and controls, tightens validation and accessibility labels, and reduces accidental duplicate/invalid shortcut creation so users editing shortcuts have a more reliable, faster flow.
• Maxx Crawford fixed the Daily crossword widget content overflowing and clipping past the bottom container boundary by adjusting the crossword widget's layout/CSS (container height calculations and overflow/overflow-anchor rules) on the New Tab Page, restoring full visibility of clues and controls across responsive breakpoints.
• Maxx Crawford fixed Related articles not opening on click by repairing the related-articles component's click handling and event delegation (anchor href/target behavior and JS listener) on the New Tab Page so article tiles now reliably open on click for users.
• Maxx Crawford added a "New" badge and interactions to the Picture of the Day widget, implementing an isNew flag, local state/localStorage handling, ARIA label updates and click behavior so users can immediately see and act on newly added images.
• Maxx Crawford updated the initial order of the Picture of the day widget by changing the PoD component's initial ordering/priority algorithm so first-run and default NTP surfaces surface curated/high-priority images first.
• Maxx Crawford migrated Crossword widget strings from Fluent back to inline markup to fix localization/formatting regressions in the crossword UI and ensure consistent rendering of labels and controls across locales.
• Irene Ni migrated the New Tab Widgets expand button to moz-button which standardizes the expand/collapse control on the New Tab Page widgets area, fixing inconsistent styling and keyboard/click handling so users now get consistent visuals and improved accessibility across platforms.
• Reem Hamoui added a dedicated trainhopConfig.widgetCrossword payload for Crossword feature config which isolates crossword rollout flags and content settings from other trainhop payloads, allowing targeted remote-config changes and safer A/B testing of the crossword widget without impacting unrelated New Tab features.
• Maxx Crawford fixed the Daily crossword widget being blank after closing and reopening the browser by ensuring widget state is correctly initialized/persisted on startup (New Tab Page widget lifecycle), so users now reliably see the daily puzzle after a restart instead of an empty frame.
• Reem Hamoui fixed Daily crossword completed puzzle and show clues are displayed in medium sized widget, restoring completed-puzzle rendering and clue visibility in the New Tab Page medium widget (widget template/CSS).
• Maxx Crawford updated Discovery Stream Admin buttons to use moz-button components, replacing custom controls with moz-button to standardize admin UI styling and focus behavior.
• Maxx Crawford added per-widget feature toggles and pref reset buttons to Discovery Stream Admin, enabling admins to toggle individual widgets and reset prefs without code deploys - changes here can alter what users see when toggled.
• Maxx Crawford migrated Discovery Stream Admin unit tests to jest, moving tests to Jest for faster developer feedback and more consistent test tooling.
• Maxx Crawford enforced Fail jest tests that emit console.error messages, making tests fail on console.error to catch regressions earlier and improve content quality before release.
• Kyle Jones populated MozAdsRequestOptions flags from adsBackendConfig in AdsFeed on the New Tab Page, changing ad request parameters that may alter which ads or personalization users see.
• Mike Conley removed the version 145 train-hop shim for the PrivacyFeed getTodayStats guard, simplifying guard logic in the New Tab Page with no direct user-visible change.

Search and Urlbar

Search

• Mandy fixed the "New" label incorrectly appearing for user-installed third party search engines that override application-provided engines (2053710).
• Standard8 fixed search engine telemetry notifications and private browsing search engine defaults (2053129, 1792669).

Suggest

• Adw added header_text support for AMP (AdMarketPlace) suggestions (2053626).

Nova

• Adw continued working on Nova with visual improvements across the address bar, search UI, icons, spacing, hover states, and accessibility (2019160, 2050821, 2053381, 2055109, 2053652, 2054784, 2055353, 2053927, 2053332, 2050366, 2053038).
• Daisuke improved the legacy search bar for Nova and fixed several Nova UI issues (2053934, 2050759, 2054304, 2046300, 2045993).

Address Bar

• Dharma improved Unified Search Button with search engine icons and a modernized result menu (2052741, 2039292).
• James continued work on adaptive autofill improvements (2013362, 2053891, 2050379).
• Dao and Mortiz continue multi-context address bar work (MCAB) (2054328, 2054207, 2054168, 2054110, 2054070, 2054066, 2051435, 2055474, 2054801, 2052555).

Places & Bookmarks

• Mak fixed several favicon and Places issues, including bookmark/history fixes (418144, 2055488, 2053482, 2052799, 2050378).
• Caleb improved Places performance by batching bookmark lookups and modernizing bookmark APIs (2042098, 2042099, 2042087, 2042097)

Storybook/Reusable Components/Acorn Design System

• Nova stuff
• Theme Picker for HNT, OMC and Profiles
• [mconley] There's a new vertical variant for visual picker. Thanks for the reviews, hjones!

25 Aug 2026 5:43pm GMT

Github Link

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

• Bug 1224099 - create 2fa user documentation
• Bug 1832783 - Wrong error message for exceeding file size
• Bug 2064475 - phab-bot leaves #release-managers review as non-blocking when a user manually adds it first
• Bug 2043229 - Display a "Show External" button beneath attachments list to display all attachments that would redirect such as Github and Phabricator
• Bug 2057679 - Update docker build process to pull in latest builds of vendered javascript libraries needed by the client
• Bug 2061264 - Remove CSP header from REST API responses
• Bug 2061831 - Add additional information to bugzilla comments in REST API if comment edited before
• Bug 2061441 - Migrate Classification REST resource to native Mojo API
• Bug 2064523 - [meta] tracking bug for BMO dependency upgrades
• Bug 2053504 - Need to add index to tracking_flags_values table for better performance from /bzapi/bug and REST search
• Bug 2055001 - Github Pull Requests: Look for etag value before fetching pull request data to cut down on rate limiting

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

24 Aug 2026 8:29pm GMT

It isn't often that new image formats land in browsers. In the early 2000s we had JPEG, GIF, and PNG. The 2010s gave us WebP, which was a modest step up from JPEG. But the 2020s have given us two new image formats that are a big step up from previous formats: AVIF and JPEG XL.

We shipped AVIF back in 2021, and today we posted our intent to ship JPEG XL. Chrome are also intending to ship, and given there's already a partial implementation in Safari, the format will be supported across browsers before the end of the year.

Shipping JPEG XL securely

We added experimental support for JPEG XL behind a flag back in 2021. But, at 100,000 lines of multithreaded C++, we were concerned about the attack surface this added to Firefox.

So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we'll ship it. That challenge was met; Google Research built jxl-rs, and it's the core of our JPEG XL support in Firefox.

We also pushed for high quality integration tests as part of an Interop 2026 investigation area, and they're coming along nicely.

Progressive rendering

Although Safari shipped JPEG XL in 2023, their implementation lacked some key features of JPEG XL - our favourite is progressive rendering, which is something we pushed for in the Rust implementation.

Progressive rendering means the image can render as it's downloading.

Although the full image is 135 kB, with only a few kB downloaded the user can determine the subject of the image. Try the above demo image in a browser that supports JPEG XL & progressive rendering, like Firefox Nightly - move the slider to see how the image displays with just a portion downloaded.

JPEG XL vs AVIF

Browsers will now have two modern image formats for developers to choose from. Which you choose depends on your use-case.

• JPEG XL: Excels at lossless imagery, progressive rendering, and further compressing JPEGs without quality loss.
• AVIF: Excels at web-quality photographic images, and images that have a mix of sharp edges and flat surfaces.

For example:

The image above is a 116 kB AVIF with a quality score (SSIMULACRA 2) of 62.8, meaning medium-high quality. To get the same quality, the JPEG XL image would be 134 kB.

At a SSIMULACRA 2 score of 80 (very high quality), the AVIF is 227 kB, and the JPEG XL is 264 kB.

But at lossless, the AVIF is 1.76 MB, and the JPEG XL is 1.45 MB. A lossless WebP is 1.55 MB.

Another example is a screenshot of the Interop 2025 scores:

At a SSIMULACRA 2 score of 78 (very high quality), the AVIF is 11.6 kB, and the JPEG XL is 23.8 kB.

But at lossless, the AVIF is 164 kB, and the JPEG XL is 92 kB. A lossless WebP is 96 kB.

Although AVIF tends to produce smaller files at web-quality than JPEG XL, AVIF only has basic progressive rendering support. So, for very large images, it may be worth taking the filesize hit with JPEG XL.

The key is to test with a representative set of images for your site, at a quality that works best for your users, and remember to optimise for high density.

The post Intent to Ship: JPEG XL appeared first on Mozilla Hacks - the Web developer blog.

24 Aug 2026 3:32pm GMT

While using guest wifi during travels, I was trying to fetch some changes from a github remote and my git fetch is over SSH which happens over port 22. Most (TCP?) ports are blocked on public or hotel wifi, so with some help¹ I learnt that Github serves SSH over 443 too.

A simple ssh config fixes this:

Host github.com
  HostName ssh.github.com
  Port 443

24 Aug 2026 12:00am GMT

While working on Writing the Docs: 2026 Edition, I experimented a bit with updating the Glean Dictionary to incorporate some of the ideas in the essay, in particular those around reference documentation.

As a sort of demonstration that documentation about an application can be treated as a data product in and of itself, I hacked up a quick ETL pipeline to dump the JSON output of the Glean Dictionary into a DuckDB database that can be queried standalone.

Since the Glean Dictionary is just a static Netlify site, the DuckDB database can simply be published alongside as a standard file. This allows you to do fun things from the DuckDB console like:

memory D ATTACH 'https://glean-dictionary-DuckDB.netlify.app/data/glean_dictionary.DuckDB' AS glean_dictionary (READ_ONLY);
memory D SELECT type, count(*) AS metrics
         FROM glean_dictionary.metrics
         GROUP BY type
         ORDER BY metrics DESC;
┌─────────────────────────────┬─────────┐
│            type             │ metrics │
│           varchar           │  int64  │
├─────────────────────────────┼─────────┤
│ counter                     │   20057 │
│ event                       │    7256 │
│ string                      │    3545 │
│ labeled_counter             │    3275 │
│ timing_distribution         │    2481 │
│ custom_distribution         │    2169 │
│ quantity                    │    1406 │
│ boolean                     │    1078 │
│ text                        │     588 │
│ labeled_timing_distribution │     569 │
│ datetime                    │     404 │
│ memory_distribution         │     389 │
│ object                      │     369 │
│ labeled_custom_distribution │     340 │
│ rate                        │     215 │
│ dual_labeled_counter        │     210 │
│ string_list                 │     204 │
│ uuid                        │     181 │
│ timespan                    │     149 │
│ labeled_boolean             │     118 │
│ labeled_string              │      84 │
│ labeled_memory_distribution │      66 │
│ labeled_quantity            │      42 │
│ url                         │      26 │
└─────────────────────────────┴─────────┘
  24 rows                     2 columns

From there, you could either build an interface like the Glean Dictionary itself (much easier to do from a database than the somewhat harebrained dataclass soup I originally came up with) or any number of other data products or analyses. Here's an example marimo notebook that tracks the metrics added to each product over time:

Open in Molab

As you can see, the number of metrics did a big jump in 2024 (I imagine they finally moved Firefox Desktop over to Glean) with slower and steadier growth since.

23 Aug 2026 9:11pm GMT

After nearly 4 years of active development, the next-generation trait solver is close to stabilization. We are enabling it by default on nightly to surface any remaining issues and plan to stabilize it in the next months. This is the largest single change to the Rust compiler since its initial release. It completely replaces how we prove where-clauses, normalize associated types, and much more. Please try out the latest nightly and open an issue if you encounter any bugs or regressions.

This is an internal component of the compiler. The main benefits of this rework will come in the future. The removal of the old implementation will unblock features such as Type Alias Impl Trait and Return Type Notation, allow us to add new implicit default trait bounds (e.g., Move and Forget), and enable us to fix the remaining type system unsoundnesses.

Even so, this already fixes a huge number of issues. As an underapproximation, we currently know of more than 200 issues on GitHub fixed by this change. This also has a significant impact on compile times; more on that later. When developing on nightly, you may accidentally rely on behavior only supported by the new trait solver.

This is an incredibly big change which results in a non-trivial amount of breakage. Most of these changes are intended improvements to type inference or the removal of undesirable behavior. We are tracking the known issues and breakage in a pinned GitHub issue.

What can I do?

Please update to the latest nightly version by using rustup update nightly and use it to test your existing projects and libraries.

Please tell us if you encounter any breakage, compile-time performance regression, or bad diagnostics. We have not yet spent too much time on error messages for the next-generation trait solver, so we would also appreciate you using this nightly for development to find poor diagnostics and other bugs in our error handling.

If you encounter any issue, take a quick look at the pinned GitHub issue to see if the affected crate is already listed, and if not, please open a new issue! To disable the next-generation trait solver on nightly, you can pass -Znext-solver=coherence to rustc, use RUSTFLAGS=-Znext-solver=coherence, or change your project's .cargo/config.toml configuration file:

[build]
rustflags = ["-Znext-solver=coherence"]

What exactly does this mean?

We will go into more detail about the next-generation trait solver, how we got here, and what it changes when fully stabilizing it. This is a quick summary of its main impact.

impl Trait handling

The way opaque types - return-position impl Trait (RPIT), but also the unstable Type Alias Impl Trait (TAIT) and Return Type Notation (RTN) - are handled in the type system has nearly completely changed. This fixes a lot of bugs and edge cases with them and should make their behavior a lot more consistent in general. This change is why the next-generation trait solver is necessary to stabilize TAIT and RTN.

The implementation change mostly does not matter for RPIT as we special-cased impl Trait from the method signature when type checking the method body. This means the only way to observe the old behavior is via recursive function calls. The following snippet errors with the existing implementation, but compiles with -Znext-solver enabled: godbolt

fn foo(b: bool) -> impl Sized {
    if b {
        // The old implementation errored here.
        foo(false) + 1
    } else {
        0
    }
}

Associated types in higher-ranked types

The most impactful change is way we handle associated types referencing bound variables, i.e., lifetimes from a for<'a> binder, for example, the type for<'a> fn(<T as Trait>::Assoc<'a>). While most users don't encounter such types directly, there are widely used crates which do. This change impacts existing code by removing incorrect type inference, such as in bevy and minijinja.

It also fixes a bunch of unnecessary errors like in the following example: godbolt

trait OtherTrait {
    type Assoc<'a>;
}
impl OtherTrait for u32 {
    type Assoc<'a> = &'a u32;
}


trait Trait {}
impl<T: OtherTrait> Trait for (T, for<'a> fn(<T as OtherTrait>::Assoc<'a>)) {}


fn impls<T: Trait>() {}

fn main() {
    // The old implementation failed to prove
    // the where-bound of `impls`.
    impls::<(u32, for<'a> fn(&'a u32))>();
}

Compile-time performance

_{co-authored with jana :3}

We've spent a lot of time on the compile-time performance of the next-generation trait solver. There have been many cases where it performed quadratically or even exponentially slower than the old solver.

Especially the last few weeks were mainly spent on improving performance. This work was shared by many people, with major contributions by Nick Nethercote, jana, Rémy Rakic, and mira.

As part of this effort, Rémy Rakic compared the performance of both implementations for the top 20,000 crates on crates.io. Below you is a visualization of the performance changes over the last two months.

On the left and the right, the major outliers can be found. Note that the sample of crates here is biased towards such crates, because those are more interesting to us. Nearly all crates we tested in the top 20k had effectively the same performance with both implementations.

This graph shows that we've mainly focused our efforts on the negative outliers and made significant progress there. While many of the crates that previously took more than twice as long to compile with the new solver are still slightly slower, our work has made a few of them actually compile faster than with the old solver.

We will continue to improve its performance over the coming months, and there are still a lot of optimization opportunities compared to the existing implementation. My expectation is that, in the long term, nearly all crates will benefit from the next-generation trait solver. I am especially excited about the huge performance benefits for some trait-heavy crates.

As an example, a Chess implementation in Rust's type system hangs with the old implementation while taking a minute with the new one. There are also more practical crates with huge performance benefits, e.g., the datafusion crate compiles more than 8x faster now. For more details about the recent performance work, see this blog post by jana.

Again, thank you for testing with the latest nightly and opening a GitHub issue if you encounter any issues! We're excited to fully stabilize the next-generation trait solver soon.

21 Aug 2026 12:00am GMT

There's a popular post going around about Alibaba doing WebAudio fingerprinting and in the process, mucking around with the author's Bluetooth headphones. Here's the tl;dr: browser fingerprinting is a far-too-pervasive method of tracking users across the web, but at least for WebAudio specifically, it's not very effective. Firefox has largely eliminated this fingerprinting vector.

I work on Firefox. Chrome, Brave, Safari probably have defenses against this. I'm pretty sure Chrome's WebAudio code was made approximately constant (like ours) many years ago. It probably still leaks CPU architecture though.

I don't fully agree with the adage "given enough eyeballs, all bugs are shallow" - I think a more true one might be "given enough victims, your attack code is going to change something that makes someone notice". And that's exactly what happened with... sorry, wrong link. That's exactly what happened with Alibaba's fingerprinting code.

If you want to test Alibaba's WebAudio fingerprint, I had claude extract it into a standalone page. My value is sha256:9a388c0dd04cfdc54314f9d961c7e2d247b972067e28d1cea76bd6060cf1392e, and the other value we saw in an internal survey was sha256:16d3191880ce01f726015ec6a1f9a072a81ebd04bf489098d4685d1d1c0b2711.

WebAudio Fingerprinting in Firefox

We made the WebAudio constant in Firefox 118 as part of our initial round of Fingerprinting Protection features. This eliminated most of the differences.

99.24% of users belong to one of three values, and .76% of users had that data collection point fail (a value of zero.) So virtually all users have one of these three values but why are there three values??? Why isn't there one?? Well this is why we collected this telemetry - to ensure we really had made things constant the way we thought we had, and if we hadn't, figure out why and fix it.

The improvements we put into 118 eliminated a lot of differences and I wish I had a graph I could show you of what it looked like before (but I don't.) But what about these remaining three buckets? We were able to figure out that the differences between these are CPU-level differences, which is not surprising given the math operations of audio processing. Specifically one value comes from (all) x86 CPUs and x64 CPUs that lack fused multiply-add instructions, one value from x64 with FMA, and one value from CPUs with the NEON instruction set (ARM).

We followed up on that effort to collapse these buckets into one another. Bug 2036977 collapses the x64 (with FMA3) into the x86/x64 (without FMA3) bucket. Bug 2040494 is on file to collapse the remaining bucket into the NEON bucket but I haven't worked on it in a while because it's just not as high a priority as larger improvements we can make like Sanitizing the WebGL Renderer and Vendor (something I talked a bit about a few months ago).

Because if you've read this far you surely care about the rest of the graph also. There is also the long-tail of 23 other values belonging to 48 other users. This is very unfortunate, as it makes these users completely unique, but it is also not terribly unusual - computers are weird and these results could have been caused by bad RAM, a CPU bug, or possibly some crazy architecture (LoongArch??).

But at the end of the day, WebAudio fingerprinting is nearly useless. I don't expect browser fingerprinting to disappear from websites entirely (unless some regulatory action occurs, fingers crossed) - it's still going to be effective against a majority of users on the web, but at least for privacy focused browsers, it should be wildly less effective.

20 Aug 2026 7:56pm GMT

Open or closed AI isn't a fringe question anymore; it's a live policy debate, with real consequences for who gets to build, audit, and compete in the AI ecosystem. But as that debate plays out in Washington, Brussels, and beyond, the harder questions are still very much up for discussion. What does meaningful openness actually require? Where should the guardrails sit? And who gets a say in setting them?

That's exactly the gap a group of us set out to close two years ago.

Back in 2024, Mozilla and the Columbia Institute of Global Politics brought together more than 40 researchers, builders, and policy experts for the Columbia Convening on Openness and AI. The goal was simple to state, but hard to do: figure out what "open" actually means once you're talking about foundational models rather than traditional software, and build a shared vocabulary that researchers, developers, policymakers, and civil society could all work from.

The convening was the start of a years-long effort to turn a room full of perspectives on openness into something durable and useful for developers, builders, and policymakers alike. Recently, that effort reached a new milestone: Communications of the ACM published "Unpacking Open Source AI: Toward a Framework for Openness in Foundation Models," which I co-authored alongside a host of other allies spanning academia, industry, and civil society.

The paper outlines a framework that does something the open source AI debate badly needs. It stops treating "open" as a single switch you flip on or off. Instead, it breaks the AI stack down into its component parts - data, code, model weights, documentation, and more - and looks at how openness at each layer shapes who actually gets to inspect, use, and build on a system. That kind of specificity matters. A lot of the current policy debate treats open source AI as a monolith, when in reality the details of what gets shared (and how) are what determine whether openness delivers on its promise of safety, competition, and accountability.

A few of the framework's ideas are worth pulling out. First, it treats openness as a gradient rather than a binary. A system can be open on weights while remaining closed on training data, or open on code while offering little documentation on how it was evaluated. The framework offers language to describe that mix precisely, instead of lumping it under one vague label. Second, it argues that safety can't be assessed at the model level alone: what matters just as much is the surrounding system - the deployment environment, the safeguards, the moderation layers, and governance structures. That's because a model's real-world risk profile is shaped by all of it together, not by the weights in isolation. Critically, the framework deliberately stops short of prescribing one "correct" level of openness for every system. Instead, it gives developers, researchers, and regulators a common vocabulary to make and evaluate those tradeoffs on a case-by-case basis.

It's worth pausing on who's behind this work. Scroll through the author list, and you'll find a genuine cross-section of the individuals and organizations contributing to moving the development of open systems forward. It's a collection of people who've spent years arguing, in good faith and often across real disagreements, that open approaches can be a foundation for safer, more democratic, more accountable AI. That's the same spirit that drove the original convening, and it's what makes this paper a genuinely important milestone for our mission to make AI systems accessible to the many, rather than the few.

You can read the full paper here.

The post A New Framework for Open Source AI appeared first on The Mozilla Blog.

20 Aug 2026 3:57pm GMT