fidzu : Mozilla

Highlights

• Some Picture-in-Picture improvements have landed recently from some volunteer contributors, and should be going out in Firefox 141 on July 22nd:
  • Thanks to new contributor nrcrast for adding a new PiP wrapper for Peacock, SkyShowtime and Showmax, overall improving video playback and supporting PiP captions for those sites.
  • Thanks to new contributor gaastorgano for resolving an issue with the PiP window failing to function when a video is still buffering
• Carlos contributed a new i18n.getPreferredSystemLanguages WebExtensions API method (an addition to the i18n discussed in the W3C WebExtensions Community Group and now implemented by Safari and Firefox)
• Serah Nderi added the ability to print stacktrace for logpoints

• Spencer introduced a WindowManager.supportsWindows() helper to our implementation of WebDriver BiDi and Marionette to make it easier to detect whether the application supports multiple windows.

Friends of the Firefox team

Resolved bugs (excluding employees)

Volunteers that fixed more than one bug

• Gabriel Astorgano
• Gregory Pappas [:gregp]
• Masatoshi Kimura [:emk]

New contributors (🌟 = first patch)

• Gabriel Astorgano:
  • Bug 1828299 - [Picture-in-Picture] Popping out the video when it's buffering causes the Play/Pause button to get stuck [display] as the Play button + this button doesn't work
  • Bug 1959029 - Sidebar icon does not reflect sidebar position (left/right)
• Jason Jones: Bug 1959616 - Move browser-window UI functionality for session restore from browser.js and BrowserGlue.sys.mjs to a session restore module
• 🌟Nick Crast: Bug 1965895 - Add Peacock, SkyShowtime, Showmax, and Now TV to Picture-In-Picture video wrappers

Project Updates

Add-ons / Web Extensions

WebExtensions Framework

• Fixed attention dot on pinned extension not updated in non-active windows - Bug 1967564
• Fixed data collection permissions removed from the manifest between add-on updates not being revoked from the set of granted permissions (fixed in Nightly 141 and uplifted to Beta 140) - Bug 1971414
• Set a fixed uuid in the moz-extension url for the webcompat built-in add-on, as a short term mitigation to prevent webcompat moz-extensions urls to be used for user fingerprinting - Bug 1717672

WebExtension APIs

• Fixed a regression introduced in Firefox 139, which prevented browser.notifications.create non-system notifications from showing icons set as data and/or blob urls (fixed in Nightly 141, uplift requested to ESR 140) - Bug 1970075
• Emilio investigated and fixed a recent regression related to the browserSettings.useDocumentFonts, which was preventing the browser settings from affecting the webpages until the next page reload (regressed in 138, fixed in nightly 142 and uplift requested for ESR 140 and Beta 141) - Bug 1972971
• Christina introduced support for filtering by cookieStoreId the tabs.onUpdated events - Bug 1960011

DevTools

• Alex Jakobi [:ajakobi] added Dynamic toolbar in RDM, under the devtools.responsive.dynamicToolbar.enabled pref (Bug 1970616, Bug 1970617, Bug 1970618)

• James Teh [:Jamie] made it possible to pick menu items in XUL menus with the accessibility inspector picker (Bug 1972759)
• Holger Benl [:hbenl] fixed the color picker in RDM when touch simulation is enabled (Bug 1932143) and made sure the underlying screenshot we take for the picker is updated when the page is resized (Bug 1295057)
• Nicolas Chevobbe [:nchevobbe] invalid cookies error message in the storage panel (Bug 1967707)

• Hubert Boma Manilla (:bomsy) fixed an issue in the Debugger when switching sources while the file search panel was open (Bug 1971094)
• Hubert Boma Manilla (:bomsy) also fixed inline previews and preview popup for expressions which aren't in a function scope (Bug 1957885)

WebDriver BiDi

• Henrik updated our in-tree Puppeteer to version 24.10.0 and upgraded Node.js to 22.16.0 across all test jobs to enable ESM support by default.
• Ben Chatterton improved the error message shown when attempting to permanently install an unpacked, unsigned web extension.
• To address unnecessary 200ms delays on each click; even when no navigation occurred; Henrik lowered the Selenium click-and-wait timeout for possible navigations to 50ms for backward compatibility. The timeout is now also configurable and can be completely disabled by users through a preference.

Lint, Docs and Workflow

• :gerard-majax added a linter to remind developers to use proper XDG handling rather than .mozilla directory references.
• Standard8 fixed the rejected-words and codespell linters to properly check .jsx files (a typo meant they were checking .jxs files).
• Standard8 also tidied up some of the top-level ESLint configuration files following the v9 upgrade.

Migration Improvements

• Opera has changed where and how they store profile data in a recent release, which has broken importing from that browser. We're hoping to get this sorted during the 142 cycle.

New Tab Page

• Thanks to the WebExtensions team, we've got line-of-sight for performing train-hopping to the release channel starting with Firefox 142. The plan is to use Nimbus / Experimenter to distribute the newtab XPI, rather than Balrog.
  • See this bug and what it blocks for more details
• We've rolled out a change that removes story descriptions, to streamline the contents on the page!

• The team has landed some support for more variations of showing "trending searches" on the newtab page, which we'll be experimenting with soon.
• Nina has been on a tear, cleaning up a bunch of Pocket-related code in the newtab codebase. Most recently, she removed a bunch of telemetry support for Pocket events.

Picture-in-Picture

• kpatenio fixed PiP play/pause not working when watching videos on the Apple events page

Profile Management

• User-facing plans for Firefox 142:
  • Improved avatar and theme customization
  • Possibly roll out to a slightly larger audience (from 0.5% to a few percent, TBD)

Search and Navigation

• James fixed an issue where search terms might persist in the address bar.
• Moritz enabled the add search engine context menu option for POST forms with role=search (previously it was disabled on all POST forms).
• Yazan fixed an issue where unit conversions may be incorrect when dealing with long numbers.

Storybook/Reusable Components/Acorn Design System

• Bug 1972885 - Add -icon-size-xsmall token
• Bug 1962151 - Implement the listbox type of moz-visual-picker
  • This version of moz-visual-picker will not automatically select the item when it is focused with the arrow keys, unlike a radio input (selection does not follow focus)
• Bug 1956853 - Ensure grouped box items have the correct role in assistive technology
  • This variant of moz-box-group treats its children as a single focus target and provides navigation with the arrow keys
• Bug 1966426 - Create a basic moz-promo element
  • A basic element for displaying promotional messages with future support for illustrations and actions. This component is still in development, expect more updates in the future.

01 Jul 2025 10:27am GMT

Wikipedia has a page of AI catchphrases, which are phrases and formatting conventions typical of AI chatbots, such as ChatGPT.

The list isn't just useful for trying to spot if some text was generated by AI. (That's a hard task that's probably a bad idea to do because you end up blaming too many innocent people. As a large language model, I cannot advise you to rely on automated AI detection services.) What's really valuable about this list is the examples of ways to improve human-written text.

• is/stands as/serves as a testament, plays a vital/significant role, underscores its importance, continues to captivate, leaves a lasting impact, watershed moment, key turning point ChatGPT puffs up the importance of the subject matter with reminders that it represents or contributes to a broader topic. Might as well replace these assertions of importance with some useful info.

• rich cultural heritage, rich history, breathtaking, must-visit, must-see, stunning natural beauty, enduring/lasting legacy, rich cultural tapestry These are all opportunities to get specific and show not tell. Use a memorable fact instead of one of these claims?

• it's important to note/remember/consider, it is worth, no discussion would be complete without These should go without saying. Otherwise, why put more wear on your one wild and precious set of carpal tunnels even typing it?

• on the other hand, moreover, in addition, furthermore More extra verbiage. It might make the AI-generated text flow better to a reviewer, but if the sentence is clear without one of these, it can go.

Related: 3 shell scripts: Kill weasel words, avoid the passive, eliminate duplicates by Matt Might.

• various, a number of, fairly, and quite Sentences that cut these words out become stronger.

• very, extremely, several, exceedingly, many, most, few, vast. Students insert lazy words in order to avoid making a quantitative characterization. They give the impression that the author has not yet conducted said characterization.

Includes a script to spot these along with example Makefile lines.

Related

50 Years of Stupid Grammar Advice by Geoffrey K. Pullum White, in particular, often wrote beautifully, and his old professor would have been proud of him. What's wrong is that the grammatical advice proffered in Elements is so misplaced and inaccurate that counterexamples often show up in the authors' own prose on the very same page.

Bonus links

Make Fun Of Them by Ed Zitron. (I have to disagree with this one. It's not that today's leading VCs and Big Tech CEOs lack intelligence, it's that there's no g for managers and investors. The current tech big shots came up at a time when transformative inventions were happening faster than the value could be captured. The problem wasn't inventing, it was getting a piece of the action for your startup or your project within a big company. So they're probably outliers on the high end of the kind of intelligence required for capturing value. A different kind of intelligence is going to be needed now that useful inventions are growing more scarce.)

Here's a Tip to Companies: Beware of Promoting AI in Products by Sean Captain. In each test, members of the group that saw the AI-related wording were less likely to say they would want to try, buy or actively seek out any of the products or services being advertised compared with people in the other group.

Why Big Tech Turned Against Democrats - and Democracy by Paul Krugman. The public might not care about the wealth of our new oligarchs if people felt that the tech lords were earning their vast fortunes by providing ever better products. But many people, myself included, feel if anything that what Big Tech offers is getting worse, not better, as companies shift their focus from creating new and useful tools to exploiting their market position. (Related: The Circularity of Meritocracy)

Audiences Prove that the Experts Are Dead Wrong by Ted Gioia. Things will get better. And that will happen even though the forces aligned against creative vocations and human flourishing appear to be huge-so much so that many have given up hope. Today I want to give an example of a reversal that is happening right now-but few have noticed. I'll explain the shift, and then I will describe in some detail why this is happening.

I Fact-Checked This Cannes-Winning Sustainability Campaign. It's Bullshit. by Polina Zabrodskaya. Love a good sustainability report. So I did what most agencies don't: I read it. It's 302 pages long, which makes finding the key numbers an insane challenge.

01 Jul 2025 12:00am GMT

I'm changing the media queries on this blog to try to get the layout to work on a variety of different size devices and windows. In order to help do that I put a little JavaScript on the page to update the width in the upper right corner. So that's what the little number is.

Also moved the site search form.

This site should still work fine without JavaScript, except for recipe mode.

Bonus links

More on Apple's Trust-Eroding 'F1 The Movie' Wallet Ad by John Gruber. Like, what if you recently bought tickets to see another summer blockbuster movie? Using Apple Wallet? And then you got this ad? It'd be completely sensible to be spooked by that, and conclude that Apple Wallet is tracking you. Sending this ad is completely destructive to all the hard work other teams at Apple have done to make Apple Wallet actually private - and, more importantly, to get users to believe that it's private. That Apple can be trusted in ways that other big tech companies cannot. (Another good example of what has become an widely held assumption: Personalizing advertising is something that untrustworthy companies do.)

China breaks more records with surge in solar and wind power by Amy Hawkins. Between January and May, China added 198 GW of solar and 46 GW of wind, enough to generate as much electricity as Indonesia or Turkey.

European Digital Sovereignty is an Industrial Project. Everyone Else Get Out of the Way. by Cristina Caffarra. And there's only one possible direction of travel: build. Everything else is a distraction. Honestly, friends, this is not primarily about defending our democracy though sure, being less dependent helps. It's not primarily about our European values though sure, privacy and freedom of speech are natural parts of our way of thinking. But I lose patience with this discourse (typically from civil society and think tanks) because what we need is single-minded focus on building, not piety and moralizing around this stuff. (The Eurostack is not a drop-in replacement for US-based Big Tech, but it doesn't have to be. It just has to get to the point where the build (in Europe) risks are less than the buy (from a country that, any minute, you could be in a trade war or a data embargo with) risks. Another point in the Eurostack's favor is that US-based incumbent vendors are steadily enshittifying and turning to crime, so by the time a Eurostack IT project finishes, the US-based alternative will be substantially worse than it was when the project began. (or maybe Google will go legit

I Fought in Ukraine and Here's Why FPV Drones Kind of Suck by Jakub Jajcay. [T]he greatest obstacle to the successful use of these drones by far is the unreliability of the radio link between the operator and the drone. One of the reasons why hitting a target at ground level with precision is difficult is that when first-person view drones get close to the ground, due to obstacles, they start to lose their radio connection to the operator, often located up to 10 kilometers away. In some cases, drones cannot attack a target if it is simply on the wrong side of a tall building or hill because the building or hill blocks the line of sight between the drone and the operator. (Related: Generative AI's crippling and widespread failure to induce robust models of the world by Gary Marcus, Ukraine's Massive Drone Attack Was Powered by Open Source Software by Matthew Gault.)

28 Jun 2025 12:00am GMT

Here at Mozilla, we are the first to admit the internet isn't perfect, but we know the internet is pretty darn magical. The internet opens up doors and opportunities, allows for human connection, and lets everyone find where they belong - their corners of the internet. We all have an internet story worth sharing. In My Corner Of The Internet, we talk with people about the online spaces they can't get enough of, the sites and forums that shaped them, and how they would design their own corner of the web.

We caught up with Florent Daudens, who led digital innovation in Canadian newsrooms before becoming press lead at Hugging Face, the open-source AI community. He talks about shaping his feeds to feel more like home, his move from journalism to AI, and why the best way to understand new tech is to start making things.

What is your favorite corner of the internet?

That rare, quiet part of the internet that actually makes you smarter without making you feel behind. For me, it's a mix.

LinkedIn surprised me. I used to think of it as stiff and self-promotional, but it's become where I exchange ideas with people wrestling with the same big questions: What's AI doing to journalism? What's worth building?

[X] is still very relevant for everything related to AI news. It's where I get pulled into weird, fascinating rabbit holes. Someone posts a half-broken agent demo or a wild paper, and suddenly I have 12 tabs open. It's chaotic in the best way.

And Hugging Face of course, to keep pace with AI releases!

I think what changed everything was narrowing my feeds. Once I stopped trying to follow everything and leaned into what really matters to me - AI, openness, news and creative industries - it all started to feel like home.

What is an internet deep dive that you can't wait to jump back into?

My YouTube recommendations read like a personality test I didn't mean to take:

• obsessive AI build logs. I'm a sucker for "How I made this with that" videos to learn new skills related to AI.
• Mandarin tutorials (six years in and still chasing tones…)
• vintage French science shows that I now rewatch with my kid - equal parts nostalgia and wonder.

What is the one tab you always regret closing?

That post. You know the one - right under the other one. You meant to open it in a new tab, but you didn't. And then the feed refreshed and it's gone forever. A digital ghost.

What can you not stop talking about on the internet right now?

AI-generated videos that are totally unhinged and strangely beautiful. Like:

• A yeti doing ASMR
• A gorilla cracking its teeth mid-skydive
• Or Total Pixel Space - the RunwayML AI film festival winner that feels like visual poetry

What was the first online community you engaged with?

CaraMail, back in France in the late '90s. It was messy, anonymous, and kind of magical. That early feeling of connecting with people across borders, in French, about anything, was completely new. It opened up so many possibilities and shaped how I saw connection and community, and actually played a role in me moving to Montréal at 18.

If you could create your own corner of the internet, what would it look like?

Actually, I'm lucky; I am building it.

That's why I moved from journalism to AI. I could feel something shifting, not just in media, but everywhere, and I wanted to help make this foundational technology open, accessible, and collaborative. As a former data journalist, I saw how open-source wasn't just about sharing code. It was a force multiplier for learning, creativity, and community. With AI, that effect is even stronger.

So yeah, without a doubt: Hugging Face.

What articles and/or videos are you waiting to read/watch right now?

The LangGraph course on DeepLearning.ai on long-term agentic memory (it's niche, I know)

And a new series on MCP, which my colleague Ben kicked off, because I genuinely think this protocol could unlock a whole new layer of what's possible on the open web.

What's the biggest opportunity you see right now at the intersection of AI, open-source and public-interest media?

Small experiments, bold new tools, but most of all, building.

With AI-assisted coding, I think the barrier to entry is lower than ever. You can go from idea to prototype really quickly, even without knowing how to code, but just by starting with your words and ideas. And that's a game-changer.

Take AI agents: the only way to really understand their potential and their limits is to try building one yourself. That forces you into the mindset that matters most: empathy. Start with what people actually need, then design around that.

Open-source supercharges all of this. It lets you remix, test, and share. It makes scaling faster. And maybe most importantly, it's the best way to stay independent from tech companies. You're not just using tools; you're shaping them.

---

Florent Daudens is the press lead at Hugging Face, the open-source AI community. A longtime advocate for the intersection of AI and journalism, he led the digital transformation of major Canadian media such as Le Devoir and Radio-Canada. He has overseen the development of AI-powered tools, helped shape ethical guidelines for AI, and trains newsrooms on its use. He also lectures on AI and journalism at Université de Montréal and ESJ Lille.

The post At Hugging Face, a former journalist helps make AI more accessible appeared first on The Mozilla Blog.

27 Jun 2025 9:47pm GMT

Something we've long known at Mozilla is that our localization community thrives on personal connections. For years, regional meetups brought volunteers and staff together multiple times a year - forging friendships, sharing knowledge, and collectively advancing the mission of a multilingual, open internet.

After a five-year pause, we're thrilled to share that in June 2025, we re-ignited that tradition with a pilot localization meetup at the Mozilla Berlin office; it was everything we hoped for, and more.

A Weekend of Community, Collaboration, and Fresh Energy

Fourteen volunteers from 11 different locales gathered for a weekend full of shared ideas, meaningful conversations, and collaborative problem-solving. For many, it was their first time meeting fellow contributors in person, people they'd worked with for years, but only ever known through usernames and chat windows. For others, it was a long-awaited reunion, finally bringing back to life connections that had existed solely online since the last wave of community meetups.

"We now feel more connected and will work together more closely," shared one participant, reflecting on the emotional impact of finally connecting face-to-face.

Throughout the weekend, we dove into topics ranging from community building to localization tooling. Some standout moments included:

• Candid discussions about what it means to lead within a localization community, the challenges of maintaining momentum, and what kind of support really makes a difference.
• David's lightning talk on the Sicilian language and community, which sparked conversations about linguistic diversity and revitalizing regional languages through digitalization.
• Collaborative Pontoon brainstorming session, where localizers took the lead in proposing enhancements, suggesting new features, and sharing pain points - and some even supporting each other with development setup and hands-on exploration.

And of course, there was time for laughter, great food, and spontaneous late-night ideas that could only come from being in the same room together.

As one localizer put it: "The event gave me fresh energy and ideas to contribute more actively to Mozilla."

Behind the Scenes

Organizing this meetup - especially after a multi-year hiatus - was a complex endeavor. Though we were eager to bring people together in the first half of the year, it took nearly nine months of planning. In the end, only two weekends aligned with enough staff availability to make the event possible.

To keep things focused and manageable for a pilot, we made a few strategic decisions:

• Location: with a local staff member on the ground and access to Mozilla's Berlin office, we could streamline logistics - from restaurant bookings and lunch deliveries to helping attendees navigate international travel with clear guidance and local support.
• Participant selection: we prioritized inviting contributors who were highly active in Pontoon, and whose travel would be cost-effective and visa-free. This helped reduce uncertainty and made the event more accessible.
• Budget-aware planning: we extended invitations to 34 community members and received interest from 27. Due to scheduling overlaps, 14 were ultimately able to attend.

Why This Matters

Events like this don't just strengthen Mozilla's localization work, they strengthen Mozilla as a whole. Contributors left Berlin feeling recognized, energized, and motivated, and organizers left with a renewed sense of purpose and clarity about how vital it is to invest in human connection.

It also gave us space to hear directly from contributors - not in surveys or chat threads, but in real time, with nuance and context. Those conversations helped surface both immediate ideas for improvement and deeper questions about what sustainable, meaningful participation looks like in today's Mozilla. It was a reminder that strong localization doesn't just come from good tools and processes, but from mutual trust, shared ownership, and space to collaborate openly.

Looking Ahead

We're now regrouping to reflect on lessons learned and to explore if it's possible to scale these meetups going forward. That means thinking carefully about aspects like:

• How do we support communities in regions where Mozilla has no local staff?
• How do we navigate unknowns, like visa requirements, more complex traveling logistics, etc.?
• How do we sustainably host more meetups per year and ensure they're just as impactful?

One thing is certain: this pilot proved once again the value of in-person community building. It re-affirmed something our community has said all along - that being together matters.

We're incredibly grateful to everyone who participated, and we're excited about the possibilities ahead. Whether you're a seasoned localizer or just getting started, we hope this story inspires you. Your contributions make Mozilla possible and we truly hope we can celebrate that together, in more places around the world.

26 Jun 2025 5:24am GMT

The Rust team is happy to announce a new version of Rust, 1.88.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.88.0 with:

$ rustup update stable

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

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

What's in 1.88.0 stable

Let chains

This feature allows &&-chaining let statements inside if and while conditions, even intermingling with boolean expressions, so there is less distinction between if/if let and while/while let. The patterns inside the let sub-expressions can be irrefutable or refutable, and bindings are usable in later parts of the chain as well as the body.

For example, this snippet combines multiple conditions which would have required nesting if let and if blocks before:

if let Channel::Stable(v) = release_info()
    && let Semver { major, minor, .. } = v
    && major == 1
    && minor == 88
{
    println!("`let_chains` was stabilized in this version");
}

Let chains are only available in the Rust 2024 edition, as this feature depends on the if let temporary scope change for more consistent drop order.

Earlier efforts tried to work with all editions, but some difficult edge cases threatened the integrity of the implementation. 2024 made it feasible, so please upgrade your crate's edition if you'd like to use this feature!

Naked functions

Rust now supports writing naked functions with no compiler-generated epilogue and prologue, allowing full control over the generated assembly for a particular function. This is a more ergonomic alternative to defining functions in a global_asm! block. A naked function is marked with the #[unsafe(naked)] attribute, and its body consists of a single naked_asm! call.

For example:

#[unsafe(naked)]
pub unsafe extern "sysv64" fn wrapping_add(a: u64, b: u64) -> u64 {
    // Equivalent to `a.wrapping_add(b)`.
    core::arch::naked_asm!(
        "lea rax, [rdi + rsi]",
        "ret"
    );
}

The handwritten assembly block defines the entire function body: unlike non-naked functions, the compiler does not add any special handling for arguments or return values. Naked functions are used in low-level settings like Rust's compiler-builtins, operating systems, and embedded applications.

Look for a more detailed post on this soon!

Boolean configuration

The cfg predicate language now supports boolean literals, true and false, acting as a configuration that is always enabled or disabled, respectively. This works in Rust conditional compilation with cfg and cfg_attr attributes and the built-in cfg! macro, and also in Cargo [target] tables in both configuration and manifests.

Previously, empty predicate lists could be used for unconditional configuration, like cfg(all()) for enabled and cfg(any()) for disabled, but this meaning is rather implicit and easy to get backwards. cfg(true) and cfg(false) offer a more direct way to say what you mean.

See RFC 3695 for more background!

Cargo automatic cache cleaning

Starting in 1.88.0, Cargo will automatically run garbage collection on the cache in its home directory!

When building, Cargo downloads and caches crates needed as dependencies. Historically, these downloaded files would never be cleaned up, leading to an unbounded amount of disk usage in Cargo's home directory. In this version, Cargo introduces a garbage collection mechanism to automatically clean up old files (e.g. .crate files). Cargo will remove files downloaded from the network if not accessed in 3 months, and files obtained from the local system if not accessed in 1 month. Note that this automatic garbage collection will not take place if running offline (using --offline or --frozen).

Cargo 1.78 and newer track the access information needed for this garbage collection. This was introduced well before the actual cleanup that's starting now, in order to reduce cache churn for those that still use prior versions. If you regularly use versions of Cargo even older than 1.78, in addition to running current versions of Cargo, and you expect to have some crates accessed exclusively by the older versions of Cargo and don't want to re-download those crates every ~3 months, you may wish to set cache.auto-clean-frequency = "never" in the Cargo configuration, as described in the docs.

For more information, see the original unstable announcement of this feature. Some parts of that design remain unstable, like the gc subcommand tracked in cargo#13060, so there's still more to look forward to!

Stabilized APIs

• Cell::update
• impl Default for *const T
• impl Default for *mut T
• mod ffi::c_str
• HashMap::extract_if
• HashSet::extract_if
• hint::select_unpredictable
• proc_macro::Span::line
• proc_macro::Span::column
• proc_macro::Span::start
• proc_macro::Span::end
• proc_macro::Span::file
• proc_macro::Span::local_file
• <[T]>::as_chunks
• <[T]>::as_rchunks
• <[T]>::as_chunks_unchecked
• <[T]>::as_chunks_mut
• <[T]>::as_rchunks_mut
• <[T]>::as_chunks_unchecked_mut

These previously stable APIs are now stable in const contexts:

• NonNull<T>::replace
• <*mut T>::replace
• std::ptr::swap_nonoverlapping
• Cell::replace
• Cell::get
• Cell::get_mut
• Cell::from_mut
• Cell::as_slice_of_cells

Other changes

The i686-pc-windows-gnu target has been demoted to Tier 2, as mentioned in an earlier post. This won't have any immediate effect for users, since both the compiler and standard library tools will still be distributed by rustup for this target. However, with less testing than it had at Tier 1, it has more chance of accumulating bugs in the future.

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

Contributors to 1.88.0

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

26 Jun 2025 12:00am GMT

I'm old enough to remember how respectable Google used to be, back during the Obama administration. Maybe someday a book will come out on how Old Google, generous cafeteria visitor policy and all, morphed into the New Google that-unfortunately-too many people have to deal with today. (Winners don't click search ads.) The tragedy of the commons is a false and dangerous myth to describe traditional commons, but it's definitely a thing within big companies. A common resource, the company's goodwill, is drawn down unsustainably by individual decision-makers looking for short-term success for their own individual projects.

Google pivoted to crime one project at a time, and as an Internet optimist sometimes I think they might be able to pivot back one project at a time. In the long run, the pivot back would be in the interest of shareholders, since there's more money in running an ad medium that supports a publisher-brand reputation feedback loop than in a dishonest medium that people learn to avoid. Here are what should be some manageable-sized projects for those at Google who want to go legit. (Happy to come in and and pitch one of these in more detail to the new board-level committee on how to be less evil.)

Generative AI training opt outs for sites, separate from search. Everyone wants this, and it's going to be required in the EU and other jurisdictions anyway. So might as well get credit for doing it voluntarily, in advance.

Fix the Google Ads Transparency Center to be less fraud-friendly. Google's Ads Transparency Center is better than what Facebook offers, which looks like it's optimized for deceptive advertising. But it still needs a bunch of work.

• Policy-violating ads should remain available for affected people and companies. For example, if an ad includes a fake celebrity endorsement, or a trademark of a legit advertiser used without permission, that person or company needs to be able to see it to take appropriate action.

• TinEye, other independent image search sites, and trademark monitoring companies should be allowed to crawl Ads Transparency Center. Some kind of firehose feed or API might help.

• Ads Transparency Center should lead, not lag, actual ad serving. Ideally an ad would not serve to regular people until a certain number of independent services had already crawled it, but the ad should at least have been available for a little while.

• All substantial ad variations should be available. Because a lot of ads are minimally reviewed or even automatically generated, it is possible for one version of the same ad to be legit and another not.

• Index all text in the ad (using OCR if needed), not just search by advertiser or website name. Scammers often keep the same ad copy when making new accounts. Also, give legit businesses a chance to help out by searching for and reporting fake competitors.

• Show, and allow searching by, intermediary companies involved in placing an ad, not just the advertiser.

• For each ad creative, link to all accounts running the same or substantially similar ads.

• Cross-link accounts that are using the same domains in landing pages.

• Provide more metadata on accounts, such as date created and type of business documents that Google relied on.

With a full-featured Ads Transparency Center, legit advertisers will be able to do more to report their fraudulent competitors, and publishers will be able to do more to report crappy deceptive ads that show up on their sites. Both have an interest in doing it, so will be free help for Google on this. Google could differentiate their ads from Meta's by improving the Ads Transparency Center to disadvantage the scam advertisers and help the legit ones.

Make a Site Transparency Center. Fixing the Ads Transparency Center will make it practical to spot more bad ads on good sites. That's a good start, so do the advertisers a favor and address the good ad/bad site problem too. If you buy an ad through Google, where's it going to run? This could be as simple as an old-school Yahoo-style directory, with RSS feeds for newly added sites by content category. And, of course, fully populate sellers.json, including owner domains. An individual who owns a site and wants to keep their legal name confidential should be able to use their web byline for sellers.json, but that personal privacy argument doesn't apply to Google's big confidential site problem, which looks like corporate owners of multiple domains. A Site Transparency Center would also help firms like Link-Busters that copyright holders use to spot infringing sites.

Lock down the trademark policy. Yes, it was clever to make brands bid up the price of search ads on each other's names, and that bit of gamesmanship probably makes Google some money, but, sorry, way too much crime here, people. Time to end the use of one advertiser's trademark by another without explicit permission. A trademark owner needs to be able to block any use of their trademarks by other advertisers, or only allow use by permission, as for distributors or dealers.

Take the anticompetitive shenanigans out of the Privacy Sandbox in-browser ad system. This stuff may not be in Google Chrome much longer, but at least fix the voluminous competition issues in the CMA reports before wrapping up. So-called privacy-enhancing technologies might be a bad fit for advertising purposes, but they're still promising for product telemetry, route planning, and energy markets.

stop dialing for dollars around ad agencies. This is a common complaint among ad agency people. As an agency, you get the client's campaigns set up the way they work best-saving money by avoiding wasteful placements-and then some minimally trained Google contractor calls the client directly to tell them you did it all wrong and they need to turn on some feature Google happens to want to push. The agency can do some work to address this problem, making sure that the client knows that Google does this and that someone from the agency is available to join a meeting to find out if it's a real issue. But Google could do the most to fix it by including the agency to start with. See Don't Be Evil - Agency Hackers.

Andon cords for ad review and support. If Toyota assembly line workers get behind in their work, they can pull the cord and stop the line. Install a similar cord for support and ad review teams, and hook it up so that anyone on the team can pause turning on new sites and ads if they're in the weeds. Better to keep the quality level as consistent as possible than to randomly impose deceptive ads on people because of moderation and support issues.

Support responsible privacy laws. Some companies are like obligate anaerobes, and won't survive in the presence of decent privacy laws. But Google is more like a facultative anaerobe-it can survive in today's high-surveillance, low-trust system but will really thrive in an oxygen atmosphere. Advocating against any privacy law, even those that will disadvantage the obligate anerobes, such as the companies that provide databases of assassination targets or North Korean drone strikes as a service, is suboptimal. Stop teaming up with less reputable surveillance companies on lobbying, quit the creepy sockpuppet orgs, and find some long-term aligned allies to work with on lobbying for better laws. The Check My Ads Institute Policy Platform could be a good place to start.

Related

how to break up Google (maybe a Google breakup is more likely than Google reform, though? See also Wall Street Tells Google to Break Itself Up by Matt Stoller)

Bonus links

New zine: The Secret Rules of the Terminal by Julia Evans. (brb, adding this zine collection to the library purchase form before the local Linux installfest. Could be useful for Mac OS and other Unix-like systems too)

Here's how I know more people read my personal blog via RSS then any other platform by Aram Zucker-Scharff. RSS feeds present a set of unique problems for measurement which is why many companies, including big ones, don't do much to try and measure them.

Trump's FTC announces merger condition that prohibits advertising boycotts by Jon Brodkin. (Another reason to use inclusion lists. Related: time to sharpen your pencils, people)

Games run faster on SteamOS than Windows 11, Ars testing finds by Kyle Orland. (Getting off US tech is no easy task but it's getting easier as Microsoft declines from its early-2000s peak. Some good news: Microsoft surprises MS-DOS fans with remake of ancient text editor that works on Linux by Benj Edwards.)

26 Jun 2025 12:00am GMT

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

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

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Announcing the Clippy feature freeze

Newsletters

• Rust Trends Issue #67

Project/Tooling Updates

• Tantivy 0.24
• How to write Rust in the kernel: part 1
• GlueSQL v0.17.0 - Added redb storage support

Observations/Thoughts

• The Unreasonable Effectiveness of Fuzzing for Porting Programs
• So you want to serialize some DER?
• Why I Switched from Flutter + Rust to Rust + egui
• Weird expressions in rust
• Migrating off legacy Tokio at scale
• Driving the Rust Compiler to Compile Single Files as Shellcode
• Counter Service: How we rewrote it in Rust
• Defending Democracies With Rust
• Rust: A language that grows with you, your career and your projects
• [video playlist] Scientific Computing in Rust 2025

Rust Walkthroughs

• Porting GPU shaders to Rust 30x faster with AI
• Bitwise DNA Compression in Rust: Small Footprint with Fast Reverse Complements
• Writing a basic Linux device driver when you know nothing about Linux drivers or USB
• Rewriting Kafka in Rust Async: Insights and Lessons Learned in Rust
• The Complete Rust Security Handbook

Crate of the Week

This week's crate is primitive_fixed_point_decimal, a crate of real fixed-point decimal types.

Thanks to Wu Bingzheng for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

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

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

RFCs

Rust

Rustup

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

Call for Participation; projects and speakers

CFP - Projects

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

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

• Continuwuity - Default room ACLs
• Continuwuity - Ability to entirely disable typing and read receipts
• Continuwuity - bug: appservice users are not created on registration
• Continuwuity - Invite filtering / disable invites per account

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 X (formerly Twitter) or Mastodon!

CFP - Events

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

No Calls for papers or presentations were submitted this week.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

Updates from the Rust Project

448 pull requests were merged in the last week

Compiler

• perf: Cache the canonical instantiation of param-envs
• asyncDrop trait without sync Drop generates an error
• stabilize generic_arg_infer
• skip no-op drop glue

Library

• add trim_prefix and trim_suffix methods for both slice and str types
• allow comparisons between CStr, CString, and Cow<CStr>
• allow storing format_args!() in variable
• impl Default for array::IntoIter
• change core::iter::Fuse's Default impl to do what its docs say it does
• let String pass #[track_caller] to its Vec calls
• safer implementation of RepeatN
• use a distinct ToString implementation for u128 and i128

Cargo

• cargo: feat(toml): Parse support for multiple build scripts
• cargo: feat: introduce perma unstable --compile-time-deps option for cargo build
• cargo: fix potential deadlock in CacheState::lock

Rustdoc

• avoid a few more allocations in write_shared.rs
• rustdoc-json: keep empty generic args if parenthesized
• rustdoc: make srcIndex no longer a global variable

Clippy

• use jemalloc for Clippy
• perf: Don't spawn so many compilers (3/2) (19m → 250k)
• Sugg: do not parenthesize a double unary operator
• or_fun_call: lint more methods
• add missing space when expanding a struct-like variant
• check MSRV before suggesting applying const to a function
• emit lint about redundant closure on the closure node itself
• fix branches_sharing_code suggests misleadingly when in assignment
• fix clippy::question_mark on let-else with cfg
• fix exhaustive_structs false positive on structs with default valued field
• fix manual_ok_err suggests wrongly with references
• fix non_copy_const ICE
• fix wildcard_enum_match_arm suggests wrongly with raw identifiers
• fix false positive of borrow_deref_ref
• fix suggestion-causes-error of empty_line_after_outer_attr
• new lint: manual_is_multiple_of

Rust-Analyzer

• rust-analyzer: add fn parent(self, db) → GenericDef to hir::TypeParam
• rust-analyzer: cleanup folding_ranges and support more things
• rust-analyzer: do not default to 'static for trait object lifetimes
• rust-analyzer: closure capturing for let exprs
• rust-analyzer: fix cargo project manifest not pointing to the workspace root
• rust-analyzer: in "Wrap return type" assist, don't wrap exit points if they already have the right type
• rust-analyzer: respect .cargo/config.toml build.target-dir
• rust-analyzer: temporarily disable + typing handler as it moves the cursor position
• rust-analyzer: use ROOT hygiene for args inside new format_args! expansion
• rust-analyzer: hide imported privates if private editable is disabled
• rust-analyzer: mimic rustc's new format_args! expansion

Rust Compiler Performance Triage

A week dominated by the landing of a large patch implementing RFC#3729 which unfortunately introduced rather sizeable performance regressions (avg of ~1% instruction count on 111 primary benchmarks). This was deemed worth it so that the patch could land and performance could be won back in follow up PRs.

Triage done by @rylev. Revision range: 45acf54e..42245d34

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	1.1%	[0.2%, 9.1%]	123
Regressions ❌ (secondary)	1.0%	[0.1%, 4.6%]	86
Improvements ✅ (primary)	-3.8%	[-7.3%, -0.3%]	2
Improvements ✅ (secondary)	-2.3%	[-18.5%, -0.2%]	44
All ❌✅ (primary)	1.0%	[-7.3%, 9.1%]	125

2 Regressions, 4 Improvements, 10 Mixed; 7 of them in rollups 40 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

• Use lld by default on x86_64-unknown-linux-gnu stable
• Allow #[must_use] on associated types to warn on unused values in generic contexts
• Fix proc_macro::Ident 's handling of $crate
• Ensure non-empty buffers for large vectored I/O

Rust RFCs

• RFC: --crate-attr

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

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

New and Updated RFCs

• No New or Updated RFCs were created this week.

Upcoming Events

Rusty Events between 2025-06-25 - 2025-07-23 🦀

Virtual

• 2025-06-25 | Virtual (Lima, PE)| Perú Rust User Group
  • Interfaces y Costos en la nube con Rust
• 2025-06-26 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2025-06-26 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2025-06-29 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-07-02 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2025-07-03 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2025-07-03 | Virtual (Rotterdam, NL) | Bevy Game Development
  • Bevy Meetup #11
• 2025-07-05 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2025-07-06 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-07-08 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2025-07-13 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-07-15 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2025-07-15 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2025-07-16 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2025-07-17 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2025-07-20 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Rust Atomics and Locks
• 2025-07-22 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2025-07-22 | Virtual (London, GB) | Women in Rust
  • Lunch & Learn: Crates, Tips & Tricks Lightning Talks - Bring your ideas!

Asia

• 2025-06-28 | Bangalore/Bengaluru, IN | Rust Bangalore
  • June 2025 Rustacean meetup
• 2025-07-02 | Seoul, KR | Seoul Rust (Programming Language) Meetup
  • Seoul Rust Meetup

Europe

• 2025-06-25 | London, UK | London Rust Project Group
  • Lessons learnt from making a tiny game in nostd Rust
• 2025-06-25 | Paris, FR | Systematic Paris Region
  • Rust Paris Conference 2025
• 2025-06-26 | Barcelona, ES | BcnRust
  • 18th BcnRust Meetup
• 2025-06-26 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #58
• 2025-06-26 | Paris, FR | Rust Paris
  • Rust meetup #77
• 2025-06-30 | Zagreb, HR | impl Zagreb for Rust
  • Meetup 2025/06: Drink-up zatvaranje sezone
• 2025-07-01 | Gdansk, PL | Rust Gdansk
  • Rust Gdansk Meetup #9
• 2025-07-01 | Paris, FR | Stockly
  • Rust Meetup in Paris - hosted by Stockly
• 2025-07-02 | Basel, CH | Rust Basel
  • Rust Meetup #12 @ kHaus
• 2025-07-02 | Frankfurt, DE | Rust Rhein-Main
  • The (un)holy Trinity of Flutter, Rust and C
• 2025-07-02 | London, UK | Oxford Rust Meetup Group
  • Oxford Rust and ACCU special - Vibe coding workshop
• 2025-07-02 | Posnan, PL | Rust Poland
  • Rust Poland Meetup x Poznan
• 2025-07-05 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #13
• 2025-07-08 | London, UK | London Rust Project Group
  • Garbage Collection for Rust: the Finalizer Frontier
• 2025-07-09 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 07 2025
• 2025-07-09 | Reading, UK | Reading Rust Workshop
  • Reading Rust Meetup
• 2025-07-15 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Topic TBD
• 2025-07-15 | London, UK | London Rust Project Group
  • TUI Power: Simulating & Visualising Sensor Data with Rust

North America

• 2025-06-25 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2025-06-26 | Chicago, IL, US | Chicago Rust Meetup
  • Rust Happy Hour
• 2025-06-26 | Los Angeles, CA, US | Rust Los Angeles
  • Rust in Web3 Developer Group
• 2025-06-26 | Los Angeles (Chino Hills), CA, US | Vara Network
  • Rust in Web3
• 2025-06-26 | México City, MX | Rust MX
  • Elixir y Rust
• 2025-06-26 | Spokane, WA, US | Spokane Rust
  • Monthly Meetup: Making a CRUD API with Rust!
• 2025-06-28 | Boston, MA, US | Boston Rust Meetup
  • Back Bay Rust Lunch, June 28
• 2025-07-03 | Montréal, QC, CA | Rust Montréal
  • July Monthly Social
• 2025-07-03 | Saint Louis, MO, US | STL Rust
  • Building Resilient and Observable Rust Services with steady_state
• 2025-07-06 | Boston, MA, US | Boston Rust Meetup
  • Alewife Rust Lunch, July 6
• 2025-07-09 | Phoenix, AZ, US | Desert Rust
  • Rust <> AI
• 2025-07-15 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2025-07-17 | Nashville, TN, US | Music City Rust Developers
  • Rust on Bare Metal Series 1 : Introduction to Embedded Development
• 2025-07-17 | Redmond, WA, US | Seattle Rust User Group
  • July, 2025 Computer Programming Language Panel (Special Event)
• 2025-07-23 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground

Oceania

• 2025-06-30 | Collingwood, VI, AU | Rust Melbourne
  • June 2025 Mini Rust Melbourne Meetup
• 2025-07-01 | Christchurch, NZ | Christchurch Rust Meetup Group
  • July 2025 Christchurch Rust Meetup

South America

• 2025-07-12 | São Paulo, BR | Rust São Paulo Meetup
  • Encontro do Rust-SP na WillBank

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

Jobs

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

Quote of the Week

Our experience is that no matter how many safeguards you put on code, there's no cure-all that prevents bad programming. Of course, to take the contrary argument, seat belts don't stop all traffic fatalities, but you could just choose not to have accidents. So we do have seat belts. If Rust can prevent some mistakes or malicious intent, maybe it's worth it even if it isn't perfect.

- Al Williams on hackaday

Thanks to Kill The Mule for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, U007D, joelmarcey, mariannegoldin, bennyvasquez, bdillo

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

25 Jun 2025 4:00am GMT

Firefox WebDriver Newsletter 140

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 140 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 140, several contributors managed to land fixes and improvements in our codebase:

• Martin Pitt fixed a bug which could prevent action commands to resolve, and also helped with some related refactoring.
• Liam (ldebeasi) improved two browsingContext events: contextCreated and contextDestroyed.

WebDriver code is written in JavaScript, Python, and Rust so any web developer can contribute! Read how to setup 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!

General

Bug fixes:

• Fixed a bug where WebDriver Classic and BiDi commands - particularly Action commands - could time out while waiting for a RequestAnimationFrame.
• Improved the Actions implementation in both Marionette and WebDriver BiDi to prevent microtasks from being blocked while individual events are dispatched. For more information about microtasks, head over to the MDN guide for microtasks.

WebDriver BiDi

New: browsingContext.navigationCommitted event

Implemented a new browsingContext event, browsingContext.navigationCommitted, which should be emitted as soon as a new document has been created for a navigation.

New: acceptInsecureCerts parameter for browser.createUserContext

Added support for the acceptInsecureCerts argument to the browser.createUserContext command. This argument allows clients to disable or enable certificate related security settings for a specific user context (aka Firefox container) and override the settings specified for a session.

Updated: NoSuchWebExtensionError for webExtension.uninstall

Updated the webExtension.uninstall command to throw a NoSuchWebExtensionError when an empty string is provided as the extension ID.

Updated: clientWindow property for browsingContext events

Updated browsingContext.contextCreated and browsingContext.contextDestroyed events to return the clientWindow property in all the remaining cases (including Firefox for Android). This property corresponds to the ID of the window owning the Browsing Context.

Bug fixes:

Fixed a bug for various browsingContext events which were unexpectedly emitted for webextension Browsing Contexts.

24 Jun 2025 4:03pm GMT

We've updated Add-on policies for addons.mozilla.org (AMO). Here's a summary of the changes and their impact on AMO's publishing process. Our main objective was to simplify and clarify Add-on policies for the developer community. The following policy updates will take effect on 4 August, 2025.

"Closed group" prohibition lifted

Closed group extensions are typically intended for internal or private use among a relatively small group of users. In the past AMO did not allow closed group extensions, but we're lifting this prohibition to give developers more flexibility to publish restricted access extensions for any number of reasons.

Data consent and control terminology

We've updated terminology in an effort to clarify our policies related to user data consent and control.

A core aspect of our data policy is we only permit extensions to transmit data that's necessary for functionality (and even so users must consent to data transmission). Prior policy language often intermingled the terms collection and transmission of data. This was often confusing for developers who naturally assumed these were two separate aspects of handling data. But in fact we are only concerned with the transmission of data outside of an extension or browser. Thus we've removed all references to the collection of user data and framed all data concerns around transmission.

Privacy policy not required to be hosted on AMO

In effort to reduce developer overhead and publishing friction, we are no longer requiring extensions to host privacy policies on AMO. Rather, we encourage developers to link to self-hosted privacy policies. Removing this requirement will allow developers to more easily update their privacy policies without necessitating the submission of an entirely new extension version on AMO.

Data collection transparency is of paramount importance to Firefox users. We're also working on other changes that will make it easier for developers to select the types of data their extension requires, which will in turn provide enhanced data collection clarity for users.

User scripts API policy added

A user script manager is a type of extension that allows users to inject custom, website-specific scripts that alter a site's appearance or behavior. These extensions leverage the userScripts API, which our policies now clarify may only be used by user script manager extensions. The userScript API may not be used to extend or modify the functionality of the script manager itself.

Source code submission guidelines

It has been a longtime AMO policy that all extension submissions must provide reviewable source code, regardless if it's transpiled, minified, or otherwise machine generated. We've now amended our policy to more specifically stipulate that all dependencies must either be included in the source code package directly or downloaded only through the respective official package managers during the build process.

Taken together, we hope these policy refinements will make developing Firefox extensions a more straightforward and streamlined process. Let us hear your thoughts in the comments. Happy coding!

The post Updated Add-on policies - simplified, clarified appeared first on Mozilla Add-ons Community Blog.

23 Jun 2025 11:13pm GMT

Firefox is expanding its AI-powered features, all designed to keep your data private. We believe technology should serve you, not monitor you. Our team understands the importance of privacy, especially as AI rapidly integrates into our daily lives.

Firefox protects your privacy by running AI models directly on your device, ensuring your sensitive data remains local. We aim to integrate AI in ways that genuinely enhance your daily browsing while preserving what matters most: choice, privacy and trust.

Supercharge your productivity with no privacy trade-offs

Our AI-powered tools are built to enhance your experience while keeping your data secure:

Automatic alt text generation describes images, enhancing accessibility without compromising privacy.

Translation capabilities allow seamless browsing, translating pages instantly without sending content off-device.

AI-enhanced tab groups automatically suggest intuitive names based on page titles and recommend related tabs - all computed privately on your device.

Link preview, our latest experimental feature, generates key points from articles, providing a quick snippet without external processing.

Firefox brings choice and transparency to you

Unlike browsers that impose proprietary solutions, Firefox allows you to select your preferred AI chatbot provider directly in the sidebar. You're free to explore and switch between AI chatbots at any time. You can also remove downloaded AI models anytime from the on-device model management screen. Whether you're seeking quick assistance, deep research, or daily productivity, Firefox ensures you remain in control.

Our ongoing commitment to privacy-preserving AI drives us to continuously develop and enhance features that respect and protect your personal information. At Firefox, AI is about creating a smarter, more intuitive browsing experience that boosts productivity without sacrificing privacy.

We're excited about the future and remain dedicated to investing in AI solutions that position Firefox as your trusted digital companion.

The post Your data, your rules: Firefox's privacy-first AI features you can trust appeared first on The Mozilla Blog.

23 Jun 2025 4:03pm GMT

Thunderbird for iOS

We're growing a few more stars! We're so happy to hear there is great interest in Thunderbird for iOS, and hope to reach a stage soon where you all can be more involved. Thank you, also, to those of you who've submitted an increasing number of ideas via Mozilla Connect.

Todd has been preparing the JMAP implementation for iOS, which will allow us to test the app with real data. We're exploring the possibility of releasing the first community TestFlight a bit earlier by working directly with in-memory live data instead of syncing everything to a database upfront. The app may crash if your inbox has 30GB of email, but this approach should help us iterate more quickly. We still believe offline-first is the right path, and designing a database that supports this will follow soon after.

Further we've set up the initial localization infrastructure. This was surprisingly easy using Weblate's translation propagation feature. We simply needed to add a new component to our Android localization project that pulls from the iOS repository. While Weblate doesn't (yet?) auto-propagate when the component is set up, if there are changes across iOS and Android in the future, the strings will automatically apply to both products.

Thunderbird for Android

We spent a lot of time thinking about the beta and making adjustments. Fast forward to June, we're still experiencing a number of crashes. If you are running the beta, please report crashes and try to find out how to trigger them. If you are not using Beta, please give it a try and report back on the beta list or issue tracker. We'd greatly appreciate it! Here are a few updates worth noting for the month of May:

• Some folks on beta may have noticed the "recipient field contains incomplete input" error which kept you from sending emails. We've noticed as well, and halted the rollout of 11.0b1 on app stores where supported. Shamim fixed this issue for 11.0b2.
• Another important issue was when attaching multiple issues, only one image would be attached. This happens all the way back to 10.0, and we'll release a 10.1 that includes this fix. Again thank you to Shamim!
• Final round of fixes from Shamim: new mail notifications can be disabled again, we have a bunch of new tests and refactoring, we have a few new UI types for the new preference system that Wolf created.
• Timur Erofeev solved a crash on Android 7 due to some library changes in dependency updates we didn't anticipate
• Wolf is getting closer to finishing the drawer updates that we're excited to share in a beta soon. He has also been working diligently to remove some of the crashes we've been experiencing on beta due to the new drawer and some of the legacy code it needs to fall back to. Finally, as we're venturing into Thunderbird for iOS, Wolf has been thinking about the KMP (Kotlin Multiplatform) approach and added support to the Thunderbird for Android repository. He will soon separate a simple component and set things up so we can re-use it from Thunderbird for iOS.
• Rafael and Marcos have fixed some issues with the system bar appearing transparent. The issue has been very persistent, we're still getting reports of cases where this isn't yet resolved.
• Philipp has fixed an issue for our release automation to make sure the changelog doesn't break on HTML entities.

I also wanted to highlight the new Git Commit Guide that Wolf created to give us a little more stability in our commits and set expectations for pull requests. We have a few more docs coming up in June, stay tuned.

You could be on this list next month, please get in touch if you'd like to help out!

-
Philipp Kewisch (he/him)
Thunderbird Mobile Engineering | Mozilla Thunderbird

The post Thunderbird Mobile Progress Report: May 2025 appeared first on The Thunderbird Blog.

20 Jun 2025 2:47pm GMT

The Rust project is currently working towards a slate of 40 project goals, with 3 of them designated as Flagship Goals. This post provides selected updates on our progress towards these goals (or, in some cases, lack thereof). The full details for any particular goal are available in its associated tracking issue on the rust-project-goals repository.

Flagship goals

Why this goal? This work continues our drive to improve support for async programming in Rust. In 2024H2 we stabilized async closures; explored the generator design space; and began work on the dynosaur crate, an experimental proc-macro to provide dynamic dispatch for async functions in traits. In 2025H1 our plan is to deliver (1) improved support for async-fn-in-traits, completely subsuming the functionality of the async-trait crate; (2) progress towards sync and async generators, simplifying the creation of iterators and async data streams; (3) and improve the ergonomics of Pin, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.

What has happened?

Generators. Experimental support for an iter! macro has landed in nightly. This is intended for nightly-only experimentation and will still need an RFC before it can stabilize. Tracking issue is rust-lang/rust#142269.

Async book. @nrc has been hard at work filling out the official Async Rust book, recently adding chapters on concurrency primitives, structured concurrency, and pinning.

dynosaur. A dynosaur RFC was opened describing what blanket impls we think the proc macro should generate for a trait, to make the trait usable as impl Trait in argument position in other traits. This is the last remaining open design question before we release dynosaur 0.3 as a candidate for 1.0. Please chime in on the RFC if you have thoughts.

1 detailed update available.

Comment by @tmandry posted on 2025-06-09:

Generators. Experimental support for an iter! macro has landed in nightly. This is intended for nightly-only experimentation and will still need an RFC before it can stabilize. Tracking issue is rust-lang/rust#142269.

Async book. @nrc has been hard at work filling out the official Async Rust book, recently adding chapters on concurrency primitives, structured concurrency, and pinning.

dynosaur. A dynosaur RFC was opened describing what blanket impls we think the proc macro should generate for a trait, to make the trait usable as impl Trait in argument position in other traits. This is the last remaining open design question before we release dynosaur 0.3 as a candidate for 1.0. Please chime in on the RFC if you have thoughts.

Why this goal? May 15, 2025 marks the 10-year anniversary of Rust's 1.0 release; it also marks 10 years since the creation of the Rust subteams. At the time there were 6 Rust teams with 24 people in total. There are now 57 teams with 166 people. In-person All Hands meetings are an effective way to help these maintainers get to know one another with high-bandwidth discussions. This year, the Rust project will be coming together for RustWeek 2025, a joint event organized with RustNL. Participating project teams will use the time to share knowledge, make plans, or just get to know one another better. One particular goal for the All Hands is reviewing a draft of the Rust Vision Doc, a document that aims to take stock of where Rust is and lay out high-level goals for the next few years.

What has happened?

The All-Hands did!

More than 150 project members and invited guests attended, making this the largest in-person collaborative event in the history of the Rust project.

We celebrated the 10 year birthday of Rust 1.0. With over 300 people, we celebrated, listened to speeches from various former and current team members and contributors, and watched the live release of Rust 1.87.0 on stage.

The feedback from the participants was overwhelmingly positive with an average score of 9.5/10. 🎉 The vast majority would like this to be a yearly event -- which Mara started working on.

1 detailed update available.

Comment by @m-ou-se posted on 2025-06-19:

Update!

The all-hands has happened!

More than 150 project members and invited guests attended, making this the largest in-person collaborative event in the history of the Rust project.

On Wednesday, several Rust project members gave talks to other project members and (potential) contributors, as part of the "Rust Project Track" at the RustWeek conference. The recordings are available on YouTube. 📹

On Thursday, we celebrated the 10 year birthday of Rust 1.0. With over 300 people, we celebrated, listened to speeches from various former and current team members and contributors, and watched the live release of Rust 1.87.0 on stage.

On Friday and Saturday, the actual Rust All-Hands 2025 took place. For two full days spread over 10 different meeting rooms, both pre-planned and ad-hoc discussions took place on a very wide range of topics. Meeting notes have been collected in this Zulip topic: #all-hands-2025 > Meeting notes!

Many many long standing issues have been unblocked. Many new ideas were discussed, both small and big. Conflicts were resolved. Plans were made. And many personal connections were formed and improved. ❤

I've collected feedback from the participants (67 of you replied so far), and the replies where overwhelmingly positive with an average score of 9.5/10. 🎉 The vast majority would like this to be a yearly event. I've started working on making that happen!

Thank you all for attending! See you all next year! 🎊

Why this goal? This goal continues our work from 2024H2 in supporting the experimental support for Rust development in the Linux kernel. Whereas in 2024H2 we were focused on stabilizing required language features, our focus in 2025H1 is stabilizing compiler flags and tooling options. We will (1) implement RFC #3716 which lays out a design for ABI-modifying flags; (2) take the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options; (3) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).

What has happened? May saw significant progress on compiler flags, with MCPs for -Zharden-sls and -Zretpoline* being accepted. Several PRs were in progress (#135927, #140733, #140740) that could potentially be combined, with the implementation approach matching clang's flag naming conventions for consistency. The RFC for configuring no-std externally #3791 entered T-compiler FCP with positive signals, and build-std discussions at the All Hands produced some consensus between libs and compiler teams, though more Cargo team involvement was needed.

The Rust for Linux team had strong participation at Rust Week, with many team members attending (Alice, Benno, Björn, Boqun, Gary, Miguel, Trevor). During the All Hands, attendees participated in a fun exercise predicting what percentage of the kernel will be written in Rust by 2035 - currently only about 0.1% of the kernel's 40M total lines are in Rust.

On language features, during May we continued work on arbitrary self types v2, where Ding focused on resolving the dichotomy between Deref::Target vs Receiver::Target. One potential approach discussed was splitting the feature gate to allow arbitrary self types only for types implementing Deref, which would cover the kernel use case. For derive(CoercePointee), we continued waiting on PRs #136764 and #136776, with the latter needing diagnostic work.

The All Hands meeting also produced interesting developments on field projections, with Benno working on an approach that reuses borrow checker logic to extend what we do for & and &mut to custom types using the -> syntax. Alice also presented a new proposal for AFIDT/RPITIDT and placement (discussed here).

2 detailed updates available.

Comment by @ojeda posted on 2025-05-20:

Update from our 2025-05-07 meeting (full minutes):

• Enthusiasm and plans for RustWeek.

• arbitrary_self_types: update from @dingxiangfei2009 at https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/2025-05-07.20meeting/near/516734641 -- he plans to talk to types in order to find a solution. @davidtwco will ping @petrochenkov about rustc_resolve.

• Sanitizer support and #[sanitize(off)]: discussed by lang at https://github.com/rust-lang/rust/pull/123617#issuecomment-2859621119. Discussion about allowing to disable particular sanitizers. Older concern from compiler at https://github.com/rust-lang/rust/pull/123617#issuecomment-2192330122.

• asm_const with pointers support: lang talked about it -- lang will want an RFC: https://github.com/rust-lang/rust/issues/128464#issuecomment-2861515372.

• ABI-modifying compiler flags: two MCPs filled: https://github.com/rust-lang/compiler-team/issues/868 (-Zretpoline and -Zretpoline-external-thunk) and https://github.com/rust-lang/compiler-team/issues/869 (-Zharden-sls).

  Implementation PR for -Zindirect-branch-cs-prefix at https://github.com/rust-lang/rust/pull/140740 that goes on top of https://github.com/rust-lang/rust/pull/135927.

  @davidtwco agreed there is likely no need for a separate MCP for this last one, i.e. it could go into the -Zretpoline* one. @azhogin pinged about this at https://github.com/rust-lang/rust/pull/135927#issuecomment-2859906060.

• --crate-attr: @Mark-Simulacrum was pinged and he is OK to adopt the RFC (https://github.com/rust-lang/rfcs/pull/3791).

Comment by @nikomatsakis posted on 2025-05-20:

TL;DR:

The primary focus for this year is compiled flags, and we are continuing to push on the various compiler flags and things that are needed to support building RFL on stable (e.g., RFC #3791 proposed adding --crate-attr, which permits injecting attributes into crates externally to allow the Kernel's build process to add things like #![no_std] so they don't have to be inserted manually into every file; MCPs for ABI flags like retpoline and harden-sls and implementation of -Zindirect-branch-cs-prefix). A number of issues had minor design questions (how to manage clippy configuration; best approach for rustdoc tests) and we plan to use the RustWeek time to hash those out.

We are also finishing up some of the work on language items. We have had two stabilizations of lang features needed by Rust for Linux (naked functions, asm_goto syntax). The trickiest bit here is arbitrary self types, where we encountered a concern relating to pin and are still discussing the best resolution.

Goals looking for help

The main bottleneck is the customization of the dependent rustc-rayon library. @oli-obk and @Zoxc are helping to move this forward.

Help wanted: Help test the deadlock code in the issue list and try to reproduce the issues. If you'd like to help, please post in this goal's dedicated zulip topic.

Help wanted: T-compiler people to work on the blocking issues #119428 and #71043. If you'd like to help, please post in this goal's dedicated zulip topic.

Help wanted: @ZuseZ4: there is only really one issue left which I'd like to see fixed before enabling autodiff on nightly, and that is MacOS support.

Most of the MacOS CI already works, we can now build Enzyme, LLVM, and rustc, but later fail when we build Cranelift due to linker flag issues. The person who was looking into it got busy with other things, so I would really appreciate it if someone could pick it up! Otherwise I can also just start by shipping autodiff on Linux only, but given how close we are to MacOS support, I feel like it would be a shame.

Since it's only an issue in CI, you don't need an own Mac to help with this. If anyone has time, I'm happy to chat here here or on Zulip/Discord.

3 detailed updates available.

Comment by @ZuseZ4 posted on 2025-05-25:

And another round of updates. First of all, Google approved two GSoC projects for the summer, where @Sa4dUs will work on the autodiff frontend and @KMJ-007 will work on the backend. The frontend project is about improving our ABI handling to remove corner-cases around specific types that we currently can not differentiate. If time permits he might also get to re-model our frontend to lower our autodiff macro to a proper rustc intrinsic, which should allow us to simplify our logic a lot. The backend project will look at how Enzyme uses TypeTrees, and create those during the lowering to LLVM-IR. This should allow autodiff to become more reliable, work on debug builds, and generally compile a lot faster.

Comment by @ZuseZ4 posted on 2025-05-25:

The last weeks were focused on enabling autodiff in a lot more locations, as well as doing a lot of CI and Cmake work to be able to ship it on nightly. At the same time, autodiff is also gaining increasingly more contributors. That should help a lot with the uptick in issues, which I expect once we enable autodiff in nightly builds.

Key developments:

1. @Shourya742 added support for applying autodiff inside of inherent impl blocks. https://github.com/rust-lang/rust/pull/140104
2. @haenoe added support for applying autodiff to generic functions. https://github.com/rust-lang/rust/pull/140049
3. @Shourya742 added an optimization to inline the generated function, removing one layer of indirection. That should improve performance when differentiating tiny functions. https://github.com/rust-lang/rust/pull/139308
4. @haenoe added support for applying autodiff to inner (nested) functions. https://github.com/rust-lang/rust/pull/138314
5. I have found a bugfix for building rustc with both debug and autodiff enabled. This previously failed during bootstrap. This bugfix also solved the last remaining (compile time) performance regression of the autodiff feature. That means that if we now enable autodiff on nightly, it won't affect compile times for people not using it. https://github.com/rust-lang/rust/pull/140030
6. After a hint from Onur I also fixed autodiff check builds:https://github.com/rust-lang/rust/pull/140000, which makes contributing to autodiff easier.
7. I ran countless experiments on improving and fixing Enzyme's CMake and merged a few PRs into Enzyme. We don't fully support the macos dist runners yet and some of my CMake improvements only live in our Enzyme fork and aren't accepted by upstream yet, but the CI is now able to run longer before failing with the next bug, which should hopefully be easy to fix. At least I already received a hint on how to solve it.
8. @Shourya742 also helped with an experiment on how to bundle Enzyme with the Rust compiler. We ended up selecting a different distribution path, but the PR was helpful to discuss solutions with Infra contributors. https://github.com/rust-lang/rust/pull/140244
9. @Sa4dUs implemented a PR to split our #[autodiff] macro into autodiff_forward and autodiff_reverse. They behave quite differently in some ways that might surprise users, so I decided it's best for now to have them separated, which also will make teaching and documenting easier. https://github.com/rust-lang/rust/pull/140697

Help Wanted: There are two or three smaller issues remaining to distribute Enzyme/autodiff. If anyone is open to help, either with bootstrap, CI, or CMake issues, I'd appreciate any support. Please feel free to ping me on Discord, Zulip, or in https://github.com/rust-lang/rust/pull/140064 to discuss what's left to do.

In general, we solved most of the distribution issues over the last weeks, and autodiff can now be applied to almost all functions. That's a pretty good base, so I will now start to look again more into the GPU support for rustc.

Comment by @ZuseZ4 posted on 2025-06-15:

The last three weeks I had success in shifting away from autodiff, towards my other projects.

Key developments:

1. I forgot to mention it in a previous update, but I have added support for sret (struct return) handling to std::autodiff, so we now can differentiate a lot more functions reliably. https://github.com/rust-lang/rust/pull/139465

2. I added more support for batched autodiff in: https://github.com/rust-lang/rust/pull/139351

3. I have started working on a std::batching PR, which just allows fusing multiple function calls into one. https://github.com/rust-lang/rust/pull/141637. I am still not fully sure on how to design the frontend, but in general it will allow Array-of-Struct and Struct-of-Array vectorization. Based on a popular feedback I received it's now also generating SIMD types. So you can write your function in a scalar way, and just use the macro to generate a vectorized version which accepts and generates SIMD types.

4. My first PR to handle automatic data movement to and from a GPU is up! https://github.com/rust-lang/rust/pull/142097 It can handle data movements for almost arbitrary functions, as long as your function is named kernel_{num}, and each of your arguments is a pointer to exactly 256 f32 values. As the next step, I will probably work on the backend to generate the actual kernel launches, so people can run their Rust code on the GPU. Once I have that tested and working I will go back to develop a frontend, to remove the input type limitations and give users a way to manually schedule data transfers. The gpu/offload frontend will likely be very simple compared to my autodiff frontend, so I don't expect many complications and therefore leave it to the end.

Help Wanted:

There is only really one issue left which I'd like to see fixed before enabling autodiff on nightly, and that is MacOS support. Most of the MacOS CI already works, we can now build Enzyme, LLVM, and rustc, but later fail when we build Cranelift due to linker flag issues. The person who was looking into it got busy with other things, so I would really appreciate it if someone could pick it up! Otherwise I can also just start by shipping autodiff on Linux only, but given how close we are to MacOS support, I feel like it would be a shame. Since it's only an issue in CI, you don't need an own Mac to help with this. If anyeone has time, I'm happy to chat here here or on Zulip/Discord.

Help wanted: 1c3t3a: happy to join forces on general checks and for advice what other UB would be great to check!! :).

1 detailed update available.

Comment by @1c3t3a posted on 2025-05-22:

Upps, giving another status update here:

Key developments: Landed an extension of the alignment check to include (mutable) borrows in rust#137940. Working on the enums check (no draft PR yet). Hope to open a PR by mid next week.

Blockers: None so far.

Help wanted: Happy to join forces on general checks and for advice what other UB would be great to check!! :)

Help wanted: Help is appreciated in anything with the performance-project label in the Clippy repository.

1 detailed update available.

Comment by @blyxyas posted on 2025-05-25:

Monthly update!

Key developments:

• Documentation lints have been optimized greatly, giving us up to a 13.5% decrease in documentation-heavy crates. See https://github.com/rust-lang/rust-clippy/pull/14693 and https://github.com/rust-lang/rust-clippy/pull/14870

• The efforts on getting Clippy benchmarked on the official @rust-timer bot account are getting started by the infra team. This allows us to do per-PR benchmarking instead of fixing performance problems ad-hoc.

• We need to do further testing on the early parallel lints effort. While I have a working patch, no performance improvement has yet been proven.

• Work on making an interface for a single-lint Clippy, for denoising benchmarks is getting in the works.

Blockers The query system not being parallelized. Currently working on a work-around but a parallel query system would make things a lot easier.

Help wanted: Help is appreciated in anything with the performance-project label in the Clippy repository.

Other goal updates

1 detailed update available.

Comment by @BoxyUwU posted on 2025-05-23:

We should now be correctly deferring evaluation of type system constants making use of generic parameters or inference variables. There's also been some work to make our normalization infrastructure more term agnostic (i.e. work on both types and consts). Camelid's PR mentioned in the previous update has also made great progress.

Comment by @wesleywiser posted on 2025-06-19:

• @adamgemmell and @davidtwco hosted a session on build-std at the All Hands with members from various teams discussing some of the design questions.
• We've continued our biweekly sync call with lang, compiler and cargo team members.
• @davidtwco and @adamgemmell have been hard at work preparing a compendium detailing the history of build-std and the wg-cargo-std-aware repo.
  • Reviewing and editing this document is ongoing and a continuing topic of discussion for the sync call.
• In the last sync call, we discussed:
  • Renewing the project goal for another cycle: enthusiastic agreement from many participants.
  • Posting updates to the project goal page biweekly after each sync call.
  • Discussion on the content and format of the compendium. Most of the content appears to be done but further editing and restructuring will make it clearer and more easily digestible.

1 detailed update available.

No detailed updates available.

No detailed updates available.

1 detailed update available.

Comment by @tmandry posted on 2025-05-22:

Last week was the Rust All Hands. There were three days of discussions about interop at the all hands, led by @baumanj and including members from the Rust Project and C++ standards bodies as well as the developers of foundational Rust/C++ interop tools. The topics included

• Comparing differing needs of interop across the industry
• Sharing the design philosophy and approach of different interop tools
• Brainstorming how to tackle common interop problems between the languages, like differences in integer types, memory/object models, and move semantics
• Discussing ways the Rust and C++ languages and toolchains can develop to make interop easier in the future

Speaking for myself from the Rust Project side, it was a real pleasure to meet some of the faces from the C++ side! I look forward to working with them more in the future.

No detailed updates available.

1 detailed update available.

Comment by @Eh2406 posted on 2025-05-27:

The talk went smoothly and was well received. I had several useful and interesting conversations at Rust Week about effort. That is all I have to report.

No detailed updates available.

1 detailed update available.

Comment by @epage posted on 2025-05-21:

• Key developments:
  • Moved crates to https://github.com/crate-ci/libtest2
• Blockers
• Help wanted

1 detailed update available.

Comment by @b-naber posted on 2025-06-10:

We have reached an agreement on the compiler implementation, and will implement it in the next 2-3 weeks hopefully.

1 detailed update available.

Comment by @jhpratt posted on 2025-05-30:

https://github.com/rust-lang/rust/pull/141754 has been opened to parse impl restrictions and lower them to rustc_middle. A separate pull request will be opened to enforce the restriction soon after that is merged.

No detailed updates available.

No detailed updates available.

No detailed updates available.

2 detailed updates available.

Comment by @yaahc posted on 2025-05-26:

Quick update, Data is currently being gathered (and has been for almost 2 weeks now) on docs.rs and I should have it uploaded and accessible on the PoC dashboard within the next week or two (depending on how long I want to let the data gather).

Comment by @yaahc posted on 2025-06-03:

Bigger Update,

I've done the initial integration with the data gathered so far since rustweek. I have the data uploaded to the influxdb cloud instance managed by the infra team, I connected the infra team's grafana instance to said influxdb server and I imported my dashboards so we now have fancy graphs with real data on infra managed servers :tada:

I'm now working with the infra team to see how we can open up access of the graphana dashboard so that anyone can go and poke around and look at the data.

Another issue that came up is that the influxdb cloud serverless free instance that we're currently using has a mandatory max 30 day retention policy, so either I have to figure out a way to get that disabled on our instance or our data will get steadily deleted and will only be useful as a PoC demo dashboard for a short window of time.

No detailed updates available.

2 detailed updates available.

Comment by @lcnr posted on 2025-05-29:

We have triaged all major regressions discovered by the full crater run. While there are still some untriaged root regressions impacting a single crate, we've either fixed all major regressions or opened fixes to the affected crates in cases where the breakage is intended. We've started to track intended breakage in https://github.com/rust-lang/trait-system-refactor-initiative/issues/211.

We've fixed quite a few additional issues encountered via crater: https://github.com/rust-lang/rust/pull/140672 https://github.com/rust-lang/rust/pull/140678 https://github.com/rust-lang/rust/pull/140707 https://github.com/rust-lang/rust/pull/140711 https://github.com/rust-lang/rust/pull/140712 https://github.com/rust-lang/rust/pull/140713 https://github.com/rust-lang/rust/pull/141125 https://github.com/rust-lang/rust/pull/141332 https://github.com/rust-lang/rust/pull/141333 https://github.com/rust-lang/rust/pull/141334 https://github.com/rust-lang/rust/pull/141347 https://github.com/rust-lang/rust/pull/141359.

We are now tracking performance of some benchmarks with the new solver in our test suite and have started to optimize the new solver. Thank you @Kobzol for this! There are a lot of long-hanging fruit so we've made some large improvements already: https://github.com/rust-lang/rust/pull/141442 https://github.com/rust-lang/rust/pull/141500. There are also a bunch of additional improvements in-flight right now, e.g. https://github.com/rust-lang/rust/pull/141451. We still have a few crates which are significantly slower with the new solver, most notably nalgebra and diesel. I am confident we'll get the new solver a lot more competitive here over the next few months.

Going forward, we will continue to improve the performance of the new solver. We will also finally work through our backlog of in-process changes and land the new opaque type handling.

Comment by @lcnr posted on 2025-05-29:

Ah, also @jackh726 continued to work on integrating the new solver in RustAnalyzer and it looks like we will be able to replace chalk in the near future.

1 detailed update available.

Comment by @veluca93 posted on 2025-05-25:

Key developments: https://github.com/rust-lang/rust/issues/139368 was opened, which poses some possibly-relevant questions on the interaction between the target_feature attribute and traits. Otherwise, still trying to get a better understanding of the interaction between target feature and effects.

1 detailed update available.

Comment by @oli-obk posted on 2025-05-21:

No updates on my side, but we may be going back to the original proposal (modulo syntax) with a syntax that is extensible to more opt-out marker effects without lots of repetition of the const keyword

1 detailed update available.

Comment by @epage posted on 2025-05-27:

This has been approved as a GSoC project.

1 detailed update available.

Comment by @JoelMarcey posted on 2025-06-01:

Key Developments: A PR is ready for review and merging to update the FLS to be self-sufficient, not relying on external Ferrocene packages for building. This will give us more control of changes we would like to make to the document, including theming, logos, naming, etc.

Next step: Make some modifications to the FLS content and have it published at https://rust-lang.github.io/fls

Blockers: Potential blocker around the (re)naming / rebranding of the FLS.

No detailed updates available.

No detailed updates available.

No detailed updates available.

No detailed updates available.

2 detailed updates available.

Comment by @davidtwco posted on 2025-06-02:

• @Jamesbarford has added the ability to write tests against the database to rustc-perf (rust-lang/rustc-perf#2119)
• @Jamesbarford has started to submit parts of rust-lang/rustc-perf#2081 in smaller chunks, with review feedback addressed, starting with rust-lang/rustc-perf#2134 (originally rust-lang/rustc-perf#2096)
• @Jamesbarford has prepared a HackMD describing the design considerations involved in making rustc-perf support multiple collectors.

Comment by @Jamesbarford posted on 2025-06-20:

• @Kobzol & @Jamesbarford collaborated on finishing a workable draft for the new architecture of the rustc-perf benchmarking; https://hackmd.io/wq30YNEIQMSFLWWcWDSI9A
• @Kobzol PR enabling backfilling of data, required for the new system design https://github.com/rust-lang/rustc-perf/pull/2161
• @Jamesbarford PR for creating a cron job and doing a first stage queue of master commits; https://github.com/rust-lang/rustc-perf/pull/2163
• @Jamesbarford PR for the collectors configuration, holding off merging for the time being as we learn more about the system through building. https://github.com/rust-lang/rustc-perf/pull/2157
• @Kobzol PR allowing running the database tests on SQLite too; https://github.com/rust-lang/rustc-perf/pull/2152

1 detailed update available.

Comment by @lqd posted on 2025-05-27:

Here are the key developments for May, though there was a bit less time this month due to the All Hands.

@amandasystems: A few more rounds of reviews were done on https://github.com/rust-lang/rust/pull/140466 (thanks to lcnr!), and most, if not all, of the feedback has been addressed already. Another PR was opened as a successor, containing another big chunk of work from the initial PR #130227: https://github.com/rust-lang/rust/pull/140737.

@tage64: The work discussed in the previous updates has been extracted into a few PRs, mostly to do perf runs to be able to gauge the overhead in the in-progress implementation. First, an alternative implementation to rustc's dense bitset, which is used extensively in dataflow analyses such as the ones in the borrow checker, for example. Then, a prototype of the algorithm discussed in prior updates, trying to make the location-sensitive constraints built lazily, as well as the loans in scope themselves. (And the union of these two in #141583)

@lqd: As discussed in the previous update, I've tried to see if we can limit scope here by evaluating the current algorithm a bit more: the expressiveness it allows, and where it fails. I've also evaluated all the open issues about NLL expressiveness that we hoped to fix, and see the ones we support now or could defer to future improvements. It seems possible. I've also started to have some idea of the work needed to make it more production-ready. That includes the experiments made with Tage above, but also trying to lower the total overhead by finding wins in NLLs, and here I e.g. have some improvements in-flight for the dataflow analysis used in liveness.

All Hands: we discussed with t-types the plan and in-progress PRs about opaque types, how they impact member constraints and in turn the constraint graph and SCCs. Some more work is needed here to ensure member constraints are correctly handled, even though they should only impact the SCCs and not the borrow checking algorithm per se (but there still are possible ambiguity issues if we don't take flow sensitivity into account here).

(Fun and interesting aside: there's an RFC to add a polonius-like lifetime analysis to clang)

No detailed updates available.

1 detailed update available.

Comment by @epage posted on 2025-05-21:

Key developments:

• rust-lang/rust#140035 has been merged

Blockers:

Help wanted:

1 detailed update available.

Comment by @davidtwco posted on 2025-05-07:

• We've resolved a handful of rounds of feedback on rust-lang/rust#137944 from @oli-obk, @lcnr and @fee1-dead; resolved issues from a crater run (bar one); and worked to decrease the performance regression.
  • We've removed the constness parts of the patch to make it smaller and easier to review. Constness will come in a Part II.
  • There's currently a -1% mean regression (min 0.1%, max 5.3%) that we're working to improve, but starting to run out of ideas. Regressions are just a consequence of the compiler having to prove more things with the addition of MetaSized bounds, rather than hot spots in newly introduced code.
  • Given the large impact of the change, we ran a crater run and found three distinct issues, two have been fixed. The remaining issue is a overflow in a single niche crate which we're working out how we can resolve.
  • We're largely just waiting on hearing from our reviewers what would be needed to see this change land.
• We've not made any changes to the Sized Hierarchy RFC, there's a small amount of discussion which will be responded to once the implementation has landed.
• We're working on changes to the SVE RFC which further clarifies that the language changes are decided by the Sized RFC and that the SVE RFC is only proposing the forever-unstable repr(scalable) attribute which are non-const Sized and lower to vscale in LLVM.

Comment by @davidtwco posted on 2025-06-02:

• rust-lang/rust#137944 is ready! It's in a t-types FCP to merge as there's a small unavoidable breakage (unless we wanted to wait for the new trait solver).
  • Once this is merged, I'll work on a #[rustc_no_implicit_bounds] attribute for tests, testing whether Deref::Target can be relaxed, and Part II.
• I've still not made any changes to the Sized Hierarchy RFC, there's a small amount of discussion which will be responded to once the implementation has landed.

1 detailed update available.

Comment by @jswrenn posted on 2025-05-22:

Key developments: No significant developments since previous updates.

Blockers: Waiting on lang team review.

No detailed updates available.

20 Jun 2025 12:00am GMT

Highlights

• Henrik removed all the code related to our experimental CDP (Chrome DevTools Protocol) implementation for browser automation. We also published a fxdx.dev blog post to explain what this means for clients and end users.
• The unit converter has now been enabled by default in the address bar, starting in Firefox 141!
  • e.g. 100 cm to inches, 1m to cm, 30 kg to lbs, 38 celsius in f

• • Units include: angle, force, length, mass, temperature, timezone
  • For other examples, see our automated tests here
• We're rolling out a change to the release channel this week or next which will remove the descriptive text for stories, to reduce clutter and visual noise. This is part of an ongoing effort to refine the look and feel of New Tab

Friends of the Firefox team

Resolved bugs (excluding employees)

Volunteers that fixed more than one bug

• Gregory Pappas [:gregp]
• Jonas Jenwald [:Snuffleupagus]

New contributors (🌟 = first patch)

• Anthony Mclamb: Bug 1967827 - Add moz-input-color link to customElements.js
• Brian Ouyang: Bug 1841773 - The link displayed after extension migration appears gray instead of blue as in Figma
• 🌟Chris Vander Linden: Bug 1888847 - DevTools Storage inspector cookie table rendering issue/misalignment with tall characters
• 🌟 gaastorgano: Bug 1911190 - Write a site-specific wrapper for kick.com that interprets a video duration of 0x40000000 as +Infinity

Project Updates

DevTools

• Chris Vander Linden fixed the Storage inspector table when it contains tall characters (#1888847)
• Roke Julian Lockhart changed the extension of exported logs from .txt to .log (#1969599)
• Masatoshi Kimura [:emk] fixed an issue in Netmonitor where responses containing multibyte characters would fail to be decoded (#1968766)
• Julien Wajsberg [:julienw] made about:debugging more enjoyable by automatically selecting the runtime page after the connection is done (#1968049)
• Holger Benl [:hbenl] fixed a few issues in the Responsive Design Mode toolbar (#1964126, #1968675, #1968677, #1968898)
• Alexandre Poirot [:ochameau] made "late" breakpoint (i.e. in unload event listener) to work for iframes (#1892411)
• Nicolas Chevobbe [:nchevobbe] fixed an issue where closing RDM would override the "Disable cache" setting in Netmonitor, even though the toolbox was still open (#1672473)
• Nicolas Chevobbe [:nchevobbe] fixed a couple Netmonitor crashes, when a JSON response was null (#1968257), and using the (re)send request panel (#1970248)
• Hubert Boma Manilla (:bomsy) improved performance by throttle some events in the parent process events on the server side (#1959452) (we were already doing it for content process events)
• Hubert Boma Manilla (:bomsy) fixed an issue in the webconsole "pinned-to-bottom" feature where the output could exit this state even though the user didn't scrolled up (#1966005)

WebDriver BiDi

• Thanks to :anutrix who removed the usage of six in testing/marionette/ directory.
• Julian updated the "browsingContext.navigate" and "browsingContext.reload" commands to wait for the `browsingContext.navigationCommitted` event when using the "wait" condition "none".
• Julian also implemented a new event "browsingContext.historyUpdated" which is emitted when using history.pushState/replaceState or document.open.
• Sasha added support for the "proxy" argument of the "browser.createUserContext" command. This allows clients to setup either a "direct" or "manual" proxy when creating a user context (ie Firefox Container). Support for additional proxy types will be added later on.

Lint, Docs and Workflow

• Hanna enabled Prettier for our CSS files 🎉
• We've now upgraded to ESLint v9.6.0. More version bumps coming soon.
• Kagami added a file name matching option to ESLint for service workers to set the globals correctly when the filename is *.serviceworker.(m)js
• :gerard-majax enabled the rejected words linter on Rust code.

Migration Improvements

• tgiles fixed a stylistic glitch for support links shown when importing extensions from Chrome-based browsers

New Tab Page

• We are planning on performing our first train-hop from Nightly 141 to Beta 140 next week. This train-hop will update Beta 140's New Tab to use the code from Nightly 141. This will not ride the trains, so Release 140 will still use the Release 140 New Tab.
  • RelMan / QA is aware and will be testing both modes.
  • This is mainly a test to ensure that New Tab can be updated this way.
  • mconley also added some taskcluster jobs (currently Tier 3) that run Nightly New Tab's XPI and automated tests against Beta (and eventually Release)
    • Example
• We've also in the early stages of an experiment for showing trending searches on New Tab
  • This is one variant we're in the early stages of developing:

• This is another variant that's in its early stages:

Picture-in-Picture

• Thanks to gaastorgano, a volunteer contributor who provided a patch to make it so that kick.com live-streaming videos don't show outrageous video durations when opened in Picture-in-Picture

Search and Navigation

• Address Bar
  • The search mode indication is now limited in width to avoid issues with search engines with long names.
  • The search button in the address bar now has support for selection via mouse up.
• Places
  • We transitioned browser/components/places to use the new moz-src: protocol.

Storybook/Reusable Components/Acorn Design System

• New component: moz-breadcrumb-group that displays a horizontal navigation trail - storybook link.

• moz-select got an icon support (in-page button only, not the dropdown) - storybook link.

• Clear button on search input enabled for chrome documents
  • Emilio is burning down search-textbox uses and replacing them with moz-input-search Bug 1968916
• moz-button size small is now 24px high

18 Jun 2025 7:35pm GMT

Category: 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.

Updates from Rust Community

Official

• Rust compiler performance survey 2025
• June 2025 Leadership Council Update | Inside Rust Blog

Foundation

• Announcing the RustConf 2025 Speaker Lineup

Newsletters

• This Month in Rust OSDev: May 2025

Project/Tooling Updates

• rust-analyzer changelog #290
• Linebender in May 2025
• bzip2 crate switches from C to 100% rust
• Hypershell: A Type-Level DSL for Shell-Scripting in Rust
• Slint 1.12 Released with WGPU Support, iOS Port, and Figma Variables Integration
• Glues v0.7.0 - TUI Note-Taking App with a New Theme Engine & Color Palettes

Observations/Thoughts

• retrobootstrapping rust for some reason
• The plight of the misunderstood memory ordering
• Don't you dare to sort your struct fields when using ?Sized
• [audio] Tembo with Adam Hendel
• [audio] Rust at Work - conversation with Eli Shalom and Igal Tabachnik of Eureka Labs
• [video] sans-io: meh
• [video] Guillaume Gomez - Rustdoc as a case study of developer tooling
• [video] 10th Bevy Meetup - Tristan - From zero to demo: a newcomer's experience learning Bevy

Rust Walkthroughs

• Putting seat calculations in Dutch election software to the (fuzz) test
• Datalog in Rust
• [video] Driving an LED matrix using async embedded Rust - moxi Ep2

Research

• Asterinas: A Linux ABI-Compatible, Rust-Based Framekernel OS with a Small and Sound TCB

Miscellaneous

• Making GNOME's GdkPixbuf Image Loading Safer
• May 2025 Jobs Report
• Rust social status update 2025.06
• How Rolldown Works: Symbol Linking, CJS/ESM Resolution, and Export Analysis Explained

Crate of the Week

This week's crate is RobustMQ, a next-generation, high-performance, multi-protocol message queue.

Thanks to Yu Liu for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

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

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

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

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

Call for Participation; projects and speakers

CFP - Projects

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

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

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

CFP - Events

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

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

Updates from the Rust Project

461 pull requests were merged in the last week

Compiler

• cache param_env canonicalization
• early linting: avoid redundant calls to check_id
• move fast reject into inner
• use MixedBitSet for borrows-in-scope dataflow analysis
• miri: add flag to suppress float non-determinism
• miri: we can use apfloat's mul_add now

Library

• stabilize "file_lock" feature
• stabilize keylocker
• add Vec::peek_mut
• added Clone implementation for ChunkBy
• faster fmt::Display of 128-bit integers, without unsafe pointer
• add bit_width for unsigned integer types
• remove unneeded lifetime bound from signature of BTreeSet::extract_if

Cargo

• add custom completer for cargo remove <TAB>
• highlight the correct words
• refactor: replace InternedString with Cow in IndexPackage

Rustdoc

• Give more information into extracted doctest information
• rustdoc_json: reduce allocations

Rustfmt

• don't try to repair invalid self-imports

Clippy

• Optimize 3rd heaviest func, (81b → 10m)
• add lint for broken doc links
• docs: add link to span_lint in diagnostics.rs
• docs: make unbuffered_bytes docs more consistent
• fix FP of identity_op when encountering Default::default()
• fix collapsible_else_if FP on conditionally compiled stmt
• fix needless_doctest_main panic when doctest is invalid
• fix unit_arg suggests wrongly for Default::default
• fix suggestion-causes-error of manual_swap
• fixes manual_flatten removes the useless if let
• remove ClippyCtfe pass
• remove unneeded lifetime

#### Rust-Analyzer

• ItemTree's ItemVisibilities has no identity, so deduplicate
• add support for excluding imports from symbol search
• cleanup incremental tests and verify query executions
• add the quickfix for increasing visibility of a private field to the private-field diagnostic
• in "Fill match arms", allow users to prefer Self to the enum name when possible
• insert required parentheses when typing + in dyn trait type
• show what cargo metadata is doing in status
• copy lockfiles into target directory before invoking cargo metadata
• do not force descend into derives for goto IDE features
• fix comparison of proc macros
• fix completion with some attribute macros
• fix proc macro server handling of strings with minuses
• hide dyn inlay hints for incomplete impls
• never make type mismatch diagnostic stable, even when there is a fix
• reload workspaces when cargo configs change
• support spans with proc macro servers from before the ast id changes
• generate annotations for macro defined items if their name is in the input
• idiomatic salsa use for enum variants query
• improve completions in if / while expression conditions
• optimize pub(crate) and pub(self) visibility resolution
• perf: bring back EMPTY item tree deduplication
• provide better incrementality when items are changed
• simplify and optimize ItemTree
• turn BlockId into a #[salsa::tracked]
• use ThinVec in ItemScope in a couple places

Rust Compiler Performance Triage

Relatively quiet week, with a few improvements to benchmarks leveraging the new trait solver.

Triage done by @kobzol. Revision range: c31cccb7..45acf54e

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.5%]	14
Regressions ❌ (secondary)	0.3%	[0.1%, 0.5%]	52
Improvements ✅ (primary)	-0.5%	[-4.8%, -0.1%]	68
Improvements ✅ (secondary)	-4.3%	[-56.5%, -0.1%]	85
All ❌✅ (primary)	-0.4%	[-4.8%, 0.5%]	82

3 Regressions, 7 Improvements, 4 Mixed; 4 of them in rollups 51 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

• Set MSG_NOSIGNAL for UnixStream
• Reject unsupported extern "{abi}"s consistently in all positions

Cargo

• Add http.proxy-cainfo config for proxy certs

Rust RFCs

• Declarative macro_rules! derive macros
• Declarative macro_rules! attribute macros

No Items entered Final Comment Period this week for Language Reference, Language Team or Unsafe Code Guidelines.

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

New and Updated RFCs

• [new] RFC: #[export_visibility = ...] attribute.

Upcoming Events

Rusty Events between 2025-06-18 - 2025-07-16 🦀

Virtual

• 2025-06-18 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Rust Panics and FFI Boundaries
• 2025-06-19 | Hybrid (Redmond, WA, US) | Seattle Rust User Group
  • June, 2025 SRUG (Seattle Rust User Group) Meetup
• 2025-06-19 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2025-06-19 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2025-06-22 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-06-24 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2025-06-24 | Virtual (London, UK) | Women in Rust
  • Building Efficient Web Scrapers: Rust vs. Python for Data Ingestion
• 2025-06-25 | Virtual (Lima, PE)| Perú Rust User Group
  • Interfaces y Costos en la nube con Rust
• 2025-06-26 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2025-06-26 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2025-06-29 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-07-02 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2025-07-03 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2025-07-03 | Virtual (Rotterdam, NL) | Bevy Game Development
  • Bevy Meetup #11
• 2025-07-05 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2025-07-06 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-07-08 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2025-07-13 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Readers Discord Discussion: Async Rust
• 2025-07-15 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2025-07-15 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2025-07-16 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out

Asia

• 2025-06-28 | Bangalore/Bengaluru, IN | Rust Bangalore
  • June 2025 Rustacean meetup
• 2025-07-02 | Seoul, KR | Seoul Rust (Programming Language) Meetup
  • Seoul Rust Meetup

Europe

• 2025-06-18 | Stockholm, SE | Stockholm Rust
  • Rust Meetup @Magello
• 2025-06-19 | Aarhus, DK | Rust Aarhus
  • Rust Aarhus meetup at Trifork
• 2025-06-19 | Edinburgh, UK | Rust and Friends
  • Rust and Friends (evening pub)
• 2025-06-20 | Edinburgh, UK | Rust and Friends
  • Rust and Friends (daytime coffee)
• 2025-06-23 | London, UK | Rust London User Group
  • Rust London: Rust Hack & Learn June 2025
• 2025-06-24 | Manchester, UK | Rust Manchester
  • Rust Manchester June Code Night
• 2025-06-25 | London, UK | London Rust Project Group
  • Lessons learnt from making a tiny game in nostd Rust
• 2025-06-25 | Paris, FR | Systematic Paris Region
  • Rust Paris Conference 2025
• 2025-06-26 | Barcelona, ES | BcnRust
  • 18th BcnRust Meetup
• 2025-06-26 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #58
• 2025-06-26 | Paris, FR | Rust Paris
  • Rust meetup #77
• 2025-06-30 | Zagreb, HR | impl Zagreb for Rust
  • Meetup 2025/06: Drink-up zatvaranje sezone
• 2025-07-01 | Gdansk, PL | Rust Gdansk
  • Rust Gdansk Meetup #9
• 2025-07-02 | Basel, CH | Rust Basel
  • Rust Meetup #12 @ kHaus
• 2025-07-02 | London, UK | Oxford Rust Meetup Group
  • Oxford Rust and ACCU special - Vibe coding workshop
• 2025-07-02 | Posnan, PL | Rust Poland
  • Rust Poland Meetup x Poznan
• 2025-07-05 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #13
• 2025-07-08 | London, UK | London Rust Project Group
  • Garbage Collection for Rust: the Finalizer Frontier
• 2025-07-09 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 07 2025
• 2025-07-09 | Reading, UK | Reading Rust Workshop
  • Reading Rust Meetup
• 2025-07-15 | London, UK | London Rust Project Group
  • TUI Power: Simulating & Visualising Sensor Data with Rust

North America

• 2025-06-18 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Rust Study/Hack/Hang-out
• 2025-06-19 | Hybrid (Redmond, WA, US) | Seattle Rust User Group
  • June, 2025 SRUG (Seattle Rust User Group) Meetup
• 2025-06-19 | México City, MX | Rust MX
  • programación asíncrona en Rust usando Tokio
• 2025-06-19 | Nashville, TN, US | Music City Rust Developers
  • Using Rust For Web Series 3 : Final Presentations and Community Social
• 2025-06-19 | Redmond, WA, US | Seattle Rust User Group
  • June, 2025 SRUG (Seattle Rust User Group) Meetup
• 2025-06-20 | Boston, MA, US | Boston Rust Meetup
  • Lechmere Rust Lunch, June 20
• 2025-06-25 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2025-06-26 | Los Angeles, CA, US | Rust Los Angeles
  • Rust in Web3 Developer Group
• 2025-06-26 | Los Angeles (Chino Hills), CA, US | Vara Network
  • Rust in Web3
• 2025-06-26 | Spokane, WA, US | Spokane Rust
  • Monthly Meetup: Making a CRUD API with Rust!
• 2025-06-28 | Boston, MA, US | Boston Rust Meetup
  • Back Bay Rust Lunch, June 28
• 2025-07-03 | Montréal, QC, CA | Rust Montréal
  • July Monthly Social
• 2025-07-03 | Saint Louis, MO, US | STL Rust
  • Building Resilient and Observable Rust Services with steady_state
• 2025-07-06 | Boston, MA, US | Boston Rust Meetup
  • Alewife Rust Lunch, July 6
• 2025-07-09 | Phoenix, AZ, US | Desert Rust
  • Rust <> AI
• 2025-07-15 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person

Oceania

• 2025-06-24 | Barton, AC, AU | Canberra Rust User Group
  • June Meetup
• 2025-06-30 | Collingwood, VI, AU | Rust Melbourne
  • June 2025 Mini Rust Melbourne Meetup

South America

• 2025-07-12 | São Paulo, BR | Rust São Paulo Meetup
  • Encontro do Rust-SP na WillBank

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

Jobs

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

Quote of the Week

But after a few weeks, it compiled and the results surprised us. The code was 10x faster than our carefully tuned Kotlin implementation - despite no attempt to make it faster. To put this in perspective, we had spent years incrementally improving the Kotlin version from 2,000 to 3,000 transactions per second (TPS). The Rust version, written by Java developers who were new to the language, clocked 30,000 TPS.

This was one of those moments that fundamentally shifts your thinking. Suddenly, the couple of weeks spent learning Rust no longer looked like a big deal, when compared with how long it'd have taken us to get the same results on the JVM. We stopped asking, "Should we be using Rust?" and started asking "Where else could Rust help us solve our problems?"

- Dr. Werner Vogels on his blog

Thanks to Brian Kung for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, U007D, joelmarcey, mariannegoldin, bennyvasquez, bdillo

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

18 Jun 2025 4:00am GMT

Two big pieces of news for images in Servo this month:

1. We now display animated GIFs in all their animated glory (@rayguo17, #36286)! This work required careful architecting to integrate with existing animation mechanisms in the engine without incurring unnecessary CPU usage.

2. We support loading SVG images in <img src> (@mukilan, @mrobinson, #36721).

Outreachy

We're excited to host two Outreachy interns over the next few months! Jerens Lensun (@jerensl) will be working on improving Servo's CI setup and other Python-focused infrastructure, while Usman Baba Yahaya (@uthmaniv) will implement support for the Network Monitor in our devtools.

They will both be blogging about their internships, and you can follow their work on Jeren's blog and Usman's blog.

Web content

Servo's layout implementation has historically been all-or-nothing - any change in the page, no matter how isolated, requires laying out the entire page from scratch. Fixing this limitation is known as incremental layout, and it's a key performance optimization in all browser engines. This month we've landed a number of changes in this area that make some kinds of CSS changes much more efficient than a full layout (@mrobinson, @Loirooriol, #36896, #36978, #37004, #37047, #37069, #37048, #37088, #37099).

We have also made significant progress on the Trusted Types API, going from 47% of tests passing to 58% over the course of May (@TimvdLippe, #36710, #36668, #36811, #36824, #36941, #36960). Supporting this work on Trusted Types, our Content Security Policy implementation has been steadily improving, now passing 59% of automated tests (@TimvdLippe, @jdm, @simonwuelker, #36709, #36710, #36776, #36832, #36860, #36887, #36923, #36963, #36962, #36961, #36965, #37020).

We've enabled support for URLPattern (@simonwuelker, #36826, #37004, #37116), <input type=color> (@simonwuelker, #36992), plus several other web API features:

• TransformStream (@Taym95, @gterzian, #36739, #36905)
• setHTMLUnsafe() method on ShadowRoot (@TG199, #36240)
• scrollingElement property on Document (@JimmyDdotEXE, #35994)
• pipeThrough() method on ReadableStream (@Taym95, #36977)
• readText() method on navigator.clipboard (@Gae24, #36689)
• type property on Stylesheet (@simonwuelker, #37126)

Our layout and CSS support continues to improve. This month, we improved our page background sizing and style computation (@mrobinson, @Loirooriol, #36917, #37147), and added support for 'wavy' and 'double' in the 'text-decoration-line' property (@mrobinson, #37079).

HTMLVideoElement can now be used as an image source for 2D canvas APIs (@tharkum, #37135), ImageBitmap can be serialized and transferred via postMessage() (@tharkum, #37101), media elements redraw properly whenever their size changes (@tharkum, #37056), polygon image map areas are clickable (@arihant2math, #37064), <select> elements are redrawn when their contents change (@simonwuelker, #36958), and getPreferredCanvasFormat() on GPU returns platform-appropriate values (@arihant2math, #37073).

We've fixed bugs relating to invertible and non-invertible transforms (@Loirooriol, #36749, #37147), missing underlines on macOS (@mrobinson, #37029), and sizing issues for tables and flex containers (@stevennovaryo, @Loirooriol, #36703, #36993, #36980, #37024, #37011). We've also fixed a number of bugs where Servo's behaviour did not match relevant specifications:

• input events are now fired following keydown events (@yezhizhen, #37078)
• unscopable objects are now writable and readable, and don't have a prototype (@simonwuelker, #37119, #37122)
• Request headers reject more erroneous headers (@sebsebmc, #36943)
• External stylesheets in documents with quirks mode are more lenient about the stylesheet's Content-Type (@ghostd, @mrobinson, #28321)
• the ImageData constructor throws better errors for unsupported arguments (@Taym95, #31398)
• Attribute nodes are serialized as the empty string (@simonwuelker, #36875)
• custom element is values are serialized as attributes (@simonwuelker, #36888)
• EventSource ignores invalid field values and treats non-200 responses codes as failures (@KiChjang, #36853, #36854)
• the premultipliedAlpha flag for WebGL canvases premultiplies correctly (@tharkum, #36895)

Our WebDriver server implementation received a lot of attention this month! Element clicks now receive the expected button value (@longvatrong111, #36871), wheel actions are supported (@PotatoCP, #36744, #36985), and we removed the possibility of races between some input actions and other WebDriver commands (@longvatrong111, @mrobinson, #36932). We've also added support for passing WebDriver references to DOM objects as arguments when executing scripts (@jdm, #36673), and fixed some bugs with JS value serialization (@yezhizhen, #36908) and cancelling inputs (@yezhizhen, #37010).

We've begun preparatory work to integrate Vello as the backend for 2D canvases (@sagudev, #36783, #36790, #36999). We've also landed some changes towards supporting '::placeholder' pseudo-elements and fixing rendering issues with text inputs (@stevennovaryo, #37065).

Embedding

The engine

Embedders can now evaluate JavaScript inside a webview and receive results asynchronously (@Narfinger, @mrobinson, #35720).

All embedders will receive default styling and interactivity for elements like inputs and media elements (@webbeef, #36803), reducing the amount of configuration required to embed the engine.

Any provided system light/dark theme will be propagated to all documents loaded inside of a webview (@mrobinson, #37132).

Servo's developer tools integration now highlights elements in the layout inspector (@simonwuelker, #35822), and displays <!DOCTYPE> nodes correctly (@simonwuelker, #36787).

We have removed the dom_shadowdom_enabled preference, since the feature has been enabled by default since March 2025 (@simonwuelker, #37043).

Our automated benchmarking setup is expanding, and we can now measure how long it takes to start up Servo and load the servo.org homepage on HarmonyOS (@Narfinger, #36878), which will help us identify regressions in the future.

Finally, we can now write unit tests for Servo's embedding API (@mrobinson, #36791), which allows us to write better regression tests for shutdown-related issues (@mrobinson, #36808).

servoshell

The --user-agent (-u) flag now correctly sets the User-Agent header for network requests (@PartiallyUntyped, @mrobinson, #36859).

Service workers have been removed from the list of features enabled by --enable-experimental-web-platform-features until they provide more value (@jdm, #36867).

Building servoshell with --with-asan now causes all C++ dependencies to be built with Address Sanitizer as well, and mach bootstrap on Windows can now use winget as a fallback if choco is unavailable (@jschwe, #32836).

The current system light/dark theme is now queried on startup (@Legend-Master, #37128). Additionally, the screen dimensions and geometry reported by the engine are now correct on OpenHarmony (@PartiallyUntyped, @jschwe, #36915).

Performance

Servo is now better at evicting image data from GPU caches (@webbeef, #36956). We also reduced the memory needed to store HSTS data, saving more than 60mb by doing so (@sebsebmc, #37000, #37015).

We now measure the memory usage of sessionStorage and localStorage data (@jdm, #37053), the Public Suffix List (@sebsebmc, #37049), and system fonts (@jdm, #36834).

In addition, we've reduced the size of the final Servo binary by 2 MB by stripping out DOM code that should never be used outside of automated tests (@jdm, #37034).

Stability

We fixed a number of crashes involving animated images (@simonwuelker, #37058), media elements with an unknown duration (@tharkum, servo-media#437), canvas elements during shutdown (@mrobinson, #37182), adding a Path2D to itself (@Taym95, #36847), calculating IntersectionObserver areas (@webbeef, #36955), the childNodes() method on Node (@jdm, #36889), resizing OffscreenCanvas (@simonwuelker, #36855), querying WebGL extensions (@mrobinson, #36911), and slicing a sliced Blob (@simonwuelker, #36866).

We've also fixed a deadlock involving streams with very large chunks (@wusyong, #36914), and fixed a source of intermittent crashes when closing tabs or removing iframes (@jdm, #37120). Finally, we rewrote the implementation of the text property on HTMLOptionElement to avoid crashes with deeply-nested elements (@kkoyung, #37167).

Having previously noticed an unsafe pattern triggered by using JS-owned values in Rust Drop implementations (#26488), we have begun incrementally removing existing Drop impls to remove that source of unsafety (@willypuzzle, #37136).

Upgrades

We upgraded our fork of WebRender to April 2025 (@mrobinson, #36770), and upgraded our Stylo dependency to May 2025 (@Loirooriol, #36835). These changes ensure that Servo is up to date with ongoing work in Firefox, which shares these dependencies.

Donations

Thanks again for your generous support! We are now receiving 4597 USD/month (−1.4% over April) in recurring donations. This helps cover the cost of our self-hosted CI runners and one of our latest Outreachy interns!

Servo is also on thanks.dev, and already 25 GitHub users (+1 over April) 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.

4597 USD/month

10000

As always, use of these funds will be decided transparently in the Technical Steering Committee. For more details, head to our Sponsorship page.

18 Jun 2025 12:00am GMT