Planet Mozilla

Firefox Tooling Announcements: Happy BMO Push Day! (20260916.1)

dkl1 — 2026-09-16T18:03:55+00:00

Github Link

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

Bug 2069143 - When retrieving comments for a bug(s) via REST API, remove comments that would be collapsed in the web UI unless explicitly asking for them
Bug 2070247 - Support limiting who can needinfo the Hackbot account
Bug 2061445 - Migrate Bugzilla (system info) REST resource to native Mojo API
Bug 1877201 - Post to bug/{bugid}/comment returns wrong comment_id
Bug 2072224 - Update REST API authentication documentation to reflect per-resource migration to native Mojo auth
Bug 2060932 - Support GitHub-style <details>/<summary> collapsible sections in comments
Bug 2072689 - Buglist link on My Dashboard is broken

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

Firefox Tooling Announcements: MozPhab 2.19.1 Released

sheehan — 2026-09-16T14:28:36+00:00

Bugs resolved in Moz-Phab 2.19.1:

bug 2071003 moz-phab patch --apply-to head moves to a detached HEAD

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

1 post - 1 participant

Read full topic

The Mozilla Blog: Mozilla and Mistral: Partnering to expand AI competition and preserve user choice

Mozilla — 2026-09-16T08:00:00+00:00

The AI race is shifting. Again. Practically overnight, competition has expanded from “which AI model is best?” to a new high-stakes battle over which models people can access, through which products, and whether people have meaningful choice about AI at all.

In response, Mozilla and Mistral today announced a partnership built on a shared idea: a new, open-source AI model alternative to Big Tech-default browser ecosystems. The intent: a model deliberately designed to keep the web open to technological diversity, competition, and choice.

And we’re putting this idea into practice in Firefox.

Mistral Small 4 is coming to Firefox Smart Window beta (learn more about Firefox Smart Window here), becoming a new AI model for Smart Window users in the US and Canada, while expanding Smart Window beta access and French-language support to Firefox users in France. Across all markets where Smart Window beta is available, Firefox users can still choose from a multitude of other AI models.

“AI is becoming part of how people experience the web every day. We want to make sure that doesn’t mean people are chained to one company’s self-serving pipeline. With the browser sitting at the heart of the web and online experience, it should be a place where different AI providers can compete and open source has a seat at the table.

This isn’t just a product partnership. A browser shouldn’t be a one-way funnel. It should preserve what made the internet powerful to begin with: the freedom to explore, discover different ideas and tech, and decide for ourselves where to go next,” said Anthony Enzor-DeMeo, CEO of Mozilla Corporation.

Choice and competition are worth protecting

As AI integration becomes increasingly concentrated, we are in jeopardy of a handful of closed-model companies controlling the browser, the search engine, the AI model, and the surrounding services that connect them. Mozilla and Mistral are betting that independent and interoperable models can offer an alternative to global tech monopolies controlling the next digital era.

“This partnership represents two open source advocates working together to bring Mistral’s scientific innovations to Mozilla’s consumers around the world. Together, we are bringing privacy, control, and choice to AI-powered web browsing,” said Arthur Mensch, Co-founder and CEO of Mistral.

Meaningful choice isn’t confined to personal preference for one AI model over another. Web products need to be able to work with different AI providers, and people deserve the option of switching without being locked into a single company’s ecosystem. When a tech layer as far-reaching and influential as AI is controlled by a small handful of players, it risks creating closed systems and closed doors, making it harder for new ideas and better technologies to grow, reach users, and compete on merits.

Mozilla and Mistral aim to keep that door open. The combination of an independent browser with a frontier European AI company gives people and institutions greater access to useful, responsible AI, the opposite of locking them into one company’s singular technology ecosystem.

Selecting Mistral, and expanding to France

Mozilla selected Mistral Small 4 after evaluating its performance for Smart Window Beta, including multilingual performance, an important part of the fit. The companies approached multilingual and multicultural tuning as a core model feature, rather than simply adapting an English-first experience for a new market.

For Firefox users, Mistral access starts with Smart Window Beta, a browsing experience designed to turn AI into a useful assistant for the things we do online: making sense of complex search trails, finding something valuable you clicked away from, presenting data sources, and generally picking up where day-to-day internet use got left off.

France is the first new market for Smart Window with official French-language support. Mozilla is planning additional European expansion later this year.

A different kind of AI competition

Our Mistral partnership puts an ambitious new AI model approach into practice: a multilingual, globally competitive European AI company reaching people through an independent browser, leveraging openness to create more room for new technologies to compete and succeed. Mistral can reach Firefox users without owning the browser, and Mozilla can integrate and recommend Mistral without removing user choice.

It is a natural extension of the principles that have shaped Firefox and the open web, and the kind of AI ecosystem we intend to continue building.

The post Mozilla and Mistral: Partnering to expand AI competition and preserve user choice appeared first on The Mozilla Blog.

Jonathan Almeida: Checkout a Github pull request from one-off contributions

Jonathan Almeida — 2026-09-16T05:38:50+00:00

EDIT: Updated to reference gh correctly. Thanks flod!

Sometimes on Github, I need to fetch a patch from a fork I don't typically see everyday so I can try it out locally. I use the line at the top of the patch which has a copy button next to it because it's convenient.

The common steps for this are:

Click the contributor's branch and go to their github fork repository.
Copy the repository link.
Add a new git remote with an alias (typically their username).
git fetch <alias>
git checkout <alias>/<branch>

Here is a one-liner for it that you can add to your gitconfig:

[alias]
  co = "!f() { PNAME=$(basename `git rev-parse --show-toplevel`); OWNER=$(echo $1 | cut -d':' -f1); BRANCH=$(echo $1 | cut -d':' -f2); git fetch git@github.com:$OWNER/$PNAME.git $BRANCH; git checkout FETCH_HEAD; }; f"

You might ask, why do all of this when the github gh CLI does this for you? While it does simplify some tasks, I wanted a solution that was independant to a specific git host. The git@github.com remote that is used in the alias can be changed or made configurable if desired. This is something that I wouldn't be able to do with platform-dependant gh.

The fetch also works well with jj too because the fetch and checkout remain headless.

Formatted and commented, it looks less intimidating:

f() {
  # Get the repository name from your checkout (assuming it is the
  # original directory name as the remote).
  PNAME=$(basename `git rev-parse --show-toplevel`);

  # Parse out the fork's owner.
  # Example: `<owner>:<branch>`
  OWNER=$(echo $1 | cut -d':' -f1);

  # Parse out the branch name.
  # Example: `<owner>:<branch>`
  BRANCH=$(echo $1 | cut -d':' -f2);

  # Do a fetch of that particular branch using the extracted
  # information from above.
  # This assumes the remote is hosted on github.
  git fetch git@github.com:$OWNER/$PNAME.git $BRANCH;

  # Checkout using the alias `FETCH_HEAD` which git provides.
  git checkout FETCH_HEAD;
};

# Execute the function!
# It's easier to build a function that holds variables and execute
# rather than in-line it.
f

Comments

With an account on the Fediverse or Mastodon, you can respond to this post. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. Known non-private replies are displayed below.

Learn how this was implemented from the original source here.

The Servo Blog: Your Donations at Work: One Year of Sponsored Servo Development

2026-09-15T00:00:00+00:00

Last September, the Servo project announced that long-time maintainer Josh Bowman-Matthews (@jdm) would work part-time on improving the Servo contributor experience, entirely funded by the monthly donations on OpenCollective and GitHub. In his own words, here is a look back over the past year!

First of all, I am enormously grateful to everyone who financially supports Servo, as those donations have enabled me to devote significant time to a project that I care a lot about. Some highlights from that funded work that I’m proud of:

I nominated 8 new maintainers
I reviewed 1150 pull requests
I filed 114 issues targeted at newer contributors (92% of them have been fixed)
I wrote new documentation about borrow hazards, experimental features, the AI policy, finding things to do, and fixing stable and intermittent test failures

On top of that, I spent time diagnosing unexpected failures in others’ PRs and fixed numerous intermittent test failures that made merging PRs more difficult for everyone.

A few pieces of work from this period that stand out to me:

supporting a large scale rewrite of Servo’s JS engine integration to address intermittent panics related to garbage collection—I reviewed lots of pull requests, but also filed many issues that enabled the work addressing the panics to be spread across many other contributors
getting tagged in to help understand test failures, uncovering our broken window.open behaviour, and eventually making a lot of flaky tests more stable
supporting another contributor’s grant proposal to work on Servo that was approved!

This role I’ve carved out means a lot to me—I’ve found a healthy balance that allows me to spend time with my family as well as make meaningful contributions to Servo, and I get to spend a lot of time looking for ways to make the project more accessible for others. A big thank you to everybody supporting the project and my work; each individual monthly donation makes a big difference! I’m excited to see what’s possible in the coming year.

Firefox Nightly: The Need for Speed Controls – These Weeks in Firefox: Issue 208

Katherine Patenio — 2026-09-11T17:32:05+00:00

Highlights

Firefox 154 went out today! Lots of goodies in there for our users, including support for NVIDIA GeForce NOW
The new 2 week release cycle is now in effect. This means that Firefox 155 is slated to hit release on September 1st!
- You can follow along at https://whattrainisitnow.com/
As part of the Nova redesign, a “Use Linux system theme” checkbox is being shown on Linux builds for the about:addons theme picker, which will make Firefox’s Nova UI use the colours of the system theme.
Thanks to Simon Rosen for adding a new playback speed control to the PiP player. The feature can be enabled by flipping the pref media.videocontrols.picture-in-picture.playback-speed.enabled.

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

Benoit
Chris Vander Linden
Fede
japandi
Lukáš Lipinský
Nirmal Advani
Ruhollah Majdoddin
Sameem [:sameembaba]
Sebastian Zartner [:sebo]
Zyphrenn

New contributors (🌟 = first patch)

Aditi: Increase the maximum number of PDF.js preferences
Fede:
Giulio B: frameId is wrong in webRequest events triggered via importScripts
🌟 Gopalarathnam Venkatesan: Fix incorrect ‘this’ in the Sync add-on install error handler
🌟 Kevin Gosse: nsDataObj::QueryGetData in Firefox returns E_FAIL for formats it doesn’t carry, instead of DV_E_FORMATETC per the COM contract
🌟 mikey gough: Remove three unused devtools.debugger.file-search-* preferences
🌟 Nathan Leuz: Remove unused legacy preference browser.translation.neverForLanguages
🌟 Priyanshu[:0xanshu]: “Forget About This Site” dialog is cut off
🌟 K: Disable breakpoints shortcut
🌟 Shawn Zivontsis: Reorder moz_origins composite unique index to UNIQUE(host, prefix)
🌟 Simon Rosen: Suggestion: Add speed button for Youtube in picture-in-picture(PiP) modals
tanvi.manku: unnecessary scrollbars in edit dialogs for payments and addresses
Zyphrenn:
- browser.tabs.groups.enabled should disable drag-n-drop
- “Tab group suggestions” AI control setting still visible when browser.tabs.groups.enabled is false

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

As part of Nova about:addons work:
- Replaced the “more themes” button in the themes list view footer with a promo element when Nova is enabled – Bug 2057200
- Removed the testing XPI base url pref from ThemesList.sys.mjs – Bug 2053220
- Fixed a mismatch between the popup panel border radius applied by Nova and the border radius applied to the document.body of the WebExtensions popup page loaded into it – Bug 2057844
- Moved new strings added as part of the about:addons Nova restyling out of the locales preview – Bug 2052034
As part of legacy telemetry cleanups for the Add-ons related telemetry, migrated addons-search-detection telemetry off the legacy telemetry mirroring path, now collected only through Glean – Bug 2055606

WebExtensions Framework

Fixed a series of intermittent and CI-reliability test failures across the WebExtensions browser-chrome test suite – Bug 1575369 / Bug 1697626 / Bug 1699341 / Bug 1974953 / Bug 2015004 / Bug 2030542 / Bug 2062186 / Bug 2062187 / Bug 2062189 / Bug 2062191 / Bug 2062193
- Thanks to Florian Quèze for applying his work on an LLM-based system for investigating intermittent tests to investigating and fixing intermittents and perma failures across the WebExtensions test suite.

DevTools

Ruhollah Majdoddin fixed issues in the Storage panel to make sure we’re only showing relevant cookies (and their values) for the debugged tab (#1856645, #2060029, #2061166) and also did some cleanup in this area (#2061348)
sevenwithawp added a keyboard shortcut (Ctrl+Alt+B, Cmd+Alt+B on Mac) to disable/enable breakpoints (#1642578)
Hubert Boma Manilla (:bomsy) continues his work to display stylesheets in the Debugger (#2051029, #2051264)
- Preference: devtools.debugger.features.stylesheets-in-debugger
Nicolas Chevobbe [:nchevobbe] added support for ::picker() rules in pseudo element section (#2042839)
- Used by customizable select (MDN)
- Preference: dom.select.customizable_select.enabled

Nicolas Chevobbe [:nchevobbe] made CSS explainers work for substitution functions (var(), attr() and env()) (#2041622)
- Preference: devtools.inspector.css-explainers

Julian Descottes [:jdescottes] fixed an accessibility bug in about:debugging where error message where not announced (#2056332)

WebDriver

Sameem added the cleanup logic for subscriptions when a browsing context is destroyed.
Nirmal Advani updated the Actions API to fire the dblclick event when performing a double-click while holding down the Ctrl key on non-macOS platforms.
Khalid AlHaddad updated the webdriver bidi moz:debugging module to stop using enterNestedEventLoop which can avoid conflicts with the regular DevTools’ debugger.
Alexandra Borovova fixed the “browsingContext.reload” command to not fail for frames.

New Tab Page

Big ticket items:
- Did a trainhop last week to help with the remote layouts effort
- Doing another trainhop this week to make some spacing optimizations, deploying tomorrow if all goes well
- We will be experimenting with some more layout variations over the next few months
  - Example:

We’ve migrated a bunch of our unit tests to Jest/RTL from the deprecated Mocha / Karma framework we’ve historically used.
Joel added a WebNotifications badge to Top Sites on the New Tab Page which surfaces per-origin unread web-notification state directly on TopSites tiles by rendering a compact badge in the activity-stream/TopSites component—users can now glance at NTP tiles to see which sites have pending web notifications without changing navigation or site state (affects desktop and mobile NTP Top Sites UI). This is something we plan on experimenting with later this year.
Similarly, Joel added a TopSites hover card with notifications which expands the to show per-site notification items and actions on hover or long-press, enabling users to read and dismiss notifications from the NTP itself rather than opening each site.
Hanna Alemu fixed the focus outline for the “Learn how we protect your data” link in NEWTAB_PERSONALIZATION_MESSAGE, replacing the blue non-rounded ring with the standard rounded focus style via CSS so keyboard and assistive users get a consistent, discoverable focus indicator.
Maxx Crawford added logic to show different tip messages throughout the day/week on the New Tab Page in the upcoming privacy widget, implementing time-of-day/day-of-week selection in the tip renderer so users receive context-varying tips rather than a static message, which affects the tip surface and supports time-targeted experiments.
Irene Ni removed the New Tab daily briefing slice from the New Tab Page, so users will no longer see the daily-briefing card on new tabs and related New Tab slice prefs/registrations were cleaned up.
Jack Brown migrated the New Tab ContextMenu/LinkMenu implementation to the panel-list component, so right-click menus and link context behavior on the New Tab now use panel-list rendering (affects keyboard navigation, theming, and menu perf).
Irene Ni removed a root-level <hr> selector from the Weather forecast widget SCSS that leaked global divider styles into the New Tab Page layout, restoring correct dividers and preventing spacing/layout regressions on about:newtab.
Irene Ni enabled the remote-settings-driven sections layout in Nightly, flipping the remote-settings/sections layout so Nightly users receive Discovery Stream section composition from Remote Settings.
Irene Ni automated the New Tab Page locales update for train-hop to ensure locale bundles are refreshed on train deploys so users see corrected translations and no longer encounter stale labels after a hop.
Reem Hamoui fixed the Crossword widget double-counting and removed broad “interaction” user_actions so telemetry and UX-triggered actions reflect a single user event and analytics driven by user_action are no longer inflated.
Dre fixed the “Show more widgets” visibility by adjusting the widget container overflow/visibility logic so the Show more control is reliably revealed on constrained viewports, restoring widget discoverability.
Joel fixed newtab.closed and newtab.sections_impression firing unexpectedly on the New Tab Page by gating event emission on section visibility and tab lifecycle, which stops spurious impression and close telemetry pings and improves the accuracy of NTP impression/close counts for affected users.
Joel added a topsite display customization event to newtab ping, updating the New Tab ping schema so user topsite layout and appearance changes are emitted as topsite.display_customization events, enabling reliable capture of pin/remove/resize/customization actions in Telemetry.
Nina Pypchenko [:nina-py] added widgets.stocks.interaction and flip it on user actions so explicit click/tap interactions with the Stocks widget now generate widgets.stocks.interaction events, improving engagement capture for the Stocks surface.
Nina Pypchenko [:nina-py] migrated the Stocks widget telemetry to the shared useWidgetTelemetry hook, standardizing how the Stocks widget emits metrics and ping fields to match other widgets, which reduces missing/duplicate events and makes per-widget telemetry consistent across platforms.
Irene Ni created an initial JSON dump of Remote Settings sections layouts for cold startup to prepopulate New Tab Page sections on first launch and reduce layout flash or missing tiles.
Nina Pypchenko [:nina-py] added a persistent “New” badge to the Stocks widget until first user interaction, which improves discoverability of the Stocks card and is cleared on the user’s first click/tap.
Maxx Crawford implemented a side-by-side content layout variant for the New Tab Page feed, which introduces a new responsive layout option that changes feed column behavior and visual density on wider viewports.
Scott Downe added support for five-column content feed layouts, which enables denser content grids for large displays by updating grid logic and responsive breakpoints and affects NTP rendering on wide screens.
Dre added a “Celebrations” UI state to the Privacy Widget, which surfaces milestone/celebratory visuals and transient animations in the Privacy Widget when triggers are satisfied.
Irene Ni updated the New Tab topsite context menu button to respect prefers-reduced-motion via CSS/media-query changes, so users with reduce-motion enabled no longer see the button’s motion/animation.
Scott Downe expanded New Tab’s list of region and locales for content support, updating the New Tab content selection config and region→locale mappings so more users in newly-added locales receive localized tiles and recommendations on the New Tab Page.
Irene Ni fixed the New Shortcut / Edit Shortcut prompt background being transparent with the Newtab addon installed, restoring CSS/background opacity for the edit UI so shortcut editing is readable across themes and addon combinations.
Maxx Crawford added a dedicated trainhopConfig.widgetPrivacy payload for the Privacy widget feature, introducing a per-trainhop config payload in Discovery Stream so Privacy widget rollouts and toggles can be controlled without code deploys.
Maxx Crawford added a layout management panel in Discovery Stream Admin, giving editors an admin UI to modify New Tab/stream layouts (reduces manual config edits and speeds layout experiments).
Dre reduced the Privacy Widget celebration sparkles on the New Tab Page in Privacy Widget Celebration: Reduce the Sparkles by lowering particle counts and throttling animation cadence in the widget’s CSS/JS animation code, reducing visual noise and a small amount of GPU/animation work for users during the celebration without changing privacy settings.
Maxx Crawford restored the “Change size” context menu item for the side-by-side experimental New Tab layout so users with the side-by-side exp layout enabled regain the resize control in widget context menus.
Maxx Crawford stopped the sports widget from rendering regardless of the pref so unwanted sports content no longer appears on New Tab when the pref should prevent it.

Picture-in-Picture

Thanks to Lukáš Lipinský for adding live event caption support for ceskatelevize.cz!
Thanks to Mike Conley for fixing play / pause issues with the PiP player on Udemy.

Search and Urlbar

Nova: continued work on the Nova redesign, focusing on CSS fixes, tab group and container styling, and tab/address bar polish. Efforts are underway to ensure the UI integrates correctly with platform themes and high-contrast modes.
IPC Urlbar / Multi-Context Address Bar (MCAB) on New Tab: Significant progress has been made on the IPC Urlbar implementation. The CI variant is now live and upgraded to Tier 2, allowing for better bug detection. Currently focused on making content modules content-process-safe and preparing for new tab search bar integration. Here’s moz-urlbar rendering something on about:newtab for the first time:

Post-MVP work continues on refining the new search bar that can be added to the toolbar.
- Let Tab land on the search input rather than the search button, behind a Nightly-only pref
Google address bar messaging experiment relaunched.
Search & Suggest Telemetry: Development is ongoing for search term telemetry, specifically regarding fetching results from Merino for online suggestions. Also preparing to retire legacy telemetry for certain search service metrics.

Mozilla Data YouTube Channel: Data Club: Jan-Erik Rediger - Little Bobby Tables - from metrics.yaml to data-filled columns

Mozilla Data — 2026-09-11T11:25:48+00:00

A short story about Little Bobby Tables and how we know what data to fill in where.

Mozilla Data YouTube Channel: Last Lecture: Writing the Data Docs

Mozilla Data — 2026-09-11T10:42:15+00:00

Will Lachance gives a last lecture on writing data documentation at Mozilla.

Mozilla Data YouTube Channel: Data Club Talk: Jan-Erik Rediger - The Glean UniFFI migration and how no one noticed

Mozilla Data — 2026-09-11T06:45:45+00:00

Given at the Mozilla Data Club on August 12th, 2022.

Mozilla Data YouTube Channel: Monitoring Sensitive Data: How do we monitor data we don't store?

Mozilla Data — 2026-09-11T00:19:06+00:00

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

Jonathan Almeida: Perf wins from relocating MOZ_OBJDIR have a dev experience cost

Jonathan Almeida — 2026-09-11T00:00:00+00:00

This is the opposite of what I wanted to write about: relocating your MOZ_OBJDIR outside of your source directory will make your IDE faster.

In mozilla-central (the firefox monorepo), a default object files directory is created within the same source directory. This is equivalent to the build/ directory you would typically see in other projects.

While this is typically fine, I've found that Android Studio indexes many of these files and that can be slow when you're not working across all the layers in Gecko and Firefox. I ended up with these build directories that grew over time:

Directory	Last touched	Size	Files
obj-aarch64-unknown-linux-android	2025-11-04	29 G	113,116
objdir-desktop	2025-11-04	19 G	41,010
objdir-frontend	2026-09-09	6.3 G	66,930
obj-aarch64-apple-darwin24.5.0	2025-06-16	4 K	1

That's a lot to index! I figured a way around this problem is to move the OBJDIRs out of the source directory and into something like ~/.mozbuild:

mk_add_options MOZ_OBJDIR="$HOME/.mozbuild/objdir-frontend"

While this does speed up IDE indexing, it's at the cost of developer experience, because now our generated code (e.g. FxNimbus) shows up as red symbols everywhere.

[insert sad trombone sound clip]

I'm uncertain if trimming what we index in these OBJDIRs is worth a large enough performance win, so for now I'll ensure I clean-up my stale copies which I'm not actively using.

About:Community: Game on: Play, share, and help shape Mozilla

Rizki Kelimutu — 2026-09-10T15:05:52+00:00

P.S. Apologies for the delay in publishing this edition on the community blog. The original newsletter was sent to subscribers on August 27.

Firefox was leveling up in August! GeForce NOW arrived on Firefox for Windows, JPEG XL support was on the way, and the Firefox + NVIDIA teams joined forces for a Reddit AMA. We also invited SUMO and Mozilla Connect contributors to share their experiences through the Mozilla Contributor Survey, which has since closed (thank you to everyone who took the time to participate!).

Read on to catch up on what you may have missed and see what the community was up to!

GeForce NOW is now available on Firefox for Windows

Firefox has joined NVIDIA GeForce NOW’s supported browser lineup, making it possible to stream more than 2,000 PC games directly from Firefox on Windows. There are no downloads, installs, or hardware upgrades required! Just a Windows PC, a GeForce NOW account, and your existing game library.

Learn more

Share your voice in the Mozilla Contributor Survey 2026

We’re gathering feedback from SUMO and Mozilla Connect contributors to help shape the future of Mozilla’s contributor community. The 2026 Contributor Survey explores what motivates you to contribute, what matters most throughout your contributor journey, and how we can improve areas such as onboarding, recognition, and the upcoming Mozilla Connect migration to SUMO. The survey takes about 10 minutes to complete and is now open until September 1, 2026, end of day UTC.

Complete the survey

JPEG XL is coming to Firefox

Firefox plans to ship support for JPEG XL, a modern image format designed to deliver high-quality images more efficiently. With progressive rendering, images can start appearing before they have fully downloaded so it helps make pages feel faster, especially on slower connections.

Learn more

From the Reddit Community

The Firefox and NVIDIA GeForce NOW teams are hosting a Reddit AMA on September 2 to celebrate GeForce NOW support on Firefox for Windows. Bring your questions about the integration, share your cloud-gaming setup, and let the teams know what else you’d love Firefox to support for online play.

Join the AMA

P.S.

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

Mozilla Data YouTube Channel: Glean Dictionary Looker Demo

Mozilla Data — 2026-09-10T06:48:16+00:00

A quick demonstration of the Glean Dictionary's new integration with Mozilla's instance of Looker.

Mozilla Data YouTube Channel: Responsible Data Collection is Good, Actually (Ubisoft Data Summit 2021)

Mozilla Data — 2026-09-10T06:18:04+00:00

Firefox Telemetry Engineer and Data Steward Chris H-C (:chutten) gives a talk at Ubisoft's Data Summit 2021 about how Responsible Data Collection as practised at Mozilla makes cataloguing easy, stops instrumentation mistakes before they ship, and allows you to build self-serve analysis tooling that gets everyone invested in data quality. Oh, and it's cheaper, too.

Mozilla Data YouTube Channel: Mozillians sharing the 2021 SciPy Conference experience

Mozilla Data — 2026-09-10T04:38:29+00:00

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

Mozilla Data YouTube Channel: Data Club Lightning Talk: Jan-Erik Rediger - Your personal Glean data pipeline

Mozilla Data — 2026-09-10T04:35:53+00:00

This talk was given as part of the Data Club Lightning Talk Session on February 11th, 2022. More on https://blog.mozilla.org/data/2022/02/25/this-week-in-glean-your-personal-glean-data-pipeline Information about Glean: https://mozilla.github.io/glean/book/index.html

Firefox Tooling Announcements: Happy BMO Push Day! (20260908.1)

dkl1 — 2026-09-10T02:34:16+00:00

Github Link

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

Bug 1205300 - Missing: related documentation “Reporting”
Bug 2068120 - Thunderbird access to “Iteration” and “Due Date” fields
Bug 2066252 - Prevent save if keyword checkin-needed-tb exists without target milestone
Bug 2070017 - Reinstate web bounty form
Bug 2059948 - Do not offer printable recovery codes to Duo users

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

Mozilla Data YouTube Channel: GLAM Datasets

Mozilla Data — 2026-09-09T22:01:52+00:00

Marina Samuel and Anthony Miyaguchi talk about the ETL pipeline created for the GLAM project (https://github.com/mozilla/glam).

Firefox Tooling Announcements: MozPhab 2.19.0 Released

sheehan — 2026-09-09T20:59:02+00:00

Bugs resolved in Moz-Phab 2.19.0:

bug 1987220 moz-phab patch --apply-to here should apply to the original base revision and rebase, rather than applying the raw diff on HEAD
bug 2016442 add moz-phab list subcommand

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

1 post - 1 participant

Read full topic

Thunderbird Blog: Desktop Settings: Removing technical jargon

Aly Blenkin — 2026-09-09T15:25:40+00:00

Our goal for this phase of work is to remove the technical jargon, use plain language, and make it effortless for everyone to make informed decisions about their settings. With over 250 blocks of settings content to untangle, we aimed for incremental improvements rather than striving for perfection.

While our previous research leaned heavily on our technical power users, this round intentionally focused on new users to make sure Thunderbird is intuitive from day one.

Summary of research

The new copy tested well: We achieved >80% comprehension across our tested copy for Notifications, Appearance, and Composition settings.
High confidence levels: Users felt confident to change settings without external help (asking someone, referencing docs, or using AI for support).
Interactions need refinement: We found spots where the interface didn’t always match expectations, like using a checkbox instead of an on/off toggle.

Using our content guidelines, we audited all 250+ content blocks to check accuracy, what was overly technical, and if anything was outdated. Our strategy was built up into steps to make it more achievable.

Step 1: Research & prioritization

User journey mapping, insights from research and user needs

Last month, we conducted research where we used a card sorting method to understand what users actually care about most and where they expect settings to live. Catch up on the Research Summary.

Step 2: Inventory audit

Content inventory with Thunderbird on the left and the content table on the right.

We mapped every piece of text in the app to build a full content inventory, assessing each piece of text for accuracy, freshness, and 8th-grade readability.

Step 3: Content redesign

Example of how we updated the notifications content

We removed any developer or system updates from the interface and replaced it with language that speaks to what the setting actually does for the user.

Our findings

We tested prototypes for Notifications, Appearance, and Composition and asked 4 questions to test the purpose of each setting category, scenario comprehension, and user confidence. Our target threshold was 80% comprehension.

Lyssna prototype displaying Appearance settings and question

Here is how the new copy tested with room for improvement around the interactions, visuals, and how the language can be even more clear and user friendly.

Settings Category	Purpose Comprehension	Scenario Accuracy	Confidence Score (out of 5)
Notifications	86%	71%	4.00
Appearance	86%	86%	4.14
Composition	100%	100%	4.43

What’s next

Improve the interactions: Aligning component types with immediate vs. batch actions so the UI behaves the way people expect.
Sharper indicators: Testers liked the visual diagrams for Threaded, Unthreaded, and Grouped messages, but they need a bit more detail to make the visual distinction instant.
Continue iterating on copy: Cleaning up remaining awkward phrasing (like Autosave 5 seconds) that still makes the experience feel slightly dated.

Next, we are taking everything we learned from this copy testing and applying it to the overall settings navigation and layout structure.

Redesigning settings isn’t always glamorous, which is why our team internally nicknamed this effort “Project Toto” inspired by high-tech Japanese toilets. Settings are something most people prefer not to think about, but when they are designed thoughtfully, the experience becomes seamless, intuitive, and surprisingly delightful.

As our new designs take shape, we’ll be reaching back out to both new and long-time users for feedback. Stay tuned for our next update, and let us know your thoughts in the comments!

The post Desktop Settings: Removing technical jargon appeared first on The Thunderbird Blog.

This Week In Rust: This Week in Rust 668

TWiR Contributors — 2026-09-09T04:00:00+00:00

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

Observations/Thoughts

Rust Walkthroughs

Miscellaneous

Awesome Rust Migrations

Crate of the Week

This week's crate is tokio-rcu, a user-space RCU implementation specifically built around the semantics of async rust and tokio.

Thanks to Roee Shoshani 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.

Cargo

Tracking Issue for checksum freshness

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

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

RFCs

Rust

Rustup

If you are a feature implementer and would like your RFC to appear on the above list, add the new 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.

Call for Participation; projects and speakers

CFP - Projects

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

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

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

CFP - Events

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

No Calls for papers or presentations were submitted this week.

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

613 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

add --print option

Rustfmt

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

This week we've hit quite a few regressions, both expected and unexpected. One of them has already been fixed, with fixes for a few others being discussed. One big improvement comes from caching the sanitizer set in Session, which fixes a large regression from last week. A few minor improvements landed, including a 75% reduction in memory usage while compiling bevy_render with the next trait solver.

Triage done by @JonathanBrouwer. Revision range: 5321a4f4..656a9da1

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.5%	[0.1%, 1.3%]	121
Regressions ❌ (secondary)	0.6%	[0.1%, 10.3%]	106
Improvements ✅ (primary)	-0.6%	[-1.9%, -0.1%]	63
Improvements ✅ (secondary)	-0.6%	[-2.4%, -0.1%]	65
All ❌✅ (primary)	0.1%	[-1.9%, 1.3%]	184

3 Regressions, 2 Improvements, 8 Mixed; 6 of them in rollups 33 artifact comparisons made in total

Full report here

Calls for Testing

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

Cargo

Tracking Issue for checksum freshness

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

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

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation 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

Cargo

fix(install): use packaged lockfile by default

Language Reference

UB does not time travel

Unsafe Code Guidelines

Can references inside an enum transiently set an invalid enum discriminant?

No Items entered Final Comment Period this week for Rust RFCs, Compiler Team, Language Team or Leadership Council. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

No New or Updated RFCs were created this week.

Upcoming Events

Rusty Events between 2026-09-09 - 2026-10-07 🦀

Virtual

2026-09-09 | Virtual (Cardiff, UK) | Rust and C++ Cardiff
- Operating Systems Book Club: Address spaces and Memory API
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
- Building a Rust GPU driver in the Linux kernel
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
2026-09-24 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-09-24 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
- Rust Cells — Interior Mutability from Rust Core to Tock OS
2026-09-29 | Virtual (London, UK) | Women in Rust
- Lunch & Learn: Crates, Tips & Tricks Lightning Talks - Bring your ideas!
2026-10-02 | Virtual | Rust Girona
- Sessió setmanal de codificació / Weekly coding session
2026-10-04 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Rust Deep Learning: First Sunday
2026-10-06 | Virtual (London, UK) | Women in Rust
- 👋 Community Catch Up
2026-10-07 | Virtual (Indianapolis, IN, US) | Indy Rust
- Indy.rs - with Social Distancing

Europe

2026-09-10 | Geneva, CH | Rust Geneva
- Rust Meetup Geneva
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-15 | Madrid, ES | MadRust
- Tras la Máscara de Async Rust
2026-09-17 | Dortmund, DE | Rust Dortmund
- Rust Dortmund Meetup - From Segfault to Safety @DiWoDo
2026-09-22 | Prague, CZ | Rust Prague
- Rust Meetup Prague @ Rockwell Automation
2026-09-24 | Aarhus, DK | Rust Aarhus
- Talk Night at SkyTEM
2026-09-24 | Amsterdam, NL | Rust Developers Amsterdam Group
- Rust Meetup @ BlockTech
2026-09-24 | Frankfurt, DE | Rust Rhein-Main
- AI Agentic Coding
2026-09-28 | Augsburg, DE | Rust Meetup Augsburg
- Rust Meetup #21: Maximilian Grauvogl & Marcel Fink - From Bits to Bugs: A Rust generator for SUIT Manifests and Structure-Aware Parser Fuzzing
2026-09-29 | Manchester, UK | Rust Manchester
- Rust Manchester September Code Night
2026-09-30 | Basel, CH | Rust Basel
- Rust Meetup #16 @ ERNI
2026-10-05 | München, DE | Rust Munich
- Rust Munich 2026 / 3

North America

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-12 | Boston, MA, US | Boston Rust Meetup
- Somerville Union Square Rust Lunch, Sep 12
2026-09-15 | San Francisco, CA, US | San Francisco Rust Study Group
- Rust Hacking in Person
2026-09-16 | San Francisco, CA, US | Bay Area Rust
- Bay Area Rust - Graphics Meetup
2026-09-16 | Hybrid (Vancouver, CA) | Vancouver Rust
- Building a Rust GPU driver in the Linux kernel
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-19 | Boston, MA, US | Boston Rust Meetup
- Boston Common Rust Lunch, Sep 19
2026-09-23 | Austin, TX, US | Rust ATX
- Rust Lunch - Fareground
2026-09-24 | Atlanta, GA, US | Rust Atlanta
- Rust-Atl
2026-09-26 | Boston, MA, US | Boston Rust Meetup
- Harvard Rust Lunch, Sep 26
2026-10-01 | Saint Louis, MO, US | STL Rust
- Building a Minimal, Rootless Container in Rust
2026-10-03 | Boston, MA, US | Boston Rust Meetup
- Alewife Rust Lunch, Oct 3

Oceania

2026-09-29 | Barton, AU | Canberra Rust User Group
- September Meetup

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

Jobs

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

Quote of the Week

The Demon has access to a Super Turing Machine.

– Connor Horman on rust zulip

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Firefox Nightly: Motion, Colour, Captions, Kit – These Weeks in Firefox: Issue 207

Mike Conley — 2026-09-08T18:38:38+00:00

Highlights

Want some Kit? Check out the store!
Sebastian Zartner [:sebo] added a panel to expose @media emulation (#1692434) and provided a way to emulate @media (prefers-reduced-motion: reduce) (#1477920)
More theme controls have been added to the New Tab customization panel:
Improved Picture-in-Picture caption support from some volunteer contributors
- Thanks to Lukáš Lipinský for adding caption support to Česká televize!
- Thanks to kernp25 for adding caption support to ardmediathek.de!

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

:Vincent
japandi
Nirmal Advani
Sebastian Zartner [:sebo]
tanvi.manku

New contributors (🌟 = first patch)

Aditi: Increase the maximum number of PDF.js preferences
🌟 Anil Verman: [Docs] Trigger listeners doc is seriously out of date
Fede: more than six thumbnails needed when Ctrl+Tab is used
Giulio B: frameId is wrong in webRequest events triggered via importScripts
🌟 Luiz Henrique Vieira: Remove dead CSS rule .alltabs-item[selected=”true”]
🌟 Devin Rousso: `emulation.setLocaleOverride` does not override `Accept-Language` header for in `Worker` for `fetch` and `WebSocket`
🌟 muhammad shaikh: Profile delete page heading should enclose profile name in quotes
🌟 Kevin Gosse: nsDataObj::QueryGetData in Firefox returns E_FAIL for formats it doesn’t carry, instead of DV_E_FORMATETC per the COM contract
Lukáš Lipinský: Česká televize captions do not display in the Picture-in-Picture window
🌟 mikey gough: Remove three unused devtools.debugger.file-search-* preferences
🌟 Nathan Leuz: Remove unused legacy preference browser.translation.neverForLanguages
🌟 Shawn Zivontsis: Reorder moz_origins composite unique index to UNIQUE(host, prefix)
tanvi.manku:
- Remove or update metrics expiring at the end of Firefox 154: pwmgr.doorhanger_submitted_* before Gecko switches to version 155 on 2026-07-20
- unnecessary scrollbars in edit dialogs for payments and addresses
🌟 Tim McNulty: Remove always-true clause from NS_ASSERTION in nsNavBookmarks::AdjustIndices (Coverity CID 1274453)

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

As part of Nova about:addons work:
- Introduced a shared localization module for built-in and curated AMO-hosted theme names, and updated the corresponding about:addons theme test to expect the new “Default” theme name shown when Nova is enabled – Bug 2055936 / Bug 2058235
- Added a message bar to the about:addons themes picker to surface AMO-hosted Nova theme download and install failures instead of failing silently – Bug 2054548

WebExtensions Framework

Fixed a startup race where an extension’s restored dynamic content scripts could be missing from the parent WebExtensionPolicy due to stale shared data – Bug 2058719

WebExtension APIs

Fixed publicSuffix.isKnownSuffix() to reject invalid domain-name characters, including wildcard suffixes, that could previously be matched as a known public suffix – Bug 2059819
Fixed the frameId reported by webRequest events for requests made from workers, including importScripts()-loaded scripts, which were previously attributed to the wrong frame – Bug 2048884
- Thanks to Giulio B for the fix to webRequest frameId attribution for worker requests.

DevTools

Benoit made it possible to display JSON Lines (JSONL/NDJSON) documents in the JSON Viewer (#2055774)
Leo McArdle [:leo] continues his quest to add MDN icons next links to MDN (#2049610, #2050159)
Julian Descottes [:jdescottes] vastly improved DevTools screenshot performance (by up to 35%) (#2056716)
Hubert Boma Manilla (:bomsy) fixed keyboard navigation for about:debugging (#2050797)
Julian Descottes [:jdescottes] fixed a bug that was preventing to show error messages in about:debugging (#2058021)
Nicolas Chevobbe [:nchevobbe] made ::checkmark pseudo element visible in the Inspector (#2009909)
- Used by customizable select (MDN)
- Preference: dom.select.customizable_select.enabled

WebDriver

Nirmal Advani cleaned up our codebase by removing the executeSoon helper, which was just a thin wrapper on top of Services.tm.dispatchToMainThread().
Sameem removed support for the “contexts” argument in the “session.unsubscribe” command. From now on, clients can unsubscribe only by event names or subscription ids.
John Schanck added support for validating if an authentication id is stored in the Virtual Authenticator Database.
Alexandra Borovova disabled the download panel to prevent the loss of the focus of the current document when a download begins.

Fluent

Here are utilities for measuring localization coverage at runtime

Lint, Docs and Workflow

Sylvestre has converted all our in-tree documents to be Markdown instead of reStructuredText.
Standard8 adjusted the source doc upload task, that runs on code review, to report failures into phabricator, rather than having a generic error message.
Standard8 made it so that test-manifest-toml issues for out-of-order entries should show up in phabricator more often.
https://arewemozsrcyet.com/ continues to head (mostly) in the right direction.

New Tab Page

HNT Eng had a work week last week. Did a lot of prep for big cleanups (Nova, Widget cleanup post WCW)
- Also worked on ways to automate trainhops / make them easier to deploy
Jack Brown updated newtabTrainhopAddon to allow co-enrollment and prioritize the highest version number, which ensures the New Tab Page picks the newest addon build when multiple enrollments overlap and prevents older experiment variants from replacing newer installs.
Fred Chasen fixed AccuWeather sponsored text overlapping the “Tell us what you think” link by adjusting medium weather card CSS (z-index and pointer-events), restoring hover and click behavior for the feedback link on affected New Tab Page cards.
Mike Kaply fixed wallpaper uploads failing when the wallpaper list can’t be queried from remote settings by adding a remote‑settings query fallback/local cache and defensive error handling so users can upload custom wallpapers during remote‑settings outages or timeouts.
japandi added the widgets.clocks.interaction pref and wired interaction tracking so World Clocks now emits telemetry/events for taps and opens (pref registration + tracker hooks), enabling accurate UX metrics without changing visible UI behavior.
Maxx Crawford prevented the weather widget from activating without user opt‑in by gating activation on the opt‑in pref and updating the onboarding flow, so weather and related location/telemetry remain disabled by default until explicit user consent.
Irene Ni made the New Tab client request layouts from remote-settings so NTP layouts and remote-config-driven content now update on load instead of remaining stale; this fixes cases where layout changes pushed via the remote-settings service (layouts collection) weren’t applied, improving consistency on desktop and Android clients that rely on remote layouts.
Nirmal Advani removed three unused activity-stream preferences (discoverystream.thumbsUpDown.*) from prefs and related code paths, reducing prefs surface area and avoiding confusion in about:config/telemetry without changing user-visible behavior.
Mike Conley fixed ExternalComponentWrapper to forward “live” properties like isIntersecting from MessageWrapper, restoring correct IntersectionObserver-driven behavior (visibility-based lazy-load and impression tracking) for remote components in the New Tab Page and discovery streams that relied on isIntersecting for render/telemetry triggers.
Irene Ni standardized New Tab widgets and sections header spacing (standardize spacing) to remove misaligned tiles and reduce visual jitter when resizing or toggling sections in the New Tab Page.
Mike Conley removed version-153 train-hop compatibility shims for the World Cup newtab logo variations (remove compatibility shims), an internal cleanup that prevents legacy logo-selection fallbacks from influencing current logo variations.
Maxx Crawford exposed available browser themes to New Tab and added apply/install actions (expose and apply themes), allowing users to install or immediately apply themes from the New Tab surface via ThemeManager/Theme API hooks.
Maxx Crawford added New Tab Customize Panel browser theme selection strings (add theme selection strings) so the new theme-selection UI is localized and displays correct labels across locales.
Maxx Crawford added a full browser theme selection sub-panel to the New Tab Customize Panel (theme selection sub-panel) to let users browse, preview, and pick themes directly inside the New Tab customization flow.
Scott Downe fixed Custom newtab wallpapers flash / blink some seconds after loading newtab by ensuring the custom wallpaper is painted only after image data is ready, which removes the multi-second visual flash on about:newtab for users with custom backgrounds and improves perceived stability during initial new-tab load.
Maxx Crawford exposed trainhopConfig values in Discovery Stream Admin tooling, giving operators direct access to trainhop routing/weight values from the admin UI/API so content trains and experiment routing can be adjusted without code deploys—this has no immediate end-user UI change but reduces time-to-rollout for Discovery Stream content changes.
Dre fixed Newtab custom wallpapers flash when selecting from picture of the day widget by deferring the wallpaper swap until the selected Picture of the Day is decoded and ready, which prevents the transient blank/flash users saw when changing wallpapers via the widget and makes wallpaper selection feel instantaneous and stable.
Maxx Crawford used the POTD thumbnailUrl image for the widget background (instead of the high-res image), which reduces bandwidth, memory footprint, and New Tab Page widget load latency for users who see the Picture‑of‑the‑Day widget.
Kyle Jones added MAC support to TopSitesFeed when fetching tiles from MARS, which enforces authenticated tile retrieval and reduces missing/401 tile failures for users relying on MARS‑served Top Sites tiles.

Performance Tools (aka Firefox Profiler)

Bug 2050028 – Enable the Gecko profiler by default with low-overhead features when running mochitests landed, which means mochitest failures now upload profiles by default:
- https://tests.firefox.dev/try.html can give you a prompt to ask an AI agent to look at the profile for you using profiler-cli:

Search and Urlbar

Dao and Moritz continue work on MCAB working on making the address bar’s contents to be content-process-safe and preparing to allow cross-process IPC for the address bar.
Mike Kaply fixed hidden actions still visible in Quick Actions mode.
Daisuke and Drew continued work on supporting Nova on the address bar and search bar components.
Caleb continued work to use array–binding for places sql queries, to improve performance.

The Rust Programming Language Blog: Rust debugging survey 2026 results

Sam Kellam — 2026-09-07T00:00:00+00:00

One of the biggest challenges Rust developers report in our annual surveys is a subpar debugging experience. So, back in February, we ran our first Rust Debugging Survey, in the hopes of identifying how Rust developers are using debuggers and what problems they are facing when doing so. We received over 2,300 responses, and we'd like to thank everyone who took the time to participate in the survey!

In this report, we'll go over some of the results of the survey. If you'd like, you can also check out the complete results of the survey.

If you'd like to skip ahead to any particular section, you can do so with this index:

Who Uses Debuggers?

The first step to making sense of the survey results is understanding who took the survey. We asked respondents to rate their Rust expertise, from "Never used it" to "Advanced". Over 80% reported themselves as "Advanced" or "Intermediate", split roughly evenly between the two:

[PNG] [SVG]

We also asked respondents if they currently use or have used debuggers in Rust. Over 46% said they currently do, with the remaining responses split between "have in the past" and "never have". That means that over half of respondents do not currently use a debugger for Rust!

[PNG] [SVG]

Categorized by expertise, the responses reveal that roughly half of "beginners" have never used debuggers in Rust! On the other hand, nearly half of "advanced users" currently do use debuggers in Rust:

[PNG] [SVG]

For respondents who indicated they had previously used Rust but no longer did, we asked if challenges with debugging support were why they stopped. For nearly 3%, the answer was "yes", with an additional 24% reporting debugging issues as being partially responsible (though mind the small response count; most respondents were active users of Rust):

[PNG] [SVG]

How Are Debuggers Used?

Knowing what debuggers developers are using and how is another important part of understanding the challenges they face. To this end, we asked respondents how they were debugging their programs. Unsurprisingly, most developers make use of print debugging and the dbg! macro. Excluding those, using lldb inside an IDE was the most popular choice, followed by gdb on the command line:

[PNG] [SVG]

We can get a more detailed breakdown of these results if we include the operating system on which the respondents use a given debugging approach. We examine this from two different angles. The first angle being, "On operating system X, what percent of responses are using debugger Y?". Print debugging and the dbg! macro are consistently the top two yet again, but looking beyond that, things get more interesting. On Linux, using gdb on the command line was the most popular choice by a thin margin, beating lldb in an IDE by only 0.4%. On Windows, Windows Subsystem for Linux (WSL), and macOS, lldb in an IDE was the top pick by at least 6%, making it a very popular choice in general. On Windows, the three least popular choices were the command line debuggers (gdb CLI, lldb CLI, and BugStalker), and on both Windows and macOS the third most popular pick was, "I don't know". Those who were debugging on operating systems not listed (Other) most frequently used some kind of special embedded debugger or gdb:

[PNG] [SVG]

The other angle we can look at these responses from is, "For users of debugger X, what percent of responses are using it on operating system Y?". For most debuggers, Linux makes up the largest portion of uses, ranging from about 45% to about 77%, followed by Windows, then macOS. The most notable exceptions are WinDbg and the Visual Studio debugger, which are primarily used on Windows, and lldb, which is used more on macOS than Windows in an IDE and on the command line:

[PNG] [SVG]

To the 6 respondents who use WinDbg on Linux: we wish you luck!

As for how people actually use their debugger of choice, the aggregate results are not particularly surprising. Roughly 87% of users are using debuggers for stepping line-by-line through programs and a little over half of users are using debuggers to obtain stack traces from hung/crashed processes. Only a quarter of the respondents use a debugger to debug async code. That might be partially caused by the async Rust debugging experience being clumsy and incomplete, or it could just be that users aren't writing much async code:

[PNG] [SVG] [Wordcloud of open answers]

If we break these results down by expertise, we can learn a bit more about usage patterns. As users become more experienced with Rust, their use of debuggers for learning purposes decreases, and they get more stack traces from crashed processes:

[PNG] [SVG]

The final bit of insight into how Rustaceans use debuggers is if they are debugging programs that use Rust alongside other programming languages. For 44% of respondents, the answer is "yes", which is a pretty high number!

As for which languages those are, C dominates the scene at a little over 70%, followed by C++ at about 43% and Python at about 20%:

[PNG] [SVG] [Wordcloud of open answers]

Challenges

Instead of diving right into asking, "what problems do you face when using debuggers?", or something to that effect, we first asked respondents why they decide against using debuggers whenever they do, including for reasons that aren't necessarily "problems with debuggers".

The most commonly reported reason was that it was easier or faster to use logs or print debugging to solve problems, reported by a little over 81% of respondents. This could partially be explained by the open responses, which featured complaints that debuggers were too difficult to set up and/or use (especially on Windows, when dealing with Web Assembly, or in embedded contexts) and sentiment suggesting that small and/or simple problems just don't really need a debugger. It does leave one wondering if the user experience could be made convenient enough to dethrone print debugging, but it seems hard to beat something so intuitive. This is followed by roughly 37% of respondents who write code that Just Works. Fair enough. After that, about 26% of respondents indicated that they've decided not to use debuggers in situations where the language features they were working with had poor support. This is slightly more than issues with standard library types, at about 22%, which is slightly more than issues with external library types, at about 20%:

[PNG] [SVG] [Wordcloud of open answers]

As stepping through code was anticipated to be one of the most common uses for debuggers, we directly asked respondents if they faced any issues when doing so. A little over 51% of respondents said they did! Of those who reported that they experienced issues stepping through code, we asked when they were experiencing issues. Async code was the most common case reported at slightly over 28%, followed by code involving macros at about 23%. The least common case reported was code involving function pointers, at almost 6%:

[PNG] [SVG] [Wordcloud of open answers]

We also directly asked respondents which types in the standard library were hard to work with, if any. This was an open-response question, and reading through the responses, some particularly common complaints were with enums and collections, particularly std::collections::HashMap and std::vec::Vec. This is also visible in the word cloud in the full report.

We asked respondents to indicate which pain points, if any, they have encountered when using debuggers with Rust. At slightly over 74%, poor representation of values was the most common pain point by a decent margin, followed by being unable to print variables at just over 55%:

[PNG] [SVG]

Debugger Visualizers

We asked respondents to indicate if they were library authors, and if so, if they were aware of and using the debugger_visualizer attribute. Nearly 62% of respondents indicated that they were library authors who were not aware of this attribute:

[PNG] [SVG]

For those who indicated that they were library authors who knew about the attribute but did not use it, we also asked why. This represented a much smaller fraction of respondents, so keep that in mind! That said, half of these library authors indicated that they didn't have the time to maintain visualizer attributes, and just under half indicated they didn't know how to write visualizer scripts:

[PNG] [SVG] [Wordcloud of open answers]

For those of you who have been reading this section asking yourself what the debugger_visualizer attribute is, you can read up on it in The Rust Reference: Debugger Attributes. The quick explanation is that the debugger_visualizer attribute can be applied to modules or the crate root to embed files in the debug information which improve the display of values with certain debuggers. The two currently supported file types are Natvis files, used by Microsoft debuggers such as WinDbg, and GDB "pretty printers", which are structured Python scripts used by GDB.

Closing Remarks

Thanks to your participation in this survey, we've gained some great insights about how Rustaceans are using debuggers and what issues they are facing. For example, knowing that such a high number of users are dealing with poor representation of values pairs well with knowing which standard library types are causing issues, knowing that many library authors haven't heard of the debugger_visualizer attribute, and knowing that many of those who have but don't use it either don't know how or don't have time to maintain visualizer scripts.

Looking to the future, the survey results have suggested that there are a few notable ways we could most significantly improve the debugging experience in Rust, such as:

Fixing the way enums are represented by debuggers so they show actual variants
Fixing the way collections (such as HashMap) are represented by debuggers so they show their contents, rather than their implementation details
Fixing the way string types (such as String and CString) are represented by debuggers so they render as text, rather than their implementation details
Improving the async debugging experience, particularly with stack traces
Improving stepping through certain state machines (such as iterators and Futures)
Providing documentation on basic set up and use of some common debuggers

A common suggestion that could resolve those first three points is to use the Debug implementation of types to display them in debuggers. There are challenges to that approach, such as the fact that the Debug implementation is not present in the final binary unless it is actually used somewhere in the program, but it isn't impossible. Notably, this is already supported by the BugStalker debugger (given the same condition that the Debug implementation must actually be used), which some of you first heard about from the survey! It also appears to have some support for async, with plans to expand.

One notable way the debugger experience is currently being improved is through the ongoing Google Summer of Code project improving how we test debug info and visualizer scripts, making it easier to maintain and improve our own visualizer scripts and general compatibility with visualizer scripts without silent breakage or regressions.

Once again, we'd like to thank everyone who took the time to participate in the survey!

Firefox Tooling Announcements: Firefox DevTools MCP 0.10.2 released

jdescottes — 2026-09-04T13:41:12+00:00

Firefox DevTools MCP (firefox-devtools-mcp) 0.10.2 is out on npm.

New tools:

press_key — sends a single key, optionally with modifiers, to a snapshot element or the focused element (Return, Escape, Tab, arrows, ctrl+shift+t, …).
type_text — types text key by key into the focused element, with an optional key to press afterwards.
set_network_cache — bypass or restore the HTTP cache, for the selected tab or browser-wide. Useful before a performance measurement or when verifying a change a cached asset would otherwise hide.

Other changes:

navigate_page and new_page take an optional wait argument (none, interactive, complete), so an agent can wait for the load event before deciding a page is done.
Windows: per-user Firefox installs are now detected, instead of failing with “unable to find binary in default location”.
aarch64 Linux: geckodriver is now resolved on all platforms, fixing “Unable to obtain browser driver” when a native geckodriver is on PATH.
Several Windows path fixes for --output-file, --log-file and saveTo.
New generated reference page documenting every tool and its parameters: docs/tools.md (firefox-devtools-mcp/docs/tools.md at main · mozilla/firefox-devtools-mcp · GitHub)

Install:

claude mcp add firefox-devtools npx @mozilla/firefox-devtools-mcp@latest

codex mcp add firefox-devtools – npx @mozilla/firefox-devtools-mcp@latest

For internal Firefox development, swap firefox-devtools-mcp with firefox-devtools-mcp-moz in order to benefit from additional tools, such as chrome-privileged script execution.

Special thanks to all the contributors who filed issues and submitted patches for this release: freema, f3tch (github), jasonanovak and shoemoney.

Full changelog: https://github.com/mozilla/firefox-devtools-mcp/releases/tag/v0.10.2
Repository and issues: GitHub - mozilla/firefox-devtools-mcp: Model Context Protocol server for Firefox DevTools - enables AI assistants to inspect and control Firefox browser through the Remote Debugging Protocol · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org

1 post - 1 participant

Read full topic

Firefox Tooling Announcements: PerfCompare just deployed (Sept 3, 2026)

csevere — 2026-09-03T18:34:29+00:00

The latest version of PerfCompare is now live! This includes the launch of PerfCompare’s Simple View. Read the following blog post, Introducing PerfCompare’s Simple View, to learn more.

Check out the change-log below to see the updates:

Highlights:

[kala-moz]

Other changes:

[kala-moz]

[gopar]

[bug-2021092 ] Update light/dark toggle wording to be less ambiguous (#1073 )

Thank you for the contributions!

Bugs or feature requests can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Matrix. Come and chat!

1 post - 1 participant

Read full topic

Mozilla Performance Blog: Introducing PerfCompare’s Simple View

Kala Severe — 2026-09-03T18:29:50+00:00

We heard you. You don’t want to open your PerfCompare performance comparison and feel like you need a background in statistics to interpret the Mann-Whitney-U results. Cliff’s Delta, CLES, and normality tests, oh my! It should not feel like you’ve blindly walked into a college stats exam, unless of course, you love statistics. For the rest, all you want is an easy answer to the question: Did my changes make things faster or slower?

So we fixed that. PerfCompare now shows the bare essentials by default and tucks the heavy statistics one click away.

An approachable default for beginners and occasional users

The results table now leads with the platform, the Base and New values, how far the median moved and its direction, the status (which includes the option to filter out noise) and the size of the change. To create a more advanced view, a single “Advanced options” dropdown allows you to add the expert columns (Cliff’s Delta, CLES, Significance) and the info-rich expanded row details below the full-width graph. A small help section at the top of the results provides a quick explanation of the columns. The purpose is to serve a diverse audience while preserving your selections in the URL so a shared link reproduces your view.

The “Advanced options” dropdown lets you add the precise statistics columns:

Cliff’s Delta: An effect-size measure of how far the Base and New distributions have pulled apart
CLES (Common Language Effect Size): The chance a random New run beats a random Base run, e.g. “New wins 78% of the time”
Significance: Whether the difference is a real signal or just noise

Each one toggles on independently, so you can surface only Significance or the whole trio.

Expand a result and you get a clean panel: a full-width graph of how your Base and New runs are spread out, a quick summary (platform, app, which direction is “better”), and a little “how to read this graph” tool-tip for anyone who hasn’t stared at a distribution curve before. You can still poke at the graph’s mode controls if you want to dig in.

You can access the extra expanded row details such as effect size and confidence intervals or the full stats table in the “Advanced options” dropdown. Turn on what you need, and the expanded extras lay out in neat two-column rows. If you turn on mode analysis and there aren’t multiple modes to show, we now say “No mode analysis available” instead of a blank space.

Lastly, the advanced columns and expanded-row details you’ve switched on, along with your filters and sorting, are all encoded in the URL. Paste it to a coworker and they’ll land on the same result you were looking at; for filters and sorting, the shared link takes precedence over whatever they had saved locally. (One exception: the “How to read the results” panel is a personal per-browser preference, so it stays with you rather than tagging along on the link.)

What’s next

Several follow-ups on the way:

Remembering your advanced choices. Right now the advanced columns and expanded-row toggles start from the clean defaults each visit (they only persist in a link). Soon PerfCompare will remember them in your browser the same way we do for filters. However, if you open a shared link from a colleague, their specific view takes priority, overriding your own local settings so you both see the exact same data.
Carrying your selections into subtests. Today, the Advanced options you pick on the main results page don’t follow you when you open a test’s subtests. We’re wiring it up so whatever you’ve enabled up top is automatically enabled in the subtests dropdown too, for one consistent view.
Expanding the “How to read the results” cheat sheet to include Cliff’s Delta, CLES, and Significance definitions.

Share your feedback

We want PerfCompare to work for all users, whether you’re chasing your first regression, or you’re an expert who doesn’t want to lose their favorite metrics to a cleaner view. Our answer is separating the simple view from the power user view, and making the toggle obvious and shareable.

The great news is it’s live now! Go expand a Mann-Whitney-U result, click around the Advanced options, and tell us what you think. Please share your feedback, suggestions, or comments on the #perfcompare channel on Matrix. If you’ve encountered a bug or have a feature request, please file them in Bugzilla. We’re listening.

Firefox Tooling Announcements: Firefox Profiler Deployment (September 3, 2026)

canova — 2026-09-03T15:36:56+00:00

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

Highlights:

[Andrew Creskey] Show which network requests were prefetched (#6259)
[Florian Quèze] profiler-cli: accept --limit 0 as unlimited, and make truncation loud (#6267)

Other Changes:

[Nazım Can Altınova] Update oxfmt 0.59.0 → 0.63.0 (major) (#6262)
[Florian Quèze] profiler-cli: document the marker field:value search syntax (#6265)
[Florian Quèze] profiler-cli: report one time base for text and JSON output (#6266)
[Florian Quèze] profiler-cli: avoid a stack overflow on large marker threads (#6264)
[Markus Stange] Give the frameTable a lib column (#6258)
[Florian Quèze] profiler-cli: report the network request count the filters ran against (#6274)
[Nazım Can Altınova] Fix dark mode contrast of the warning icons in the publish panel (#6280)
[Nazım Can Altınova] Extract the publish panel warning indicator into a small component (#6282)
[Markus Stange] More typed arrays in the FrameTable (and a flags column) (#6173)
[Nazım Can Altınova] Improve the profiler-cli publish script and document the whole deployment in a better way (#6260)
[fatadel] Sync: l10n → main (September 3, 2026) (#6301)
[fatadel] Bump profiler-cli version to 0.9.0 (#6302)

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

es-CL: ravmn
nl: Mark Heijl
sv-SE: Andreas Pettersson
sv-SE: Luna Jernberg
sv-SE: Peter Kihlstedt
tr: Selim Şumlu
tr: giray
zh-CN: 高乐喆

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

1 post - 1 participant

Read full topic

The Rust Programming Language Blog: Announcing Rust 1.98.1

The Rust Release Team — 2026-09-03T00:00:00+00:00

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

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

rustup update stable

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

What's in 1.98.1

Rust 1.98.1 fixes a miscompilation in vtable generation.

In Rust 1.98.0, in some circumstances, rustc would incorrectly generate a trait object vtable with a null pointer where a function pointer should be. This leads to undefined behavior in the emitted code. In some cases this may 'just' cause segfaults due to the null pointer being loaded, but it is possible for it to be justification for arbitrary effects (as is typical for UB).

If you'd like to help us out by testing future releases, you might consider using the beta (rustup default beta) and nightly (rustup default nightly) channels locally and in your CI. Please report any bugs you might come across!

Contributors to 1.98.1

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

Thunderbird Blog: Thunderbird Desktop New Protocol Support: Microsoft Graph API

Eleanor Dicharry — 2026-09-02T19:58:47+00:00

As many of you know, Microsoft will be disabling Exchange Web Services (EWS) support on its Microsoft 365 platform later this year. The Thunderbird Desktop team has been hard at work to ensure continuity of functionality through this transition, and today we are pleased to announce the release of native Thunderbird support for the Microsoft Graph API! Curious what this means for you? Then keep reading to find out!

IMAP and EWS and Graph, Oh My!

When connecting to either on-premises or hosted Microsoft accounts, Thunderbird users now have an array of options. Users might not know which option is best for their case, so we’ll start with a little bit of guidance to help users decide what will be best for them. First off, if you are currently using IMAP with an on-premises Exchange account or a Microsoft 365 hosted account, and it’s currently working for you, then there’s nothing you need to do! EWS and Graph support are for users whose organizations do not allow IMAP access.

Now for the more complicated part. Last year, we released EWS email support for both on-premises Exchange accounts and Microsoft 365 hosted accounts. If you are using the EWS protocol with an on-premises Exchange account, then you don’t need to do anything.

However, if your organization uses Microsoft 365 for email, and you’re currently using EWS to connect to that account, then you need to take action before October of this year. Earlier this year, Microsoft announced that they would begin a phased shutdown of EWS on Microsoft 365/Exchange Online starting in October of 2026 with the goal of a complete shutdown in 2027. If you are currently using Thunderbird’s EWS support to connect to a Microsoft 365/Exchange Online email account, then you will need to switch to the Microsoft Graph API support to keep using Thunderbird beyond these dates. See below for details.

So the TL;DR is:

IMAP for on-premises or Microsoft 365 hosted email => No action required.
EWS for on-premises Exchange => No action required.
EWS for Microsoft 365/Exchange Online => Set up a new Microsoft Graph account in Thunderbird.

Microsoft only supports the Graph protocol on Microsoft 365, so that is the only provider that offers it. On-premises Exchange servers do not implement the Graph API, so Thunderbird’s EWS support will continue to be the primary mechanism for users on these servers to connect to their email accounts.

Microsoft Graph Account Set Up

Thunderbird does not support migrating accounts to different protocols. Instead, you will need to set up a new account. If you have an existing EWS-connected Microsoft 365 account, first you’ll need to delete that account in Thunderbird. You can do this from the account settings. Deleting the account locally in Thunderbird will not affect any data stored on Microsoft 365, so your data is safe.

Once your previous EWS account has been deleted, you can use Account Hub to set up a new account. In the new account set up dialog, enter your Microsoft 365 hosted email account. Thunderbird should automatically detect that your email is hosted on Microsoft 365 and will give you a few options for getting connected. Choose the Microsoft Graph option, and you should be good to go! If for some reason automatic configuration doesn’t work, you can still configure your account manually using these instructions.

What is currently supported?

As with EWS, Thunderbird’s current Graph support extends only to email. Thunderbird does not yet support Calendar and Address Book functionality with either EWS or Graph.

What’s in ESR?

Thunderbird’s current Extended Support Release, version 153, supports the EWS protocol, but does not support the Microsoft Graph API, which was first enabled in the Thunderbird Release channel in version 154. Users on the ESR channel who are using Microsoft 365 will need to migrate to the Release channel in order to use the Microsoft Graph API support to continue accessing Microsoft 365 hosted mailboxes.

What’s Next?

Calendar and Address Book! The Thunderbird Desktop team has already started working on support for connecting to Microsoft 365-hosted calendars using the Graph protocol. We will be busily working on this throughout the rest of the year. As with our previous work on Thunderbird support for EWS, this is the first new calendar protocol to be added to Thunderbird in many years. We are currently doing some up-front design work to ensure a sustainable product going forward and hopefully make the next calendar protocol easier to add.

How can users give us feedback?

As with all new functionality, there may be features we are missing or unexpected issues. As always, Bugzilla is always open! You can send us feature requests and issue reports using this Bugzilla link. Thunderbird’s greatest strength is its community of users, developers, and supporters who help us deliver the best tools we can to connect people with one another. We welcome community involvement to help us make everything better!

Nitty-Gritty development details

Those of you who have followed along with development throughout EWS and into Graph support might have noticed that, compared to EWS, we were able to implement support for the Microsoft Graph API relatively quickly. This is largely due to the up-front thought and work that went into the design and development of Thunderbird’s EWS support. The Graph implementation was the team’s first test of the extensibility of the new architecture, and we were very pleased with the results. It took 11 months to enable basic synchronization with EWS. With the new architecture, we were able to cut that time down to 4 months with Graph.

Graph’s operations are similar to the operations that EWS provides, but different enough that it served as a great first test case for how the new email client architecture can support future protocols, such as JMAP. Given the results of the Graph implementation, we are optimistic that the same architecture will extend to JMAP once the team decides to move forward to that new protocol. We are hopeful that what we have built here can provide a sustainable base on which to build future protocol support in Thunderbird.

This would not have been possible without many contributions from Thunderbird developers, past and present, and the community of users who have helped us improve Thunderbird by submitting issue reports and feature requests. We are grateful to everyone for their support!

The post Thunderbird Desktop New Protocol Support: Microsoft Graph API appeared first on The Thunderbird Blog.

The Mozilla Blog: AI on your terms: Firefox meets you where you are

Mozilla — 2026-09-02T13:00:00+00:00

People feel differently about AI, and here at Firefox, we think that is completely reasonable. Something else that is completely reasonable: deciding for yourself how and when you engage with AI features.

For some of you, AI is part of your everyday life, whether you are using it to summarize a large amount of information, brainstorm ideas for work, or research trips and personal purchases. Some of you interact with AI as little as possible, and prefer to keep it that way. And a lot of you are somewhere in between: curious, but exploring on your own terms and at your own pace.

Your personal use of AI is just that, personal. Firefox offers various levels of AI integration into your browser, and the choice between them is entirely yours.

Block new and current AI features in a single switch

Opting out of upcoming and current AI features on your browser should not require endless navigation through multiple Settings pages. That’s why Firefox offers an AI controls section within its General Settings panel. A single, easily located place where you can block current and future AI features and related pop-ups with the swipe of a toggle.

Not only do we want people to have the choice to remove certain AI features from their Firefox browsing experience, we make sure doing so is as easy and accessible as possible.

Choose the features that work for you

For the many people who sit in the middle of the AI usage spectrum, we made sure you can opt in and out of specific features in line with your preferences. Capabilities like AI translations, image alt text in Firefox PDF viewer, tab group suggestions, and key points in link previews can all be individually switched on and off, ensuring you can enjoy such offerings on a case by case basis as it suits your needs.

In addition, if there is an AI chatbot provider you already trust or pay for, you can use it directly inside Firefox’s built-in desktop sidebar. This means you can use your chatbot of choice and browse side by side without ping-ponging between tabs.

While some browsers integrate a singular AI model or chatbot into their system, this can restrict flexibility and concentrate data sharing. Firefox prioritizes transparency and user control by letting you select from multiple providers, allowing you to review each option’s policies before you engage with them.

You can turn on AI chatbot providers in the AI controls section of browser settings and select one of the following: Anthropic Claude, ChatGPT, Google Gemini, and Le Chat Mistral. Once this feature is turned on, you can switch between chatbots within the sidebar itself based on your preferences and task at hand.

Smart Window, for when you want help finishing what you started

Smart Window is Firefox’s most integrated AI experience, but that doesn’t mean it compromises our commitment to choice, privacy, and transparency. Our newest window type, which we’ve been polishing and testing in beta, uses only the context you share with it to help you move work forward and across the finish line.

When permitted by you, its built-in, AI-powered assistant can work directly with your open tabs and browsing history to connect the dots. This means comparing information, generating recommendations, summarizing pages, and planning projects without having to feed every crumb of context from your previous and current browsing activity each time you enter a new prompt.

As we’ve built out Smart Window, we’ve added a few additional features to align its design with how people actually browse. These include the ability to group related tabs together – so you can make sense of what’s open without spending time organizing everything yourself – and visual history previews that help you spot a page you visited earlier when you can’t remember the exact URL or phrase searched. In addition, a new partnership with Exa enables Smart Window to not only locate current web information to include in responses, but also display the sources behind these responses so you can verify what you’re seeing, without breaking your flow.

We understand people use different Firefox windows for different reasons, and often switch between options based on the task at hand. Smart Window is the window you reach for when your browsing turns into a project. When your quick search becomes inspo for the girls’ trip you’ve been meaning to plan, or finding the perfect gift for your partner becomes a dozen tabs comparing prices and reviews, turn the window you’re already using into a Smart Window. Your tabs and progress stay in place while Smart Window helps organize the task and move it forward. Use it for one complex project, use it all the time, or switch it back when you’re done.

Smart Window remains in beta as we continue to learn and improve from our community’s feedback. At present, it’s available in English to people in the U.S. and Canada.

To try Smart Window, visit: https://www.firefox.com/smart-window

Always your call

Your opinions and preferences on AI usage are individual to you.

We don’t think there is one right answer for how and when to engage with AI, and we’re not going to pretend there is one. What we can do is make sure that whatever level of engagement is right for you, Firefox supports it well. Because the only person telling you how much AI you need should be you.

The post AI on your terms: Firefox meets you where you are appeared first on The Mozilla Blog.

This Week In Rust: This Week in Rust 667

TWiR Contributors — 2026-09-02T04:00:00+00:00

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

Foundation

Newsletters

The Embedded Rustacean Issue #79

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Research

Functional State Machines in Rust: Typestate and Newtype Patterns

Miscellaneous

Ubuntu Rust: How Canonical Is Modernizing Core System Tools

Crate of the Week

This week's crate is buf_read_splitter, a crate to split (separate) a stream into sub-subtreams.

Thanks to flo 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.

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

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

CFP - Events

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

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

522 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

Rustfmt

allow users to set the release channel when running the diff check

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

This week continues a steady stream of compile time improvements. Most of the impact this week comes from type system micro-optimization in #160473 and dead_code lint propagation fix in #161571. We've also hit unexpected regression in a standard library refactor, but we expect that to be addressed soon.

Triage done by @panstromek. Revision range: 9a4ad59a..5321a4f4

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.6%	[0.2%, 1.8%]	27
Regressions ❌ (secondary)	0.6%	[0.2%, 1.8%]	27
Improvements ✅ (primary)	-0.7%	[-2.4%, -0.1%]	135
Improvements ✅ (secondary)	-0.7%	[-2.2%, -0.1%]	120
All ❌✅ (primary)	-0.5%	[-2.4%, 1.8%]	162

5 Regressions, 4 Improvements, 4 Mixed; 9 of them in rollups 39 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:

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

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

Rust RFCs

Leadership Council

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

Errata RFC 4004: Discourage locally recursive accessible(..)

Upcoming Events

Rusty Events between 2026-09-02 - 2026-09-30 🦀

Virtual

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-09 | Virtual (Cardiff, GB) | Rust and C++ Cardiff
- Operating Systems Book Club: Address spaces and Memory API
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
- Building a Rust GPU driver in the Linux kernel
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
2026-09-24 | Virtual (Berlin, DE) | Rust Berlin
- Rust Hack and Learn
2026-09-29 | Virtual (London, UK) | Women in Rust
- Lunch & Learn: Crates, Tips & Tricks Lightning Talks - Bring your ideas!

Africa

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

Europe

2026-09-03 | Berlin, DE | Rust Berlin
- Rust Berlin on location 🏳️‍🌈 - Edition 017
2026-09-03 | Oxford, GB | Oxford ACCU/Rust Meetup.
- Live coding a Sinclair Spectrum from scratch
2026-09-08 | Paris, FR | Rust Paris
- Rust meetup #87
2026-10-10 | Geneva, CH | Rust Geneva
- Rust Meetup Geneva
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-15 | Madrid, ES | MadRust
- Tras la Máscara de Async Rust
2026-09-22 | Prague, CZ | Rust Prague
- Rust Meetup Prague @ Rockwell Automation
2026-09-24 | Aarhus, DK | Rust Aarhus
- Talk Night at SkyTEM
2026-09-24 | Amsterdam, NL | Rust Developers Amsterdam Group
- Rust Meetup @ BlockTech
2026-09-24 | Frankfurt, DE | Rust Rhein-Main
- AI Agentic Coding
2026-09-29 | Manchester, GB | Rust Manchester
- Rust Manchester September Code Night
2026-09-30 | Basel, CH | Rust Basel
- Rust Meetup #16 @ ERNI

North America

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-05 | Boston, MA, US | Boston Rust Meetup
- Allston-Brighton Rust Lunch, Sep 5
2026-09-08 | Montreal, CA| The Rust Foundation
- Rust Teams Health Summit
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-12 | Boston, MA, US | Boston Rust Meetup
- Somerville Union Square Rust Lunch, Sep 12
2026-09-15 | San Francisco, CA, US | San Francisco Rust Study Group
- Rust Hacking in Person
2026-09-16 | San Francisco, CA, US | Bay Area Rust
- Bay Area Rust - Graphics Meetup
2026-09-16 | Hybrid (Vancouver, CA) | Vancouver Rust
- Building a Rust GPU driver in the Linux kernel
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
2026-09-24 | Atlanta, GA, US | Rust Atlanta
- Rust-Atl
2026-09-26 | Boston, MA, US | Boston Rust Meetup
- Harvard Rust Lunch, Sep 26

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

Jobs

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

Quote of the Week

I think you are inventing provenance for integers. Please, let's not.

– Ralf Jung in an RFC discussion

Thanks to kleines Filmröllchen for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Firefox Developer Experience: Firefox WebDriver Newsletter 155

Henrik Skupin — 2026-09-01T16:00:00+00:00

WebDriver is a remote control interface that enables introspection and control of user agents. As such, it can help developers to verify that their websites are working and performing well with all major browsers. The protocol is standardized by the W3C and consists of two separate specifications: WebDriver classic (HTTP) and the new WebDriver BiDi (Bi-Directional).This newsletter gives an overview of the work we’ve done as part of the Firefox 155 release cycle.

Contributions

Firefox is an open source project, and we are always happy to receive external code contributions to our WebDriver implementation. We want to give special thanks to everyone who filed issues, bugs, and submitted patches. In Firefox 155, several WebDriver bugs were fixed by contributors:

Khalid AlHaddad updated the Mozilla-specific moz:debugging module to no longer rely on the same nested event loop API as DevTools, which prevents conflicts when WebDriver BiDi and DevTools are used in parallel.
Nirmal Advani cleaned up our codebase by removing the executeSoon helper, which was just a thin wrapper on top of Services.tm.dispatchToMainThread().
Nirmal Advani fixed the Actions API so that the dblclick event is fired when performing a double-click while holding down the Ctrl key on non-macOS platforms.
Sameem added the cleanup logic for subscriptions when a browsing context is destroyed.
Sameem removed support for the contexts argument in the session.unsubscribe command. From now on, clients can unsubscribe only by event names or subscription ids.

WebDriver code is written in JavaScript, Python, and Rust, so any web developer can contribute! Read how to set up the work environment and check the list of mentored issues for Marionette or the list of mentored JavaScript bugs for WebDriver BiDi. Join our chatroom if you need any help to get started!

All Changes

A complete list of developer-facing changes included in this Firefox release is available in the MDN Firefox 155 Release Notes.

Mozilla Open Policy & Advocacy Blog: Browsers compete on privacy. When the operating system allows.

Sema Karaman — 2026-09-01T12:59:52+00:00

For more than two decades, Mozilla has advocated for an internet where people, not powerful platforms, determine how technology works for them. Meaningful consumer choice requires more than the ability to select a browser. People should also be able to choose what their browser can do, from the privacy protections it provides to the ways they can customize their experience.

A recent Firefox product initiative brings that longstanding policy concern into focus.

Firefox is bringing a built-in Ad Blocker to Firefox for iOS, giving people an optional way to reduce intrusive ads and ad-related trackers while browsing. The feature uses an EasyList-based filter list and Apple’s WebKit Content Blocker framework. It is off by default and can be enabled or disabled at any time.

The feature responds to years of requests from Firefox users on iPhone. It also illustrates a wider policy problem: dominant mobile platforms can determine which privacy and customization tools competing browsers are able to offer.

On Firefox for desktop and Android, people can install add-ons that change how they experience the web.

Almost 40% of all Firefox users take advantage of this functionality. They include content blockers, accessibility tools, password managers and other extensions that allow people to shape their browser around their own priorities.

Firefox cannot offer that same add-on ecosystem on iOS. Apple’s App Review Guidelines generally require apps to remain self-contained and restrict them from downloading or executing code that introduces or changes an app’s functionality.

Apple also controls the conditions under which browsers may use alternative browser engines, with entitlement pathways available only in certain jurisdictions and subject to detailed requirements that no browser developer has been able to meet. In practice, the combined effect of Apple’s app distribution and browser policies prevents Mozilla from bringing the full Firefox add-on experience available on other platforms to iPhone users.

This is not simply a technical inconvenience but a competition and consumer-choice problem.

A mobile platform owner controls the operating system, the primary app-distribution channel and its own browser.

When that company can also determine which technologies, add-on models and operating-system capabilities competing browsers may use, it sets the boundaries within which browser competition takes place.

Operating system restrictions can prevent independent browsers from differentiating themselves.

Even when users want browsers to differentiate on privacy, operating system restrictions can prevent independent browsers from doing so. They can also force browser developers to recreate individual tools as platform-specific, built-in features rather than allowing people to choose from a broader add-on ecosystem. That increases development costs, slows or restricts innovation and produces uneven experiences across devices.

The new Firefox Ad Blocker is a practical response to those constraints. It gives iPhone users more control today using the technical options currently available to us. But building one feature directly into a browser is not a replacement for a healthy, independent add-on ecosystem. It addresses a specific capability gap for Firefox users on iOS at this time.

A competitive browser ecosystem should focus on the entire user experience.

The EU’s Digital Markets Act has shown that policy interventions can improve user choice, with Mozilla and other browsers reporting significant growth following the introduction of browser choice screens. However, meaningful browser competition must extend to the full user experience. This includes whether people can easily choose and change their default browser. It also includes whether people can benefit from the full set of innovations developed by rival browsers by ensuring adequate interoperability with the operating system. With this deeper focus on the full user experience, people can benefit from differentiated privacy and security features.

People’s privacy choices should not depend on whether a dominant platform permits their browser to offer them.

The post Browsers compete on privacy. When the operating system allows. appeared first on Open Policy & Advocacy.

The Mozilla Blog: Introducing Ad Blocker for Firefox on iOS: More Control, Fewer Distractions

Mozilla — 2026-09-01T12:45:52+00:00

There’s only so much room on your screen. Pop-ups, overlays, and ads can take over fast, getting between you and what you came to do.

That’s where Ad Blocker for Firefox on iOS comes in: a built-in option that blocks many third-party ads and ad-related trackers before they load, helping reduce clutter and distractions while you browse.

How it works

Ad Blocker uses Apple’s WebKit Content Blocker technology and the EasyList filter list to determine what gets blocked. There’s no separate extension to install, and you can turn it on in Settings > Browsing > Ad Blocker. It’s off by default, so you decide whether to use it.

Ad Blocker won’t block every ad. Ads served directly by the site you’re visiting and ads shown in search results will still appear. Sponsored shortcuts and other sponsored content shown by Firefox when you open a new tab are separate from ads on the web pages you visit, so Ad Blocker doesn’t affect them.

Ad Blocker works alongside the privacy protections already built into Firefox, including Enhanced Tracking Protection, which blocks many trackers and limits tracking across the web.

More control over how you experience the web

On Desktop and Android, Firefox already supports a strong ecosystem of ad-blocking and privacy extensions, giving people the flexibility to choose the tools that work best for them. We value that ecosystem and will keep supporting it.

iOS works differently. Extensions aren’t available in the same way, and we know people want more options. Bringing ad blocking to Firefox on iOS meant building it directly into the browser.

Giving people choice in how they experience the web is important to us. Advertising helps fund much of the open web, supporting the publishers, creators and websites people rely on. We also know that ads can sometimes crowd the screen or interrupt what you’re trying to do.

That’s why Ad Blocker is optional: you decide whether it’s part of how you browse. It’s part of a broader approach across Firefox to give you more control over your experience, from the extensions you use to how AI shows up in your browser.

Try it

To turn on Ad Blocker, go to Settings > Browsing > Ad Blocker.

If you find an ad you expected to be blocked, a site that behaves strangely or something we should improve, let us know on Mozilla Connect.

Visit our Support page for more details on Ad Blocker for Firefox on iOS. For more on Firefox’s built-in privacy protections, check out How Firefox Protects Your Data.

The post Introducing Ad Blocker for Firefox on iOS: More Control, Fewer Distractions appeared first on The Mozilla Blog.

The Rust Programming Language Blog: Announcing rustup 1.29.1

The Rustup Team — 2026-09-01T00:00:00+00:00

The rustup team is happy to announce the release of rustup version 1.29.1.

Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software.

What's new in rustup 1.29.1

The headlines of this release are:

Concurrency in certain rustup operations has been improved:
- When running rustup update, rustup will first check for possible updates in parallel. pr#4752
- When running rustup component add with multiple components, they will be installed concurrently. pr#4790
Implicit installation of the active toolchain in rustup-init and rustup invocations has been deprecated where deemed unnecessary and will now produce a warning. pr#4840
- Please see our blog post for more details regarding this change.
rustup doc now supports the --serve flag which allows serving the docs over local HTTP. This should help users with containerized browser and/or rustup setups. pr#4986
Installing i686-pc-windows-* host toolchains on 64-bit Windows now requires --force-non-host. pr#4935
rustup-init will no longer leave unexpected files on disk after cancelled installations. pr#4996
A bug has been fixed which might cause Windows installation to fail when using rustup-init.sh. pr#4756
"Target triple" has been renamed to "target tuple" across the project to reflect the new terminology. pr#4743 pr#4827 pr#4834
- Please note that this is not a breaking change in the CLI since the existing options such as --target are not using this terminology.

In addition, rustup now officially supports aarch64-pc-windows-gnullvm as a host platform. pr#4523

Further details are available in the changelog!

How to update

If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running:

$ rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

$ rustup update

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

Rustup's documentation is also available in the rustup book.

Caveats

Rustup releases can come with problems not caused by rustup itself but just due to having a new release.

In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing rust-docs which contains many small files.

Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release.

Thanks

Thanks again to all the contributors who made this rustup release possible!

Mozilla Open Policy & Advocacy Blog: How Challengers Thrive and Competition Survives In Today’s Ecosystem

Jenn Taylor Hodges — 2026-08-31T18:16:31+00:00

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.

Mozilla Localization (L10N): Minding My Language: My Internship Story

Jamie Hu — 2026-08-31T18:07:31+00:00

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.

The Servo Blog: July in Servo: more platforms, faster canvas, web fonts in SVG, and more!

2026-08-31T00:00:00+00:00

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 SubtleCrypto (@kkoyung, #46402, #46141, #46180, #46583, #46606, #46622, #46334, #46376)
‘insertHorizontalRule’, ‘insertImage’, ‘insertText’, and ‘forwardDelete’ commands in document.execCommand() (@Psychpsyo, #46608, #46597, #46538, #46838)
AnimationEffect (@simonwuelker, #46677)
new Touch() (@yezhizhen, #46741)
duplex property on Request (@Taym95, #46858)
effect property on Animation (@simonwuelker, #46677)
getKeyframes() and setKeyframes() on KeyframeEffect (@simonwuelker, #46118)
id property on LargestContentfulPaint (@shubhamg13, #46828)
read-only CSSFontFeatureValuesRule (@simonwuelker, #46728)

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

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:

You add the monthly update label to your pull request, or comment @servo-highfive monthly update
Highfive posts a comment asking you some questions
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

duckduckgo.com

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

gumroad.com

v0.4.0

v0.5.0

gumroad.com

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

WebGPU content can now enjoy better conformance and use GPUExternalTexture and importExternalTexture() on GPUDevice, under --pref dom_webgpu_enabled (@sagudev, #45873, #46178, #46286).

IndexedDB content can now use the name property on IDBIndex, under --pref dom_indexeddb_enabled (@skyz1, #45512).

document.fonts now includes a FontFace 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 HTMLTrackElement (@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 webkitGetAsEntry() on DataTransferItem, plus minimal support for FileSystemEntry, FileSystemDirectoryEntry, and FileSystemFileEntry, under --pref dom_entries_api_enabled (@yezhizhen, #46456, #46879, #46832).

Embedding API

We’ve improved the docs for the servo crate, and for WebViewDelegate (@mukilan, #46193).

Breaking change: ServoBuilder::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 SVGElement, SVGCircleElement, SVGDefsElement, SVGEllipseElement, SVGLineElement, SVGLinearGradientElement, SVGPathElement, SVGPolygonElement, SVGPolylineElement, SVGRadialGradientElement, SVGStopElement, SVGRectElement, SVGSymbolElement, and SVGUseElement (@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), GamepadEvent (@log101, #46788), document.execCommand(“delete”) (@Psychpsyo, #46539), the selectorText property on CSSStyleRule (@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), IDBDatabase and IDBObjectStore and IDBIndex (@mrobinson, #46615), the adoptedStyleSheets property on ShadowRoot (@simonwuelker, #46738), delete() on FontFaceSet (@simonwuelker, #46634), moveBefore() on Element (@mrobinson, #46599), resizeTo() on Window (@janeoa, #46477), the selected property on HTMLOptionElement (@rhit-kapilaar, #46386), and the value property on HTMLSelectElement (@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 getElementsByClassName() 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)
ArrayBuffer (@jdm, #46504)
adoptedStyleSheets on Document (@TimvdLippe, #46373)
execCommand("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.

7824 USD/month

10000

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

Firefox Tooling Announcements: MozPhab 2.18.0 Released

sheehan — 2026-08-27T18:43:01+00:00

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

Serge Guelton: Pros and Cons of Unified Build

serge-sans-paille — 2026-08-26T22:00:00+00:00

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.

Quality of the Generated Code

Let's create a shared object from algo{0,1}.o (this implies a recompilation with -fPIC of the sources):

% /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

And do the same from unified_algo.o:

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

After stripping, comparing the size of the binaries yield a difference of a few bytes. After disassembling, it turns out the compiler decides to inline the call to void translate(std::vector<std::string>& w, void (&t)(std::string&)) from algo0.cpp when compiling the unified source, something the compiler cannot do when doing split compilation, as it does not know anything about the implementation of that function.

Interestingly, compiling with -flto=thin still lead the compiler instantiation through different optimization path.

Falling back to -flto=full finally yields to the same shared object, which makes sense because Full LTO is very close to performing source unification at the bytecode level and our sources are very simple. It's not a given though because the actual optimisation pipeline is still different in the two scenario.

Why does it matter? Depending on the value of P, the compiler will see different sets of files per unified file, which will result in different binary code. It's actually even worse: depending on the way we fill those unification sets, event with the same parameter P, we end up with different binaries. Let's call that the reunifying problem.

Even if we have an algorithm that seems to guarantee reproducibility, for instance working on a sorted list of files with a fixed P, variation can arise: the introduction of a new source file can lead to changes in every unified file (e.g. if the split is done by chunks and the new file ends up at the beginning of the file list).

So unified builds tend to improve performance, but they do not interact in a gentle way with performance reproducibility.

Recompilation Times

Let's denote S as the number of sources and C as the number of CPUs.

Intuitively, setting P=1 yields to the faster recompilation time when a single file is touched---a usual scenario when developing a new feature.

On the opposite, setting P=S yields to the slower recompilation time (if S >> C!) under the same scenario as all sources are recompiled under that scenario.

The form of the curve between those two extreme varies depending on the nature of the files, and the amount of header sharing between individual sources.

Caching tools like sccache is impacted by the same mechanism: as P gets greater, more cache misses are hit and more recompilation are done.

Marginally, introducing a new source also pollutes the cache or triggers recompilation for the unified source it gets added to, and eventually for all the unified sources derived from the associated file list. The reunifying problem strikes again.

So unified build make compilation faster, but recompilation slower. Setting P to an acceptable value is important depending on the usage scenario.

Correctness

Unified build changing the compilation unit frontier, which in turns modifies the semantic of the program. This change can be straight-forward or complex to debug, and even remain silent. I've listed a few instances of the two first categories below, and a crafted one for the latter category.

Macro / Symbol Redefinition

This one is trivial to spot (a preprocessor-warning is issued for the macro, and a compiler error is issued for the symbol redefinition):

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

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

The solution usually lies in moving the definition in a shared header, moving the declaration in a shared header and the definition in a single file, or renaming identifiers to avoid the name conflict. Note that depending on the solution we may change the visibility of the symbols, or impact code readability (assuming the identifier name was perfectly chosen in the first place).

Overload Conflicts

This one is also trivial to spot and may hint toward debatable design. But it exists and may be more complex to understand than the above:

/* 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);

The fix is generally to provide a perfect match for the overload, change the call site to avoid the ambiguity, or rename the functions/change their namespace to make the call site explicit.

Using Namespace Confusion

This one tends to creep a lot in codebase where using namespace is used. It generates ambiguity among potential symbols.

A caricatured situation is exhibited with the following situation:

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

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

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

Once using{0,1}.cpp unified, the second using namespace a; directive is ambiguous.

A more realistic (but similar in spirit) situation arises when the same symbol is defined in different namespaces:

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

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

The problem with that category is that the fix is quite unsatisfying: there is no way to limit the scope of a using directive, removing using directive can lead to very verbose codebase, renaming symbols to avoid conflicts goes against the very purpose of namespaces...

Delicatessen

I spent a lot of time nailing that one down, so I wrote a small reproducer to illustrate the problem.

% 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"

Let me comment that layout a bit: We basically have two different classes named Lock: one lives in the mozilla::dom namespace, and one lives at top-level. In header1.h, although we include the definition of mozilla::dom::Lock, we also get the definition of ::Lock, so a straight reference to Lock is not ambiguous.

Concerning source files, src0.cpp, src1.cpp and src3.cpp just include headers while src2.cpp contains the infamous using namespace modilla::dom; statement.

Let's now consider various partition of the file list src0.cpp, src1.cpp, src2.cpp, src3.cpp:

% 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

Isn't that amazing? Some intermediate unification, namely 0,1;2,3 and 0;1,2,3 fail, but other unifications, namely 0,1,2,3 and 0;1,2,3 fail. Did you notice that both non-unified and full unified build succeeds, while some intermediate unification fail? What a disaster. This basically mean that given a set of sources, and without putting restriction on the language (like banning using statement), the only way to be sure that a unified build always succeeds whatever the chosen partition is to test every partition. Not very satisfying.

As a side effect, we can also deduce that adding a new source file to a set of files to be unified can break compilation in files that used to compile fine. That's another instance of the reunifying problem.

Changing Semantic

It is quite easy to derive from the above an example whose semantic change once unified. Let's slightly change the overload conflict example from above:

/* 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);

When compiled independently, this results in a binary that prints a 0 and a 1 on the screen. But when compiled as a unified source, we only get a pair of 0.

Concluding Words

Remember that discussion between Luke and Yoda?

LUKE Vader. Is the dark side stronger?

YODA No… no… no. Quicker, easier, more seductive.

That's exactly my thoughts on unified builds: they give you quick wins in term of cold build speed and give faster builds. That's very good properties, and you rip the benefit of them very quickly. Then you realize that you're tied to a monster in terms of maintainability and developer experience, but you're already addict to the speed it gave you.

Mozilla Performance Blog: The Road to Better Performance Profiles – Part 2

Abhishek Nimalan — 2026-08-26T19:28:35+00:00

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:

Start the system profiler.
Run Speedometer 3 on Firefox or Chromium as Release using Raptor and Browsertime.
Stop the system profiler.
Symbolicate the profiles using samply and the corresponding build symbols.
Post-process the symbolicated profiles using profiler-edit (formerly symbolicator-cli) and create compact and labelled variants of the profiles.
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.

This Week In Rust: This Week in Rust 666

TWiR Contributors — 2026-08-26T04:00:00+00:00

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

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

Project/Tooling Updates

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

Observations/Thoughts

Rust Walkthroughs

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.

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.

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

Library

Cargo

Rustdoc

Rustfmt

Clippy

Rust-Analyzer

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

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

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

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:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

The Rust Programming Language Blog: Announcing our first Maintainers in Residence

Lori Lorusso, Jakub Beránek — 2026-08-26T00:00:00+00:00

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.

Firefox Nightly: Icons! Lots of them! – These Weeks in Firefox: Issue 206

Katherine Patenio — 2026-08-25T17:43:36+00:00

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!

Firefox Tooling Announcements: Happy BMO Push Day! (20260824.1)

dkl1 — 2026-08-24T20:29:42+00:00

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

Hacks.Mozilla.Org: Intent to Ship: JPEG XL

Jake Archibald — 2026-08-24T15:32:15+00:00

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.

Jonathan Almeida: SSH access to Github over HTTPS

Jonathan Almeida — 2026-08-24T00:00:00+00:00

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

Claude.

William Lachance: Glean Dictionary + DuckDB

Will Lachance — 2026-08-23T21:11:16+00:00

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.

The Rust Programming Language Blog: Enabling the next-generation trait solver on nightly

lcnr — 2026-08-21T00:00:00+00:00

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.

Tom Ritter: webaudio fingerprinting on alibaba

2026-08-20T19:56:00+00:00

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.

The Mozilla Blog: A New Framework for Open Source AI

Mark Surman — 2026-08-20T15:57:30+00:00

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.

Firefox Add-on Reviews: Extension starter pack

Scott DeVaney — 2026-08-20T01:16:13+00:00

You’ve probably heard about “ad blockers,” “tab managers,” “anti-trackers” or any number of browser customization tools commonly known as extensions. And maybe you’re intrigued to try one, but you’ve never installed an extension before and the whole notion just seems a bit vague.

Let’s demystify extensions.

An extension is simply an app that runs on a browser like Firefox. From serious productivity and privacy enhancing features to fun stuff like changing the way the web looks and feels, extensions give you the power to completely personalize your browsing experience.

Addons.mozilla.org (AMO) is a discovery site that hosts thousands of independently developed Firefox extensions. It’s a vast and eclectic ecosystem of features, so we’ve hand-picked a small collection of great extensions to get you started…

I’ve always wanted an ad blocker!

uBlock Origin

Works beautifully “right out of the box.” Just add it to Firefox and uBlock Origin will automatically start blocking all types of advertising — display ads, banners, video pre-rolls, pop-ups — you name it.

Of course, if you prefer deeper content blocking customization, uBlock Origin allows for fine control as well, like the ability to import your own custom block filters or access a data display that shows how much of a web page was blocked by the extension. More than just an ad blocker, uBlock Origin also effectively thwarts some websites that may be infected with malware.

For more insights about this excellent ad blocker, please see uBlock Origin — everything you need to know about the ad blocker, or to explore even more ad blocker options, check out What’s the best ad blocker for you?

I’m concerned about my privacy and tracking around the web

Privacy Badger

The flagship anti-tracking extension from privacy proponents at the Electronic Frontier Foundation, Privacy Badger is programmed to look for tracking heuristics (i.e. specific actions that indicate someone is trying to track you).

Zero set up required. Just install Privacy Badger and it will automatically search for third-party cookies, HTML5 local storage “supercookies,” canvas fingerprinting, and other sneaky tracking methods.

Consent-O-Matic

Not only will Consent-O-Matic automatically handle pop-up data consent forms (per GDPR regulations), but it’s brilliantly designed to interpret the often intentionally confusing language of consent pop-ups trying to trick you into agreeing to invasive tracking.

Developed by internet privacy researchers at Aarhus University in Denmark who grew sick of seeing so many deceptive consent pop-ups, Consent-O-Matic’s decision-making logic is built upon studying hundreds of pop-ups and identifying duplicitous patterns. So using this extension not only gives you a great ally in the fight against intrusive tracking, but you’re spared the annoyance of constantly clicking consent forms all over the internet.

I need an easier way to translate languages

Simple Translate

Do you do a lot of language translations on the web? If so, it’s a hassle always copying text and navigating away from the page you’re on just to translate a word or phrase. Simple Translate solves this problem by giving you the power to perform translations right there on the page.

Just highlight the text you want translated and right-click to get instant translations in a handy pop-up display, so you never have to leave the page again.

YouTube your way

Enhancer for YouTube

Despite offering dozens of creative customization features, Enhancer for YouTube is easy to grasp and gives you a variety of ways to radically alter YouTube functionality.

Once the extension is installed you’ll find an additional set of controls just beneath YouTube’s video player (you can even select the extension features you want to appear in the control bar).

Key features include…

Customize video player size
Change YouTube’s look with a dark theme
Volume boost
Ad blocking (with ability to allow ads from channels you choose to support)
One-click screenshots
Change playback speed
High-def default video quality

I’m drowning in browser tabs! Send help!

OneTab

You’ve got an overwhelming number of open tabs. You can’t close them. You need them. But you can’t organize them all right now either. You’re too busy. What to do?!

If you have OneTab on Firefox you just click the toolbar button and suddenly all those open tabs become a clean list of text links listed on a single page. Ahhh serenity.

Not only will you create browser breathing room for yourself, but with all those previously open tabs now closed and converted to text links, you’ve also freed up a bunch of CPU and memory, which should improve browser speed and performance.

If you’ve never installed a browser extension before, we hope you found something here that piques your interest to try. To continue exploring ways to personalize Firefox through the power of extensions, please see our collection of 100+ Recommended Extensions.

Firefox Add-on Reviews: YouTube your way — browser extensions put you in charge of your video experience

Scott DeVaney — 2026-08-20T01:10:19+00:00

YouTube wants you to experience YouTube in prescribed ways. But with the right browser extension, you’re free to alter YouTube to taste. Change the way the site looks, behaves, and delivers your favorite videos.

Enhancer for YouTube

With dozens of customization features, Enhancer for YouTube has the power to dramatically reorient the way you watch videos.

While a bunch of customization options may seem overwhelming, Enhancer for YouTube actually makes it very simple to navigate settings and select just your favorite features. You can even choose which of your preferred features will display in the extension’s easy access interface that appears just beneath the video player.

Key features…

Customize video player size
Change YouTube’s look with a dark theme
Volume booster
Ad blocking (with ability to whitelist channels you OK for ads)
Take quick screenshots of videos
Change playback speed
Set default video quality from low to high def
Shortcut configuration

Enhancer for YouTube provides feature controls just beneath the video player.

Return YouTube Dislike

Do you like the Dislike? YouTube removed the display that reveals the number of thumbs-down Dislikes a video has, but with Return YouTube Dislike you can bring back the brutal truth.

“Does exactly what the name suggests. Can’t see myself without this extension. Seriously, bad move on YouTube for removing such a vital tool.”
Firefox user OFG

“i have never smashed 5 stars faster.”
Firefox user 12918016

YouTube High Definition

Though its primary function is to automatically play all YouTube videos in their highest possible resolution, YouTube High Definition has a few other fine features to offer.

In addition to automatic HD, YouTube High Definition can…

Customize video player size
HD support for clips embedded on external sites
Specify your ideal resolution (4k – 144p)
Set a preferred volume level
Also automatically plays the highest quality audio

YouTube NonStop

So simple. So awesome. YouTube NonStop remedies the headache of interrupting your music with that awful “Video paused. Continue watching?” message.

Works on YouTube and YouTube Music. Now you’re free to navigate away from the YouTube tab for as long as you like and never worry about music interruption again.

YouTube Screenshot Button

If you take a lot of screenshots on YouTube, then the aptly titled YouTube Screenshot Button is worth your time.

You’ll find a “Screenshot” button conveniently located on the control panel of videos, or at the top of the screen on Shorts (or you can use custom keystrokes), so it’s always easy to snap a quick shot. Set preferences to automatically download screenshots as JPEG or PNG files.

Unhook: Remove YouTube Recommended Videos & Comments

Instant serenity for YouTube! Unhook strips away unwanted distractions like the promotional sidebar, end-screen suggestions, trending tab, and much more.

More than two dozen customization options make this an essential extension for anyone seeking escape from YouTube rabbit holes. You can even hide notifications and live chat boxes.

“This is the best extension to control YouTube usage, and not let YouTube control you.”
Firefox user Shubham Mandiya

PocketTube

If you subscribe to a lot of YouTube channels PocketTube is a fantastic way to organize all your subscriptions by themed collections.

Group your channel collections by subject, like “Sports,” “Cooking,” “Cat videos,” etc. Other key features include…

Add custom icons to easily identify channel collections
Customize your feed so you just see videos you haven’t watched yet and prioritize videos from certain channels
Integrates seamlessly with YouTube homepage
Sync collections across Firefox/Android/iOS using Google Drive and Chrome Profiler

PocketTube keeps your channel collections neatly tucked away to the side.

AdBlocker for YouTube

It’s not just you who’s noticed a lot more ads lately. Regain control with AdBlocker for YouTube.

The extension very simply and effectively removes both video and display ads from YouTube. Period. Enjoy a faster, more focused YouTube.

SponsorBlock

It’s a terrible experience when you’re enjoying a video or music on YouTube and you’re suddenly interrupted by a blaring ad. SponsorBlock solves this problem in a highly effective and original way.

Leveraging the power of crowd sourced information to locate where — precisely — interruptive sponsored segments appear in videos, SponsorBlock learns where to automatically skip sponsored segments with its ever growing database of videos. You can also participate in the project by reporting sponsored segments whenever you encounter them (it’s easy to report right there on the video page with the extension).

SponsorBlock can also learn to skip non-music portions of music videos and intros/outros, as well. If you’d like a deeper dive of SponsorBlock we profiled its developer and open source project on Mozilla Distilled.

We hope one of these extensions enhances the way you enjoy YouTube. Feel free to explore more great media extensions on addons.mozilla.org.

The Rust Programming Language Blog: Supply chain attack on arrayref

Manish Goregaokar — 2026-08-20T00:00:00+00:00

What happened

On 2026-08-20 at 7:15 UTC we got a report that the proc-macro1 crate was malicious.

The Rust Security Response Team verified this to be the case: the crate had a build script that was downloading a malicious payload.

This crate proc-macro1 and others like it (proc-macro-en, aovine, arone, aronenao, tinymember) have been deleted.

Furthermore, we discovered that the popular arrayref crate had recently been republished and made to depend on this crate, with the most recent versions yanked. We have removed the malicious version and unyanked the maliciously-yanked versions. Other crates by that author (internment, append-only-vec) were also affected so we have done the same for those, and locked the account as a precaution. We do not believe the author of arrayref to be acting maliciously, but their computer or credentials are likely compromised, and we are attempting to contact them.

What you need to do

We recommend you check your local dependencies to ensure these crates were not pulled in. Here are the malicious versions that we deleted from crates.io:

append-only-vec@0.1.9: published at 2026-08-20T07:37:49Z, deleted at 2026-08-20T09:25:24Z. Online for 107 minutes.
arrayref@0.3.10: published at 2026-08-20T07:15:00Z, deleted at 2026-08-20T08:41:40Z. Online for 86 minutes.
internment@0.8.7: published at 2026-08-20T07:34:07Z, deleted at 2026-08-20T09:04:11Z. Online for 90 minutes.
proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember (any versions).

You can quickly check if these crates have been used locally by going through ~/.cargo/registry/cache with this command:

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

Thanks

We'd like to thank the Research Team at Nextron Systems GmbH for initially discovering this and reporting it to us. We'd also like to thank Emily Albini, Manish Goregaokar, Marco Ieni, Tobias Bieniek, Ubiratan Soares, and Walter Pearce for participating in the response here.

The Rust Programming Language Blog: Announcing Rust 1.98.0

The Rust Release Team — 2026-08-20T00:00:00+00:00

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

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

$ rustup update stable

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

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

What's in 1.98.0 stable

Algebraic floating-point methods

The floating-point types f32 and f64 now have "algebraic" methods for addition, subtraction, multiplication, division, and remainder. These allow optimizations on these operations using the algebraic properties of real numbers, even though these properties do not hold with the limitations of floating-point representations. The exact set of optimizations is not specified, but may be similar to the kind of optimization you would see with the -ffast-math option in other languages.

For example, floating-point addition is not associative, so a sum like a + b + c + d must be evaluated in the left-associative order in which it is parsed, like ((a + b) + c) + d. If you write the same sum as a chain of algebraic_add calls, then the compiler is free to reorder it, perhaps like (a + b) + (c + d) to evaluate the partial sums simultaneously. Broader loop-vectorization is often enabled by using these algebraic methods as well.

These methods are non-deterministic, since the compiler is free to choose different optimizations, but they never cause undefined behavior. See the library documentation and the original API change proposal for more details.

Buffered integer formatting

All of the primitive integer types now have a format_into method that takes a &mut NumBuffer<Self> parameter, which is a buffer that is large enough to hold the decimal format of any value of that type. The buffer itself is opaque, but the method returns the formatted &str with a lifetime borrowed from that buffer.

This method also bypasses much of the dynamic dispatch that you would get with buffered write! formatting, which can be a boon to performance. The itoa-benchmark repo now shows that format_into performs similarly to itoa itself, so this could serve as a standard replacement for that dependency and others like it.

Fix interaction between `ManuallyDrop` and `Box`

Prior to Rust 1.96.0, there was a bug in the Rust compiler, which made the following code undefined behavior:

let mut x = ManuallyDrop::new(Box::new(1));
unsafe { ManuallyDrop::drop(&mut x) };
let x = x; // UB!

This is because the compiler considers it undefined behavior to move a Box that has been dropped (deallocated), and ManuallyDrop used to propagate that, such that moving ManuallyDrop<Box<_>> where the box has been dropped would also be considered UB.

In Rust 1.96.0 we fixed this, so this code was no longer UB. In this release we have updated the ManuallyDrop documentation, providing a stable guarantee that this code will continue to not be UB in the future. See ManuallyDrop docs and the related RFC 3336 for more information.

Stabilized APIs

Other changes

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

Contributors to 1.98.0

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

Support.Mozilla.Org: Firefox new release cadence and what to expect

Rizki Kelimutu — 2026-08-19T16:07:01+00:00

Some of you may have heard about this change from the announcement the team shared in early July, but Firefox is moving to a two-week release cycle. The first release on the new cadence is Firefox 155 on September 1, 2026, two weeks earlier than the originally planned September 15 release.

Why this is happening

If you’ve been following recent Firefox releases, you may have noticed that we’ve shipped multiple dot releases for several versions (up to six for Firefox 152). This new release cadence is designed to get bug fixes and completed features into users’ hands sooner, while making the release process more predictable.

It’s important to note that this doesn’t mean Firefox will ship twice as many features. Instead, we’ll be releasing updates more frequently, using a two-week rhythm instead of the current four-week cadence. For contributors, the biggest benefit is predictability: rather than waiting for an unpredictable series of dot releases, we’ll have a more consistent release schedule to plan around.

That said, it doesn’t mean dot releases will disappear entirely. They may still happen when needed, albeit not as often.

Here’s what to expect, how we’re preparing, and how you can help.

What it means for SUMO

Community Forum

On a typical Firefox release, we see an average of 30% increase in incoming support questions during the first 10 days. Under the new two-week release cadence, we expect these waves of questions will arrive more frequently.

The good news is that we’ve observed a consistent pattern after each release. Most questions fall into a handful of common categories, including UI changes (“Where did this go?”), lost data after updating, and crashes. We expect to see the same types of questions, just on a more frequent schedule, which gives us an opportunity to prepare ahead of each release.

Knowledge Base & Localization

A faster release cadence also means a faster content cycle. We expect that content requests will arrive on a more distributed timeline instead of every 4 weeks. But of course, this will also have a downstream impact on localization, as new and updated KB articles become available for translation more frequently. We recognize the additional pressure this could put on localization communities, and we’ll be monitoring the transition closely to make sure we’re mindful of contributor capacity.

Release preparation

We’ll be preparing a release wiki page every two weeks instead of every four. For now, our monthly Community Call will remain on its existing monthly schedule, though we’ll revisit that if the new release cadence creates a need for more frequent community updates.

How we’re preparing and how you can help

Here’s what we’re doing:

Community Forum: We’ll be adding and updating canned responses related to the most common post-release questions, including UI changes, lost data after updating, crashes, and other recurring issues. We’ll also continue to prepare the release wiki before each Firefox release so you’ll know what’s changing and what to expect.
Knowledge Base: The CX team is updating the Bugzilla content request template and collaborating with the product folks to make it easier for them to submit content requests and provide the information needed to create the content. We’ve also introduced a sumo-contributors keyword in Bugzilla to categorize requests that are open for contributors, making them easier to find and track.
Localization: We know the SUMO localization dashboard doesn’t currently have a priority indicator, so please use the release wiki as a guide to identify which content may need attention first. We’ll also explore ways to provide better visibility into upcoming content changes, giving localization communities more time to plan their work around the new release cadence.

Here’s how you can help:

Be extra active during the first 10 days after each release. That’s when we see the biggest wave of support questions, and your contributions have the greatest impact.
Use our common forum responses. They’ll help you reply more quickly and consistently. If you spot opportunities for improvement, please let us know in this thread! Your feedback will help make them even better for future releases.
Get involved in the KB content request process. With content requests arriving more frequently, we’ll need more contributor participation to help create, update, and review support content. Keep an eye on Bugzilla requests tagged with sumo-contributors for opportunities to get involved.
Keep an eye on the release calendar for localization work. Localization work will likely arrive on a more distributed schedule rather than being concentrated every four weeks. Following the release calendar can help you anticipate when new or updated content may be ready for localization. But of course, be sure to contribute at a pace that works for you.

Looking after each other

We also want to acknowledge that contributor burnout is a real risk when the quieter periods between releases become shorter. We’ll be monitoring the transition closely and adjusting as we learn. Most importantly, you should never feel like you have to be “on” all the time. Every contribution, no matter how big or small, makes a difference.

The first major test of this new cadence will likely come with Firefox 157, when Project Nova is expected to roll out more broadly. We’ll treat that release as an opportunity to learn what works, identify where we need to improve, and fine-tune our approach together.

Thank you for everything you do to support Firefox users. This transition is only possible because of our contributor community. If you have any questions, concerns, or ideas, we’d love to hear them. Join our Community Call where we’ll also discuss more about this change.

This Week In Rust: This Week in Rust 665

TWiR Contributors — 2026-08-19T04:00:00+00:00

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

Experiment in reducing target directory size on nightly

Newsletters

The Embedded Rustacean Issue #78

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Research

GPU Offload in Rust: Portable, Safe, and Fast

Miscellaneous

Zerocopy with Joshua Liebow-Feeser

Crate of the Week

This week's crate is tokio_with_wasm, a crate that lets a single tokio codebase run both natively and in web browsers.

Thanks to Kim Dong-Hyun 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.

Cargo

Tracking Issue for -Zembed-metadata

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

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

CFP - Events

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

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

613 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

There were almost no regressions this week, while the next trait solver saw several significant performance improvements!

Triage done by @kobzol. Revision range: 771916f9..8fa1c96c

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.5%]	6
Regressions ❌ (secondary)	0.6%	[0.2%, 1.0%]	17
Improvements ✅ (primary)	-0.5%	[-1.7%, -0.2%]	166
Improvements ✅ (secondary)	-2.3%	[-16.0%, -0.1%]	219
All ❌✅ (primary)	-0.5%	[-1.7%, 0.5%]	172

0 Regressions, 6 Improvements, 7 Mixed; 4 of them in rollups 50 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:

RFC: Refactor the libs team

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

Cargo

Compiler Team (MCPs only)

Expose target_abi = "v8plus" on sparc-unknown-linux-gnu

No Items entered Final Comment Period this week for Rust RFCs, Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

This RFC will appear in the Call for Testing section of the next issue (#) of This Week in Rust (TWiR). You may remove the call-for-testing label. Please feel free to leave the call-for-testing label in place if you would like this RFC to appear again in another issue of TWiR.

Upcoming Events

Rusty Events between 2026-08-19 - 2026-09-16 🦀

Virtual

2026-08-19 | Hybrid (Vancouver, CA) | Vancouver Rust
- Dealing with Dependencies
2026-08-20 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- August, 2026 SRUG (Seattle Rust User Group) Meetup
2026-08-20 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
- Tock OS Part #5 — Wireless Communication with the IEEE 802.15.4 protocol
2026-08-21 | Virtual | Rust Girona
- Sessió setmanal de codificació / Weekly coding session
2026-08-25 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- Fourth Tuesday
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 (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

Africa

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

Asia

2026-08-22 | Bangalore, IN | Rust Bangalore
- August 2026 Rustacean Meetup
2026-08-22 | Delhi, IN | Rust Delhi
- Rust Delhi X SciPy India Meetup
2026-08-22 | Noida, IN | SciPy India
- Scientific Computing in Rust and Python
2026-08-29 | Pune, IN | Rust Pune
- Rust Pune Meetup: August 2026

Europe

2026-08-20 | Berlin, DE | Rust Berlin
- Rust Summer Party!
2026-08-20 | Frankfurt, DE | Rust Rhein-Main
- Building an acoustic camera with egui and embassy
2026-08-21 | Edinburgh, UK | Rust and Friends
- Rust and Friends (daytime coffee)
2026-08-26 | Dresden, DE | Rust Dresden
- Third Meetup
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"

North America

2026-08-19 | Hybrid (Vancouver, CA) | Vancouver Rust
- Dealing with Dependencies
2026-08-19 | San Francisco, CA, US | Bay Area Rust
- Bay Area Rust August Meetup
2026-08-20 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- August, 2026 SRUG (Seattle Rust User Group) Meetup
2026-08-20 | Mountain View, CA, US | Hacker Dojo
- RUST MEETUP at HACKER DOJO
2026-08-20 | New York, NY, US | Rust NYC
- Rust NYC: 'Data Shapes Your Memory' and 'Rust in Peace'
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
- RustConf
2026-09-08 | Montreal, QC, CA | Rust Foundation
- Rust Teams Health Summit
2026-09-08 - 2026-09-11 | Montreal, QC, CA | RustConf 2026
- RustConf 2026, Hosted by the Rust Foundation
2026-09-09 | Montreal, CA | Women in Rust
- RustConf Coffee Break Meetup
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

Oceania

2026-08-27 | Melbourne, AU | Rust Melbourne
- Rust Melbourne August 2026
2026-08-27 | Melbourne, AU | Rust Melbourne
- Rust Melbourne Meetup

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

Jobs

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

Quote of the Week

ass-bind is peak

– Clar Fon on rust-zulip discussion "assumptions on binders" abbreviations

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Firefox Tooling Announcements: MozPhab 2.17.0 Released

sheehan — 2026-08-18T21:16:16+00:00

Bugs resolved in Moz-Phab 2.17.0:

bug 2036748 submit: parallelise per-commit upload + creatediff across the stack
bug 2036749 git: skip restoring git checkout in cleanup/finalize when HEAD already on branch
bug 2060484 " Phabricator Error: Validation errors" should display the revision

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

1 post - 1 participant

Read full topic

Mozilla Open Policy & Advocacy Blog: Brasil dá um passo importante para a promoção de mercados digitais abertos e competitivos

Elise Phillips — 2026-08-18T20:59:10+00:00

Leia a versão em inglês aqui.

A concorrência é o ponto forte da internet. Com a possibilidade de as pessoas escolherem navegadores, mecanismos de pesquisa e aplicativos livremente, a concorrência entre das empresas se baseia no mérito. No entanto, os mercados digitais estão concentrados em “guardiões” que controlam a descoberta, dificultando o alcance de usuários por desenvolvedores independentes. A fiscalização tradicional acabou se tornando ineficaz, normalmente sendo muito tardia. Agora, governos do mundo todo estão adotando novas ferramentas para garantir um mercado aberto e contestável.

O projeto de lei (PL) 4675/2025 é um passo importante nessa direção. Baseando-se na DMA (Digital Markets Act) da União Europeia e na DMCCA (Digital Markets, Competition and Consumers Act) do Reino Unido, esse projeto de lei aborda questões de concorrência sistêmica voltadas à realidade do mercado brasileiro. A Mozilla é a favor dessa legislação, que visa criar uma estrutura segmentada de concorrência para os mercados digitais brasileiros.

A concorrência possibilita produtos melhores e liberdade de escolha

Há vinte anos, a Mozilla desenvolve o Firefox como um navegador independente, priorizando a privacidade, a segurança e a escolha. Operamos no Gecko, um dos três mecanismos de navegador existentes no mundo. A independência é essencial para evitar dominância no mercado e garantir que os usuários tenham liberdade de escolha. A inovação não é suficiente. Os produtos precisam de oportunidades justas de concorrência sem barreiras de pré-instalação ou interoperabilidade.

O PL 4675/2025 trata dessa questão por meio de uma estrutura ex ante, permitindo que a autoridade relevante mitigue os riscos antes de se tornarem irreversíveis. O anteprojeto mais recente contém melhorias importantes dessa estrutura. Ele determina as obrigações de acordo com produtos ou serviços específicos, em vez de aplicá-las automaticamente a todo um grupo corporativo; define proteções processuais durante todo o processo de designação; e traça limites mais claros sobre a capacidade da autoridade de fazer algo as obrigações além daquelas estabelecidas na legislação. De forma mais notável, ele determina uma arquitetura de escolha “isonômica e não discriminatória”, incluindo telas de opções para selecionar, instalar ou definir produtos de terceiros como padrão.

A experiência da Mozilla com telas de escolha de navegador, em conformidade com a DMA da União Europeia, mostra que essas disposições funcionam. O Firefox foi o navegador de escolha mais de seis milhões de vezes. A probabilidade de as pessoas que escolheram o Firefox nessas telas continuarem usando o navegador é cinco vezes maior. Ao tornar a estrutura segmentada e previsível, o PL 4675/2025 estabelece a base para um ecossistema de concorrência em que a inovação impulsiona o sucesso.

Qual é o benefício da concorrência para as pessoas

A política de concorrência defende as pessoas. Mercados abertos permitem a liberdade de escolha e o sucesso de empresas menores. Críticos argumentam que essas propostas prejudicam a inovação, mas nossa experiência sugere o contrário. O Gecko, mecanismo de navegador do Firefox, continua sendo o maior mecanismo não controlado por uma operadora dominante de sistema operacional. Essa independência nos permite priorizar inovações voltadas aos usuários, como proteções avançadas de privacidade e segurança.

Decisões de design, como padrões pré-instalados e barreiras de interoperabilidade, moldam significativamente a experiência de usuários. A pesquisa Over the Edge 2.0 da Mozilla destaca como essas práticas afetam a liberdade de escolha. Startups também se beneficiam, pois podem alcançar usuários e concorrer com base no mérito, em vez de depender de decisões de plataformas dominantes. O projeto de lei brasileiro promove essas condições ao proporcionar ao Cade (Conselho Administrativo de Defesa Econômica) as ferramentas para tratar de práticas anticoncorrenciais, garantindo que a concorrência de plataformas dominantes ocorra por meio de melhoria da qualidade do produto, não por controle da infraestrutura.

De olho no futuro

Os mercados digitais evoluem, mas os princípios de concorrência justa (abertura, liberdade de escolha, interoperabilidade e transparência) continuam iguais. O PL 4675/2025 transforma esses princípios em normas aplicáveis. Seu modelo ex ante segmentado e suas proteções processuais posicionam o Brasil entre os países que visam restaurar o equilíbrio do mercado. Por fim, o sucesso da estrutura será medido por sua capacidade de proporcionar uma mudança significativa para os usuários.

A Mozilla é a favor desse projeto de lei e se dispõe a colaborar com o poder legislativo, o Cade e todas as partes interessadas. Com alterações segmentadas, o PL 4675/2025 pode se tornar uma estrutura duradoura a favor da concorrência, da inovação e da liberdade de escolha.

The post Brasil dá um passo importante para a promoção de mercados digitais abertos e competitivos appeared first on Open Policy & Advocacy.

Mozilla Open Policy & Advocacy Blog: Brazil is Taking an Important Step Toward More Open & Competitive Digital Markets

Elise Phillips — 2026-08-18T20:59:02+00:00

Read the Portuguese version here.

Competition is a strength of the internet. When people freely choose among browsers, search engines, and apps, companies compete on merit. However, digital markets have concentrated around ‘gatekeepers’ that control discovery, making it harder for independent developers to reach users. Traditional enforcement has proven ineffective, often arriving too late. Governments worldwide are now adopting new tools to ensure open, contestable markets.

Brazil’s Bill 4,675/2025 is a critical step in this direction. Drawing lessons from the EU’s Digital Markets Act and the UK’s Digital Markets, Competition and Consumers regime, the bill addresses structural competition concerns with an approach calibrated to Brazil’s market realities. Mozilla strongly supports this legislation, which aims to establish a tailored competition framework for Brazil’s digital markets.

Competition unlocks better products and meaningful choice

For over twenty years, Mozilla has built Firefox as an independent browser prioritizing privacy, security, and choice. We operate on Gecko, one of only three browser engines worldwide. Maintaining independence is critical to preventing market dominance and ensuring users have genuine choices. Innovation alone isn’t enough; products need fair opportunities to compete without being hindered by preinstallation or interoperability barriers.

Bill 4,675 addresses this via an ex ante framework, allowing Brazil’s competition authority to mitigate risks before they become irreversible. The latest draft improves this framework in several important ways. It tailors obligations to specific products and services rather than automatically applying them across an entire corporate group, strengthens procedural safeguards throughout the designation process, and places clearer limits on the authority’s ability to expand obligations beyond those established in legislation. Most notably, it requires “neutral and non-discriminatory” choice architecture, including choice screens, for selecting, installing, or setting third-party products as defaults.

Mozilla’s experience with browser choice screens under the EU Digital Markets Act proves these provisions work. Firefox has been selected more than six million times, and users who select Firefox through these screens are five times more likely to continue using it. By making the framework targeted and predictable, Bill 4,675 establishes a foundation for a competitive ecosystem where innovation drives success.

How competition delivers for people

Competition policy is about people. Open markets provide genuine choice and allow smaller players to thrive. Critics argue these proposals harm innovation, but our experience suggests the opposite. Gecko, Firefox’s browser engine, remains the only major engine not controlled by a dominant OS operator. This independence enables us to prioritize user-focused innovations like advanced privacy and security protections.

Design decisions, like preinstalled defaults and interoperability barriers, significantly shape the user experience. Mozilla’s Over the Edge 2.0 research highlights how these practices undermine choice. Startups similarly benefit when they can reach users and compete on merit rather than relying on dominant platform decisions. Brazil’s bill can foster these conditions by providing CADE with tools to address anti-competitive practices, ensuring dominant platforms compete by improving product quality rather than leveraging infrastructure control.

Looking ahead

Digital markets evolve, but healthy competition principles (openness, choice, interoperability, and transparency) remain constant. Bill 4,675 translates these into enforceable rules. Its tailored ex ante model and procedural safeguards position Brazil among jurisdictions restoring market balance. Ultimately, the framework’s success will be measured by its ability to deliver meaningful change for users.

Mozilla supports this bill and looks forward to collaborating with lawmakers, CADE, and stakeholders. With targeted refinements, Bill 4,675 can become a durable framework that promotes competition, supports innovation, and empowers people with greater choice.

The post Brazil is Taking an Important Step Toward More Open & Competitive Digital Markets appeared first on Open Policy & Advocacy.

The Mozilla Blog: The wait is over. NVIDIA GeForce NOW adds Firefox to its supported browser lineup.

Mozilla — 2026-08-18T14:58:48+00:00

Gamers have asked for GeForce NOW support for years. Today, NVIDIA made it official, opening up GeForce RTX-powered play to Firefox on Windows.

Firefox users can now stream more than 2,000 PC games from virtually anywhere, no downloads, installs, or hardware upgrades required, just a Windows PC and a browser.

Gaming: one of the web’s toughest tests

Cloud gaming pushes a browser in ways most websites never do. Every click and frame matters. Behind today’s announcement is months of collaboration and engineering between Mozilla and NVIDIA to deliver GeForce NOW on Firefox for Windows.

Now, players can jump into high-performance PC gaming directly from Firefox, no waiting on lengthy game downloads, installs, or updates. The experience delivers GeForce RTX-powered performance at up to 1440p and up to 120 frames per second for GeForce NOW Ultimate members.

“Firefox earned its place on our list of supported browsers by delivering the first-class experience GeForce NOW players expect. We set a high bar for browser support, and we’re excited to welcome Firefox — giving millions of Firefox fans a new way to stream the games they love,” said Andrew Fear, Director of NVIDIA GeForce NOW.

Versatility and customization baked into your gaming rig

Gamers put real effort into making their rigs their own, and Firefox gets that. Users can choose themes, custom colors, and tab settings to customize their setup, instead of sitting there like just another window.

We also know online gaming doesn’t happen in just one window. It’s social and sometimes spontaneous. With Firefox, you can have a Discord call running in Split View, a guide open in another tab, or Reddit pulled up between matches. Then go full screen when you’re ready to play, no need to switch browsers to stream games.

“Teaming up with NVIDIA to bring GeForce NOW to Firefox is a milestone moment — one of the world’s leading cloud gaming services, now running on a browser built for privacy, control and flexibility. This is a big win for the Firefox community and for NVIDIA’s gaming community — and a sign of even bigger things ahead,” said Ajit Varma, Head of Firefox.

If Firefox is already your browser of choice, online gaming and your PC game library can join the party. Whether your library lives on Steam, Epic Games Store, GOG, Xbox PC Game Pass, or Ubisoft Connect, you can sign in, open your library, and start streaming the games you already own. For all the gamers returning to Night City in Cyberpunk 2077, jumping into Halo: Campaign Evolved, or dropping in for a quick round of Fortnite, Firefox users can now play where you want.

Try it today

Update to the latest version of Firefox, go to play.geforcenow.com, and sign in with your GeForce NOW account.

Join us August 25 as NVIDIA heads to Gamescom, where we’ll have more to share about what this partnership means for gamers.

The post The wait is over. NVIDIA GeForce NOW adds Firefox to its supported browser lineup. appeared first on The Mozilla Blog.

The Mozilla Blog: A billion searches a year, now built in: Startpage comes to Firefox

Mozilla — 2026-08-18T14:57:52+00:00

Firefox users were choosing Startpage long before today — to the tune of more than a billion searches a year, every one of them required some assembly: an extension, a manual setting, a workaround.

Today, starting with Firefox 154, that choice becomes as easy as head to the drop-down menu, hit ‘select,’ and start searching. Startpage is now a built-in search option for Firefox users on desktop in Germany, France, Austria, Switzerland, and the Netherlands. Android and iOS are coming soon. Whether you want to search with Startpage, or another preferred search engine, it’s as easy as opening your search settings, picking a default, and done.

And if you’re happy with your current search engine, nothing about your setup changes.

Why Europe first

This launch starts in Startpage’s home markets: a Netherlands-based search engine, now built into the browser for some of the most privacy-conscious users in the world. At a moment when so much of the web experience is decided by a handful of very large companies, a search option that’s private by design and European by origin isn’t a small thing.

What Startpage delivers

Startpage delivers full, high-quality search results without the privacy trade off. Queries aren’t stored or linked to you, and there are no AI answers pushed above your search results. In fact, there’s no AI at all. Based in the Netherlands, Startpage built its product around a simple idea: great search and personal privacy can go hand in hand.

“So much of your web experience is prescribed before you ever open a browser. We’d rather you decide how you want to search. Adding Startpage puts a genuinely private search engine option — real results, zero profiling, AI-free — one click away for millions of people in Europe,” said Ajit Varma, Head of Firefox.

Users asked with one billion searches

Startpage ranks among the most-requested search engines in the Firefox community. When demand is this clear, our job is to remove the friction.

“More and more of what people use online comes from a handful of very large companies, and search is where that concentration gets felt most directly. Firefox has always been the browser for people who want to make their own decisions about the web, which makes it a natural home for private search. Firefox users already run over a billion Startpage searches a year. Now Startpage is built in for everyone in these markets,” said Stewart Marlborough, President of Startpage.

That’s the pattern we want: people who use Firefox every day tell us what they need, and we ship it.

Search is a choice. Firefox treats it like one.

Most browsers have already decided how you’re going to search. Firefox hasn’t. Pick your search engine, control what happens to your queries, decide who sees data about you, even turn AI on or off. It should always be your call. Not everyone wants the same thing from search, and a browser shouldn’t pretend they do.

Try it out

If you’re in Germany, France, Austria, Switzerland, or the Netherlands, update to Firefox 154 and you’ll find Startpage in your search settings.

The post A billion searches a year, now built in: Startpage comes to Firefox appeared first on The Mozilla Blog.

The Mozilla Blog: Smart Window: Finish what you start online

Mozilla — 2026-08-18T13:06:06+00:00

Update on September 16, 2026: Smart Window is now rolling out in France, marking its first expansion beyond North America. People in France will be able to download and try the Smart Window beta in French. Download Smart Window here and share your feedback with us on Mozilla Connect.

Original post from August 2026:

Browsers make it easy to start things, but picking them back up is another story.

We start planning a trip or researching a purchase, and before long we’re comparing options and chasing ideas across dozens of tabs. That work rarely happens in one sitting. When we come back after an interruption, we have to figure out where we were, what we’d already found, and what we were trying to do in the first place.

Smart Window is Firefox’s privacy-first, AI-powered browsing experience designed to help people finish what they start online. It works with the context you choose to share, such as your open tabs and relevant browsing history, so you can get back to what you were doing without retracing your steps.

We’ve spent the last several months building and testing Smart Window in beta with our community. Today, we’re adding new capabilities that help you check answers without losing your place, make sense of open tabs and get back to things you’ve seen before. Together, they help keep a task moving across tabs, searches, and time.

“The browser already has much of the context around what you’re trying to do — the research in your tabs, the pages you’ve visited, the things you’ve found along the way,” said Ajit Varma, Head of Firefox. “With Smart Window, we’re exploring how to make more of that context useful while keeping you in control.”

What’s new in Smart Window

Check answers without losing your place

When you have a question in the middle of a task, getting an answer shouldn’t take you out of your flow or require you to track down the sources separately.

Through our new partnership with Exa, Smart Window can now retrieve current web information and show the sources behind its response without taking you to a separate search results page. Learn more about why we chose Exa and what the partnership means for Firefox in our companion post.

Group tabs that belong together

It doesn’t take long for a quick search to turn into a browser full of tabs. Once they pile up, keeping track of everything becomes even more work.

Smart Window can now suggest groups for related tabs, making it easier to organize what you have open and return to it later. It can also spot duplicate tabs and close them with a click.

Find your spot again

Sometimes you remember what was on a page better than you remember what it was called or how you got there. Smart Window can now show visual previews of pages in your browsing history, making it easier to spot the page you’re looking for among similar results without opening each one to figure out which is which.

Behind the evolution

Last November, we shared an early concept called “AI Window,” exploring what it could look like to give people a user-controlled space where they could chat with an AI assistant to get help while browsing. We shared it early because we wanted our community to help shape where it went next.

Over the months that followed, we watched how people used the experience, listened to feedback, and tested new ideas. A consistent theme emerged: people were increasingly using it as part of their everyday browsing — searching, navigating, and working through the things they’d come online to do. The value of the AI assistant came through in how it helped them make progress on those tasks.

We saw the same idea in feedback from beta users. One described using Smart Window to keep track of their “train of thought.” Another used it to find something they’d looked at before without remembering exactly where they’d seen it.

Those learnings helped us shape Smart Window into a broader browsing experience that helps people make progress on what they came online to do.

While the product is evolving, the principles we started with remain the same: choice, privacy, and transparency. Smart Window is optional. You choose when to use it, what browsing context it can use to help with a task, and which AI model you want to use. Firefox’s AI Controls gives you one place to manage Smart Window, including turning it off entirely, so you can easily choose the browsing experience you want.

What’s next

We’re continuing to explore ways Smart Window can help carry a task forward, especially when you leave it and come back later.

Soon, Smart Window will be able to surface recent browsing journeys and pull together related tabs and history, giving you a starting point when you return to something you were working on. We’re also working on ways for Smart Window to use relevant information to help fill out online forms, so you don’t have to re-enter the same details again and again. You’ll stay in control of what Smart Window can access, including which tabs you choose to share with it.

Smart Window remains in beta, and we’ll keep learning from our community as these experiences develop. It’s currently available in English to people in the U.S. and Canada. If it’s not available where you are yet, you can sign up to be notified when it is.

To try Smart Window, visit https://www.firefox.com/smart-window.

The post Smart Window: Finish what you start online appeared first on The Mozilla Blog.

The Mozilla Blog: Firefox and Exa: Building AI search around people, not platforms

Mozilla — 2026-08-18T13:05:34+00:00

AI has changed how we browse. Full stop. The real question is whether AI leads to one browser experience for everyone, or gives people more ways to make the browser work for them.

Firefox was always built to give users an alternative to the status quo, and our approach with AI is no different. Much of the industry is going in another direction: Company A builds the browser → and the search engine → and the AI model → and all the surrounding services. The seduction lies in how effortless every layer feels, but it also means one company has total influence over what tech you can use and what AI delivers.

We aim to deliver users a different model: one where AI makes your browser empowering and helpful, with visible citations and with a zero-data-retention commitment, all powered by an independent browser engine. To get there, we’re partnering with people who align with the same open, choice-first thinking that’s shaped Firefox from day one.

Today, that starts with Exa.ai, a search and retrieval company built for the AI era.

Going forward, Exa will help power Smart Window on desktop and Quick Answers on iOS, giving people a way to get current, source-backed answers without leaving the page. More on our related Smart Window announcement here.

But our Exa news isn’t about one feature or product. It’s about model choice and how people find things online.

An independent AI model

Mozilla has always believed the web is strongest when it encourages technology competition and variety, and we think the same principle should apply to AI. We want to create an AI ecosystem that is open, diverse, and grounded in the same values we champion for the web. So, instead of building our own closed AI stack, Firefox is investing in partnerships with companies like Exa.ai to bring deep expertise in specific areas while sharing our commitment to user choice, privacy, and transparency.

As Ajit Varma, Head of Firefox, puts it, “Firefox’s philosophy is straightforward: the open internet is a critical resource and people should be able to shape it to their needs and preferences — even as new entry points like AI emerge. AI should be responsible. It should stay transparent and under your control. AI shouldn’t be an-all-or nothing offering, but rather built so users can pick and choose the model or system that works for them.”

The idea is simple: Mozilla builds the browser people trust, and partners like Exa.ai bring the specialized pieces that make it better. That lets us move faster without asking people to give up what made Firefox different in the first place.

Adds Will Bryk, Co-founder and CEO of Exa.ai, “Search built for the AI era doesn’t work if it’s locked inside one company’s stack. Firefox is one of the last browsers that isn’t trying to own the model, the search, and the browser all at once. That’s why this partnership makes sense to us. We’re building the information layer for an agentic web, where trust and transparency are paramount. We share those values with Firefox, making this partnership a very easy call.”

AI should make the web more useful, not replace it

AI is only as useful as your ability to check its work.

That’s the point of building Exa’s retrieval into Firefox: when you get an answer, you can see the source it came from. Nothing is buried in a ‘citations’ menu, but sitting right there so a two-second glance tells you whether to trust it or read more. We’re not forcing you ‘just trust us’ that it’s right.

It’s a small design choice, but it matters. It’s the difference between an AI that tells you things and one that shows you where to look. It also means the people who actually wrote that content don’t disappear from the picture, the way they often do when AI summarizes and moves on.

Looking ahead

This won’t be the last partnership like it. We’re picking partners for the same reason each time: people who think AI in a browser should work for you, not the other way around.

The post Firefox and Exa: Building AI search around people, not platforms appeared first on The Mozilla Blog.

Firefox Developer Experience: Firefox WebDriver Newsletter 154

Alexandra Borovova — 2026-08-18T10:00:32+00:00

This newsletter gives an overview of the work we’ve done as part of the Firefox 154 release cycle.

Contributions

Firefox 154, one WebDriver bug was fixed by a contributor:

Devin Rousso updated the emulation.setLocaleOverride command to allow overriding the Accept-Language header for fetch and WebSocket requests in workers.

All Changes

A complete list of developer-facing changes included in this Firefox release is available in the MDN Firefox 154 Release Notes.

Firefox Tooling Announcements: MozPhab 2.16.0 and 2.16.1 Released

sheehan — 2026-08-18T03:18:29+00:00

Bugs resolved in Moz-Phab 2.16.1:

bug 2063077 Run tests in parallel with pytest-xdist
bug 2063810 Obscure error installing MozPhab

Bugs resolved in Moz-Phab 2.16.0:

bug 2050987 moz-phab self-update fails when installed via uv tool: “No module named pip”

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

1 post - 1 participant

Read full topic

Andreas Farre: Tracing algorithms through web specifications

2026-08-17T00:00:00+00:00

A bug comes in, or someone shows me a page doing something surprising, and the question is always the same one. Is that what the spec says? Not what we all assume it says, and not what Gecko happens to do, but what the algorithm actually does when you follow it step by step. So I open html.spec.whatwg.org, find the entry point, and start reading. Twenty tabs later I have usually lost the thread.

This isn’t an occasional chore. I do it when I’m implementing something new, when I’m working out whether a Gecko bug is a bug in Gecko or a bug in the spec, when I’m reviewing a spec change someone else has proposed, and when I’m trying to design something that has to fit alongside everything that already exists. Four fairly different jobs, and every one of them comes down to the same mechanical work. Start at an algorithm, follow the calls, keep track of where you’ve been.

The specs are built for exactly this, in principle. Every step that invokes another algorithm is a hyperlink, and the whole thing is one large call graph spread across HTML, DOM, Fetch, URL and Infra. The trouble is that walking that graph by hand is slow, and it’s the kind of slow a machine should be doing on your behalf.

Two tools have changed how I do this. One answers questions about the graph, and the other helps me walk it. If you’d rather install them first and read afterwards, they’re both at the end.

webspec-index trace

webspec-index is Jan Jaeschke’s tool for querying web specifications from the command line. It indexes the specs, on demand as it needs them, and lets you ask about definitions, references and IDL. In August it gained a trace subcommand, and that’s the one I keep reaching for.

You give it two anchors and it finds the routes between them. It answers in JSON by default, which is the right choice for feeding it into something else but not for reading, so add --format markdown when the audience is you. Say I want to know how a navigation can end up firing navigateerror:

$ webspec-index trace HTML#navigate HTML#event-navigateerror \
    --format markdown

# trace: `HTML#navigate` -> `HTML#event-navigateerror`

Max depth 6, kind `step`. Found 11 trace(s).

## Trace 1 (5 hop(s))

1) [`HTML#navigate` step 20](…#beginning-navigation:set-the-ongoing-navigation)
   calls `HTML#set-the-ongoing-navigation`
   > Set the ongoing navigation for navigable to navigationId.

2) [`HTML#set-the-ongoing-navigation` step 2](…#aborting-navigation:inform-the-…)
   calls `HTML#inform-the-navigation-api-about-aborting-navigation`
   > Inform the navigation API about aborting navigation given navigable.

3) [`HTML#inform-the-navigation-api-…` step 3.1](…#ongoing-navigation-tracking:…)
   calls `HTML#abort-the-ongoing-navigation`
   - under: While navigation's ongoing navigate event is not null:
   > Abort the ongoing navigation given navigation.

4) [`HTML#abort-the-ongoing-navigation` step 7](…#ongoing-navigation-tracking:…)
   calls `HTML#abort-a-navigateevent`
   > Abort event given error.

5) `HTML#abort-a-navigateevent` step 6 calls `HTML#event-navigateerror`
   > Fire an event named navigateerror at navigation using ErrorEvent, with
     additional attributes initialized according to errorInfo.

I’ve wrapped those lines and shortened the URLs to fit; in the real output each hop is one long line and every link is a full deep link to that exact call site.

Every hop names the exact step number, quotes the step text, and tells you the condition it sits under. That last part matters more than it looks. Step 3.1 only runs while the ongoing navigate event is non-null, and knowing that is the difference between a path that exists on paper and a path your case actually took.

Eleven routes, though¹. Reading eleven of these back to back is not much better than the twenty tabs.

Three zoom levels

This is where webspec-index trace gets genuinely nice, and it’s the part I want to draw attention to, because it’s easy to miss in the help text. The --detail flag changes how much of each route you get, and the three levels turn out to be three different ways of working rather than just three verbosity settings.

Ask the same question again with --detail edges and the prose falls away, leaving the skeleton:

$ webspec-index trace HTML#navigate HTML#event-navigateerror \
    --detail edges --format markdown

# trace: `HTML#navigate` -> `HTML#event-navigateerror`

Max depth 6, kind `step`. Found 11 trace(s).

## Trace 1 (5 hop(s))

1) `HTML#navigate` step 20 calls `HTML#set-the-ongoing-navigation`

2) `HTML#set-the-ongoing-navigation` step 2 calls `HTML#inform-the-navigation-api-about-aborting-navigation`

3) `HTML#inform-the-navigation-api-about-aborting-navigation` step 3.1 calls `HTML#abort-the-ongoing-navigation`

4) `HTML#abort-the-ongoing-navigation` step 7 calls `HTML#abort-a-navigateevent`

5) `HTML#abort-a-navigateevent` step 6 calls `HTML#event-navigateerror`

## Trace 2 (5 hop(s))

1) `HTML#navigate` step 22.4 calls `HTML#fire-a-push/replace/reload-navigate-event`

2) `HTML#fire-a-push/replace/reload-navigate-event` step 2 calls `HTML#inform-the-navigation-api-about-aborting-navigation`

...

Now you can read all eleven at once, and a shape appears that I could not see in the verbose output at all. There are five places inside navigate where a route starts:

step	calls
15.1	`#navigate-fragid`
20	`#set-the-ongoing-navigation`
21.1	`#navigate-to-a-javascript:-url`
22.4	`#fire-a-push/replace/reload-navigate-event`
24.1	`#checking-if-unloading-is-canceled`

And all eleven finish on the same line:

`HTML#abort-a-navigateevent` step 6 calls `HTML#event-navigateerror`

There are exactly two ways into that step, from HTML#abort-the-ongoing-navigation step 7 and from HTML#process-navigate-event-handler-failure step 5. Eleven routes exist because three of the five entry points re-enter the same navigate event firing machinery from different directions, not because there are eleven genuinely different things going on.

That’s a useful thing to know before you start debugging. If a navigation is firing navigateerror and you want to find out why, you don’t instrument eleven places. You instrument the one step they all pass through and work backwards from there.

So the way I use it now is to start at --detail edges to find the shape, then drop back to the default once I know which route I care about and want to read the reasoning. The third level, --detail compact, drops the prose but keeps every anchor as a deep link to the exact call site, which is the form you want when you’re pasting a route into a bug report for someone else to follow.

WebSpec Tracer

webspec-index trace answers a specific kind of question, and it’s worth being precise about which kind. You have to know both ends. That’s fine when you’re asking whether one thing can reach another, but a lot of the time I only know where I’m standing. I have a starting point, a bug in front of me, and no idea yet where the algorithm goes.

There’s also something webspec-index trace can’t do for you in principle. It finds routes through the spec text, statically. It doesn’t know which branch your case took, because that depends on what actually happened at runtime, and only you have that information.

So I wrote WebSpec Tracer, a Firefox extension that walks the specs with you rather than ahead of you. You give it a starting anchor and it shows you that algorithm with every linked term highlighted. Click one and it becomes the next hop in the trace, and the panel moves you into it. Click the wrong one and Back undoes it.

The screenshot is a walk that started at location.assign and has arrived inside navigate. Step 15 is the interesting one. It runs only if four things are all true, that there’s no document resource, no response, the URL matches the current entry’s URL ignoring fragments, and the fragment is non-null. If all four hold, it navigates to a fragment and returns. Otherwise the algorithm keeps going into the full navigation path below.

No tool can decide that for me. Whether my bug went left or right at step 15 depends on the page and on what the user did. But the extension puts the decision in front of me with the alternatives visible, which is precisely what I was failing to do for myself with twenty tabs open.

The trace builds up in the panel underneath as markdown, with every anchor pointing at the exact call site. That box is a display rather than a text field, so there are buttons for getting the trace out of it. Copy does what you’d expect. Insert is the one I actually use, and it’s the reason the extension lives in the sidebar: it writes the markdown straight into whichever field you have focused on the page, so you can have a spec issue open next to the panel and drop the trace into it without going near the clipboard. Reset clears everything and starts over.

Switch the issue over to Preview and there are the same two hops, rendered, each one a link into the spec. That’s most of the reason I built the thing. Explaining a route through an algorithm in prose is miserable, and the version you retype by hand is always slightly wrong. This way what I hand over is exactly what I walked.

One more thing worth knowing, about the anchors themselves. The starting one has to say which spec it’s in, so HTML#dom-location-assign rather than just dom-location-assign, but after that the extension works it out as it goes. Anything that turns up in the trace without a prefix is in the spec you started from, and a prefix appears when the trace crosses a boundary:

That’s the same walk carried a few hops further. Hop 3 is that step 15 decision, taken, and the last line is WEBIDL#wait-for-all. Somewhere in the navigate event firing the trace left HTML entirely, and the prefix is the only thing that tells me so. The panel on the left has stopped showing me HTML too, and is now sitting in WebIDL. That’s easy to lose track of when you’re clicking through by hand, and it’s usually the moment a question stops being about HTML and starts being about something else.

When one call happens twelve times

Sometimes an algorithm invokes another one from many different places, and a trace has to say something sensible about that. This was in the design from the start, and the answer it arrived at is to do what the spec already does. Start at HTML#update-the-image-data and follow it to HTML#abort-the-image-request:

HTML#abort-the-image-request is invoked from twelve separate places inside HTML#update-the-image-data. The extension doesn’t make me choose one, and it doesn’t flatten them into a single link either. It records the hop once and hangs all twelve call sites off it as numbered links, so the line reads #update-the-image-data calls #abort-the-image-request, [2], [3] and onwards to [12], each number pointing at its own anchor.

The numbering isn’t invented. It’s the spec’s own scheme for repeated references: the anchors run #abort-the-image-request, then -2, -3, and so on up to -12. All the trace does is carry that through, so a hop in the output identifies call sites the same way the spec identifies them, and the numbers mean the same thing in both places.

That also keeps the trace honest. The hop happened, and that’s true whichever of the twelve fired, but the fact that there are twelve is worth knowing on its own, and anyone reading can go and check any one of them. Writing this out by hand you would link the first and lose the other eleven without ever noticing. The same thing is visible in the previous screenshot, where hop 3 reads #navigate calls #navigate-fragid, [2], [3].

webspec-index trace deals with the same situation the other way round. Ask it the same question and you get twelve separate one hop traces, each naming its own step number, step 2, then 7.4.2, then 11.1, and so on down the algorithm. Neither is wrong. The command line is telling you which steps, and the extension is keeping your trace to one line while preserving every place it could have come from.

Which one, when

They divide up cleanly enough that I don’t think about it much any more. If I know both ends and want to know what’s between them, or how many different routes there are, that’s webspec-index trace. If I know where I’m starting and want to find out where it goes, that’s the extension.

The one I underused at first was --detail edges. Asking a broad question and then zooming out far enough to see the answer’s shape is a different move from following a single path carefully, and it’s the one that has surprised me most often, usually by showing me that several things I thought were separate all funnel through the same step.

Getting them

webspec-index is on crates.io:

cargo binstall webspec-index

It builds its index as it goes, so the first trace into a corner you haven’t visited before pauses briefly to fetch and index the specs the route touches. After that it’s fast.

WebSpec Tracer is on addons.mozilla.org, and the source is on GitHub. It lives in the sidebar, toggled with Ctrl+Shift+U, so you can keep it open next to whatever you’re reading.

Both are worth a try if you spend any time at all reading specs, whether you’re implementing them, arguing with them, or just trying to find out whether the browser is wrong or you are.

Notes

Eleven is what you get at the default maximum depth of six hops. Raise it and there are more. ↩

William Lachance: Writing the Docs: 2026 Edition

Will Lachance — 2026-08-16T22:15:29+00:00

It's been about 5 years since I was working heavily on documentation and metadata at Mozilla. I wrote a bunch about this at the time:

A principled reorganization of docs.telemetry.mozilla.org (May 2020)
Mozilla Telemetry in 2020: From “Just Firefox” to a “Galaxy of Data” (July 2020)
The Glean Dictionary (January 2021).

I don't think I ever wrote about it explicitly, but in the background I (along with a few others at Mozilla Data) were digging deep into "proposal culture" and how to collaboratively build software together using design documentation.

Thinking hard about knowledge systems is a somewhat idiosyncratic obsession, and something I emphasize a little less day-to-day now. That said, I still think that putting effort into organizing information and making it legible both leads to better workplaces and makes us generally more productive. Fundamentally, it’s an act of care both to yourself and your peers, past and present.

Moreover, the core points I was trying to make at the time (either in what I wrote or what I did) mostly still hold:

Separate the "what" from the "how"
Reference documentation should derive from ground truth
Document your decisions and process
Continuous improvement

As a sort of retrospective, I'd like to revisit these principles 5 years on, with special attention to how they relate to large language models (LLMs).

I’m going to talk about Mozilla a lot because it’s all on the public record and I can talk about it relatively freely. I haven’t really been involved in the community or watching closely what’s been happening there since I left in January 2022. Likely the internal perspective at Mozilla these days is different from my own (hopefully not that different 😂).

Separate the what from the how

This is what I talked about in A principled reorganization of docs.telemetry.mozilla.org. While I wasn’t aware of it at the time, I was basically repeating the principles of the diataxis framework. Since then, diataxis has become my go-to for describing good documentation, because it's so well written and explained.^[1]

diataxis breaks documentation down into four categories:

Tutorials: How to do a basic task, step by step: intended for beginners
Explanation: Longer documents describing the "why": intended for all
How-to: How to accomplish a specific task: intended for non-beginners
Reference: Ground truth establishing the "what": intended for all

I think this framework holds up really well, and it’s still the first thing I reach for when thinking about (or explaining) how to write something. Although diataxis was never fully applied, docs.telemetry.mozilla.org became a more useful site for data practitioners after I emphasized tutorials and "getting started" docs, and put the reference and deeper dives later on. It was pretty frequent that I'd be able to answer a question on our internal slack channel and be able to quote a step-by-step link from the docs describing exactly what someone needed to do or know.

My one quibble with diataxis is that sometimes for a complex task you need to mix the different types of documentation. Visualizing Percentiles of a Main Ping Exponential Histogram was written as a very long and sprawling mix of explanation with theory (even the name is a mouthful), but I think that’s one of its strengths? I got repeated feedback that it was extremely helpful by the Firefox engineers. I can't be totally certain it still holds up today, but I'm fairly certain it does. At the very least, no one has felt motivated to take it down.

Do LLMs change anything here? I would argue no. Although some of the things we want to do now are different (and still changing as of this writing), each has proven useful in its own way.

Tutorials and explanations are the easiest case to make: they are meant for general sense making, and the need for that hasn't gone away at all. Indeed I think as we delegate more of the day-to-day work to machines and reduce the amount of hands-on work which generates understanding, our need for these aids has only increased. I occasionally use LLMs to create initial drafts of this type of work and it’s interesting to see what they miss or get wrong: often some vital fact or nuance is not there, and they have a tendency to emphasize incidental details.

One thing that many people find surprising about tutorials is that they were actually never really meant to describe how to do something. Instead, the purpose is primarily just to give some hands-on experience and feeling of success, so they can start feeling more confident in going deeper and doing the more advanced tasks where explanation, how-to, and reference become more important. This need to gain a preliminary understanding of the system has not gone away at all with LLMs-- I maintain that hands-on learning and action is still the best way for most people to learn anything, including how to work with computational systems. Once you've gone beyond the basics, any gaps in understanding or context can be filled in by absorbing the content of deeper articles describing the concepts of a system and why it is the way it is.

Howto documentation (sometimes also called cookbooks or runbooks) are an interesting case, as I feel like this is where things have simultaneously changed the most and the least. Back in the day, I felt that most human written documentation should be exactly this type of thing: it was the most broadly useful and tended to age much better than explanation or reference material that would frequently go out of date. Being able to answer a slack question with a link to this type of material was always satisfying.

Of course now, often it's a large language model or similar executing these types of tasks. Early in 2026, the hot topic was creating Agent Skills which are, at heart, just little markdown docs named SKILL.md which describe how to perform a particular task. I think they are entirely complementary to the approach. You write a detailed howto describing how to perform a task (using Mozilla data as an example, query a table in BigQuery). An LLM can process a well-written markdown file just as easily as a human: just create an appropriate skill file saying as such:

---  
name: query-main-ping-telemetry-table*  
description: Query the main ping telemetry table in Bigquery*  
---

Refer to `docs/howtos/query-telemetry-table-in-bigquery.md`

I'm often surprised at how quickly modern large language models can figure out how to do something essentially from first principles, but if you've arrived at a good solution already, why bother doing that? Just give them a cookbook and save the time and the tokens. And if you need to debug what it's doing (or do part of it yourself), the exact set of steps is right there.

Reference documentation deserves its own treatment. More on it in the next section.

Reference documentation should derive from ground truth

In Mozilla Telemetry in 2020: From “Just Firefox” to a “Galaxy of Data” I talked about how Mozilla's data could no longer reasonably be explained with a few hand-written articles:

Up until now, our defacto answer has been some combination of “Use the probe dictionary / telemetry.mozilla.org” and/or “refer to docs.telemetry.mozilla.org”. I submit that we’re at the point where these approaches break down: as mentioned above, there are many more types of data we now need to care about than just “probes” (or “metrics”, in Glean-parlance). When we just cared about the main ping, we could write dataset documentation for its recommended access point (main_summary) and the raw number of derived datasets was manageable. But in this new world, where we have N applications times M ping types, the number of canonical ping tables are now so many that documenting them all on docs.telemetry.mozilla.org no longer makes sense.

I was already thinking about the Glean Dictionary and trying to justify working on it to my peers and upper management. In retrospect, this claim is self-evident: if you're dealing with hundreds or thousands of entities (or more), a manual approach to writing the documentation just isn't going to work. Even if you can generate a perfect first draft, you've only postponed the problem: the implementation will change, and independently maintained reference documentation will drift from it.

The solution is to make your reference documentation derive from the actual truth of the thing that you're trying to document. This means some kind of machine readable representation: the source code, metrics definitions, dataset definitions, or similar. Critically, the reference documentation should directly link back to that original source, so you can verify (and examine) where these ground truth assertions are coming from. This is why the Glean Dictionary included a link back to the original schema or artifact which generated the documentation:

https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/metrics/a11y_always_underline_links

This is a pretty old idea, dating back to Sphinx’s autodoc and doxygen, although it hasn’t been super consistently applied in modern data engineering from 2020 to 2022 or so. These days, we tend to emphasize getting to an answer (“How many users did XYZ?”) over how the answer was derived. Mozilla was a bit of an exception in that it had (hopefully still has) a lot of curious engineers who really did care about these details.

When using an LLM, I feel like this type of ground truth is more critical than ever. Much has been written about the tendency of large language models to hallucinate. Conclusions drawn from inaccurate source data can compound, leading to yet more confusion and problems that only get caught at review time (if you're lucky). Having a clear statement of the system-as-it-currently-is (with citations) is the best defense against that. Not only does it reduce the chance of hallucination or confabulation, but it gives a human operator the chance to check the reference and see if it makes sense.

What was maybe a little more controversial (and possibly still is), was my conviction that writing a custom website was the right answer. The world is awash in SaaS companies offering to make sense of a data schema, service architecture, what have you-- why not just use those? At the time I wrote that article, we were considering Google's data catalog and I had to justify why creating a new thing wasn’t Not Invented Here:

A few months ago, I thought that Google’s Data Catalog (billed as offering “a unified view of all your datasets”) might provide a solution, but on further examination it only solves part of the problem: it provides only a view on your BigQuery tables and it isn’t designed to provide detailed information on the domain objects we care about (products, pings, measures, and tools). You can map some of the properties from these objects onto the tables (e.g. adding a probe’s description field to the column representing it in the BigQuery table), but Data Catalog's interface to surfacing and filtering through this information is rather slow and clumsy and requires detailed knowledge of how these higher level concepts relate to BigQuery primitives.

I haven't looked at Google's Data Catalog (or whatever it’s called now) since then, but I suspect that although it’s probably a great schema viewer, it's still going to be just as confusing for someone who doesn’t work as a data engineer day to day.

It's just inherent: unless your product is a database, the domain of a generic data catalog (schemas, tables) is going to be inherently different than that of your business. This is true whether what you care about is the experience of Firefox users or dispatching taxi cabs. Forcing a data user to think in terms of the former is to move them away from asking actual product questions.

The same really goes for any other "data catalog" SaaS product: in order to work across industries, it needs to express a bunch of concepts which are going to be foreign to your domain. If you're going to go to the trouble of mapping your own concepts and systems to the model of a product like this (which is honestly 90% of the effort, in my experience), putting in a little bit of extra effort to produce a custom interface or website might actually be the missing piece to make that work maximally impactful. This is even easier today thanks to large language models and generally evolving technology and practices.

One area where I do think there is still room for development and growth is infrastructure to create these custom tools and data representations. Partly based on my experiences with the Glean Dictionary (and associated tools like probe-scraper and mozilla-schema-generator), I've been working on a new framework called repo-parser which formalizes this concept of extracting this “ground truth”.

Given a git repository and a set of rules (e.g. “convert this set of markdown frontmatter into a set of tags”), it can take a forest of markdown, yaml, and json and produce either a duckdb database or an in-memory representation of the repository’s content. You can use this to populate a data catalog (like the Glean Dictionary), create a dedicated documentation site or any number of other things.

repo-parser’s example site is a mundane example of this. The content in the screenshot is produced from a README.md inside the repository, collected and organized dynamically at build-time:

I'm not certain if repo-parser is exactly the right abstraction for building something like this, or if it's more like an architectural design pattern where every implementation is bespoke. Time will tell.

Proposals, architectural decision records

Ground truth can tell us what, but doesn’t say much about why. When I introduced the afore-mentioned dictionary product in The Glean Dictionary, embedded within was a link to a Google docs proposal.

This was part of a larger movement towards "design docs" that myself and a few of my coworkers were pushing at the time. The idea was, before embarking on a large piece of work, you would write and circulate a large Google Doc containing a problem statement, goals, non-goals, and a preliminary expression of what you were trying to solve and alternatives considered. Then, discussion could proceed asynchronously over docs comments.

I didn't really write a lot about them because (I think) my coworkers wrote and presented on them extremely effectively and I was more interested in, well, the above. But I think they're just as valuable a kind of writing, they answer so many important product and engineering questions:

Why this design?
Why now? (or why then, if looking at the proposal retroactively)
How does this impact security, reliability, ... ?
What comes next?

I still think proposals are extremely valuable. The obvious benefit is they allow us to reject or modify sub-optimal designs before too much effort is spent building and/or supporting them. But just as importantly, they allow us to distribute understanding of what is being built and why across teams.^[2] In software engineering, it’s one of the best ways I’ve found to align a diverse group of human beings around a single objective.

This wisdom was pretty old even then: the influential article on Design Docs at Google dates all the way back to 2015, best I can tell. There are other precursors -- for example, Painless Functional Specifications by Joel Spolsky way back from the year 2000. I'm sure you can find articles about this all the back to the 70s, or even earlier if you look hard enough. However, I've noticed that many organizations struggle to have a good proposal culture. If the ideas are so obvious, why?

Some issues go well beyond the scope of this article: I do think that having an effective proposal requires a strong commitment to psychological safety. If people don't feel like their design or feedback is going to be taken in good faith, the proposal process won't work very well. People will be hesitant to put things out there and to engage, and the opportunity for learning will be reduced. In a healthy workplace, people are constantly being guided towards presenting their best ideas, with the knowledge that their colleagues are there to support them.

Looking at how large language models have affected things, I have two answers: "almost not at all" and “totally".

For the traditional "big google doc" type proposals I talk about above, I lean towards thinking that these should continue to be used (more or less) the way they were before: as a means for human beings to align on the right solution to a problem. A large language model can help with the initial brainstorming producing the first draft, but to be maximally effective both the initial communication and response should be the product of human interaction. That ensures that the proposal is an expression of a fully fleshed out train of thought and represents real effort. Likewise, the responses to it represent a real attempt to engage with and learn from the content.

On the other hand, I think for our day-to-day where the implementation is largely produced by a large language model, I have found the above formula useful in an unexpected way: as a way to converse and convey requirements to a machine.

These days, I spend more of my time prompting an LLM than writing code myself. But since they have the memory of a goldfish, I’ve found getting them to produce the right thing a bit of a crapshoot. Yes, there is AGENTS.md but that can only tell it so much: there’s always more “implicit” context that is needed to solve a problem of any complexity. And even with extremely long context, important facts can be missed or given too little weight.

Since I found that I was encoding these details in a prompt, I thought: hey, why not just make the prompt a design doc? Have a human express the intent, goals, non-goals and a sketch of a solution in a markdown document and then collaborate with an LLM on the detailed design. Then, once you’re happy with the result, proceed with implementation. The result can then be checked in along with the code as a sort of guide to understanding what was done. In a pull request type work flow, it can be critiqued or commented on like any other code artifact.

If you’re familiar with plan mode, a lot of this might sound familiar. The key difference is a fairly deliberate structure (explicit dating and proposal template) and a higher level of human involvement in the earlier stages of design. To incorporate some notion of chronology (since IDRs are meant to be “moments in time”), I used a filename convention inspired by database migration tools like alembic and goose (for example: 202601180308-upload-packages-to-pypi.md) and a design template that should be familiar if you’ve read Design Docs at Google:

# 2026-01-18: Upload packages to PyPI

Owner: Will Lachance <wlach@protonmail.com>

## Overview

### Problem Statement

Save maintainer time and avoid security gotchas by using github actions to upload to pypi

### Context (as needed)

This repo ships a Rust CLI as a Python package via \`maturin\` (\`bindings \= "bin"\`). CI already builds wheels on Linux/macOS/Windows and runs a smoke test from the built wheel.

### Goals

- Make it easier to publish new releases  
- Improve security

### Non-Goals

- Automate version bumping (will still entail a seperate commit to bump version)

### Proposed Solution 

…

I've found this a nice additional specialization of proposals, and have found it really helpful in my own work. If you're curious about this, check out the idr-tools repository, where I've been exploring this idea further. You can see a few samples of the idea both there and in repo-parser (in the idrs subdirectory).

Always be improving

One through-line which is in the above work which I didn't blog about explicitly: always be improving. Typos, fixing bitrotted instructions, little improvements in clarity: over time this type of enhancement ensures that the documentation is maximally useful both to humans and machines.

https://github.com/mozilla/data-docs/commits?author=wlach

You can use an LLM to do this automatically, but obviously you want a human being to review the output. Either way, the end result is the same: better end-user documentation and an (infectious) demonstration of actual care. It’s a way of supporting others, including your future self. After some time, repeated small actions become a habit, others follow along and it fades into the background as “the way we do things around here”.

Conclusion

Although I wouldn't write the above articles in the same way (or possibly even write them at all) today, I do think the conclusions hold up-- in some cases even more strongly-- in the new, strange world of large language models. So long as there are complex systems, I don't think describing them in forms that are meant to explain will go out of style. If anything, it becomes more powerful and needed at all stages of the design and build process.

Sometimes people talk about the divio documentation system, but as I understand it, it’s just a precursor to diataxis (created by the same author). ↩︎
I believe the same is true of code review, but that’s another story. ↩︎

Jonathan Almeida: Regenerate the BuildConfig file without assembling the whole module

Jonathan Almeida — 2026-08-14T15:49:23+00:00

We have tokens that are added to official builds when a CI server is building the production-ready application. These tokens are added to the BuildConfig.java by using the buildConfigField function in a build.gradle.

While testing, you want to quickly regenerate just this file to see changes occur with a new value. Instead of using the more expensive assembleDebug task for your debug variant, you can use generateDebugBuildConfig.

In the Firefox monorepo world for the Fenix module, the fully-qualified task name would look like this:

./mach gradle :fenix:generateDebugBuildConfig

Mozilla Localization (L10N): L10n Report: August Edition 2026

Bryan Olsson — 2026-08-13T20:38:20+00:00

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.

Welcome!

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

Changes to the localization team

A lot has changed in the team this year. Delphine and Peiying left Mozilla a few months ago, and we’re now happy to welcome three new members:

Camila (parker) will focus on our mobile projects (Android and iOS), while also helping with Spanish localization.
Eda (edie) will focus on our web projects (mozilla.org, firefox.com, AMO, etc.), while also helping with Turkish localization.
Eric (ewerybody) will work alongside Eemeli and Matjaž to support and improve our localization infrastructure, including the moz-l10n library that powers several features in Pontoon.

For both Camila and Eda, contributing directly in Pontoon will also be an important part of getting to know our localization community. By working as localizers themselves, they’ll experience firsthand the challenges contributors encounter and gain a better understanding of how our communities organize and work together.

In the coming months, we’ll publish a series of blog posts to introduce our new team members — and reintroduce some familiar faces, since it’s either been a while or we never got around to introducing them when they joined.

What’s new or coming up in Firefox desktop

Firefox 155 Beta

Today marks the beginning of the Beta cycle for Firefox 155 and the start of the shift to Firefox’s 2-week release cycle. You can find more information on this change and how it affects you in our update here: Firefox Release Changes and Localization.

Themes

A new part of the upcoming Firefox redesign is a number of built-in themes a user can select for their profile. The theme-picker.ftl strings are landing in Firefox 155 and include a number of theme names which are short, evocative names in English. We have generated a reference document to help with creating localized names in your languages, it includes both testing instructions and screenshots.

What’s new or coming up in SUMO

We would love more helping hands to bring the following locales across the finish line:

Spanish – 48% remaining
Japanese – 19% remaining
Portuguese (Brazil) – 11% remaining
Portuguese (Portugal) – 17% remaining

If you’re a contributor in one of these locales, now is a great time to jump in. Every translated string brings us one step closer to shipping a better experience for users around the world!

What’s new or coming up in Pontoon

Editor theme. The translation editor can now follow your theme choice. You can set the editor theme independently of the main interface — Light, Dark, or Main to match the rest of Pontoon. The change comes from Ayush (ayshushus), who is interning with the L10n team and wrote about the work on this blog back in July.

Copy from another locale. A new batch action lets you copy translations from another locale into the strings you’ve selected. It’s especially handy for closely related languages, or for locales that share terminology and want to bootstrap from an existing translation as a starting point. The feature was contributed by Serah (MundiaNderi), a volunteer contributor who wrote about her work on Pontoon earlier this year.

Copy from another locale

Community health. Teams can now follow their Community Health Score over time in a new chart on the team Insights tab, alongside the existing activity charts. The L10n team also gets a cross‑locale overview to spot communities that may need support. The dashboard was built by Jamie (functionzz), who is interning with the L10n team. See his previous blog post on translation search unification.

Composed Machinery suggestions. Fluent messages with attributes or selectors used to require copying each field separately, one match at a time. Machinery now offers a single suggestion that covers the entire message: every field is filled from a perfect translation memory match, falling back to machine translation, and one click copies all of them into the editor at once.

Composed Machinery suggestions

Automatic LLM suggestions. Until now, getting an LLM suggestion meant opening the AI menu on a machine translation result and picking an option. The suggestion is now generated automatically and shown as its own entry in the Machinery panel. We’re starting with a limited rollout — signed‑in users, strings without an approved translation, and a small set of locales — so we can evaluate quality and cost before expanding. The AI menu keeps working as before, in every locale.

Other improvements. A number of more focused changes also landed, thanks to our contributors:

Notifications about new strings now link only to the strings that were actually added, instead of the full resource — by flodolo (#4185).
A year selector was added to the chart on profile pages — by flodolo (#4205).
The list of translations on a Search page is now more compact and easier to scan — by functionzz (#4157).
Search boxes now look and behave consistently across the entire app — by MundiaNderi (#4301).
A clear “String not found” page is now shown when the active filters don’t match the string you’re opening — by ayshushus (#4281).
Profile images from Mozilla accounts are now supported — by wassafshahzad (#4215).
String counts in the translate interface are now formatted using your locale’s own conventions instead of a hardcoded en‑GB — by ewerybody (#4127).

New contributors. We’re happy to welcome another group of contributors who made their first patches to Pontoon in the past few months: Kasturijadhav14 (6 patches), eshu3104 (2), jbuck, troypsierrallc-dot, msranjana, and denyshon. Their work spans notifications, contributor profiles, documentation, UI polish, the API, and infrastructure — thank you all!

Friends of the Lion

Image by Elio Qoshi

Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!

Useful Links

Questions? Want to get involved?

If you want to get involved, or have any question about l10n, reach out to:

Bryan – Project Manager (Firefox, Mozilla Accounts)
Camila – Project Manager (Firefox for Android, Firefox for iOS)
Eda – Project Manager (Web projects)
Francesco (flod) – Project Manager, L10n Team Manager
Francis – Project Manager (Common Voice, Mozilla Foundation)
Théo – Project Manager (Mozilla Foundation)
Kiki – Project Manager (SUMO)
Eemeli – Developer (Pontoon, Infrastructure)
Eric – Developer (Pontoon, Infrastructure)
Matjaž (mathjazz) – Developer (Pontoon)

Did you enjoy reading this report? Let us know how we can improve it.

Thunderbird Blog: Desktop Calendar: A Design Journey

Jesse M — 2026-08-10T18:59:27+00:00

Hello, Thunderbird community and followers of the blog! This is Jesse from the design team. Today’s post is about our recent journey in redesigning the calendar portion of Thunderbird, and what you can expect us to deliver in the near future.

The calendar is a key part of any productivity toolset, from your PC Desktop to your office wall. There has been a calendar in Thunderbird since early in the project, and like all parts of the application, it’s evolved on its own terms, for better or for worse. It has many layers of functionality, but the experience has lost parity with current UI standards — at this point, it feels stylistically dated and functionally convoluted.

So, with the help of the design team and the developers and the community, we have taken on the task of modernizing and streamlining the calendar. This is my account of the designers’ part of that journey.

The Big Picture

Here are some of our guiding principles for this redesign:

First, we are here to serve the entire user base, not just the technical experts, or the productivity enthusiasts, or the brand new adoptees. For this reason, the dialog with the community is critical: we need to understand as many of the use cases and interaction patterns as possible, and we want to support them broadly, and efficiently, and effectively. Our ideal solution is open and flexible, respecting the broad range of users who rely on Thunderbird.

Second, a key point: Thunderbird is aiming higher than being simply “the other email client.” We are all committed to creating an experience that meets and exceeds expectations, and competes directly with the oliphaunts in the room: the Google Calendars, the Apple and Microsoft application suites, and the many targeted productivity apps that jockey for this space.

And as always, we will do this transparently, with an open source philosophy, in collaboration with our users and contributors.

The Journey

This design journey has been ramping up for several years now, in parallel with other company initiatives (Mobile! Web! Accessibility!). As our design practice has evolved, we have worked on the project from several directions, redesigning dialogs and rethinking patterns and collecting insights. For a while, this meant a lot of partial designs, but without a guiding vision.

Among these early designs, one of our success stories was a visual and functional update of the Event Details dialog, to replace the existing, rather archaic event details window (”archaic” both visually and in terms of code). These were one of the first redesigns to reach a point where it could be implemented — prioritized partly because it’s a self-contained element, able to be tested without reworking the whole calendar code base.

If you use Thunderbird Daily, you may recognize this:

We’ve followed this pattern for several other bits and bobs, including the dialog for editing an event, and the notification for unanswered invitations. In all cases, these changes will create better contrast and visual hierarchy, and improve the visibility and organization of controls:

This alone could provide enough work for several release cycles. But designing isolated elements creates inconsistency and debt, both for design and development. As the design process on Calendar increased in velocity, it became clear that we needed to articulate a unifying vision.

Bringing it together

With these designs setting a direction, we had to step back and decide how all the pieces would fit together. In order to do that, we still had to answer three more questions:

How does the actual calendar grid look, set to view a day, a week, a month, or a year?
How does the user change their view and navigate forward and backward?
How does the user connect to their calendars, and manage them all in one place?

These considerations led us to a lean design, with screen space broken up into three main sections. First is the grid, which provides the main element at the center of the layout — the user’s primary workspace. Second is the navigation bar, directly above the grid. Third is a sidebar for managing calendars — the nerve center for your calendars and data sources. This design, focused on the most important functional areas, provided a great foundation for all the necessary functionality, with low friction and strong fundamentals.

The blueprint for our design (called a “wireframe” in the UX design world) ended up looking like this:

The grid acts as the user’s main workspace, and the header and navigation provide their basic controls.

Here is a final design mock-up, which will provide the basis for development (this one is showing a week view in the main grid):

Given the wide range of our users’ scheduling needs, we decided the calendar sidebar should be collapsible, and useful at both large and small sizes, so that users could decide how much of a footprint they needed to manage their calendar list.Here is the screen with the sidebar in a collapsed state, showing a Month view in the main grid:

And here is this screen after the user has pressed “New Event,” showing the Create Event window over the interface:

Where we go from here

As these elements came together, we also turned outward and looked to our community for more feedback. Through the various stages of design, we published two TopicBox posts (here and here), and we ran a short but informative survey, looking for initial reactions to the direction we were taking.

This feedback has been very encouraging, and also enlightening: we have seen a positive response to our designs, and we’ve also gathered lots of insights on what you cite as most important (task integration, platform interoperability, and a re-assessment of agenda, mini-month, and multi-week views, to name a few).

These discussions gave us some additional confidence, but more so, they reminded us that we are still at the beginning of a longer arc. After we develop version 1 of our new calendar design, we will follow signals from our users as we plot a path forward. The new calendar design will clean up and simplify many aspects of the experience, but it will only be a promising first step (sort of the Rivendell stage of the epic). We will have many more cycles of design and iteration to bring our users the toolset they deserve.

For now, we venture forth, from design to implementation, and then from implementation to feedback and engagement. The new calendar will be released gradually, via proper channels, so users can try it and provide feedback — and feedback will be appreciated! We will be looking for usability testers and survey participants as we keep refining the roadmap.

The future of calendar is wide open, and much brighter and less gray than the bygone era. We appreciate all the support we’ve gotten from the community so far, and we hope you’ll continue with us as we keep making Thunderbird awesome.

The post Desktop Calendar: A Design Journey appeared first on The Thunderbird Blog.

Mozilla Security Blog: Updated GPG key for signing Firefox and Thunderbird Releases

Ben Hearsum — 2026-08-10T18:37:53+00:00

Today, we moved to a new GPG signing subkey used to sign certain Firefox and Thunderbird artifacts (namely Linux tarballs, RPM packages, checksums files) after an unencrypted copy of the previous subkey was inadvertently committed to a private GitHub repository.

Our review of available audit records found no evidence that the key was accessed by an unauthorized party while it was present in the repository. Access to the repository was limited to a small group within Mozilla, all of whom already had authorized access to the key through other means.

We have revoked the previous signing key and added safeguards to prevent similar issues in the future.

For most users, no action is required.

There are two cases where you may need to take action:

If you manually verify our GPG signatures, you will need to import the new signing key and the revocation for the old key.
If you use Firefox RPM packages, some manual intervention may be required. See the instructions below for details.

Thunderbird does not provide official RPM packages, so there is no RPM-specific action required.

RPM Users

Different RPM package management tools deal with GPG key rotations and revocations differently. See the sections below for what action (if any) you need to take to ensure you continue to receive the latest Firefox updates.

Fedora 43 and later

No special action needed. During the next update, dnf will download the updated key and you just need to confirm the import. Make sure the shown fingerprint matches 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3 before accepting.

Fedora 42 and older, RHEL/Rocky/Almalinux

Dnf on these releases cannot replace the key on its own. Updates will fail with “Import of the key didn’t help, wrong key?” or “The GPG keys listed for the mozilla repository are already installed but they are not correct for this package”. The old keys must be removed manually:

sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
sudo dnf clean all

Important: Remove the previous signing key before importing the new one. If you run rpm --import while the previous key is still installed, the command may report success even though the key is not updated.

openSUSE/SUSE based distributions

Same as the previous section, zypper won’t replace the key on its own and it must be removed manually. Updates will fail with “Signature verification failed” or “NOKEY”. Use the following commands:

sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
sudo zypper refresh

New GPG Key Details

The GPG fingerprint is 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353. The new signing subkey’s fingerprint is 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, and it expires 2028-08-05.

The new public key and revocation of the previous one can be fetched from:

KEY files of the latest Firefox Nightly (https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/)
keys.openpgp.org, or
inline below

This can be used to validate releases signed with the new key. Due to the nature of GPG signing, releases signed with the previous key will no longer be verifiable after importing the revocation.

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFWpQAQBEAC+9wVlwGLy8ILCybLesuB3KkHHK+Yt1F1PJaI30X448ttGzxCz
PQpH6BoA73uzcTReVjfCFGvM4ij6qVV2SNaTxmNBrL1uVeEUsCuGduDUQMQYRGxR
tWq5rCH48LnltKPamPiEBzrgFL3i5bYEUHO7M0lATEknG7Iaz697K/ssHREZfuuc
B4GNxXMgswZ7GTZO3VBDVEw5GwU3sUvww93TwMC29lIPCux445AxZPKr5sOVEsEn
dUB2oDMsSAoS/dZcl8F4otqfR1pXg618cU06omvq5yguWLDRV327BLmezYK0prD3
P+7qwEp8MTVmxlbkrClS5j5pR47FrJGdyupNKqLzK+7hok5kBxhsdMsdTZLd4tVR
jXf04isVO3iFFf/GKuwscOi1+ZYeB3l3sAqgFUWnjbpbHxfslTmo7BgvmjZvAH5Z
asaewF3wA06biCDJdcSkC9GmFPmN5DS5/Dkjwfj8+dZAttuSKfmQQnypUPaJ2sBu
blnJ6INpvYgsEZjV6CFG1EiDJDPu2Zxap8ep0iRMbBBZnpfZTn7SKAcurDJptxin
CRclTcdOdi1iSZ35LZW0R2FKNnGL33u1IhxU9HRLw3XuljXCOZ84RLn6M+PBc1eZ
suv1TA+Mn111yD3uDv/u/edZ/xeJccF6bYcMvUgRRZh0sgZ0ZT4b0Q6YcQARAQAB
tC9Nb3ppbGxhIFNvZnR3YXJlIFJlbGVhc2VzIDxyZWxlYXNlQG1vemlsbGEuY29t
PokCOAQTAQIAIgUCValABAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ
Ybe1JtmPA1NQqg//Rr6/V7uLqrIwx0UFknyNJasRJZhUkYxdGsLD18zO0Na8Ve3Q
sYpOC3ojpqaFUzpqm6KNv8eXfd/Ku7j3WGr9kPkbjZNghvy6V5Lva4JkxO6LMxKk
JYqiqF2o1Gfda8NfcK08GFy4C0L8zNwlADvmdMo4382tmHNGbTTft7BeVaRrE9xW
9eGmGQ2jYOsjxb5MsadAdZUuK8IC95ZHlUDR3gH9KqhfbQWp5Bo924Kiv+f2JUzN
rrG98eOm1Qb8F9rePzZ2DOYRJyOe4p8Gpl+kojCXNntkJgcwJ1a1yRE6wy9RzpeB
lCeoQuLS92MNne+deQZUskTZFoYXUadf6vbdfqL0nuPCKdl9lhef1QNwE30IRymt
6fhJCFffFQjGdeMfSiCHgcI8ichQbrzhBCGGR3bAHan9c2EbQ+puqG3Aa0YjX6Db
GJjWOI6A61bqSPepLCMVaXqV2mZEIaZWdZkOHjnRrU6CJdXG/+D4m1YBZwYM60eJ
kNu4eMMwMFnRsHiWf7bhqKptwuk8HyIGp2o4j8iqrFRVJEbK/ctdhA3H1AlKug9f
NrfwCfqhNCSBju97V03U26j04JMn9nrZ2UEGbpty+8ONTb38WX5/oC61BgwV8Ki4
6Lwyb7fImUzz8jE83pjh7s3+NCKvvbH+VfT12f+V/fsphN3EwGwJPTC3fX2IRgQQ
EQIABgUCVaz/SwAKCRB2JUA9fw0VsVNkAKDjhUW5GyFNcyj9ot48v+lSh5GBIACf
Ten/Rpo5tf77Uq7445cVs80EK5CIRgQQEQIABgUCVa064wAKCRDDTldH4j3WdwW5
AKCVDRxKjb/XYqGhjBCKYhbQ4xJuOACfVIpzE3wGLC/cm9eUnSVnv+elQnKIXgQQ
EQgABgUCVgZXYwAKCRACWrAQaxfqHqzWAP9dzEHoZNwH5JYxotudv3FOotVThaQr
jnk+5StnObpxnAD9FmYyAyYGh4o7axeDCgmW1J89+1cZtDnFPKnBpGFMB4uIXgQQ
EQoABgUCVa0s/gAKCRDwqefc055FLpQGAP99Z2ISKW+7FYoKJ3vDrxTtfcbZEff7
8ufoinmAlZb2bQD/a2fOcprjWDal9Orfq7g6htkX3VISemg+SDQ/ig+b3uyJARwE
EAECAAYFAlWs/X4ACgkQs8WpWFCKQ/JrjAf7B+fGzEs8xfc010a6KZXcO1W4/Va0
Q+zcqF+DpQwK7b3S6oD5tCVKD9oFyDXkrlT6Tnwuu+slZwRDIyH6hI6tPb3G8Gsk
vjXMeL0IdgZsw1DSxN0pZ0Z9mxFq/UkC/6TmFA1IJmOWtFCH/1irQWqbDxPmWp+d
Xs2EhH8QzX1KQOE9v/YlsCdmTstMiHy3R8r7prsonpCa36zGheC/UNDpycKdT8JL
zeCFcIWXmA7SCTeJ0XCSuS68FOwfe7nn9oagQZZe/6gh5ecuCoW9HLBWpyIPqUCz
1CXSImLc6BbZYMpAetacarVPa6hiltNicxFE/A3T1F8ZjAcugPKBngUR/4kBHAQQ
AQIABgUCVa0XXAAKCRBlc4Lb/yURCkCYB/95w/9/0rpi+5xtoO2NR0KlqYVG5+NF
1r42XB6t7gVJ9UGF3meV+ekgDSzNrfroqxpzWmV1t3MRJeSMmVS25nC1hAZVQHKd
gX9xVxW3SSufX/jPstvo2U/X3k8q8PhLS6Ihk8YJC3ScjMiNMRpkITMeVdXsdQsY
WStiT48wlWK4gSNMCG5iovdGDTEKErHTIWJl/Wx5el1kvUwg1rKo9uRS2CS/lnlV
6YztDY0cBBOqXP6pXXiWBuVW39LJxsSHq13vpeQ/GHeDxAJ6Y+fPuaV3qBmGZ91o
1/HkxTABFPkISylkPo/2PCoo4Hu31MZ0jQWdihJ7gzf+B7/w6whS79eAiQEcBBAB
AgAGBQJVrWVaAAoJEOQyfGw+ApnAc7AH/0TKg3VR4IEB3NP2C7dX/72PWO0EOh8J
w67XDccRK0lXDILg/CujsYq9EzEofv2LmQFvCuCkoBFEcGas+J2vP3jsY/G5bjZp
XALHkAx7MKlOgsgfeVqMtwaHIoR+y9Hg12TjM7Gt970UBwTIqC8SG6Z1bVWxUdc+
7Zsn43Dq8z99saOUKD6HMyl9upbjAYwL28NRQtIrNiDZ5lEmDOLh+4hWblxjxWMX
AKjg6sucrNzKD2uKGe9XdB6IkYpdfrNGPtgcnXWdfaRNk16eGVzWDVI/9mkY/G+L
E40eK6oRyMf736CvlQjcv7JBVGTsj3W28phNLLU0UidYK/QmS3AVmBeJARwEEAEC
AAYFAlXBWXAACgkQiRc/lXxV+V6gKQf/d/KfgiYg0Z4dqO3g1p40sgLuxVplhpDk
J4yP5K2isdb6I7GJykVw+po6tUCfB7KeLWiZy0I3KJDU1Ikk+Jv3uGSRMT1riSpM
Ja2pVhh+jaamHIFj2o0mG9HmEAuGKktJH8s6Jax3SiPGODRhFO8suc7B8FpB7f5q
TUDK2J18MlnSK3NN1/zl6OdXScrISQ0cNyJ0RMgW5RSXC7wKzR89tfcDK1wInD8r
cOMHz6Va5g8ehq2XCPKvBAlgo8El17+4UaRLhS0suVz4THPsGASYzZVKIhQQBf+8
xDXd6zJ/UgkC4iBWHtLm5jvm6Xhsu04s28TmgiH4FKLsstAUFzbiQYkBHAQQAQIA
BgUCVdIa6gAKCRCtfLmfgki6D8xCB/9Q+rCTDQCbWQkRoSV77+kmIb+KVFTcgxfR
Z1L0bKL5YqI6HuCJLgU1ioTxq8W4g+SDv4s69/LIajYYZvSRNv0kGRzm2D4vpcnw
ymyYCJkzcZkuBeyR50S69+1cStbFb7jZMpyZ6rwnKdYOccDSMdaynJGt4rqiY+ra
DPF0H4LExx9a1JFh21Fd0MDc15vsoRZtrOkM8QaKD85hZ/AGOwlw+Kb3DEfjNGcv
nuNp54HfJc0Z5kwVYoOKUatBgjLpRRvl43lUGRaaCCMaNpNZXM20ZhrbTjXRlko8
QVMUXqE20sDNwv+dDa6G8nBkIGNIHeixrVrVPP7hH5JRMtjZbsWFiQEcBBABCAAG
BQJVrQFGAAoJEFbucY3ODhVLNDgH/izNHcsr1BRnV3yQ6T9sTJJ187BwF1hRLR+Y
3op+fJr+nQ9301XAqLqNbzEB91hRUi2Gb8LTZxxq0gahWzSqmdAE0ObXGGlrEmfj
FSSTFyQ1xRvzooYNZzTjN91XX1dERjyj9SOHBETsZrN01BZB1t3EgoDM7PCNTsX0
qC65unWvBDftnLdiJ6s3UC9sorMk8q3Zl6DacFw8QKSmJL1R0OPvXiSOZtGQK9Jg
YyHiXQE3MOP5SFSk61e1IawocYn32CXM+EkgtXK5q/thc8OdwsgLAJmGpVB3qd2K
9OaEOKCUV/V91a2P8hCx8MMV2sQgHcMB221wDIWbD5PTHNtCegaJARwEEAEIAAYF
AlWtIrEACgkQo9ZSFzt2Po+mXgf/dUPf6q+aDFoDjLIsfJH5QS8Nn/7frUUdElg8
PdGxtZ6SQep6uR5fgc+PwOElhUxa665WYtRJ459RWAYmbh2kkP/paGBf9nW0A2wS
koXyJNydJcanyjwHyqKUbBLsXJAvGFtbYRsbeXkEPM5CaKgRUwc8Ilzo9/53CZF/
avZK4FJX00lZq0/Z8dIY8jUEF64IbJgbaUe1gkuxu7zURgjVKK4bb4lLy/s3tRe0
00hrKVbFcaNoIZs+Vk/3A/TFdYHFY6I2JpLIeSSJd/Ywh6/YZfGkSHfzn87Dfkyr
gXKQMQ5JvQQgKbO6GPBZSygxWU7R2tNNAJKHSh0/PJ8J7yrqj4kBHAQQAQgABgUC
Va05AwAKCRD20Pdh3MzspCvWB/9DAEaNx5WF3ktmw6jP5cCv60HDwgsmJHusGyAo
53Gwjo4Fx6hv5QYQpTbO4af+4KpFGkex+bZniOJWpT+NJkhx55xbzA903MoZ9+dI
oCtG4K41kA2mMYSpR097yF3fwtuP70UgMZqiCmz/iKFzsrdhjE0KvBjptnYGEWk5
MMh5xlpzGom3LV/A+KAmEdPw+GCaj5H6qG3/PtWXz+RmjG0sRPycHaNJCWuLz4xM
xV28oAG53Gqc3cDes4Hpds4fPOa8+we7yKTK/2O3lfOUOvKncsoS3vHC/GNfGD86
RX/vz2TW4GMaLmn75xcAYT0MINIFBf/tXjN1BNrmvrGkkxnbiQEcBBABCgAGBQJV
rQlbAAoJEDNC4bZno4hjKL8H/An2CRzW8IsEjFKD+J+xa5hJYQbcb5W5wjGSs9PL
/pRbH0t8FNS1DevRqoq3xdL5EEUpUgae54gix0An0qKhzC4MRdD9sYFy42mDP7f6
8Vw2sCZltfBtOHaha7Qj2U28DE9j7Dx04lkHWjdHudJV5PVaPpelW8EDIOMx+4nG
WnXiYEKKMRWpR2BVV1FXnsfbfP2HWpxVaxxWt7WqOmswU0lJCb2bSLteEn8YoA1i
CMLMdMaVXyX92v8Quh2N0NWtzXgc94ug8GiucGKoo2SpdFlXVCysqlPfKBestJlL
93dqP6dOwqoHqOscTJB6rvNzi2tmtAu7WDy4C+BBXNhbYpGJAhwEEAECAAYFAlWs
+ygACgkQljt4MQo3sXysaw/+J6Ztawe/qT5aLW6it+zLq+3oD21UgM1TVP81CjwL
hlHj9wuuGDe+xE8dZA7kvpngKjAxxXPQX/B4rz27Y+kHCvelOSrLW5kodTsPWIkL
cSYMRo4Pws0RIGQBXI8tDIaJJcj7BYb9O7OjCziTEjP5KxDeZ6o4n0NFnZk5NNhS
6B1VnC3Y34DIj4koxm1N5O5br4z8kTc5PN9bMxOZn2u+KxGIeEwZJbHvtrgeAxUP
96B2dUo+jgSuro5jSkIyD+wpfo5o6+/kCtDiXEWo//AHJAwOal02QAodUtrMggwz
J19FfnU8RgiKFjivrbfZi6ITM6RHg+DSF+KnaW2wkc3mGTB0qJsgSLGwOgfv37Qx
O1tTdPxbSfWnZJAspylC74dgh+XOYYDji9tjPtrKZ8sEaHiUVFlO4QTOTlB9yYwO
E7uI/3MKe3Q+0M2a85gvX+S0CdznpXo71aMFj0Hd/7ZMuKNausJZhagHAILbve1M
IATkkfbCTxg5bdYgvdVGAIgUEAAO8mvLl1EvOJgkME5a/I/mK6MLxByuCMaT0RMr
U9S881f+AJuJ3Qxbbo8vN0Iy9KmiCIptcSMKBKLHeMonYaXM8O392/XUKbgSBXkL
oTOybMT+LZhO0upOhpRJqmtyDT1Wjxp7FBku/sUjJXCVy7YpjwkkLxZmvWIhleb7
S8uJAhwEEAECAAYFAlWs/LgACgkQEstOl+B+Z9HYNA//UKMSIfS0bdY6K+zhxuMS
lIyol8Z/ynkDZSZ8SOeXZViLyRCRoXhY2g6JsygWLsZpthI8fnleQhwy1GLCxWMF
n/PiRjj++VHoJYK/ANP23bC+tyl+jT9gwoPF0eGdWnnot1jGO6f6jFqam0KAL/XN
6ePUrNo0jbrYVrEUer20PYsM3tqGlGgOOFikMoYWwsAVOEh2I5Sgi6iAYfx12RYW
eKw37loDwSr2FNZ5zjxdIyUQnKN1YMd0/Rfi2d86OVD7dV2qa94TFUvYmicpdcOM
9pogKVGmbhz7lirjuAidRhdZkuU+rxvIAd07Oc3bQRdsUCJAs/kjO71v9ov/NqKu
j/BLixxIa0D0eKE41yL13RCfZIG46nI/F5PvLXhDp7sIeohIWsvYv239A9yXfq6B
TeXZ1j8YTlY86yN38JStf8pbGWKlGARM7e1o9DHYY3irLCOWCAnKmF14wbbTMOAe
w2VzxV8895Bweeo2fyCOGFI6SzvOSaOQPUlfmiKmtJrwreg71Vsv64X8X6FHajZY
V9dYJFS2gO8cYJ/zajzn/oeYVTtpsFpJmq7fWByjGd7pAnZHuuSEy/57GEptmYRu
zmI2gn7vYz1rZAbLThFsk/auCU3VYke8Dd3jHnxBuq2+Pa8TmLxibvnE1ZKd0gqZ
dMNY/rT4+LZI+xDczzF3Z7mJAhwEEAECAAYFAlWtLOIACgkQirEyljoGU3rjMhAA
ijskigHf8Q3D3B4Oz673cLNOGfAyEdHWNqlJW0Vcdo05iF8q8utwqmziRWw4PbpO
cdPpUqLb61rWfjSkq4PVTOr8leHHNj/a4aiAYt8DtnpcwJqTmktiijo0Ptn0v8ao
fdRJSVLtPcV0FydLzK6oLovszdWAQ4iVdFjppvdDJtjT4ooXFmZgZg6KzqjEGm8G
4wS4tMlFR4AJZIpWN5gAeLZhCg3jfuKWEgAIVwJZfVPp8qFTIMDCbHGcmszqeDKj
G5hY8q+KeQBs7/jjibY7QjSk+qFvWPlES2NGCnjrD5NL+T5W0AlQZS3kgbDWbnSm
r/xr6OzL8+bi03J3gRW/oWmCIlzvxUJuLgR5M3TRS4GqYfNVs4etgIW7QZXwTo/5
W8zd5P8UcKOuEFPtmfRjoRZYY30TqrmO9BQkHLKcDbqgnWcm55HaRdkK6+j4tKik
f12/VXez1tP4CkHcMJWE4g3poANtZmHia2MPO9/+1P/pCxUb5jwBF+CDiDhDel1Y
8b7u/ERIugpl8TqGJx+GkUlw0cotZ7BoweNwLXwDDDQlIoA4BT+LFLGQBtUQKMQY
TrDv4PUucMfB96yiEwlw40IdkmHgcBxXFNNxDHMsxEIW2TYoITfmkShiIm7XkcSE
oilPpHFmh6JXpnqOsBhfO0FxKSWkNjsCKCMUGLww5kKJAhwEEAEIAAYFAlWs//EA
CgkQP/MbrxBL+eLdOg//Z9Tcp9kElDdZl3e6aJqGpGviNqIA20KbvYrham5Kn3B9
1LhvMkypT6fZWAwbNCBHxvOSbOolcSSLpbaHK3A5jsg5MhLJ2G3Xpf7Z91+Mqg/H
iOiJkaAhPoJ0Ny6BCB7jg3yaKLDP4wBwDbOH7JWuP7uQmQ12mqu6WFxok7e53bH5
i4gmu3QIO21RXyWoLJy/1Y5X3ljPZ1tNawy/Sz8UjeLau2Sl1mQ6JxWWCeLp7Cvw
p+j6nKOFm/hVDlgnFrfIp9aYHjR2fVpwIFxvfff94gm20EywerlcGOAMeT+1QKZy
1V1ekBVX+2zdQ8RPJGZPqXyxnLg9SyUhdLJBPNDNe5ALfolfn2pvBGM3hnRunGOs
PrK53WjGqvXXYhyIkJEd+UoyQBp6zUY/KKFK/7yjgZxX7sCSwNjDlFT2fB1gfll1
vKoYocPQl2t/B3beKOZJzBkSMk1hBdE0A7URkOoYrFQTdzsSUVwY+/0IAhvxqGKc
HhinLDFON6ee082511VVMrSbCxcnsThjc61CMYA1TxL01Jzb3QIoTWT3W1t2HRZD
/aXcDsg6UMHm1xC1MdZKeKpdJWrnnseC9b/tGuqw2EHitYDquVBmPkx0UoAdsbB5
ec3q8n4J45VJFJcSrrps/vRSNn0bUqcZlpZSZERdqBTBkbizxgFnvJx734JLhlaJ
AhwEEAEIAAYFAlWtG6MACgkQlWNH9vvzpBVikRAAmfUzps72Opq31lRHZXXGD4/H
FP9SyYRnWzaOWGDMfgO9p3IcRl3qRwOuThCvn+qxTHmRT8KUD8uko9zIU+ttx/zx
An3hvO1nCzsiW33N4vU+Y78Uvs7Rumm2CNif+dKDL41FnVpA191b3T3NGWfigvqB
78fWv/WJIuPJuAhCoJYFbK0Vv2/QF2UAo9O2wdBo0ELZKmP5tWfJuLbc8XzuzgaP
4xzRdgJ+P+IFA4q1zQ49FHQeRWBSWkxFAp3iI9sdH5Na+Lup2vLSDYYmdDOyII5w
5QQ+Y8M78Bvt5GBOk52KfTH3oNjDwtd7ae46yWrSy7razs75klSxi125IfcPr/r8
e6jt08WVDZRak5mLPryNlf/Y+ymFe07aIp3eiKO1/SJp2K73fCTslXDt/OuzKZSp
656hybxUrRPiXBxHMOWkcPllZqBXf6GxnN+Fdyutk/e+0EBjpK02AxHY3igA3411
2ZGTGXNCL8ywTidVweOfjyqiWAnCSUvF6+efjRgg2mlD1g6ZDRiKpl9p/ZGETjCh
urlpGSKhtCZWZIGt0x0iSLy4surqDrwwuBqEPSZ08KRr+q9R8HIPuAwjq2CjqDyj
DFNuLx8dhbUUVIAl7a9nJotsph5VK7c/BF0uLW5YnPJYsXG7z1KixL2ydoH1kL41
zXdcIWBP8H7yPVgUxCKJAhwEEAEIAAYFAlWtG98ACgkQvBcwG0kbPyEIVxAA4imw
p7Df/j5ZZcZ+kkBwAhFO+WnJMfkNNl4g/7vsFKbWFBpiYuGmlvX+poM3nTsWCuEv
v3QohbZHGJS/hY2kdAuxurTI6w4FvvJ0Akz1DUANIF9gfJ9Omu2Znb9xG1fzyCSc
EzUgaf3aim7zyp0arjjqR/msmd2sCjqvy5VgRK21tYAfhWmzdJQntIlCEExfTh9x
guELDLSK3j7ngZla1T3BwE1dlcPVD6l9bl/7ZV5uXmotOqFU+1dBcFG4NKNXmnG5
TV7x3Ih6Xt982SCpBgVsEow1XFPf0jflPBn6DGJsgpmuIjdymgpJacwZCYkGbTSj
wAeSibYvCw1MRYtrCXd7KlmmQxhYTvvzyoQSqaiIQM8daaXddcy4IdHoOoEJVzfA
/BCyEkb0KhhjTWXQoRBXcxhJYOUjH5nhHd+zml+MHHiy1dL+xANHaBzFaNHpxYUs
FN2MLcMW4rpCnOx/8pRu/o757Y2Ps+ypLUbGPxZJJa26zYXXTAUDDEgEFFM9Rifu
jVCps146sRbrodzgIajc4ScgAWVkHDTKYfq6IBLJZHp8KB1fYFkVrUtwjMmyZCpG
7FqWITGTWOoRbYAsInWuzT7PN+vb/sk0xOk1PzSJV1CmCH9izKrTqRAU42jd4yqV
IuQ3hN8wXoeolSlK3wl27fDtK2EDzVhklvjGdreJAhwEEAEIAAYFAlbwOBsACgkQ
RPRuFG0COV30vQ//Vzyu44NJZrDWdrAyMngMOZ+qIUkeRdtKHEzAFXl6je1ZLyXT
aSKhyWtdxD+NPA4E8vQbEqbcpvzkBhOgfNgVOxWUxC+njB5xhg4PuZLcffm+98S3
ncyu+bYuhA/kLgOJA2HL1vIQEobdM0XJhVM8G7bhKKSdS5NUd6BS8AgKL5YXbguO
ZwDVq0yuVPg9VNqG5eTwL8fvZhH4L6I5Rh/wv1g++FvnEGRR+7ePprkc2pnJC8j3
7Z08YzRf5aWCJu89EDsL8wWI/jydPcGLnitNEROfovRX/A647VUl7M4kL0oyblJb
9JFbzPK97YeMwQTUYQOHIp8KsYYKjuBvq9q/Rr9DNpyijp1pshfjEiEZ4YDjTkGX
uWu5EMSlVpC4nEtiBlKT3kMk1mqmc2F7A/g5ug1w+e72E1EbVJMDtAgzjc0+V4kt
RxtTGa8PlfyWouBwL6ReVpEyVz3NS7++QcSY98DgMODMxFggna/zf3bef/lC6RGk
kHyIOC+IhI+q72m0MjdCmzsSA8fqT0PNYs349+sCKw6ocgjSHZlR/8gEZbZC+Fwx
Jf6be2N7eo6hYctOe5XpLaMApVnD3qtw6C9CxWJ4zT6WLyI0SAF3YWmIgLtlYhfF
nRs0ObRXiO7tz0FBuTXD3vljjzq7t8DDK1IS4Cx5AnTZI4rz+/aiD0k5AhmJAhwE
EAEIAAYFAlbwOPIACgkQt4bvJaijiaC0TBAAppcnj7MhOQh+yQCzljw403/hEW5/
iVEyhfkEtF8lnJQPwSCvKphln4B9/E/Z6HBZ5MNew9xj/JrL/JZfk+E81vSs/fhg
lCXB83bFo/fZ6cnqhubcPlXyXLSAY7J195n+DdInbza5ABuaJW6UeVHbGGM+th7L
S6sYmzoOM1oU8mLzugo57M2a0SZNE2GTjeHFzdeFmKtjk6zGhJcdDMvKNalQZyuf
KSEc7+9j5r0KlJOWY4VMqfYMY6qgiQ89IVSutWbhj+oiivCgi030sXmrdOSwG8/G
gufKpYOQ1ZLXrxzowYJ02vAewYCe20PTyzGt5ReB9XkokffvHnKcxHxhyC6HiAyG
B+8+yf0tJk4Fd7uW6zjGDvphPQhH6bPObVVaMiayEfJhhHbRNmJnUKXRc2CGL0X6
vbZ12Y1bAALAttEpsNC544WMwLfUCcGfaRTF1E4OpQucU/uizaxGPiUd8Ateqt+m
3GwjY9HAb9QN8ejiOTkH6XsYSzw4KA4iPqqMySHY/DMyfFuilNWd8m93agApO+8r
9+6xjurnbkh50rYtunP3FCMul2QW1wXaGxPTt7a/IcL00NRVwZmJwa3Ys1OrYMRA
OXM0QvRzpHZOsuqHG45jjaRejMZKSQL0zJOyKgtv4YrG1fceLrZWvu7ZjWVNd+0B
nGitgBkGm5VQMuGJAhwEEAEIAAYFAlbwjIoACgkQpIWg7VG4t8QFOw//YFD2UifK
W2VfUy2ig+ewXOwe/BzVfweN/Im+HSN94ooTEwR5wgdYIjxPV+eEKFfAEsazv8b3
ktZJI+/IxEalHBA+mR4TC2/UlrOgsVCnTHYKL5yJRVHPrdOQ+Zm+kk4vszYocDtC
SPp+/aoRE8u91i6Qu0UdGjMe82HG6qdzVj6bXH9ZFRiWRsfkGxB31cnvfE+aZB+V
qfuy0pbqegJXUE/6In8XRsS12xAk58KM0b8jKQGqYaBB6xE9WDpip5sPycougy6U
29170n+U57c6+x5JQhHC/Rb2AqB8Yl1msC4bj4UsqxWHmLRdcqZs04GiVsrk2fLD
fSfsu023IZPyOhaV/t2KE4DwnAu4b9Sq7PNNzf9yrsgRL4c4OzWEYpMzt38V5QRt
ETJvuuthOypREVNuIs21oRomMJd+PjGsayDuKA7xe/SxDe8tPkoy+FdAfevPXfhy
NWX0vTtcZDpVustEMmoDs7EzlBddrNplsnRZoqW2JyMLErLujc5N8juDPqmAASVy
d7SBUD03e8apjzZSfJhbZsxw4W9z7+rETRSy7o2DPXCabjTGwB1naIc9W4wU/aWU
N81qZZecKLVLxpiXeoUwF3VIJme5Ye1KumsQpTJoi3tVmJ7XDaW9OD8shJtvhlOc
ddt1E4kl9iximuLfhzUjPJyS/ASYhpPNMVSJAhwEEAEKAAYFAlWtDgMACgkQw701
5G3UXaVUfg/+P9+3vFqijhzT7XkLuNrI9GTn3KslTAPU0Oe/BdLPTMKELqn1YVxk
lnrznLbjL9qkwYwXxY5HT6ykeS+CzQIDLLtXqR1NAz3EWVAm4dT+xqaJZmfCoJ40
+VqZdQHLjgmj9PFTK7f3vyZ3Ux6em7Z+h7C1ba8jYZS+6GnmGw6+v6LxzRh1SFUm
YBj/X+GPBYg6cnymr+9b2CwTMbczO5XN3hU9UtdF4UlupPvEuV5XWFpCw64kVwxP
OQvvUJ3aTqEGiCAqd8ntyVZ1MWtaob7GI/bj7dTOoSogUqF3aZawfoUHPp6izTd4
8aRnZhpsK47Y6jIaHDCILhKoAESTnpN1yjqaRIbviHJyYFOHnQESTS7AWrolQVmP
+pmThZWauh+PLVcs4ktp/6CKYvmgnP30HhrPczE7RVKIT32LU3MvT3nFzDmKUruK
eLUNO6LnJ8XwZEVIE3TOVcF+2ME3EcKfV4RwAlBBgYa8DB/CM/rCtoyxdxYSRpHn
9bxbNL6kn+CPAwRZGAChfOPGMhHBh3iDUJaIt79Cq9j6QcZUYfhj1sIvvkDyl0Bc
5U4slbTM6KP5aZgFlCcI9HWwGx/5qIbb1rQNVjxwtiUWediS04YaQ6yt7f/yXbdl
hxPdXDMe/9gdDyuDvP4+1FZbDiV6VT7Bl+UhQnkwf4kuCbSMFjdu+cyJAjMEEAEI
AB0WIQRZyp4tKjMd4lGqJCdfA8dnwkek1QUCWQ72QgAKCRBfA8dnwkek1aBpEACI
6mkO7aXYQyejkTbSyLdE7FoNI4Nq6aKvvQLt+vlGATLgSdz8v7QLGd3KkJYoO5SY
kKjrkGZG4Nb3GOCnWnewBmvCqt7C5/Idl1JTVPdF9CgMHQkwP2F8Tg5X1Ag9oZeL
yRKB/xWbX1LGizRy5s9G6yhq1rwoatNI+Wz36fdCmCqmphm92uPyxuAxy+JZhAbT
/vmANGKlEN5Wjryrp3tmMEhnuJykWq2ZxYiJ9jpx/cNLyjf8fSDBhLXOTG0FYBrZ
k+ZJtw1LlzA36K7IbnunO2qOJzDgvemo5FmGYcm6hyYCzqxBj1VJDmhHu7NZMeMn
vT4d8Py1xBPGPFRYmaK5AP/D07cdDPYawlZA6dMPGE8xSfQxbrayJrj0+vpjSJPt
DUHrg7L+PdpvyVxi8Py0Zfe05h6SjBPrw3eTQS6ODkoZQyh8D7M2HKUiUxvfufvn
LEfeWpd7Vp7hl/VdP3TtbOzL9H/89O5ywf7S/oRKaqgOWkYhs3cfyjqz2boQk8nw
N29sLzm5cH+APxNcju7sz07klp8dRNeImbmgj8mT1xId10mAixJ0NOY8udLhlwg1
UfsYhP+Yvy9yMcoSZOs5+RjluW/E2qubP3RUt81ohUupdM0NVUJiR/I3Ri6ARb3V
S2aAGtW4oS6PpyVT0dkWrlp8VqFpNTUKE95dNi5Og4kCTgQTAQoAOAIbAwIeAQIX
gBYhBBTyZoLQkWzdgeN7bWG3tSbZjwNTBQJpobDuBQsJCAcCBhUKCQgLAgQWAgMB
AAoJEGG3tSbZjwNTpYQQAK+60Ky1K+VzJMVvjTedchr/ACHsjRXDHfJHWp2hDBDg
GLjr0Muwo3XIaNyWhW1fwmxvyMULFVmWGb7qGTeI82O8yhY3bLMN6iA+XZwf1PsC
ZYHTls2KTYRUHYixobOA+9L0mWqWriNHeoBXe3c+SZ2jNYe/o4IR1X/zeVVpVkUq
pzKcKmhpDOfgWKZBxrBRFUm0wJnFrL+AcjVpeQi8CreR1AXzyRWT3pIGfpYilfTN
SZNy7e3oruplcu0Jk3aDdtTsJP95aej7nyI1eBdAk2hoMe4o2jCweaef5LO0y8u6
G6Kie9/LUAqQZVQuU7Zce0m0l9MNPujYv1pUy5RkMxtRyrUOJQLP60a1f1WZgU2Y
Om9OgS6gO+NoZ7fr4/5wj3C8Y7Hyzn7I1KXkvj+v6CF6u45xDPdfC5qj9p5HAE81
bPmUpXFkeeIwn8La3NJoVjiagl7OxuoFi27F4oKSGxnArPtIoiQYuIVsZ2pPvkhP
Lt2lLXbi5vGHfPKhK/kg/mvkUshiCK+jTpYZ078eg+meCFXOoRNH6Qkd7Q1MgrKz
OGAkuRVNWtnx1Ata8lxEqYuhaUlqW7okd1fNSdughtvZH5TgDUjlzkAS1eLsFIRC
qZIVBRUXgQvU02zt2OPdBuNgiXqRbZcSmsyKs1X22RG5i9WmTtP6Rv+ZL61pGsVA
uQINBGp0aqQBEADF5R+Xdp6U/SuormBFr8aSUAidp5f9kAEMNFtAWtDacRp/uWAK
U1pcC2bTOuMXDdKOq+2HG9mKAGBRP7ZJEBGrFHMj8bAK9RYJ4PdmkTbwQt6FrVs1
G2eL4PjIM6Y4DQAL8nQhuFyp4jQzXYYRqgi2a0y/JMiOQyGKhwCjRwAlJrBUplyi
mPJ4XfmtGKTj/2rcGQq4mIdDvCs6+YMyZRy8r8S8wZF+ysLpsEbqQPwgzG2uybF8
AMv4jcBT+c7Wb9WgQsnrAlQjsRoRgcS8swwIzm+ZXUMBwgv5zRzO5G2YCpuzuvx/
0/U0x1fJl1fpbW0785c+B+gIZMWmY3gdxl0JpqIpKpHj5GXXSBV72HmsOBUzui8u
0Ux2KlFlMvRL8IX5VPoPwOUzQazJM15B+5iToF3JmYlIRod73BQHrTj0NkwTFO9a
jRZCteoHOYOYY/o3lJGNFwSIkqH3Z4wa6P2Y2xpoejH0xsE25Z2NEp2H14/kyacJ
BF0Hq2Th/Bou7MtRr3ez43zt7h0v5GKL3JLAWfz5kit/Ux18h4Imqzsl/KSelDJM
4eUUGipO7dFfqO5MU/juqNt8RjvcIDO8Cnt7M+j53bANsRPJY428FiD3nqc+2WSS
EbmRaWq8SzNz5ywNeeJTLac3UvxUlUmskN2+UIM8QESHzpv5dn4u7x205wARAQAB
iQRyBBgBCgAmFiEEFPJmgtCRbN2B43ttYbe1JtmPA1MFAmp0aqQCGwIFCQPCZwAC
QAkQYbe1JtmPA1PBdCAEGQEKAB0WIQSCfmWGCGeWGM00n5NnjkVddnZ6owUCanRq
pAAKCRBnjkVddnZ6o8NvD/4tvmeD9UaKxJKiQmzL1yPBHT05M34pI3s2t9T0uSJf
hjz8DEzDruiuhTpwweTz4iOU9NBoBSGzmxYfrFE44IXvgNKMUKtoHWAFXt+3SEMP
eYOyXFBhWBBVQ6FO+5Ka8cHKfTbhU9TiLQhyCHwulWMZqLIHgGIaX3WuDEQxINbp
WXTIbkyLml3FlH7BeRCzJBGZm1TelosYSu3xRybveZr4khhSGNrvRuRKHYBT30qm
9VNkfHexvzg+WY9rif51iTCPnBk7XdPslHSe4E2/uuZafOCIHzsXlq3T0/Dqzcvw
7elaGWRiG+txo4bhnEnML6H46V7s7gqb+sdSUVVimHuq7WFWnojcw9Icg6yW2x/y
F6DvCXGFhUbP1GFggwLMIg0gbSV9wyQa849+07R9oIXUjrlliB3N0A8y5F08DCKD
6FfPjb3zZquyZr6f37RySoMXgsM6c4rlKPbR6Dks5Cjg6dHLfmCrLOX38bDJJxhY
ys1NXRSlH318ycm0wdiou2O9wV8sXTXcSOK/dc0M+g+QcA/23Pzn35lOiIlUHHNX
lD28CPhbjxjHoeUJeV+p6mux94FZTpaFSj1DgtMtP7hQoxhR6adF+nRK8rzSzyAx
TqzSQYpNrE5oJvf0QkxHScVR3uPfo8Vi9UIYVQRhoaUsIE8jlqTK3e7XLfiJ7v1j
GhwcD/40zySQmlQGfxSDx7ABR77qQTY/xjzXUKGpl6YecLUYV2FCpNYQuXGHTRcJ
jHpezJFkpzvZqpi67ZZXDX4Xz5xBXYI0UCAlnn1MrMh87Jygo5zgcxS7BuZA8YcD
6qbtkNtvuPq6vOsnyf7cFa6IbcZVTfeBN84ehy0oy6mWblYt0nGtZXc3+JoNfeCq
GRZ5iHZqopf7xL0cS+01+uNbikfMwnl10hVjP3zl9TI+D8Hm0pskJ8nZqoZBrupz
s7FR4+NTH96JzQxZFyV7v+LayOzf+M0FPrfspZkH933xABiJ/98BBCJciAB1KDAQ
SUfl+lm5ZEzOiXgMeOVtyhSUjW9Tgf9qEQtgs1+TcQ+LzrWcKCvAPXXEdxNvWCt7
a0c1MdArfBCjKQq7/65sibTdE6nqR+waDlZ14N3IbASf92sIrdP/S4KuL9R7gCGF
f23xNvIAA9DRmighFT1iymW+aYn0Wk2UFSlSisy1TUTV5p6fCIJ2ioQTA9252syA
pEp30Fyj2jC5Ep4PvTOD1cmN653DYLXVwsKMyoDcvWgQ7DFJGxhpkSKOoMViaZjQ
pFB9zEn1W389/OiXGIch+VtM9jhJvpEeuc4XaaZ34ED2RItO2QuEkRTpW2YPxegM
fUjVNQ/45uJ4qcFCD3/stBVB9Z1sr5bda+9dBAtRT2TgiwRFsLkCDQRgos3VARAA
tSRABroykqOO+3Zq3pehRGM2aft2djiigKhhVg+eJr+YffIU2Q73l9zniYSzVMkF
VuJPd7WkBnlEMIn8BUGh04op6MV+kzX0guu3v/9i/0agNS31xAdXzmf1i5sbQU1e
RylyZRSisM2iuF7BYrfSsOBHv71cf+iM94KxrzXiB1bDNL4DN0T5+vCoDjgHaXbt
en4Qdm6OdjBCUv9Ix8dhT4OzHwHOUK7gomTrQM6Hyb0vgQsDXKV2Ps/pWOSk/J2c
CrQUrafFqkVAAC3m6kaGU8te6YlAU7GFcf4MOPw15WTM2iaKWwPkwK9b/Ro/5RfZ
bqnde8EBAoFkg0X8mshGVDBtYCaW+1qUA3ZBcQzUvosYUsNQC9Nx8Y9/tkqCwIBU
zsxuIrSYHxeqPThxSMvCmg2qHXmmbAxsbOz3DTOwKpWSRGOCTGFpsLBqWigjG+L+
9iIx+7kr2gH8tYck1RPyQm04k9udD8wwXCvylTUzNVd876sN3o1xySaO5nz8JtM/
/xPPctFFMZmC01bBn+jRuapDqY+qTFL+eKherOUZgs3nHt7cEBz3m8neGg0/JhyB
wS6sQF7h0ETBapVDlKCRuvAgJHIrjejL5v+kVRrH9L6ey5CAdRG9SbffsNwZoo5o
8SrdGcX6hpFiqg1jZWvZv5x7/PPSW7fPuNNHsoxVRn8AEQEAAYkEcgQYAQoAJhYh
BBTyZoLQkWzdgeN7bWG3tSbZjwNTBQJgos3VAhsCBQkDwmcAAkAJEGG3tSbZjwNT
wXQgBBkBCgAdFiEEQ2D+IQnEl2MYb44h6+QekPbxL20FAmCizdUACgkQ6+QekPbx
L22N6w/+ObmFWpCr0dmV1tm+1tuCL05sJ031KFl3EkH389FmrMMoVk49e7H5Urn7
7ezQXO9Me8R0nZgVUavJdKcJzgf1IZtLq5Vq5q563I8gglr8rJaaefGYuv9jitx/
Ca2s+uvJMUHgMeBPmFFOKoIF8QgOJdkSht2lIkd6bd89ayLLoIXlGi8d6K4tEWeM
igtds9FYcyX7o8xXmt9XqCIaMbkJtiUzjz63dN0O81UCj0TvK17KXAvclhzrriZu
o2rOeDTBcQmKKy2UKZaJjUqiezuOg1t513ZIzhy1oXzg5CJb5jgsmZmjtJjr161f
v5d8Yockj73z2/z47wry6ThESfYSkIxJIiIP5SwZyNMeeHSZUnaMTqzd5kDL5qnN
rhJHCBByxcIBcGppv3VjZ1QNU1k0Tx+MzpfZtbE//idw+Q7Iz9T/3zjN79JhYi1t
zzaaQR6JoEiNMpHHkdkOGRwfdipM7oKl7HKl+zJCzaLTE4mbInCxSgn+1RhI+rGz
TXVxqIKonYrWra4EVBAgguMrxNMjuEtbsF54Q27x2+H/Mew+et6K/suqyh63Szfd
14LWEj4NaR89tEz76nJyJFuFtDeGSmu68/Pi5S8Ls9MxKJJiIJmc3lQqDUTHEiLc
7RtZAsgAWlLc6UnFsaCqXKJxuaMs7qFD7pqSGfHxYboBxax7Sqrttw//eC7rghiF
zfcnEZQn6+GPW3FJc5P1diSLto99six3uaWKjvSnZScvPOe8ogJt1JQpQAABoHfd
7HzzlGzJtU/yDL931WD6nETp6b/dk7t3aUpk8WFMG19L+L9QbEpjxDi2wozO7CGg
6FhC7mu+KsSsorLqd3QYKoBLG0Pb2K3Zz3PN7y17kf1Aixa2//prFNfpEGwP9flz
2TUvSdtd9JvcnDz+/3yB63tmuCsUPZaR3lhTkNiXZG7WTALA1AqIUKFpxI+cOQxa
O2+H6XXiON3x8A2Pzd1mZyuUMPk2c6I/c1ZfzJXxF/WJVfuztZXNCGocYF4kB3X0
7uOuiKrIDMXDT3Op3wJ0RInpjyyPlwwov3zIVQcG3mfWPclXNcIRSAdadLq6yhTB
UVbhMd2j2qga1vtaVlH/m0zFhib88RLf1/FiVX76D1q+anG+gT+SsMPd7hSGQQ2+
6ngBAvx4T1IHtFgPqfNaA49m8b3aAorGo6Bbzmwh4Xr+7DM2fSskBskGdIPZgA4V
yu4/PC5aCTyd0NqlBgj/g7XRQMGvFRkdnEIcVZbvxdzn4j16dS+43dUzFMLKThRb
kUaunaYoZPIYuiqbwCoFX7vJdgBMaTxYfkClc5LJSVr+X+9RYNwlOn4kiQzKstVt
l/qfpDow6QsGmA9J7v8Vt9JEg052REcZZmC5Ag0EValA9AEQAK/z677fpoVUj4zQ
z0g60wVWf+1y2lGb8iFYICmvrJyaEra5SRkyihYA1WmEzhN4T//tHw3UIfe646+G
kY3eIQW2jY9DM2XaElmMN8k/v54nbn5oD7rNEyCTFTvCOq5d74HH1vw96Lzay1vy
45E7jPWvqfg9Se8KAnzElohTJjizyhU+0QbmPHnQlY8gOkT/SvRo9bFEUnqjWh0f
Rq+K1tdLPhcFB1scc25iFqh9IAKUGDur8jQ+SDHCjgQlkFOg3rbqtaUOnVHPohfr
BM90ZNwuneFgQY7ZFSUidCimp/EN4CXnzgjDYXUUA42S8G86+G4KAJC22gRQo4mc
VmehwHTH0glfLmUK7TEu29A1KWNL3R/R7ZdyajjpCvUaK2A0Abj3ZE2BSDbJrVlb
BVfy5kfPdZjhd3wUWqFaDHiVcImcjZRWPncllhcy6fhqEy3ELZrkezpJjnARsVki
j3GXz6oX+HVULne2w0dkTXydR6muZI/GeNtrLHmA8B3/0/TllmLy8ChmYZVIKZ8z
t1ghq3f+hFTXgtZil7eBewZgA6L+EXXK6dZj14lbe6CMS2kungTX9stU1s42I+WR
biqiLpAxCX6qcLBOWrJwsOep2nvu5bhrPHptSfRhF4Vs1xteVFckCWhcLgdYi/Je
1XBEM+AAVa0k1FiywCg7MqlG6toLABEBAAGJBEQEGAECAA8FAlWpQPQCGwIFCQPC
ZwACKQkQYbe1JtmPA1PBXSAEGQECAAYFAlWpQPQACgkQHGnE5V6ZBdsvxQ/6A62Z
teN0b/TVfSJ51SdG66amwe2rpRX4UdSw7ifxo3qhgEICQmXR5c09qXwl17MFJWM3
FhGrbxnA5KGgeWGtqrPup4QZPKU+l2Ea2QLSJSiBq5QqqEgZvR14Lhr/hCGhBAq9
s/xbp8fbKNJj/uWiZ+uTPbt5T5rgKJ4+g3B6DNO1rH7F70OLrd32mxZs4pSxngHR
AyiMPB59yQVDsVMha0JTqC+P96itUzvnInc/9mwE0EMiBtpDTkoBwbJVPnuv+7Fj
kOLn5s5u3RLH9fe8z1xnV0fPC0/ndrlNiuBpAn3zVCsWasvW18Vz8K+CQY8Sw0Jw
75edBgFoz2QMFxHfDpMJefvMadB7mdte1lKk/Im9KFFH8Idh9b6zD0a/+Ooujukx
6QpFfAVhe2sT2CIm2nmMAuAZI2cCt7SC+REn9n9MSuIWxN8YTE3qgAUB6F3ea0O0
hGlLl+z5UOfX0bNAs+ebx/P6PczJtDzeqpmRb0QXqo55JWXLvmXT/fgjF7fNTTLs
yCtV+xH6ZFKGpvGJGJMHApEbz2a0hy12RZH58eI1ueN3Tzn8nI57+oYSsqFw/Qgc
dGXDonLGJsPVzIpQRg92/GXSukWF+MsCjVOilHRSY1wfPPmJ7+kMQ4rdXpjAhwNY
Jc1ff5N+omCxCKoFgYsCXlFCHFKs4JwRbTdd3MkuqBAAlBlIjym8NyJIBltfWcku
hQTX4BiBltGPNga9CpQsml519EePuLtoe5H0fTUp4UYbL0ZzyJImQE2uw/hMNZ36
bA057YtHOoP4FcPUwv6wsl5JC87UR1XFhAXb5xSU0qdi3hWh0hm772X6CBlM8lM6
GtT/fDZkSGNXMQaIs1X/O9vf8wGg+HwLJcaCvybI4w7w1K0R7WjWZlJXutCZf8hR
c0d88W/qSZYooKD9q2S7foqaJhySIaF11sH5ETvVP3oCfGVIVhKWb0Tp2jXPXlXL
eRAQA8S+4B1o5XHiM+J3SNXhPQHRGQ3VGcDn45itg3F4xQX2Qvo4SV42NMYd6Tyk
M/dIfQyJDOVg3CT3+nqfjCknf94SNvyZprHEPmpcDeseoPMw8kjKNwDwPXFLxBRn
tPgnqVXDcNN41OH2kqx4jF7FLlRmwNpB2mFVH8xeVuRm7h2WZRsaEoqvivhzRtES
VA2um5Eg763CVTcNYlK6MD/iy8JzbMuZBrlOHr58HKDdcOy1W0z2quESGoqrwA99
5IgPav/1DSpyuJPNc/oUTWlhpYshqYKoflezAyKj30+UzC3R/mY03ri6zUvCgXHN
gZlKUsM3VEXk6h5oDuaXniHLLzuxjTBVrILnGYgHSFRP80L/knz+o4Uvq4wj7NHn
ruc5fP1foFxRNsMt40yRJfW5Ag0EWUvZtQEQAL4dTYeBoI6UxWcu7kERc+Tz13WU
wSPmOIU6RdoXqBc2QyOki8s+uDqIJbpt2YJUPWnPgoU0rDt+msOG9tpAjPVg5pHJ
e8H9tXxvaPICQ1YxYw1m8E1kRGio4EurP2G/H/YI3vwRskqI8cp04t88k1DfeKvX
YVY34kO/VM12XTfRcsiMdmDubTqNPYU1kmYNeqMT+OzI9QE2kulCK0DHDJzqdJLn
Okrn1z0lrFAPoNpVtHZh4D7yB8FH3I1qk9npRdNXvSjhXu4ptvRuszktjEcfHK+i
kYP3jVqR4eWiOKrkVIWJOCsOKIUE27PXndGLbUuDzCvrKusR6W9vF+mYK1p3pT2P
YX8HEeJuzrd1UFBvCWPf2k5RQqHk4JIaKfjAlCPnSXmPHXqSGtD083RJhFkbz4U0
7/glHWer+M+Sw+hYT/v+XOhQm3CG/PUaeX2ud6GFefymX/tA1FYJqVxVOye2axoA
3lO7yM5sK/JHMdL7bFZtXVcGCwAqU2mkD2yEkFAzPLBHKigKg+4VimsTbG9jPOS+
qtv65x6uIOOsic3Ud2/BB/lfbvplIvQyJYw8HKb8O0XkUPcD3Q1i8p54JSHhiJm4
2H699uMmiJeLzTkQJG7KApEv6nOb+jLyr2DZXuX82/UvZAmzWZg/XOf2xz44/RDX
kL865dqRYenXNaOXABEBAAGJBHIEGAEIACYWIQQU8maC0JFs3YHje21ht7Um2Y8D
UwUCWUvZtQIbAgUJA8JnAAJACRBht7Um2Y8DU8F0IAQZAQgAHRYhBNzqxdlhNbkc
TqZyq7u+vbskxvNVBQJZS9m1AAoJELu+vbskxvNVBVMP/21uU+8NpPLpBn6SHJtI
AffFYMSnp0gplOjfiItA8HDbc1vqZlVpdk2xyFw6b7g+vTg1gQzF7uoAZK1czRLC
t7ocxntLVgPuSO1ZHt4hJG5Ze1UUJSDq8Pp+TTL43rg6irDLdYDBBHYESnXWAKRA
IuPb1e156pAdpSynwJ3+qPyqj5vDLkPrtMWGp7qWQpXcHaXMea8m4+/RLNIjvRof
/t6jrUermzs91Z+/C3N8ugD/aZrXTiNkF/H6BiuITZoB0j+rjy4fxEQvTYq9C3No
aBIRxJEPApxGnHKe9K9N1ZBELjCUCT1MkbBmf4CJtEgJvSScVh1yZNv+TVDfN6Rw
F9CwOM8bVrOH1VuX/L/XiIRRT02eGrvv3EvQ+BhceJpWN+GsHKQM658trZ7RhHo2
PR0ib+D7hWQprcktqutTfRFPMrgcFTPXKeR57cxvjk+B2LoLSOom3oTNEtUaMuBE
8E/jbONX34QsHWDKfLc3XpLEN+bO65AfTiR4/qtnZBmldBUG9xbrW0qcWz+M5P3S
6ssbor3VDxxrX+Fv6pJccwlgYNFQxQOz8GrZhF0cU48e+0XpU2NFeyueHQ8lb9yY
dvhc7mkGc87iIb+ILah57Wqi52Jd4f0DS2zkxN6ab5/UVEkffNwXfjN0IW28Ga4B
tZvoXVGVJo4vsGytMFdMRzRB/uAQAI21c3TTrO4TL42NcFQ0RY7yAlaKzXTXVNxC
8v/QQKIsDrNvs4w15rF/t2LXc8Cr3aUNuDtE7x+FaNwZLypCe+RFOy66AG2ENuNt
5tTGN3mgbJZl+01Cd1xPpOzmRfAJnH7YD+J4QuCEEgraAXPfp3MhjeHWtQaWDu29
fbTtPx0k/Bh0qxHFPWxhnYpktnjZEoMmwPMBeitCvcr66UzUmezgVZc0HxJ/LO9B
ss7P3egv60wPnXn579wDGnIriDUhHRcn2KuMI7eT4pL4HHjAAJB/8+vcUzYPuqtx
ULf5ciu8V+ajzHtqBcgwNR/gm/7i+4qKPo14fYBftH5PDj9iD88WIQX7paVbYHJZ
jrmnpM2iniL/DRVuxqAPToIc4hMXj8YPeTqS/1ckOzyYgFI9aRaLxZOR0uno1WTR
BifwOcy3NTwSHK/6YbtJbqoVwISJrGUuvOfBlkJZVlCzVsPG1+QZaPAL3HxVXavY
gCu2hze4OOWUe2Xuqihw8hb+F1rhP64/QtpjPxgLLb1NIBpm6OgdZjRjCbl9xnd3
RvH6hYxO+zgdn3icn2fFHhdZ7xtYcZZrg9QOXuv6LDvVe5I4VyszNs0jtdcx0P+T
5VIrKFAYyf0CCuL/UQTRrW0SrKOV/RZHuvdpVYK3YIAyd49kKjLk6O9awFQy7cXq
3PhjatBiuQINBFzwOeoBEACt8eaLW7jX3n5tQQ+ICeGOBIVbzAnXlH9bjdTqollM
+iiwkdlBNNEGku7+uQ9dTofem6cbSUXuh5kJNLy5tUIG4oGZLvpAjLdHP8zslgTg
lQymoWSbv2ss4pq8xoDbp6E51dkowkyFSuELZKMFHgPiJbfYXxQmbwEiFhGs4+21
lwtI4tVO9zs1XbzJD9XtomxkcYaePeBxpI9JnrWIUKt70JPZi/QcxPMG2si/Yitn
CVamcVw8Wri+W7MAJW3SyNjJUqx/cIOib8vdZVxvdWRIZmdkWkFO6vv4IotEBCfl
t6cD0EIy3Ijn3nDDf59v7wpdWXidjzVjKF0F8jUiX6S/ZuEz4lvdotpCgJGhDmdi
4pVCYbmShKbffgcSJ/BWn4wCOHKPA+XB75zzPj17dcWR8D9GM/sgusJy2fbHDcOd
ADPynKW3Ok1CENJDx7DTDwm2fPRMut4utSL1FMSl7zBDRabcPr1nw+zERjmSjm3R
91ayrQ9UKlP/4P8Xkhjc3FFWrRQ1Q7/SlkUmrTqSouQcOolGMa2ENNgqNeOY7oE5
xnPs64TLAzQ9z66u0dHTMODAS1A6C0l66LrPVYGoQLDkM7WQn7zznFdnKR2nsPOU
i0mMdyrG/62iARtNvuF4xdsUAoCKti3wOsXRuUhiXei4N4qdr8IaIEIFgYEKKtaq
zwARAQABiQRyBBgBCgAmFiEEFPJmgtCRbN2B43ttYbe1JtmPA1MFAlzwOeoCGwIF
CQPCZwACQAkQYbe1JtmPA1PBdCAEGQEKAB0WIQQJezEwd65ioC+E2k3xpmaPu31X
LgUCXPA56gAKCRDxpmaPu31XLopQEACKv8mYt4aMc0oA25UJXMRig2lXJDqOZBUS
vFFm8t6XgdG0zFdzFo4gqpje68kNyt9duhvOMsVwkzUr+5Di7FccvgwceU3X5ngW
pnV/GcXg79m5viipWUdBRoyZ90oi4D5K6fhlmszmWyiD7KDrjdtIdGnjAuprztkc
/JBlIwlmu/40JyDR5Dfxp256DlzsJ/HH8LbdjJG/F0XvtZUwcHefa7mDXtIWszsM
oJnEoLzOkZvJ13rhJcTHVQImClyS3o9+Pk6DTfy4Ad0w+9nF0rZp+8/GXZGilfn/
NXMj0elYu5WiyCBqargRkrHpebNKW9jxRca02aDS2Yrf8dlseO1d9FXZPOBWIxDR
G++TqRhBK8FUW00DikRDrrV5RsIiXtgtRqH+hwknE33i8m8/KKC5/pUl3Af5f+vM
KsT3s1mMX2zA+NmLUxJCXLz70WqLoShI8QEj+RLk9yuk97bo7KoNSv6xNwXotJKz
p08VAnVNX/QddmV6Z7SnocEs+S6Z0L69sEffMgUaCkH09mIt1yu0DaeOl7fM2iD3
VcO6jJ94Dg8olkhBgrZERe3sXR2fciFtsqHxYc9zP7YyL7vPbUQ8BogxEfIQZPGd
pnG5pTM0NSX/mgkOWI2VJFDe/rOFTdTk+8mKVnFdaUfHA48qIeS0V0zMLd4OZkrY
lW3iKvZps6IAEACauiivWdvKvJgKMyi3fvicXn4qL8nV1X6lmOBqDn4bb0N0mtpi
qXfvG950+29rcCJSj6qSMVj8ZHuwVktrEoWX6lpJbWwEdUh+35DnjfGOYN8gW8bx
0CfyqEx50W++DK5Wj+L+DL7jgJ/l7dMKxLdjijkg+v4yI516nzRbrx3x77U8n+H1
V9bHrDfScESnr3PtWS4ze4yDrr9Xp+YK8A7RkIctH2ToyEixin8utvfa56dGpUai
7gIRZ+0btWY0FX6g/VRHwwhLIzTsaFveQGuzFbXaGkOhRASitKtbQo2fD39qAMix
kKOctN9A/nA3dZU8BlJj7258+P36jQDOilr2Y7RlTSTZS5aXeAPbwILwKCNcDjV0
keerGSqiV2zkiH0vAJcxVokn+iMj6VOaM1RyxskgFara0Vt3IuAjnirES/OVuIkh
gpebmGXBPcHqLWpFDtEdLv6YtOwScE0eYb5/SA3XsmK3qgzEAzBfchwl4PqAhiQA
f/tbx5EgAUbFmwhEcgd9xMY5w6+8/5FjoXwHYmdfjKT9iD7QxF3LnymskoKQQGWB
HiwJjaA8LYPpopUg9we00zNdSGNXv1Lau9AM//ATiusH8iLJj33ofQh6FviQG6W3
TlLPqx/oIxxNj5bPAQy6dRKB1TxlWr4X0pUWxuqBeObPoHS9j0ysxKPru7kCDQRk
VUBzARAA1cD3n5ue0sCcZmqX2FbtIFRsk39rlGkvuxYABsWBTzr0RbRW7h46VzWb
OcU5ZmbJrp/bhgkSYRR3drmzT63yUZ62dnww6e5LJjGSt19zzcber9BHELjqKqfA
fLNsuZ7ZQ5p78c6uiJhe8WpbWogbspxJ20duraLGmK4Kl23fa3tF0Gng1RLhoFcS
VK/WtDZyC+elPKpch1Sru6sw/r8ktfuhNIRGxdbj/lFHNVOzCXb3MTAqpIynNGMo
cFFnqWLZLtItphHxPUqVr6LKvc3i3aMlC6IvLNg0Nu8O088Hg3Ah9tRmXKOshLjY
jPeXqM9edqoWWqpzxDTNl6JlFMwP+OacMKsyX7Wq+ZXC/o3ygC/oclYUKtiuoGg4
7fSCN2GS3V2GX2zFlT6SEvEQQb2g5yISLX9Q/g9AyJdqtfaLe4Fv6vM4P1xhOUDn
jmdoulm3FGkC701ZF7eFhMSRUM9QhkGH6Yz2TvS4ht6Whg7aVt4ErIoJfj9jzJOp
6k9vna5Lmgkj8l19NTiUQ7gk98H3wW4mRrINxZ2yQD47V/LJ+tUamJc5ac+I0VP7
c15xmKEJ2rfGCGhiSWQwZZw7Y2/qoADSBlI28RlBTuRP2i6AdwyJU+75CzxGzMpr
/wBLhZT+fNRV4HHd5dgR3YxajpkzZ6wXL2aaJhznFEmLBLokOwMAEQEAAYkEcgQY
AQoAJhYhBBTyZoLQkWzdgeN7bWG3tSbZjwNTBQJkVUBzAhsCBQkDwmcAAkAJEGG3
tSbZjwNTwXQgBBkBCgAdFiEErdcHlHlwDcrf3VM34207E/PZMnQFAmRVQHMACgkQ
4207E/PZMnRgdg/+LAha8Vh1SIVpXzUHVdx81kPyxBSaXtOtbBw6u9EiPW+xCUiF
/pyn7H1lu+hAodeNFADsXmmONKcBjURVfwO81s60gLKYBXxpcLLQXrfNOLrYMnok
r5FfuI3zZ0AoSnEoS9ufnf/7spjba8RldV1q2krdw1KtbiLq3D8v4E3qRfx5SqCA
+eJSavaAh3aBi6lvRlUSZmz8RWwq6gP9Z4BiTTyFp5jQv1ZKJb5OJ+44A0pS+RvG
DRq/bAAUQULLIJVOhiTM74sb/BPmeRYUS++ee10IFW4bsrKJonCoSQTXQexOpH6A
AFXeZDakJfyjTxnl3+AtA4VEp1UJIm0Ywe0h6lT0isSJPVp3RFZRPjq0g+/VniBs
vYhLE/70ph9ImU4HXdNumZVqXqawmIDRwv7NbYjpQ8QnzcP3vJ5XQ4/bNU/xWd1e
M2gdpbXI9B46ER7fQcIJRNrawbEbfzuHy5nINAzrznsg+fAC76w2Omrn547QiY2e
y7jy7k79tlCXGXWAt9ikkJ95BCLsOu5OTxPi4/UUS2en1yDbx5ej7Hh79oEZxzub
W1+v5O1+tXgMOWd6ZgXwquq50vs+X4mi7BKE2b1Mi6Zq2Y+Kw7dAEbYYzhsSA+SR
Pu5vrJgLTNQmGxxbrSA+lCUvQ8dPywXz00vKiQwI9uRqtK0LX1BLuHKIhg4OgxAA
nmFSZgu7wIsE2kBYwabCSIFJZzHu0lgtRyYrY8Xh7Pg+V9slIiMGG4SIyq5eUfmU
8bXjc4vQkE6KHxsbbzN6gFVLX1KDjxRKh+/nG/RDtfw/ic7iiXZfgkEqzIVgIrtl
Db/DK6ZDMeABnJcZZTJMAC4lWpJGgmnZxfAIGmtcUOA0CKGT43suyYET7L7HXd0T
M+cJRnbEb7m8OexT9Xqqwezfqoi1MGH2g8lRKQE4Z2eEFvCiuJnCw547wtpJWEQr
Gw1eqL3AS8Y051YqblbXLbgf5Oa49yo630ehq9OxoLd7+GdWwYBlr/0EzPUWezhd
IKKvh1RO+FQGAlzYJ6Pq7BPwvu3dC3YYdN3Ax/8dj5036Y+mHgDsnmlUk8dlziJ0
O3h1fke/W81ABx4ASBktXAf1IweRbbxqW8OgMhG6xHTeiEjjav7SmlD0XVOxjhI+
qBoNPovWlChqONxablBkuh0Jd6kdNiaSEM9cd60kK3GT/dBMyv0yVhhLci6HQZ+M
f4cbn0KtayzuQLOcdRCN3FF/JNQH3v6LA1MdRfmJlgC4UdiepBb1uCgtVIPizRuX
WDjyjzePZRN/AqaUbEoNBHhIz0nKhQGDbst4ugIzJWIX+6UokwPC3jvJqQQttccj
Ay6kXBmxfxyRMB5BEeLY0+qVPyvOxpXEGnlSHYmdIS65Ag0EZ9KQfQEQAOVIyh0s
ZPPFLWxoFT0WhPzHw8BhgnCBNdZAh9+SM0Apq2VcQKSjBjKiterOTtc6EVh0K2ik
bGKHQ1SvwNdsYL01cSkJSJORig/1Du1eh+2nlo8nut7xT//V+2FQyWFCLDeQvLlA
s3QHMrMYxTcwNk3qi/z1Z5Q4e6Re2aKRU00LtSomD6CKWy9nAaqTRNzzdndJwIyC
yshX4bbUzAzE7Wbgh/E0/FgBGw87LYITqyU6US4lvoUXB+89XxwMxO9I74L118gX
Eyybz+JN0/w87hXAKnaKjasSvobKE4mau8SXqmOO66MxiMaF4Xsmr3oIwo8q9W5d
+hA+t225ipq2rZZErmPL44deMCeKmepjLTa9CoxX2oVpDWGOYFRyJRkLDyyH4O3g
Co/5qv4rOTJqPFfKPtrjWFJKGf4P4UD0GSBX2Q+mOf2XHWsMJE4t8T7jxQCSAQUM
wt6M18h1auIqcfkuNvdJhcl2GvJyCMIbkA3AoiuKaSPgoVCmJdbc6Ao9ydmMUB5Q
1rYpMNKCMsuVP9OcX8FoHEVMXOvr0f6Wfj+iHytfO2VTqrw/cqoCyuPoSrgxjs1/
cRSz5g9fZ0zrOtQyNB5yJ3YPTG3va1/XLflrjPcT4ZUkej9nkFpCNWdEZVWD/z3v
XBGSV11N9Cdy60QbD4yZvDjV2GQ+dwAF1o1BABEBAAGJBHIEGAEKACYWIQQU8maC
0JFs3YHje21ht7Um2Y8DUwUCZ9KQfQIbAgUJA8JnAAJACRBht7Um2Y8DU8F0IAQZ
AQoAHRYhBAm+7WPzRiot/6s7h17LZJfBogJWBQJn0pB9AAoJEF7LZJfBogJW9I4Q
AJbv4Rhb4x6Jl75x2Lfp46/e3fZVDhzUdLjK8A/acRF7JRBuJVJRaijJ5tngdknm
lmbzfqlyzsMWUciAwVJRvijNFDeicet5zJpBRsXEUAug3iVCD1KlVvLzjCi9Eb9s
6xCQjSJ8DZE020s41wdqtb1nziDASAkg+YH2DzpTEaZVNM39uNDKbaJLYIjKA9MV
1YHArqUldFsoofBe4zIZRFyvMD7Gmr7Xm0IWYLrfmnenm1JJYIkvGUeVoP8dEonA
VhLVwvwwufobV0qdtMfhZsgFwf1XSHI9MtD4yAVtBqBTkfFeRLnBjJK/ywYxGqba
dt1b57I4ywTQ16oXNrlTF1Su0I8i/fo0i/9ohNl3opN3LbaEbhT37M4xpy4MgL2F
thddc2gWvF/8TFRaXw7LaLSR7HwO+Y0CpOtV/Ct4RzKEulY5DpV9b1JQJhpLcjMz
+pBDAM3KJuiV6Bcfoz5PZowFy74UmE02Vzk/oyuI/o4KMihy0UzWQVkOZTTu4eON
ktgGiZOnRFdiLKVgeLEDXTLdhbuwGS2+wX3I7lLP9AWpK8Ahc81eUwU6MwdbfwfJ
1ELtKaa/JmMjaWkr5aGrp88d8ePR9jYA47Z2q0esB67pRJVe0McVJlu9GQGq05S7
lZKs6mi9dHTzeHwua//IXHMK0s3WhMU7vGwJ3E2+pTstf8AQALSwkezD3QchPV+5
CAUYY7CmMXB6zzIU18wCS61Y8QdDvqmtWHdMVTp4xT14fS6cvB4uFzacGQJ7CVIW
eZgwEFzZiev3dKpnUOGg0WQSwmQQA0JCg6/qS0AeUPINjhWtNcR7voCqAYeRcjo4
7UJclD/KKNTCn27btHRaEmpTdTtC6sxiVElFObb3a9tHXqwLWp8gJ+NZ+6mlrvvH
2hm1CAyQTDRYC7nN69QJrKHR8HA3AeR5figQHLwvmfQlV2erZE17GT+L5t0HxX/H
KZCim91PApqa+7iY0eKPAG5iacABrBi9zzh/ex0ovvuxsBDKUFCSu7HIivnAVrdS
/kbO1qJ5I3MBMp0dlQ6PS6LeZIRhxts0aPPZedsXytoL7kFLISfJ55AuhJpskz+5
5uviJhp/H3zNBYtQ+dmFmp4RRk/Nvu0zv6OGtaZy6M5X24Pbzb/OApBML84cEmb3
iZie9J2ZYW68/D96sP09x6GItCJlCIdQZkRcwmkQwgtq9sJDw92/vSGeYdRn+oCA
xJ14eObCsVwcfJARLt45btEnx+zRCAHAHQHpV6qTGT6nqg57XuM9iNNdyTGKRU+I
klgb9LRxVAQfbn5uXYb5j2ox5pjxtbXTf9Lbo7RkygcWSKZPWmYgGsKS6jmXkDa/
TyOlPxkbaknpPbYMBztRT4Ju0VU4iQJSBCgBCgA8FiEEFPJmgtCRbN2B43ttYbe1
JtmPA1MFAmp0bIIeHQJXZSBubyBsb25nZXIgdHJ1c3QgdGhpcyBrZXkuAAoJEGG3
tSbZjwNTXUcQAIXCoftSFWYug+FmtfkQm8JFRA7NvcK9FcWLpknonbTj5XFhdj5X
EAdaYCPhit78h5iMW1nEEt9NAjuUCymqIYejHgH1G5TAy+bqmceQwuWJjy1JJ4V9
/UY+KRW7btOzAQINFfXFYJU/9nyCf8ToStpra/C3SYL/11ahsL++bmGx2aXF/l3C
BwuQihko6Amg+VbKCjT0ddzNcY6HaDWu/gZWbfyyGWlNt/Tm97okS/JJoXsX7rnd
zoqRBPv+rpJT3W67HfglPYy+1pUMfG8rvt9NkBf5A5onIs70j7A0NtSwgXveH2pB
CxmocGThQYqh75LkqSWCSGdl5TBIbiBI4SSPb2E5T56bBKJItfU9Ch66qjk/4b9/
tiS25JLO/ysdUdF0xM6EvVjeuCKy4PoeYqpa3T2YpOyMYjHo9Ohxw9Ikoe7x6GVD
EMbBKifZxc5JKwmgpCtPhT1y9jLa54KOx6sPn3hgmL8DkOPpozIXlO5iUV3eMsXE
JlamBQJfo58yREcyh+7mx7CM2P9O8SVSE90vssw1s/0vv9pgzLB0fkDU8S9Ukm4j
fKZ9HjhpGcTZoSyC+P4/OcM7woIf1d9tB0UV8h16NLoggnyF1qm6mpPml8iPdtlj
380ItMqZQIitrTtaiwh/Nhraf8jNUNREYunWrF8bN4GE8+0aptki15op
=LpNb
-----END PGP PUBLIC KEY BLOCK-----

The post Updated GPG key for signing Firefox and Thunderbird Releases appeared first on Mozilla Security Blog.

Firefox Tooling Announcements: Firefox Profiler Deployment (August 10, 2026)

canova — 2026-08-10T17:06:03+00:00

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

Highlights:

[fatadel] Improve discoverability of downloading a local profile (#6216)
[Nazım Can Altınova] Add the ability to apply source maps from the CLI (#6229)

Other Changes:

[fatadel] Create the Network track from the timeline-network schema display location (#6224)
[Markus Stange] Only call getRawFrameTableBuilderWithExistingContents once per symbolication batch. (#6233)
[Nazım Can Altınova] Handle the cli daemon startup failures more gracefully with better errors (#6241)
[Nazım Can Altınova] Handle Text and Log marker payloads with their marker schema (#6247)
[Nazım Can Altınova] Bump the Gecko profile version to make sure that the Text and Log marker changes are picked up in the frontends (#6252)
[fatadel] Deactivate a menu button as soon as its panel is dismissed (#6251)
[Nazım Can Altınova] Sync: l10n → main (August 10, 2026) (#6253)
[Nazım Can Altınova] Bump profiler-cli version to 0.8.0 (#6254)

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

de: Ger
de: Michael Köhler
el: George kitsoukakis
en-CA: chutten
en-CA: Saurabh
en-GB: Ian Neal
es-CL: ravmn
fy-NL, nl: Fjoerfoks
fr: Théo Chevalier
fy-NL: Fjoerfoks
ia: Melo46
it: Francesco Lodolo [:flod]
nl: Fjoerfoks
ru: michellemelsspam
ru: Valery Ledovskoy
tr: giray
tr: Selim Şumlu
zh-TW: Pin-guang Chen

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

1 post - 1 participant

Read full topic

Niko Matsakis: Cylic trait implementations: motivation

2026-08-10T13:35:40+00:00

Lately I’ve been thinking about cyclic trait implementations. This is a problem that I’ve been trying to understand for years and years and I finally feel like I’m geting somewhere. I’m going to try to write out a series of blog posts documenting those explorations and, hopefully, culminating in a design that could be RFC’d. In this first post, I want to talk about one of the interesting questions, what I am going to call “internal” vs “external” proofs. I know that this material can seem abstract, so I’m going to try and connect it to “real Rust” as much as possible! This particular blog post is an introduction, explaining the general problem and giving some motivation for why we care.

What are cyclic trait implementations?

Right now in Rust we require most traits to have non-cyclic, or inductive, implementations. To explain what I mean, let’s consider this trait:

trait Dump {
    fn dump(&self);
}

Now imagine that we have an impl of this for i32:

// Impl I
impl Dump for i32 {
    fn dump(&self) {
        println!("{self}");
    }
}

A simple impl for Rc<T> and `Option:

// Impl RC
impl<T> Dump for Rc<T>
where
    T: Dump,
{
    fn dump(&self) {
        T::dump(self)
    }
}

// Impl Opt
impl<T> Dump for Option<T>
where
    T: Dump,
{
    fn dump(&self) {
        if let Some(v) = self {
            T::dump(v)
        }
    }
}

and finally a recursive List type that has an impl as well:

struct List<T> {
    value: Rc<T>,
    next: Option<Rc<List<T>>>,
}

// Impl L
impl<T> Dump for List<T>
where
    T: Dump,
{
    fn dump(&self) {
        Dump::dump(&self.value);
       if let Some(n) = &self.next {
            Dump::dump(n);
        }
    }
}

If I try to show that List<i32>: Dump, I do that by

Applying “impl L” to show that List<i32>: Dump if i32: Dump
- Then applying “impl I” to show that i32: Dump

There’s no cycle here – that is, I didn’t have to use impl L to show that impl L is valid.

Cyclic logic sounds bad, but it can be exactly what you want

Now, when I said that “the impl L didn’t have to use the impl L to show that it is valid” that might not have sounded suspicious to you. In fact, it’s a pretty natural idea. After all, generally when you try to establish a logical argument, you aren’t allowed to use cyclic reasoning. That is, you can’t say: I know that Niko likes Rust because Niko likes Rust. So, in the same sense, it seems natural that I should not be able to say “I know that List<i32> implements Dump because List<i32> implements Dump”.

But actually, it would sometimes be really useful to say exactly that. One example is so-called “perfect derive”. In our Dump impl above, we had one where-clause, T: Dump. And if you were to create a custom derive for Dump and write #[derive(Dump)], the impl I showed is typically exactly what you would get. But it’s not necessarily what you want. Consider what you get with #[derive(Clone)]:

// Impl LC1
impl<T> Clone for List<T>
where
    T: Clone, // <-- generated but not really required!
{
    fn dump(&self) {
        List {
            value: Clone::clone(&self.value),
            next: Clone::clone(&self.next),
        }
    }
}

Here, the derive is going to create an impl that requires T: Clone. But if you look closely, you’ll see that all the fields only use Rc<T>, so in fact, we should be able to clone a List even without T: Clone! But how is the compiler to know this?

You might think that the compiler could do some super smarty-pants analysis on the fields to figure it out. And, in a way, it can: that is what cyclic trait solving is all about. The thing is, while the compiler can do that, the derive cannot – the derive doesn’t have access to the definitions of other types and so forth, and clearly we would need to know things about Option and Rc to figure out whether T: Clone is required here.

But what we could do is to generate a different impl. Instead of adding T: Clone for each type parameter, we could add a where-clause for each field type. This makes sense: after all, we are just going to be calling Clone on every field, so it’s quite logical to say that the impl is valid if every field is cloneable:

// Impl LC2
impl<T> Clone for List<T>
where
    Rc<T>: Clone,
    Option<Rc<List<T>>>: Clone,
{
    // .. as above ..
}

Under this formulation, we can see that all we have to be able to do is to clone an Rc<_> and clone an Option<Rc<_>>, neither of which require that T: Clone.

This idea is called perfect derive

We call this idea [perfect derive][] and it’s been a goal for a while. The thing is, cyclic reasoning is tricky to get right. The Clone example is actually an easy one: that one doesn’t really require cyclic reasoning:

To show that List<i32>: Clone we have to show that…
- Rc<i32>: Clone, which is easy because impl<T> Clone for Rc<T> doesn’t have any where-clauses¹
- Option<Rc<List<i32>>>: Clone uses the impl<T> Clone for Option<T> where T: Clone impl which requires…
  - Rc<List<i32>>: Clone, which is again easy

But it’s not so easy for `Dump`

But if we use that same “cyclic derive pattern” to generate our Dump impl, things don’t work out so well. Instead of just a T: Dump bound, our Dump impl now has two bounds:

// impl L1
impl<T> Dump for List<T>
where
    Rc<T>: Dump, // <-- Used to be `T: Dump`
    Option<Rc<List<T>>>, // <-- This one is new!
{
    fn dump(&self) {...}
}

Now imagine we try to show List<i32>: Dump. We begin by applying impl L1, which requires us to show that its where clauses hold:

To show List<i32>: Dump we use impl L1, which has two where-clauses:
- Rc<i32>: Dump, this one is easy because the Rc impl requires that i32: Dump which is true.
- But Option<Rc<List<i32>>>: Dump is tricky. The Option impl requires that…
  - We need to prove Rc<List<i32>>: Dump, and then the Rc impl requires that…
    - We need to prove List<i32>: Dump, but that is what we started with! That’s cyclic logic!

Ugh. Something’s tricky here!

We can’t just accept any old cycle because of supertraits

Now, maybe you think we can just accept any cycles. And for these examples, it would be fine: but it’s not correct if you consider supertraits. Consider this trait and impl pair:

trait Magic: Copy { }

// Impl M
impl<T> Magic for T
where
    T: Magic,
{}

If you are naive, this weird trait-impl pair can be used to prove that any type is Copy, regardless of whether it has a Copy impl. For example:

Say we want to prove that String: Copy. We observe that if a type implements Magic, it must implement Copy, so…
- We begin by proving String: Magic. We use the impl M, which requires
  - that we show String: Magic, which is a cycle, so we accept it.

Uh oh, now we did something wrong. We proved that String: Copy even though there is no Copy impl. Something is fishy.

Now clearly we can all see the problem here – the implementation of Magic didn’t really add any information. It was just a tautology, saying that T: Magic if T: Magic. It’s not wrong, but implementing Magic was supposed to tell us more than just the fact that there is an impl of Magic, it was supposed to tell us also that the supertrait Copy is implemented. And that’s not true here.

But if you think about it, it’s hard to decide why we should reject impl M but accept the impl L1 of Dump for List<T>. They both wind up with a cyclic proof. So what’s the difference? This is the question we’ll be exploring over the next few blog posts.

Soundness for traits

This gets at an interesting question: what does it mean for the trait system to be sound. This seems obvious but actually it was a question I found kind of non-obvious for a long time.

We’ve found two satisfactory answers to that question. One of them involves converting to dictionary-passing style. Nadri explained that in a blog post. I think that’s a great post to read. I’m going to give another definition here that doesn’t require converting to a dependently typed program²

My rough definition is this³: the trait system is sound if, whenever it accepts some program P, that program cannot have a function that believes some Trait holds for the T, but there is no impl of Trait that can be used. So in the case of Magic and Copy, it’s easy to write a program that shows simple cyclic trait solving is unsound:

trait Magic: Copy {}

impl<T: Magic> Magic for T {}

fn is_copy<T: Copy>() {
    // this function believes `T: Copy`
}

fn main() {
    // this can be called because we believe that
    // * `String: Magic` because
    //     * `String: Magic`, and we accept cycles.
    // And then `String: Magic` implies `String: Copy`.
    is_copy::<String>();
}

By my definition, any sound type/trait system must reject this program because, if it were to execute, then execution would reach is_copy::<String> and yet there is no Copy impl that is judged to ber applicable to String. Uh oh!

Coming next

As I promised, this post was mostly focused on “setting the scene”. My goal was to explain what the problem is that we are trying to solve – permitting “good cyclic impls” but forbidding bad ones. I didn’t spend a lot of time on the bad ones, but it turns out that there’s a wide variety of unsound things one can do, some of which the compiler currently gets wrong, others of which it would only get wrong if we started permitting cycles.

My motivation for getting into this work is a bit complicated. I want perfect derive. But it’s also a loose end in our trait semantics that I really want to see nailed down before we move onto other tasks. Having auto traits (e.g., Send) work differently from other traits is clearly a “smell”, and without a strong understanding of the logical underpinnings of our trait system it’s easy to get things wrong when we build extensions.

In the next few posts I’ll go a bit deeper into the exploration I and others have been doing. I’ll talk about some of the “false starts” we took along the way and why they don’t work, and then about some of the solutions that are under consideration. Working through this stuff has really helped me to broaden my understanding of various areas of logic. By the time we’re done, we’ll cover⁴ coinduction and productivity, modal logic and the later modality, and we’ll see how our techniques might even help us with resolving specialization⁵.

I cited it earlier, but if you want to read other tasks on the same subject, I definitely recommend Nadri’s post on dictionary-passing style.

Apart from the default Sized bound, I’m ignoring that here ↩︎
I have found that both the dictionary-passing interpretation and the logic approach I’m using are valuable. In the end, they’re more or less equivalent, which I guess shouldn’t be surprising if you’ve heard of the Curry Howard Correspondence, but I’ll talk about that later perhaps. ↩︎
I would like to, but haven’t, define a simplified version of Rust that includes trait solving and simple type checkoing and show that it cannot “go wrong”. ↩︎
In a shallow way, I’m no expert! ↩︎
Plot twist, bet you didn’t see that coming! I sure didn’t. ↩︎

Ludovic Hirlimann: 20+ years of running "alpha quality" browser as my main web browser

Ludovic Hirlimann — 2026-08-10T11:48:41+00:00

I have been accessing, using the internet since probably around 1991, using my dad's academic account and then schools and then home. I've used the internet before the web existed, sending emails, downloading freeware and sharewares from "huge" ftp repository. Sharing ftp site, using Usenet to find more and share more. This was a time you had to buy Ethernet NuBus card and install both Ethernet drivers and TCP/IP ones.

Then one day something called NCSA Mosaic came into the picture - this changed the way I consumed 'the network'. After a while some friends showed me Netscape, and mosaic faded away. I've used Netscape on Mac, Windows 3.11, NT, on workstations running Unix (hello Dec Alpha).

At the time my gig was either running OS/2, and Linux Slackware on my Pentium machine. I then got into the Beos world, and that was one OS that Netscape didn't ship binaries for. Microsoft had started pushing Internet explorer (IE). I was starting to work and *had* to use Windows. I came up with the idea of using Mozilla at work in order to find bugs that would later be fixed when I'd use it home on my favorite OS.

So I started using Mozilla builds for windows, and then following planet and mozilla.org to be aware of the process. I would now and then file bugzilla issues, often to discover they've been filled already :-) I clearly remember the day tabs were introduced. I walked around the room I was working in showing the great new feature to my colleagues that were using Mozilla. There were no formal releases, at the time CI-CD didn't exist completely yet, so you could keep the same version for a day or for a week depending on how broken the tree was

Then I continued using builds until updates became available, and I choose to use the nightly channel. At that time my motivation had changed, I had moved from dead BeOS to NeXTStep+1 aka Mac OS X. There was no way for me to help My then browser of choice Camino at work. Mac OS X was way less popular in the tech industry that it is now.

The web landscape was dominated by IE , the mac version was unfortunately different meaning that using it made a bunch of websites unusable.

When Firefox got out, Camino started dying and I switched boats.

I then got employed by Mozillamessaging and used both Thunderbird and Firefox nightlies. I was the QA lead and there were no way I could test all the software and hardware combination used by our users. So crowd testing was very valuable to me. At this point I had stopped reporting issues and the only thing I was reporting were crashes.

Since 2010 a bunch of Chrome related browsers have started taking the web over, a bit like in 2006 when Microsoft was running the show, instead now google is. I currently run 2 versions of Firefox, nightly for personal stuff and release for work related ones. I occasionally have to fire a chrome related browser because testing with Ff from the vendors is not being done (I'm looking at DocuSign and FoundryVtt ).

So running nightly software has not been a burden at all, because there are a few crashes here and there, but I always submit, so the stability team at Mozilla can investigate. The idea is that if it crashes on me, it won't crash on my Dad's computer because he runs releases. Once or twice in the course of those 20 years did I have to either reinstall or create a new profile. That's how stable nightly has been for me.

I'm annoyed at some of the decision Mozilla makes, but again they are the most independent browser maker out there with a big enough team to deal with the development surface of a browser. Hence, for some forseable future I'll be running nightlies in hopes of keeping the web open. I'm lurking at Servo and following it's development, reporting issues there because I see it has an alternative to Firefox, but it's far from being ready yet.

I'd encourage some of my readers to try/use Nightly. If you choose to do so, send in crash reports and enable telemetry.

Planet Mozilla

Firefox Tooling Announcements: Happy BMO Push Day! (20260916.1)

Firefox Tooling Announcements: MozPhab 2.19.1 Released

The Mozilla Blog: Mozilla and Mistral: Partnering to expand AI competition and preserve user choice

Choice and competition are worth protecting

Selecting Mistral, and expanding to France

A different kind of AI competition

Jonathan Almeida: Checkout a Github pull request from one-off contributions

Comments

The Servo Blog: Your Donations at Work: One Year of Sponsored Servo Development

Firefox Nightly: The Need for Speed Controls – These Weeks in Firefox: Issue 208

Highlights

Friends of the Firefox team

Volunteers that fixed more than one bug

New contributors (🌟 = first patch)

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

WebExtensions Framework

DevTools

WebDriver

New Tab Page

Picture-in-Picture

Search and Urlbar

Mozilla Data YouTube Channel: Data Club: Jan-Erik Rediger - Little Bobby Tables - from metrics.yaml to data-filled columns

Mozilla Data YouTube Channel: Last Lecture: Writing the Data Docs

Mozilla Data YouTube Channel: Data Club Talk: Jan-Erik Rediger - The Glean UniFFI migration and how no one noticed

Mozilla Data YouTube Channel: Monitoring Sensitive Data: How do we monitor data we don't store?

Jonathan Almeida: Perf wins from relocating MOZ_OBJDIR have a dev experience cost

About:Community: Game on: Play, share, and help shape Mozilla

Mozilla Data YouTube Channel: Glean Dictionary Looker Demo

Mozilla Data YouTube Channel: Responsible Data Collection is Good, Actually (Ubisoft Data Summit 2021)

Mozilla Data YouTube Channel: Mozillians sharing the 2021 SciPy Conference experience

Mozilla Data YouTube Channel: Data Club Lightning Talk: Jan-Erik Rediger - Your personal Glean data pipeline

Firefox Tooling Announcements: Happy BMO Push Day! (20260908.1)

Mozilla Data YouTube Channel: GLAM Datasets

Firefox Tooling Announcements: MozPhab 2.19.0 Released

Thunderbird Blog: Desktop Settings: Removing technical jargon

Step 1: Research & prioritization

Step 2: Inventory audit

Step 3: Content redesign

This Week In Rust: This Week in Rust 668

Firefox Nightly: Motion, Colour, Captions, Kit – These Weeks in Firefox: Issue 207

Highlights

Friends of the Firefox team

Volunteers that fixed more than one bug

New contributors (🌟 = first patch)

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

WebExtensions Framework

WebExtension APIs

DevTools

WebDriver

Fluent

Lint, Docs and Workflow

New Tab Page

Performance Tools (aka Firefox Profiler)

Search and Urlbar

The Rust Programming Language Blog: Rust debugging survey 2026 results

Who Uses Debuggers?

How Are Debuggers Used?

Challenges

Debugger Visualizers

Closing Remarks

Firefox Tooling Announcements: Firefox DevTools MCP 0.10.2 released

Firefox Tooling Announcements: PerfCompare just deployed (Sept 3, 2026)

Bug 2059826 - Simplified View: Create checkbox selection for advanced columns and display how to read the results #1069

Mozilla Performance Blog: Introducing PerfCompare’s Simple View

An approachable default for beginners and occasional users

What’s next

Share your feedback

Firefox Tooling Announcements: Firefox Profiler Deployment (September 3, 2026)

The Rust Programming Language Blog: Announcing Rust 1.98.1

What's in 1.98.1

Contributors to 1.98.1

Thunderbird Blog: Thunderbird Desktop New Protocol Support: Microsoft Graph API

IMAP and EWS and Graph, Oh My!

Microsoft Graph Account Set Up

What is currently supported?