Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
The Rust Programming Language Blog
With Rust 1.100.0, the following changes to 32-bit Windows targets will happen:
i686-pc-windows-msvc Tier 1 with host tools target will be demoted to Tier 1 without host tools.i686-pc-windows-gnu Tier 2 with host tools target will be demoted to Tier 2 without host tools.Builds of the standard library will continue to be distributed, but host tools such as the compiler will be no longer available. i686-pc-windows-msvc as a Tier 1 target still undergoes CI testing.
To build 32-bit Windows binaries, cross-compiling from a still-supported host toolchain (such as a 64-bit Windows ones) will be required from now on.
Desktop and Server 32-bit only x86 CPUs are no longer sold for over 15 years, and general 32-bit Windows support has ended in October 2025. This means that the development platforms these targets are meant for hardly exist these days, and even if they do exist they typically aren't capable enough for development.
Even on the modern x86_64 hardware, building i686 Windows toolchains has proven to be problematic. We have encountered compiler binaries crashing when built with the i686 MSVC target, and the GNU C++ toolchain failing with OOMs during LLVM build.
Considering all these things, cross-compiling these targets from a better supported one is what we have found to be the best solution forward. As part of that, we stopped producing host tools for these targets. For the time being, the prebuilt standard library is still available, and in case of i686-pc-windows-msvc still tested on CI.
After Rust 1.100, it will no longer be possible to install toolchains on 32-bit Windows hosts. We recommend cross-compiling from a still-supported host (such as a 64-bit Windows toolchain) instead. Other 32-bit platforms are not impacted by this change.
For more details about these demotions, see RFC 3999 for i686-pc-windows-msvc demotion, and MCP 1020 for i686-pc-windows-gnu demotion.
Mozilla Data YouTube Channel
Thunderbird Blog
The team has been working hard behind the scenes laying a strong foundation for the Thunderbird iOS app. Rather than leveraging existing code, we are building natively from scratch. This fresh start allows us to take everything we’ve learned from Thunderbird Desktop and Android to ensure a fast, reliable, and modern experience on your iPhone right from the start.
Our ultimate goal is seamless cross-device experience. Whether you’re sitting at your desktop computer, checking messages on the go, your workflow should feel effortless and unified.
Right now, we are focused heavily on getting the core foundations right. We are excited about the momentum because having clean architecture today means we can layer on exciting new features much faster in the future.
Below we’ve captured some of our work in progress. Nothing is final, but we wanted to share what we are cooking up so far. If you have feedback, keep reading on. At the bottom of the post we have a link to a user research study where we want to hear from you and what you want to see from Thunderbird for iOS.
We know people are really busy, often doing more than one thing at a time. We’re making login fast, secure, and fully automatic, so whether you’re signing in with a single click or setting up multiple accounts, you can get to your inbox quickly.
An email app is only as good as its connection. Behind the scenes, we’re building a background sync that maintains a steady connection with your provider that keeps your inbox up to date while respecting your battery life.
Your daily email routine should feel effortless. We’re polishing the essentials: a clutter-free, easy-to-read inbox layout paired with a clean, modern editor that lets you format messages smoothly without getting in your way.
Thunderbird has always belonged to its community. We’re structuring the app with clean code and an experimental feature flag system so it’s easy for community developers to contribute. This means power users will be able to test out new experimental features early, and external contributors can easily help us extend what the app can do.
When can you try it?
Our goal is to have a first version ready for community testing in the next few months.
Building with our community, not just for people, is core to what we are trying to do. To help us decide what to build next after our first release, we’d love your input. If you had to pick the top three things that matter most to your daily email routine, what would they be?
A note to the community
Lastly, we know how long many of you have been asking for and waiting for Thunderbird on iOS. Whether you’ve dropped a comment on our forums, tagged us on social media, or simply kept an eye on our progress, thank you for your patience!
Bringing Thunderbird to iPhone and iPad isn’t just about building an app; it’s about doing it right so it serves you reliably for years to come. Today, we want to pop open the hood, share where we are, and work with everyone to design the best possible experience.
The post Thunderbird for iOS: A First Look at the Native iPhone Email App in Development appeared first on The Thunderbird Blog.
Mozilla Data YouTube Channel
The Mozilla Blog
Following the rollout of Firefox’s Shake to Summarize feature to Android devices this May, we wanted to take a closer look at the modeling work behind the feature. In a previous blog post, we discussed our model selection process. Now that Shake to Summarize has been available on both iOS and Android for a few months, we wanted to take it a step further and outline our approach to prompt development.
This is the story of a Shake to Summarize use case that required a little extra prompt tuning: online recipes.
The first step in developing a useful prompt is clearly describing what you want the LLM to do. LLMs thrive on specificity, so the more sharply you can define your task, the better your results are likely to be.
This is especially important when using smaller LLMs (like we are here), since these little models are not as good at reading between the lines and intuiting unstated intentions as their more powerful cousins are.
For this application, we were looking to create summaries. On the face of it, this seems pretty straightforward. However, as we iterated on prompts, we quickly discovered that what constitutes a “good” summary depends largely on what one is summarizing.
For example, a useful summary of a novel should provide us with a quick overview of the plot without getting into too many specific details; we wouldn’t expect the summary to contain anything from the text verbatim.
In contrast, a summary of a recipe website should include the recipe essentially as written. If the recipe says “cook lovingly” we might be OK with shortening it to “cook,” but if it calls for 4 cups of vegetable broth, a Tbsp of oregano and a tsp of thyme, we want these details relayed to us exactly. Merely stating, “this recipe calls for some broth and some spices” would not be adequate.
From here, it became clear that we wanted not just one “summarize” instruction, but a whole set of instructions — one for each category of webpage that we wished to summarize. We worked with the product team to compile a list of article types that we were targeting for this feature. For each article type, we then gave a brief description of what a good summary would look like:
Recipe – Ingredients as written, along with the key steps, time required, and any tips given by the author or commenters
News – Only the important details: what happened, when, and what would be the likely consequences to the reader
How-to – Start with the required materials, skills, tools, etc., along with the main steps and any specific warnings called out by the author
Review – Highlight the bottom line rating. If it is a product review, include the pros and cons, the price, and who the target audience is.
Research – Key finding and level of confidence the researchers have in their results as well as the projected real-world impact.
Opinion – The main argument, along with any key evidence cited in support
We then wrapped this list in some general instructions to ground the model in the task and came up with our initial prompt (formatted for readability) [source]:
You are a Content Summarizer. You create mobile-optimized summaries by first understanding what users actually need from each type of content.
Process:
Step 1: Identify and Adapt.
Step 2: Based on content type, prioritize:
Recipe – Servings, Total time, Ingredients list, Key steps, Tips.
News – What happened, when, where.
How-to – Total time, Materials, Key steps, Warnings.
Review – Bottom line rating, price.
Opinion – Main arguments, Key evidence.
Personal Blog – Author, main points.
Fiction – Author, summary of plot.
All other content types – Provide a brief summary of no more than 6 sentences.
Step 3: Format for mobile using concise language and paragraphs with 3 sentences maximum.
Bold critical details (numbers, warnings, key terms).
We Foxfooded the above prompt and found that it mostly worked pretty well. The summaries the model produced were concise, accurate, and informative.
The only exception was recipes.
We found that, when the prompt above was used for recipes, the model tended to summarize too much — often leaving out key ingredients, or in some cases, leaving out the recipe entirely.
For example, when asked to summarize a lentil soup recipe the model returned:
The webpage provides a detailed recipe for a vegan lentil soup, which the author claims is the best they’ve ever made. The soup is made with pantry staples like lentils, diced tomatoes, vegetable broth, and spices (cumin, curry powder, thyme), along with fresh vegetables (onion, carrots, garlic) and greens (kale or collard greens). A key step is blending a portion of the soup to create a creamy texture without dairy.
The summary is accurate, so far as it goes, but it isn’t exactly useful. If our goal is to have the summary be a quick way to access the recipe itself, without having to read through the narrative preamble, this wouldn’t cut it.
To address this problem, we needed to be more explicit with the instructions we gave the model when summarizing recipes: we needed to tell it which information we were interested in and which it could safely discard.
Although we could have added this extra guidance directly to the prompt above, doing so risked causing the model to over-index on the recipe formatting and ignore the other article types. Instead, we developed a separate prompt which contained only the recipe instructions and directed recipe summarization requests to use it, rather than the general one [source].
To perform this routing, we used the structured data embedded in each webpage. While this categorization could have been handled by another model pass, metadata from the webpage itself allowed us to quickly and deterministically identify the page categories without additional inference overhead. To capture cases where this data is either missing or inaccurate, we also maintain some lightweight recipe guidance in the general prompt.
After this change, the summary returned by the model for the above recipe became much more usable (shortened for brevity):
Servings: 6
Total Time: 50 minutes
Prep Time: 10 minutes
Cook Time: 40 minutes
Ingredients
Instructions
Tips
Nutrition
With this change in place, we ran a quick test over a curated set of recipe sites and found that the new system was more than twice as likely to return a complete and accurate summary than our previous one. Success!
The system was now working as expected: summaries were useful and recipes were complete.
From this experience we learned that the model produced the best results when it was told explicitly what we wanted it to do. When the instructions were vague or left too much up to the model, performance suffered.
To this end, we found that framing this problem as a routing problem — where the specific kinds of articles are routed to specific prompts — worked well. Since the task of summarization is not monolithic, our summarization pipeline should not be either.
Even though our current approach has only a single category-specific prompt, we hypothesize that the system would see further gains by using dedicated prompts for other page types as well.
More broadly, this experience reinforced an important lesson for us: improving AI systems is not solely about building larger or more capable models. Some of the biggest gains come from reducing ambiguity, narrowing the task, and designing systems that help the model succeed. Within the right harness, smaller, open source models can deliver great value.
While building more capable models continues to advance the field, our experience shows that thoughtful system design and solid engineering still matter.
The post Under the Hood: Prompt tuning Shake to Summarize for recipes appeared first on The Mozilla Blog.
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
The Rust Programming Language Blog
The Rust team is happy to announce a new version of Rust, 1.99.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.99.0 with:
$ rustup update stableIf 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.99.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!
Rust 1.99.0 stabilizes defining C-ABI variadic functions with "C" and
"C-unwind" ABIs. Variadic functions defined this way use a variable argument
list (...) and accept an arbitrary number of arguments. Rust could already
call externally-defined variadic functions (e.g., libc::printf). With Rust
1.99, these functions can now be written in Rust itself:
/// SAFETY: must be called with (at least) 2 i32 arguments.
unsafe extern "C" fn sum(mut args: ...) -> i32 {
// SAFETY: guaranteed by the caller.
let a = unsafe { args.next_arg::<i32>() };
let b = unsafe { args.next_arg::<i32>() };
a + b
}
fn foo() -> i32 {
unsafe { sum(0i32, 2i32) }
}The type of ... is VaList,
which is ABI-compatible with the C va_list type across targets. What types can be read from a VaList is guarded by the
VaArgSafe trait.
For more details on c-variadic functions, see the Reference. This release also stabilizes support for defining naked variadic functions with non-"C" ABIs, which must be written via inline assembly.
This release settles the safety requirements for retrieving the size and
alignment on raw pointers to both Sized (trivially safe, already possible on
stable) and non-Sized types.
This is done by stabilizing three functions:
Box::leakWhile there are no changes to the language semantics in Rust 1.99, we have
updated the documentation on Box::leak to recommend against patterns that
later deallocate that memory. This was done because such code was found to have
problematic interactions with current and future potential compiler optimizations,
and is especially problematic with the upcoming stabilization of custom allocators.
Instead, Box::into_non_null or Box::into_raw should be preferred.
This guidance also applies to other leak functions in the standard library.
IntoIterator for Box<[T; N]>IntoIterator for &Box<[T; N]>IntoIterator for &mut Box<[T; N]>VecDeque::retain_backcore::ffi::VaListBox::into_non_nullBox::from_non_nullVec::into_partsVec::from_partscore::mem::size_of_val_rawcore::mem::align_of_val_rawcore::alloc::Layout::for_value_rawString::from_utf8_lossy_ownedstring::FromUtf8Error::into_utf8_lossyFusedIterator for StepBy<I>std::fs::set_timesstd::fs::set_times_nofollowCheck out everything that changed in Rust, Cargo, and Clippy.
Many people came together to create Rust 1.99.0. We couldn't have done it without all of you. Thanks!
About:Community
Hi Mozillian,
In this edition, we’re exploring the new Firefox design, Mozilla’s recent partnership with Mistral to expand choice in AI-powered browsing, and several ways to get involved with MozFest. You can join a livestream about the value of bringing open-source communities together in person, volunteer at MozFest in Barcelona, or take part in the latest privacy discussion from the Firefox community on Reddit.
Read on for the latest updates and opportunities to participate!
More modern. More flexible. Still Firefox.
Firefox 157 introduces a new Firefox design with updated colors, icons and themes that make the browser feel more modern while preserving the familiar Firefox experience. The release also brings back Compact Mode and adds easier theme selection, new wallpapers and more ways to customize the New Tab page. Underneath the new look, Firefox remains independent and open source, with built-in privacy protections and controls that let you decide how your browser works, including how AI features appear.
Mozilla and Mistral partner to expand AI choice
Mozilla and Mistral have announced a partnership aimed at increasing competition and preserving user choice in AI-powered browsing. As part of the collaboration, the open-source Mistral Small 4 model is coming to Firefox Smart Window Beta as a new option for users in the US and Canada. Smart Window Beta is also expanding to France with official French-language support, with additional European markets planned. Users can continue choosing from multiple AI models, reinforcing Firefox’s commitment to avoiding lock-in and keeping the web open to different technologies and providers.
Does open source need IRL? The case for MozFest
Is showing up in person important for open source? Join the Owners Not Renters livestream on Tuesday, September 29, to hear the story behind MozFest and explore why gathering in person still matters for open-source communities ahead of MozFest, taking place October 28–30 in Barcelona. Kali Villarosa (MoFo), Seher Shafiq (MoFo) and Brian Behlendorf (co-founded Apache) will join host Marcus Rein for an open conversation, followed by a live Q&A. Bring your questions and your hot takes!
MozFest call for Volunteers
From 28–30 October 2026, the Mozilla Foundation will host the Mozilla Festival in Barcelona, bringing together people from diverse fields to explore how we can work collectively to “re-wild” the web. To help bring the Festival to life, we’re building a team of volunteers. By joining, you’ll help deliver a major event in support of Mozilla’s mission while also having opportunities to participate in sessions throughout the three-day Festival.
From the Reddit Community
Privacy conversations are going mainstream, and Firefox has been at this for 20+ years. In light of a recent video making the rounds about the importance of privacy, the Firefox Team shared a rundown of built-in privacy features (ad blocking, tracking protection, encrypted sync, a free VPN, and more). Jump in at r/firefox and share your own privacy tips and configs!
P.S.
Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.
This Week In Rust
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.
This week's crate is ying-profiler, a native Rust sampling memory profiler.
Thanks to Evan Chan for the self-suggestion!
Please submit your suggestions and votes for next week!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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.
mw argumentsmw --help outputScoreBounds::dimension_scores docs still list estimated key counts as unboundedfinished event under-counts rows when a row cap stops the incremental engineIf 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!
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!
546 pull requests were merged in the last week
crate_hash from metadata encoding instead of HIR (implements #94878)k#)Div and Mul for Complex<{float}>AllocatorNonZero conversions'static) lifetimes in thread_local!PartialEq<VecDeque<U>> for Vec<T>, &[T], &mut [T], [T; N], &[T; N] and &mut [T; N]Box::takeResult::into_{ok,err}funnel_shifts (including const)mem::conjure_zstvec_try_removefrom_str_radixbuiltin-deps: add builtin dependencies manifest syntaxconfig: add build.profile, install.profilemetadata: mirror package features in features_v2builtin-deps: fix builtin dependencies manifest validationdiag: Don't report unused normal deps when static libs are skippedpackage: preserve feature metadata in normalized manifestsdoc(hidden) with --generate-link-to-definition#[rustc_allow_incoherent_impl] is involvedwhile_let_loop: detect the pattern when the loop has a labeltry_from_instead_of_from_str lintBox::leak in nonnull_unchecked_on_box_ptrcollapsible_match consuming/mutation checkingmatch_str_case matching str inside or patternstype_match relevance for type-aliasenumenumThis week was fairly positive. We had no pure regressions, and most of the results came from a few architectural improvements with mixed or mostly positive impact. Some improvements also come from addressing previously triaged regression caused by missing no_alias annotation for references in closures.
The biggest improvement this week is in rustdoc, from tackling quadratic behaviour when generating sidebar links. This was reported by a user, but the effect didn't show up in our benchmarks, so we added a special stress test for it.
Triage done by @panstromek. Revision range: 3670d253..c1070d69
Summary:
| (instructions:u) | mean | range | count |
|---|---|---|---|
| Regressions ❌ (primary) |
0.6% | [0.2%, 0.8%] | 8 |
| Regressions ❌ (secondary) |
1.4% | [0.1%, 5.8%] | 30 |
| Improvements ✅ (primary) |
-0.6% | [-1.7%, -0.2%] | 192 |
| Improvements ✅ (secondary) |
-1.5% | [-82.5%, -0.1%] | 101 |
| All ❌✅ (primary) | -0.6% | [-1.7%, 0.8%] | 200 |
0 Regressions, 2 Improvements, 6 Mixed; 3 of them in rollups 26 artifact comparisons made in total
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
ptr::try_cast_alignedrustc_allowed_through_unstable_modules itemsVisibleForLeakCheck in RegionOutlives fast pathdebug_closure_helpers#[panic_handler] on unsafe fn.optimize attribute#[inline(always)] + #[target_feature(enable = "....")] #2CStr::display(use<…>)+)No Items entered Final Comment Period this week for 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.
Rusty Events between 2026-09-30 - 2026-10-28 🦀
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.
Please see the latest Who's Hiring thread on r/rust
The community is obnoxiously helpful. I asked a simple question on the Rust community Discord server. What is the best way to read a file in Rust? I expected a straightforward response. Instead, I got back a 2,000-word essay on the inner workings of IO, buffering, error handling, and ownership, plus links to four different blog posts and three different approaches depending on file size, and a working code example.
...
The Rust community has weaponized education against me. I'm now a better engineer than I was yesterday against my will.
Thanks to MusicalNinjaDad 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
Mozilla Addons Blog
On September 29, Firefox 157 shipped Nova, the biggest refresh of the Firefox interface since Proton back in 2021. The browser frame is cleaner, the sidebar plays a bigger role, and vertical tabs are a first-class layout. Your theme continues to load, and most color and image properties work as they did before.
What does change is where those colors and images display, how some of them look next to each other, and a handful of properties that no longer have a visible effect. Most themes will look fine. Some, especially themes built around a background image, look different enough that you will want to take a look.
This post walks through what changed compared with the Proton interface, what to check in your theme, and what is still being worked on. If you only have five minutes, jump to the checklist.
The toolbar and sidebar now sit flush with the window edges, with no gaps between them.
For your theme, this means your frame color and background image have less empty space around them, and the edges where the toolbar, sidebar, and page meet are more visible.
| Area | Proton | Nova (Firefox 157) |
|---|---|---|
| Toolbar and sidebar | Flush with the window, no gaps or floating borders | Same as before |
| Horizontal tabs | Theme background applied to the tab strip | Same as before |
| Vertical tabs | Tab bar color on the tab strip | Tab bar color also shows on the toolbar |
| Sidebar | Separate panel | Shares the theme background with the toolbar area |
Accent color. The default Firefox theme uses Nova’s purple accent. Every other theme, including yours, uses the operating system’s accent color for buttons and other accented controls. Themes cannot set the accent color through the manifest, and is why your theme cannot show the purple you see in the default theme.
Focus and link colors. Firefox still applies its own blue and cyan to focus rings and some links when a theme other than the default is active.
The selected tab. Proton always drew a shadow under the selected tab, which helped it stand out even when a theme did not style it. Nova removes that shadow. If your theme relies on it, the selected tab can blend into the tab strip. Set the selected tab colors, with tab_selected and tab_line, so the selected tab stands out.
Button hover colors. Your button_background_hover and button_background_active colors also apply to buttons on the tab strip, and for buttons that sit on your frame background with vertical tabs. A solid color picked to match the toolbar can almost disappear there. Semi-transparent colors, for example rgba(0, 0, 0, 0.15) for hover and rgba(0, 0, 0, 0.3) for pressed, work on both backgrounds.
sidebar and sidebar_text for sidebar panels. If you leave them out, Firefox picks colors for you, relevant to your theme’s color.sidebar_border is now a separator. The sidebar splitter is gone; the property now colors the line between the sidebar and the page.Some theme properties behave differently in Nova. Your theme still loads if it uses them; they just have no visible effect, or style something different.
| Property | In Nova |
|---|---|
ntp_text |
No longer styles the new tab page search box |
popup_text |
No longer styles the address bar dropdown; other popups still use it |
sidebar_highlight |
No visible effect; the default highlight color is used |
sidebar_highlight_text |
No visible effect |
toolbar_bottom_separator |
Acts as a separator next to or below the toolbar and around the page |
The theme manifest reference on MDN is being updated with these changes.
Themes using images are where you are most likely to see a difference. Your image can now show behind the sidebar and vertical tabs, and an image designed for a wide, short toolbar rarely looks good stretched or tiled down a vertical panel. In our testing of popular themes, the image themes that look off in the sidebar mostly did before Nova too. We did test a number of themes but we invite you to do your own testing. Nova makes the sidebar more visible, so the issues are easier to notice.
You can now choose where your images go with the backgrounds_area property, available from Firefox 156:
additional_backgrounds_alignment. If any image is aligned to the vertical center or bottom, images stay in the top toolbars; otherwise they cover the whole window.If your image was made for the toolbar only, “top_toolbars” with a frame color that suits the image is usually the quickest fix.
Also set a toolbar color, even a semi-transparent one. Without it, notification bars that appear above the page sit directly on your image and can be hard to read.
Nova’s color themes use gradients, and you can too. The Nova theme manifests are the best working example; look at how they set colors for each surface, including the sidebar. backgrounds_area applies to gradients the same way it applies to images. Older versions of Firefox ignore color properties they don’t recognize, so your theme still loads there; if you use a feature older versions reject, set strict_min_version in your manifest.
Install your theme in Firefox 157 and look at it in each of these states:
Then, if something looks off:
tab_selected and tab_line so the selected tab stands out without Firefox’s old shadow.sidebar and sidebar_text to colors that match your theme.button_background_hover and button_background_active colors.backgrounds_area and set a toolbar color.Nova will evolve after launch. Firefox 158 ships on October 13 with the expand-on-hover sidebar fix. We are also working on these, with no release date yet:
popup_icons color for icons in menus and panels, separate from toolbar icons.We will post again when these land.
Some of your users may miss Proton. From September 29, Mozilla is featuring a Firefox Proton theme in the Add-ons Manager for anyone who wants the previous look. It is a normal theme, so users can switch between it and yours at any time.
Resources
backgrounds_area.We want your theme to look its best in Nova. If something looks wrong and the checklist does not fix it, tell us on Discourse and include a link to your theme and a screenshot. Those reports help us find the cases that need a Firefox fix rather than a theme change.
Thank you for making Firefox look like you and like your users.
The post Nova is here: what changes for your Firefox theme appeared first on Mozilla Add-ons Community Blog.
The Mozilla Blog
What comes to mind when you think of Firefox? Is it our best-in-class privacy features and ad blocking capabilities? Our partnerships with Wrexham, NVIDIA or Mistral? Or maybe our adorable mascot Kit?
If you’ve been following Firefox this year, you’ve seen us add new ways to get things done while giving you more choice over how you browse. That includes browsing two pages side by side, adding an extra layer of privacy with built-in VPN, blocking trackers for smoother scrolling and faster load times, and deciding how AI shows up in Firefox.
For the past few months, many of you have also been trying out our new Firefox design in Nightly and sharing your thoughts with us as we continued to refine the experience.
Today, we’re rolling out that design with FX 157 to everyone using Firefox across desktop and mobile devices. Firefox has done a lot of growing over the last year; now it looks the part.
When we first shared our plans to design Firefox for the future, we said we wanted Firefox to feel “current, but not generic. Warm, but still precise.”
That design ethos now carries across all of Firefox. We’ve refreshed the colors, icons and themes throughout the browser, from the tabs and toolbars you use every day to your New Tab page, Private Browsing experience and more, with no cost to your browser performance.
This shared design language across desktop and mobile gives Firefox a consistent foundation for new features and experiences, while keeping the personality that makes Firefox unique.
We’ve added more choices for how Firefox looks and works, including the return of a feature many of you asked for:
Compact Mode is back. As people started trying the new design, we heard from many of you who wanted to fit more into your browser window. Compact Mode reduces the size of your tabs and toolbar to give more of your screen to the web, with an auto-compact option for smaller screens.
Find your look. A new theme picker makes it easier to explore different looks for Firefox, with new themes and wallpapers to choose from.
Set up New Tab your way. Choose what you want to see on your homepage. Now, you have a dedicated space to pin and organize shortcuts so sites you use all the time stay put.
Themes and wallpapers may change over time, but the things that made people choose Firefox in the first place are still the same. We’re still independent and open source, with privacy protections built into the browser and controls that put you in charge of how Firefox works for you.
This carries through everything we build, from the height of your toolbars and what belongs on your New Tab page to which AI features show up in your browser, which model you choose and what context you want it to have.
Today’s Firefox is a renewal, grounded in the same principles that have shaped it from the beginning, with a new design built to carry Firefox forward.
For those who have come with us on this journey, thank you for helping us shape the future of Firefox.
If you’ve been away on hiatus, welcome back. Try the latest Firefox and let us know what you think.
The post More modern. More flexible. Still Firefox. appeared first on The Mozilla Blog.
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Firefox Nightly
browser.newtabpage.activity-stream.newtabWallpapers.customWallpaper.library.enabled to true, starting in Firefox 157.
Script to find new contributors from bug list
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.21.0:
moz-phab submit could load reviewers and review groups in parallel with revisions and diffsmoz-phab submit should display the revisionDiscuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
Mozilla Data YouTube Channel
The Mozilla Blog
We spend a lot of time browsing online. Whether you are researching for work, planning a trip, paying your bills, or scrolling through social media, your browser is there for it all.
While all these tasks are very different in nature, a lot of people still tend to stick to the same window type for all their use cases. But what if there was a different way to browse?
You may have noticed Firefox now has three window options for desktop. On top of the Classic and Private windows you’ve known for years, a third choice has been rolling out in beta: Smart Window. This optional AI-powered browsing experience is built to move your work forward and help finish what you started online.
Following the recent addition of several new Smart Window capabilities, we thought now would be the perfect time for a breakdown of what each of our three window options actually does, and when to use them.
Classic Window is still the most customizable option of the three. While Private and Smart windows share many of the same features and capabilities as Classic, a Classic Window offers the widest range of Firefox’s standard personalization options. It gives you the broadest canvas for tailoring Firefox to the way you browse.
What makes it Classic:
When to use it:
Classic is your home base. It’s the best place to start customizing around your browsing needs, whether that means an extension setup specifically tailored to your workflow, a special theme that matches your style, or just the familiar Firefox experience you created over years of tweaking to your personal taste. While many customizations are also available on Private and Smart window, Classic offers the most extensive line-up of optional browser features, extensions, and aesthetics to personalize your setup.
Classic is the right move for general browsing like scrolling through social media, conducting a quick Google search, or reading online articles. It’s also the best place to start if you are looking to build your browser around you.
Private Window stays true to its name and number one priority: it’s designed to limit the information associated with your browser session. When a Private Window is closed, Firefox doesn’t retain session information, such as what you searched for, the sites you visited, or the cookies they set.
What makes it Private:
When to use it:
A Private Window is recommended when you don’t want activity from a browsing session sitting in your history, such as shopping for a gift. It’s also helpful when browsing on a shared device, ensuring your history, logins, and cookies will not be saved for the next person.
You may not need a Private Window every time you open your browser, but it’s always there for you when you do.
Smart Windowis Firefox’s newest window type, currently rolling out in Beta to users in the U.S., Canada, and France. Think of it as a Classic Firefox window with a built-in AI assistant layered on top – one that you can choose to have utilize your open tabs, recent browsing, and the page in front of you, so it can help you do more without switching contexts – all with the privacy and security you expect from Firefox.
What makes it Smart:
When to use it:
Smart Window shines when you need a little extra help finishing what you started. Its ability to work with the context you choose to share can help you make progress on ongoing tasks that may require more than one session, like trip or event planning, comparison price shopping, or conducting research for work or personal reasons.
And with Smart Window’s optional memories, which learn your patterns and preferences over time (with your permission), Smart Window gets more useful the more you use it, keeping you from having to spell everything out from scratch each time.
None of these windows is “better” than the others, they’re built for different moments.
The good news is you are never locked into one. Firefox lets you move between all three depending on what you’re doing, so you can choose the window that fits each task.
You can access Classic and Private windows at any time from the Firefox menu. As for Smart Window, it remains in beta, with current availability to people in the U.S., Canada, and France.
To try Smart Window, visit https://www.firefox.com/smart-window. Or, if it’s not available in your region yet, you can sign up to be notified when it is.
The post Classic, Private, or Smart? Choose the right Firefox window for every task appeared first on The Mozilla Blog.
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
Thunderbird Blog
Greetings once more from the Thunderbird development team!
As the Northern hemisphere summer comes to an end and a slew of PTO, company holidays and projects have wrapped up, what better time to share progress and next steps on the work the Thunderbird Desktop Engineering team has on their plates!?
The powerhouse Exchange engineering team had some great momentum over the summer and completed their work on implementation of the Graph protocol to support email accounts – well in advance of their deadline. They have since moved on to start work to support Exchange calendars using the Graph protocol which is a significant milestone given that our calendar code hasn’t had significant changes for some time.
While some team members are now juggling multiple projects, good progress has been made to wrestle the foundations into place, with calendar discovery and persistence in place, along with display of calendar items. Following a brief hiatus to focus on other priorities, the team is once again back into gear.
Keep track of our Graph API Calendar implementation here.
Since I last wrote, many of the account setup and account authentication improvements have landed (mostly in versions 156 & 157), unlocking some important security use cases which are becoming more frequently requested and mandated by organizations and legislation around the world.
While diving into the code is an enjoyable adventure, the newly-minted articles devoted to the topic of Oauth customization might be a better starting point for most:
Knowledge Base – Custom OAuth for Thunderbird
The front end engineering team has completed the rebuild of our account setup manual configuration flows to include new protocol options and security customizations, so it is time to pick up where we left off on our Calendar UI rebuild.
The majority of the front end team is now either focused on Calendar Event data write operations stemming from the Event Read dialog (delete event, RSVPs, Reminders) – or beginning the largest part of the journey, which is the implementation of a new Calendar Create/Edit dialog, along with REDUX-based state management, a new WYSIWYG editor and more reusable components such as date pickers.
Follow the Calendar Event Create/Edit work here
While that work is underway, why not weave in some more improvements?!
After some extensive user research and testing, our design team has begun work to improve the Settings UI, starting with some updates to humanize and homogenize the various options, headings and guidance provided in that area of the application.
Read more about that journey here
In the past few months, we’ve seen a wonderful increase in contributions from community members – partially thanks to our move away from Mercurial to a more familiar Git-based workflow – and partially thanks to many LLMs doing a great job of interpreting our public codebase and making it far more accessible. Or it could be that our team is just such a friendly bunch that we’ve attracted a great group of people willing to support.
Whatever the reason, we’re happy to see new names. faces and ideas in our chats and review queue!!
Having said that…We’ve reached the point where the velocity of work is beginning to pile up and clog our review queue – so I felt it might be time to share some guidance to make the process easier for both external contributors and the internal review team. Bear in mind that while we use AI workflows in several areas, our goal is to preserve a codebase which can be maintained by humans. We’re working on a policy that may word some of these points better, but from the past few months of my experience here’s what I see as being helpful:
As parts of the world turn their infrastructure priorities toward digital sovereignty, we’ve seen an increase in interest from governments, institutions and organizations around the world who are looking to either improve their existing FOSS-based infrastructure or deploy for the first time. That has resulted in some focused efforts throughout Q3 to improve our Enterprise security and policy framework to bring it in line with the strides that the Firefox engineering team has made, and also roll out more Thunderbird-specific administrative mechanisms that allow granular control over end user configurations. Read more about your options and follow the work below:
Thunderbird Enterprise Policies and Relevant Preferences
Thunderbird Enterprise PoC Work Items
Waves of changes from upstream Firefox have continually kept the team on their toes throughout July & August, but the small but mighty gang have kept Daily builds largely intact each day. In addition, the team and contributor community have continued landing a series of reliability, stability, and usability improvements across the application. Recent highlights include:
If you would like to see new features as they land, and help us find some early bugs, you can try running daily and check the pushlog to see what has recently landed. This assistance is immensely helpful for catching problems early.
Toby Pilling
Senior Manager, Desktop Engineering
The post Thunderbird Monthly Development Digest: September 2026 appeared first on The Thunderbird Blog.
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.20.0:
moz-phab submit is getting the file size from hg/git even if it could infer it from the blob itselfDiscuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
This Week In Rust
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.
This week's crate is fastlogging-rs, a fast logger which supports 8 different programming languages.
Thanks to brmmm3 for the self-suggestion!
Please submit your suggestions and votes for next week!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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.
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!
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!
618 pull requests were merged in the last week
tainted_by_error in LateLintrustc_builtin_macrosDir::try_cloneCommandExt::show_windowfeature(trim_prefix_suffix) ({str,[T], Path}::trim_prefix and {str, [T]}::trim_suffix)windows_process_extensions_main_thread_handlebuild-rs: make unstable compilebuild.warnings='deny'dyn trait methods linking for jump to def featuremust_use_without_reason lintconst_trait_impl related infinite loop in needless_borrows_for_generic_argsextend_with_drain to VecDeque and BinaryHeapsuboptimal_flops for mul_add, custom_abs and radians in const contextformat_args! for uninlined argscfg!()Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
repr(C) ZSTs from others in ABI compatibility ruleswide-arithmetic featurethread_local!mem::conjure_zstCommandExt::exec and opt to use execve and resolve path manuallydebug_closure_helpersfunnel_shifts (including const)Result::into_{ok,err}trusted-contributors marker teamNo Items entered Final Comment Period this week for Rust RFCs, 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.
Rusty Events between 2026-09-23 - 2026-10-21 🦀
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.
Please see the latest Who's Hiring thread on r/rust
operational pedantics
Thanks to Jules Bertholet 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
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
Thanks to Kohei for his work on the newly revised Guided Bug Entry form! If you want to check it out yourself, then click on the Switch to Bugzilla Helper link at the bottom of the enter bug product selection page. Normally users without canconfirm permissions will see the Guided Bug page by default which a large percentage of our Bugzilla users.
Discuss these changes in the BMO Matrix Room
1 post - 1 participant
Firefox Tooling Announcements
The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed:
Highlights:
--with-samply to “profiler-cli load” (#6339)Other Changes:
Sync: l10n → main (Sept 22, 2026) (#6341)Big thanks to our amazing localizers for making this release possible:
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
Firefox Tooling Announcements
Firefox DevTools MCP (firefox-devtools-mcp) 0.10.4 is out on npm.
Changes
This release only contains additional hooks and configuration files to register Firefox DevTools MCP on various third-party aggregators, as well as a new task to automatically register the mcp on https://registry.modelcontextprotocol.io/ on release.
Full changelog: Release v0.10.4 · mozilla/firefox-devtools-mcp · GitHub
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 WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org
1 post - 1 participant
Mozilla Data YouTube Channel
Mozilla Data YouTube Channel
The Rust Programming Language Blog
At the end of August, we announced our first Maintainers in Residence, Rust Project contributors who are funded for their upstream contributions and maintenance work from the Rust Foundation Maintainers Fund (RFMF). Since then, the Rust Leadership Council has dedicated more funds from its Project Priorities budget to RFMF, and together with AWS also providing additional funds, this allowed us to open a new full-time Maintainer in Residence (MiR) position to support the Cargo team. We would like to thank the Rust Leadership Council, AWS, and also the Rust Foundation for providing us with this opportunity! If you would like to help us hire more maintainers to improve Rust, consider donating to RFMF.
This post explains why we chose to support the Cargo team specifically, and introduces Scott Schafer, the new Cargo Maintainer in Residence.
The new MiR full-time position is dedicated to helping with the maintenance of Cargo, our build system and package manager. The Cargo project is deeply involved in many new Rust features, improvements, and Project Goals. Combined with its cross-cutting nature, where it has to support many different use-cases and integrate with several other tools, it takes a lot of work just to keep up with its maintenance needs, let alone support so many feature requests and proposed changes.
Because of that, the Cargo team has sometimes struggled with meeting its maintenance demands. You might remember that for several years, it actually held a feature freeze, to reduce Cargo's internal tech debt, perform necessary refactorings, go through the issue and pull request backlog, and come up with scalable internal development and design processes, so that they could eventually go back to even thinking about adding new features.
Recently, some changes occurred within the team, which made it more difficult for them to meet their maintenance baseline. Some members of the team left, while others lost their dedicated funding for working on Cargo maintenance and had to scale down their involvement. The Funding team thus considered it very important to support this team, given that we had an opportunity to do so. And thus we decided to hire a full-time maintainer to work on Cargo for (at least) the next 12 months.
Even though we know that a single full-time maintainer will not completely solve the maintenance struggles of the Cargo team, we hope that it will improve the situation, and provide a bit of a relief for the team.
We are very happy to welcome Scott Schafer (@muscraft) into the Maintainer in Residence role! Scott has joined the Cargo team three years ago, and apart from working on Cargo, he is also the lead of the Rust Docker team, which prepares official Docker images for every Rust version.
Apart from working on general maintenance of Cargo, Scott has implemented Cargo's Workspace inheritance feature, and has also spearheaded a complex multi-year effort to switch the rendering of diagnostics in the Rust compiler to use the annotate-snippets crate. This effort has been completed in the Rust 1.93.0 release. Thanks to it, the same diagnostics interface can now be shared between the compiler and Cargo (and also other tools), which amongst other things unblocked further development of the Cargo linting system, which has now been stabilized and will ship in the Rust 1.100.0 release.
Everyone we talked about was very excited about Scott becoming a Cargo Maintainer in Residence, and we share that feeling. We wish Scott all the best in his new role, and we are very happy that we can support his maintenance work.
Here is what Scott thinks about it:
I am incredibly excited to work on Cargo full-time! There have been so many things that I wish I could've worked on over the years, that I will now be able to get to. I hope that my efforts will bring Cargo into a more maintainable state.
We are incredibly happy that we keep getting more funds for the Rust Foundation Maintainers Fund, which allows us to support Rust Project contributors. The funding team will be working with the supported maintainers, and also the funders, to ensure that they are all happy with the arrangement, so that we can secure stable funding for Rust maintenance for years to come.
If you would like to help us support more Rust maintainers, consider donating to RFMF!
The Mozilla Blog
When it’s Monday morning and you’re on the subway, in a coffee shop, or squeezing in a few email replies after your morning workout, your phone becomes your digital office. But every time you open your browser, you risk getting struck with any combination of distracting ads, auto-playing videos, and open tabs from the previous week competing for your attention.
For many remote and on-the-go workers, your mobile browser can become a minefield of interruptions and distractions, slowing you down when you need to focus most.
Luckily, there are multiple Firefox features that can help ensure your mobile browser is a focused, productive workspace.
Opening a link shared via text or email can save time and keep things moving when a client or coworker needs a fast response. However, once it’s actually opened, there is a lot of opportunity for various pop-ups, overlays, and ads to get in between you and what you came in to do.
Ad Blocker for Firefox on iOS was built to reduce distractions and screen clutter while you browse, so you can stay focused on the task at hand. It’s a built-in, optional feature that blocks many intrusive ad formats, third-party ad networks, and ad-related trackers. That means no separate extension required, and you decide if and when to use it.
Because Firefox’s strong line-up of ad-blocking and privacy extensions on desktop and Android are not available in the same way on iOS, we built Ad Blocker for Firefox directly into the browser. To decide what gets blocked, Ad Blocker uses the EasyList filter and Apple’s WebKit Content Blocker technology. It won’t impact every ad or sponsored content on a new tab, as those presented directly by host sites and displayed in search results will still be visible.
To try Ad Blocker on iOS, go to Settings > Browsing > Ad Blocker and turn it on to enjoy a cleaner browsing experience.
When you’re on a deadline, scanning through heavy text, ads, and filler content can turn a quick scan into an infinite scroll session.
Firefox’s Shake to Summarize feature helps people get the gist in seconds on both iOS and Android. To use it, simply shake your phone on any web page under 5,000 words, and a clean summary of the page’s content will instantly appear. It can also be activated by tapping the “Summarize Page” option under “More” in the three-dot menu.
Like all Firefox features, we built Shake to Summarize with your privacy and protection in mind. This means using device-specific technology to keep your data secure. You can learn more about the AI powering this feature here.
The feature launched on iOS last September, received a strong response from users, and earned a special mention in TIME’s Best Inventions of 2025. It is now available on iOS and Android in English, German, French, Spanish, Portuguese, Italian, and Japanese.
Just like us, our smartphones tend to live multiple lives: work, personal, and everything in between. While it can be incredibly convenient to have everything you need for all parts of your life on one device, things can get cluttered fast.
One minute you are knee-deep in a client proposal and the next you’re flicking through the countless Google searches from over the weekend. “How old is Harry Styles?” and “Movie times near me” – while pertinent when you were off the clock 24 hours ago – have absolutely nothing to do with the work you are trying to get done now.
To help make sure your prep for Thursday’s client meeting doesn’t get lost in your pop music deep dive from the weekend, you can group related tabs in Firefox for Android. Each group can be labeled and assigned a color, appearing as a single, searchable card in the tab tray rather than separate tabs, so it’s easy to locate when needed. You can open, rename, recolor, and delete these cards whenever you want.
To use Tab Groups on Android, simply drag one tab onto another, or select a few and tap “Add to group.” Label the group, choose a color, and you’re all set. To try it out, download the latest version of Firefox for Android. iOS support for this feature is on the way.
Sometimes we start a task on one device and finish it on another. Maybe you found an article on your computer that you want to read on the subway on your phone. Or, perhaps you want to pull out your laptop and finish filling out that lease application you started on your tablet.
Enable Firefox Sync and you can resume tasks you paused in your browser when switching across your mobile phone, tablet, and laptop. The feature lets you access your open tabs, bookmarks, and passwords across all the devices you access Firefox on.
The best part? We put your data privacy first. Firefox Sync uses end-to-end encryption so your synced data is encrypted before it reaches Mozilla’s servers.
To take your browsing experience with you wherever you go, connect your iOS or Android phone to your Mozilla account and start syncing with your other devices.
For remote and on-the-go workers, focus is everything.
With Firefox features like built-in ad blocking on iOS, Shake to Summarize for instant insights, and Tab Groups on Android to keep your work and personal digital spaces organized, you can transform your phone from a distraction hub into a productive workspace.
Download the latest version of Firefox for Android or Firefox for iOS today to test out any of the above features available on your device – and take back control of your attention.
The post Stay focused wherever you work with Firefox mobile browsers appeared first on The Mozilla Blog.
The Rust Programming Language Blog
The Rust Security Response Team was notified that Miri stores all environment variables to target/, allowing secrets to persist in caches.
While not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose secrets to PRs.
GitHub Actions makes it possible to cache directories between runs. Typical setups allow CI runs on main (and other branches) to write to cache, and PRs can only read from cache (preventing cache poisoning). Rust projects tend to speed up CI by caching binaries built by cargo install and sometimes the contents of target/.
PR CI can be triggered by anyone who can open PRs on your repository. GitHub requires maintainer approval for the first PR, but future PRs will rerun CI on every push. Anyone who has previously landed a change can trigger a CI run extracting information from cached target/ and then cover their tracks by pushing a second commit to the PR.
GitHub sometimes hides overwritten commits in its UI, making this kind of attack harder to detect. CI run logs and overwritten commits are also deleted after a few months.
When cargo miri is invoked, Miri needs to retain build-relevant environment variables between runs1. The current code to do so achieves this by storing all environment variables to target/. This, of course, persists when target/ is cached.
If your environment contained secrets, these can now be accessed by PRs via the cache.
Our short term fix for this is to make Miri only preserve CARGO_* environment variables (excepting CARGO_*_TOKEN) and OUT_DIR. In the longer term, Miri and cargo may figure out better ways to inform Miri of the relevant list of environment variables. Note that this patch may not be available on nightly yet.
We also performed an ecosystem scan of GitHub repositories and identified 1 repository with this issue and 7 repositories that do not appear to be vulnerable but should be cautious anyway. We have reached out to those maintainers.
It is likely that our scan was imperfect, so we recommend you check your own GitHub Actions setups if you run Miri.
You are vulnerable if:
cargo miri in CIcargo miri has access to secrets as an environment variable:
env for the workflowtarget directory, usually done via actions/cache or swatinem/rust-cachePossible quick fixes include:
Once done, please clear the cache. Consider rotating any secrets that might have leaked.
The Miri release in the upcoming nightly (2026-09-22) will no longer have this problem.
Even if you do not run Miri, ensure jobs that can write to public caches do not have access to secrets. Many tools do not have special handling for secrets, and assume the entire environment can be written to the filesystem.
We consider it bad practice to have a cache that can easily be tainted by secrets.
If caching target/, it is worth making sure that the inputs to processes that create target/ (anything invoking cargo) do not have secrets available. It is generally rare for standard cargo build/test subcommands to need any secrets or tokens2, so this is mostly a matter of being careful about having secrets exposed as environment variables to the entire job.
Cargo/Miri/Rust does not guarantee that environment variables will be safe from being copied into target/. While we are treating this as a security issue and patching it out of an abundance of caution, this is not something you should rely on in general. Beyond official Rust tooling, it is possible for build scripts to be doing things that lead to the environment being stored in compilation artifacts.
Thanks to Predrag Gruevski of OpenAI for reporting this issue to us. Furthermore, the ecosystem scan was performed using Codex access and credits donated by OpenAI, which we also thank them for.
Issue triage and remediation was performed by Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone, and Mark Rousskov.
Firefox Tooling Announcements
Firefox DevTools MCP (firefox-devtools-mcp) 0.10.3 is out on npm.
New features:
close_firefox_session — ends the browser session: it releases the connection when the server is attached to an existing Firefox, and closes the browser when the server started it.fullPage for screenshot_page — captures the whole scrollable document instead of the viewport.downloadFolder for set_download_behavior — only used when setting the “allowed” behavior, it sets the folder where downloads should be stored and defaults to ~/.firefox-devtools-mcp/output/downloads.Bug fixes:
restart_firefox now rejects when used against a server started with --connectExisting, whereas it used to restart the WebDriver session without restarting the browser and silently ignored all its configuration parameters.Other changes:
--connectExisting now disconnect after 30 minutes without any tool call.restart_firefox is now part of the mozilla-internal package, and should only be used in controlled environments, as it allows the agent to restart the browser with a custom configuration. Instead, the new tool close_firefox_session can be used whenever clients do not need to update the browser configuration, and will have a more consistent behavior.saveTo parameters have been improved to avoid overlapping with existing profile foldersInstall:
claude mcp add firefox-devtools npx @mozillamozilla/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: f3tch (github), shoemoney and mightykatun.
Full changelog: Release v0.10.3 · mozilla/firefox-devtools-mcp · GitHub
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 WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org
1 post - 1 participant
The Mozilla Blog
Today at ALL IN, Canada’s largest AI and technology event, Mozilla and Mila announced a new initiative and fresh investment to build an open source AI foundation layer that enables organizations and institutions to own and operate advanced AI systems locally, ensuring full control over their technology and data.
Doubling down on its commitment to open source AI, the Government of Canada announced its support for the initiative. Mila will lead the technical delivery and coordination of the project, while Mozilla contributes technical expertise. It also provided the initial $5 million investment to kick off the project. Hypertec is committing an additional $1 million in first-year funding to accelerate initial Canadian deployments of the open source AI foundation layer on Hypertec hardware.
“Canada has a choice: depend on technologies developed elsewhere, or build more of what we need here at home,” said The Honourable Evan Solomon, Minister of Artificial Intelligence and Digital Innovation and Minister responsible for the Federal Economic Development Agency for Southern Ontario. “Open source AI gives Canadian businesses and institutions greater control over their technology and data, while making powerful tools more affordable, accessible, and easier to adapt. By supporting this work, we are strengthening Canada’s capacity to build and adopt AI on our own terms.”
Mila and Mozilla will lead the work together: Mila drawing on a world-class community of close to 2,000 researchers and professionals, Mozilla as technical partner from industry, bringing 25 years of experience stewarding open infrastructure others build on. Mila and Mozilla are actively engaging new partners, inviting companies, research institutions, funders, governments, and developers to join and support this work.
The goal is simple: make owning your AI as easy as renting it. Using open source models was never the hard part. Turning a raw open source model into something a small business, a hospital, a local charity, or a government can run in production — secure, reliable, plugged into everything else — takes an engineering team most organizations and institutions do not have and months they can’t spare.
The goal is to offer businesses and organizations a ready-to-use AI package that they can run privately and keep under their own control, rather than having to build a complex system themselves or rely entirely on expensive, pay-per-use proprietary AI services.
For example, a small manufacturer could use the system as a private AI assistant for its employees. It could search the company’s manuals, procedures, and past project files; help staff draft reports or answer technical questions; and help its software team write and improve code. Because the system is designed to be able to run locally, the company could do this while keeping its proprietary information and data within its own environment.
That also means lower costs. For the vast majority of everyday business tasks, companies will be able to use open source AI running on open source tools instead of paying a commercial provider every time an employee makes a request. But this requires reducing the technical work and expense involved in putting open source AI into practice.
This initiative was founded to solve that problem, building the free layer that makes owning open source AI easy — the same kind of layer the web was built on. It has two halves: An open standard, published as interface contracts, so any part of the stack can be swapped for a better one. And a working “reference implementation” any organization can install on its own machines or the ones it chooses, running the models and controls it chooses against its own data, with governance and access control built in from the start. The ambition is that with the standards and foundation in place, open source AI can be built anywhere, by anyone.
“Six months ago, we announced our partnership with Mozilla to advance open source and sovereign AI. Today, we are bringing that work to a whole new level,” said Valérie Pisano, President and CEO of Mila. “By delivering an open, secure AI foundation layer, we empower organizations, from small businesses to non-profits to governments, to own their technological future so they can run, control, and maintain AI models themselves. At Mila, our research community has always believed that for AI to be trustworthy and accessible, it must be built on open standards that keep control in local hands.”
Over the last six months, Mila and Mozilla have been designing the architecture, deciding which open source components belong at each layer, and testing that the whole system works end to end. This investment builds on that progress.
Working alongside Mila and Mozilla, Hypertec will help move the initiative from research and reference implementation to real-world adoption by Canadian businesses and institutions, providing a practical, private, and cost-effective path to deploy AI while maintaining greater control over their data and technology.
“AI is advancing at an extraordinary pace and has the potential to transform our economy and society for the better. Canada has an important role to play in ensuring that AI is developed and adopted responsibly, said Simon Ahdoot, CEO of Hypertec Group. “Hypertec is proud to help turn open source innovation into AI that Canadian organizations can deploy securely and under their own control. This is exactly the kind of partnership between government, research, and Canadian industry needed to realize the full potential of AI.”
Mozilla’s State of Open Source AI report found that while 79% of developers adding AI functionality use open models, only 53% of teams ever reach production, stopped by cost, security, integration, and maintenance. This work aims to change that.
“AI today is at a crossroads, where it could be closed and owned by a few, or open and available to every coder, developer, enterprise, and nation,” said Mark Surman, President of Mozilla. That’s what we’re building — an open source AI ecosystem that fits together as seamlessly as the web, and that anyone, anywhere can build on. We’re so grateful to Canada for scaling this work, and call on partners across sectors — from enterprises and governments to coders and startups — to join us in building this future.”
Within six months, Mozilla and Mila expect to publish working reference implementations for enterprise, government and public-interest use cases. The two-year ambition is bigger: to have solved this problem outright, so that open source AI can be adopted fully and easily, anywhere, by anyone.
The post Mila and Mozilla announce new initiative to build trustworthy open source AI for everyone, with Canadian government support appeared first on The Mozilla Blog.
Firefox Nightly
Script to find new contributors from bug list
Mozilla Privacy Blog
This is the second part of a two-part series in which we explore approaches to protecting children online while safeguarding privacy, security and the open web. Part one covers our concerns regarding age gates, and suggests alternative policy proposals that address the root causes of online harms. Part two explores better ways to build age assurance architectures that respect users’ rights and autonomy.
Across the world, legislation to introduce age gates and social media bans is proliferating. Many governments are still considering age restrictions a straight-forward and cost-effective tool to achieve their child safety goals. However, evidence is mounting that age assurance mandates pose risks to users’ privacy, security, free expression and access to information, threaten the open web and competition, and undermine policymakers’ goals: enabling young people to have safe and trustworthy experiences online, while enabling the digital economy to grow.
As we have said before, we believe that blunt tools like social media bans are overly broad, undermine users’ rights and do not address the root causes of online harm. Reducing risks to young people online requires a holistic, privacy-first approach to online harms emphasizing enforcement of existing rules, addressing harmful design, and equipping all users with better defaults, more choice and granular controls over their experiences online.
Age gates alone are insufficient to address online harms, but age signals can contribute to more holistic approaches by helping achieve age-appropriate experiences online. Where age assurance obligations are considered as one tool out of many to foster age-appropriate experiences, their potential benefits must be balanced against their negative implications for users’ privacy and security, access to services, and the openness of the web.
Implementing age assurance is not a single intervention, but a series of steps. A user’s age is first assessed, which can happen through a variety of sources of age information and with varying degrees of accuracy. That signal is secondly shared with the actor responsible for age-appropriate experiences, and thirdly acted upon or enforced by that actor.
Dominant approaches to age assurance obligations focus on online platforms – given that this is where many risks encountered by young people unfold. In practice, this has led to online services – websites or apps – turning to third-party age assurance providers to perform age assurance, whether through biometric age estimation, age inference based on users’ behavioral data, ID-based checks, or other methods.
In this model, third-party age assurance companies both assess users’ ages and share that signal with the platforms responsible for implementing it. To retain access to social media platforms, messaging services and many other online offerings, users are thus forced to surrender their sensitive personal data to these age brokers, often a different one for each service.
Once in the hands of these providers, peoples’ data is at risk of being sold, repurposed or accessed by law enforcement. The recent data breach of a ID and age verification provider that exposed more than 153 million IDs underscores that this is not a theoretical concern, but a significant risk for anyone asked to prove their age online. Rather than being asked to trust companies, some of which have already been exposed for their harmful data practices, people deserve verifiable guarantees that their data is safe and secure.
Emerging regulatory models are considering the role that device intermediaries, like operating systems, device manufacturers, and app stores, can play in age assurance. In such models, these actors are either required to communicate an age signal to the actor responsible for acting on it, or to restrict access to services themselves, based on an age signal created at the device level.
Device intermediary focused approaches, too, come with significant challenges: Given the significant concentration of power among (mobile) operating systems and app stores, such a legislative design can easily further entrench the dominance of Apple and Google, disadvantage open source competitors, and undermine users’ privacy and control, including over their devices. These implications must be carefully mitigated.
Every approach to age assurance comes with important trade-offs, and we maintain that there is no age assurance system that mitigates all risks to users’ fundamental rights, access to services, competition and the open web, while being effective in avoiding every instance of under-age access. However, we do believe that better age assurance architectures are possible. In many situations, unverified age signals may be sufficient to provide age -appropriate experiences without undermining fundamental rights. Where stronger assurances are considered necessary, zero knowledge architectures can help protect users’ privacy.
Better age assurance architectures must be private, secure, accessible to all users, and, crucially, must provide them with autonomy, choice and control. Designing age assurance obligations that live up to these values is a question of governance, not technology. Hence, policymakers have a crucial role to play in defining requirements for rights-respecting age assurance systems.
1. Assign responsibilities deliberately.
From people’s devices, to operating systems, app stores and websites or apps, many actors can be involved in age assurance processes. Some of these actors will be better suited to be responsible for certain steps of age assurance processes than others to avoid negative outcomes for fundamental rights and the open web.
Given that websites and apps know most about their services, their features and content hosted, we argue that they are in the best place to act on age signals to provide age-appropriate experiences. Implementing age signals at this level allows for more granular choices for creating age appropriate experiences. Other actors, like network operators or device vendors, simply do not have the necessary information.
While websites or apps are best placed to create age appropriate experiences, device intermediaries like operating systems are well-placed to facilitate the privacy-preserving sharing of age signals created locally. Moving age assessments to the device-level allows users to interact with an age provider once, rather than having their age assessed by a different age provider for every service they use. If such approaches are pursued, strong protections need to be in place for open source operating system providers, as well as mandates for the development of open and free standards to avoid fragmentation and competition harms, and to strengthen transparency and user consent
2. Ensure choice, equity and accessibility.
Age can be attested to, approximated or verified in many ways. Every age assessment method comes with important trade-offs, but people should not be forced to take risks on their personal data and safety to retain access to services and information. Users should thus always have a choice between multiple age providers that are privacy-preserving, non-discriminatory and accessible. This is especially important for young people who often don’t have access to more privacy-preserving age assurance methods, and are expected to hand over their biometric data to stay online.
The question of which providers are deemed trustworthy enough to participate in such a system is a crucial one. Policymakers must ensure that the options available to people protect their privacy and security, and that a diverse list of providers prevents people from being locked out. Only if everyone has the ability to access age assurance systems through privacy-preserving and rights-respecting providers, will the web remain accessible and open. People should be able to rely on a plurality of institutions, government or private, that can either attest to their age, including face-to-face, or have existing knowledge of their ages that they can share through the use of anonymous credential technology. Examples might be banks, public health and educational institutions, libraries, or services like phone providers, ISPs, subscription services or other services that are able to attest to a user’s age.
3. Put people in control.
We should always be in control over what information is shared about us, and to whom. Once an age signal is created, age assurance architectures should empower users to hold that signal – in the form of a credential – on their device. Whether an age signal is shared with an app or website by the operating system or the browser, users must be in control of the decision whether and to whom that information is shared with.
Users must also retain control over – and trust in – their devices. Digital devices are the interface through which we all navigate increasingly large parts of our lives; they are our trust anchors. Enforcing restrictions at the device level on what people can or cannot do online would undermine the already fragile trust relationship between the two — pushing people toward less secure workarounds, rather than addressing the underlying policy concern.
This means that it is best when responsibility for sharing the results of age assessments is performed by users and their devices.
4. Assess risks end-to-end.
Many jurisdictions require age assurance systems to be “highly effective”. We believe that the effectiveness of an age assurance system should be considered end-to-end, and not be limited to the assessment step: After all, where an older relative or friend is willing to help a child circumvent a block, no technical mechanism can be effective.
Given these considerations, we think there is value in considering age assurance approaches that empower parents to attest to their child’s age when setting up their device. Coupled with barriers to resetting the age once set, such an age signal would provide a high degree of confidence without requiring invasive proofs of age through biometric analysis or ID document checks. As noted above, such approaches need to ensure that age attestation is not another factor cementing the dominance for a few actors, and that open source projects are meaningfully protected from being locked out of participating in a market.
Despite those challenges, we believe that it is crucial to not only consider the potential risks young people could encounter online, but also the risks flowing from age assurance systems themselves. Given those risks, parental age attestation can be a lower-risk approach suitable in many contexts.
5. Leverage zero-knowledge architectures.
Where high-assurance age credentials are used, zero-knowledge architectures are the right step towards sharing age signals in a privacy preserving way. Such approaches allow users to verify the truth of a statement about them, like their age or age range, without having to reveal the information on which the statement is based.
While zero-knowledge architectures are promising, they do not solve every issue. Beyond limiting disclosure of information about people (such as attributes other than their age), hiding the issuer of age credentials (like a bank, public service or educational institution) is key to preserving users’ privacy and choice of assessment methods. This prevents discrimination against users of smaller or less common age providers.
Likewise, the issuer of an age credential should not know which service or feature someone is accessing with an age proof. The example of Spain’s Catera Digital, or “porn passport”, shows why: The Spanish age verification system created tokens that the verifying authority could use to infer a user’s browsing history, undermining users’ privacy, trust, and ultimately the adoption of the system.
Zero-knowledge proofs themselves also do not prevent abuse of age information, such as by using age data in ad targeting. Beyond strict prohibitions on repurposing age data, we believe that any age assurance system should be open source to facilitate trust, accountability and transparency.
To prevent the sharing of age tokens, we believe rate limits, which restrict how often an age token can be used, are the best and most effective solution. We strongly caution against linking tokens to attested hardware, such as trusted platform modules (TPMs). Hardware-bound tokens force users to use specific, approved hardware. Hardware attestations can leak details about the device’s configuration and location, thus enabling tracking or unjustified discrimination at the moment of certification issuance. Attestations undermine users’ freedom over their own devices, including what software they can install and run. People who run older or unsupported devices might be excluded as old, weak hardware is routinely found to be compromised, such that it needs to be revoked. Rate limits offer a far simpler and more robust answer to these challenges.
6. Don’t break the internet.
The open internet – and the web built on top of it – is a global public resource that millions depend on every day, and that has become a cornerstone of our societies. This openness thrives on open standards, shared protocols, and interoperability. Age checks risk fragmenting the web in more ways than one: Incompatible requirements will create a patchwork of age-gated communities, and age gates in the hands of a few will push people further into closed ecosystems, undermining the wider digital competition and the decentralization that gives the internet its strength.
To avoid the hollowing out of fundamental rights online, and the undermining of the open internet, international collaboration and free and open standards are urgently needed to govern age assurance across borders.
***
We believe the principles set out above can help mitigate the large-scale erosion of privacy, security, and agency that the first wave of age assurance laws and social media bans has introduced.
But improved legislative mandates and technical fixes alone are not enough to improve young people’s online experiences in a rights-respecting way. Enabling young people to develop positive relationships with digital technologies is foremost a societal issue, not a technical one. Changing norms around how we engage with technology, what we ask of companies seeking our attention, and how we have conversations about what safety means beyond abstinence and control will require a whole-of-society approach to digital well-being.
The post Pragmatic principles for more rights-respecting age assurance architectures appeared first on Open Policy & Advocacy.
The Rust Programming Language Blog
We believe that there is an ongoing campaign targeting rust-lang members and owners of popular crates that is attempting to compromise devices and accounts in order to use them to publish malware.
A video call is set up for something positive — maybe for a job, maybe for a project, maybe for a contract opportunity — and then that's used as a vector to either get the target to install something on their computer (such as a purportedly missing audio codec) or execute another command (for example, via putting a command on the clipboard).
These attackers are setting up new but legitimate seeming company profiles, including plausible LinkedIn presences, in order to pass cursory inspection.
A previous attack of this form targeted many prominent Rust developers in
June, and, last month, the arrayref crate was briefly compromised through similar
attacks. At this moment we do not know if these are all a part of the same
campaign.
This attack style is known to be used by the DPRK, and has been seen outside of the Rust community as well.
Please take extra care in the near term. Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust — ideally, try to be the one who sets up the call on a platform you already use.
Please also re-check that your accounts look normal: MFA enabled, no unexpected logins on platforms that can track that, and so on.
If you have any concerns about your accounts, please reach out to help@crates.io (for crates.io account concerns) and/or security@rust-lang.org (for any other concerns). We're very happy to help.
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
bug/{bugid}/comment returns wrong comment_idDiscuss these changes in the BMO Matrix Room
1 post - 1 participant
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.19.1:
Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
The Mozilla Blog
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.
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.
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.
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
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:
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.
fWith 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.
This Week In Rust
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.
This week's crate is zenjpeg, a pure Rust JPEG encoder and decoder.
Thanks to Kornel for the suggestion!
Please submit your suggestions and votes for next week!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or
guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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!
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!
523 pull requests were merged in the last week
rustc_builtin_macrosDenseBit for drop_live_at in liveness tracingBox<[Word]> for word storage in DenseBitSetBoxThread::os_idExtend implementationsVec::from_fncore::mem::DropGuardunsafe_cell_accessfix(git): For git cli, tell users what config we aren't forwarding on errorfix(install): use packaged lockfile by defaultmanual_readme and non_kebab_case_bins to allow--edition in messages testsmax_width within macrosconst when formatting inline const blocksmap_clone: avoid suggestions after type-changing coercionscollapsible_match suggesting wrongly for conditional compiled codemanual_swap in const contextshir::Type owner mismatches between anon constsimpls_trait for self type of builtin derive impls for generic typesThere were almost no regressions this week, and several performance improvements! Though some of them were reverts of regressions from a previous week. #162422 improved the performance of Polonius, whose performance is getting closer to the previous NLL borrow checker.
Triage done by @Kobzol. Revision range: 656a9da1..20d35a3a
Summary:
| (instructions:u) | mean | range | count |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
0.4% | [0.1%, 0.9%] | 3 |
| Improvements ✅ (primary) |
-0.7% | [-4.4%, -0.1%] | 199 |
| Improvements ✅ (secondary) |
-0.9% | [-2.7%, -0.1%] | 222 |
| All ❌✅ (primary) | -0.7% | [-4.4%, -0.1%] | 199 |
0 Regressions, 5 Improvements, 5 Mixed; 2 of them in rollups 40 artifact comparisons made in total
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
debug_closure_helpersthread_local!funnel_shifts (including const)mem::conjure_zstResult::into_{ok,err}wide-arithmetic featureCommandExt::exec and opt to use execve and resolve path manuallyAllocatorNo Items entered Final Comment Period this week for Rust RFCs, 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.
Rusty Events between 2026-09-16 - 2026-10-14 🦀
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.
Please see the latest Who's Hiring thread on r/rust
Every so often I am told about some maths fact that I can only assume someone went to prison for discovering
Thanks to Chayim Refael Friedman 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
The Servo Blog
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:
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:
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
Script to find new contributors from bug list
Jonathan Almeida
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
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.
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.
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.
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.
P.S.
Enjoyed these updates? Subscribe to the Mozilla Community Newsletter and get the latest updates delivered straight to your inbox.
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
Discuss these changes in the BMO Matrix Room
1 post - 1 participant
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.19.0:
moz-phab patch --apply-to here should apply to the original base revision and rebase, rather than applying the raw diff on HEADmoz-phab list subcommandDiscuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
Thunderbird Blog
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
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.
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.
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.
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.
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
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
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.
const fn: Parse files, build tables, and catch mistakes … without a build script (Part 2)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!
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
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.
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!
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!
613 pull requests were merged in the last week
(try_)map on UniqueArc and UniqueRcmap/try_map deallocate callsdocs(lints): how to configure Cargo lintsdocs(trim-paths): add limitations and polishdocs(trim-paths): workspace remap begins with .fix(git): Apply pr hint to git-fetch-with-clifix(git): Make PR dep note cloer to our style guidefix(git): Simplify error messagefix(git): Use git's 429 retry, when availablefix(parser): Resolve theoretical use-after-freewrite_atomicnone|object|allcfg_select! armsunnecessary_self_imports: lint nested importslegacy_numeric_constants: make fixes machine-applicablestd_instead_of_core: don't suggest a path that does not resolveuseless_conversion: ignore From::from in generated codeuseless_format: improve suggestionregex_creation_in_loops: check MIR loop structureis_in_testinteger_division_remainder_used in macrosmap_unwrap_or lint to support map(f).unwrap_or_default()clippy_ci_panic_test integration into a regular testneedless_pass_by_valueclippy::all to clippy::defaultNamedTempFile constructors#[unsafe()] attrs without inner metaself:: in fn param list1f64 use float instead of integerhir_def::hir::Expr::Unsafe into Expr::BlockThis 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
An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.
If you are a feature implementer and would like your RFC to appear in this list, add a
call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.
No calls for testing were issued this week by Rust, Rustup or Rust language RFCs.
Let us know if you would like your feature to be tracked as a part of this list.
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
i686-pc-windows-msvc from Tier 1 with host tools => Tier 1 without host toolsEvery week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
core::fmt::NumBuffer in alloc (and std)core::mem::DropGuardNo 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.
Rusty Events between 2026-09-09 - 2026-10-07 🦀
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.
Please see the latest Who's Hiring thread on r/rust
The Demon has access to a Super Turing Machine.
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
Firefox Nightly
Script to find new contributors from bug list
The Rust Programming Language Blog
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:
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:
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!
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:
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):
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:
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:
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:
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:
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:
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%:
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%:
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%:
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%:
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:
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:
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.
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:
enums are represented by debuggers so they show actual
variantsHashMap) are represented by debuggers so
they show their contents, rather than their implementation detailsString and CString) are represented
by debuggers so they render as text, rather than their implementation detailsasync debugging experience, particularly with stack tracesFutures)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 (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.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 WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org
1 post - 1 participant
Firefox Tooling Announcements
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
Mozilla Performance Blog
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.
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:
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.)
Several follow-ups on the way:
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
The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed:
Highlights:
Other Changes:
Sync: l10n → main (September 3, 2026) (#6301)Big thanks to our amazing localizers for making this release possible:
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
The Rust Programming Language Blog
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 stableIf you don't have it already, you can get rustup from the appropriate page on our website.
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!
Many people came together to create Rust 1.98.1. We couldn't have done it without all of you. Thanks!
Thunderbird Blog
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!
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:
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.
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.
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.
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.
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.
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!
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
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.
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.
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 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
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.
Firefox Developer Experience
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:
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.dblclick event is fired when performing a double-click while holding down the Ctrl key on non-macOS platforms.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!
A complete list of developer-facing changes included in this Firefox release is available in the MDN Firefox 155 Release Notes.
Mozilla Privacy Blog
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.
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.
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.
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
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.
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.
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.
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
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.
The headlines of this release are:
Concurrency in certain rustup operations has been improved:
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
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
--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!
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 updateRustup will also automatically update itself at the end of a normal toolchain update:
$ rustup updateIf 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.
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 again to all the contributors who made this rustup release possible!
Mozilla Privacy Blog
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)
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.
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.
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.
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.
Here is a shortlist of the varying projects I had the opportunity to work on at my time with the L10N team.
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.
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.
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.
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.
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.
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.
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. 🙂
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
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:
Plus a bunch of new DOM APIs:
This is another big update, so here’s an outline:
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
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).
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).
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.
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.
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).
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).
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).
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).
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:
"delete") on Document (@TimvdLippe, #46265)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).
A special thanks to the following people for landing their first patch in Servo:
Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!
Thanks again for your generous support! We are now receiving 7824 USD/month (+1.8% from June) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo.
Servo is also on thanks.dev, and already 35 GitHub users (same as June) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.
We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you’re interested in this kind of sponsorship, please contact us at join@servo.org.
Use of donations is decided transparently via the Technical Steering Committee’s public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.
Firefox Tooling Announcements
Bugs resolved in Moz-Phab 2.18.0:
moz-phab incorrectly uploads symlinks as text files when using MercurialDiscuss these changes in #engineering-workflow on Slack or #Conduit Matrix.
1 post - 1 participant
Serge Guelton
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>
voidtranslate(std::vector<std::string>&w,void(&t)(std::string&));
voidtranslate(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>
voidtranslate(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--warmup5"/usr/bin/clang++ -O2 algo0.cpp -c"
Benchmark1:/usr/bin/clang++-O2algo0.cpp-c
Time(mean±σ):267.7ms±7.4ms[User:234.6ms,System:30.4ms]
Range(min…max):259.7ms…277.3ms11runs
%hyperfine--warmup5"/usr/bin/clang++ -O2 algo1.cpp -c"
Benchmark1:/usr/bin/clang++-O2algo1.cpp-c
Time(mean±σ):173.6ms±46.3ms[User:149.6ms,System:22.1ms]
Range(min…max):130.4ms…231.6ms13runs
Creation of the unified file is just a matter of invoking cat, let's benchmark the compilation of the unified source:
%catalgo{0,1}.cpp>unified_algo.cpp
%hyperfine--warmup5"/usr/bin/clang++ -O2 unified_algo.cpp -c"
Benchmark1:/usr/bin/clang++-O2unified_algo.cpp-c
Time(mean±σ):223.8ms±64.5ms[User:193.0ms,System:28.4ms]
Range(min…max):160.8ms…301.8ms10runs
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.
Let's create a shared object from algo{0,1}.o (this implies a recompilation with -fPIC of the sources):
%/usr/bin/clang++-O2algo0.cpp-c-fPIC
%/usr/bin/clang++-O2algo1.cpp-c-fPIC
%/usr/bin/clang++-sharedalgo{0,1}.o-fPIC-oalgo.so
And do the same from unified_algo.o:
%/usr/bin/clang++-O2unified_algo.cpp-c-fPIC
%/usr/bin/clang++-sharedunified_algo.o-fPIC-ounified_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.
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.
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.
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
constexprdoublepi(){return3.141593;}
/* pi1.cpp */
#define PI 3.14159265
constexprdoublepi(){return3.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).
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 */
staticfloatdoit(floatf){returnf;}
constfloatf=doit(1);
/* overload1.cpp */
staticdoubledoit(doubled){returnd;}
constdoubled=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.
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
namespacea{
namespacea{}
}
/* using0.cpp */
#include"using.h"
usingnamespacea;
/* using1.cpp */
#include"using.h"
usingnamespacea;
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 */
namespacea0{
intvar;
}
usingnamespacea0;
intfoo=var;
/* namespace1.cpp */
namespacea1{
intvar;
}
usingnamespacea1;
intbar=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...
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
namespacemozilla::dom{
classLockfinal{};
}
#endif
==>header1.h<==
#ifndef H1
#define H1
#include "header0.h"
classLock{};
classAutoUnlock{
Lock*lock_;
};
#endif
==>src0.cpp<==
#include "header1.h"
==>src1.cpp<==
#include "header0.h"
==>src2.cpp<==
namespacemozilla::dom{};
usingnamespacemozilla::dom;
usingnamespacemozilla;
==>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:
%forpermin0,12,30,1,21,2,30,1,2,3;doprintf"unifying $perm... ";cat`evalechosrc{$perm}.cpp`|clang++-xc++--fsyntax-only2>/dev/null&&echook||echoko;done
unifying0,1...ok
unifying2,3...ko
unifying0,1,2...ok
unifying1,2,3...ko
unifying0,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.
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>
staticintdoit(intf){putchar('0');returnf;}
constintf=doit(1);
/* silent1.cpp */
#include<cstdio>
staticdoubledoit(doubled){putchar('1');returnd;}
constdoubled=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.
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
Following the symbolication work from Part 1, I undertook two more efforts to improve performance profiles for the Performance team.
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:
samply and the corresponding build symbols.profiler-edit (formerly symbolicator-cli) and create compact and labelled variants of the profiles.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)
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!
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:
mozgeckoprofiler’s fallback symbolication service.simpleperf, rather than producing a profile for each test suite.The Rust Programming Language Blog
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!
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:
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!
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 :)
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.
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!
Being funded to work on Rust means I can sustainably focus my time and energy on a project I call a passion of mine.
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.
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.
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
Firefox Tooling Announcements
The following changes have been pushed to bugzilla.mozilla.org:
Discuss these changes in the BMO Matrix Room
1 post - 1 participant
Collected here are the most recent blog posts from all over the Mozilla community. The content here is unfiltered and uncensored, and represents the views of individual community members. Individual posts are owned by their authors -- see original source for licensing information.
About:Community Andreas Farre David Burns Firefox Add-on Reviews Firefox Application Security Team Firefox Developer Experience Firefox Nightly Firefox Tooling Announcements Firefox UX Hacks.Mozilla.Org Jonathan Almeida Ludovic Hirlimann Martin Thompson Mozilla Addons Blog Mozilla Data YouTube Channel Mozilla GFX Mozilla Localization (L10N) Mozilla Performance Blog Mozilla Security Blog Niko Matsakis Ryan Hunt Serge Guelton Support.Mozilla.Org The Mozilla Blog The Rust Programming Language Blog The Servo Blog This Week In Rust Thunderbird Blog Tom Ritter William Lachance 
