After nearly three years of development (it takes time to make up one's mind) Firefox for Linux users can now enjoy seamless emoji insertion using the native GTK emoji chooser. This long-requested feature, implemented in Firefox 150 (recent Beta), brings a more integrated experience for Linux users who want to add emojis to their web content.
Starting with Firefox 150, the native Gtk emoji picker can be invoked directly within Firefox. This means you can insert emojis into text fields, comment boxes, social media posts, and any other web input using the same interface you're already familiar with from other GTK applications.
How to use it
Using the emoji picker is simple and follows standard GTK conventions:
Click into any text input field on a webpage
Press Ctrl+. (Control + period) or Ctrl+; (Control + semicolon)
The native GTK emoji chooser will appear
Select your emoji, and it will be inserted at your cursor position. The picker works seamlessly in both main browser windows and popup windows.
How to disable it
The feature leverages GTK's built-in GtkEmojiChooser widget, ensuring that the look and feel matches other applications in your desktop environment.
For users who prefer not to use this feature (perhaps due to conflicts with custom keybindings or specific workflows), Firefox provides a preference to disable it. Go to about:config page and set widget.gtk.native-emoji-dialog to false.
Why it took too long?
The native GTK emoji picker implementation uses the GtkEmojiChooser popover built into GTK3. Unlike other GTK dialogs (file picker, print dialog), it can't be invoked directly in GTK3 - it must be triggered by a key-binding event or signal on GtkEntry or GtkTextView widgets, and the widget has to be visible from GTK's perspective.
This conflicts with Firefox's GTK architecture, which doesn't use GTK widgets directly but instead paints everything itself.
But a solution was found. Firefox already has an invisible GtkEntry widget that's not attached to any actual window. It's an offscreen widget used to invoke
key-binding events from GTK input events, like copy/paste and other edit commands. It also receives the 'emoji-insert' signal after Ctrl+., but normally ignores it since the GtkEntry itself isn't visible.
I configured the GtkEntry to listen for the 'emoji-insert' signal. When received, I create a new GtkEntry as a child of the recently focused GtkWindow and redirect the 'emoji-insert' signal there. The GtkEntry has to be 'shown' but remains invisible to users because Firefox paints a wl_subsurface over it.
It also needs to be correctly positioned to show the GtkEmojiChooser in the right location, and connected to other signals like 'insert_text' to retrieve the selected emoji. Thanks to Emilio Cobos Álvarez and Masayuki Nakano for their helpful hints on text processing and positioning!
When we set out to understand Rust's challenges, we expected to hear about the borrow checker learning curve and maybe some ecosystem gaps. Of course, we did. A lot. But, of course, it's more nuanced.
The conventional wisdom is that Rust has a steep learning curve, but once you "get it," smooth sailing awaits. We found that while some challenges disappear with experience, they are replaced with others. Beginners struggle with ownership concepts, experts face domain-specific challenges: async complexity for network developers, certification gaps for safety-critical teams, ecosystem maturity issues for embedded developers.
This isn't all doom and gloom though: we ultimately found that despite Rust's challenges, it remains necessary and desired:
If all the things laid out [to make Rust better] were done, I'd be a happy Rust programmer. If not, I'd still be a Rust programmer. -- Engineering manager adopting Rust for performance
The universal challenges that affect everyone
Across every interview, regardless of experience level or domain, we heard about the same core set of challenges. These aren't beginner problems that go away-they're fundamental friction points that manifest differently as developers grow.
Compilation performance: the universal productivity tax
Every single cohort we analyzed-from novices to experts, from embedded developers to web developers-cited compilation times as a significant barrier to productivity:
"Java takes about 100 milliseconds, Rust anywhere from 5 seconds to a minute depending on what you changed" -- Distinguished engineer working on backend systems at a large company
"8 to 10s iteration cycle... when you want to tweak the padding on a box" -- GUI development team
The impact varies by domain, but the pattern is consistent. CLI tool and GUI developers, who need rapid iteration cycles, are hit hardest. Safety-critical developers with 25-30 minute build times face workflow disruption. Size-constrained embedded developers are forced into optimized builds that take longer to compile and complicate debugging.
What's particularly important to note, is that this isn't just about absolute build times; it's about the development velocity tax that compounds over time. Long compile times can have strong negative impact on code iteration time. Anything that can reduce this code iteration time - hot reloading, fast debug builds, faster linking - will have an outsized impact on development velocity.
Moreover, the compilation performance tax compounds at scale. Individual developers might tolerate 5-10 second builds, but teams with CI/CD pipelines, large codebases, and frequent iterations face exponentially worse impacts. One participant noted 25-30 minute builds that create "wait for 30 minutes before the tool finds out I made a mistake" cycles.
The borrow checker: first it's sour, then it's sweet
The borrow checker is often touted as a "beginner problem", and we found that this is largely true: Novices are most strongly impacted by the borrow checker, but this often extends even into the stage where a developer is comfortable writing Rust where they still get tripped by the borrow checker sometimes.
However, highly-experienced Rust developers basically never cite the borrow checker itself as a frustration for them.
Ownership: The first time I went through the chapter, I was really like, what is this? - Developer learning Rust as a first language
I actually did not understand the borrow checker until I spent a lot of time writing Rust - Executive at a developer tools company
Async complexity: the "Three Horsemen" problem
Multiple participants identified async as a pain point. Many people, not just beginners, often choose to completely avoid it, instead focusing on solely on sync Rust. This is because, for many, async Rust feels completely different.
My biggest complaint with Rust is async. If we want to use [a tool], we're forced into that model...not just a different language, but a different programming model...I have zero [experience], I've been avoiding it. - Developer working on a security agent at a large company
Of course, those who do use it often share how complex it is, how it can feel incomplete in ways, or how it is difficult to learn.
"When you got Rust that's both async and generic and has lifetimes, then those types become so complicated that you basically have to be some sort of Rust god" -- Software engineer with production Rust experience
"My general impression is actually pretty negative. It feels unbaked... there is a lot of arcane knowledge that you need" -- Research software engineer
"There's a significant learning gap between basic Rust and async programming... creating a 'chasm of sadness' that requires substantial investment to cross." -- Professional developer
The async complexity isn't just about individual developer experience: it is exacerbated by ecosystem fragmentation and architectural lock-in:
"the fact that there is still plenty of situations where you go that library looks useful I want to use that library and then that immediately locks you into one of tokio or one of the other runtimes" -- Community-focused developer
This fragmentation forces architectural decisions early and limits library compatibility, creating a unique challenge among programming languages.
Of course, it would remiss to clarify that plenty of people do express positive sentiments of async, often despite the mentioned challenges.
Ecosystem navigation: choice paralysis and tacit knowledge
The Rust ecosystem shows uneven maturity across domains: excellent for CLI tools and web backends, but significantly lacking in other domains such as embedded and safety-critical applications. This creates a fragmented adoption landscape where Rust's reputation varies dramatically depending on your domain.
"Biggest reason people don't use Rust is that the ecosystem they'd be entering into is not what they expect. It doesn't have the tooling that C++ has nor the libraries." -- Developer for a large tech company
"I think the amount of choice you can have often makes it difficult to make the right choice" -- Developer transitioning from high-level languages
"the crates to use are sort of undiscoverable... There's a layer of tacit knowledge about what crates to use for specific things that you kind of gather through experience" -- Web developer
The problem isn't lack of libraries-it's that choosing the right ones requires expertise that newcomers don't have.
The Rust Project has made this choice mostly intentionally though: it has chosen not to bless certain crates in order to not unduly stifle innovation. The expectation is that if a newer crate ends up being "better" than some well-established crate, then that newer crate should be become more popular; but, if the Project recommends using the more established crate, then that is less likely to happen. This is a tradeoff that might be worth reevaluating, or finding clever solutions to.
How challenges amplify differently across domains
While the core challenges are universal, different domains have unique challenges that ultimately must be either adoption blockers or acceptable trade-offs.
Embedded systems: where every constraint matters
Embedded developers face the most constrained environment for resources, which can amplify other challenges like learning.
"if you pull in a crate, you pull in a lot of things and you have no control" -- Embedded systems researcher
"can't use standard collections like hashmaps" -- Embedded software engineer
Debug builds become too large for small controllers, forcing developers into optimized builds that complicate debugging. Cross-compilation adds another layer of complexity. The "no-std" ecosystem, while growing, still has significant gaps.
Safety-critical systems: stability vs. innovation tension
Safety-critical developers need Rust's memory safety guarantees, but face unique challenges around certification and tooling:
"we don't have the same tools we have to measure its safety criticality as we do in C++ and I think it's a worry point" -- Safety systems engineer
"not a lot of people know Rust not a lot of managers actually trust that this is a technology that's here to stay" -- Safety-critical developer on organizational barriers
The tension between Rust's rapid evolution and safety-critical requirements for stability creates adoption barriers even when the technical benefits are clear.
To note, we previously wrote a blog post all about safety-critical Rust. Check it out!
GUI development: compile times inhibit iteration speed
GUI developers need rapid visual feedback, making compilation times particularly painful:
We've got a UI framework that's just Rust code so when you want to tweak the padding on a box ... it's a pain that we just kind of accept a 10 seconds or more iteration cycle. -- Developer working on a GUI app
Background-dependent learning paths
One important insight gained from this work, and it seems obvious if you think about it, is that learning Rust isn't a universal experience: it depends heavily on your background:
High-level language developers must learn systems concepts alongside Rust:
The challenge for me was I needed to grasp the idea of a lower-level computer science ideas and Rust at the same time. -- Developer with Typescript background
Low-level developers often struggle to unlearn patterns and concepts:
I'm coming from C++ world so I had the big class that does everything. Taken a while for me to internalize that "dude you gotta go down a level". -- Developer with C++ background
Rust tried to hide away notion of pointers - Just tell me it's a pointer -- System-level developer
Interestingly though, learning Rust alongside C++ can help students understand both better:
Students learn smart pointers in C++ and then 'we're just now learning smart pointers with Rust as well' - learning both at the same time makes it easier. -- Community organizer
Recommendations
Invest in compilation performance as a first-class concern
Given that compilation performance affects every single user group, we recommend treating it as a first-class language concern, not just an implementation detail. This could include:
Incremental compilation improvements that better match developer workflows
Build system innovations that reduce the iteration cycle tax
Tooling integration that makes build times less disruptive
We do want to quickly shout a couple of neat community projects that have this goal in mind:
The subsecond crate by the Dioxus team allows hot-reloading, which can make workflows like those found in GUI development more seamless
The Wild linker aims to be a fast linker for Linux, with plans for incremental linking
Invest in ecosystem guidance and compatibility
We previously made some suggestions in this area, and they still hold true. Finding ways to not only help users find crates that are useful to them, but also enable better compatibility between crates will surely have a net-positive benefit to the Rust community.
Address learning diversity
When someone is learning Rust, their programming language background, level of experience, and domain in which they are trying to work in, all influence the challenges they face. We recommend that the Rust Project and the community find ways to tailor learning paths to individuals' needs. For example, for someone with a C or C++ background, it might be useful to be able to directly compare references to pointers.
Similarly, having domain-specific learning materials can help newcomers focus on the problems they are facing more specifically than a general "Rust tutorial" might. The Embedded Rust Book does this, for example.
Close the gap between sync and async Rust
This is a tall order -- there are a lot of moving parts here, but it's clear that many people struggle. On one hand, async Rust feels often "incomplete" in some language features compared to sync Rust. On the other, documentation is often focused on sync Rust (for example, much of The Rust Programming Language Book is focused on sync code patterns).
Within the Rust Project, we can work towards stabilizing long-awaited features such as async functions in dyn traits, or improving compiler errors for issues with, for example, lifetimes and async code. We can include fundamental async library traits and functions within std, enabling a more cohesive async ecosystem.
Of course, as much as can be done within the Rust Project, even getting more community involvement in producing tutorials, example code, and otherwise just sharing knowledge, can go a long way to closing the gap.
Conclusion
Rust's challenges are more nuanced than the conventional "steep learning curve" narrative suggests. They are domain-specific and evolve with experience.
Understanding these patterns is crucial for Rust's continued growth. As we work to expand Rust's reach, we need to address not just the initial learning curve, but the ongoing friction that affects productivity across all experience levels.
The good news is that recognizing these patterns gives us recommendations for improvement. By acknowledging the expertise gradient, prioritizing compilation performance, creating better ecosystem navigation, and addressing background-dependent challenges, we can help Rust fulfill its promise of empowering everyone to build reliable, efficient software.
At Thunderbird, we firmly believe in the strength of listening to our community's needs and wants, and balancing it with our resources and capabilities. While this has always been part of our ethos, we want to start 2026 by making our goals easier to read and comprehend at roadmaps.thunderbird.net, where you will find our roadmaps for our Services and both the Thunderbird Desktop and Mobile products.
To better serve our community, we are making several thoughtful updates to how we build and communicate our roadmap. These key changes include clearer estimation practices, stronger strategic framing, and more transparent updates when priorities evolve.
Intentional Descriptions
You may notice that the descriptions of each roadmap item is written in very common, non-technical, language as much as possible. This is done purposefully, so that someone from any technical level can understand what we are trying to achieve. We have also tried to not be too verbose so that you, the reader, can be informed without being bored.
Regular Reviews and Updates
At the end of each calendar quarter, we will hold internal roadmap review meetings with each of the Desktop, Mobile, and Services teams. We will review the estimated progress and priority of each item and adjust the roadmap as needed.
Any changes to the roadmap will be clearly communicated to the tb-planning topicbox list.
What the Roadmap is and is not
We know that different companies and projects can approach the term "roadmap" differently so let's be clear about what Thunderbird is providing.
This roadmap reflects our current priorities and the work we believe will have the greatest impact in 2026. While priorities can evolve as new information arises, we're committed to reviewing progress quarterly and communicating any adjustments clearly and transparently.
Our public roadmap is focused on themes rather than individual tasks or bugs to fix. It is our directional plan that outlines the goals for this year. We view a roadmap as a plan to keep us on target, towards accomplishing broader goals, rather than a wishlist of bugs to fix.
Balancing Ideas with Capacity
Thunderbird thrives because of its community. Every year, we receive more great ideas than we have capacity to implement. Our responsibility is to focus on the initiatives that create the broadest impact while enduring the long-term health of the project.
That doesn't mean individual ideas don't matter. In fact, community input directly influences our roadmap over time. The updated roadmap process helps us be more clear about what we can take on right now, and how new ideas can shape what comes next.
If there's something you'd love to see in Thunderbird, please share it. Momentum starts with voices like yours.
Accessibility has always been close to my heart. I was introduced to it early in my career, when a client required our product to be AAA-compliant. As a team of two, we audited our entire app.
We were barely AA.
If those letters don't mean much, they refer to the Web Content Accessibility Guidelines (WCAG), the international standard for making digital products usable for people with disabilities. AAA is the highest level of conformance. AA is typically considered the acceptable baseline.
We weren't even confidently there. That experience changed how I see design.
Most products today aren't perfect. Many aren't even close. But accessibility isn't just about passing audits or checking contrast ratios.
Yes, color contrast matters. Alt text matters. Focus states matter. But those should be the floor, not the ceiling. Accessibility goes beyond a checklist. It's a mindset. And that mindset deepened for me on the Firefox UX team.
At Mozilla, I've had the opportunity to collaborate closely with our accessibility specialists and conduct research using Fable: a platform that connects us directly with people who use assistive technologies like screen readers, magnification software, and voice access.
Instead of designing based on assumptions, we test with real users navigating Firefox in real ways. That difference is everything.
In two recent moderated sessions I facilitated, I was reminded how much nuance lives in the margins of our designs.
In one session, we worked with a participant who uses screen magnification software. We learned:
Even the slightest pixelation can create ocular vibration and discomfort
Swipe gestures, which often feel "modern" to designers, can be risky or disorienting for magnification users
Thoughtful line height can meaningfully reduce cognitive load
These aren't things you catch in a checklist review. They're things you learn by listening.
In another session, an Android user who relies on Voice Access showed us something equally important:
Holding and dragging interactions are difficult with voice control
App-level voice commands can interfere with system-level voice access tools
Features designed to feel innovative can unintentionally create barriers. That tension is where real accessibility work happens.
This experience wasn't just eye-opening for me. My teammate Nicole reflected:
"Working with Fable was a great experience. One takeaway that stood out was how low vision users face similar challenges to anyone using their phone outside in bright sunlight, especially around contrast. It also made us think more about designing for an aging population… building in accessibility now sets us up to serve more users over time. Overall, it broadened our perspective, helped us build empathy, and made the product better. This kind of research should be a standard part of the design process."
That last line stays with me: This kind of research should be standard.
These sessions fundamentally changed how I approach design. Accessibility now shows up much earlier in my process: not as a final pass, but as a lens.
When defining problems, I ask:
What happens if this is heard instead of seen?
How does this interaction work without touch?
Could this increase cognitive load?
Are we designing for someone unlike ourselves?
It's no longer a checklist I review at the end. It's something I carry from the beginning. And it makes our critiques stronger, our conversations sharper, and our decisions more intentional.
Accessibility also deeply aligns with Mozilla's mission. We will always stand behind our belief that the internet should be open, usable, and available to everyone. Designing accessibly is just one of the ways we can achieve that.
When we remove barriers, we're not just improving usability; we're protecting participation, agency, and inclusion on the web.
Of course, no process is perfect. Deadlines are real. Technical constraints are real. Accessibility can feel overwhelming, especially if you're new to it.
But you don't have to know everything to start. A lot of it is just learning as you go.
Start with the basics
Take advantage of resources you do have
Advocate for testing with real users
Most importantly: don't treat accessibility as an afterthought. The more you practice it, the more it becomes instinctive.
Accessibility extends beyond pixels.
It's not about compliance. It's about empathy. And when we design with accessibility in mind, we're not designing for a small group of users.
One can use git add [-N|--intent-to-add] <PATH> to record that a new path will need to be considered in later additions to the index. But what about the other way round? How to tell git that a change SHOULD NOT be considered?
Fortunately, there is the git update-index(1) command. Amongst (many) other options, it supports --assume-unchanged <PATH>. This will tell git to ignore current and any further changes to this <PATH>, until --no-assume-unchanged is used.
This abuses the initial purpose of the assume-unchanged logic, but it's handy for when you want test changes to survive for a bit longer, without risking committing them when git adding in wild abandon. Also, a footgun for when you think your repository is clean, but it has some magic in an assumed-unchanged file you forgot about. You can use git ls-files -v to check the status of your files (h is assumed unchanged, H is normal behaviour).
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.
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.
Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!
Some of these tasks may also have mentors available, visit the task page for more information.
If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!
Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.
Oxidize Conference | CFP open until 2026-03-23 | Berlin, Germany | 2026-09-14 - 2026-09-16
EuroRust | CFP open until 2026-04-27 | Barcelona, Spain | 2026-10-14 - 2026-10-17
NDC Techtown 2026 | CFP open until 2026-05-03 | Kongsberg, Norway | 2026-09-21 - 2026-09-24
If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!
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.
What we collectively build, beyond the code artifacts that the compiler+tools are, is a group of people who come back, who learn, who share their understanding, who align their tastes, who take input from the community, etc etc. Merging an LLM-generated PR feeds only the "we have code that works" part of the Project; it's not participating in all the other feedback cycles that make the project alive.
Welcome to the first Community Office Hours of 2026! We're all recovered from conferences in Brussels and California, and we're talking to members of one of our newest teams: Support.
Wait, hasn't Thunderbird always had a support team? Surprisingly, no! We've had individual staff members responsible for different parts of our support efforts, but never combined into one fantastic team. This includes new hires Lisa (Jill) Wess, Manager of Customer Support Operations, and MadHatter McGinnis, Support Knowledge and Enablement Lead, whose work is not only vital for Thundermail, but a better experience for donors, users, and contributors alike. We're also joined by Roland Tanglao and Wayne Mery, two of our longstanding support and community staff who you might remember from our office hours on writing support articles and helping users on the support forums.
Community Office Hours are just getting started this year. Thank you so much for joining us for these sneak peeks into how we make, improve, and expand Thunderbird! As always, if you have any ideas for future office hours topics, let us know in the comments!
A New Model for Support
While Lisa and MadHatter have only been at Thunderbird for less than a year, the impact they've made since then is notable. When Thundermail launches later this year, users will experience their work when they read a user guide, ask for support, or make a suggestion on ideas.tb.pro. This renewed focus on support won't only be for Thundermail users, however! In the video, the members of the support team discuss how the team wants to make it easier to get help AND easier to provide it, whether the person answering questions is a staff member or a volunteer contributor. No matter what technical improvements the team has planned, human beings will always be at the heart of the Thunderbird (and Thundermail) support experience.
This includes the existing Thunderbird support on the Mozilla Support forums. As always, there is so much our community can do to help out fellow Thunderbird users with questions or issues they might have. Roland and Wayne offer useful tips on where to get started on the support contributor journey. One path that might be new to readers is suggesting improvements or new knowledge base (KB) articles! If you have ideas on replacing outdated advice, updating screenshots, or ways to fill knowledge gaps with a new KB article, we'd love to hear from you, whether your advice is about the desktop or Android client.
Smart Window added contextual prompts for follow-ups bug 2012208 and conversation starters bug 2014946
SplitView is approaching completion in Nightly and hopes to ride the trains soon. If you see something, say something (File a bug in Firefox: Tabbed Browser: Split View)
Session History (Jake Diagrams) is now available in DevTools
Set behind a pref devtools.application.sessionHistory.enabled. Feel free to try it out!
The Firefox Profiler now supports dark mode thanks to :arai!
Fixed issue hit by concurrent installations due to error handling potentially removing the entire staging directory used by the other concurrent XPI files pending installation - Bug 2006512
Fixed issue with "Available Updated" badge counter getting out of sync - Bug 1548836
WebExtensions Framework
Disabled dom.keyboardevent.init_key_event.enabled_in_addons preference on all channels - Bug 2015079 / Bug 2013772
NOTE: 1Password 4.x relied on a deprecated, non-standard API (initKeyEvent) in Firefox. The deprecated feature has been disabled for the release channel in Firefox versions >= 147. Users still using the discontinued 1password classic extension should migrate to the maintained 1password extension or migrate to another maintained password manager.
Investigated and fixed excessive process creation on rapidly clicking extension icons (e.g., uBlock) - Bug 1987679 / Bug 2007742
WebExtension APIs
Exposed splitViewId property in tabs extension API to support split view feature - Bug 1993037
Improved cross-browser compatibility for the browserAction and pageAction openPopup API method, in particular allowing it to be called without user interaction (which is an ability that password managers leverages) - Bug 1799344 / Bug 1799347 / Bug 2011516
Fixed issue with browser.storage.onChanged API event not emitted for object writes after opening Storage tab in DevTools - Bug 1994355
Deprecating executeScript API methods support for dynamically executing code into moz-extension documents - Bug 2011234
NOTE: This deprecation is in the process of being documented and communicated to extensions developers. The restriction is active by default on Nightly, whereas it will be logging a deprecation warning on Beta and Release channels.
Nicolas Chevobbe [:nchevobbe] added inactive CSS indicator for position-area when the element is not absolutely positioned, and/or doesn't have a default anchor (#1895185)
We've started making xul:splitter keyboard accessible. Bug 2012633 - Splitter component is not accessible landed for splitview splitter. There are others across the product that can make it focusable.
New Tab Page
With the startup crash fixed, train-hopping has been unblocked! 149.1.20260121.51415 went out to the release and beta channels recently.
Maxx Crawford added thumbnail attachment to uploaded wallpapers, using the generated thumbnail for previews in the Customize panel to speed image rendering and reduce decode cost while keeping full‑res when applied.
Nathan Barrett enabled the image proxy backend for newtab, giving us the ability to route newtab image requests through a third-party proxy for better privacy characteristics. This is disabled by default while we investigate proxying strategies.
Working on the mobile Firefox team gives you the opportunity to touch on many different parts of the browser space. You often need to test the interaction between web content and the application integration's to another component, say for example, a site registering for a WebPush subscription and Firefox using Firebase Cloud Messaging to deliver the encrypted message to the end-user. Hunting around for an example to validate everything fine and dandy takes time.
Sometimes a simple test site for your use case is helpful for initial validation or comparison against other browsers.
Below is a list of tests that I've used in the past (in no particular order):
Push notifications requires a server to send a notification to the client (not the same as a WebNotification), so you can use this WebPush test site for validating just that.
Tracking Protection test page. Somewhat ancient so cookie blocking might not work.
Forms and Autocomplete
There are various form types and various heuristics to trigger completion options, so they deserve their own section. The more (test sites) the merrier!
Sign-up and login forms behave differently, so they are handy to test separately. For example, autofilling a generated password is useful on a registration form but not on a login one.
Make your own
If you need to make your own, try to write out the code yourself so you can understand the reduced test case. If it's not straight-forward, try using the Testcase Reducer by Thomas Wisniewski.
Comments
With an account on the Fediverse or Mastodon, you can respond to this post. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. Known non-private replies are displayed below.
Learn how this was implemented from the original source here.
<noscript><p>Loading comments relies on JavaScript. Try enabling JavaScript and reloading, or visit <a href="https://mindly.social/@jonalmeida/115937256635328128">the original post</a> on Mastodon.</p></noscript>
<noscript>You need JavaScript to view the comments.</noscript> &>"'
Firefox is for people who make their own choices online, from what stays private to the tools that help get things done. That commitment to choice shows up throughout the Firefox experience, and AI controls is just the latest example - making it possible to turn generative AI features off, on, or customize them feature by feature.
Over the coming weeks, we'll be rolling out a series of updates that build on that. Expect more control where it matters, better protections in the background, and a few new tools that make everyday browsing better. You may even spot a fresh face of Firefox along the way.
Here's a quick look at what to watch for:
An easier way to personalize Firefox
The Settings section has been improved with clear navigation and search, so it's simpler to customize Firefox. Available soon inFirefox Nightly.
Privacy upgrades, built in
A freebuilt-in VPN is coming to Firefox. Free VPNs can sometimes mean sketchy arrangements that end up compromising your privacy, but ours is built from our data principles and commitment to be the world's most trusted browser. It routes your browser traffic through a proxy to hide your IP address and location while you browse, giving you stronger privacy and protection online with no extra downloads. Users will have 50 gigabytes of data monthly in the U.S., France, Germany and U.K. to start. Available in Firefox 149 starting March 24.
Smart Window, previously called AI Window, uses AI to give quick help while you browse - like quick definitions, article summaries, product comparisons and more - without leaving the page. It's completely optional to use and will be opt in. Waitlistnow open for updates and early access.
Split view puts two webpages side by side in one window, making it easy to compare, copy and multitask without bouncing between tabs. Rolling out in Firefox 149 on March 24.
Tab Notes let you add notes to any tab, another tool to help with multitasking and picking up where you left off. Available inFirefox Labs 149starting March 24.
"The roadmap for Firefox this year is the most exciting one we've developed in quite a while. We're solely focused on building the best browser, and our features over the next few months and beyond are driven by the feedback from our community," said Ajit Varma, head of Firefox. "We're improving the fundamentals like speed and performance. We're also launching innovative new open standards in Gecko to ensure the future of the web is open, diverse, and not controlled by a single engine. At the same time we're prioritizing features that give users real power, choice and strong privacy protections, built in a way that only Firefox can. And as always, we'll keep listening, inviting users to help shape what comes next and giving them more reasons to love Firefox."
Firefox is also getting a fresh new look across our website, product and beyond. This includes updated themes, icons, and visual refinements across Firefox, including our toolbars, menus, and the homepage. It also brings usability improvements that make key features easier to access. The changes reflect user feedback and aim to modernize the browser while reinforcing a more distinctly Firefox look and feel. We appreciate the community feedback on the designs. We'll be sharing more soon.
You also may have noticed something else showing up in Firefox recently: our new mascot, Kit. Kit is your companion in this new internet era, our way of making Firefox's support visible and bringing a little warmth and familiarity as you browse.
More to come
Choosing Firefox means using the internet on your own terms: options when you want them, safety when it matters most, and tools that make the web easier to navigate.
Download the latest version of Firefox to try what's new, and let us know what you think on Mozilla Connect.
The web shouldn't feel like it's working against you. Yet so much of it now is designed to pull you off course: endless feeds, pop-up windows and content that looks credible until it isn't. Staying focused and trusting your next click takes more effort than it should.
Firefox is here to help you navigate the web on your own terms. That means a browser built for people: one that doesn't sell your data, that's open and optional with AI and that isn't owned by billionaires.
And as we enter a new internet era - one shaped by AI and a web that's harder to trust - Kit is our way of making our support visible, a companion that brings some warmth and familiarity when you're browsing with Firefox.
Where you'll see Kit
In Firefox, Kit may appear in moments that are meant to feel welcoming or encouraging: when you're getting started, discovering a new feature or hitting a small win (like when you've successfully made a setting change).
You'll also see Kit outside the browser, like on our product website, the blog, across social media and in campaigns. If you want, you can set Kit as your new tab wallpaper (bottom right corner: Customize > Firefox). You may even spot Kit in the real world at our community events.
Kit is a companion, not a commentator. They're not here to deliver punchlines. Kit shows up as a small signal that Firefox is working for you, then steps back so you can keep moving.
How we made Kit
To bring Kit to life, we partnered with creative agency JKR and illustrator Marco Palmieri. We chose JKR because they've helped iconic character brands evolve for modern audiences, and we needed collaborators who could build a companion with range - not just a mascot.
Marco helped shape Kit's personality through the kind of craft that only comes from drawing characters for a living. He started the way he always does: with a pencil. "I tend to stay away from the computer at the beginning," he said. "I want as few obstacles as possible between me and what I'm trying to see."
From there, the work moved into Illustrator, where Kit could be refined through many rounds of iteration. Two decisions shaped Kit along the way.
First: the tail. It isn't just a signature detail. It's part of Kit's personality, helping carry motion and emotion even in still moments.
Second: no mouth. We wanted Kit to feel expressive without tipping into "talking cartoon" territory. So expression lives in the eyes, posture and body language instead.
Our teams explored how literal Kit should be to the Firefox logo. Fox proportions mattered, but so did making something new. At one point, we asked ourselves whether or not Kit should look more like a red panda (leading to a brief detour into red panda references).
In the end, we agreed that Kit isn't a fox nor a red panda. Kit is a Firefox, its own creature - with attributes from both a fox and a red panda, and perhaps a little fire magic.
Marco wants Firefox fans to meet Kit with curiosity. "I hope that they would want to look," he said. "Not just glance and move on, but feel like there's a little character here you might actually want to get to know."
Kit was created by a team of people, not generated by AI. And Kit isn't an AI assistant or a chatbot. Kit came from hundreds of small choices - tail flicks, textures, gradients, proportions - made deliberately, then refined until the character felt right to what Firefox stands for.
More fire. More fox.
The web can feel like it's trying to wear you down: pulling at your attention, keeping you stuck with defaults and asking for more than it should. That's why Firefox exists, and why the internet needs it. Firefox has your back. And we hope Kit helps make that promise visible, with conviction where it matters and lightness when it helps.
You deserve a browser that respects your humanity, agency and privacy - one that's built for people, not profit. The internet as it should be.
Hi all, I wanted to share some of the performance optimizations for mach that have landed recently or are landing soon:
bug 1775197 reduced the overhead of mach's initialization process by ~30%-50% (highly platform and command specific), which means that commands you invoke could begin executing up to a second sooner than before, which should make things feel much more responsive.
bug 2018327 sped up a pre-test step that verifies all test files are in the right place before tests start running. On Windows, this shaved ~13 seconds off the time between invoking ./mach test/./mach xpcshell-test and tests actually starting to run (~75% speedup). Minor (if any) improvement on Linux/macOS.
bug 2017746 (landing today) speeds up ./mach configure by adding caching to a taskcluster step that verifies you have up-to-date toolchains, which saves up to 10 seconds (~50% speedup) if none of the toolchain input files changed since the previous run. The most common scenario that benefits from this is editing your mozconfig then building.
The Firefox bug bounty program is the longest-running security bug bounty program. Born out of Netscape's bug bounty program, we've been awarding ingenious security research for over two decades, helping keep our hundreds of millions of users safe.
With the threat landscape changing, we're updating our security program along with it. As browser security architecture continues to improve, our bug bounty program is evolving to focus incentives on the highest-impact work and the most critical threats.
Policy changes
We are keeping updates to the reporting process to a minimum so that experienced and successful researchers do not need to change how their security bugs are reported right now.
Raising the bar for report quality and novelty
Quality: As part of our policy update, we are putting an increasing emphasis on actionable reports: Reducing the time spent on validating theoretical concerns and focusing on confirmed vulnerabilities is ensuring faster resolution, faster reward payments and a better Firefox. Our existing policy already differentiates between high-quality reports and reports that only provide sufficient information to inform us of a new security vulnerability. Going forward, we will now require security researchers to provide simple and reproducible test cases for reports to be eligible for bounty rewards (e.g., demonstrable with an Address Sanitizer build). Reports without any credible evidence of a security issue will be assigned a much lower priority.
Novelty: In light of a recent increase in duplicate security bug reports and timing issues where researchers were able to race some of our internal tools, we are reserving an increased time window of seven days for our internal automated methods to find security issues. While this might affect more bug reports than before, we also believe this encourages researchers to focus on novel research that genuinely benefits advancements in the security posture, rather than research that replicates existing open source tools or results already captured by internal processes. This puts original, high-quality research back in the center of our bug bounty program
Aligning Security Architecture and Reward Structure
Security Architecture: Firefox is already using multiple utility processes to reduce the level of privilege for security-critical code. We are therefore focusing our rewards for "Highest Impact" / "Sandbox Escape" solely on attacks that compromise the parent process. We are also going to release a separate, sandboxed GPU process on all Operating Systems in 2026, which means that from now on, we will assess vulnerabilities in our graphics stack according to their sandboxed context, rather than treating them as full sandbox escapes. These bugs will still be considered as "High Impact" memory corruptions. We are also working on better definitions for compromising other processes and will update the bounty program again with more eligible process pairs in the future.
Changes to our Reward Structure: We limit our definition of sandbox escapes to true escapes that will allow the attacker to gain control over a higher privileged, unsandboxed process. This definition also excludes memory-reads as well as cross-process exploits targeting other sandboxed processes. As with above, we will continue to rate memory corruptions and attacks on other processes as "High Impact" findings. Consequently, the highest reward will be limited to breaches of the most hardened security boundaries.
Join our bug bounty program
These updates are a natural step forward in maintaining a highly effective, quality-focused program that addresses the real and evolving security risks facing modern browsers.
We encourage researchers to engage with these clarified guidelines and focus their efforts on high-impact vulnerabilities and continue working alongside us to strengthen Firefox by focusing on the vulnerabilities that matter most.
We will provide additional guides and tips for improved bug finding and reporting based on previous bug reports in upcoming blog posts. We are also reminding our readers and security community that we welcome guest articles on our blog where successful researchers can share their discoveries.
We would welcome people to try and report issues with the nightly-only cargo -Zbuild-dir-new-layout. While the layout of the build dir is internal-only, many projects need to rely on the unspecified details due to missing features within Cargo. While we've performed a crater run, that won't cover everything and we need help identifying tools and process that rely on the details, reporting issues to these projects so they can update to the new layout or support them both.
How to test this?
With at least nightly 2026-03-10, run your tests, release processes, and anything else that may touch build-dir/target-dir with the -Zbuild-dir-new-layout flag.
For example:
$ cargo test -Zbuild-dir-new-layout
Note: if you see failures, the problem may not be isolated to just -Zbuild-dir-new-layout. With Cargo 1.91, users can separate where to store intermediate build artifacts (build-dir) and final artifacts (still in target-dir). You can verify this by running with only CARGO_BUILD_BUILD_DIR=build set. We are evaluating changing the default for build-dir in #16147.
Outcomes may include:
Fixing local problems
Reporting problems in upstream tools with a note on the the tracking issue for others
ranger-ross has worked tirelessly on this as a stepping stone to cross-workspace caching which will be easier when we can track each cacheable unit in a self-contained directory.
While the Cargo team does not officially endorse sharing a build-dir across workspaces, that last item should reduce the chance of encountering problems for those who choose to.
Future work
We will use the experience of this layout change to help guide how and when to perform any future layout changes, including:
Efforts to reduce path lengths to reduce risks for errors for developers on Windows
Experimenting with moving artifacts out of the --profile and --target directories, allowing sharing of more artifacts where possible
In addition to narrowing scope, we did not do all of the layout changes now because some are blocked on the lock change which is blocked on this layout change.
We would also like to work to decouple projects from the unspecified details of build-dir.
Sync: l10n → main (March 20, 2026) (
![Screenshot of a terminal. ``` [17:33:58] ~/src/tests/assume-unchanged$ echo a > a 0s main [17:34:01] ~/src/tests/assume-unchanged$ git status 0s ✭ main On branch main No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) a nothing added to commit but untracked files present (use "git add" to track) [17:34:05] ~/src/tests/assume-unchanged$ git add -N a 0s ✭ main [17:34:07] ~/src/tests/assume-unchanged$ git status 0s main On branch main No commits yet Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) new file: a no changes added to commit (use "git add" and/or "git commit -a") [17:34:08] ~/src/tests/assume-unchanged$ git add -p 0s main diff --git a/a b/a new file mode 100644 index 0000000..7898192 --- /dev/null +++ b/a @@ -0,0 +1 @@ +a (1/1) Stage addition [y,n,q,a,d,e,p,P,?]? y [17:34:11] ~/src/tests/assume-unchanged$ git commit -m 'a' 2s ✚ main [main (root-commit) 023d084] a 1 file changed, 1 insertion(+) create mode 100644 a ```](https://blog.narf.ssji.net/wp-content/uploads/sites/3/2026/03/2026-03-18T1734154333917131100.png)
![Screenshot of a terminal. ``` [17:36:00] ~/src/tests/assume-unchanged$ echo b > a 0s main [17:36:02] ~/src/tests/assume-unchanged$ git status 0s ✹ main On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: a no changes added to commit (use "git add" and/or "git commit -a") [17:36:03] ~/src/tests/assume-unchanged$ git update-index --assume-unchanged a [17:36:10] ~/src/tests/assume-unchanged$ git status 0s main On branch main nothing to commit, working tree clean [17:36:12] ~/src/tests/assume-unchanged$ echo c > a 0s main [17:36:14] ~/src/tests/assume-unchanged$ git status 0s main On branch main nothing to commit, working tree clean [17:36:15] ~/src/tests/assume-unchanged$ git update-index --no-assume-unchanged a [17:36:18] ~/src/tests/assume-unchanged$ git status 0s ✹ main On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: a no changes added to commit (use "git add" and/or "git commit -a") ```](https://blog.narf.ssji.net/wp-content/uploads/sites/3/2026/03/2026-03-18T1736209147243461100.png)
![Screenshot of a terminal. ``` [17:46:02] ~/src/tests/assume-unchanged$ git ls-files -v 0s ✹ main H a [17:46:06] ~/src/tests/assume-unchanged$ git update-index --assume-unchanged a [17:46:13] ~/src/tests/assume-unchanged$ git ls-files -v 0s main h a [17:46:14] ~/src/tests/assume-unchanged$ git update-index --no-assume-unchanged a [17:48:00] ~/src/tests/assume-unchanged$ git ls-files -v 0s ✹ main H a ```](https://blog.narf.ssji.net/wp-content/uploads/sites/3/2026/03/2026-03-18T1748289562047631100.png)
