<figcaption class="wp-element-caption">Jeff Lindsay is working to build the Photoshop of software at his company Progrium.</figcaption>
More than ever, we need a movement to ensure the internet remains a force for good. The Mozilla Internet Ecosystem (MIECO) program fuels this movement by supporting people who are looking to advance a more human-centered internet. With MIECO, Mozilla is looking to foster a new era of internet innovation that moves away from “fast and breaking things” and into a more purposeful, collaborative effort that includes voices and perspectives from many different companies and organizations.
This week we’re highlighting Jeff Lindsay, a self-proclaimed “rogue software engineer” who’s working to build the Photoshop of software at his company Progrium.
Jeff Lindsay has been shaking things up in Silicon Valley for the last two decades.
In the 2000s, he helped start SuperHappyDevHouse, a series of large parties for laptop-toting hackers to “work on whatever they feel like working on,” as his co-founder David Weekly once described it.
Jeff went on to develop a reputation for his ability to build things quickly while freelancing across the Bay Area. While working at a NASA research center in Mountain View, he was involved in developing OpenStack, an open source version of Amazon’s cloud service. Jeff also helped design and prototype the software Docker, which has become a billion-dollar company that creates productivity tools. He coined and pioneered webhooks, a standard way to create app integrations and plugins. Over the years, developers widely adopted his open source tools and libraries.
Now, in collaboration with MIECO, Jeff is working on Tractor System, a tool that lets users build software in a way that’s similar to creating and editing in Photoshop. His company, Progrium, is on a mission to empower the next generation of makers by providing tools and resources to reduce the complexity of computing through generative building blocks.
Jeff wants to make it easier for people to make software for themselves so that they’re less dependent on vendors who make software for companies and their needs. As the landscape of software development continues to evolve at a rapid pace, Jeff’s work aims to bridge the gap between using software, and creating it.
Tractor System is about building software that works for people, not corporations, Jeff said.
“Photoshop gives you the tools to do image manipulation yourself,” he explained. “So if I can build something that gives you enough tools to assemble and interact with software systems in a very general sense, then it opens up a whole lot more possibilities.”
He compared using Tractor System to having pre-assembled Lego kits. “You just take these pieces, and you put them together in new and novel ways,” he said. “Then you can take [the structure] apart and remix it with another kit.”
Jeff said the idea was inspired by game development, where designers can configure and make custom components using the game engine Unity. In a sense, Tractor System takes him back to how he got started as a programmer in the first place: finding a Commodore 64 at a flea market and then learning how to make games from programming books at his local library.
“I love anything that gives programmers more superpowers,” Jeff said. “And I love anything that then makes programming more accessible, because then regular people get those superpowers.”
The investment will help Fiddler scale its AI Observability Platform
(PALO ALTO, CA | JUNE 1, 2023) – Today, Mozilla Ventures is announcing an investment in Fiddler, the Silicon Valley-based company that helps enterprises build trust into AI with monitoring, explainability, analytics, fairness, and safety.
The Fiddler AI Observability Platform gives companies more visibility into their predictive and generative AI models. Fiddler’s platform helps stakeholders understand why predictions are made and what improvements are necessary for better outcomes — ultimately creating more trustworthy AI systems.
Fiddler brings increased transparency and actionable insights to the AI field at a vital moment. Generative AI models and applications are quickly being folded into consumer products and impacting billions of people — but sometimes these systems are biased and opaque, even to the engineers who build them.
Mozilla Ventures is a first-of-its-kind impact venture fund to invest in startups that push the internet — and the tech industry — in a better direction. The fund’s mission is largely modeled on Mozilla’s “Creating Trustworthy AI” whitepaper.
Mozilla Ventures isn’t publicizing its investment amount at this time. Fiddler has previously received investment from Insight Partners, Lightspeed Venture Partners, Lux Capital, Alteryx Ventures, Haystack Ventures, Bloomberg Beta, and The Alexa Fund, among other investors.
This funding will help Fiddler bring its Responsible AI by Design approach to influential customers, a list which already includes some noteworthy organizations. Core to Fiddler’s Responsible AI by Design approach is the question, How might an AI model adversely affect humans?
Fiddler defines responsible AI as a series of best practices to ensure that LLM and MLOps-based systems deliver on their intent while mitigating unintended or harmful consequences. The platform enables responsible AI through monitoring and out-of-the-box AI explainability and relies on the principles offairness, transparency, privacy, reliability, and accountability.
Fiddler also participated in Mozilla’s Responsible AI Challenge event on May 31, which convenes some of the brightest AI thinkers, technologists, ethicists and business leaders.
Says Krishna Gade, Founder and CEO of Fiddler: “We started Fiddler because there’s a need not just for more AI Observability in the industry, but also a framework that prioritizes societal good. Mozilla’s investment helps fuel our mission to make trustworthy, transparent, and understandable AI the status quo.”
Says Mohamed Nanabhay, Managing Partner of Mozilla Ventures: “Fiddler and Mozilla Ventures have a shared vision of AI — one that prioritizes fairness and explainability. In Fiddler’s role supporting a wide-range of AI companies, they can have an outsized influence on the ecosystem.”
Fiddler will join a cohort of other mission driven startups that Mozilla Ventures has invested in, including SAIL, heylogin, Lelapa AI, Themis AI, Block Party, and Rodeo. Mozilla Ventures launched in 2022 with an initial $35 million in funding.
When we relaunched the Mozilla Builders program last March, we unveiled our Responsible AI Challenge — a one-day, in-person event designed to inspire and encourage a community of builders working on trustworthy AI products and solutions — essentially a call to builders and technologists all over the world to create trustworthy AI solutions.
We are delighted to announce the prize winners of our Responsible AI Challenge, who demonstrated their ingenuity, innovation, and proficiency in developing human-centered and trustworthy AI applications and solutions.
A community of Builders
After weeks of reviewing hundreds of competitive consumer technology and generative AI projects, this challenge brought together builders and entrepreneurs from around the world, each vying to build better products and more responsible companies, despite the fact that it’s often the path of most resistance. After careful deliberation by our panel of judges – select individuals including AI academics, developers and entrepreneurs – we are proud to present the top prize winners amongst a community of Builders working on Trustworthy AI products and solutions.
<figcaption class="wp-element-caption">Projects pictured from left to right: Nolano, Sanative AI and Kwanele Chat Bot.</figcaption>
Top Prize Winner [$50,000]: Sanative AI provides anti-AI watermarks to protect images and artwork from being used as training data for diffusion models.
2nd Prize Winner [$30,000]: Kwanele Chat Bot aims to empower women in communities plagued by violence by enabling them to access help fast and ensure the collection of admissible evidence.
3rd Prize Winner [$20,000]: Nolano is a trained language model that uses natural language processing to run on laptops and smartphones.
Build-by-Build: Standing on the shoulders of giants
<figcaption class="wp-element-caption">Imo Udom introduces the keynote speakers to the stage.</figcaption>
“We’re existing in a unique and consequential time that is drawing huge emphasis on AI and catalyzing a movement towards more responsible development (something Mozilla is best known for) and it’s critical we act accordingly and influence where we can.”
Imo Udom, Senior Vice President of Innovation Ecosystems at Mozilla
The Responsible AI Challenge featured builders at various stages of their entrepreneurial and Trustworthy AI journeys: some were very early on and had never built a product before, others were seasoned entrepreneurs who were unfamiliar with Trustworthy AI, and still others were seasoned entrepreneurs who are already developing AI responsibly.
“Mozilla’s goal was for the judging process to be motivational for all candidates, inspiring them to continue developing responsible AI solutions in the future, even if they did not win,” says Britney Crooks, Director, Innovation and Product Strategy at Mozilla. “We asked that the judges raise key issues and considerations, while focusing on practical suggestions or alternative approaches for the applicants to address these issues.”
<figcaption class="wp-element-caption">Mozillians take part in a reception post-ceremony.</figcaption>
In addition to cash prizes, the top three Responsible AI Challenge winners will receive ongoing access to mentorship from leaders in the industry and to Mozilla’s resources and communities, as they continue to develop, refine and deliver their responsible AI projects.
We will be publishing more in-depth features on the upcoming projects on the Mozilla Hacks blog.
(“This Week in Glean Data” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean. You can find an index of all TWiG posts online.)
Recently I’ve been granted the role of “tech-lead” of the Glean SDK, where I find myself responsible for more of the direction and communication regarding Glean. As part of my continuing professional development, I sat down to read “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change” by Camille Fournier. The book focuses on several aspects of technical management up to and including managing several teams. I’d like to focus on the things that I took away from the book through the lens of my new role as tech-lead in this blog, most of which come from a couple of chapters in the book. Don’t take that as the rest of the content not being anything less than really good, only that I’m choosing to take a narrow focus. I felt it was more appropriate and personal to share what I took away from it related to my new responsibilities. I highly recommend this book to any contributor, management or otherwise, as it can give you great insight into what good (and bad) management looks like, with some really good examples that delineate the idealistic views from the realistic views of different situations. So, without further ado, let’s get started with the things I gleaned from this book through the eyes of a new tech-lead.
The definition of “tech-lead” offered in the Tech-Lead chapter was one I both liked and agreed with. Basically, tech-leads aren’t necessarily the most senior person on the team, they are someone willing to take on the set of responsibilities of representing the team to management, vetting plans, and dealing with project management details. Tech-leads focus on these things so that the team as a whole can be more productive. Now that I find myself the tech-lead of Glean, my productivity comes second to the overall team’s effectiveness. The book suggests that the best trick a tech-lead can learn is the ability to step away from the code and balance their technical commitments with the needs of the team. This balancing act is something that I’m still working on, and has meant being more deliberate in managing my schedule and including focus times to get things done.
Another topic from the same chapter is the defining characteristics of the role. This, unsurprisingly, includes the importance of communication. This is something that I already knew from past experience, but the book reiterated to me that taking the time to explain things and listening can be extremely helpful, even in roles with newfound expectations of our expertise. It also includes having a thorough understanding of the architecture of the project so that you can make informed decisions that take the project as a whole into consideration and be able to offer more constructive feedback to changes. This allows the tech-lead to be able to “lead” the technical decisions rather than “make” all of them. Sometimes a tech-lead isn’t the expert in a particular aspect of the project. It falls on the tech-lead to understand who on the team has the context and knowledge to make the best decisions and empower them to do so. The final key characteristic of a tech-lead is that they are first and foremost a team player. They shouldn’t be doing all the interesting work themselves, they should instead be looking at the tricky and boring things and figuring out how to get them unstuck. But they also shouldn’t be doing only boring work, either. Being a tech-lead does mean less time to work on code some days, so knowing what you can (and can’t) commit to is also vital; being able to delegate effectively is critical.
The book points out that being a tech-lead is about managing projects as well as the team’s efforts towards them. The distinction the book makes between these is that managing projects tends to be more about managing time and complexity, while managing the team is more about trust and mentoring. Both have a strong overlap on communication being a key part of the formula for success. A tech-lead needs to be able to communicate about projects to different stakeholders, both in a way that management understands and in the more technical communications with the theme. Being able to break down complex work into a series of deliverable tasks is only part of the picture. Knowing the level of detail that a particular project needs also plays into this because not every project needs the same level of project management. Ultimately, a tech-lead’s project management duties are about developing the discipline to think about something before diving into it and understanding how to structure the work so the team can better deliver on it.
Another chapter that I found tied in well with the tech-lead content that I’ve focused on so far is the chapter on “Mentoring”. Being a tech-lead is also about helping those around you reach their own goals, which means keeping up with regular one-on-one meetings with team members so that you can be aware of the challenges that they are facing and the successes they are having. This allows you to be able to provide guidance early and help unblock the team and to be able to call out these successes to management and peers. Being a tech-lead also means being open to the idea that you are now a source of feedback on career growth for your team. A willingness to share your insights into things that have helped you grow can help your teammates to identify areas they could potentially grow.
Finally, in the chapter on “Managing People” I found additional helpful information that tied in nicely with the other concepts that resonated with me in this book. This chapter mostly focuses on the importance of building relationships through trust and rapport, and how to clearly communicate your expectations. There’s also a ton of tips on how to improve these skills as well as how to structure and schedule your one-on-one meetings for success. I really appreciated the chapter mentioning how important it is to create a culture of continuous feedback. All of this points to the importance of communication and provides several useful examples of how to do it more effectively.
Like I mentioned before, the whole book is really well written with a great flow that builds upon each chapter. Each chapter is filled with great information for anyone in or considering a lead or management position. There’s a lot of very helpful communication and time management wisdom, even if you aren’t considering a leadership direction for your career. This blog post was purposefully scoped to my experiences, but I hope it was enough to encourage you to consider reading “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change” by Camille Fournier, it’s definitely worth it!
<figcaption class="wp-element-caption">Adam Bouhenguel has partnered with Mozilla to look for new ways to build ecosystems that support builders working on the next generation of the web.</figcaption>
More than ever, we need a movement to ensure the internet remains a force for good. This post introduces the Mozilla Internet Ecosystem (MIECO) program, which fuels this movement by supporting people who are looking to advance a more human-centered internet. With MIECO, Mozilla is looking to foster a new era of internet innovation that moves away from “fast and breaking things” and into a more purposeful, collaborative effort that includes voices and perspectives from many different companies and organizations.
Today, we’re highlighting the work of Adam Bouhenguel, who has partnered with Mozilla to look for new ways to build ecosystems that support builders working on the next generation of the web.
Adam Bouhenguel has been building things for a long time.
“As a kid, I would go to museums and fairs and see machines that people had built, or reproductions of famous machines throughout history, and then I would go home and build them out of Legos,” Adam said of his childhood in South Florida.
Once, a friend told him that their cousin built games on calculators, so Adam carried around programming books until he learned how to program. “I spent a lot of time writing the things that I wanted to play,” Adam recalled. “So that was always a strong motivator for me.”
Adam participated in programming and math competitions in high school. Before graduating, he interned at Motorola’s robotics group, where he developed software that ended up shipping with the company’s phones. Adam went on to attend MIT, during which he continued to work for Motorola.
“I realized how powerful tools can be,” Adam said. “If you have the right tools and the right ideas about what those tools should do, you can get much farther than you otherwise would.”
Adam’s love of technology and building found an early home at YCombinator in 2007, where he launched his first company with a goal of simplifying the process of building software for mobile phones. At the time, the iPhone had yet to be announced, and Adam was already thinking about ways to make things easier for creators and developers — a mission that he’s continued working on over the past 15 years.
Today, Adam is using his experience as founder and community advocate to work with Mozilla on new ways to support builders, researchers, and individuals who are ready to be part of a larger movement for change in the way that we build the internet.
When Imo Udom joined Mozilla as the senior vice president of innovation towards the end of 2021, he knew that building a future home for innovation that could expand on the growth of Mozilla’s past 25 years would require new models for thinking about the ways that we work together. In late 2022, Mozilla launched the inaugural cohort of the Mozilla Internet Ecosystem (MIECO) program, where Imo worked closely with Adam to understand the landscape that researchers, computer scientists, and creators were facing and identifying ways to support the changing dynamics of building technology. MIECO is an opportunity to shift the way that we think about building software from a single corporate model to one that is grounded in community and open collaboration.
Exploring new ways of collaborating is a theme throughout Adam’s work. His current MIECO projects, which include the Open Retrospective Contributor Agreement (ORCA), Metered.dev, and Research Portfolio, all seek to give developers and researchers new tools to share and iterate on their work. As more of the world gains access to the internet, Adam sees a need for different models for attribution and sharing in the value generated by different projects and ideas.
ORCA, which allows open source project maintainers to fund contributors, is just one example of an experimental new approach that may encourage more organizations and individuals to work in the open. Making sure that people’s respective work is acknowledged and valued, Adam says, will encourage innovation and translate to better products in the market. While ORCA is in its infancy, it shows promise in helping people shift their thinking about what the future of compensation might look for within technological ecosystems.
Adam believes that making it easier for developers to monetize their work will lead to more sharing of ideas, with the ultimate goal of creating better solutions for some of the most challenging problems that we’re facing as a society today. With that goal in mind, he created Metered.dev, a platform for developers to easily publish and charge for the software that they’re creating, and Research Portfolio, a way for researchers to record and reward the influential work that has shaped their own thinking.
Making sure that people’s respective work is acknowledged and valued, Adam said, will encourage innovation and translate to better products in the market.
Adam hopes that ultimately, people are inspired to think deeper about the software they choose to use.
“We’ll get to see what things are based on, what they’re inspired by,” Adam said. “We can give credit to these ideas that become software that we depend on and benefit from.”
Hello Thunderbird Family! After nearly 20 years, we are thrilled to share a completely redesigned Thunderbird logo that honors our history and vital connection to Mozilla, while carrying us forward into the next 20 years.
It’s no secret that after many years of being viewed as stagnant, Thunderbird is enjoying a resurgence. Our project is thriving with a renewed sense of purpose, and we see an invigorating energy bubbling up from our users, our community of contributors, and our core team.
Just like the software, the current Thunderbird logo has seen small, iterative improvements throughout the last 20 years. But now the software is evolving into something more modern (while retaining its powerful customization) and we believe it deserves a fresh logo that properly represents this revitalization.
But you should never forget your roots, which is why we asked Jon Hicks, the creator of the original Firefox and Thunderbird logos, to re-imagine his iconic design in light of Thunderbird’s exciting future.
Here’s a look at our new logo across Linux, Windows, macOS, Android, and iOS.
<figcaption class="wp-element-caption">Yes, we have officially added an iOS version of Thunderbird to our future development roadmap. Expect more concrete news about this toward the end of 2023.</figcaption>
And here’s a glimpse of what Thunderbird for Android will look like on an Android device, sitting next to our best friend Firefox:
When can you see it integrated with Thunderbird itself? Our plan is to incorporate it into Thunderbird 115 (code-named “Supernova“) this summer. During the next few months, we’ll also gradually redesign our website and update the branding on various social channels and communication platforms.
We understand that change can be uncomfortable, but we hope you agree this is a positive new look for the project. I encourage everyone to do what we did throughout this process: to live with the new design for a while. Let it breathe, let it sink in, and let us know what you think after a few days.
We all have a soft spot for the old Thunderbird logo (which I affectionately call the “wig on an envelope”), but our project is changing in big, positive ways, and we want to clearly show that to the world with a beautiful, revitalized logo and icon.
So here’s to a bright future! On behalf of the entire team: thank you for taking this journey with us. We wouldn’t be here without you.
Recently, I came across a post in one of my Facebook groups. This group is primarily women who juggle their job in the tech space while raising children. The post asked if people used multiple emails to limit exposure to account breaches and if so, they wanted advice on setting it up. First, I was surprised people cared enough to plan ahead for data breaches. I was also surprised at the responses, and I didn’t realize how much time people spend organizing their emails and online accounts.
I learned that, first, people didn’t mind having more than one email account to manage. Many people had several individual email accounts for personal, job search, kids school, travel and e-commerce. Some had an individual email address “strictly for bank/financial information.” Another person wrote: “Email addresses will always end up in breaches, sooner or later. The important part is to never, ever reuse the same password for multiple accounts and activate MFA (multi-factor authentication) whenever possible.”
I was curious, so I posted a similar question to my network of friends, previous coworkers and colleagues on LinkedIn. Sure enough, there were similar themes, even though it was on a different platform with different goals. Since LinkedIn is geared toward a more professional audience, the responses were focused on people who had their own consulting business, so separation of work and personal life was essential. Here’s what I heard back:
I have an insane amount of emails. Several for personal use. Most of my emails auto-forward to one of my main emails for ease. I have all of them, so I’m not giving out one personal email for everything.
I have one for my agency, one for my artistic hobbies (voice over and ceramics), one for general junk email and one for professional stuff that doesn’t fall into the other categories. It’s kind of a lot, but I feel more organized that way. All are hosted by Gmail and I also have two custom domains.
I have social, banking, spam/shopping, I check none of those, then separate for personal but professional and then personal where friends and travel stuff go, and I actually occasionally check the last 2. I also have one for each of my businesses and of course work email. I barely ever check any inbox, and that’s a whole another thread.
It makes total sense for people to have separate email accounts. So, I wondered if there was an easier and better way to manage those emails AND protect your personal information from data breaches. I turned to Firefox Relay, a service where you use email masks instead of your true email address to prevent emails from clogging up your inbox.
Naming it is the key to keeping it organized
I recently started using Firefox Relay after hearing about the latest update which included its integration in Firefox. How it works: Whenever I visit a site and get prompted to sign up and share my email address, I can use one of my Firefox Relay email masks or create a new one. It is super easy to use.
Last month, I signed up for new accounts that needed my email, examples like requesting I get notified when there was a high pollen count in my area and shopping for a new summer hat, so I used Firefox Relay. I can get up to five free email masks. Did you know that you could label each email mask? This allows you to easily tell who is reaching out and how they got your contact information. It’s simple: You go to the Firefox Relay dashboard to write each label associated with each mask, like shopping, information or travel.
Plus, you can quickly go to the Firefox Relay dashboard through the Firefox Relay add-on, which gives you a shortcut. Then, you can continue to reuse those email masks. This seems like the perfect solution for people who want to organize their email accounts and have all their emails in one inbox.
Tackle more stuff with the latest Firefox Relay add-on
Recently, we added new features to the Firefox Relay add-on. You can now see it in your toolbar for every site, reusing existing masks and generating a new random mask.
Firefox Relay Premium users can instantly create custom masks through the Firefox Relay add-on. For example, if you have a banking or financial account, you can call it banking@mozmail.com, and add a label like finances.
Whether you have a few or many email addresses, this is an easy way to manage them, and it comes from a company you can trust. Mozilla has a long-standing history of creating privacy-first products that people use and know their information is safe.
The Firefox Relay add-on is available for Firefox, Chrome and Firefox for Android. Try out the free version for yourself!
Funding will grow the startup’s tech team, help make gig work more transparent
(UNITED KINGDOM | MAY 18, 2023) – Today, Mozilla Ventures is announcing a new investment and its first in the United Kingdom: Rodeo, an app that makes the gig work ecosystem more transparent for gig workers.
Rodeo helps workers access and control their data, providing critical insights like earnings over time and pay rates across different gig platforms. The app also allows its users to chat with fellow gig workers and swap valuable learnings and tips. Rodeo is used by more than 10,000 delivery drivers from Deliveroo, Uber Eats, and Just Eat.
Gig work is a rapidly-growing sector, with an estimated 4.4 million gig workers in the UK and likely more than 1 billion across the world. While gig work platforms have played a crucial role in unlocking economic opportunity, they have also come under fire for exploitative behavior.
Mozilla Ventures is a first-of-its-kind impact venture fund to invest in startups that push the internet — and the tech industry — in a better direction. Mozilla Ventures isn’t publicizing its investment amount at this time. Rodeo has previously received investment from LocalGlobe and Seedcamp.
The funding will help expand Rodeo’s tech team and also defend users’ legal rights to access and portability of their data — two vital mechanisms for earning a living in the gig economy.
Says Alfie Pearce-Higgins, Co-Founder of Rodeo: “Mozilla has always fought for interoperability and user agency. That’s why we are excited to work with Mozilla Ventures as we continue to empower gig workers and ensure their rights of data access and portability as enshrined in GDPR.”
Says Mohamed Nanabhay, Managing Partner of Mozilla Ventures: “Mozilla Ventures’ mission is to fuel companies pushing the tech industry in a better direction — companies that respect users, and that empower them with their data. Rodeo exemplifies these principles.”
Says Champika Fernando, who leads Mozilla’s Data Futures Lab: “The scales of the gig economy are currently tipped very much in favor of the platforms, not the workers. By addressing the way data is governed, we attempt to balance the scales and make the gig economy more equitable.”
Rodeo will join a cohort of other mission driven startups that Mozilla Ventures has invested in, including SAIL, heylogin, Lelapa AI, Themis AI, and Block Party. Mozilla Ventures launched in 2022 with an initial $35 million in funding.
The declarativeNetRequest (DNR) extension API is now available to all extensions starting from Firefox 113, released last week. Extensions with functionality that can be expressed in terms of declarative rules are highly encouraged to transition to the DNR API. Documentation is available at declarativeNetRequest (MDN).
DNR allows extensions to declare rules that describe how the browser should handle network requests. These rules enable Firefox to process network requests without involving the extension further. In comparison with the blocking webRequest API, this offers the following benefits:
Privacy: Blocking network requests without host permissions. DNR offers more privacy by design because extension code does not get direct access to the request details. Thus request blocking functionality can be offered without requiring scary host permissions. This feature is especially useful in Manifest Version 3, where host permissions are available on an opt-in basis.
Performance: Network requests are not blocked on extension startup and response. DNR rules are evaluated independent of extension scripts. A background page is therefore not required. This characteristic is especially important for the reliability of extensions on Android, because the Android OS may terminate the background page outside of the control of the extension and browser.
Cross-browser: DNR is the only extension API for handling network requests that is available across the major browsers. Other than Firefox, DNR is also supported by Safari and Chromium-based browsers such as Chrome and Edge.
Some extensions require more flexibility than DNR offers, and we are committed to supporting both the DNR and blocking webRequest APIs to ensure that Firefox users have access to the best privacy tools available.
What’s next
The DNR implementation is not final. We are working on further optimizations and additional functionality, which are tracked as dependencies of bug 1687755. Our work is not limited to Firefox; where it makes sense we try to establish cross-browser consensus in the WebExtensions Community Group (WECG), as seen at WECG issues with topic:dnr.
Stay Up to Date and Informed On the Topics You Care About
Pocket’s latest updates make it simpler than ever to discover and organize high-quality content that aligns with your unique interests and passions. As you may have noticed, Pocket has been rapidly evolving and growing; we’re listening to our users so that we can continue to make Pocket the go-to destination to stay informed and keep up to date with the topics you love. Starting today, Pocket is rolling out a new mobile and web experience so you can easily find the stories and topics you care about. In addition, Pocket is launching a new feature called Lists (at launch just on web, with the feature coming to Pocket mobile later this year), which will make it simpler to organize saved content.
Pocket iOS: A new home to quickly discover and save content
For over a decade, Pocket has been a place where millions of users stay in the know without falling into a rabbit hole. Our latest iOS update makes it easier to keep up to date while on the go with personalized recommendations and more discovery content, as well as an intuitive user interface so you can quickly catch up on topics you care about.
Since we first released Pocket on iOS in 2009, a tremendous amount has changed about what makes for a compelling app experience. We always knew at some point that in order to move forward, we’d need to break new ground and start fresh. Last year, we made the decision to start over and build a new version of the iOS app with the goal of enabling quicker feature development as a primary objective.
With the launch of the latest version of Pocket on iOS (available once you download iOS 16 on your iPhone), the redesigned app will be faster and simpler to use with a focus on a new Home experience – a starting off point for visiting everything in Pocket, from your saved content to the articles and Curated Collections we think you’ll love. We will be continuing to build on Home to provide you with different perspectives on what you’ve saved and what you’ve discovered, as well as topics like Best of the Web, Editors’ Picks, In Case You Missed It, and more.
The new redesign also includes a simplified navigation and settings screen, creating a more enjoyable user experience. The new Saves tab (formerly My List) will have an updated design, making it even more streamlined and giving Pocket users one place to access features like search, and listen, as well as to view your tagged items and favorites. We’ve also made it easier to archive items with a swipe.
Your favorite features are getting better
At the time of this release, you may have noticed that some features are missing. Fear not, friend! In a handful of cases—e.g. the feature that allows you to highlight articles—the Pocket product team is working hard to bring back the missing features to continue enhancing our user experience.
In a few select cases, we did remove a feature from the app permanently in order to make room for new or improved experiences. For example: the feature that allowed you to make recommendations to other Pocket users to make way for the new Lists feature. Letting users share content is an important part of what makes Pocket useful, so we are actively investing on improving this experience.
At the end of the day, all this means is that your favorite features just became a little faster and easier to use!
What’s next for Pocket on iOS?
Moving forward, Pocket on iOS will be updated every two weeks. In the next few months, we’ll be bringing back the ability to create and view highlights on your saved articles, improving the quality of the articles that we recommend to you, and bringing additional functionality to our Listen feature, through which you can listen to your saved articles.
Pocket on the Web: Create your own Pocket Lists
Starting today, users in the U.S. can create private lists on the web version of Pocket, where they can collect their saved articles, videos, and websites. Users will be able to create and manage multiple lists on their Pocket web experience, give them a title and description, add or remove items, and easily switch between lists as they browse their saved content. Pocket Lists make it easier to find and consume content that matters most.
“The new Pocket Lists feature will offer users a more intuitive way to organize their content, and unlike tags, which can sometimes be difficult to manage, Pocket Lists provide a more structured approach to categorizing content,” said Kait Gaiss, Pocket’s head of product management. “We’ve received many requests from Pocket users who wished to create Lists to organize their content, so we are excited to release this new feature to meet their needs.”
Some examples of Lists you can make include:
keeping track of your favorite recipes
saving content like videos and memes that bring you joy
building a travel guide for your upcoming trip (with history, culture and sites to visit)
creating a how-to guide for DIY projects around your home
tracking articles on career planning that you want to visit again and again
How to create your own Lists on Pocket for Web
To create a new list in Pocket, follow these steps:
Click Saves at the top of the screen.
Click the “+” sign next to Lists in the menu on the left-hand side of the screen (or click the Create List button in the top-right side of the screen).
In the panel that appears, give your new list a name and a description.
Click the Create List button to finish.
All of your lists will appear under All Lists in the panel to the left.
Add items to your list
Click on Saves in the top menu to view all of your saved items
Locate the item you want to add to a list and click the three dots at the bottom right of the card
Click Add to list from the available options.
The Add to List panel will open next. Select a list from the drop-down menu.
Click Save to List to add the item to your selected list.
Manage your lists
To manage your lists Click All Lists in the menu to the left. All your lists will be displayed here.
To remove an item from a list
Click All Lists in the right-hand panel to view all of your lists
Select the list that contains the item you wish to remove
Find the item you want to remove from the list and click Remove at the bottom right
Delete a list
Click All Lists in the menu on the left-hand side of the screen to view all of your lists.
Locate the list you want to delete and click the Delete button
Click Delete again in the prompt that appears next. Deleting a list cannot be undone
While the initial launch is just for U.S.-based users and on the web version of Pocket, we will open up to Pocket users worldwide this summer. Coming soon, Pocket users will be able to add multiple items to a List at once, as well as adding notes to the items in their Lists (a feature that has been requested by many Pocket users so they can remember why they added that item to their List!). And later this year, Pocket users will be able to publish and share their Lists with their family and friends, and, as mentioned previously, while it is only available on the web at launch, the Lists feature will also roll out in Pocket on mobile.
Pocket Android: Reading your favorite articles just got easier
We’re releasing new features for Reader that will help you enjoy your Pocket experience more!
Love reading articles that you Pocketed from your favorite news sites, but hate having to log in each time you try to access those articles? Say no more! Pocket will now save your login info so that you don’t need to sign in each time you go to a website to see content you’ve saved when you visit those sites through the Pocket app.
The ability to use the Previous-Next buttons in Article View will make it easier for Pocket users to continue enjoying their saved content without having to return to your Saves list.
The ability to use the Previous-Next buttons for all your saves regardless of viewing in Pocket or going to the original site will make it easier for Pocket users to continue enjoying their saved content without having to return to your Saves list.
Reading articles on an Android tablet is now more efficient with text that is optimized for wide screens.
All of these updates are a culmination of Pocket’s Android updates, which started in January of this year.
What’s ahead for the rest of 2023
In the coming weeks and months, we’ll have more news and updates to share from Pocket. If you’re interested in staying in the know, join our mailing list!
Cybersecurity incidents and attacks have been on the rise in the past years. Enhancing security and trust is more relevant than ever to protect users online. Legislators worldwide have been contemplating new rules to ensure that hardware and software products become more secure, with the latest example being the EU’s Cyber Resilience Act. Below we present our concrete recommendations on how legislators can ensure that the CRA can effectively achieve its objectives.
In recent years, the European Commission has taken concrete steps to boost its cyber security capabilities across Europe. After successfully adopting the NISD2 and the EU Cybersecurity Act, the last missing piece of the puzzle is the Cyber Resilience Act (CRA). This latest proposal aims to bolster the security capabilities of hardware and software products in the EU market while ensuring a more coherent framework that facilities compliance.
At Mozilla, we believe that individuals’ security and privacy online and a safe Internet overall can only be guaranteed when all actors comply with high cybersecurity standards. We are constantly investing in the security of our products, the internet, and its underlying infrastructure. Therefore, we welcome and support the overarching goals of the CRA. To realize its full potential and achieve its objectives, we call on legislators to consider the following recommendations during the upcoming legislative deliberations:
Clarify ‘commercial activity’ for open-source software – free and open-source software promotes the development of the internet as a public resource. Many open-source projects (like Mozilla’s products) have commercial characteristics (i.e., provided in exchange for a price) and, therefore, should abide by the CRA rules. However, there are several open-source projects that will be unintentionally captured by the CRA obligations. For example, merely charging a small fee for the technical support of the freely provided software to fund the financial existence of such projects should not be considered a commercial activity.
Align the proposal with existing EU cybersecurity legislation – given the number of legislative initiatives the EU’s cybersecurity package has introduced in the past years, legislators should ensure that obligations around reporting incidents, timeframes, and competent authorities remain aligned across different laws. Such discrepancies can lead to confusion at a time when the efficiency of reporting cybersecurity incidents is paramount.
Refrain from disclosing unmitigated vulnerabilities – Mozilla has long advocated for reforms to how governments handle vulnerabilities. Stockpiling vulnerabilities can result in abusive use from governments themselves but also from malicious actors. Policies that mandate the disclosure of unpatched vulnerabilities should be scrutinized carefully. Even if well-intended, we believe that sharing such vulnerabilities with governments creates more risk than it solves.
Clear, proportionate, and enforceable rules are the way forward to achieve cyber resilience of digital products and, eventually, safety for all Internet users. We look forward to working closely with policymakers to realize these goals.
We’re back with another progress report as we continue improving K-9 Mail for its transformation to Thunderbird for Android! We spent most of the previous month preparing for a new stable release. In April 2023, we finally published K-9 Mail 6.600.
(By the way, if you missed the exciting news last summer, K-9 Mail is now part of the Thunderbird family, and we’re working steadily on transforming it into Thunderbird for Android. If you want to learn more, check out our Android roadmap, this blog post, and this FAQ.)
K-9 Mail 6.600
Along with a couple of new features, a lot of changes and bug fixes went into the new K-9 Mail version. However, space for release notes in app stores is very limited. So we went with this list of changes:
Redesigned the message view screen; tap the message header containing sender/recipient names to see more details
Added a setting for three different message list densities: compact, default, relaxed
Added better support for right-to-left languages when composing messages
Search now also considers recipient addresses
Fixed a bug where notifications would sometimes reappear shortly after having been dismissed
IMAP: Fixed a bug where sometimes authentication errors were silently ignored
Various other small bug fixes and improvements
Missing home screen widgets
After learning that an old bug in Android had finally been fixed in 2021, we changed the app to disable home screen widgets by default and only enable them after the user had added at least one account to K-9 Mail. Of course we limited this to Android versions that should include the fix. However, this didn’t quite work as intended and existing home screen widgets disappeared on some devices. So we reverted the change in K-9 Mail 6.601.
K-9 Mail 6.7xx
With the stable release out the door, it was time for a new series of beta releases to test early versions of features and fixes that should go into the next stable release.
Bug fixes
The first beta version (6.700) didn’t include any new features, but fixes quite a few bugs (mostly obscure crashes).
IMAP ID extension
The GitHub user wh201906contributed code to add support for the IMAP ID extension (thank you). It is used by an email client to send information about itself to the IMAP server. In turn, the server responds with some information about itself (name, software version, etc).
Unfortunately, some email providers reject clients not using this extension, even though the specification explicitly states the extension must not be used for that purpose. To make K-9 Mail work with such email providers without users having to change a setting, we decided to enable this functionality by default. Also, because we want to align our default values with Thunderbird, and it’s enabled there by default.
The information sent to the server is limited to just the app name – “K-9 Mail”. If you wish, you can disable this feature under Settings → <Account> → Fetching mail → Incoming server → Send client ID.
Next: Improved account setup
The main goal for the next stable release is to improve the account setup experience. Many new users are struggling with setting up an account in K-9 Mail. That’s because K-9 Mail only supports automatic account setup for a handful of large email providers. For all other email providers users have to manually enter the email server settings. And this can be a very frustrating experience.
Ideally, users only have to provide their email address and the app will figure out the rest. We’ll be adding support for Thunderbird’s Autoconfig mechanism which aims to deliver just this user experience.
Hopefully, we’ll be able to ship a first version of this in a beta release in May.
Releases
In April 2023 we published the following stable releases:
The GPG key used to sign the Firefox release manifests is expiring soon, and so we’re going to be switching over to new key shortly.
The new GPG subkey’s fingerprint is ADD7 0794 7970 0DCA DFDD 5337 E36D 3B13 F3D9 3274, and it expires 2025-05-04.
The public key can be fetched from KEY files from the latest Firefox Nightly, keys.openpgp.org, or from below. This can be used to validate existing releases signed with the current key, or future releases signed with the new key.
About five years ago Mozilla shipped Firefox Quantum, an upgrade that included significant performance improvements for most Firefox users. Unfortunately, Firefox Quantum didn’t improve performance for people who use screen readers and other assistive technology. In some ways, our screen reader performance actually regressed with the architecture changes that Quantum delivered.
The Firefox accessibility engineers remedied much of that performance regression in the late twenty-teens, but by 2020 they’d done all they could to keep up. Continued investment in the old architecture simply wasn’t going to be enough to maintain a competitive browser so we began planning a re-write, which became a project called Cache the World. This upgrade changes the way things work in Firefox’s accessibility code so that screen readers and other assistive technologies have fast access to the content they need.
Today, with the release of Firefox 113, those improvements are available to all Firefox users on Windows, Mac, Linux, and Android.
Browsers are more complicated today than when Firefox’s accessibility engine was first designed, and the most significant overall change has been the move to security-isolated, multi-process architectures. With multiple isolated processes, screen readers had to do a lot of expensive work to retrieve and relay content to users. We were inspired by Chrome’s approach and extended it to improve Firefox’s accessibility performance; Firefox now provides a cache of all tab and browser UI content to screen readers in the browser’s parent process, where it can be used quickly and very easily.
This blog post by accessibility tech lead Jamie Teh provides more context and technical details on the project, but the largest impact you’ll notice immediately is speed. For some of the worst use cases — like pages with very large tables — Firefox now performs up to 20 times faster, and we’re clocking other very large pages at 10 times faster! However, even for the most everyday actions, like opening and closing a Gmail message or switching channels in a Slack window, the performance is 2 to 3 times better.
This upgrade shipped for Android last year in the Firefox 102 release, for Windows and Linux in the Firefox 112 release, and today it arrives on MacOS, which completes our rollout to all Firefox platforms. We’re very excited to be delivering this performance and stability improvement to you all, and we’re eager to hear your feedback and answer questions. Please let us know what you think about these changes in a comment on this post, and if you’ve found something broken, report it in a Bugzilla ticket. Got a completely different idea for making Firefox accessibility better? Please join us on and share via Mozilla Connect.
– Asa Dotzler, on behalf of the Firefox accessibility team: Jamie Teh, Eitan Isaacson, Morgan Rae Reschenberg, Anna Yeddi, Nathan LaPré, and Kim Bryant
A few years ago, Thunderbird was in survival mode. Our dedicated core team, passionate community of users, and generous donors kept Thunderbird alive during some difficult times. Then, just last May, we happily reported that Thunderbird’s financial outlook was steadily improving: our 2021 income had increased by 21% over 2020, and by more than 100% over 2018.
But we are not content merely surviving. Our mission is to build the best email client and personal information manager available. To build professional software that puts your privacy first. To craft an experience that boosts your productivity, compliments your daily workflow, and meets your customization needs. And to expand the Thunderbird experience to Android and iOS. And to do all of this transparently, guided by the values of free and open source software.
Donations In 2022
Last year, our mighty donor base – representing approximately 300,000 daily users – contributed a total of $6,442,704 in donations to the Thunderbird project. (Note: user donations represent more than 99.9% of our annual revenue.) Our 2022 donation income was a bright, assertive sign that you also believe in that mission, and you also want to see Thunderbird thriving. Not just in 2023, but decades into the future!
This is nothing short of outstanding, and we are tremendously grateful for the generous donations of our users. Below, we’ll talk about what this enables us to do in the future, and how we spent some of that income in 2022.
Before we discuss that, you might be wondering what we did differently to generate such a significant surge of support last year.
At the end of 2021, we decided to make a bigger investment in communicating with you. That meant more frequent blog posts and newsletters, daily engagement across our social media channels, and expanding the number of places we interact with you (like our relatively new Mastodon account).
We also attribute this amazing uplift to the release of Thunderbird 102, as well as a first-of-its-kind, in-app donation appeal at the end of year.
In short, we learned that projects like ours can benefit greatly from simply asking for donations, while simultaneously explaining how those donations will benefit the project – and ultimately, how they will benefit you. So let’s talk about that!
Thunderbird’s People And Thunderbird’s Future
The heart of Thunderbird is obviously its people, and we invested heavily in personnel last year. We began 2022 with 15 core staff, and now employ a team of 24 in these roles:
Product and Business Development Manager
Director of Operations
Product Design Manager
Engineering Manager
Staff Engineers (3)
Sr SW Engineers (2)
Sr Security Engineer
SW Engineer, Add-Ons Ecosystem
Sr UI/UX Developer
UI/UX Developers (2)
Android Project Lead
Android Developer (1)
Build & Release Engineers (2)
Full Stack Developer
Front End Developer
Community Manager
Marketing Manager
Bug Triager
Support Engineer
The breakout growth we enjoyed last year means hiring even more talented people to vastly improve the Thunderbird desktop experience. This past year we expended significant effort to dramatically improve Thunderbird’s UX and bring it in-line with modern expectations and standards. In 2022 we also laid the groundwork for large architectural changes for Thunderbird on the desktop. These changes address many years of technical debt that has limited our ability to add new features at a brisk pace. This work will largely pay off in our 2024 release, however it does power some of the improvements in the 115 “Supernova” release this summer.
But we’re also building beyond the desktop, to provide you with a truly cross-platform, synergistic experience. Last summer we invested in the K-9 Mail Project, which is being steadily improved in its transformation to Thunderbird on Android. And yes, we’re almost ready to add an iOS version to our roadmap! Later in 2023, we’ll hire an iOS developer to begin creating the foundation for Thunderbird on iOS.
Thunderbird is also expanding beyond the core experience you already use. We’ve been exploring additional sources of revenue in the form of new tools and services to increase your productivity. We’re planning to introduce some of these, in Beta status, later this year. Rest assured that we have no plans to charge money for the powerful Thunderbird experience you enjoy today (nor do we plan to remove features and charge for them later).
Total Spending In 2022
The Thunderbird Project’s total operating expenses for 2022 was $3,569,706. While personnel is where most of our money is spent, there are other areas crucial to Thunderbird’s continued operation. Here’s an overview of our total spending in 2022:
Professional Services are things like HR, legal and tax services, as well as agreements with other Mozilla entities to provide technology infrastructure and operational resources.
The remaining items help us to run the business, such as the services and technology we use to communicate and manage operations, insurance, bank and donation processing fees.
Closing Comments
The state of Thunderbird’s finances is strong. But that doesn’t make our team complacent. We are careful stewards of the thoughtful donations we receive from you. We don’t just use it to enhance features; we invest it strategically towards ensuring long-term stability and viability of Thunderbird. Having healthy cash reserves ensures the long-term sustainability of Thunderbird, even during periods of economic instability.
Your ongoing financial gifts have enabled Thunderbird to go from surviving to thriving. But as it has been since 2003, Thunderbird’s future is in your hands. Please continue to donate, and we will continue to build software you can be proud of.
Thank you,
Ryan Sipes Thunderbird Product and Business Development Manager
Last March, during the SXSW festival in Austin, Texas, Mozilla issued a call to builders and technologists all over the world to create trustworthy AI solutions when we relaunched the Mozilla Builders program and unveiled our Responsible AI Challenge — a one-day, in-person event designed to inspire and encourage a community of builders working on trustworthy AI products and solutions.
The future of AI is promising! And there are those, like Mozilla, who believe in its power and potential to solve the world’s most difficult challenges. Nonetheless, we also recognize its risks and advocate for and contribute to the responsible development of AI for the betterment of society. Ultimately, we believe that responsible AI – technology that takes into consideration accountability, user agency, and individual and collective well-being – is demonstrably worthy of trust.
Challenge accepted! Announcing our top 10 finalists
After weeks of reviewing hundreds of competitive consumer technology and generative AI projects, it is with great pleasure that we announce our top 10 challenge finalists. The finalist selection process was made possible by a panel of select individuals including AI academics, developers and entrepreneurs. We’re deeply grateful to the panel for sharing their time, insight and expertise, and Mozilla is honored to share resources with and work alongside the final challengers and their projects listed below:
Micro Adventures is an AI-powered app that combines gamified local learning adventures for parents and kids.
Droomverhalen (Dutch for ‘dream stories’) is an AI-based story generator that enables parents to craft unique and personalized stories for their little ones.
LivePose Portal trains participants and deep-learning models for camera-based group interactivity in the immersive arts.
Nolano is a trained language model that uses natural language processing to run on laptops and smartphones.
Kwanele Chat Bot aims to empower women in communities plagued by violence by enabling them to access help fast and ensure the collection of admissible evidence.
Simprints is developing privacy-preserving, unbiased face biometrics with AI for NGOs and governments in global health and humanitarian programs.
Quirk is building game-based virtual worlds where children learn character building skills with the help of AI guidance and through play.
Visually Impaired Assistant System is a multi-disciplinary AI project that aims to improve accessibility for the visually impaired community.
Blind AI provides a confidential deployment solution for LLMs, in order to enable the protection of sensitive data when leveraging AI SaaS solutions.
Sanative AI provides anti-AI watermarks to protect images and artwork from being used as training data for diffusion models.
What’s in San Francisco? A golden state of mind.
Esteemed builders and technologists will join each other in San Francisco on May 31 for a day of discovery and celebration as we showcase some of the most innovative and responsible uses of AI to date, learn from industry thought leaders, and discover the future of AI together.
In addition to cash prizes, the top three Responsible AI Challenge winners will receive ongoing access to mentorship from leaders in the industry as they continue to develop, refine and deliver their responsible AI projects.
“Mozilla is in great company working beside other organizations and individuals committed to responsible innovation and ensuring the future of AI is one that provides ethical solutions that benefit humanity. We’re already blown away by the caliber of applications we’ve gotten and are grateful for the community support we’ve received from folks like Craig Newmark Philanthropies and others who have stepped forward to make this challenge a reality.”
Imo Udom, Senior Vice President of Innovation Ecosystems at Mozilla
Meet our judges and speakers
The event will feature keynotes from Margaret Mitchell, chief AI ethics scientist at Hugging Face who was also recently named one of Time’s Top 100 Most Influential People, and Gary Marcus, Emeritus Professor of Psychology and Neural Science at NYU and bestselling author. We’ll also introduce a special guest!
Finalists will have the opportunity to pitch in front of a panel of judges with combined expertise in technology, entrepreneurship and ethics.
Margaret Mitchell, Speaker
Margaret is the Chief Ethics Scientist at Hugging Face, with deep experience in ML development, ML data governance, and AI evaluation.
Gary Marcus, Speaker
Gary is the Emeritus Professor of Psychology and Neural Science at NYU and the author of five books, including New York Times Bestseller Guitar Zero.
Raffi Krikorian, Judge
Raffi is an Armenian-American technology executive and the CTO of the Emerson Collective.
Lauren Wagner, Judge
Lauren is an early-stage investor and Fellow at the Berggruen Institute.
Ramak Molavi, Judge
Ramak is a digital rights lawyer and has led the “Meaningful AI Transparency” research project at Mozilla since 2021.
Raesetje Sefala, Judge
Raesetje is an AI Research Fellow at the Distributed AI Research Institute (DAIR).
Damon Horowitz, Judge
Damon is a technologist, philosophy professor and serial entrepreneur.
James Hodson, Judge
James is the CEO of the AI for Good Foundation, which is building economic and community resilience through technology.
Deb Raji, Judge
Deb is a Nigerian-Canadian computer scientist and activist working on algorithmic bias, AI accountability, and algorithmic auditing.
Welcome back to the ThunderCast, the official podcast of Mozilla Thunderbird! In this episode, we’re thrilled to welcome our first special guest: Mike Conley, Principal Software developer at Mozilla. Mike is a software mechanic, musician, livestreamer, and self-described “pre-internet phenomenon” among many other awesome things.
We had a wonderful, energetic conversation about the early days of the internet, Mike’s early work on Mozilla Messaging, and his current work on Firefox. He also gives us a peek behind the curtain of upcoming Picture-in-Picture features, and some fresh changes to Firefox’s migration tools.
We also asked Mike about some of the more underrated features of Firefox. Plus, we get the community involved by asking you which Thunderbird features more people should know about.
Hope you enjoy listening to this one as much as we enjoyed recording it!
We include a full transcript of the episode inside the podcast metadata, which should be supported by your podcast app. If it’s not, here’s a direct link to the Episode 2 transcript.
Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.
Are you a locale leader and want us to include new members in our upcoming reports? Contact us!
We also want to welcome Ayanaa Rahman to the localization team. She’s joining us for an internship as a backend software engineer, and you’ll see her active primarily around Pontoon. Here’s a few words from her:
Hi all, I’m Ayanaa Rahman. I recently completed my third year studying Computer Science at the University of Toronto. I have also worked at financial institutions in both the US & Canada as a Software Developer intern, focusing on automation and big data.
Born into an immigrant family and raised in the multicultural city of Toronto, I’ve been exposed to multiple languages and cultures throughout my life. This experience has highlighted the importance of effective communication across different languages, particularly to enhance people’s digital experiences. I am eager to leverage my background and skills to make a meaningful contribution to the Mozilla community.
New content and projects
What’s new or coming up in Firefox desktop
Firefox 113, shipping to release users on May 9, is going to include a new locale: Tajik (tg). Huge thanks to Victor Ibragimov, the locale manager, and all other community members for achieving such an impressive result. Victor has been amazing over the last months, both online and offline, in finding resources and promoting the Tajik language.
In terms of new features, developers are currently working on the workflow to import data from other browsers, and we expect an overall increase in the number of strings around messaging and onboarding. Keep an eye out on notifications in Pontoon for updated testing instructions.
Fonts and fingerprinting
Firefox developers are working on reducing the ability for websites to track users based on their browser “fingerprint”, and fonts are one of the characteristics that bad actors can use to uniquely identify your browser.
By restricting access to only fonts pre-installed with the operating system, this form of fingerprinting becomes much less effective. The challenge is that it could impair the experience for users that access content in other languages, as they might rely on fonts installed through other systems (e.g. OS language packs).
Given how large the number of possible scenarios is, the team working on this feature needs help from the localization community to ensure user experience is not degraded. This document contains detailed information about the feature, how to test it and how to report errors.
What’s new or coming up in mobile
Things have been moving quite a bit in mobile land since our last report in January – especially with the past couple of versions leading up to the next v114 (in Nightly right now) – which all feature some notable updates.
A reminder that the last day to get translations in for version 114 is May 28 (all strings for this version should have landed by May 5th approximately).
One thing you may have noticed are the experiments going on these days both in Firefox desktop and mobile (often labeled as “Nimbus” in localization comments and string IDs). For mobile, we have been playing around with onboarding cards, as we suggest new users to change their default mobile browsers to Firefox.
Other notable updates are:
Users can now choose whether to be asked every time they open a link that would open in another app
Websites that use window.print() can now be printed in Firefox for Android
Improvements to Credit Card Autofill
Cookie Banner Reduction/Blocking: this new feature aims at providing users a seamless browsing experience by drastically minimizing cookie banner annoyance while also delivering the most private and secure option to handling the cookie banners
Now on to some community highlights: on mobile, Tajik (tg) has recently shipped at 100% complete translation on Focus for Android browser, making it the third browser available to Tajik speakers: Firefox for desktop, Firefox for Android, and now Focus for Android. As mentioned previously in this newsletter, congratulations to Victor and his team for sustaining this work – and the community – across the board! We look forward to the local initiatives taking place in Tajikistan in the near future, expanding the open, free and accessible internet in the region.
Amharic (am) has also recently shipped entirely localized versions of Firefox for Android, Focus for Android and Focus for iOS. Congratulations to the team who has worked relentlessly on keeping these projects up to date as well as growing the community.
Sardinian (sc) also recently initiated and completed Firefox for Android localization, as an ongoing effort in their existing projects. And Persian (fa) locale has been ramping up with projects thanks to locale manager Reza and fellow translator MSKF.
We want to take the opportunity to remind folks that Firefox for Android has an in-app language switcher, which works independently from the native Android OS language options. It generally supports a larger set of languages than the Android system language settings does. Head over to your Firefox for Android “Settings > Language” to discover 100+ languages available. (Taking the opportunity to note that a language switcher also exists within the Mozilla VPN settings, which seems to be a feature overlooked by many).
What’s new or coming up in web projects
Relay Website
As you may have noticed, the app.ftl file is no longer in Pontoon. In place are multiple, feature oriented files. The goal is to make each file more modular so it gives more context where strings land in the product. And it also offers flexibility to provide regional specific strings. There will be a few more of these efforts in the future. If the strings were localized prior to the migration, they are already moved to the new file, including contribution history. No need to go in to retranslate them. If there are untranslated strings, they are brand new strings.
Mozilla.org
This is a heads-up. A few pages from the Relay Website project will be migrated to mozilla.org. Pages to be migrated include faq.ftl and landing.ftl. Like the previous migrations, the Pontoon team will do their best to preserve the work you did, including attributes to each of the localized strings, approved or pending for review. For locales that have not localized the Relay product, you will see an increase in untranslated strings. You can prioritize these sets of files against others.
The migration is scheduled to be complete before the next l10n report. The purpose of this migration is for better search ranking. A link to the Relay pages will be added to the navigation bar.
Firefox Accounts
The Firefox accounts team are undergoing work to improve the user experience around account authentication and data recovery. Some changes are already in progress, and going forward you should see more strings related to two factor authentication, account recovery, password resets, and more. Many of these changes can be viewed before changes go to staging or production by checking Storybooks which can show English strings in context. The link to Storybooks can be found under the resources section of Firefox Accounts within Pontoon.
Watch the recording of our community call in March if you haven’t already to learn more about SUI (Simplified User Interface) screenshot that Lucas shared.
It’s also highly recommended to watch our community call in April to catch up on the result of the contributor survey we’ve done in Q1.
If you’re a Social Support or Mobile Store Support contributor, make sure to watch the contributor forum to get updates about queue stats every week. Kiki will post the update by the end of the week to make sure that you’re updated. Here’s the latest one from last week.
You can now learn more about Kitsune releases by following this Discourse topic.
What’s new or coming up in Pontoon
Pretranslation
We have successfully completed the Alpha testing phase of the Pretranslation feature with the Italian and Slovenian locale. The results, especially when accounting for the bugs fixed during the testing period, were quite promising:
51.62% pretranslated strings were approved without changes.
Between April and June 2023, Pontoon Pretranslation feature will be in the Beta testing phase with a total of 9 participating locales. In case of a success, we expect to make the feature available to more locales soon after. Stay tuned!
New contributions
Thanks to our army of awesome contributors for recent improvements to our codebase:
Willian, who joined the project last year, landed 10 additional patches(!) recently, including making the All contributions view the new default view on the Profile page.
Ivan added support for reading project configurations from the repository. (Ivan, sorry it took forever to review it!)
We have neglected our Pontoon documentation for a long time, and unfortunately it shows. We’re actively working on updating it, and we plan to wrap this project by the end of June.
Events
Localization “Fireside Chat”: come join us on Wednesday May 10, at 9am PT, where we will answer any questions you may have concerning updates contained in this localization report. This is the first time the localization-drivers try out this type of event, and we will accommodate for more timezones in the next iteration. It will take place on AirMozilla, and is open to anyone interested.
In the meantime you can check out our blog and visit past reports here.
Stay tuned on Discourse or in our Matrix channel for more info coming out soon!
Start asking questions here (or in this pad). You can also drop questions in the comments section of this blog post. Note that during the event, you will be able to ask more questions on our Matrix channel, and we will address them live if time permits.
Want to showcase an event coming up that your community is participating in? Contact us and we’ll include it.
Friends of the Lion
Image by Elio Qoshi
Thanks to all locale managers and translators who are helping us to test the Pretranslation feature in Pontoon. The locales currently involved are: cy, de, es-AR, fr, hu, id, it, sl, zh-TW. Your help, on top of what you’re doing every day to support Mozilla, is very much appreciated.
Kudos to Aderajew and Bantegize who single-handedly revived the Amharic community in a span of a few months! They completed the localization of a few mobile projects, and are making progress weekly on the mozilla.org project. Between the two of them, they split the tasks of what they each do best: localizing the products but also looking for new contributors, building up the community. Way to go!
Parvez and Abass led the effort in completing several high priority projects for Saraiki, including Firefox desktop, mobile products for Android, and mozilla.org.
Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!
The internet isn’t just about browsers. Browsers are a critical part of the human experience on the internet and will always be core to our work at Mozilla. But the internet is bigger than browsers — it’s every piece of content, app and experience on your device. Our mission will always be to make the internet better for everyone, and because of that, just like with browsers over the last quarter century, we need to show a better way forward in problematic areas over the next 25 years. And today, I’m thrilled to share a new area of experimentation for us — social.
Love it or hate it, there’s no denying that social media is a huge part of our lives. At its best, it’s how we connect with one another across space and time, discover new ideas, learn what’s happening in the world, and get introduced to content that makes us feel. It provides critical services, like alerting us to catastrophic weather or that the train you’re waiting for is delayed. It’s helped chip away at traditional power dynamics, giving a public platform to voices that haven’t had one before and offering a way for us to have influence over the powers and decision-markers that shape our lives.
But, look, at the risk of being both dramatic and cliched, social is broken. Most of those great things I just mentioned are…well none of them are working super well right now, are they? Things are primed for experimentation and a new direction, and we believe the Fediverse is central to that. Why? Because it moves power away from big tech companies and into the hands of diverse voices to build a social platform that meets people’s needs, not shareholders’ needs.
Last year, we announced we’re dipping our toes into the world of Mastodon. Today, we’re expanding Mozilla.social to a private beta. We’ve put a lot of work into getting to this stage, but there is a lot more to do before we open it up more broadly. We’re making a long-term investment because we think we can contribute to making Mastodon, and social media generally, better.
You’ll notice a big difference in our content moderation approach compared to other major social media platforms. We’re not building another self-declared “neutral” platform. We believe that far too often, “neutrality” is used as an excuse to allow behaviors and content that’s designed to harass and harm those from communities that have always faced harassment and violence. Our content moderation plan is rooted in the goals and values expressed in our Mozilla Manifesto — human dignity, inclusion, security, individual expression and collaboration. We understand that individual expression is often seen, particularly in the US, as an absolute right to free speech at any cost. Even if that cost is harm to others. We do not subscribe to this view. We want to be clear about this. We’re building an awesome sandbox for us all to play in, but it comes with rules governing how we engage with one another. You’re completely free to go elsewhere if you don’t like them.
I’d love to say those rules will be perfect on day one, but they won’t and we know they never will be. But we’re going to create a way to have a dialogue with the community we want to form, and to be open about what we’re learning.
What’s most important to us is that the people who use our instance feel like their experience brings back more of what makes social great – and reduces the muck that has made it horrible.
This will take us a while, especially because we’re committed to doing it in the open and with the community that already exists. Many other areas of the experience are ripe for experimentation – onboarding, discovery, identity, monetization just to name a few – so expect more from us soon.
If you’re interested in joining mozilla.social as we continue to expand it, join our waitlist. Or get involved in your own way–join in, give feedback, create your own instance. We could not be more excited about this, and can’t wait to work with all of you to build something that’s better for all of humanity.
Something happened on January 5, 2023. All of a sudden we abruptly started receiving a number of pings from Firefox Desktop clients in Korea equal to two times the size of the entire Korean Firefox Desktop population.
What happened? How did we notice it? What did we do about it?
Let’s back up.
I can’t remember where I learned it, but I’d already started reciting as dogma in my first year of University: “The most important part about any feature is the ability to turn it off”. It’s served me well through my studies and my career. I’ve also found it to be especially true for data collection systems where, for whatever reason, as a user you might decide you no longer want the software you’re using to continue to send data. In some places this is even enshrined in laws where you can request the deletion of data that has already been collected.
Law or not, Mozilla has before, does now, and will always make it easy for you to decide whether to send data to Mozilla. We may not understand why you make that choice, and it definitely will make it harder for us to ensure our products meet your needs, but we’ll respect the heck out of your choice in our processes and in our products.
This is why, when Mozilla’s data collection system Glean is told the user went from allowing data upload to forbidding it, we send one final “deletion-request” ping before shutting down. The “deletion-request” ping contains all the internal identifiers we’ve used to longitudinally group data (if we receive ten crash reports it’s important to know whether it’s the same Firefox crashing ten times or if it’s ten Firefoxes crashing once), and we use those identifiers to (well) identify what data we’ve collected that we’re now going to delete.
For the purposes of this story you’ll need to know that there’s two times when Glean notices the product’s gone from “data upload: on” to “data upload: off”: while Glean is running, and during Glean startup. If Glean’s running, then we just handle things – we were told the setting changed from “data upload: on” to “data upload: off” and away we go. But Glean knows that it isn’t always listening to the data upload setting, so if it it starts up with “data upload: off” and the last time it shut down we were “data upload: on” we’ll send a specific “at_init”-reason “deletion-request” ping.
We in the Data Org monitor how Glean is behaving. One thing we’ve learned about how Glean behaves is that the number of “deletion-request” pings is roughly constant over time. And the proportion of “deletion-request” pings that have the “at_init” reason should remain a fairly fixed one.
What shouldn’t happen is for Firefox Desktop-sent “at_init”-reason “deletion-request” pings to spike like this on January 5:
What we do when we notice things like this is file a bug. As the one responsible for Glean’s integration in Firefox Desktop, and as someone with a long history of looking into anomalies, I took a look. At this initial point I was pretty sure it’d be a single actor (a single user, a single company, a single internet cafe) doing something odd… but alas, the evidence was inconclusive:
Evidence consistent with a single actor being responsible for it all:
All the pings were coming from the same internet provider. Korea Telecom is responsible for a bare majority of Firefox Desktop data delivery from Korea, but the spikes were entirely from that ISP.
The Mozilla Community in Korea could offer no explanation of any wide-spread computer or software event that matched the timeline.
“at_init”-reason “deletion-request” pings could be a result of automation changing the files on disk to read “data upload: off” between runs of Firefox Desktop.
Evidence inconsistent with a single actor being responsible for it all:
The data came from a mix of Firefox Desktop versions: versions 101.0.1, 104.0, and 108.0.2.
The data came from a range of different regions, more or less following the population density of Korea itself.
“at_init”-reason “deletion-request” pings could instead be the result of users changing the setting to “data upload: off” early enough during Firefox Desktop startup that Glean hasn’t yet been initialized.
Regardless of why it was happening, it quickly became more important that we learn what we needed to do about it. We spun up an Incident, which is how we organize ourselves when there’s something happening that requires cross-functional collaboration and isn’t getting better on its own. Once there we ascertained that we could respond very quickly and decisively and do
Nothing at all.
The volume of these pings vastly eclipsed any other “deletion-request” pings we would otherwise have received, so you’d be forgiven for thinking that it was terribly expensive to receive, store, and process them all. In reality, we batch these requests. And even before this spike, every batch of requests required editing every partition of every table. Adding another list of identifiers to delete equal in size to two times the peak Firefox Desktop population in Korea just doesn’t matter all that much.
The pressure was off. Even if it got worse… which it did:
On March 26, when it reached and maintained a peak of five times the volume of the Firefox Desktop population in Korea, it still wasn’t harming our data platform’s ability to serve business needs or costing us all that much in operational spend. We didn’t need to invest effort into running down the source, so we didn’t.
And so I just kept an occasional eye on it until, just as suddenly but not quite as abruptly as it began, on April 12 the ping volumes began to decrease. By April 18, we were back to normal levels.
We had successfully ignored it until it went away.
So what happened to Korean Firefox Desktop users from Jan 5 to April 12, 2023? We never figured it out. If you know about something happening across those dates in Korea: please get in touch. As little as it needed solving for the sake of business needs, it still needs solving for the sake of my curiosity.
Welcome to a brand new feature called “Meet The Team!” In this ongoing series of conversations, I introduce you to the people behind the software you use every day. We kicked things off by talking to Thunderbird’s Product Design Manager Alex Castellani. Now let’s meet someone much newer to the team: Wolf-Martell Montwe.
Having recently joined us from Berlin as a full-time Android developer, Wolf brings his passion for building mobile applications to the Thunderbird team. He’ll be helping to develop new features and an updated interface for K-9 Mail as we transform it into Thunderbird for Android. I spoke with him about his first computer and early gaming memories, what he hopes to accomplish for the Thunderbird mobile app, and how our community of contributors can help.
<figcaption class="wp-element-caption">Catch up on the “Meet The Team” series by reading my conversation with Alex Castellani</figcaption>
Wolf’s Technology Origin Story
I love a great origin story, and many people working in technology seem to have one that’s directly tied to their first computer. Wolf is no exception.
“I think I started my computer journey with playing games — the first I remember is Sid Meier’s Pirates!” Wolf remembers. “Back then I had an IBM 386. Super slow, super loud! And I hacked around a lot to get games running too, to free up memory, to free up disk space because this was super limited. I think one partition was maximum 3MB! It was a big achievement if something just was running.”
Wolf’s fascination with games eventually led to some basic programming knowledge and web page development.
“I used to develop web pages, especially for my school to build up like a little forum,” he says. “I fell in love with PHP because it had one of the first editors with code completion, and that was awesome.”
What Attracted Wolf To The Thunderbird Project?
“I’m a longtime Thunderbird user, and I have used K-9 Mail from 2010 on,” Wolf says. “In my last position, my task was to build up open source software. (So we developed the software and then prepared it to be open source, because the code was readable, but people couldn’t contribute.) And over that time I fall in love with developing open source, so I was looking for opportunities to to follow up on that direction. “
The Thunderbird Android Team Just Doubled In Size. Now What?
Believe it or not, for many years K-9 Mail had one full-time developer (in addition to a community of contributors). So, Wolf effectively doubles the size of the core team. The first questions that came to mind: what doors does this open to the future of Thunderbird for Android, and what can Wolf and cketti accomplish during the next few months?
“First, I want to strengthen the technology base and also open it up for using more modern tooling, especially because the whole Android ecosystem is right now under a really drastic change,” Wolf explains. “It could be pretty beneficial for the project since it’s being rebranded, and think it’s good timing to then also adapt new technology and base everything on that.”
(The desktop version of Thunderbird is undergoing a similar transformation, as we slowly rebuild it with more modern tooling while eliminating years of technical debt.)
Wolf continues: “I think that would also open the Android app to be a little bit easier maintain from a UI side, because right now it is hard to achieve.”
It’s certainly easier for our developers — and our global team of community contributors — to improve an application and more easily add new features when the code isn’t fighting against them.
How Can The Community Help?
There’s so much we can do to contribute to open source software besides writing code. So I asked Wolf: what’s the most important thing the K-9 Mail and Thunderbird community can do to help development?
“Constructive feedback on what we’re doing,” Wolf says. “Whether it’s positive or negative, I think that’s important. But please be nice!”
We certainly encourage everyone on Android to try K-9 Mail as we continue its transformation to Thunderbird. When you’re ready to give feedback or suggest ideas, we invite you to join our Thunderbird Android Planning mailing list, which is open to the public.
I know some of you have been asking about the monthly blog post since January. We’re back today, with a summary of what happened in the past 3 months. This will be our new cadence for this kind of post. So please look out for our next edition by early July.
I hope the past 3 months have treated you well. Time surely flies so fast. We’ve done a lot of internal research for the past 3 months, but in Q2, I promise you will see more of me all around our various community channels.
Shout-outs to Tim Maks, Christophe, for participating in FOSDEM 2023! Also to Paul for his continued support for Mozfest over the years. You are all amazing!
Thanks to everybody for your participation in the Mozilla Support 2023 contributor survey. Your input and feedback are greatly appreciated. #MozLove to you all!
If you know anyone that we should feature here, please contact Kiki, and we’ll make sure to add them in our next edition.
Community news
What happened at FOSDEM 2023? Check out this blog post!
Learn more about Mozilla.social initiative if you’re into the fediverse world.
Watch the recording of our community call in March if you haven’t already to learn more about SUI (Simplified User Interface) screenshot that Lucas shared.
It’s also highly recommended to watch our community call in April to catch up on the result of the contributor survey we’ve done in Q1.
Catch up
Watch the monthly community call if you haven’t. Learn more about what’s new in January, February and March! Reminder:Don’t hesitate to join the call in person if you can. We try our best to provide a safe space for everyone to contribute. You’re more than welcome to lurk in the call if you don’t feel comfortable turning on your video or speaking up. If you feel shy to ask questions during the meeting, feel free to add your questions on the contributor forum in advance, or put them in our Matrix channel, so we can answer them during the meeting.
If you’re an NDA’ed contributor, you can watch the recording of the Customer Experience weekly scrum meeting from AirMozilla to catch up with the latest product updates.
Consider subscribe to Firefox Daily Digest to get daily updates about Firefox from across different platforms.
To catch up on product releases update, please watch the recording of the Customer Experience scrum meeting from AirMozilla. You can also subscribe to the AirMozilla folder by clickling on the Subscribe button at the top right corner of the page to get notifications each time we add a new recording.
At Thunderbird, we enthusiastically embrace open development. That means more than making our software open-source. It also means being as transparent as possible, and communicating frequently with our global family of users.
We want that communication to go both ways! Which is why Mozilla Connect is such an important tool for telling us the features you want to see get developed for Thunderbird (and soon, for our entire family of products and services). Mozilla Connect is an easy-to-use community tool that can help shape future Thunderbird (and Firefox) releases. It allows you to post a feature request, contribute your opinions to existing ones, and give kudos to the features you believe in.
We’re actively monitoring your Thunderbird feature suggestions at Mozilla Connect, but “voting up” ideas from the community is crucial. There are currently 287 Thunderbird ideas at Connect, many of which need wider discussion and votes.
With that in mind, we collected the Top 20 feature requests and linked them below. Check them out, and please consider lending your voice and your votes to these ideas – and the other 267 – if you believe in them.
Top 20 Thunderbird Feature Ideas At Mozilla Connect
Join Mozilla and the Center for Democracy & Technology (CDT) for a conversation about Congress’ work on tech transparency. The event will feature keynote remarks from U.S. Congresswoman Lori Trahan followed by an expert panel discussion.
The panel and remarks will be immediately followed by a happy hour reception where drinks and light fare will be served.
Date and time: Wednesday, April 26th – event starts @ 4:00PM promptly (doors @ 3:45pm) Location: Jackie, 79 Potomac Ave SE, Washington, DC 20003
Last month we reported on our progress in turning K-9 Mail into Thunderbird for Android. Since then a month has passed, so it’s time for another detailed update.
(If you missed the exciting news last summer, K-9 Mail is now part of the Thunderbird family, and we’re working steadily on transforming it into Thunderbird for Android. If you want to learn more, check out our Android roadmap, this blog post, and this FAQ.)
Towards a new stable release
The goal for March was to get the app into shape for a new stable release. We didn’t quite get there, but we should be close now.
Polishing the user interface
In February we introduced changes to the message view and message list screens. In March we spent quite some time polishing the UI and fixing bugs in that newly added code.
Message list
After experimenting with displaying the colored account indicator to the left of the subject/sender text, we decided to move it back to where it was in K-9 Mail 6.400.
<figcaption class="wp-element-caption">K-9 Mail 6.509: Colored account indicator to the left of the text</figcaption><figcaption class="wp-element-caption">K-9 Mail 6.511: Colored account indicator in line with text</figcaption>
We updated the “snackbar” that is displayed after the app was updated to disappear automatically after 10 seconds.
<figcaption class="wp-element-caption">K-9 Mail 6.511: “Find out what’s new in this release” notice</figcaption>
A keen observer will notice that we also changed the appearance of the floating button used to compose a new message. It now only shows an icon and the button is hidden when the message list is scrolled down.
Message view
In a previous beta version we accidentally increased the size of the star in the message view. We fixed that, and also reduced the size of the account “chip”.
<figcaption class="wp-element-caption">K-9 Mail 6.509: Large account indicator and message star</figcaption><figcaption class="wp-element-caption">K-9 Mail 6.509: Large account indicator and message star</figcaption>
We also added a setting to specify the font size of the account name under Settings → General settings → Display → Font size → Account name.
Bug fixes
Thanks to our beta testers we were able to track down and and fix a couple bugs:
Toolbar icons in the message view screen were missing when the app was killed while in the background and restored afterwards.
When the message list was updated while the user was swiping between messages, the swipe action was canceled, and the previously displayed message was displayed again.
The layout of the message details screen wasn’t adjusted when contact pictures were disabled, leading to contact picture sized gaps in the layout.
A couple of other minor bugs.
User Manual & Updating Screenshots
Did you know that K-9 Mail has a user manual? It can be found under docs.k9mail.app.
We updated the site to support multiple app versions and languages. For now, though, the user manual is only available in English.
In preparation for a new stable version, we added a “6.5xx (beta)” version and started updating the screenshots throughout the user manual. It turns out there’s quite a lot of them, and basically all of the screenshots need to be updated because the appearance of the app has changed since the last stable version. This is tedious work and has to be done every time we make visual changes that affect the whole app. So we started automating this task
Design system
Over the years, the visual appearance of Android has changed quite a lot, and so has the appearance of K-9 Mail. However, due to lack of resources, we never managed to update the whole app at once. And so the app still is a mix of different visual styles.
To improve this situation, we started working on implementing a design system – reusable components that can be assembled to build the different screens of the app. We’ll use it for new screens added to the app and will slowly migrate existing screens to using the design system.
Hopefully, this will allow us to react faster to design changes in Android in the future. For now, we’re still playing catch-up.
Releases
In March 2023 we published the following beta versions:
Let’s talk about what this means and when it might be useful.
What is third-party DLL injection?
On Windows, third-party products have a variety of ways to inject their code into other running processes. This is done for a number of reasons; the most common is for antivirus software, but other uses include hardware drivers, screen readers, banking (in some countries) and, unfortunately, malware.
Having a DLL from a third-party product injected into a Firefox process is surprisingly common – according to our telemetry, over 70% of users on Windows have at least one such DLL! (to be clear, this means any DLL not digitally signed by Mozilla or part of the OS).
Most users are unaware when DLLs are injected into Firefox, as most of the time there’s no obvious indication this is happening, other than checking the about:third-party page.
Unfortunately, having DLLs injected into Firefox can lead to performance, security, or stability problems. This is for a number of reasons:
DLLs will often hook into internal Firefox functions, which are subject to change from release to release. We make no special effort to maintain the behavior of internal functions (of which there are thousands), so the publisher of the third-party product has to be diligent about testing with new versions of Firefox to avoid stability problems.
Firefox, being a web browser, loads and runs code from untrusted and potentially hostile websites. Knowing this, we go to a lot of effort to keep Firefox secure; see, for example, the Site Isolation Security Architecture and Improved Process Isolation. Third-party products may not have the same focus on security.
We run an extensive number of tests on Firefox, and third-party products may not test to that extent since they’re probably not designed to work specifically with Firefox.
Indeed, our data shows that just over 2% of all Firefox crash reports on Windows are in third-party code. This is despite the fact that Firefox already blocks a number of specific third-party DLLs that are known to cause a crash (see below for details).
This also undercounts crashes that are caused indirectly by third-party DLLs, since our metrics only look for third-party DLLs directly in the call stack. Additionally, third-party DLLs are a bit more likely to cause crashes at startup, which are much more serious for users.
Firefox has a third-party injection policy, and whenever possible we recommend third parties instead use extensions to integrate into Firefox, as this is officially supported and much more stable.
Why not block all DLL injection by default?
For maximum stability and performance, Firefox could try to block all third-party DLLs from being injected into its processes. However, this would break some useful products like screen readers that users want to be able to use with Firefox. This would also be technically challenging and it would probably be impossible to block every third-party DLL, especially third-party products that run with higher privilege than Firefox.
Since 2010, Mozilla has had the ability to block specific third-party DLLs for all Windows users of Firefox. We do this only as a last resort, after trying to communicate with the vendor to get the underlying issue fixed, and we tailor it as tightly as we can to make Firefox users stop crashing. (We have the ability to only block specific versions of the DLL and only in specific Firefox processes where it’s causing problems). This is a helpful tool, but we only consider using it if a particular third-party DLL is causing lots of crashes such that it shows up on our list of top crashes in Firefox.
Even if we know a third-party DLL can cause a crash in Firefox, there are times when the functionality that the DLL provides is essential to the user, and the user would not want us to block the DLL on their behalf. If the user’s bank or government requires some software to access their accounts or file their taxes, we wouldn’t be doing them any favors by blocking it, even if blocking it would make Firefox more stable.
Giving users the power to block injected DLLs
With Firefox 110, users can block third-party DLLs from being loaded into Firefox. This can be done on the about:third-party page, which already lists all loaded third-party modules. The about:third-party page also shows which third-party DLLs have been involved in previous Firefox crashes; along with the name of the publisher of the DLL, hopefully this will let users make an informed decision about whether or not to block a DLL. Here’s an example of a DLL that recently crashed Firefox; clicking the button with a dash on it will block it:
Here’s what it looks like after blocking the DLL and restarting Firefox:
If blocking a DLL causes a problem, launching Firefox in Troubleshoot Mode will disable all third-party DLL blocking for that run of Firefox, and DLLs can be blocked or unblocked on the about:third-party page as usual.
How it works
Blocking DLLs from loading into a process is tricky business. In order to detect all DLLs loading into a Firefox process, the blocklist has to be set up very early during startup. For this purpose, we have the launcher process, which creates the main browser process in a suspended state. Then it sets up any sandboxing policies, loads the blocklist file from disk, and copies the entries into the browser process before starting that process.
The copying is done in an interesting way: the launcher process creates an OS-backed file mapping object with CreateFileMapping(), and, after populating that with blocklist entries, duplicates the handle and uses WriteProcessMemory() to write that handle value into the browser process. Ironically, WriteProcessMemory() is often used as a way for third-party DLLs to inject themselves into other processes; here we’re using it to set a variable at a known location, since the launcher process and the browser process are run from the same .exe file!
Because everything happens so early during startup, well before the Firefox profile is loaded, the list of blocked DLLs is stored per Windows user instead of per Firefox profile. Specifically, the file is in %AppData%\Mozilla\Firefox, and the filename has the format blocklist-{install hash}, where the install hash is a hash of the location on disk of Firefox. This is an easy way of keeping the blocklist separate for different Firefox installations.
Detecting and blocking DLLs from loading
To detect when a DLL is trying to load, Firefox uses a technique known as function interception or hooking. This modifies an existing function in memory so another function can be called before the existing function begins to execute. This can be useful for many reasons; it allows changing the function’s behavior even if the function wasn’t designed to allow changes. Microsoft Detours is a tool commonly used to intercept functions.
In Firefox’s case, the function we’re interested in is NtMapViewOfSection(), which gets called whenever a DLL loads. The goal is to get notified when this happens so we can check the blocklist and forbid a DLL from loading if it’s on the blocklist.
To do this, Firefox uses a homegrown function interceptor to intercept calls to NtMapViewOfSection() and return that the mapping failed if the DLL is on the blocklist. To do this, the interceptor tries two different techniques:
On the 32-bit x86 platform, some functions exported from a DLL will begin with a two-byte instruction that does nothing (mov edi, edi) and have five one-byte unused instructions before that. (either nop or int 3) For example:
nop
nop
nop
nop
nop
DLLFunction: mov edi, edi
(actual function code starts here)
If the interceptor detects that this is the case, it can replace the five bytes of unused instructions with a jmp to the address of the function to call instead. (since we’re on a 32-bit platform, we just need one byte to indicate a jump and four bytes for the address) So, this would look like
jmp <address of Firefox patched function>
DLLFunction: jmp $-5 # encodes in two bytes: EB F9
(actual function code starts here)
When the patched function wants to call the unpatched version of DLLFunction(), it simply jumps 2 bytes past the address of DLLFunction() to start the actual function code.
Otherwise, things get a bit more complicated. Let’s consider the x64 case. The instructions to jump to our patched function require 13 bytes: 10 bytes for loading the address into a register, and 3 bytes to jump to that register’s location. So the interceptor needs to move at least the first 13 bytes worth of instructions, plus enough to finish the last instruction if needed, to a trampoline function. (it’s known as a trampoline because typically code jumps there, which causes a few instructions to run, and then jumps out to the rest of the target function). Let’s look at a real example. Here’s a simple function that we’re going to intercept, first the C source (Godbolt compiler explorer link):
int fn(int aX, int aY) {
if (aX + 1 >= aY) {
return aX * 3;
}
return aY + 5 - aX;
}
and the assembly, with corresponding raw instructions. Note that this was compiled with -O3, so it’s a little dense:
Now, counting 13 bytes from the beginning of fn() puts us in the middle of the lea eax,[rdi+rdi*2] instruction, so we’ll have to copy everything down to that point to the trampoline.
The end result looks like this:
fn(int,int) (address 0x100000000):
# overwritten code
mov r11, 0x600000000 # 49 bb 00 00 00 00 06 00 00 00
jmp r11 # 41 ff e3
# leftover bytes from the last instruction
# so the addresses of everything stays the same
# We could also fill these with nop’s or int 3’s,
# since they won’t be executed
.byte 04
.byte 7f
# rest of fn() starts here
cmovl eax,ecx # 0f 4c c1
ret # c3
Trampoline (address 0x300000000):
# First 13 bytes worth of instructions from fn()
lea eax,[rdi+0x1] # 8d 47 01
mov ecx,esi # 89 f1
sub ecx,edi # 29 f9
add ecx,0x5 # 83 c1 05
cmp eax,esi # 39 f0
lea eax,[rdi+rdi*2] # 8d 04 7f
# Now jump past first 13 bytes of fn()
jmp [RIP+0x0] # ff 25 00 00 00 00
# implemented as jmp [RIP+0x0], then storing
# address to jump to directly after this
# instruction
.qword 0x10000000f
Firefox patched function (address 0x600000000):
<whatever the patched function wants to do>
If the Firefox patched function wants to call the unpatched fn(), the patcher has stored the address of the trampoline (0x300000000 in this example). In C++ code we encapsulate this in the FuncHook class, and the patched function can just call the trampoline with the same syntax as a normal function call.
This whole setup is significantly more complicated than the first case; you can see that the patcher for the first case is only around 200 lines long while the patcher that handles this case is more than 1700 lines long! Some additional notes and complications:
Not all instructions that get moved to the trampoline can necessarily stay exactly the same. One example is jumping to a relative address that didn’t get moved to the trampoline – since the instruction has moved in memory, the patcher needs to replace this with an absolute jump. The patcher doesn’t handle every kind of x64 instruction (otherwise it would have to be much longer!), but we have automated tests to make sure we can successfully intercept the Windows functions that we know Firefox needs.
We specifically use r11 to load the address of the patched function into because according to the x64 calling convention, r11 is a volatile register that is not required to be preserved by the callee.
Since we use jmp to get from fn() to the patched function instead of ret, and similarly to get from the trampoline back into the main code of fn(), this keeps the code stack-neutral. So calling other functions and returning from fn() all work correctly with respect to the position of the stack.
If there are any jumps from later in fn() into the first 13 bytes, these will now be jumping into the middle of the jump to the patched function and bad things will almost certainly happen. Luckily this is very rare; most functions are doing function prologue operations in their beginning, so this isn’t a problem for the functions that Firefox intercepts.
Similarly, in some cases fn() has some data stored in the first 13 bytes that are used by later instructions, and moving this data to the trampoline will result in the later instructions getting the wrong data. We have run into this, and can work around it by using a shorter mov instruction if we can allocate space for a trampoline that’s within the first 2 GB of address space. This results in a 10 byte patch instead of a 13 byte patch, which in many cases is good enough to avoid problems.
Some other complications to quickly mention (not an exhaustive list!):
Firefox also has a way to do this interception across processes. Fun!
Trampolines are tricky for the Control Flow Guard security measure: since they are legitimate indirect call targets that do not exist at compile time, it requires special care to allow Firefox patched functions to call into them.
Trampolines also involve some more fixing up for exception handling, as we must provide unwind info for them.
If the DLL is on the blocklist, our patched version of NtMapViewOfSection() will return that the mapping fails, which causes the whole DLL load to fail. This will not work to block every kind of injection, but it does block most of them.
One added complication is that some DLLs will inject themselves by modifying firefox.exe’s Import Address Table, which is a list of external functions that firefox.exe calls into. If one of these functions fails to load, Windows will terminate the Firefox process. So if Firefox detects this sort of injection and wants to block the DLL, we will instead redirect the DLL’s DllMain() to a function that does nothing.
Final words
Principle 4 of the Mozilla Manifesto states that “Individuals’ security and privacy on the internet are fundamental and must not be treated as optional”, and we hope that this will give Firefox users the power to access the internet with more confidence. Instead of having to choose between uninstalling a useful third-party product and having stability problems with Firefox, now users have a third option of leaving the third-party product installed and blocking it from injecting into Firefox!
As this is a new feature, if you have problems with blocking third-party DLLs, please file a bug. If you have issues with a third-party product causing problems in Firefox, please don’t forget to file an issue with the vendor of that product – since you’re the user of that product, any report the vendor gets means more coming from you than it does coming from us!
Special thanks to David Parks and Yannis Juglaret for reading and providing feedback on many drafts of this post and Toshihito Kikuchi for the initial prototype of the dynamic blocklist.
As the value of being connected to the internet increases, the need to make internet access available and affordable to all citizens becomes ever more urgent. But how many people actually have access to the internet? Statistics are often quoted about what percentage of the world has access to the internet but those numbers are inevitably fuzzy, relying on varying definitions of internet access and varying levels of reporting quality. In order to understand the true extent of the internet, we need to start with the basics, the physical infrastructure that carries the internet around the world.
The first step in developing a solid foundation on which to understand the growth of the internet are terrestrial fibre optic networks, the high-capacity backbones that carry thousands of terabits of internet traffic every day across vast distances. Fibre optic networks are the “deep water ports” of the internet, offering orders of magnitude of greater communication capacity than any other access technology. Research has shown that just living close to a fibre optic network is positively correlated with higher employment levels.
But fibre networks come in all sorts of shapes and sizes, from underground to aerial, from a few fibre strands to hundreds, from old technology to new. We can’t map the full extent of the fibre optic network infrastructure underpinning the internet without a common framework for describing them. And that is where the Open Fibre Data Standard comes in. It provides a common framework for describing terrestrial fibre optic infrastructure that can be used by operators, researchers, governments, and regulators.
The Open Fibre Data Standard has gone through extensive development and consultation. Beginning with an Alpha and Beta release, it is now in release 0.2. Mozilla staff will travel to Ghana, Kenya and India in March and April of 2023 to build technical capacity for operators and regulators in the implementation of the standard and to support participation in its further development.
This month, the National Telecommunications Information Administration (NTIA) requested comments on a vital topic – the intersection of privacy, equity, and civil rights in commercial data collection practices. In its role as principal advisor to the President on telecommunications and information policy issues, we applaud NTIA’s focus on privacy – and particularly on marginalized or underserved communities, who are especially at risk of privacy violations.
As builders of privacy and security-preserving technology, Mozilla shared our perspective, advocating for improved consumer technology and policies that advance choice and equity outcomes for consumers.
At Mozilla, privacy comes first in our products, like Enhanced Tracking Protection (ETP) and our end-to-end encrypted Firefox Sync service. Mozilla also prioritizes privacy in our public interest advocacy, calling for comprehensive privacy legislation, greater ad transparency, and robust enforcement of data privacy law and regulations around the globe. Through research such as the award-winning Internet Health Report and “Privacy Not Included” consumer guide, Mozilla serves as a global, open resource to empower consumers, inform policymakers, and inspire industry best practices.
Our comments to NTIA focus on areas that pose substantial risk to equity and civil rights in terms of data collection practices, advertising targeting, and the use of automated decision making systems (ADMS). Lastly, we conclude with several policy recommendations to guide more equitable technology policymaking.
Privacy and Data Collection Practices Online:
Privacy practices must strike the balance between delivering value in service and minimizing consumer data collection. In practice, this means being conscious to collect only the data that’s needed, not keep it longer than necessary, and clearly and concisely explain to consumers what data we collect, how to use it, and how we mitigate risks. From an equity perspective, it is important to note that without comprehensive federal privacy protections, many Americans are unprotected. Therefore, depending on where somebody lives, they may not have the right to access, delete, or even correct data – for example, even potentially false criminal records that data brokers share about users.
Equity, Ad targeting, and ADMS:
In a lot of ways, ad targeting systems drive today’s internet. This allows advertisers to target consumers based on their interests, behaviors and demographics. Systems also allow for easy segmentation of racial or demographic groups, with the potential for discriminatory outcomes and raising significant equity concerns. Automated-decision making systems (ADMS) share a similar set of equity risks, but across a broader set of use cases from facial recognition to automating decisions about mortgage rates or healthcare.
Despite challenges in studying the harms and risks associated with these practices and automated systems from the outside, companies that develop and implement these systems are in a position to prevent or mitigate harms like discrimination. Yet, the incentives for broad adoption of audits and mitigation tools are lacking. Thus, rules are necessary to change this incentive structure and make companies price in the externalities caused by the ADMS they develop.
Policy Recommendations:
Transparency is an important prerequisite to empowering consumers and diagnosing potential harm and risk associated with certain data collection practices. As a part of this, we also need to mandate greater access to platform data and protection for researchers at the federal level. To be able to address the harms associated with ADMS, policymakers must also compel transparency to understand: Are ADMS used for certain decisions? How do they make said decisions? In what contexts are they deployed?
Regulators must also take proactive steps in enforcing audits of ADMS that can surface and prevent potential harms to consumers, both before and after deployment in the market. This means making sure that systems are checked for bias, accuracy, privacy risks, and other harms.
Comprehensive privacy protection at the federal level and promoting Global Privacy Control (GPC) are other important protective measures.
Welcome to the debut episode of the Thunderbird podcast, which we’re affectionately calling the ThunderCast! It’s an inside look at the making of Thunderbird, alongside community-driven conversations with our friends in the open-source world. We can’t wait for you to listen!
Alex starts a band, Ryan is building a keyboard, Jason’s island adventures
4 years of “invisible work” to prepare for Supernova
Thunderbird on Android… and iOS
Transcript
We include a full transcript of the episode inside the podcast metadata, which should be supported by your podcast app. If it’s not, here’s a direct link to the Episode 1 transcript.
Chapter Markers
The ThunderCast includes chapters for podcast players that support the feature. If yours does not, here are some timestamps to help you navigate the episode:
The last few months it has become clear that AI is no longer our future, but our present. Some of the most exciting ideas for the future of both the internet and the world involve AI solutions. This didn’t happen overnight, decades of work have gone into this moment. Mozilla has been working to make sure that the future of AI benefits humanity in the right ways by investing in the creation of trustworthy AI.
We want entrepreneurs and builders to join us in creating a future where AI is developed through this responsible lens. That’s why we are relaunching our Mozilla Builders program with the Responsible AI Challenge.
At Mozilla, we believe in AI: in its power, its commercial opportunity, and its potential to solve the world’s most challenging problems. But now is the moment to make sure that it is developed responsibly to serve society.
If you want to build (or are already building) AI solutions that are ambitious but also ethical and holistic, the Mozilla Builder’s Responsible AI Challenge is for you. We will be inviting the top nominees to join a gathering of the brightest technologists, community leaders and ethicists working on trustworthy AI to help get your ideas off the ground. Participants will also have access to mentorship from some of the best minds in the industry, the ability to meet key contributors in this community, and an opportunity to win some funding for their project.
Mozilla will be investing $50,000 into the top applications and projects, with a grand prize of $25,000 for the first-place winner.
While K-9 Mail is developed in the open, following its development on GitHub can be somewhat tedious for a casual observer. So we’re trying something new and summarizing the most notable things that happened in the past month as we head down the road to Thunderbird for Android.
If you missed the exciting news last summer, K-9 Mail is now part of the Thunderbird family, and we’re working steadily on transforming it into Thunderbird for Android. If you want to learn more, check out the Android roadmap, this blog post, and this FAQ.
In July 2022 ByteHamster proposed a change to the message view header. cketti’s decision to take a more holistic approach sent us on a months-long journey redesigning this screen in close cooperation with the Thunderbird design team. A first version finally shipped with K-9 Mail v6.505 (beta) at the start of February. The UI has since been refined based on user feedback.
The next stable release will most likely ship with what is included in the latest beta version. But during our design sessions we’ve looked at many other improvements, e.g. selecting which remote images to load (or not load), attachment handling, and more. So expect smaller updates to this screen in the future.
Message list
We started making small changes to the message list screen. It’s mostly about text alignment and whitespace. But we’ve also enlarged the click areas for the contact image and the star. That should make it much less likely that you accidentally open a message when you meant to select or star it.
We also added three different message list density settings: compact, default, relaxed.
<figcaption class="wp-element-caption">Message List Density Settings</figcaption>
<figcaption class="wp-element-caption">Compact Message List Density</figcaption>
<figcaption class="wp-element-caption">Default Message List Density</figcaption>
<figcaption class="wp-element-caption">Relaxed Message List Density</figcaption>
A first version of these changes can be found in K-9 Mail v6.509 (beta). We’re looking forward to getting your feedback on this.
Bug fixes
Most of the bugs we fixed in February were related to newly added functionality. We also fixed a couple of (rare) crashes that we received via the Google Play Developer Console. Nothing too exciting.
Welcome to a brand new feature called “Meet The Team!” In this ongoing series of conversations, I want to introduce you to the people behind the software you use every day. When and why did they fall in love with technology? What does their day-to-day schedule look like? What attracts them to open-source projects? And what’s their playlist of choice when hacking away on Thunderbird?
Let’s kick it off by getting to know the person leading the charge on Thunderbird’s modern redesign: Product Design manager, Alex Castellani.
Alex’s Origin Story
I’ve always been fascinated by learning about the initial spark that ignited someone’s love for technology, open source, or programming. Everyone loves a good origin story, right? So that’s one of the first questions I’m asking every member of the Thunderbird team.
<figcaption class="wp-element-caption">In his own words: Listen to Alex share how he fell in love with web design and programming.</figcaption>
At the young age of 12, after his father taught him how to paint, Alex initially wanted to be a comic book artist and attend art school. But a few years later, this wondrous new thing called the Internet distracted him.
“I started doing some web design very loosely, and I was participating in a web design forum where I was doing the design and other people were doing the development,” Alex says. “But I was getting very upset about the developers not recreating my design perfectly! Because I am who I am, I said to myself ‘I’m sure I can do better than them, so I will teach myself.’ So I started learning PHP and HTML — by the way, at that time CSS didn’t even have floating elements.”
It didn’t take long for Alex to fall in love with coding. But his journey took another step forward thanks to, of all things, an Italian-language Star Trek role-playing game.
“I was fascinated by how they were doing online activities and multiple people chatting,” Alex says. “I found out it was built on PHP and MySQL, and I wanted to learn how to build it myself as well. And yeah, I’ve never had a full night’s sleep ever since!”
Pricey, Proprietary Tools: A Gateway to Open-Source
Alex’s fondness for coding and design would eventually lead him to discover the concept of open source. But first, he learned a hard lesson about what “proprietary” meant in the real world.
<figcaption class="wp-element-caption">In his own words: The pricey proprietary tools that led Alex to open source</figcaption>
“After High School, I wanted to be an architect,” Alex says. “So I went to university — and dropped out after 3 months because I hated it so much.”
Alex came from what he describes as a blue collar family, and while he didn’t live an uncomfortable life, certain things were unaffordable luxuries.
“I couldn’t afford a phone,” Alex says. “I couldn’t even afford textbooks, especially old, important architecture textbooks that cost hundreds of Euros. So I tried to sneak out, grab them from the library and photocopy them. But that wasn’t even allowed because these restrictive policies were in place.”
Alex tells me he felt shut out. Blocked from accessing the tools he needed.
“And even little things like, you need this specific type of paper, this specific pencil, this specific compass,” he explains. “You need all these tools that are so expensive…”
After coming home from university, a glimmer of light appeared. A closer look at the burgeoning internet revealed things like website developers sharing HTML source code for the sites he visited, and freely available documentation showing how to write CSS.
“I’m not forced to pay thousands of dollars to learn these things that are just out there,” he says. “That influenced a lot in my way of thinking. Since day one, everything that I coded and everything that I built, I always put the source code online for free. I never thought about other people stealing it. I thought other people could learn from it!”
A Typical Week At Thunderbird?
Alex manages the entire front-end team, which means a typical week involves lots of meetings. But each day starts at 7am when he rolls out of bed and walks his dog. Then, before enjoying some breakfast, he sits down and filters through hundreds of emails to see what he can contribute to. He points out that since we’re a global, remote team, it’s important for him to answer any European-based messages so that the senders have a response to wake up to.
Those meetings though? They definitely couldn’t just be an email. Right now, as Thunderbird 115 is being built, the team is looking at the entire user interface, every single pixel, every single tab, discussing what doesn’t work and what needs to be fixed. They’re evaluating various mockups to see what can be applied. They have regular design sessions and generally work toward making Supernova awesome.
After the meetings are over, Alex typically does patch reviews, then dedicates some time to coding.
And yes, those coding sessions have a very specific soundtrack: Eastern European, female-fronted heavy metal.
What Excites Alex Most About Thunderbird Supernova?
As the person heading up UX and UI design, you might think Alex is a little biased when it comes to naming his favorite Supernova feature. And you’d be right! But when pressed to name a very specific favorite feature about the upcoming Thunderbird 115 in July, Alex points to customization.
<figcaption class="wp-element-caption">In his own words: Is Thunderbird REALLY that customizable?</figcaption>
“A lot of our current users put Thunderbird on a pedestal for how customizable it is, but it’s actually not,” Alex exclaims. “Thunderbird is customizable in a manner that you can hide a panel, change some buttons in the toolbars, and change the theming.”
“But what if I want my reading list in my message pane to be like a vertical layout, with only three lines of preview text, or zero lines of preview text,” he asks. “What if I want my calendar to have tiny dot colors and not block colors? And I want to hide the notification icons, and not be shown which ones are recurring? What if I want to collapse my Saturday and Sunday to smaller chunks instead of hiding them entirely? What if I want to see the subject line larger, and I don’t even want to see the ‘From’ and ‘To’ labels? I don’t need to see those, it’s been like that for 20 years. Let’s hide them!”
Alex explains that he — and by extension the entire team — wants the Thunderbird experience to feel more personal, and more suited to what individual users want and expect. “That’s why we needed to rebuild it from scratch, but make it behave exactly like the old version,” he says.
“Now that we rebuilt, we can customize it much more, and we can offer the user much more flexibility to shape it the way they want.”
Alex Castellani, Thunderbird product design manager
How Can The Community Help You?
We’ve written previously about all the ways our community — and any open source project’s community — can contribute without knowing how to code. So I asked Alex what our community could do to have a direct, positive impact on his specific role at Thunderbird.
VIDEO: IN HIS WORDS
“What I love about our community is they are extremely involved and they care about everything that we do,” Alex says. “So in general, using more Beta and using more Daily. Be aware though that Daily is literally alpha software and could crash. But testing the operating system, integrations, the usability and accessibility of the whole interface is something that’s really important.”
The SeaMonkey project team is pleased to announce the immediate release of SeaMonkey 2.53.16 Beta 1. As it is a beta version, please do backup your profile. That said, please checkout [1] and/or [2] for the release information.
[side note/thought here: I had thought of using “SeaMonkey 2.53.16 Beta 1 is OUT!” or “SeaMonkey 2.53.16 Beta 1 is out!” but had thought that’d be shouting… though I am exclaiming that it is out. Looking at previous release messages, I didn’t realize I had used the exclamation mark that much. Didn’t really mean to shout rudely. Was just exclaiming. Just hard to properly exclaim in a message without sounding a bit rude… anyway.. I digress.]
As I was reading about this news I saw that the commentary around it repeated an often heard assumption that says, as Jeremy Keith puts it, it’s a “fact that adding a website to the home screen remains such a hidden feature that even power users would be forgiven for not knowing about it.” No one ever seems to cite a study that shows this. I always see this written as if it is indeed a statement of fact. But it just so happens that recently we were testing some prototypes on iOS (unrelated to web apps) and we needed participants to add them their home screens. Of the ten people we talked to, four were familiar with this flow and had saved various things this way. When I mentioned this to others on the UX team a few shared similar stories.
So four of ten people in a user test – what does that tell us? It tells us that it’s something that at least some regular people do and that it’s not a hidden power user feature. More than that, it’s a good reminder to check your assumptions.
It is that time of the year, and we are off to Brussels for FOSDEM 2023!
FOSDEM is a central appointment for the Open Source community.
This is the first year the conference will be back in person and Mozilla will be there, with a stand on the conference floor and many interesting talks in our DevRoom.
We are all looking forward to meet-up in person with developers and Open Source enthusiasts from all over Europe (and beyond).
The event will take place on the 4th and 5th of February, including more than 700 talks and 60 stands.
If you are there, come to say hi to our stand or watch the streaming of our talks on the FOSDEM website!
Many mozillians that are going to FOSDEM will also be in this Matrix Room, so feel free to join and ask any questions.
The Mozilla Stand
Our stand will be in building K level 2 and will be managed by many enthusiastic Mozillians. Come pick up a sticker and chat all that is Mozilla, including Firefox, MDN, Hubs, digital policy, and many other projects.
Mozilla DevRoom – UA2.220 (Guillissen)
The Mozilla DevRoom will take place on Saturday between 15:00 and 19:00. If you cannot make it, all the talks will be streamed during the event (click on the event link to find the streaming link).
A key difference between the web and other platforms is that the web puts users in control: people are free to choose whichever browser best meets their needs, and use it with any website. This is interoperability: the ability to pick and choose components of a system as long as they adhere to common standards.
For Mozilla, interoperability based on standards is an essential element of what makes the web special and sets it apart from other, proprietary, platforms. Therefore it’s no surprise that maintaining this is a key part of our vision for the web.
However, interoperability doesn’t just happen. Even with precise and well-written standards it’s possible for implementations to have bugs or other deviations from the agreed-upon behavior. There is also a tension between the desire to add new features to the platform, and the effort required to go back and fix deficiencies in already shipping features.
Interoperability gaps can result in sites behaving differently across browsers, which generally creates problems for everyone. When site authors notice the difference, they have to spend time and energy working around it. When they don’t, users suffer the consequences. Therefore it’s no surprise that authors consider cross-browser differences to be one of the most significant frustrations when developing sites.
Clearly this is a problem that needs to be addressed at the source. One of the ways we’ve tried to tackle this problem is via web-platform-tests. This is a shared testsuite for the web platform that everyone can contribute to. This is run in the Firefox CI system, as well as those of other vendors. Whenever Gecko engineers implement a new feature, the new tests they write are contributed back upstream so that they’re available to everyone.
Having shared tests allows us to find out where platform implementations are different, and gives implementers a clear target to aim for. However, users’ needs are large, and as a result, the web platform is large. That means that simply trying to fix every known test failure doesn’t work: we need a way to prioritize and ensure that we strike a balance between fixing the most important bugs and shipping the most useful new features.
The Interop project is designed to help with this process, and enable vendors to focus their energies in the way that’s most helpful to the long term health of the web. Starting in 2022, the Interop project is a collaboration between Apple, Bocoup, Google, Igalia, Microsoft and Mozilla (and open to any organization implementing the web platform) to set a public metric to measure improvements to interoperability on the web.
Interop 2022 showed significant improvements in the interoperability of multiple platform features, along with several cross-browser investigations that looked into complex, under-specified, areas of the platform where interoperability has been difficult to achieve. Building on this, we’re pleased to announce Interop 2023, the next iteration of the Interop project.
Interop 2023
Like Interop 2022, Interop 2023 considers two kinds of platform improvement:
Focus areas cover parts of the platform where we already have a high quality specification and good test coverage in web-platform-tests. Therefore progress is measured by looking at the pass rate of those tests across implementations. “Active focus areas” are ones that contribute to this year’s scores, whereas “inactive” focus areas are ones from previous years where we don’t anticipate further improvement.
As well as calculating the test pass rate for each browser engine, we’re also computing the “Interop” score: how many tests are passed by all of Gecko, WebKit and Blink. This reflects our goal not just to improve one browser, but to make sure features work reliably across all browsers.
Investigations are for areas where we know interoperability is lacking, but can’t make progress just by passing existing tests. These could include legacy parts of the platform which shipped without a good specification or tests, or areas which are hard to test due to missing test infrastructure. Progress on these investigations is measured according to a set of mutually agreed goals.
Focus Areas
The complete list of focus areas can be seen in the Interop 2023 readme. This was the result of a consensus based process, with input from web authors, for example using the results of the State of CSS 2022 survey, and MDN “short surveys”. That process means you can have confidence that all the participants are committed to meaningful improvements this year.
Rather than looking at all the focus areas in detail, I’ll just call out some of the highlights.
CSS
Over the past several years CSS has added powerful new layout primitives — flexbox and grid, followed by subgrid — to allow sophisticated, easy to maintain, designs. These are features we’ve been driving & championing for manyyears, and which we were very pleased to see included in Interop 2022. They have been carried forward into Interop 2023, adding additional tests, reflecting the importance of ensuring that they’re totally dependable across implementations.
As well as older features, Interop 2023 also contains some new additions to CSS. Based on feedback from web developers we know that two of these in particular are widely anticipated: Container Queries and parent selectors via :has(). Both of these features are currently being implemented in Gecko; Container Queries are already available to try in prerelease versions of Firefox, and is expected to be released in Firefox 110 later this month, whilst :has() is under active development. We believe that including these new features in Interop 2023 will help ensure that they’re usable cross-browser as soon as they’re shipped.
Web Apps
Several of the features included in Interop 2023 are those that extend and enhance the capability of the platform; either allowing authors to achieve things that were previously impossible, or improving the ergonomics of building web applications.
The Web Components focus area is about ergonomics; components allow people to create and share interactive elements that encapsulate their behavior and integrate into native platform APIs. This is especially important for larger web applications, and success depends on the implementations being rock solid across all browsers.
Unlike the other focus areas, Web Compatibility isn’t about a specific feature or specification. Instead the tests in this focus area have been written and selected on the basis of observed site breakage, for example from browser bug reports or via webcompat.com. The fact that these bugs are causing sites to break immediately makes them a very high priority for improving interoperability on the web.
Investigations
Unfortunately not all interoperability challenges can be simply defined in terms of a set of tests that need to be fixed. In some cases we need to do preliminary work to understand the problem, or to develop new infrastructure that will allow testing.
For 2023 we’re going to concentrate on two areas in which we know that our current test infrastructure is insufficient: mobile platforms and accessibility APIs.
Mobile browsing interaction modes often create web development and interoperability challenges that don’t occur on desktop. For example, the browser viewport is significantly more dynamic and complex on mobile, reflecting the limited screen size. Whilst browser vendors have ways to test their own mobile browsers, we lack shared infrastructure required to run mobile-specific tests in web-platform-tests and include the results in Interop metrics. The Mobile Testing investigation will look at plugging that gap.
Users who make use of assistive technology (e.g., screen readers) depend on parts of the platform that are currently difficult to test in a cross-browser fashion. The Accessibility Testing investigation aims to ensure that accessibility technologies are just as testable as other parts of the web technology stack and can be included in future rounds of Interop as focus areas.
Together these investigations reflect the importance of ensuring that the web works for everyone, irrespective of how they access it.
Dashboard
To follow progress on Inteop 2023, see the dashboard on wpt.fyi. This gives detailed scores for each focus area, as well as overall progress on Interop and the investigations.
Mozilla & Firefox
The Interop project is an important part of Mozilla’s vision for a safe & open web where users are in control, and can use any browser on any device. Working with other vendors to focus efforts towards improving cross-browser interoperability is a big part of making that vision a reality. We also know how important it is to lead through our products, and look forward to bringing these improvements to Firefox and into the hands of users.
Last March we announced the Interop 2022 project, a collaboration between Apple, Bocoup, Google, Igalia, Microsoft, and Mozilla to improve the quality and consistency of their implementations of the web platform.
Now that it’s 2023 and we’re deep into preparations for the next iteration of Interop, it’s a good time to reflect on how the first year of Interop has gone.
Interop Wins
Happily, Interop 2022 appears to have been a big success. Every browser has made significant improvements to their test pass rates in the Interop focus areas, and now all browsers are scoring over 90%. A particular success can be seen in the Viewport Units focus area, which went from 0% pass rate in all browsers to 100% in all browsers in less than a year. This almost never happens with web platform features!
Looking at the release version of browsers — reflecting what actually ships to users — Firefox started the year with a score of around 60% in Firefox 95 and reached 90% in Firefox 108, which was released in December. This reflects a great deal of effort put into Gecko, both in adding new features and improving the quality of implementation of existing features like CSS containment, which jumped from 85% pass rate to 98% with the improvements that were part of Firefox 103.
One of the big new web-platform features in 2022 was Cascade Layers, which first shipped as part of Firefox 97 in February. This was swiftly followed by implementations shipping in Chrome 99 and Safari 15.4, again showing the power of Interop to rapidly drive a web platform feature from initial implementation to something production-quality and available across browsers.
Another big win that’s worth highlighting was the progress of all browsers to >95% on the “Web Compatibility” focus area. This focus area consisted of a small set of tests from already implemented features where browser differences were known to cause problems for users (e.g. through bug reports to webcompat.com). In an environment where it’s easy to fixate on the new, it’s very pleasing to see everyone come together to clean up these longstanding problems that broke sites in the wild.
Other new features that have shipped, or become interoperable, as part of Interop 2022 have been written about in retrospectives by Apple and Google. There’s a lot of work there to be proud of, and I’d suggest you check out their posts.
Investigations
Along with the “focus areas” based on counts of passing tests, Interop 2022 had three “investigations”, covering areas where there’s less clarity on what’s required to make the web interoperable, and progress can’t be characterized by a test pass rate.
The Viewport investigation resulted in multiple spec bugs being filed, as well as agreement with the CSSWG to start work on a Viewport Specification. We know that viewport-related differences are a common source of pain, particularly on mobile browsers; so this is very promising for future improvements in this area.
The Mouse and Pointer Events investigation collated a large number of browser differences in the handling of input events. A subset of these issues got tests and formed the basis for a proposed Interop 2023 focus area. There is clearly still more to be done to fix other input-related differences between implementations.
The Editing investigation tackled one of the most historically tricky areas of the platform, where it has long been assumed that complex tasks require the use of libraries that smooth over differences with bespoke handling of each browser engine. One thing that became apparent from this investigation is that IME input (used to input characters that can’t be directly typed on the keyboard) has behavioral differences for which we lack the infrastructure to write automated cross-browser tests. This Interop investigation looks set to catalyze future work in this area.
Next Steps
All the signs are that Interop 2022 was helpful in aligning implementations of the web and ensuring that users are able to retain a free choice of browser without running into compatibility problems. We plan to build on that success with the forthcoming launch of Interop 2023, which we hope will further push the state of the art for web developers and help web browser developers focus on the most important issues to ensure the future of a healthy open web.
Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.
Are you a locale leader and want us to include new members in our upcoming reports? Contact us!
New community/locales added
Punjabi from Pakistan (pa-pk) was recently added to Pontoon.
New content and projects
What’s new or coming up in Firefox desktop
Firefox 111, shipping to release users on March 14, is going to include two new locales: Friulian (fur) and Sardinian (sc). Congratulations to the team for this achievement, it’s been a long time since we added new locales to release (Firefox 91).
A new locale is also available in Nightly, Saraiki (skr). Unfortunately, it’s currently blocked by missing information in the Unicode (CLDR) database that prevents the layout from being correctly displayed with right-to-left direction. If you want to help them, feel free to reach out to the locale manager.
In terms of content, one major feature coming is Cookie Banner Reduction, which will allow users to automatically reject all cookies in cookie banner requests. Several strings already landed over the last weeks, but expect some changes and instructions on how to test the feature (and different variations of messages used for testing).
What’s new or coming up in mobile
Just as for Firefox desktop, the v111 release ships on March 14 for all mobile projects, and also contains strings for the new Cookie Banner Reduction feature (see section above). Stay tuned for more information around that.
What’s new or coming up in web projects
Mozilla.org
The site is going to go through some transformation this year. It involves restructuring such as removing pages with duplicate information, consolidating other pages, redesigning the site, and rewriting some copy. Having said that, the effort involves several cross functional teams to accomplish. Impact of these changes on localization is estimated to be in the second half of the year.
If your locales have some catching up to do, please continue working. Your work won’t go wasted as it will be stored in the translation memory in Pontoon. Speaking of such, congratulations to the Saraiki (skr) team for completing the project. The site was recently launched on production.
AMO
Strings related to tools for reviewer and admins have been removed from Pontoon. The features used to be available for vetted contributors plus Mozilla staff and contractors in the production environment, but now it’s no longer the case. Since the localized strings can’t be reviewed in context by localizers, the team has decided to separate the strings from landing in Pontoon. Currently the feature is partially localized if your locale has done some or all the work in the past.
Firefox Accounts
Behind the scenes, the Firefox Accounts team are in the process of refactoring a number of pages to use Fluent. This means we will see a number of strings reusing translations from older file formats with updated Fluent syntax. These strings are in the process of landing, but won’t be exposed until the rework is done, so it may be some time before strings can be reviewed in production.
Congratulations to Baurzhan of the Kazakh (kk) team for recently raising the completion rate of his locale from 30% to 100%. The Kazakh locale is already activated on staging and will soon be released to production.
What’s new or coming up in SUMO
What did SUMO accomplish in 2022? Check out our 2022 summary in this blog post.
Please join our discussion on how we would like to present ourselves in Mozilla.Social!
SUMO just redesigned our Contribute Page recently. Check out the news and the new page if you haven’t already!
The Android mobile team (Firefox for Android and Firefox Focus for Android) have decided to move to Bugzilla. If you’re a mobile contributor, make sure to direct users to the right place for bug report by referring them to this article.
Are you a KB or article localization contributor and experience issue with special characters when copying tags? Please chime in on the discussion thread or directly in the bug report (Thanks to Tim for filing that bug).
If you’re a Social Support or Mobile Store Support contributor, make sure to watch the contributor forum to get updates about queue stats every week. Kiki will post the update by the end of the week to make sure that you’re updated. Here’s the latest one from last week.
You can now learn more about Kitsune releases by following this Discourse topic.
What’s new or coming up in Pontoon
Changes to the Editor
Pontoon’s editor is undergoing improvements, thanks to some deeper data model changes. The “rich” editor is now able to work with messages with multiple selectors, with further improvements incoming as this work progresses.
As with all other aspects of Pontoon, please let us know if you’ve any comments on these changes as they are deployed.
Pretranslation
We started evaluating the Pretranslation feature on pontoon.mozilla.org. Testing is currently limited to 2 locales, but we’ll start adding more when we reach the satisfactory level of quality and stability.
New contributions
Thanks to our army of awesome contributors for recent improvements to our codebase:
Willian made his first contributions to Pontoon, including upgrading our legacy jQuery library.
Tomás fixed a bug in the local setup, which was also his first contribution.
Vishal fixed several bugs in the Pretranslation feature, which he developed a while ago.
Events
Want to showcase an event coming up that your community is participating in? Contact us and we’ll include it.
Friends of the Lion
Image by Elio Qoshi
Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!
I’m going to try to keep a monthly newsletter like this going so people can keep up to date on what’s going on with the Bugzilla project. Hopefully in the future I’ll get it out a little closer to the beginning of the month. With that said, here’s a review of what happened in December 2022:
Dylan continued to work on simplifying the docker config in Harmony to be usable out of the box without depending on Mozilla’s infrastructure and private docker repos. (still in progress)
Justdave wrote a blog post detailing the current project status.
Justdave communicated with multiple organizations who made inquiries about donating funds.
Justdave wrote up a funding proposal at the request of an organization who might be interested in funding some of our work in a more substantial way.
Justdave engaged in conversations with the Mozilla Foundation about how to handle the legal/financial side of the Bugzilla project going forward, since they technically own it, even though it’s treated as a community project. (still in progress – this needs to be resolved before we can accept the above-mentioned donations, though directly funding individual developers can still happen without that)
Justdave spent time experimenting with intercepting and modifying GitHub webhooks in pursuit of Bug 1802737, a prerequisite to committing security bugs prior to the upcoming releases. (still in progress)
We’re making slow and steady progress. I’m starting to think we won’t get the big releases that I mentioned in the blog post last month out as soon as hoped, but we’re definitely getting closer.
Most of the fixed bugs in December had to do with cleaning up the website (fixes for things broken by the site redesign).
Upcoming plans for January (and perhaps February) :
Finish off Docker support for both 5.2 and harmony (5.9).
Finish the infrastructure fixes (mostly GitHub and Bugzilla integration with the chat bots) needed to commit the security fixes.
Continue the discussions with Mozilla Foundation in hopes of being able to accept donations soon.
Set up a triage party to work on winnowing down the older bug reports.
Get the releases out the door.
The rest of this post is a bunch of statistics, so if you’re not into that stuff you can stop reading now.
There were 11 new bugs filed in December, of which one of them is classified as a low-severity security bug. 2 of the bugs were for the website, and 1 for the IRC bot, the remainder for Bugzilla itself.
Overall there were 17 bugs touched during December, including the above 11.
Much like taking a space walk, performing a content audit can be exciting, overwhelming, and a little scary. Who knows what content complexities and usability meteors you’ll encounter in the nooks and crannies of your product’s terrain? You might even be going where no content designer has gone before — moonwalking your way through a dusty, dated workflow from your pre-style guide era.
The good news is that, like a space walk, a content audit is much less intimidating when you’re well prepared. The more work you put in up front, the smoother your audit will go. So before you slip on that space helmet and start taking screenshots, follow these tips from my Button 2022 conference talk to set yourself up for a successful content audit.
1. Find your stakeholders
Every good astronaut has a top-notch ground control team in place before takeoff. If you try to go it alone, you could find yourself lost in space with a giant list of product improvements and no way to implement them. That’s why starting an audit by identifying your major stakeholders is key. You can always add to this list later, but here’s who you’ll likely start with:
Product & UX
Find the product managers, UX designers, UX researchers, and content designers currently responsible for the area or feature you’re auditing. They’ll be the ones you’ll partner with to translate your audit findings into product improvements, so it’s vital to keep them involved.
In some cases, it may be helpful to identify people who worked on the product previously. Try reaching out to them to learn historical context, or ask if they’d be okay with fielding ad hoc questions.
Engineering
Try to find at least one engineer or engineering manager who can help with technical questions during your audit. You can also work with this engineer later on to size and scope findings into tickets for the backlog.
Marketing
You might want to involve someone from the marketing team if your audit area overlaps with acquisition activities, such as a product landing page, app store page, or a create account flow.
They’ll likely have valuable feedback on voice and tone as well as aligning product copy and design with marketing assets and campaigns.
2. Set goals
Space missions are expensive — and so are content audits. They’re time-intensive and create work outside of just content design. To avoid burning your precious mental rocket fuel without making actual product improvements,it’s important to set goals that are realistic to the resources your team can devote to auditing and fixing issues.
Suggested goals
To increase your chances of mission success, try focusing your audit on a specific feature or flow with a concrete goal in mind, like:
Build a backlog of general UX improvements to address in the future
Avoid goal traps
Watch out for goals that are too broad, too vague, or too narrowly focused on fixing surface-level microcopy issues without acknowledging that there may be bigger UX or engineering issues at play.
Here are two common “goal traps” to avoid when stakeholders are requesting an audit (based on real-life failed audit missions).
Goal trap 1: Roll out a new voice to an entire product at once
This is an unrealistic goal unless teams can devote the necessary resources to achieve this and tie to a specific ROI measurement.
How to reframe: Identify high-impact areas to audit first. Start with one area and then expand as time and resources allow.
Goal trap 2: We didn’t have a content designer when we built this, and we want to get some “fresh eyes” on the content
It’s great that your team is excited about having a content designer, but you should always ask: What resources will be available for implementing improvements? Often, there’s an expectation that you’ll simply point out surface-level copy issues with no plan or support for addressing underlying UX issues. The impact will be limited and may not be worth the time invested in the audit.
How to reframe:Identify UX opportunities and inconsistencies and devote the necessary UX, product management, and engineering resources to fixing them.
Or instead of an in-depth audit, you can just create an overview of common content issues in the product and discuss how to better approach these as a team during future projects.
<figcaption>Photo by NASA on Unsplash</figcaption>
3. Define your scope
On your space walk, are you going to photograph every inch of your product planet, or are you going to zoom in on a few problem areas? Since scope can make or break an audit, you should define your parameters before you set foot off the ship.
If your scope is too large, you risk overextending your timeline. And you may end up with an unmanageable list of issues that makes prioritization an overwhelming — if not impossible — task. To start, try picking a product area that one person can audit within one week, maximum. Any bigger, and you could risk getting overwhelmed.
Why one person? Involving multiple people in your first audit can be tricky unless you are all committed to cataloging things the same way. If you’d like to break up a bigger audit scope amongst a team of people, try having one person pilot this approach on a few smaller areas to nail down the documentation process and then teach it to others.
Once you’ve defined an area to audit, think about setting additional parameters around devices and content states. Every parameter you add increases the time your audit will take, so consider scope impacts carefully.
Devices:
Will your audit cover desktop, mobile phones, tablets, or all three?
Which operating systems will you include?
If you’re including multiple devices and/or operating systems, how will you document issues that occur on multiple platforms?
States:
Will your audit include error states or just happy paths?
Will your audit cover harder-to-capture microcopy (behind form field menus and tooltips, for example)? Or just stick to the surface?
4. Share the plan
By now you’re itching to put on your space suit and start walking through your product, but first you should take time to document what you decided in steps 2 and 3 and share it with the stakeholders you identified in step 1.
Feel free to use a doc, a deck, or whatever format works for you. It will pay off to have this artifact to refer to later!
5. Build your audit toolbox
You’re almost ready to launch your audit mission. But first, you need to have the right tools for the job.
Screenshot tools
Feel free to use your device’s native screenshot tool, but here are additional apps that can make the process easier (all are free unless otherwise noted with $).
Recording yourself walking through an audit area on mobile allows you to capture screenshots later on desktop, which can save a lot of time. Share the video to your desktop using Airdrop, Slack, Google drive, or Snapdrop.
Pick an audit spreadsheet template that best fits your needs — like this one for example — and add or subtract columns depending on your needs. Remember: every audit is different, and no template is one-size-fits-all.
Log each issue on its own line. This way, you can easily filter by issue type, product area, and priority so you can quickly sort issues and identify trends.
Ready to blast off?
Hopefully by now you’re feeling ready to take your first small steps (or giant leap) into your product content audit. All of the prep work you put in up front ensures you can now focus on the mission at hand: identifying content and usability issues that you’ll soon transform into real product improvements.
I’m delighted to introduce you to Erik Avila who is joining our team as an additional Community Support Advocate. Here’s a short intro from Erik:
Hi! I’m Erik. I’ll be helping the mobile support team to moderate and send responses to app reviews, also, I’ll help identify trends to track them. I’m very excited to help and work with you all.
Erik will be helping out with the Mobile Store Support initiative, alongside with Dayana. We also introduced him in the community call last week.
Time surely flies, and here we are, already at the end of the year. 2022 has been an amazing year for the Customer Experience team. We welcomed 5 new people to our team this year, including 2 engineers, and 1 technical writer.
As an extension of our team, the SUMO community definitely plays an important role in our achievements. Let’s take a moment to reflect on what the community has accomplished this year.
Forum
From January 1 to November 11, we posted 49K answers (from non-OP* users) to 28K questions posted on the forum. On average, our answer rate within 72 hours is 75% while our solved rate is around 14%. In a month, around 300 users have contributed to the forum (including the OP).
From January 1 to November 11, the KB contributors have made 1746 revisions (all contributor revisions) with a 73% review rate and 95% approval rate. On average, we have in total of 30 contributors to our Knowledge Base on a monthly basis.
Localization
The localization community had been doing great things this year by submitting to 13K revisions from January 1 to November 11. The review rate for the localization is looking pretty good at 90%, while the approval rate is 99%. On average, there are around 73 contributors involved on a monthly basis, from around 30 locales. We saw the PT-PT community has been recently re-activated as well after the pandemic, which is amazing.
Social Support
From January 1 to December 28, the Social Support Contributors have contributed to 908 responses in total (39.6% of our total responses). We also have been able to improve our resolved rate from 58% in 2021 to 70% this year.
Mobile Store
Last but not least, from January 1 to Dec 28, the Mobile Store Support contributors have contributed to 1.6K replies and onboarded 4 new contributors this year. The response conversion (comparison between total responses against total moderation) rate is also looking good, with 47% on average throughout the year. Meaning, 47% of reviews that contributors moderated are replied to.
Apart from that, we have also managed to work on a few projects throughout the year:
Mobile hybrid support
In Q2, we hired a Community Support Advocate whose primary role is to support the mobile store ecosystem by moderating questions in Google Play Store and Apple App Store. This Community Support Advocate is working alongside contributors on Google Play Store and takes primary care of the App Store reviews as well as moderating forum questions (mainly by adding tags) for the mobile products to this day.
With the spirit of continuing the community program, we also rename the Mobile Support program to Mobile Store Support in Q4 with the introduction of the new contributor onboarding page.
Locale audit
We also did a locale audit in Q2 to check on the stage of our localization community. I presented the result of the audit on the community call in June.
Internal community dashboard
After the platform team fixed the data pipeline issue that was going on since the beginning of the year, Q3 follows with a project to create an internal community dashboard. I gave a brief overview of the project back then on the community call in July.
MR2022
Major Release 2022 went smoothly in Q3 because of the support of you all. Similar to what we did for the Major Release last year, we also prepared a list of changes for contributors and monitor the inbounds closely across the channels that we oversee. This time, the product team also worked with the CMO team to collect rapid feedback about some of the major features that we released in Firefox 106.
Contributor onboarding launch
In early November, we finally got to see the new face of our contributor onboarding page, which was formerly called the Get Involved page. You can learn more about this update in this blog post or by directly checking out the page.
It was not all rainbows and butterflies, though. On September 2022, we learned the news about the passing of one of our top contributors in the forum, FredMcD. It was definitely a great loss for the community.
Despite all the bumps, we do survive the year 2022, with grace and triumph. All the numbers that I presented at the beginning are not merely metrics. They are reflections of a collective effort from all of you, Mozillians around the world, who work tirelessly to keep the internet healthy and supported each other in the spirit of keeping the internet as a global public resource, open and accessible to all. I’m proud of working alongside you all and to reflect on what we have accomplished this year.
And yes, let’s keep on rocking the helpful web through 2023 and beyond!
PS!
If you’re a looker and interested in contributing to Mozilla Support, please head over to our Contribute page to learn more about our programs!
As we continue to develop extensions support on Firefox for Android, we’re pleased to announce new additions to our library of featured Android extensions. To access featured extensions on Firefox for Android, tap Settings -> Add-ons.
Based on currently available APIs, performance evaluations, and listening to requests from the Mozilla community, here are five new extensions now available to Firefox for Android users…
Firefox Relay
Mozilla’s own Firefox Relay is now available for mobile usage. The extension lets you easily generate email masks that will forward messages to your authentic email while hiding your address from unwanted spam, or worse, hackers.
Tampermonkey on Android.
Tampermonkey
One of the most popular userscript managers makes its way to mobile. Tampermonkey top features include automatic update checks, an intuitive display of running scripts, plus browser and cloud storage sync.
Read Aloud: A Text to Speech Voice Reader
Have you ever wanted your news or other web pages (even PDF’s) read aloud so your hands and eyes are free to focus on other things? Read-Aloud: A Text to Speech Voice Reader can now accommodate you on Android — in 40+ languages.
AdNauseum
More than just an effective ad blocker, AdNauseum punches back against privacy invasive ad tech by clicking a bunch of blocked ads in the background so advertisers can’t build an accurate profile of your interests.
ClearURLs
A simple extension that provides a powerful privacy feature — ClearURLs automatically strips away tracking elements from web links you open.
Create extension collections on Firefox for Android Beta
By following these instructions you can now create your own custom extension collections on Firefox for Android Beta (previously, collections were only available on Nightly). Name the collection anything you like, so long as there aren’t any spaces in its title. When creating your collection, you’ll see a number in the Custom URL field; this is your user ID. You’ll need the collection name and user ID to configure Beta in the following way:
Once created, simply add extensions to your collection. Each collection generates a custom URL so you’re to share it with others.
Are more extensions coming to Firefox for Android?
Absolutely. Right now we’re focused on implementing Manifest version 3 (MV3) for Firefox desktop (i.e. wide ranging foundational changes to WebExtensions API). In 2023 we’ll begin work on the mobile adoption of MV3. Though we’re still early in planning, MV3 will certainly offer a number of advances for mobile extensions, such as elegant handling of process restarts and improved security by splitting extensions into their own processes, while also retaining critical MV2 features that support privacy and ad blocking capabilities. Indeed our goal is to design MV3 for mobile in such a manner we’re able to open up the discoverability of mobile extensions beyond the short list available today. As plans take shape, we’ll be sure to keep you informed. In the meantime you’re welcome to join conversations about extensions development on Firefox Add-ons Discourse.
So I posted a bunch of this a few months ago on the developers mailing list but it’s time to get it in front of a bigger audience.
I am trying to kick-start getting stuff moving again with Bugzilla since most of the core Bugzilla volunteers have had job changes over the last few years that have left them with less time to spend on the project, so things have been very slow going for a while. For those that don’t know, I’ve been more or less of a figurehead of a project leader for a number of years now, not having much time to spend on Bugzilla, but not having anyone in a position to be able to step in to replace me, and only stepping in myself to make decision calls when the other developers were at an impasse. I’ve attempted to hand off control of the project to someone else twice in the last 10 years or so, and both times, the person I was about to hand off to got a new job and didn’t have time for it anymore just before we were about to do the hand-off (on the plus side, that happened before they took over and not after). It takes a while for someone to build the trust needed to know I’m leaving it in good hands, so without a lot of active developers it’s hard to get someone in place to do that. But I’ve had some life changes of my own now, which actually give me more time to spend on Bugzilla finally, so I’m getting back in the saddle and taking direct control again. I’ve probably poked at it more in the last 5 or 6 months than I have in the last 5 or 6 years combined.
I have started a new consulting business, and I’ve been trying to structure it in a way that allows me to spend time on Bugzilla again. (If you want to hire me to help with your Bugzilla, or help funding work on upstream Bugzilla, feel free to contact me, even if I’m not publicly advertising yet)
Now back to the nitty gritty and my plans for this project.
There is a call for help in this post below the release information. If you can give us a hand it would be greatly appreciated. Not all of it is code-related, so there might be something you can do even if you’re not a coder!
Infrastructure Updates
Prior to a few weeks ago, our main website hadn’t been updated beyond quick bugfixes to content in a long time. LCP recently did a full overhaul of the website to modernize it and make information easier to find. We deployed this a few weeks ago, so go have a look! It looks awesome! Also, the new website has RSS feeds!
Also over the last couple months, I’ve been working on getting some of the project infrastructure back in place to help support active development. Among the list of things that have gotten done are:
getting our testing suite moved into GitHub Actions so that it runs automatically on every commit
updating our IRC bot, both to get it to talk to the IRC server again (which it stopped doing recently due to outdated SSL versions), and to update the mail parsing code in it to handle newer versions of Bugzilla (most importantly bugzilla.mozilla.org, where our own notification emails would be coming from).
Setting up a private Git repository for security commits so that we can stage and test them prior to release without exposing them to the public prior to disclosures.
The Release Plans
I would like to put out a new multi-branch release of Bugzilla as soon as we can get all the pieces in place to do so. I was hoping to do this within a few weeks of the original post to the developers list, but that was back in August and it hasn’t happened yet. At this point I think we’ll be really lucky if it happens before the end of December; though mid-January is definitely a possibility. As a forewarning to everyone, there will be security content in it, and that’s part of the holdup. For obvious reasons I can’t ask for help with the security bugs outside of the existing core developer team, as that risks exposure to hackers that might take advantage of it before users have a chance to update. So we ask for your patience while we work through these issues and get them ready to land.
The 4.4 branch has been on life support for a LONG time (it was initially released in 2013!!!), supports outdated OSes that are hard to find or install, let alone test for these days, and we’ve been itching to drop it for a long time. But our support policy says that we have to support it for 4 months after the following two major releases. The next major release after 4.4 was 5.0, and there have been no major releases after that, which means that 4 month countdown hasn’t even started yet.
4.4.14 – I am intending this to be the final release of the 4.4 branch (barring any additional security issues being found in the next 4 months) as the 5.2 release below will start that 4 month countdown to End-of-Life this branch.
5.0.4.1 – Why 5.0.4.1 when there’s a 5.0.6 release? Well, if you paid attention to the change logs, 5.0.5 and 5.0.6 contained a massive schema change, as well as reformatting almost all of the Perl code in the source, both of which are a violation of our support policy for a stable branch (a new-to-the-process release manager pushed the release out not realizing that, and by the time we caught it, it was too late). A lot of people noticed this and never upgraded to 5.0.5 or 5.0.6, since they didn’t contain any security fixes. 5.0.4.1 will give those people additional fixes for 5.0.4 without forcing them to pick up those schema and code reformatting changes. Additional updates to the 5.0 branch from now on will continue from 5.0.4.2 and onward.
5.2 – This will be the next major release, and will start the 4 month countdown for discontinuing the 4.4 branch. 5.2 is forked from the 5.0 branch after 5.0.6, and will contain those schema and code formatting changes from 5.0.5 and 5.0.6 in it. So if you did upgrade to 5.0.6, 5.2 will be equivalent to a point upgrade for you. Those schema changes should have caused a major release to happen anyway, so this is just fixing the numbering problem with that release (i.e. 5.0.5 should have been called 5.2 to begin with). Note that if you are using the 5.1.x development releases, those did NOT feed into this, and 5.2 would actually be a downgrade for you.
5.1.3 – The 5.1 branch is basically dead, as we’ve put all of our resources into finishing off the Harmony release (see 5.9.1 below). We’re going to encourage people on 5.1.x to move to Harmony, but you’ll want to be mindful of the release blockers first before you make the jump. There are some features in 5.1.x that were implemented differently in Harmony, and the code to migrate the related data may or may not work yet (if the feature in question is listed on the release blockers and you use it, you’ll want to wait for now). Even though this branch is dead, we’re going to put out a release with the current batch of security fixes so you aren’t left high and dry before Harmony is ready for you.
5.9.1 – This will be the first official release off the Harmony branch, and will be classified as a developer preview release, not for production use. This is what will eventually be Bugzilla 6. The code is mostly good enough to use right now, but there are still showstoppers to be able to fully release it as a production release. There are also a few gotchas when upgrading from older versions of Bugzilla. If you’re interested in helping make Bugzilla 6 happen, that list of showstoppers is here.
Immediate Help Wanted
There’s a few things (not all necessarily code related) that I would love to get help with prior to the above releases. This list is not entirely the same as the one that was in the original post to the developers list. Some of the items in that list actually got done! Yay! Thanks to those of you who pitched in!
Documentation. This is going to be primarily for the newer branches, but the older ones are going to need some help as well. Installation instructions mostly. The examples in the docs use ancient versions of the OSes that are given as sample installs, and no sane person is going to be using an OS that old on a new install. So the installation sections of the docs need to be updated to use modern versions of the OSes in the instructions and examples. See also Bug 1785943. This has been done for the 5.0 and 5.2 branches (thanks, LCP!) but still needs to be done for 4.4 and Harmony. In fact, Harmony needs a LOT of documentation help, as what’s there now is pretty specific to trying to produce a testing environment for bugzilla.mozilla.org, rather than a standalone Bugzilla.
Section 508 Compliance Audit. There are a number of US government agencies who use Bugzilla internally (NASA is a publicly visible example). New US government projects have to comply with the new accessibility guidelines in Section 508 of the Communications Act, so if we want them to be able to upgrade we need to comply (at least in our newer versions). See https://section508.gov/. There is a template for a compliance statement at https://www.section508.gov/sell/vpat/. I would love to get a volunteer (or a company who can sponsor someone?) who could audit the 5.2 and harmony branches for compliance, file bugs for things that are violations, and figure out how much of the VPAT we can actually provide at this point. Even if we’re not compliant yet (I suspect we aren’t) I would love to be able to provide a statement with the 5.2 release saying how compliant we are, and listing what’s left to be fixed to make us compliant. See also Bug 1785941.
Ongoing Help Wanted
There’s also a few things not specifically related to the above release that we’d love to get help with on an ongoing basis:
Bug Triage! As you probably noticed from the lack of updates around here in a while, the bug list hasn’t been getting paid much attention to, either. Part of getting this project moving again means re-triaging the existing bug reports. Some of them are really ancient and may not even apply to the current code-base anymore. I’m going to have another blog post coming in the next day or two with information on this topic (specifics for how to help with it), so keep an eye out for that post!
Paid Developer Time. If you are a business that makes use of Bugzilla, and has a staff person responsible for maintaining your Bugzilla installation, and that person is willing, please consider officially sponsoring that person to help with upstream Bugzilla development for at least a few hours per week. Most of our lack of development lately has happened because the last few companies that used to do that stopped providing developer time during the economic downturn a few years back (either laid off said person or pulled them away to work on other things), and they haven’t returned. The developers we have currently are all volunteer, and most of them are struggling to find time to work on it.
In Conclusion…
If you can help with any of these things, visit us on IRC or Matrix (links to both can be found in the left sidebar on https://bugzilla.org/ ), join the developer mailing list and post there, or add comments to the above-listed bugs.
After much fiddling and fudging (well, not really), just managed to release build 3 of SeaMonkey 2.53.15b1. Build 1 was a mix up and not sure what happened with build 2.
Due to some confusion on my part, I had released the wrong set of binaries from the Windows builder. I’ve disabled all updates and we’re redoing the whole build again.
It’s been a while since our last monthly update. Ever since our internal dashboard was broken, we didn’t have an easy way to export the platform data. Now that we got access to our data back, let’s talk about what we’ve missed.
Welcome note and shout-outs
Welcome to Daniel López, Spencer Peck, Rafael Oliver, and Edoardo Viola. Thanks for joining the Social & Mobile Store Support.
Thanks to every one of you for contributing to SUMO. Those who replied to our users in the forum, Twitter, or Play Store reviews. All of you who helped us improve the Knowledge Base. Last but not the least, to many of you who helped translate the help articles to your local languages. Thank you all so much! I can’t stress enough that SUMO cannot exist without you. ❤️❤️❤️
If you know anyone that we should feature here, please contact Kiki and we’ll make sure to add them in our next edition.
Community news
Forum question detail is now limited only to these groups and the trusted contributors group.
Our new contribute page is finally released. Check out what we’ve changed and share the news to your network and local community.
We have a new Technical Writer joined the content team on late October. Please join me to welcome to Lucas.
Learn more about Hubs transition and how it impacts the support team in this blog post.
Watch the community call in December to learn more about what we’ve accomplished throughout this year.
Catch up
Watch the monthly community call if you haven’t. Learn more about what’s new in August, September, October, November and December! Reminder:Don’t hesitate to join the call in person if you can. We try our best to provide a safe space for everyone to contribute. You’re more than welcome to lurk in the call if you don’t feel comfortable turning on your video or speaking up. If you feel shy to ask questions during the meeting, feel free to add your questions on the contributor forum in advance, or put them in our Matrix channel, so we can answer them during the meeting.
If you’re an NDA’ed contributor, you can watch the recording of the Customer Experience weekly scrum meeting from AirMozilla to catch up with the latest product updates.
Consider subscribe to Firefox Daily Digest to get daily updates about Firefox from across different platforms.
* Locale pageviews is an overall pageviews from the given locale (KB and other pages)
** Localization progress is the percentage of localized article from all KB articles per locale per Dec 8,2022
Top 5 localization contributors in the last 90 days:
To catch up on product releases update, please watch the recording of the Customer Experience scrum meeting from AirMozilla. You can also subscribe to the AirMozilla folder by clickling on the Subscribe button at the top right corner of the page to get notifications each time we add a new recording.
A product is first an idea, then a project, and then a prototype. It is tested, refined, and localized so that it is accessible to users in different regions. When the product is released into the world, these users need to be supported. Of course, there are always going to be improvements, fixes, and new features, and those will also need to be planned, developed, tested…and so on, and so forth…
What do all these stages have in common?
Here at Mozilla, our awesome community is there every step of the way to support and contribute to our products. None of what we do would be possible without this multicultural, multilingual community of like-minded people working together to be a better internet.
Of course, contributions to our products are not everything that the community does. There is much more that our community creates, contributes, and discusses.
However, as a major release recently happened we want to take the occasion to celebrate our community by giving you a peek at how their great contributions helped with version 106 (as well as all versions!) of Firefox.
Ideation (Mozilla Connect)
Ideas for new features and products come from many different sources. Research, data, internal ideas, and feature requests during Foxfooding…at Mozilla one of the sources of new ideas is Mozilla Connect.
Mozilla Connect is a collaborative space for ideas, feedback, and discussions that help shape future product releases. Anyone can propose and vote for new ideas. The ideas that gain more support are brought to the appropriate team for review.
Firefox Picture in picture subtitles was a feature requested by the Mozilla Connect Community!
Connect is also a place where Mozilla Product Managers ask for feedback from the community when thinking about ways to improve our product, and where the community can interact directly with Product Managers and engineers.
In this way, the community contributes to continuous product improvement and introduces diverse perspectives and experiences to our product cycle.
Connect played a role in the latest Firefox Major release on both sides of the ideation cycle.
Are you enjoying the new PDF editor’s functionalities? Then you should know that the community discussed this idea in Connect. After many upvotes, the idea was officially brought to the product team.
After the release is done, the community joined discussions with Firefox Product Managers to give feedback and new suggestions on the new features.
Mozilla developers work side by side with the Community.
Community members find and help solve product bugs and help with the development of different features.
Community is fundamental for the development of Firefox, as community members routinely add their code contributions to the Nightly version of Firefox!
You can check out how staff members and contributors work together to solve issues in the Nightly version of Firefox.
Interested? Check out how you can submit your first code contribution. You can also discover more about Nightly here.
Testing and reporting bugs
There are many ways in which the Community helps find and report bugs. One of these is a Foxfooding campaign.
Because we still have to meet a Mozillian that does not enjoy a good (and…less good) pun, Foxfooding is the Firefox version of Dogfooding.
This is where we make a feature or a product available to our community (and staff) before it is released to the public. Then we ask them to use it, test it, and submit bugs, product feedback, and feature requests.
This is an incredibly precious process, as it ensures that the product is tested by a very diverse (and enthusiastic) group of people, bringing unexpected feedback, and testing in much more diverse conditions than we could do internally.
Plus it is, you know, fun ;)
We ran a Foxfooding campaign for the last Major Release too! And the community all over the world submitted more than 60 bugs.
Foxfooding campaigns are published here. You can subscribe to our Community Newsletter to be notified when one is starting.
Furthermore, community members find, report, and help solve Firefox Nightly bugs, as well as bugs that appear in other Firefox versions.
In fact, simply using Firefox Nightly (or Beta) is a way to contribute easily to the Mozilla project. The simple fact of using Nightly sends anonymous data on and crash reports that help discover issues before we ship to the general public.
Localization (l10n)
Currently, Firefox is localized in 98 languages (110 in the Nightly version) and that is entirely thanks to the effort of a determined international community.
Localization is important because we are committed to a Web open and accessible to all— where a person’s demographic characteristics do not determine their online access, opportunities, or quality of experience.
The Mozilla Localization effort represents a commitment to advancing these aspirations. They work together with people everywhere who share the goal to make the internet an even better place for everyone.
The community worked really hard on the global launch for the Major release! Thank you to all localizers that took part in this global launch. There were more than 274 folks working on, and (approximately) 67,094 translations!
Users Support (SUMO)
Once a product is out into the world, the work is far from done! There are always bugs that need reporting, users who need troubleshooting help, and new features that need explanation…
At Mozilla, the Mozilla Support a.k.a. SUMO community is the one supporting users all over the world, answering support questions through the forum, socials, or mobile app stores, creating helpdesk articles, and localizing the articles.
When it’s done right, providing high-quality support may contribute to our user’s loyalty and retention. Plus, it can help improve the product: when we bring the data back to the product team, we can establish a feedback loop that can be delivered into product improvements as well.
The SUMO community is actively helping users during the Major release. Up until now:
3975 forum responses were sent during the release from 2344 questions that were submitted.
12 support articles were created, updated, and translated into Greek, French, Italian, Japanese, Russian, Portuguese, Simplified Chinese, Polish, and many more.
They posted responses to review in the 445 Google Play Store responses
They answer 88 Twitter questions
And they are still going strong!
Want to Join?
Would you also like to contribute? Our products are one of the ways in which we shape the web, and protect the privacy of our users. Getting involved is a great way to contribute to the missions and get in touch with like-minded people.
The SeaMonkey Project is proud to announce the immediate release of SeaMonkey 2.53.15 Beta 1.
Please check out [1] or [2].
:ewong
PS: SeaMonkey 2.53.15 Beta 1 was slated to be released around November 15th or so. However, I wasn’t able to do the release due to a personal issue that required my major attention. I apologize for the delay.
I’m delighted to share this news with you. The Hubs team has recently transitioned into a new phase of a product. If in the past, you needed to figure out the hosting and deployment on your own with Hubs Cloud, you now have the option to simply subscribe to unlock more capabilities to customize your Hubs room. To learn more about this transformation, you can read their blog post.
Along with this relaunch, Mozilla has also just acquired Active Replica, a team that shares Mozilla’s passion for 3D development. To learn more about this acquisition, you can read this announcement.
What does this mean for the community?
To support this change, the SUMO team has been collaborating with the Hubs team to update Hubs help articles that we host on our platform. We also recently removed Hubs AAQ (Ask a Question) from our forum, and replaced it with a contact form that is directly linked to our paid support infrastructure (similar to what we have for Mozilla VPN and Firefox Relay).
Paying customers of Hubs will need to be directed to file a support ticket via the Hubs contact form which will be managed by our designated staff members. Though contributors can no longer help with the forum, you are definitely welcome to help with Hubs’ help articles. There’s also a Mozilla Hubs Discord server that contributors can pop into and participate in.
We are excited about the new direction that the Hubs team is taking and hope that you’ll support us along the way. If you have any questions or concerns, we’re always open to discussion.
The first computer I owned shipped with 128 KiB of RAM and to this day I’m still jarred by the idea that applications can run out of memory given that even 15-year-old machines often shipped with 4 GiB of memory. And yet it’s one of the most common causes of instability experienced by users and in the case of Firefox the biggest source of crashes on Windows.
As such, at Mozilla, we spend significant resources trimming down Firefox memory consumption and carefully monitoring the changes. Some extra efforts have been spent on the Windows platform because Firefox was more likely to run out of memory there than on macOS or Linux. And yet none of those efforts had the impact of a cool trick we deployed in Firefox 105.
But first things first, to understand why applications running on Windows are more prone to running out of memory compared to other operating systems it’s important to understand how Windows handles memory.
All modern operating systems allow applications to allocate chunks of the address space. Initially these chunks only represent address ranges that aren’t backed by physical memory unless data is stored in them. When an application starts using a bit of address space it has reserved, the OS will dedicate a chunk of physical memory to back it, possibly swapping out some existing data if need be. Both Linux and macOS work this way, and so does Windows except that it requires an extra step compared to the other OSes.
After an application has requested a chunk of address space it needs to commit it before being able to use it. Committing a range requires Windows to guarantee it can always find some physical memory to back it. Afterwards, it behaves just like Linux and macOS. As such Windows limits how much memory can be committed to the sum of the machine’s physical memory plus the size of the swap file.
This resource – known as commit space – is a hard limit for applications. Memory allocations will start to fail once the limit is reached. In operating system speech this means that Windows does not allow applications to overcommit memory.
One interesting aspect of this system is that an application can commit memory that it won’t use. The committed amount will still count against the limit even if no data is stored in the corresponding areas and thus no physical memory has been used to back the committed region. When we started analyzing out of memory crashes we discovered that many users still had plenty of physical memory available – sometimes gigabytes of it – but were running out of commit space instead.
Why was that happening? We don’t really know but we made some educated guesses: Firefox tracks all the memory it uses and we could account for all the memory that we committed directly.
However, we have no control over Windows system libraries and in particular graphics drivers. One thing we noticed is that graphics drivers commit memory to make room for textures in system memory. This allows them to swap textures out of the GPU memory if there isn’t enough and keep them in system memory instead. A mechanism that is similar to how regular memory can be swapped out to disk when there is not enough RAM available. In practice, this rarely happens, but these areas still count against the limit.
We had no way of fixing this issue directly but we still had an ace up our sleeve: when an application runs out of memory on Windows it’s not outright killed by the OS, its allocation simply fails and it can then decide what it does by itself.
In some cases, Firefox could handle the failed allocation, but in most cases, there is no sensible or safe way to handle the error and it would need to crash in a controlled way… but what if we could recover from this situation instead? Windows automatically resizes the swap file when it’s almost full, increasing the amount of commit space available. Could we use this to our advantage?
It turns out that the answer is yes, we can. So we adjusted Firefox to wait for a bit instead of crashing and then retry the failed memory allocation. This leads to a bit of jank as the browser can be stuck for a fraction of a second, but it’s a lot better than crashing.
There’s also another angle to this: Firefox is made up of several processes and can survive losing all of them but the main one. Delaying a main process crash might lead to another process dying if memory is tight. This is good because it would free up memory and let us resume execution, for example by getting rid of a web page with runaway memory consumption.
If a content process died we would need to reload it if it was the GPU process instead the browser would briefly flash while we relaunched it; either way, the result is less disruptive than a full browser crash. We used a similar trick in Firefox for Android and Firefox OS before that and it worked well on both platforms.
This little trick shipped in Firefox 105 and had an enormous impact on Firefox stability on Windows. The chart below shows how many out-of-memory browser crashes were experienced by users per active usage hours:
You’re looking at a >70% reduction in crashes, far more than our rosiest predictions.
And we’re not done yet! Stalling the main process led to a smaller increase in tab crashes – which are also unpleasant for the user even if not nearly as annoying as a full browser crash – so we’re cutting those down too.
Last but not least we want to improve Firefox behavior in low-memory scenarios by responding differently to cases where we’re low on commit space and cases where we’re low on physical memory, this will reduce swapping and help shrink Firefox footprint to make room for other applications.
I’d like to send special thanks to my colleague Raymond Kraesig who implemented this “trick”, carefully monitored its impact and is working on the aforementioned improvements.
Starting November 21, 2022 add-on developers are welcome to upload their Firefox Manifest version 3 (MV3) compatible extensions to addons.mozilla.org (AMO) and have them signed as MV3 extensions. Getting an early jump on MV3 signing enables you to begin testing your extension’s future functionality on Nightly to ensure a smooth eventual transition to MV3 in Firefox.
To be clear, Firefox will continue to support MV2 extensions for the foreseeable future, even as we welcome MV3 extensions in the release to general availability in Firefox 109 (January 17, 2023). Our goal has been to ensure a seamless transition from MV2 to MV3 for extension developers. Taking a gradual approach and gathering feedback as MV3 matures, we anticipate opportunities will emerge over time to modify our initial MV3 offering. In these instances, we intend to take the time necessary to make informed decisions about our approach.
Towards the end of 2023 — once we’ve had time to evaluate and assess MV3’s rollout (including identifying important MV2 use cases that will persist into MV3) — we’ll decide on an appropriate timeframe to deprecate MV2. Once this timeframe is established, we’ll communicate MV2’s closure process with advance notice. For now, please see this guide for supporting both MV2 and MV3 versions of your extension on AMO.
Mozilla’s vision for Firefox MV3
Firefox MV3 offers simplified and consolidated APIs, enhanced security and privacy mechanisms, and functionality to better support mobile platforms. As we continue to collaborate with other browser vendors and the developer community to shape MV3, we recognize cross-browser compatibility as a fundamental consideration. That said, we’re also implementing distinct elements to suit Firefox’s product and community needs. We want to give extension developers creative flexibility and choice, while ensuring users maintain access to the highest standards of extension customization and security. Firefox MV3 stands apart from other iterations of MV3 in two critical ways:
While other browser vendors introduced declarativeNetRequest (DNR) in favor of blocking Web Request in MV3, Firefox MV3 continues to support blocking Web Request and will support a compatible version of DNR in the future. We believe blocking Web Request is more flexible than DNR, thus allowing for more creative use cases in content blockers and other privacy and security extensions. However, DNR also has important performance and compatibility characteristics we want to support.
Firefox MV3 offers Event Pages as the background script in lieu of service workers, though we plan to support service workers in the future for compatibility. Event Pages offer benefits like DOM and Web APIs that aren’t available to service workers, while also generally providing a simpler migration path.
Over subsequent releases next year, we’ll continue to expand Firefox MV3 compatibility.
MV3 also ushers an exciting user interface change in the form of the new extensions button (already available on Firefox Nightly). This will give users direct control over which extensions can access specific web sites.
The extensions button will give Firefox users direct control over website specific extension permissions.
Users are able to review, grant, or revoke MV3 extension access to any website. MV2 extensions will display in the button interface, but permissions access is unavailable. Please see this post for more information about the new extensions button.
If you’re planning to migrate your MV2 extension to MV3, there are steps you can take today to get started. We always encourage feedback from our developer community, so don’t hesitate to get in touch:
Manifest V3 (MV3) is bringing new user-facing changes to Firefox, including an extensions button to manage installed and enabled browser extension permissions (origin controls), providing Firefox users control over extension access to their browsers. The first building blocks of this button were added to Nightly in Firefox 107 and will become available with the general release of MV3 in Firefox 109.
Extensions button
The extensions button will give Firefox users direct control over website specific extension permissions.
In MV2, host permissions are granted by the user at the time of install and there’s no elegant way for the user to change this setting (short of uninstalling/reinstalling and choosing different permissions). But with the new extensions button in MV3 in Firefox, users will have easy access and persistent control over which extensions can access any web page, at any time. Users are free to grant ongoing access to a website, or make a choice per visit. To enable this, MV3 treats host permissions (listed in the extension manifest) as opt-in.
The button panel will display the user’s installed and enabled extensions and their current permission state. In addition to managing host permissions, the panel also allows the user to manage, remove, or report the extension. Extensions with browser actions will behave similarly in the toolbar as in the panel.
Manifest V2 (MV2) extensions will also display in the panel; however users can’t take actions for MV2 host permissions since those were granted at installation and this choice cannot be reversed in MV2 without uninstalling the extension and starting again.
How to deal with opt-in permissions in extension code
The Permissions API provides a way for developers to read and request permissions.
With permissions.request(), you can request specific permissions that have been defined as optional permissions in the manifest:
const permissionsToRequest = {
permissions: ["bookmarks", "history"],
origins: ["https://developer.mozilla.org/"]
}
async function requestPermissions() {
function onResponse(response) {
if (response) {
console.log("Permission was granted");
} else {
console.log("Permission was refused");
}
return browser.permissions.getAll();
}
const response = await browser.permissions.request(permissionsToRequest);
const currentPermissions = await onResponse(response);
console.log(`Current permissions:`, currentPermissions);
}
This is handy when the request for permissions is tied to a user action like selecting a context menu item. Note that you cannot request for a permission that is not defined in the manifest.
function handleAdded(permissions) {
console.log(`New API permissions: ${permissions.permissions}`);
console.log(`New host permissions: ${permissions.origins}`);
}
browser.permissions.onAdded.addListener(handleAdded);
Finally, you can check for already existing permissions in two different ways: permissions.getAll() returns a list of all granted permissions and permissions.contains(permissionsToCheck) checks for specific permissions and resolves to true if, and only if, all checked permissions are granted.
Like regulators around the world, the US Federal Trade Commission (FTC) is exploring the possibility of new rules to protect consumer privacy online. We’re excited to see the FTC take this important step and ask key questions surrounding commercial surveillance and data security practices, from advertising and transparency to data collection and deceptive design practices.
Mozilla has a long track record on privacy. It’s an integral aspect of our Manifesto, where we state that individuals’ security and privacy on the internet are fundamental and must not be treated as optional. It’s evidencedinourproducts and in our collaboration with others in industry to forge solutions to create a better, more private online experience.
But we can’t do it alone. Without rules of the road, sufficient incentive won’t exist to shift the rest of the industry to more privacy preserving practices. To meet that need, we’ve called for comprehensive privacy legislation like the American Data Privacy and Protection Act (ADPPA), greater ad transparency, and strong enforcement around the world. In our latest submission to the FTC, we detail the urgent need for US regulators and policymakers to take action to create a healthier internet.
At a high level, our comments focus on:
Privacy Practices Online: Everyone should have control over their personal data, understand how it’s obtained and used, and be able to access, modify, or delete it. To that end, Mozilla has long advocated for companies to adopt better privacy practices through our Lean Data Practices methodology. It’s also important that rules govern not just the collection of data, but the uses of that data in order to limit harmful effects – from the impact of addictive user interfaces on kids to the use of recommendation systems to discrimination in housing and jobs.
Privacy Preserving Advertising: The way in which advertising is conducted today is broken and causes more harm than good. At the same time, we believe there’s nothing inherently wrong with digital advertising. It supports a large section of services provided on the web and it is here to stay, in some form. A combination of new research, technical solutions, increased public awareness, and effective regulatory enforcement can reform advertising for the future of the web.
Deceptive Design Practices: Consumers are being tricked into handing over their data with deceptive patterns, then that data is used to manipulate them. The use of deceptive design patterns results in consumer harms including limited or frustrated choice, lower quality, lower innovation, poor privacy, and unfair contracts. This is bread-and-butter deception – the online manifestation of what the FTC was established to address – and it is critical that the FTC has the authority to take action against such deception.
Automated Decision Making Systems (ADMS): For years, research and investigative reporting have uncovered instances of ADMS that cause or enable discrimination, surveillance, or other harms to individuals and communities. The risks stemming from ADMS are particularly grave where these systems affect, for example, people’s livelihoods, safety, and liberties. We need enforceable rules that hold developers and deployers of ADMS to a higher standard, built on the pillars of transparency, accountability, and redress.
Systemic Transparency and Data Sharing: We encourage the FTC to strengthen the mechanisms that empower policymakers and trusted experts to better understand what is happening on major internet platforms. To achieve this, we need greater access to platform data (subject to strong user privacy protections), greater research tooling, and greater protections for researchers.
Practices surrounding consumer data on the internet today, and the resulting societal harms, have put people and trust at risk. The future of privacy online requires industry to step up to protect and empower people online, and demands that lawmakers and regulators implement frameworks that create the ecosystem and incentive for a better internet ahead.
It is with great pleasure that I am announcing the launch of our new contribute page in SUMO a.k.a SUpport.Mozilla.Org. SUMO is one of the oldest contribution areas in Mozilla, and we want to show you just how easy it is to contribute!
There are many ways you can get involved with SUMO, so getting started can be confusing. However, our new contribute page should help with that, since the pages are now updated with simpler steps to follow and a refreshed design.
We also added two new contribution areas, so now we have five ways to contribute:
The first 3 areas are nothing new for SUMO contributors. You can contribute by replying to forum posts, writing help articles (or Knowledge Base articles as we call them here), or translating the help article’s content to your respective locales.
Providing support on social media channels is also nothing new to SUMO. But with the ease of tools that we have now, we are able to invite more contributors to the program. In 2020, we started the @FirefoxSupport account on Twitter and as of now, we have posted 4115 tweets and gained 3336 followers. If you’re a social media enthusiast, the Social Support program is a perfect contribution area for you.
Responding to user reviews on the mobile store is something relatively new that we started a couple of years ago to support the Firefox for Android transition from Fennec to Fenix. We realize that the mobile ecosystem is a different territory with different behavior. We wanted to make sure that we serve people where they need us the most, which means providing support for those who leave us app reviews. If this sounds more like your thing, you should definitely join the Mobile Store Support program.
Early next year, Firefox will release Mozilla’s Manifest V3 (MV3). Therefore, it’s an ideal time to consider migrating your Manifest V2 extensions. One of our goals throughout our approach to MV3 has been to gradually release new WebExtensions features that enable you to begin implementing APIs that are compatible with MV3. To this end, we recently released some exciting new features you should know about…
MV3 changes you can make to your extension right now
Event Pages
In Firefox MV3, we’re providing Event Pages as the background script. Event Pages retain several important features, including access to DOM and WebAPIs that are not available with the new service worker backgrounds used in Google Chrome.
We enabled Event Pages for MV2 (aka non-persistent background pages that can be closed and respawned based on browser events) in Firefox 106. This update is a major step toward MV3 because all extensions must adopt Event Pages in MV3. But you can make this change today and use new Event Pages benefits such as:
Resiliency against unexpected system crashes. Now we can restart a corrupted background page without hindering the user.
No need for an extension reboot to reset a background page.
Save on memory resources by putting idle background pages to sleep.
Now that your background script is non-persistent, you need to tell Firefox when to wake up the page if it’s suspended. There are two methods available:
Use an event listener like `browser.tabs.onCreated` in your background script. Event listeners must be added at the top level execution of your script. This way, if your background is sleeping Firefox knows to wake the script whenever a new tab is spawned. This works with nearly all events in the WebExtensions API. Here’s more info on adding listeners. (Note that Firefox recognizes arguments passed to addListener and does not create multiple listeners for the same set of arguments.)
Use `browser.runtime.getBackgroundPage` if you need a background page to run processes unrelated to events. For instance, you may need a background script to run a process while the user is involved with a browser action or side panel. Use this API anytime you need direct access to a background page that may be suspended or closed. Here’s more info on background script functions.
Menu items created by an event page are available after they’re registered — even if the event page is terminated. The event page respawns as necessary to menu events.
Registered scripts can be injected into matching web pages without the need for a running Event Page.
Scripting
You can take another big step toward MV3 by switching to the new Scripting API. This API consolidates several scripting related APIs — contentScripts.register(), tabs.insertCSS(), tabs.removeCSS(), and tabs.executeScript() — and adds capabilities to register, update, and unregister content scripts at runtime.
Also, arbitrary strings can no longer be executed because the code parameter has been removed. So you’ll need to move any arbitrary strings executed as scripts into files contained within the extension, or to the func property used with, if necessary, the args parameter.
MV3 will impose enhanced restrictions on several features. Most of these restrictions are outlined in the MV3 migration guide. By following the steps detailed in the guide, there are some ways you can begin modifying your MV2 extension to make it comply more closely with MV3 requirements. A few noteworthy areas include…
Conform to MV3’s Content Security Policy
Mozilla’s long-standing add-on policies prohibit remote code execution. In keeping with these policies, the content_security_policy field no longer supports sources permitting remote code in script-related directives, such as script-src or `’unsafe-eval’`. The only permitted values for the `script-src` directive is `’self’` and `’wasm-unsafe-eval’`. `’wasm-unsafe-eval’` must be specified in the CSP if an extension wants to use WebAssembly. In MV3, content scripts are subject to the same CSP as other parts of the extension.
Historically, a custom extension CSP required object-src to be specified. This is not required in MV3 and was removed from MV2 in Firefox 106 (see object-src in content_security_policy on MDN). This change makes it easier for extensions to customize the CSP with minimal boilerplate.
The Content Security Policy (CSP) is more restrictive in MV3. If you are using a custom CSP in your MV2 add-on, you can validate the CSP by temporarily running it as an MV3 extension. See the MV3 migration guide for details.
Upgrade insecure requests – https by default
When communicating with external servers, extensions will use https by default. Extensions should replace the “http:” and ”ws:” schemes in their source code with secure alternatives, “https:” and ”wss:”. The default MV3 CSP includes the upgrade-secure-requests directive, to enforce the use of secure schemes even if an insecure scheme was used.
Extensions can opt out of this https requirement by overriding the content_security_policy and omitting the upgrade-secure-requests, provided that no user data is transmitted insecurely through the extension.
Opt-in permissions
All MV3 permissions, including host permissions, are opt-in for users. This necessitated a significant Firefox design change — the introduction of the extensions button — so users can easily grant or deny website specific permissions at any time (the button is enabled on Firefox Nightly for early testing and feedback).
The extensions button gives Firefox users direct control over website specific extension permissions.
Therefore, you must ensure your extension has permission whenever it accesses APIs covered by a permission, accesses a tab, or uses Fetch API. MV2 already has APIs that enables you to check for permissions and watch for changes in permission. When necessary, you can get the current permission status. However, rather than always checking, use the permissions.onAdded and permissions.onRemoved event APIs to watch for changes.
Update content scripts
While content scripts continue to have access to the same extension APIs in MV3 as in MV2, most of the special exceptions and extension specific capabilities have been removed from the web platform APIs (DOM APIs). In particular, the extension’s host permissions no longer apply to Fetch and XMLHttpRequest.
CSP for content scripts
With MV2 no CSP is applied to content scripts. In MV3, content scripts are subjected to the same CSP as other parts of the extension (see CSP for content scripts on MDN). Notably, this means that remote code cannot be executed from the content script. Some existing uses can be replaced with functionality from the Scripting API such as func and args (see the “Scripting” section above), which is available to MV2 extensions.
XHR and Fetch
With MV2 you also have access to some APIs, such as XMLHttpRequest and Fetch, from both extension and web page contexts. This allows for cross origin requests in a way that is not available in MV3. In MV3, XHR and Fetch operate as if the web page itself was using them, and are subject to cross origin controls.
Content scripts can continue using XHR and Fetch by first making requests to background scripts. A background script can then use Fetch to get the data and return the necessary information to the content script. To avoid privacy issues, set the “credentials” option to “omit” and cache option to “no-cache”. In the future, we may offer an API to support the make-request-on-behalf-of-a-document-in-a-tab use case.
Will Chrome MV3 extensions work in Firefox MV2?
The release of MV3 in Firefox is distinct from Chrome. Add-ons intended to work across different browsers will, in most cases, require some level of adjustment to be compatible in both Firefox and Chrome. That said, we are committed to a high level of compatibility. We will be providing additional APIs and features in the near future. If you’ve converted your Chrome extension to Google’s MV3, you may be able to consolidate some of those changes into your Firefox MV2 extension. Here are a few areas to investigate:
Service Workers are not yet available in Firefox; however many scripts may work interchangeably between Service Workers and Event Pages, depending on functionality. To get things working, you may need to remove service worker specific APIs. See Service Worker Global Scope for more information.
DNR is not yet available in Firefox. Firefox retains WebRequest blocking in MV3, which can be used in place of DNR. When DNR is available, simple request modifications can be moved over to DNR.
The storage.session API is not yet available in Firefox. You can use other storage mechanisms in the meantime.
Hopefully, we’ve provided helpful information so you can use the new MV2 features to start your migration to MV3. As always, we appreciate your feedback and welcome questions. Here are the ways to get in touch:
The MDN Web Docs team recently undertook a project to revamp and reorganize the “Contribution Docs”. These are all the pages on MDN that describe what’s what – the templates and page structures, how to perform a task on MDN, how to contribute to MDN, and the community guidelines to follow while contributing to this massive open source project.
The contribution docs are an essential resource that help authors navigate the MDN project. Both the community as well as the partner and internal teams reference it regularly whenever we want to cross-check our policies or how-tos in any situation. Therefore, it was becoming important that we spruce up these pages to keep them relevant and up to date.
Cleanup
This article describes the updates we made to the “Contribution Docs”.
Reorganization
To begin with, we grouped and reorganized the content into two distinct buckets – Community guidelines and Writing guidelines. This is how the project outline looks like now:
You’ll now find all the information about open source etiquette, discussions, process flows, users and teams, and how to get in touch with the maintainers in the Community guidelines section.
You’ll find the information about how to write for MDN, what we write, what we regard as experimental, and so on in the Writing guidelines section.
Next, we shuffled the information around a bit so that logically similar pieces sit together. We also collated information that was scattered across multiple pages into more logical chunks.
For example, the Writing style guide now also includes information about “Write with SEO in mind”, which was earlier a separate page elsewhere.
We also restructured some documents, such as the Writing style guide. This document is now divided into the sections “General writing guidelines”, “Writing style”, and “Page components”. In the previous version of the style guide, everything was grouped under “Basics”.
Updates and rewrites
In general, we reviewed and removed outdated as well as repeated content. The cleanup effort also involved doing the following:
Removing and redirecting common procedural instructions, such as setting up Git and using Github, to Github docs, instead of repeating the steps on MDN.
Moving some repository-specific information to the respective repository. For example, a better home for the content about “Matching web features to browser release version numbers” is in the mdn/browser-compat-data repository.
Rewriting a few pages to make them relevant to the currently followed guidelines and processes.
Documenting our process flows for issues and pull requests on mdn/content vs other repositories on mdn. This is an ongoing task as we tweak and define better guidelines to work with our partners and community.
New look
As a result of the cleanup effort, the new “Contributor Docs” structure looks like this:
The list below will give you an idea of the new home for some of the content in the previous version:
“Contributing to MDN”
New home: Community guidelines > Contributing to MDN Web Docs
“Get started on MDN”
New home: Community guidelines > Contributing to MDN Web Docs > Getting started with MDN Web Docs
“Basic etiquette for open source projects”
New home: Community guidelines > Contributing to MDN Web Docs > Open source etiquette
“Where is everything on MDN”
New home: Community guidelines > Contributing to MDN Web Docs > MDN Web Docs Repositories
“Localizing MDN”
New home: Community guidelines > Contributing to MDN Web Docs > Translated content
“Does this belong on MDN Web Docs”, “Editorial policies”, “Criteria for inclusion”, “Process for selection”, “Project guidelines”
New home: Writing guidelines > What we write
“Criteria for inclusion”, “Process for selection”, “Project guidelines”
New home: Writing guidelines > What we write > Criteria for inclusion on MDN Web Docs
“MDN conventions and definitions”
New home for definitions: Writing guidelines > Experimental, deprecated and obsolete
New home for conventions: Writing guidelines > What we write
“Video data on MDN”
New home: Writing guidelines > How-to guides > How to add images and media
“Structured data on MDN”
New home: Writing guidelines > How-to guides > How to use structured data
“Content structures”
New home: Writing guidelines > Page structures
Summary
The Contribution Docs are working documents — they are reviewed and edited regularly to keep them up to date with editorial and community policies. Giving them a good spring clean allows easier maintenance for us and our partners.
I’m super delighted to introduce you to our new Technical Writer, Lucas Siebert. Lucas is joining the content team alongside Abby and Fabi. Some of you may meet him already in our previous community call in October. Here’s a bit more info about Lucas:
Hi, everyone! I’m Lucas, Mozilla’s newest Technical Writer. I’m super excited to work alongside you all to provide content for our knowledge base. You will find me authoring, proofreading, editing, and localizing articles. If you have suggestions for making our content more accurate and user-friendly, please get in touch!
Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.
Welcome!
Are you a locale leader and want us to include new members in our upcoming reports? Contact us!
New content and projects
What’s new or coming up in Firefox desktop
First of all, thanks to all localizers who contributed to a successful MR release (106) for Firefox desktop. While the new content wasn’t as large as previous major releases, it was definitely challenging, with new feature names added for the first time in a long time.
What’s next? We expect a period of stabilization, with bug fixes that will require new strings, followed by a low volume of new content. We’ll make sure to keep an eye out for the next major release in 2023, and provide as much context as possible for both translation and testing.
Now more than ever it’s a good time to make sure you’re following the Bugzilla component for your locale, testing Nightly builds, and keeping an eye out for potential feedback on social media.
One other update is that we have made significant progress in removing legacy formats from Firefox:
All DTD strings have been removed and migrated to Fluent. Given the nature of our infrastructure — we need to support all shipping versions including ESR — the strings will remain available in Pontoon until late Summer 2023, when Firefox ESR 102 will become obsolete. In the meantime, all these files have been marked as low priority in Pontoon (see for example Italian, tag “Legacy DTD strings (ESR 102)”).
We have started migrating some plural strings from .properties to Fluent. We are aware that plural forms in .properties were confusing, using a semicolon as separator and only a comment to distinguish them from standard strings. For this reason, we’ll also try to prevent developers from adding new plural strings using this format.
What’s new or coming up in mobile
We have recently launched our Major Release on both Mobile and Desktop! This was v106 release. Thank you to all localizers who have worked hard on this global launch. There were more than 274 folks working on this, and (approximately) 67,094 translations!
Thank you!
Here are the main MR features on mobile:
New wallpapers
Recently synced tabs will now appear in the “Jump Back” section of your home page
Users will see CFR (UI popups) pointing to the new MR features. Existing users updating to 106 should also see new onboarding screens introducing the MR features
What’s new or coming up in web projects
Firefox Relay Website
A bunch of strings were added as the result of a new feature that’s only available in Canada and the US at the moment. Locale specific files were created. This is the first time a product team targets non-English users as well as English users in both countries with a new feature. Since we don’t have Canadian French and US Spanish communities, these pages were assigned to the French and Mexican Spanish communities respectively. Please give these pages higher priority as they are time sensitive and there is a promotion going on. The promotion encourages users to sign up for both Firefox Relay and Mozilla VPN as a bundle at a discounted price. Thanks to both communities for helping out.
There will be promotional strings added to the Firefox Relay Add-on project. The strings are available for all locales to localize but the promotion is only visible for users in the US and Canada.
What’s new or coming up in Pontoon
Pontoon profile pages have a brand new look: check out this blog post for more information about this change, and don’t forget to update your profile with relevant contact information, to help both project managers and fellow localizers get in touch if needed.
Events
Want to showcase an event coming up that your community is participating in? Contact us and we’ll include it.
Friends of the Lion
Image by Elio Qoshi
Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out!
(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean. All “This Week in Glean” blog posts are listed in the TWiG index).
At Mozilla we make, amongotherthings, Web Browsers which we tend to call Firefox. The central activity in a Web Browser like Firefox is loading a web page. It gets done a lot by each and every one of our users, and so you can imagine that data about pageloads is of important business interest to us.
But exactly because this is done a lot and by every one of our users, this inspires concerns of scale and cost. How much does it cost us to learn more about pageloads?[0]
As with all things in Data, the answer is the same: “Well, it depends.”
In this case it depends on how you record the data. How you record the data depends on what questions you hope to answer with it. We’re going to stick to the simplest of questions to make this (highly-suspect) comparison even remotely comparable.
Option 1: Just the Counts, Ma’am
I say page loads are done a lot, but how much is “a lot”? If that’s our only question, maybe the data we need is simply a count of pageloads. Glean already has a metric type for counting things, so it should be fairly quick to implement.
This should be cheap, right? Just a single number? Well, it depends.
Scale 1: Frequency
The count of pageloads is just a single number. One, maybe as many as eight, bytes to record, store, transmit, retain, and analyze. But Firefox has to report it more than once, so we need to first scale our cost of “one, maybe as many as eight, bytes” by the number of times we send this information.
When we first implemented Firefox’s pageload count in Glean, I wanted to send it on the builtin “metrics” ping which is sent once a day from anyone running Firefox that day[1]. In an effort to gain more complete and timely data, we ended up adding it to the builtin “baseline” ping which is sent (on average for Firefox Desktop) 8 or more times per day.
For our frequency scale we thus use 8/day.
Scale 2: Population
These 8 recordings per day are sent by about 200M users over a month. Days and months aren’t easy to scale between as not all users use Firefox every day, and our population gains new users and loses old users at variable rates… so I recalculated the Frequency scale to be in terms of months and found that we get 68 pings per month from these roughly 200M users.
So the cost is pretty easy to calculate then? Whatever the cost is of storing and transmitting 200M x 68/month x eight bytes ~= 109 GB?
Not entirely. But until and unless those other costs are not comparable between options, we can just treat them as noise. This cost, rendered in the size of the data, of about 109GB? It’ll do.
Option 2: What an Event
Page loads are interesting not just in how many of them there are, but also about what type of load they are and how long the load took. The order of a page load in between other events might also be of interest: did it happen before or after some network trouble? Did a bunch of pageloads happen all at once, or spread across the day? We might wish to instrument page loads as Glean events.
Events are each more expensive than a count. They carry a timestamp (eight bytes) and repeat their names each time they’re recorded (some strings, say fifteen bytes).
(We are not counting the load type or how long the load took in our calculations of the size of an individual sample as we’re still trying to compare methods of answering the same “How many page loads are there?” question.)
Scale 3: Page Loads
“Each time they’re recorded”, huh. Guess that means we get to multiply by the number of page loads. Each Firefox Desktop user, over the course of a month, loads on average 1190 pages[2]. This means instead of sending 68 numbers a month, we’re sending 1190 batches of strings a month.
So the comparable cost is whatever the cost is of storing and transmitting 200M x (eight bytes and fifteen bytes) x 1190 ~= 5.47TB..
We’ve jumped an order of magnitude here. And we’re not done.
Option 3: Custom Pings, and Custom Pings Only
What if the context we wish to record alongside the event of a page load cannot fit inside Glean’s prudent “event” metric type limits? What if the collected pageload data would benefit from a retention limit or access control list different from other counts or events? What if you want to submit this data to be uploaded as soon as it has been recorded? In that case, we could send a pageload as a Glean custom ping.
We’ve not (yet) done this in Firefox Desktop (at least partially because it complicates ordering amongst other events: the Glean SDK expends a lot of effort to ensure the timestamps between events are reliable. Ping times are client times which are subject to the whims of the user.), so I’m going to get even hand-wavier than before as I try to determine how large each individual data sample will be.
A Glean custom ping without any metrics in it comes to around 500 bytes. When our data platform ingests the ping and turns it into a row in a dataset, we add some metadata which adds another 300 bytes or so (which only affects storage inside the Data Platform and doesn’t add costs to client storage or client bandwidth).
We could go deeper and cost out the network headers, the costs of using TLS to ensure the integrity of the connection… but we’d be here all day. So I’m gonna call that 200 bytes to make it a nice round 1000 bytes per ping.
We’re sending these pings per pageload, so the cost is whatever the cost is of storing and transmitting 200M x 1190 x 1000 bytes = 238TB.
Rule of Thumb: 50x
There you have it: for each step up the cost ladder you’re adding an extra 50x multiplier to the cost of storing and transmitting the data. The reality’s actually much worse if it’s harder to analyze and reason about the data as it gets more complex (which it in most cases is) because, as you might remember from one of my previous explorations in costing out metrics: it’s the human costs of things (like analysis) that really getcha.
But you have to balance it out. If adding more context and information ensures your analyses only have to look in one place for its data instead of trying to tie together loosely-coupled concepts from multiple locations… if using a custom ping ensures you have everything you need and don’t have to form a committee to resource an engineer to add implementation which needs to be deployed and individually validated… if you’re willing to bet 50x or 250x the cost on getting it right the first time, then that could be a good price to pay.
[1]: How often a “metrics” ping is sent is a little more complicated than “once a day”, but it averages out to about that much so I’m sticking with it for this napkin.
[2]: Yes there are some wild and wacky outliers included in the figure “an average of 1190 page loads” that I’m not bothering to clean up. You can Page Loads Georg to your hearts’ content.
[3]: This is about how many characters the JSON-encoded ping payload comes to, uncompressed.
If you’re running Firefox on macOS you might have noticed that its responsiveness has improved significantly in version 103, especially if you’ve got a lot of tabs, or when your machine is busy running other applications at the same time. This improvement was achieved via a small change in how locking is implemented within Firefox’s memory allocator.
Firefox uses a highly customized version of the jemalloc memory allocator across all architectures. We’ve diverged significantly from upstream jemalloc in order to guarantee optimal performance and memory usage on Firefox.
Memory allocators have to be thread safe and – in order to be performant – need to be able to serve a large number of concurrent requests from different threads. To achieve this, jemalloc uses locks within its internal structures that are usually only held very briefly.
Locking within the allocator is implemented differently than in the rest of the codebase. Specifically, creating mutexes and using them must not issue new memory allocations because that would lead to infinite recursion within the allocator itself. To achieve this the allocator tends to use thin locks native to the underlying operating system. On macOS we relied for a long time on OSSpinLock locks.
As the name suggests these are not regular mutexes that put threads trying to acquire them to sleep if they’re already taken by another thread. A thread attempting to lock an already locked instance of OSSpinLock will busy-poll the lock instead of waiting for it to be released, which is commonly referred to as spinning on the lock.
This might seem counter-intuitive, as spinning consumes CPU cycles and power and is usually frowned upon in modern codebases. However, putting a thread to sleep has significant performance implications and thus is not always the best option.
In particular, putting a thread to sleep and then waking it up requires two context switches as well as saving and restoring the thread state to/from memory. Depending on the CPU and workload the thread state can range from several hundred bytes to a few kilobytes. Putting a thread to sleep also has indirect performance effects.
For example, the caches associated with the core the thread was running on were likely holding useful data. When a thread is put to sleep another thread from an unrelated workload might then be selected to run in its place, replacing the data in the caches with new data.
When the original thread is restored it might end up on a different core, or on the same core but with cold caches, filled with unrelated data. Either way, the thread will proceed execution more slowly than if it had kept running undisturbed.
Because of all the above, it might be advantageous to let a thread spin briefly if the lock it’s trying to acquire is only held for a brief period of time. It can result in both higher performance and lower power consumption as the cost of spinning is less than sleeping.
However spinning has a significant drawback: if it goes on for too long it can be detrimental, as it will just waste cycles. Worse still, if the machine is heavily loaded, spinning might put additional load on the system, potentially slowing down precisely the thread that owns the lock, increasing the chance of further threads needing the lock, spinning some more.
As you might have guessed by now OSSpinLock offered very good performance on a lightly loaded system, but behaved poorly as load ramped up. More importantly it had two fundamental flaws: it spinned in user-space and never slept.
Spinning in user-space is a bad idea in general, as user-space doesn’t know how much load the system is currently experiencing. In kernel-space a lock might make an informed decision, for example not to spin at all if the load is high, but OSSpinLock had no such provision, nor did it adapt.
But more importantly, when it couldn’t really grab a lock it would yield instead of sleeping. This is particularly bad because the kernel has no clue that the yielding thread is waiting on a lock, so it might wake up another thread that is also fighting for the same lock instead of the one that owns it.
This will lead to more spinning and yielding and the resulting user experience will be terrible. On heavily loaded systems this could lead to a near live-lock and Firefox effectively hanging. This problem with OSSpinLock was known within Apple hence its deprecation.
Enter os_unfair_lock, Apple’s official replacement for OSSpinLock. If you still use OSSpinLock you’ll get explicit warnings to use it instead.
So I went ahead and used it, but the results were terrible. Performance in some of our automated tests degraded by as much as 30%. os_unfair_lock might be better behaved than OSSpinLock, but it sucked.
For the memory allocator this behavior was suboptimal and the performance regression unacceptable. In some ways, os_unfair_lock had the opposite problem of OSSpinLock: it was too willing to sleep when spinning would have been a better choice. At this point, it’s worth mentioning while we’re at it that pthread_mutex locks are even slower on macOS so those weren’t an option either.
However, as I dug into Apple’s libraries and kernel, I noticed that some spin locks were indeed available, and they did the spinning in kernel-space where they could make a more informed choice with regards to load and scheduling. Those would have been an excellent choice for our use-case.
So how do you use them? Well, it turns out they’re not documented. They rely on a non-public function and flags which I had to duplicate in Firefox.
The function is os_unfair_lock_with_options() and the options I used are OS_UNFAIR_LOCK_DATA_SYNCHRONIZATION and OS_UNFAIR_LOCK_ADAPTIVE_SPIN.
The latter asks the kernel to use kernel-space adaptive spinning, and the former prevents it from spawning additional threads in the thread pools used by Apple’s libraries.
Did they work? Yes! Performance on lightly loaded systems was about the same as OSSpinLock but on loaded ones, they provided massively better responsiveness. They also did something extremely useful for laptop users: they cut down power consumption as a lot less cycles were wasted having the CPUs spinning on locks that couldn’t be acquired.
Unfortunately, my woes weren’t over. The OS_UNFAIR_LOCK_ADAPTIVE_SPIN flag is supported only starting with macOS 10.15, but Firefox also runs on older versions (all the way to 10.12).
As an intermediate solution, I initially fell back to OSSpinLock on older systems. Later I managed to get rid of it for good by relying on os_unfair_lock plus manual spinning in user-space.
This isn’t ideal but it’s still better than relying on OSSpinLock, especially because it’s needed only on x86-64 processors, where I can use pause instructions in the loop which should reduce the performance and power impact when a lock can’t be acquired.
When two threads are running on the same physical core, one using pause instructions leaves almost all of the core’s resources available to the other thread. In the unfortunate case of two threads spinning on the same core they’ll still consume very little power.
At this point, you might wonder if os_unfair_lock – possibly coupled with the undocumented flags – would be a good fit for your codebase. My answer is likely yes but you’ll have to be careful when using it.
If you’re using the undocumented flags be sure to routinely test your software on new beta versions of macOS, as they might break in future versions. And even if you’re only using os_unfair_lock public interface beware that it doesn’t play well with fork(). That’s because the lock stores internally the mach thread IDs to ensure consistent acquisition and release.
These IDs change after a call to fork() as the thread creates new ones when copying your process’ threads. This can lead to potential crashes in the child process. If your application uses fork(), or your library needs to be fork()-safe you’ll need to register at-fork handlers using pthread_atfork() to acquire all the locks in the parent before the fork, then release them after the fork (also in the parent), and reset them in the child.
The SeaMonkey Project team is pleased to announce the immediate release of SeaMonkey 2.53.14! There has been some changes, so please check out [1] and/or [2].
PS: A confession: I haven’t been working too closely with the code and have only been doing the release engineering bit. So the work of actually building the code and ensuring running is kudos to everyone else(Ian and frg both driving the releases). While I don’t understand the code layout anymore; I do hope to figure it out soon. I just need a new laptop to build stuff and time. *sigh*
This week, the EU’s General Court largely upheld the decision sanctioning Google for restricting competition on the Android mobile operating system. But, on their own, the judgment and the record fine do not help to unlock competition and choice online, especially when it comes to browsers.
In July 2018, when the European Commission announced its decision, we expressed hope that the result would help to level the playing field for independent browsers like Firefox and provide real choice for consumers. Sadly for billions of people around the world who use browsers every day, this hope has not been realized – yet.
The case may rumble on in appeals for several more years, but Mozilla will continue to advocate for an Internet which is open, accessible, private, and secure for all, and we will continue to build products which advance this vision. We hope that those with the power to improve browser choice for consumers will also work towards these tangible goals.
It brings us great sadness to share the news that FredMcD has recently passed away.
If you ever posted a question to our Support Forum, you may be familiar with a contributor named “FredMcD”. Fred was one of the most active contributors in Mozilla Support, and for many years remains one of our core contributors. He was regularly awarded a forum contributor badge every year since 2013 for his consistency in contributing to the Support Forum.
He was a dedicated contributor, super helpful, and very loyal to Firefox users making over 81400 contributions to the Support Forum since 2013. During the COVID-19 lockdown period, he focussed on helping people all over the world when they were online the most – at one point he was doing approximately 3600 responses in 90 days, an average of 40 a day.
In March 2022, I learned the news that he was hospitalized for a few weeks. He was back active in our forum shortly after he was discharged. But then we never heard from him again after his last contribution on May 5, 2022. There’s very little we know about Fred. But we were finally able to confirm his passing just recently.
We surely lost a great contributor. He was a helpful community member and his assistance with incidents was greatly appreciated. His support approach has always been straightforward and simple. It’s not rare, that he was able to solve a problem in one go like this or this one.
To honor his passing, we added his name to the about:credits page to make sure that his contribution and impact on Mozilla will never be forgotten. He will surely be missed by the community.
I’d like to thank Paul for his collaboration in this post and for his help in getting Fred’s name to the about:credits page. Thanks, Paul!
Back in February 2022, we reached out to our community to ask for feedback on a proposal to completely rethink the profile page in Pontoon.
The goal was to improve the experience for everyone on the platform, transforming this page into an effective tool that could showcase contributions, provide useful contact information, and help locale managers to grow their communities.
As a reminder, these were the user stories that we defined to help us guide the design process.
As a contributor, I want to be able to:
Quickly see how much I contribute over time to localization.
Share my profile with potential employers in the localization industry, or use it to demonstrate my involvement in projects as a volunteer.
Control visibility of personal information displayed in my profile.
See data about the quality of my contributions and use it to make a case for promotion with locale managers or administrators.
See when my own suggestions have been reviewed and access them.
As a translator, I want to be able to:
See if a person has usually been providing good quality translations.
Check if the person has specific permissions for my own locale, potentially for other locales.
As a locale manager, I want to be able to:
See the quality of contributions provided by a specific person.
See how frequently a person contributes translations, and the amount of their contributions.
As an administrator (or project manager), I want to be able to:
See data about the user:
When they signed up.
When was the last time they logged in to Pontoon, or they were active on the platform.
Quickly assess the frequency of contributions by type (reviews performed, translations).
Which projects and locales they contributed to.
Get a sense of the quality and amount of their contribution.
Easily access contributions by a specific person.
We’re happy to announce that the vast majority of the work has been completed, and you can already see it online in Pontoon. You can click on your profile icon in the top right corner, then click again on the name/icon in the dropdown to display your personal profile page (or you can see an example here).
In the left column, you can find information about the user: contact details, roles, as well as last known activity.
Each user can customize this information in the updated Settings page (click the CHANGE SETTINGS button to access it), where it’s possible to enter data as well as determine the visibility of some of the fields.
In the top central section there are two new graphs:
Approval rate shows the ratio between the number of translations approved and the total number of translations reviewed, excluding self-approved translations.
Self-approvalrate is only visible for users with translator rights, and shows the ratio between the number of translations submitted directly — or self-approved after submitting them as suggestions — and the total number of translations approved.
Right below these graphs, there is a section showing a graphical representation of the user’s activity in the last year:
Each square represents a day, while each row represents a day of the week. The lighter the color, the higher the number of contributions on that day.
By default, the chart will show data for Submissions and reviews, which means translations submitted and reviews performed. We decided to use this as default among all the options, since it actually shows actions that require an active role from the user.
The chart will display activity for the last year, while the activity log below will by default display activity in more detail for the last month. Clicking on a specific square (day) will only show the activity for that day.
It’s important to note that the activity log includes links that allow you to jump to those specific strings in the translation editor, and that includes reviews performed or received, for which a new filter has been implemented.
We hope that you’ll find this new profile page useful in your day to day contributions to Mozilla. If you encounter any problems, don’t hesitate to file an issue on GitHub.
In June 2021, we decided to start converting the source code for MDN web docs from HTML into a format that would be easier for us to work with. The goal was to get 100% of our manually-written documentation converted to Markdown, and we really had a mountain of source code to climb for this particular expedition.
In this post, we’ll describe why we decided to migrate to Markdown, and the steps you can take that will help us on our mission.
Why get to 100% Markdown?
We want to get all active content on MDN Web Docs to Markdown for several reasons. The top three reasons are:
Markdown is a much more approachable and friendlier way to contribute to MDN Web Docs content. Having all content in Markdown will help create a unified contribution experience across languages and repositories.
With all content in Markdown, the MDN engineering team will be able to clean up a lot of the currently maintained code. Having less code to maintain will enable them to focus on improving the tooling for writers and contributors. Better tooling will lead to a more enjoyable contribution workflow.
All content in Markdown will allow the MDN Web Docs team to run the same linting rules across all active languages.
Here is the tracking issue for this project on the translated content repository.
Tools
This section describes the tools you’ll need to participate in this project.
Git
If you do not have git installed, you can follow the steps described on this getting started page.
We’re tracking source code and managing contributions on GitHub, so the following will be needed:
• A GitHub account.
• The GitHub CLI to follow the commands below. (Encouraged, but optional, i.e., if you are already comfortable using Git, you can accomplish all the same tasks without the need for the GitHub CLI.)
cd .. # This moves you out of the `markdown` folder
cd content
yarn
Converting to Markdown
I will touch on some specific commands here, but for detailed documentation, please check out the markdown repo’s README.
We maintain a list of documents that need to be converted to Markdown in this Google sheet. There is a worksheet for each language. The worksheets are sorted in the order of the number of documents to be converted in each language – from the lowest to the highest. You do not need to understand the language to do the conversion. As long as you are comfortable with Markdown and some HTML, you will be able to contribute.
NOTE: You can find a useful reference to the flavor of Markdown supported on MDN Web Docs. There are some customizations, but in general, it is based on GitHub flavouredMarkdown.
On the translated-contentrepository go to the Issues tab and click on the “New issue” button. As mentioned in the introduction, there is a tracking issue for this work and so, it is good practice to reference the tracking issue in the issue you’ll create.
You will be presented with three options when you click the “New issue” button. For our purposes here, we will choose the “Open a blank issue” option. For the title of the issue, use something like, “chore: convert mozilla/firefox/releases for Spanish to Markdown”. In your description, you can add something like the following:
As part of the larger 100% Markdown project, I am converting the set of documents under mozilla/firefox/releases to Markdown.
NOTE: You will most likely be unable to a assign an issue to yourself. The best thing to do here is to mention the localization team member for the appropriate locale and ask them to assign the issue to you. For example, on GitHub you would add a comment like this: “Hey @mdn/yari-content-es I would like to work on this issue, please assign it to me. Thank you!”
The tracking spreadsheet contains a couple of fields that you should update if you intend to work on speific items. The first item you need to add is your GitHub username and link the text to your GitHub profile. Secondly, set the status to “In progress”. In the issue column, paste a link to the issue you created in the previous step.
Creating a feature branch
It is a common practice on projects that use Git and GitHub to follow a feature branch workflow. I therefore need to create a feature branch for the work on the translated-content repository. To do this, we will again use our issue as a reference.
Let’s say your issue was called ” chore: convert mozilla/firefox/releases for Spanish to Markdown” with an id of 8192. You will do the following at the root of the translated-content repository folder:
NOTE: The translated content repository is a very active repository. Before creating your feature branch, be sure to pull the latest from the remote using the command git pull upstream main
git pull upstream main
git switch -c 8192-chore-es-convert-firefox-release-docs-to-markdown
NOTE: In older version of Git, you will need to use git checkout -B 8192-chore-es-convert-firefox-release-docs-to-markdown.
The above command will create the feature branch and switch to it.
Running the conversion
Now you are ready to do the conversion. The Markdown conversion tool has a couple of modes you can run it in:
dry – Run the script, but do not actually write any output
keep – Run the script and do the conversion but, do not delete the HTML file
replace – Do the conversion and delete the HTML file
You will almost always start with a dry run.
NOTE: Before running the command below, esnure that you are in the root of the markdown repository.
yarn h2m mozilla/firefox/releases --locale es --mode dry
This is because the conversion tool will sometimes encounter situations where it does not know how to convert parts of the document. The markdown tool will produce a report with details of the errors encountered. For example:
# Report from 9/1/2022, 2:40:14 PM
## All unhandled elements
- li.toggle (4)
- dl (2)
- ol (1)
## Details per Document
### [/es/docs/Mozilla/Firefox/Releases/1.5](<https://developer.mozilla.org/es/docs/Mozilla/Firefox/Releases/1.5>)
#### Invalid AST transformations
##### dl (101:1) => listItem
type: "text"
value: ""
### [/es/docs/Mozilla/Firefox/Releases/3](<https://developer.mozilla.org/es/docs/Mozilla/Firefox/Releases/3>)
### Missing conversion rules
- dl (218:1)
The first line in the report states that the tool had a problem converting four instances of li.toggle. So, there are four list items with the class attribute set to toggle. In the larger report, there is this section:
### [/es/docs/Mozilla/Firefox/Releases/9](<https://developer.mozilla.org/es/docs/Mozilla/Firefox/Releases/9>)
#### Invalid AST transformations
##### ol (14:3) => list
type: "html"
value: "<li class=\\"toggle\\"><details><summary>Notas de la Versión para Desarrolladores de Firefox</summary><ol><li><a href=\\"/es/docs/Mozilla/Firefox/Releases\\">Notas de la Versión para Desarrolladores de Firefox</a></li></ol></details></li>",type: "html"
value: "<li class=\\"toggle\\"><details><summary>Complementos</summary><ol><li><a href=\\"/es/Add-ons/WebExtensions\\">Extensiones del navegador</a></li><li><a href=\\"/es/Add-ons/Themes\\">Temas</a></li></ol></details></li>",type: "html"
value: "<li class=\\"toggle\\"><details><summary>Firefox por dentro</summary><ol><li><a href=\\"/es/docs/Mozilla/\\">Proyecto Mozilla (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/Gecko\\">Gecko</a></li><li><a href=\\"/es/docs/Mozilla/Firefox/Headless_mode\\">Headless mode</a></li><li><a href=\\"/es/docs/Mozilla/JavaScript_code_modules\\">Modulos de código JavaScript (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/js-ctypes\\">JS-ctypes (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/MathML_Project\\">Proyecto MathML</a></li><li><a href=\\"/es/docs/Mozilla/MFBT\\">MFBT (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/Projects\\">Proyectos Mozilla (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/Preferences\\">Sistema de Preferencias (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/WebIDL_bindings\\">Ataduras WebIDL (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/Tech/XPCOM\\">XPCOM</a></li><li><a href=\\"/es/docs/Mozilla/Tech/XUL\\">XUL</a></li></ol></details></li>",type: "html"
value: "<li class=\\"toggle\\"><details><summary>Crear y contribuir</summary><ol><li><a href=\\"/es/docs/Mozilla/Developer_guide/Build_Instructions\\">Instrucciones para la compilación</a></li><li><a href=\\"/es/docs/Mozilla/Developer_guide/Build_Instructions/Configuring_Build_Options\\">Configurar las opciones de compilación</a></li><li><a href=\\"/es/docs/Mozilla/Developer_guide/Build_Instructions/How_Mozilla_s_build_system_works\\">Cómo funciona el sistema de compilación (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/Developer_guide/Source_Code/Mercurial\\">Código fuente de Mozilla</a></li><li><a href=\\"/es/docs/Mozilla/Localization\\">Localización</a></li><li><a href=\\"/es/docs/Mozilla/Mercurial\\">Mercurial (Inglés)</a></li><li><a href=\\"/es/docs/Mozilla/QA\\">Garantía de Calidad</a></li><li><a href=\\"/es/docs/Mozilla/Using_Mozilla_code_in_other_projects\\">Usar Mozilla en otros proyectos (Inglés)</a></li></ol></details></li>"
The problem is therefore in the file /es/docs/Mozilla/Firefox/Releases/9. In this instance, we can ignore this as we will simply leave the HTML as is in the Markdown. This is sometimes needed as the HTML we need cannot be accurately represented in Markdown. The part you cannot see in the output above is this portion of the file:
If you do a search in the main content repo you will find lots of instances of this. In all those cases, you will see that the HTML is kept in place and this section is not converted to Markdown.
The next two problematic items are two dl or description list elements. These elements will require manual conversion using the guidelines in our documentation. The last item, the ol is actually related to the li.toggle issue. Those list items are wrapped by an ol and because the tool is not sure what to do with the list items, it is also complaining about the ordered list item.
Now that we understand what the problems are, we have two options. We can run the exact same command but this time use the replace mode or, we can use the keep mode. I am going to go ahead and run the command with replace. While the previous command did not actually write anything to the translated content repository, when run with replace it will create a new file called index.md with the converted Markdown and delete the index.html that resides in the same directory.
yarn h2m mozilla/firefox/releases --locale es --mode replace
Following the guidelines from the report, I will have to pay particular attention to the following files post conversion:
/es/docs/Mozilla/Firefox/Releases/1.5
/es/docs/Mozilla/Firefox/Releases/3
/es/docs/Mozilla/Firefox/Releases/9
After running the command, run the following at the root of the translated content repository folder, git status. This will show you a list of the changes made by the command. Depending on the number of files touched, the output can be verbose. The vital thing to keep an eye out for is that there are no changes to folders or files you did not expect.
Testing the changes
Now that the conversion has been done, we need to review the syntax and see that the pages render correctly. This is where the content repo is going to come into play. As with the markdown repository, we also need to create a .env file at the root of the content folder.
With this in place we can start the development server and take a look at the pages in the browser. To start the server, run yarn start. You should see output like the following:
Go ahead and open http://localhost:5042 which will serve the homepage. To find the URL for one of the pages that was converted open up the Markdown file and look at the slug in the frontmatter. When you ran git status earlier, it would have printed out the file paths to the terminal window. The file path will show you exactly where to find the file, for example, files/es/mozilla/firefox/releases/1.5/index.md. Go ahead and open the file in your editor of choice.
In the frontmatter, you will find an entry like this:
slug: Mozilla/Firefox/Releases/1.5
To load the page in your browser, you will always prepend http://localhost:5042/es/docs/ to the slug. In other words, the final URL you will open in your browser will be http://localhost:5042/es/docs/Mozilla/Firefox/Releases/1.5. You can open the English version of the page in a separate tab to compare, but be aware that the content could be wildly different as you might have converted a page that has not been updated in some time.
What you want to look out for is anything in the page that looks like it is not rendering correctly. If you find something that looks incorrect, look at the Markdown file and see if you can find any syntax that looks incorrect or completely broken. It can be extremely useful to use a tool such as VSCode with a Markdown tool and Prettier installed.
Even if the rendered content looks good, do take a minute and skim over the generated Markdown and see if the linters bring up any possible errors.
NOTE: If you see code like this {{FirefoxSidebar}} this is a macro call. There is not a lot of documentation yet but, these macros come from KumaScript in Yari.
A couple of other things to keep in mind. When you run into an error, before you spend a lot of time trying to understand what exatly the problem is or how to fix it, do the following:
Look for the same page in the content repository and make sure the page still exists. If it was removed from the content repository, you can safely remove it from translated-content as well.
Look at the same page in another language that has already been converted and see how they solved the problem.
For example, I ran into an error where a page I loaded simply printed the following in the browser: Error: 500 on /es/docs/Mozilla/Firefox/Releases/2/Adding_feed_readers_to_Firefox/index.json: SyntaxError: Expected "u" or ["bfnrt\\\\/] but "_" found.. I narrowed it down to the following piece of code inside the Markdown:
In French it seems that they removed the page, but when I looked in zh-tw it looks like they simply removed this macro call. I opted for the latter and just removed the macro call. This solved the problem and the page rendered correctly. Once you have gone through all of the files you converted it is time to open a pull request.
Preparing and opening a pull request
# the dot says add everything
git add .
Start by getting all your changes ready for committing:
If you run git status now you will see something like the following:
❯ git status
On branch 8192-chore-es-convert-firefox-release-docs-to-markdown
Changes to be committed: # this be followed by a list of files that has been added, ready for commit
Commit your changes:
git commit -m 'chore: convert Firefox release docs to markdown for Spanish'
Finally you need to push the changes to GitHub so we can open the pull request:
You can now head over to the translated content repository on GitHub where you should see a banner that asks whether you want to open a pull request. Click the “Compare and pull button” and look over your changes on the next page to ensure nothing surprises.
At this point, you can also add some more information and context around the pull request in the description box. It is also critical that you add a line as follows, “Fix #8192”. Substitute the number with the number of the issue you created earlier. The reason we do this is so that we link the issue and the pull request. What will also happen is, once the pull request is merged, GitHub will automatically close the issue.
Once you are satisfied with the changes as well as your description, go ahead and click the button to open the pull request. At this stage GitHub will auto-assign someone from the appropriate localization team to review your pull request. You can now sit back and wait for feedback. Once you receive feedback, address any changes requested by the reviewer and update your pull request.
Once you are both satisfied with the end result, the pull request will be merged and you will have helped us get a little bit closer to 100% Markdown. Thank you! One final step remains though. Open the spreadsheet and update the relevant rows with a link to the pull request, and update the status to “In review”.
Once the pull request has been merged, remember to come back and update the status to done.
Reach out if you need help
If you run into any problems and have questions, please join our MDN Web Docs channel on Matrix.
Hello extension developers, I’m Juhis, it’s a pleasure to meet you all. In the beginning of August I joined Mozilla and the Firefox add-ons team as a developer advocate. I expect us to see each other quite a lot in the future. My mom taught me to always introduce myself to new people so here we go!
My goal is to help all of you to learn from each other, to build great add-ons and to make that journey an enjoyable experience. Also, I want to be your voice to the teams building Firefox and add-ons tooling.
My journey into the world of software
I’m originally from Finland and grew up in a rather small town in the southwest. I got excited about computers from a very young age. I vividly remember a moment from my childhood when my sister created a digital painting of two horses, but since it was too large for the screen, I had to scroll to reveal the other horse. That blew my four-year old mind and I’ve been fascinated by the opportunities of technology ever since.
After some years working in professional software development, I realized I could offer maximum impact by building communities and helping others become developers rather than just coding myself. Ever since, I’ve been building developer communities, organized meetups, taught programming and served as a general advocate for the potentials of technology.
I believe in the positive empowerment that technology can bring to individuals all around the world. Whether it’s someone building something small to solve a problem in their daily life, someone building tools for their community, or being able to build and run your own business, there are so many ways we can leverage technology for good.
Customize your own internet experience with add-ons
The idea of shaping your own internet experience has been close to my heart for a long time. It can be something relatively simple like running custom CSS through existing extensions to make a website more enjoyable to use, or maybe it’s building big extensions for thousands of other people to enjoy. I’m excited to now be in a position where I can help others to build great add-ons of their own.
To understand better what a new extensions developer goes through, I built an extension following our documentation and processes. I built it for fellow Pokemon TCG players who want a a more visual way to read decklists online. Pokemon TCG card viewer can be installed from addons.mozilla.org. It adds a hover state to card codes it recognizes and displays a picture of the card on hover.
Best way to find me is in the Mozilla Matrix server as @hamatti:mozilla.org in the Add-ons channel. Come say hi!
The SeaMonkey Project team is pleased to announce the immediate release of SeaMonkey 2.53.14 beta 1.
As it is a beta, please check out the release notes at [1] and/or [2] and take it for a spin with a new profile (or a copy/backup of your production profile).
The updates will be forthcoming, specifically, within the hour after I’ve pressed that shiny red button. or was it the green one?
Summer is not a thing in my home country, Indonesia. But I learn that taking some time off after having done a lot of work in the first half of the year is useful for my well-being. So I hope you had a chance to take a break this summer.
We passed half of Q3 already at this point, so let’s see what SUMO has been doing and up to with renewed excitement after this holiday season.
Welcome note and shout-outs
Thanks to Felipe for doing a short experiment on social support mentoring. This was helpful to understand what other contributors might need when they start contributing.
Thanks to top contributors for Firefox for iOS in the forum. We are in need of more iOS contributors in the forum, so your contribution is highly appreciated.
I’d like to give special thanks to a few contributors who start to contribute more to KB these days: Denys, Kaie, Lisah933, jmaustin, and many others.
If you know anyone that we should feature here, please contact Kiki and we’ll make sure to add them in our next edition.
Community news
We are now sharing social and mobile support stats regularly. This is an effort to make sure that contributors are updated and exposed to both contribution areas. We knew it’s not always easy to discover opportunity to contribute to social or mobile support since we’re utilizing a different tool for these contribution areas. Check out the last one was from last week.
The long-awaited work to fix the automatic function to shorten KB article link has been released to production. Read more about this change in this contributor thread and how you can help remove manual links that we added in the past when the functionality was broken.
Consider subscribing to Firefox Daily Digest if you haven’t to get daily updates about Firefox from across different platforms.
Watch the monthly community call if you haven’t. Learn more about what’s new in July! Reminder:Don’t hesitate to join the call in person if you can. We try our best to provide a safe space for everyone to contribute. You’re more than welcome to lurk in the call if you don’t feel comfortable turning on your video or speaking up. If you feel shy to ask questions during the meeting, feel free to add your questions on the contributor forum in advance, or put them in our Matrix channel, so we can answer them during the meeting.
If you’re an NDA’ed contributor, you can watch the recording of the Customer Experience weekly scrum meeting from AirMozilla to catch up with the latest product updates.
Check out the following release notes from Kitsune in the month:
* Locale pageviews is an overall pageviews from the given locale (KB and other pages)
** Localization progress is the percentage of localized article from all KB articles per locale
Top 5 localization contributors in the last 90 days:
Top 5 Social Support contributors in the past 2 months:
Bithiah K
Christophe Villeneuve
Felipe Koji
Kaio Duarte
Matt Cianfarani
Play Store Support
Channel
Jul 2022
Total priority review
Total priority review replied
Total reviews replied
Firefox for Android
2155
508
575
Firefox Focus for Android
45
18
92
Firefox Klar Android
3
0
0
Top 5 Play Store contributors in the past 2 months:
Paul Wright
Selim Şumlu
Felipe Koji
Tim Maks
Matt Cianfarani
Product updates
To catch up on product releases update, please watch the recording of the Customer Experience scrum meeting from AirMozilla. You can also subscribe to the AirMozilla folder by clickling on the Subscribe button at the top right corner of the page to get notifications each time we add a new recording.
Register Below!
Join us for a discussion about the need for comprehensive privacy reform and whether the political landscape is ready to make it happen.
The panel session will be immediately followed by a happy hour reception with drinks and light fare.
Date and time: Wednesday, September 21st – panel starts @ 4:00PM promptly (doors @ 3:45pm) Location: Wunder Garten, 1101 First St. NE, Washington, DC 20002
Merging two GitHub repositories without losing history
We are in the process of merging smaller example code repositories into larger parent repositories on the MDN Web Docs project. While we thought that copying the files from one repository into the new one would lose commit history, we felt that this might be an OK strategy. After all, we are not deleting the old repository but archiving it.
tl;dr The approach is to use basic git commands to apply all of the histories of our old repo onto a new repo without needing special tooling.
Getting started
For the experiment, I used the sw-test repository that is meant to be merged into the dom-examples repository.
This is how Eric describes the first steps:
# Assume the current directory is where we want the new repository to be created
# Create the new repository
git init
# Before we do a merge, we need to have an initial commit, so we’ll make a dummy commit
dir > deleteme.txt
git add .
git commit -m “Initial dummy commit”
# Add a remote for and fetch the old repo
git remote add -f old_a <OldA repo URL>
# Merge the files from old_a/master into new/master
git merge old_a/master
I could skip everything up to the git remote ... step as my target repository already had some history, so I started as follows:
git clone https://github.com/mdn/dom-examples.git
cd dom-examples
Running git log on this repository, I see the following commit history:
commit cdfd2aeb93cb4bd8456345881997fcec1057efbb (HEAD -> master, upstream/master)
Merge: 1c7ff6e dfe991b
Author:
Date: Fri Aug 5 10:21:27 2022 +0200
Merge pull request #143 from mdn/sideshowbarker/webgl-sample6-UNPACK_FLIP_Y_WEBGL
“Using textures in WebGL”: Fix orientation of Firefox logo
commit dfe991b5d1b34a492ccd524131982e140cf1e555
Author:
Date: Fri Aug 5 17:08:50 2022 +0900
“Using textures in WebGL”: Fix orientation of Firefox logo
Fixes <https://github.com/mdn/content/issues/10132>
commit 1c7ff6eec8bb0fff5630a66a32d1b9b6b9d5a6e5
Merge: be41273 5618100
Author:
Date: Fri Aug 5 09:01:56 2022 +0200
Merge pull request #142 from mdn/sideshowbarker/webgl-demo-add-playsInline-drop-autoplay
WebGL sample8: Drop “autoplay”; add “playsInline”
commit 56181007b7a33907097d767dfe837bb5573dcd38
Author:
Date: Fri Aug 5 13:41:45 2022 +0900
With the current setup, I could continue from the git remote command, but I wondered if the current directory contained files or folders that would conflict with those in the service worker repository. I searched around some more to see if anyone else had run into this same situation but did not find an answer. Then it hit me! I need to prepare the service worker repo to be moved.
What do I mean by that? I need to create a new directory in the root of the sw-test repo called service-worker/sw-test and move all relevant files into this new subdirectory. This will allow me to safely merge it into dom-examples as everything is contained in a subfolder already.
To get started, I need to clone the repo we want to merge into dom-examples.
git clone https://github.com/mdn/sw-test.git
cd sw-test
Ok, now we can start preparing the repo. The first step is to create our new subdirectory.
mkdir service-worker
mkdir service-worker/sw-test
With this in place, I simply need to move everything in the root directory to the subdirectory. To do this, we will make use of the move (mv) command:
NOTE: Do not yet run any of the commands below at this stage.
# enable extendedglob for ZSH
set -o extendedglob
mv ^sw-test(D) service-worker/swtest
The above command is a little more complex than you might think. It uses a negation syntax. The next section explains why we need it and how to enable it.
How to exclude subdirectories when using mv
While the end goal seemed simple, I am pretty sure I grew a small animal’s worth of grey hair trying to figure out how to make that last move command work. I read many StackOverflow threads, blog posts, and manual pages for the different commands with varying amounts of success. However, none of the initial set of options quite met my needs. I finally stumbled upon two StackOverflow threads that brought me to the answer.
To spare you the trouble, here is what I had to do.
First, a note. I am on a Mac using ZSH (since macOS Catalina, this is now the default shell). Depending on your shell, the instructions below may differ.
For new versions of ZSH, you use the set -o and set +o commands to enable and disable settings. To enable extendedglob, I used the following command:
# Yes, this _enables_ it
set -o extendedglob
On older versions of ZSH, you use the setopt and unsetopt commands.
setopt extendedglob
With bash, you can achieve the same using the following command:
shopt -s extglob
Why do you even have to do this, you may ask? Without this, you will not be able to use the negation operator I use in the above move command, which is the crux of the whole thing. If you do the following, for example:
mkdir service-worker
mv * service-worker/sw-test
It will “work,” but you will see an error message like this:
mv: rename service-worker to service-worker/sw-test/service-worker: Invalid argument
We want to tell the operating system to move everything into our new subfolder except the subfolder itself. We, therefore, need this negation syntax. It is not enabled by default because it could cause problems if file names contain some of the extendedglob patterns, such as ^. So we need to enable it explicitly.
NOTE: You might also want to disable it after completing your move operation.
Now that we know how and why we want extendedglob enabled, we move on to using our new powers.
NOTE: Do not yet run any of the commands below at this stage.
mv ^sw-test(D) service-worker/sw-test
The above means:
Move all the files in the current directory into service-worker/sw-test.
Do not try to move the service-worker directory itself.
The (D) option tells the move command to also move all hidden files, such as .gitignore, and hidden folders, such as .git.
NOTE: I found that if I typed mv ^sw-test and pressed tab, my terminal would expand the command to mv CODE_OF_CONDUCT.md LICENSE README.md app.js gallery image-list.js index.html service-worker star-wars-logo.jpg style.css sw.js. If I typed mv ^sw-test(D) and pressed tab, it would expand to mv .git .prettierrc CODE_OF_CONDUCT.md LICENSE README.md app.js gallery image-list.js index.html service-worker star-wars-logo.jpg style.css sw.js. This is interesting because it clearly demonstrates what happens under the hood. This allows you to see the effect of using (D) clearly. I am not sure whether this is just a native ZSH thing or one of my terminal plugins, such as Fig. Your mileage may vary.
Handling hidden files and creating a pull request
While it is nice to be able to move all of the hidden files and folders like this, it causes a problem. Because the .git folder is transferred into our new subfolder, our root directory is no longer seen as a Git repository. This is a problem.
Therefore, I will not run the above command with (D) but instead move the hidden files as a separate step. I will run the following command instead:
At this stage, if you run ls it will look like it moved everything. That is not the case because the ls command does not list hidden files. To do that, you need to pass the -A flag as shown below:
ls -A
You should now see something like the following:
❯ ls -A
.git .prettierrc service-worker
Looking at the above output, I realized that I should not need to move the .git folder. All I needed to do now was to run the following command:
mv .prettierrc service-worker
After running the above command, ls -A will now output the following:
❯ ls -A
.git simple-service-worker
Time to do a little celebration dance
We can move on now that we have successfully moved everything into our new subdirectory. However, while doing this, I realized I forgot to create a feature branch for the work.
Not a problem. I just run the command, git switch -C prepare-repo-for-move. Running git status at this point should output something like this:
❯ git status
On branch prepare-repo-for-move
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: .prettierrc
deleted: CODE_OF_CONDUCT.md
deleted: LICENSE
deleted: README.md
deleted: app.js
deleted: gallery/bountyHunters.jpg
deleted: gallery/myLittleVader.jpg
deleted: gallery/snowTroopers.jpg
deleted: image-list.js
deleted: index.html
deleted: star-wars-logo.jpg
deleted: style.css
deleted: sw.js
Untracked files:
(use "git add <file>..." to include in what will be committed)
service-worker/
no changes added to commit (use "git add" and/or "git commit -a")
Great! Let’s add our changes and commit them.
git add .
git commit -m 'Moved all source files into new subdirectory'
Now we want to push our changes and open a pull request.
Woop! Let’s push:
git push origin prepare-repo-for-move
Head over to your repository on GitHub. You should see a banner like “mv-files-into-subdir had recent pushes less than a minute ago” and a “Compare & pull request” button.
Click the button and follow the steps to open the pull request. Once the pull request is green and ready to merge, go ahead and merge!
NOTE: Depending on your workflow, this is the point to ask a team member to review your proposed changes before merging. It is also a good idea to have a look over the changes in the “Files changed” tab to ensure nothing is part of the pull request you did not intend. If any conflicts prevent your pull request from being merged, GitHub will warn you about these, and you will need to resolve them. This can be done directly on GitHub.com or locally and pushed to GitHub as a separate commit.
When you head back to the code view on GitHub, you should see our new subdirectory and the .gitignore file.
With that, our repository is ready to move.
Merging our repositories
Back in the terminal, you want to switch back to the main branch:
git switch main
You can now safely delete the feature branch and pull down the changes from your remote.
git branch -D prepare-repo-for-move
git pull origin main
Running ls -A after pulling the latest should now show the following:
❯ ls -A
.git README.md service-worker
Also, running git log in the root outputs the following:
commit 8fdfe7379130b8d6ea13ea8bf14a0bb45ad725d0 (HEAD -> gh-pages, origin/gh-pages, origin/HEAD)
Author: Schalk Neethling
Date: Thu Aug 11 22:56:48 2022 +0200
Create README.md
commit 254a95749c4cc3d7d2c7ec8a5902bea225870176
Merge: f5c319b bc2cdd9
Author: Schalk Neethling
Date: Thu Aug 11 22:55:26 2022 +0200
Merge pull request #45 from mdn/prepare-repo-for-move
chore: prepare repo for move to dom-examples
commit bc2cdd939f568380ce03d56f50f16f2dc98d750c (origin/prepare-repo-for-move)
Author: Schalk Neethling
Date: Thu Aug 11 22:53:13 2022 +0200
chore: prepare repo for move to dom-examples
Prepping the repository for the move to dom-examples
commit f5c319be3b8d4f14a1505173910877ca3bb429e5
Merge: d587747 2ed0eff
Author: Ruth John
Date: Fri Mar 18 12:24:09 2022 +0000
Merge pull request #43 from SimonSiefke/add-navigation-preload
Here are the commands left over from where we diverted earlier on.
# Add a remote for and fetch the old repo
git remote add -f old_a <OldA repo URL>
# Merge the files from old_a/master into new/master
git merge old_a/master
Alrighty, let’s wrap this up. First, we need to move into the root of the project to which we want to move our project. For our purpose here, this is the dom-examples directory. Once in the root of the directory, run the following:
NOTE: While we deleted the branch locally, this is not automatically synced with the remote, so this is why you will still see a reference to the rename-sw-test branch. If you wanted to delete it on the remote, you would run the following from the root of that repository: git push origin :rename-sw-test (if you have configured your repository “to automatically delete head branches”, this will be automatically deleted for you)
Only a few commands left.
NOTE: Do not yet run any of the commands below at this stage.
git merge swtest/gh-pages
Whoops! When I ran the above, I got the following error:
❯ git merge swtest/gh-pages
fatal: refusing to merge unrelated histories
But this is pretty much exactly what I do want, right? This is the default behavior of the merge command, but you can pass a flag and allow this behavior.
NOTE: Why gh-pages? More often than not, the one you will merge here will be main but for this particular repository, the default branch was named gh-pages. It used to be that when using GitHub pages, you would need a branch called gh-pages that will then be automatically deployed by GitHub to a URL that would be something like mdn.github.io/sw-test.
After running the above, I got the following:
❯ git merge swtest/gh-pages --allow-unrelated-histories
Auto-merging README.md
CONFLICT (add/add): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
Ah yes, of course. Our current project and the one we are merging both contain a README.md, so Git is asking us to decide what to do. If you open up the README.md file in your editor, you will notice something like this:
<<<<<<< HEAD
=======
There might be a number of these in the file. You will also see some entries like this, >>>>>>> swtest/gh-pages. This highlights the conflicts that Git is not sure how to resolve. You could go through and clear these manually. In this instance, I just want what is in the README.md at the root of the dom-examples repo, so I will clean up the conflicts or copy the content from the README.md from GitHub.
As Git requested, we will add and commit our changes.
git add .
git commit -m 'merging sw-test into dom-examples'
And finally, running ls -A service-worker/simple-service-worker/ shows:
❯ ls -A service-worker/simple-service-worker/
.prettierrc README.md image-list.js style.css
CODE_OF_CONDUCT.md app.js index.html sw.js
LICENSE gallery star-wars-logo.jpg
All that is left is to push to remote.
git push origin 146-chore-mo…dom-examples
NOTE: Do not squash merge this pull request, or else all commits will be squashed together as a single commit. Instead, you want to use a merge commit. You can read all the details about merge methods in their documentation on GitHub.
After you merge the pull request, go ahead and browse the commit history of the repo. You will find that the commit history is intact and merged. o/\o You can now go ahead and either delete or archive the old repository.
At this point having the remote configured for our target repo serve no purpose so, we can safe remove the remote.
git remote rm swtest
In Conclusion
The steps to accomplish this task is then as follows:
# Clone the repository you want to merge
git clone https://github.com/mdn/sw-test.git
cd sw-test
# Create your feature branch
git switch -C prepare-repo-for-move
# NOTE: With older versions of Git you can run:
# git checkout -b prepare-repo-for-move
# Create directories as needed. You may only need one, not two as
# in the example below.
mkdir service-worker
mkdir service-worker/sw-test
# Enable extendedglob so we can use negation
# The command below is for modern versions of ZSH. See earlier
# in the post for examples for bash and older versions of ZSH
set -o extendedglob
# Move everything except hidden files into your subdirectory,
# also, exclude your target directories
mv ^(sw-test|service-worker) service-worker/sw-test
# Move any of the hidden files or folders you _do_ want
# to move into the subdirectory
mv .prettierrc service-worker
# Add and commit your changes
git add .
git commit -m 'Moved all source files into new subdirectory'
# Push your changes to GitHub
git push origin prepare-repo-for-move
# Head over to the repository on GitHub, open and merge your pull request
# Back in the terminal, switch to your `main` branch
git switch main
# Delete your feature branch
# This is not technically required, but I like to clean up after myself :)
git branch -D prepare-repo-for-move
# Pull the changes you just merged
git pull origin main
# Change to the root directory of your target repository
# If you have not yet cloned your target repository, change
# out of your current directory
cd ..
# Clone your target repository
git clone https://github.com/mdn/dom-examples.git
# Change directory
cd dom-examples
# Create a feature branch for the work
git switch -C 146-chore-move-sw-test-into-dom-examples
# Add your merge target as a remote
git remote add -f ssw https://github.com/mdn/sw-test.git
# Merge the merge target and allow unrelated history
git merge swtest/gh-pages --allow-unrelated-histories
# Add and commit your changes
git add .
git commit -m 'merging sw-test into dom-examples'
# Push your changes to GitHub
git push origin 146-chore-move-sw-test-into-dom-examples
# Open the pull request, have it reviewed by a team member, and merge.
# Do not squash merge this pull request, or else all commits will be
# squashed together as a single commit. Instead, you want to use a merge commit.
# Remove the remote for the merge target
git remote rm swtest
Hopefully, you now know how to exclude subdirectories using the mv command, set and view shell configuration, and merge the file contents of a git repo into a new repository while preserving the entire commit history using only basic git commands.
Despite being a powerhouse of technology and innovation, the U.S. lags behind global counterparts when it comes to privacy protections. Everyday, people face the real possibility that their very personal information could fall into the hands of third parties seeking to weaponize it against them.
At Mozilla, we strive to not only empower people with tools to protect their own privacy, but also to influence other companies to adopt better privacy practices. That said, we can’t solve every problem with a technical fix or rely on companies to voluntarily prioritize privacy.
The good news? After decades of failed attempts and false starts, real reform may finally be on the horizon. We’ve recently seen more momentum than ever for policy changes that would provide meaningful protections for consumers and more accountability from companies. It’s time that we tackle the real-world harms that emerge as a result of pervasive data collection online and abusive privacy practices.
Strong federal privacy legislation is critical in creating an environment where users can truly benefit from the technologies they rely on without paying the premium of exploitation of their personal data. Last month, the House Committee on Energy & Commerce took the important step of voting the bipartisan American Data Privacy and Protection Act (ADPPA) out of committee and advancing the bill to the House floor. Mozilla supports these efforts and encourages Congress to pass the ADPPA.
Stalling on federal policy efforts would only hurt American consumers. We look forward to continuing our work with policymakers and regulators to achieve meaningful reform that restores trust online and holds companies accountable. There’s more progress than ever before towards a solution. We can’t miss this moment.
Firefox UX adopted Figma about two years ago. In this post, I’ll share how our content design team has used the tool to shape collaboration and influence how design gets done.
Our Figma Journey: From Coach House to Co-Creation
Before Figma, the Firefox content design team worked in a separate space from visual and interaction designers. Our own tools — primarily the Google suite of products — were like a copy coach house.
When it came time to collaborate with UX design colleagues, we had to walk to the main design house (like Sketch, for example). We had to ask for help with the fancy coffee machine (Can you update this label for me? Is it too late to make a change to the layout to fit our content needs?). We felt a bit like guests: out of our element.
This way of working made collaboration more complex. Content and UX design were using different tools, working in silo and simultaneously, to create one experience. If a content designer needed to explore layout changes, we would find ourselves painstakingly recreating mocks in other tools.
<figcaption>To propose copy and design changes to the Firefox homepage, I had to re-create the mock in Google Slides.</figcaption>
Today, thanks to Figma, visual, interaction, and content design can co-create within the same space. This approach better reflects how our disciplines can and should collaborate:
In early stages, when exploring ideas and shaping the architecture of an experience, content and design work together in a shared tool.
When it’s time to refine visuals, annotate interactions, or polish copy, our disciplines can branch off in different tools as needed, while staying in sync and on the same page. Then, we come back together to reflect the final visual and copy design in Figma.
“As the design systems team, it is very important to foster and support a culture of collaboration within the Firefox org for designing and making decisions together. Figma is a flexible design tool that has allowed the design systems team to partner more closely with teammates like content design, which ultimately means we build better products.” — Jules Simplicio, Design Systems, Firefox
Figma, Two Years Later: What We’ve Learned
1. Content design still needs other tools to do our jobs well
While Figma gave us the keys to the main design house, we continue to use other tools for copy development. There are a few steps critical to our process that Figma just can’t do.
Tools like Google Docs and Google Slides continue to serve us well for:
Content reviews with stakeholders like product management, legal, and localization
Aligning cross-functionally on content direction
Documenting rationale and context to tee up content recommendations
Managing comments and feedback
There’s no silver bullet tool for us, and that reflects the diversity of our stakeholders and collaborators, within and outside of UX. For now, we’ve accepted that our discipline will continue to need multiple tools, and we’ve identified which ones are best for which purpose.
<figcaption>Guidelines for tool usage. How and when to use what will flex according to context. Link to file.</figcaption>
Our pull towards tools that focus on the words also isn’t a bad or surprising thing. Focusing on language forces us to focus on understanding, first and foremost.
“Design teams use software like Sketch or XD to show what they’re designing — and those tools are great — but it’s easy to get caught up in the details… there’s no selector for figuring out what you’re working on or why it matters. It’s an open world — a blank slate. It’s a job for words… so before you start writing button labels, working on voice and tone guidelines, use the world’s most understated and effective design tool: a text editor.” Writing is Designing, Metts & Welfle
2. Content designers don’t need to become Figma experts
As a content designer, our focus is still on content: how it’s organized, what it includes, what it says. We’ve learned we don’t need to get into the Figma weeds of interaction or visual design, like creating our own components or variants.
However, we’ve found these basic functions helpful for collaboration:
Using a low-fidelity wireframe library (see below)
Inserting a component from a library
Copying a component
Turning things on or off within a complex component (example: hide a button)
Editing text within components
Creating sticky notes, pulling from a project template file (see below)
Exporting frames for sharing
Following someone in a file (for presentation and collaboration)
You can learn all these things in Figma’s public forums. But when we get stuck, we’ve saved ourselves time and frustration by asking a UX design colleague to troubleshoot. We’ve found that designers, especially those who work in design systems, are happy to help. We recommend creating or joining a Figma Slack channel at work to share ideas and ask questions.
3. Content designers DO need a low-fidelity library
Figma made it much easier for UX teams, including content design, to work in high fidelity. But this can be a blessing and a curse. It’s nice to be able to make quick adjustments to a component. However, when we’re in the early stages of a project we need to focus on ideas, strategy, and structure, rather than polish. We found ourselves getting distracted by details, and turning to other tools (like pen and paper) for visual explorations.
To solve for this, we partnered with the design systems team to create a low-fidelity wireframing library. We built this together, tested it, and then rolled it out to the broader UX team. As a result, we now have a tool within Figma that allows us to create mocks quickly and collaboratively. We created our custom library specific to browser design but Figma has many wireframing kits that you can use (like this one).
Our low-fidelity library democratizes the design process in a way that’s especially helpful for us writers: we can co-create with UX design colleagues using the same easy tools. It also helps people understand the part we play in determining things like information architecture. More broadly, working in low-fidelity work prevents stakeholders like engineering from thinking something is ready for hand-off when it’s not.
<figcaption>Example components from our low-fidelity library.</figcaption>
4. File structure is important
As new roommates, when we first started collaborating with UX designers in Figma, there was some awkwardness. We were used to working in separate tools. The Figma design canvas yawned before us. How would we do this? What the fig?
We collaborated with design systems to build a project template file. Of course, having a standard file structure and naming system is good documentation hygiene for any design team, but the template file also supports cross-discipline UX collaboration:
It puts some structure and process in place for that wide open Figma space, including identifying the end-to-end steps of the design process.
It gives us a shared set of tools to align on goals, capture thoughts, and track progress.
It helps concretize and solidify content design’s place and role within that process.
<figcaption>Screenshot of our Firefox Figma Project Template.</figcaption>
The file template is like a kit of parts. You don’t need all the parts for every design project. Certain pieces are particularly helpful for collaboration:
Status strip punch list to track the design and content review process. You can adjust the pill for each step as you move through the review process.
<figcaption>Our Firefox design status strip. Note, steps may happen in a different order (for example, localization is often earlier in the process).</figcaption>
Summary card: This asks UX and content designers to summarize the problem and share relevant documentation. As content designers, this helps us context switch more quickly (as we frequently need to do).
<figcaption>Summary card component in the Firefox Project Template.</figcaption>
Standardized layout: Design files can quickly get out of control, in particular for projects with a lot of exploration and iteration. The file suggests a vertical structure in which you move your explorations to a space below, with final design and copy at the top. This kind of documentation is helpful for cross-functional collaborators like product management and engineering so they can orient themselves to the designs and understand status, like what’s final and what’s still work-in-progress.
Content frame: This is a space to explore and document copy-specific issues like information architecture, localization, and terminology.
<figcaption>Content card in the Firefox Project Template.</figcaption>
Sticky notes and call-outs. The comment function in Figma can be tricky to manage. Comments get lost in the sea of design, you can’t search them, and you lose a thread once they are closed. For all those reasons, we tend to prefer sticky notes and call-outs, especially for meatier topics.
<figcaption>Sticky note and call-out cards in the Firefox Project Template.</figcaption>
Closing Thoughts
A tool is only as effective as the collaboration and process surrounding it. Our team is still figuring out the best way to use Figma and scale best practices.
At the end of the day, collaboration is about people. It’s messy and a continual work-in-progress, especially for content design. But, at least we’re in the same design house now, and it’s got good bones for us to continue defining and refining how our discipline does its work.
Thank you to Betsy Mikel, Brent G. Trotter, and Emily Wachowiak for reviewing this post. And thank you to our design systems collaborators, Jules Simplicio and Katie Caldwell, for all the work you do to make getting work done better.
Collected here are the most recent blog posts from projects all over the Mozilla community.
The content here is unfiltered and uncensored, and represents the views of community members.
Individual posts are owned by their authors -- see original source for licensing information.
<figcaption class="wp-element-caption">Jeff Lindsay is working to build the Photoshop of software at his company Progrium.</figcaption>
<figcaption class="wp-element-caption">Projects pictured from left to right: Nolano, Sanative AI and Kwanele Chat Bot.</figcaption>
<figcaption class="wp-element-caption">Imo Udom introduces the keynote speakers to the stage.</figcaption>
<figcaption class="wp-element-caption">Mozillians take part in a reception post-ceremony.</figcaption>
<figcaption class="wp-element-caption">Adam Bouhenguel has partnered with Mozilla to look for new ways to build ecosystems that support builders working on the next generation of the web.</figcaption>
Polishing the user interface
Message list
Message view
Bug fixes
<figcaption>Photo by 
<figcaption>Photo by 
As we continue to develop extensions support on Firefox for Android, we’re pleased to announce new additions to our library of featured Android extensions. To 
<figcaption>Photo by 
<figcaption>
<figcaption>To propose copy and design changes to the Firefox homepage, I had to re-create the mock in Google Slides.</figcaption>
<figcaption>Guidelines for tool usage. How and when to use what will flex according to context. 
<figcaption>Example components from our low-fidelity library.</figcaption>
<figcaption>Screenshot of our Firefox Figma Project Template.</figcaption>
<figcaption>Our Firefox design status strip. Note, steps may happen in a different order (for example, localization is often earlier in the process).</figcaption>
<figcaption>Summary card component in the Firefox Project Template.</figcaption>
<figcaption>Content card in the Firefox Project Template.</figcaption>
<figcaption>Sticky note and call-out cards in the Firefox Project Template.</figcaption>