Mozilla // William Durand

Moziversary #8

2026-05-01T00:00:00+00:00

Today is my eighth Moziversary 🎂 I joined Mozilla as a full-time employee on May 1st, 2018. I previously blogged in ~~2019~~, 2020, 2021, 2022, 2023, 2024, and 2025.

You might have come across this built-in data consent thing for extensions in Firefox. I spent a good chunk of last year working on this project, from developing a technical proposal to implementing the feature in Gecko, Firefox for desktop and Firefox for Android.

Talking about Android, I became the module owner for Fenix::Add-ons, a module for all the code related to add-ons in Firefox for Android (which we call “Fenix” internally). Between the creation of this new module, and an ever-solidifying collaboration between the Add-ons and Android teams, the support for extensions in Firefox for Android has a bright future! Having started my Android journey in 2023, this feels like a noteworthy achievement.

Near the end of last year, I moved back to being a full-time AMO engineer to support a team that was down to two engineers. I redesigned the detail page, and started some refactoring on our security scanners, which I had originally created back in 2019 😬

In other news, I joined the AI/LLM/vibe-coding crowd thanks to my colleague Paul, and it took me about a month to get brain-fried… AI fatigue is real, indeed. That said, Claude code has been somewhat useful to me, and I don’t hate it, but I also don’t love it.

Thank you to everyone in the Add-ons team as well as to all the folks I had the pleasure to work with so far. Cheers!

Moziversary #7

2025-05-05T00:00:00+00:00

A few days ago, this was my seventh Moziversary 🎂 I joined Mozilla as a full-time employee on May 1st, 2018. I previously blogged in ~~2019~~, 2020, 2021, 2022, 2023, and 2024.

While I may not have the energy to reflect extensively on the past year right now, I can say with confidence that the last 12 months have been incredibly productive, and things are generally going well for me.

Seven years later, I am still part of the Add-ons team. As a senior staff engineer, I am no longer working full time on the WebExtensions team. Instead, I am spending my time on anything related to Add-ons within Mozilla (be it Firefox, AMO, etc.).

My team went through a lot of changes over the last few years¹, with some years more memorable than others. About a year ago, things started to head into the right direction, and I am rather hopeful. It’s going to take some time, but the team is really set up for success again!

Shout-out to all my amazing colleagues at Mozilla, I wouldn’t be where I am today without y’all ❤️

Let’s talk briefly about the elephant. Mozilla has changed a lot too but I don’t have much control over that so I tend to not think too much about it 🤷 ↩

Firefox AI & WebExtensions

2025-03-24T00:00:00+00:00

I gave an introduction to the Firefox AI runtime and WebExtensions at a French local conference this month. This article is a loose transcript of what I said.

Let’s talk about Firefox, AI, and WebExtensions.

Browser extensions

Browser extensions are tiny applications that modify and/or add features to a web browser. Nowadays, these small programs can be written in such a way that they should be compatible with different browsers.

That’s because there exists a cross-browser system called “WebExtensions”, which – among other things – provides a set of common APIs that browser extensions can use. In addition to that, browsers can also expose their own APIs, and we’ll see that in a moment.

You’ll find a lot more information on this MDN page.

Note: During my talk, I used the Borderify extension to walk the audience through an example of a web extension. I then concluded that it’s super easy to get started but also very powerful. Extensions like uBlock Origin, Dark Reader, 1Password, etc. are rather powerful and sophisticated features.

Firefox AI runtime

Firefox has a new component based on Transformers.js and the ONNX runtime to perform local inference directly in the browser. In short, this runtime allows to use a model from Hugging Face (like GitHub but for Machine Learning models) directly in Firefox¹, without the need to send data to any servers. Every operation is performed on the user’s machine once the model files have been downloaded by Firefox.

While every website could technically load Transformers.js and a model, this isn’t very efficient. Say two websites use the same model, you end up with two copies of the model files. And those aren’t exactly small.

This Firefox component – also known as the Firefox (AI) runtime – addresses this problem by ensuring that models are shared. In addition, this runtime takes care of managing resources, and model inference is isolated from the rest of Firefox in an inference process.

Note: During my talk, I mentioned that – while we call this “AI” now – Mozilla has been doing Machine Learning (ML) for a very long time². For instance, Firefox Translations isn’t exactly new, and whether you like it or not, this is clearly an application of Generative AI³. Same thing, still.

Anyway, let’s see how we can interact with this runtime. We’re going to generate text that describes an image in the rest of this section.

The “hacker’s approach” is probably to open a Browser console in Nightly, and run some privileged JavaScript code:

const { createEngine } = ChromeUtils.importESModule(
  "chrome://global/content/ml/EngineProcess.sys.mjs"
);

const options = {
  taskName: "image-to-text",
  modelHub: "mozilla",
};
const engine = await createEngine(options);

const [res] = await engine.run({
  args: ["https://williamdurand.fr/images/posts/2014/12/brussels.jpg"],
});
// res => { generated_text: "A large poster of a man on a wall." }

As mentioned previously, the Firefox runtime is based on Transformers.js, which is why the code looks familiar when you know Transformers already. For instance, instead of passing an actual model here, we pass a task name. That’s an abstraction coming from Transformers. Don’t worry, we can also pass a model name and a lot of other (pipeline) options!

For those looking for a more graphical approach to play with this AI runtime, Firefox Nightly provides an about:inference page that looks like this:

That’s cool but… Why? Well, it turns out this example isn’t a random example. This code snippet is an overly simplified version of a feature in Firefox’s PDF reader (PDF.js ❤️): alt text generation⁴.

Screenshot of an “Edit alt text” dialog in PDF.js (inside Firefox): the image description has been automatically generated.

Note: During my talk, someone asked a question about the use of GPU, for which I didn’t have the answer. I do have it now, though. The Firefox AI runtime runs on CPU by default, but it is possible to run on GPU via WebGPU. It’s worth mentioning that this runtime doesn’t feel as fast as a more “native” solution (like Ollama) yet but the team at Mozilla is working on it!

Anyhow, let’s move to the final part of this ~~talk~~ article.

WebExtensions ML API

The best of both worlds, yay!

We shipped an experimental WebExtensions API to allow extensions to do local inference (docs), leveraging the Firefox AI runtime under the hood. Expect things to evolve, it’s bleeding edge technology!

At the time of writing this, we can rewrite the example from the previous section into “extension code” as follows:

const options = {
  taskName: "image-to-text",
  modelHub: "mozilla",
};
await browser.trial.ml.createEngine(options);

const [res] = await browser.trial.ml.runEngine({
  args: ["https://williamdurand.fr/images/posts/2014/12/brussels.jpg"],
});
// res => { generated_text: "A large poster of a man on a wall." }

This looks similar, right? That’s on purpose. For extension developers, the WebExtensions API namespace is trial.ml, and the associated permission is named trialML, which extensions must request at runtime.

What can we do with that, though? Well, what if we were to provide the alt-text-generation feature not just in PDFs but for any image on any website?

That’s what we have done in a demo extension (code, docs), which we can see in action in the screencast below:

At 00:00, the demo extension has been loaded in Firefox Nightly.
At 00:02, we open the context menu on an image in the current web page, and we click on “Generate Alt Text”. This menu entry has been added by the extension using the menus API by the way.
At 00:05, we can see that Firefox is downloading the model files (the UI is provided by the extension, which receives events from Firefox). This means the model was not used before so the Firefox AI runtime has to download the model files first. This step is only necessary when Firefox doesn’t already have the model used by the extension.
At 00:09, the model inference starts.
At 00:12, the result of the inference, which is the description of the image in this case, is returned to the extension, and the extension shows it to the user.

Your browser doesn't support HTML video.

Previously, I mentioned that browser extensions can be cross-browser. They can also run on different platforms as well. In Bug 1954362, I updated this demo extension so that it can run on Firefox for Android 😎

The screencast below shows the same extension running in Firefox for Android:

At 00:00, we can see a dialog because the extension has just been installed.
At 00:01, the extension opened a page in a new tab to request permission to interact with the Firefox AI runtime. This is pretty standard for browser extensions to request permissions ahead of time.
At 00:06, we load a web page with an image.
At 00:10, we use long-press on the image to trigger the extension because the menus API is not supported on Android yet (Bug 1595822).
At 00:12, similar to the previous screencast, Firefox starts by downloading the model files. This takes a lot of time because my emulator isn’t exactly fast. Do remember that this is only needed once, though.
At 01:09, the model inference starts.
At 01:12, the result of the inference, which is – again – the description of the image, is returned to the extension, and the extension shows it to the user.

Your browser doesn't support HTML video.

And that’s basically it.

I am personally looking forward to see what extension developers could do with this new capability in Firefox! And since this is related to my work at Mozilla, feel free to get in touch if you have questions.

Mozilla has its own “hub” too, so it isn’t just from Hugging Face. ↩
I wrote a bit about my use of ML at work in 2019 in this article. ↩
Firefox Translations generates text so this can be considered Generative AI. A major difference is that this doesn’t rely on a Large Language Model (LLM). Instead, Translations uses (Marian) Neural Machine Translation (NMT) models and the Bergamot runtime. ↩
My colleague Tarek wrote an extensive Hacks article about this in 2024. ↩

Senior Staff.

2025-03-01T00:00:00+00:00

I remember a conversation I had with a colleague a while back, shortly after I joined, where they told me that promotions at Mozilla were almost inevitable—that if you just stuck around long enough, you’d get promoted eventually¹.

It certainly didn’t feel like that to me.

I’ve been working at Mozilla for about 7 years and I was last promoted in 2021. I joined the WebExtensions team in 2022 to work on Manifest Version 3, and then I led the engineering efforts to offer full add-ons support for Firefox for Android in 2023. I became the tech lead for Add-ons in 2024.

This month, I’ve been promoted to Senior Staff Software Engineer! 🥳

But, what is a Senior Staff? Mozilla says it is an individual “recognized as one of a small set of renowned experts in an important area”, who is able to “lead projects requiring implementation across multiple teams”.

I’m grateful to my manager and coworkers for their support and guidance over the years. I’ve been able to achieve so much more than I thought possible thanks to them! ❤️

Coincidentally, and years later, another colleague told me this person had actually worked hard to get where they were, and it wasn’t just a matter of showing up and waiting for a promotion to happen 🙃 ↩

Moziversary #6

2024-05-01T00:00:00+00:00

Today is my sixth Moziversary 🎂 I joined Mozilla as a full-time employee on May 1st, 2018. I previously blogged in ~~2019~~, 2020, 2021, 2022, and 2023.

Last year, I mainly contributed to Firefox for Android as the lead engineer on a project called “Add-ons General Availability (GA)”. The goal was to allow for more add-ons on this platform. Success! More than a thousand extensions are now available on Android 🎉

In addition, I worked on a Firefox feature called Quarantined Domains and implemented a new abuse report form on addons.mozilla.org (AMO) to comply with the Digital Services Act (DSA). I was also involved in two other cross-team efforts related to the Firefox installation funnel. I investigated various issues (e.g. this openSUSE bug), and I coordinated the deprecation of weak add-on signatures and some more changes around certificates lately, which is why I wrote xpidump.

Phew! There is no shortage of work.

When I moved to the WebExtensions team in 2022, I wrote about this incredible challenge. I echoed this sentiment several months later in my 2022 Moziversary update. I couldn’t imagine how much I would achieve in two years…

Back then, I didn’t know what the next step in my career would be. I have been aiming to bridge the gap between the AMO and WebExtensions engineering teams since at least 2021 and that is my “next step”.

I recently took a new role as Add-ons Tech Lead. This is the continuation of what I’ve been doing for some time but that comes with new challenges and opportunities as well. We’ll see how it goes but I am excited!

I’ll be forever grateful to my manager and coworkers. Thank you ❤️

Introducing xpidump

2024-04-08T00:00:00+00:00

I wrote xpidump to give a human-readable summary of some information about a Firefox add-on. It is designed to answer these two questions: is the add-on likely¹ signed? And if so, how?

This tool takes an XPI file as input. XPI files are Firefox add-ons packaged as ZIP archives with the .xpi file extension. xpidump currently extracts information from up to 4 files in an XPI (depending on what is available in the archive):

manifest.json: this JSON file defines the add-on. It is required in any add-on (packaged or not, signed or not).
META-INF/mozilla.rsa: this binary file is a PKCS#7 signature. Any signed add-on should have this file (in addition to META-INF/mozilla.sf and META-INF/manifest.mf but xpidump doesn’t read them).
META-INF/cose.sig: this binary file is a COSE signature². It might not be present when the add-on isn’t signed or relatively old³. There should also be a META-INF/cose.manifest file when this file exists.
mozilla-recommendation.json: this JSON file is generated by Mozilla’s signing service Autograph when an add-on is signed with recommendation states. This is how Firefox knows that an add-on is recommended for instance. It might or might not be present.

xpidump is both a command-line tool and a web app since the latter is usually more convenient (no need to install anything). It’s written in Rust, and compiled to WebAssembly for the web app. You can try it at: williamdurand.fr/xpidump/.

xpidump is available in the browser thanks to WebAssembly!

The code is published on GitHub under the MIT license, see: willdurand/xpidump. I don’t have any more plans for this weekend-ish project, it’s doing what I wanted it to be doing… Let me know if you have ideas, though.

One more thing while we’re here… If you want a tool to read the entire content of any XPI file and get tons of information, you want to use CRX Viewer created by my brilliant colleague Rob!

This tool doesn’t verify the signature, so it cannot guarantee that the add-on is correctly signed. ↩
Well, a COSE sign message with a signature and serialized with CBOR, though we should probably refer to the protocol as COSEish because of this issue. ↩
Mozilla started to dual-sign add-ons in 2019. ↩

Moziversary #5

2023-05-01T00:00:00+00:00

Today is my fifth¹ Moziversary 🎂 I joined Mozilla as a full-time employee on May 1st, 2018. I previously blogged in ~~2019,~~ 2020, 2021, and 2022.

I spent a good chunk of last year working on Manifest Version 3 (MV3) with the rest of my team (WebExtensions / Add-ons team). My most notable “H1 2022” contributions were probably the scripting namespace and a simpler versioning format.

The extensions button and its panel (with 3 extensions listed) in Firefox.

Next, I worked on a new primary User Interface (UI) for Firefox Desktop: the extensions button. This feature wasn’t unanimously well-received² ³ (like many other changes to the Firefox UI). Anyway, I addressed different (usability) issues since then, and I will continue to do so!

I also…

took over more web-ext maintenance (in addition to addons-linter)
contributed content to support.mozilla.org (SUMO)
added WebMIDI support to navigator.permissions.query()
wrote my first Web platform test. Pretty cool!
committed to new repositories such as scriptworker-scripts, xpi-template, MDN, browser-compat-data, and firefox-android lately
found myself involved in various incidents…
stopped hating Jira

But wait, there is more!

When I was on the AMO team, we had to maintain a feature named “Return to AMO” (RTAMO). In short, this feature allows new users interested in an add-on on addons.mozilla.org (AMO) to download Firefox and install the add-on when Firefox starts for the first time (without having to go back to AMO). RTAMO was extended to more add-ons at the beginning of 2022 (and I was involved). I became very knowledgeable about how attribution worked and documented all of that.

This is one of the reasons why I became the main owner⁴ of the stub attribution service, an HTTP server that encodes attribution data in Firefox (for Windows) installers and – incidentally – one of the few critical services involved when users download Firefox. Coincidentally, this project is now at the center of different 2023 projects. Good thing I took the time to put this project back on track 😛

Phew. That was a good year! I am now involved in many cross-functional projects and I really enjoy it. Speaking of which, I am currently working on bringing more add-ons to Firefox for Android 🚀

That’s all for now. Many thanks to everyone I worked with over the last 12 months, it’s been great working with all of you!

5 years or… 5 months? I moved back to France and my current employment contract started on January 1st, heh. Still better than nothing, though. ↩
In case you didn’t know, many engineers read Reddit and/or other social platforms. I’ve shared actionable feedback from public comments internally more than once. That said, writing that the extensions button is the “worst Mozilla idea of the decade” isn’t helpful. ↩
If I may, I would add that reaching out to me personally to say that you hate the button is probably not OK. ↩
I am (still) trying to build a small team around this project and another one. If you want to join the fun, please let me know! ↩

Developing Firefox in Firefox with Gitpod

2022-05-03T00:00:00+00:00

Gitpod provides Linux-based development environments on demand along with a web editor frontend (VS Code). There is apparently no limit on what you can do in a Gitpod workspace, e.g., I ran my own toy kernel in QEMU in the browser.

I like Gitpod because it…

avoids potential issues when setting up a new project, which is great for the maintainers (e.g., it is easier to reproduce an issue when you have access to the same environment) and the newcomers (e.g., no fatal error when trying to contribute for the first time)
allows anyone to have access to a (somewhat) powerful machine because not everyone can afford a MacBook Pro. I suppose one needs a pretty reliable Internet connection, though

Motivations

My main machine runs MacOS. I also have a Windows machine on my desk (useful to debug annoying Windows-only intermittent failures), which I access with Microsoft Remote Desktop.

It looks like Gitpod, runs like Gitpod, and quacks like Gitpod but it isn’t Gitpod!

Except my ever growing collection of single-board computers, I don’t have a Linux-based machine at home^W work, though. I haven’t used Virtual Machines on Apple Silicon yet and I’d rather keep an eye on Asahi Linux instead.

This is why I wanted to give Gitpod a try and see if it could become my Linux environment for working on Firefox. Clearly, this is a nice to have for me (I don’t necessarily need to build Firefox on Linux) but that might be useful to others.

Assuming a Gitpod-based setup would work for me, this could possibly become a strong alternative for other contributors as well. Then, mayyybe I could start a conversation about it internally in the (far) future.

Note that this isn’t a novel idea, Jan Keromnes was already working on a similar tool called “Janitor” for Mozilla needs in 2015.

Firefox development with Gitpod = ❤️

I recently put together a proof of concept and played with it since then. This GitHub repository contains the Gitpod configuration to checkout the Firefox sources as well as the tools required to build Firefox.

It takes about 7 minutes to be able to run ./mach run in a fresh workspace (artifact mode). It is not super fast, although I already improved the initial load time by using a custom Docker image. It is also worth mentioning that re-opening an existing workspace is much faster!

./mach run executed in a Gitpod workspace

Gitpod provides a Docker image with X11 and VNC, which I used as the base for my custom Docker image. This is useful to interact with Firefox as well as observing some of the tests running.

A “mochitest” running in a Gitpod workspace

I don’t know if this is the right approach, though. My understanding is that Gitpod works best when its configuration lives next to the sources. For Firefox, that would mean having the configuration in the official Mozilla Mercurial repositories but then we would need hgpod.io 😅

On the other hand, we develop Firefox using a stacked diff workflow. Therefore, we probably don’t need most of the VCS features and Gitpod does not want to be seen as an online IDE anyway. I personally rely on git with the excellent git-cinnabar helper, and moz-phab to submit patches to Phabricator. Except for the latter, which can easily be installed with ./mach install-moz-phab, these tools are already available in Gitpod workspaces created with my repository.

In terms of limitations, cloning mozilla-unified is the most time-consuming task at the moment. Gitpod has a feature called Prebuilds that could help but I am not sure how that would work when the actual project repository isn’t the one that contains the Gitpod configuration.

In case you’re wondering, I also started a full build (no artifact) and it took about 40 minutes to finish 🙁 I was hoping to have better performances out of the box even if it isn’t that bad. For comparison, it takes [~15min on my MacBook Pro with M1 Max]¹ (and 2 hours on my previous Apple machine).

There are other things that I’d like to poke around. For instance, I would love to have rr support in Gitpod. I gave it a quick try and it does not seem possible so far, maybe because of how Docker is configured.

gitpod /workspace/gitpod-firefox-dev/mozilla-unified (bookmarks/central) $ rr record -n /usr/bin/ls
[FATAL /tmp/rr/src/PerfCounters.cc:224:start_counter() errno: EPERM] Failed to initialize counter

After a few messages exchanged on Twitter, Jan Keromnesjan (yeah, same as above) from Gitpod filed a feature request to support rr 🤞

Next steps

As I mentioned previously, this is a proof of concept but it is already functional. I’ll personally continue to evaluate this Linux-based development environment. If it gets rr support, this might become my debugging environment of choice!

Now, if you are interested, you can go ahead and create a new workspace automatically. Otherwise please reach out to me and let’s discuss!

One more thing: Mozilla employees (and many other Open Source contributors) qualify for the Gitpod for Open Source program.

This used to be a link to a tweet from me:

This new MBP 14” with M1 Max chip seems promising: keyboard feels nice, no distracting touch bar, and it compiles Firefox in less than 15 minutes! (vs ~2 hours with my previous machine)

↩

Moziversary #4

2022-05-01T00:00:00+00:00

Today is my fourth Moziversary 🎂 I have been working at Mozilla as a full-time employee for 4 years. I blogged two times before: in 2020 and 2021. What happened in 2019? I. Don’t. Know.

I was hired as a Senior Web Developer on addons.mozilla.org (AMO). I am now a Staff Software Engineer in the Firefox WebExtensions team. I officially joined this team in January. Since then, I became a peer of the Add-ons Manager and WebExtensions modules.

Farewell AMO!

As mentioned above, I moved to another team after many years in the AMO team. If I had to summarize my time in this team, I would probably say: “I did my part”.

Earlier this year, I transferred ownership of more than 10 projects that I either created or took over to my former (AMO) colleagues 😬 I was maintaining these projects in addition to the bulk of my work, which has been extremely diverse. As far as I can remember, I…

worked on countless user-facing features on AMO, quickly becoming the top committer on addons-frontend (for what it’s worth)
contributed many improvements to the AMO backend (Django/Python). For example, I drastically improved the reliability of the Git extraction system that we use for signed add-ons
developed a set of anti-malware scanning and code search tools that have been “a game changer to secure the add-ons ecosystem for Firefox”
introduced AWS Lambda to our infrastructure for some (micro) services
created prototypes, e.g., I wrote a CLI tool leveraging SpiderMonkey to dynamically analyze browser extension behaviors
almost integrated Stripe with AMO 🙃
shipped entire features spanning many components end-to-end like the AMO Statistics (AMO frontend + backend, BigQuery/ETL with Airflow, and some patches in Firefox)
created various dev/QA tools

Last but not least, I started and developed a collaboration with Mozilla’s Data Science team on a Machine Learning (security-oriented) project. This has been one of my best contributions to Mozilla to date.

What did I do over the last 12 months?

I built the “new” AMO blog. I played with Eleventy for the first time and wrote some PHP to tweak the WordPress backend for our needs. I also “hijacked” our addons-frontend project a bit to reuse some logic and components for the “enhanced add-on cards” used on the blog (screenshot below).

The AMO blog with an add-on card for the “OneTab” extension. The “Add to Firefox” button is dynamic like the install buttons on the main AMO website.

Next, I co-specified and implemented a Firefox feature to detect search hijacking at scale. After that, I started to work on some of the new Manifest V3 APIs in Firefox and eventually joined the WebExtensions team full-time.

I also…

wrote a blog post about the add-ons linter on the Community Blog
interviewed candidates (if you want to discuss, we’re hiring 😉)
took the time to meet new colleagues in a few donut chats
accidentally prevented huge unnecessary storage costs 😅

This period has been complicated, though. The manager who hired me and helped me grow as an engineer left last year 😭 Some other folks I used to work with are no longer at Mozilla either. That got me thinking about my career and my recent choices. I firmly believe that moving to the WebExtensions team was the right call. Yet, most of the key people who could have helped me grow further are gone. Building trustful relationships takes time and so does having opportunities to demonstrate capabilities.

Sure, I still have plenty of things to learn in my current role but I hardly see what the next milestone will be in my career at the moment. That being said, I love what I am doing at Mozilla and my team is fabulous ❤️

Thank you to everyone in the Add-ons team as well as to all the folks I had the pleasure to work with so far!

Some non-production tools I wrote

2022-03-29T00:00:00+00:00

This is a short article about 3 different tools I authored for my needs at Mozilla.

I worked on AMO for almost 4 years and created various libraries like pino-mozlog, pino-devtools or an ESLint plugin to name a few. These libraries have been created either to improve our developer experience or to fulfill some production requirements.

This isn’t the kind of projects I want to focus on in the rest of this article, though. Indeed, I also wrote “non-production” tools, i.e. some side projects to improve my day-to-day work. These tools have been extremely useful to me and, possibly, other individuals as well. I use most of them on a weekly basis and I maintain them on my own.

amo-info

I wrote a browser extension named amo-info. This extension adds a page action button when we open the web applications maintained by the AMO/Add-ons team. Clicking on this button reveals a pop-up with relevant information like the environment, git tag, feature flags, etc.

The amo-info extension displaying information about addons.mozilla.org.

If this sounds familiar to you, it might be because I already mentioned this project in my article about feature flags. Anyway, knowing what is currently deployed in any environment at any given time is super valuable, and this extension makes it easy to find out!

I recently added support for Firefox for Android but it only works in Nightly.

`git npm-release`

A different tool I use every week is the git npm-release command, which automates my process to release new versions of our JavaScript packages.

$ git npm-release -h
usage: git npm-release [help|major|minor|patch]

git npm-release help
        print this help message.
git npm-release major
        create a major version.
git npm-release minor
        create a minor version.
git npm-release patch
        create a patch version.

For most of our JavaScript projects, we leverage a Continuous Integration (CI) platform (e.g., CircleCI) to automatically publish new versions on the npm registry when a git tag is pushed to a GitHub repository.

The git npm-release command is built on top of hub, npm version and a homemade script to format release notes. Running this command will (1) update the package.json file with the right version, (2) make a git tag, (3) prepare the release notes and open an editor, (4) push the commit/tag to GitHub, and (5) create a GitHub release.

This process isn’t fully automated because (3) opens an editor with the pre-formatted release notes. I usually provide some more high level information in the notes, which is why this step requires manual intervention.

fx-attribution-data-reader

This is a tool I created not too long ago after telling a QA engineer that “he could simply open the binary in an hex editor” 😅 I can find my way in hex dumps because my hobbies are weird but I get that it isn’t everyone else’s cup of tea.

The fx-attribution-data-reader web application takes a Firefox for Windows binary and displays the attribution data that may be contained in it. Everything is performed locally (in the browser) but the results can also be shared (URLs are “shareable”).

The fx-attribution-data-reader tool with a binary loaded and parsed.

Currently, this is mainly useful to debug some add-ons related features and it is very niche. As such, this tool isn’t used very often but this is a good example of a very simple UI built to hide some (unnecessary) complexity.

Conclusion

I introduced three different tools that I am happy to use and maintain. Is it worth the time? I think so because it isn’t so much about the time shaved off in this case.

It is more about the simplicity and ease of use. Also, writing new tools is fun! I often use these ideas as excuses to learn more about new topics, be it programming languages, frameworks, libraries, or some internals.

I joined a new team (at Mozilla)

2022-01-25T00:00:00+00:00

The year is 2022 and I am still using my blog to share personal-ish status updates. Today’s post is about my career.

I work at Mozilla for ~4 years now (including my time as a contractor). After having worked on many things and getting a promotion not too long ago, I made a lateral move.

I am now a full-time Firefox engineer, working on the WebExtensions API. I’ve been working on “web apps” for most of my career and now I’ll be writing code for developers to write browser extensions.

This is scary and maybe a bit silly (career-wise) but this is also an incredible challenge for me. That’s what I wanted. That’s what I needed. I left a great team to join a fantastic team where I am the least experienced in the domain we own. It almost feels like I am back at the beginning of my career, except that I now know how much I don’t know. Ha, well. It’s going to be fine.

Moziversary #3

2021-05-01T00:00:00+00:00

Three years at Mozilla, yay! 🎉 It’s my longest time at the same company, and I am now a Staff Software Engineer. What a ride!

A year ago, I wrote that I was starting to be more involved in Firefox. I worked on very diverse projects in 2020 but one of them was super fun: we revamped the AMO statistics and it required backend changes on AMO, some ETL/BigQuery work, and new data collection in Firefox. I worked on all those components and learned a lot of stuff along the way. I also [deleted a lot of code]¹, [changed a lot of code]², contributed to Firefox for Android (Fenix), created new libraries to support the work of my team, continued to work on security stuff, and even wrote some PHP lately.

My role is constantly evolving. By knowing every bit of the AMO platform and expanding my skill sets with contributions in Firefox, I am hoping to have a wider vision of add-ons in general, from a technical perspective. I am doing my best to bridge the gap between the AMO and WebExtensions engineering teams, which will be welcomed as more Product requirements need changes in both contexts.

Now, thinking about the last 12 months, there are areas that I would like to improve.

I mentioned it above, I work on very different projects and components. It’s exciting because I am never bored, I can help many folks and I learn a lot but context switching is hard. My tmux session has ~10 windows open all the time nowadays (one per project) so I had to adapt. I wrote a bunch of scripts to automate some maintenance tasks, I started to dedicate specific days to certain projects, and I learned to be more strict about priorities. I still have some work to do on that front, though.

I noticed that all these different projects kinda “forced” me to “move fast”, and too fast actually. It didn’t negatively impact anything (yet) but I’ve definitely been reminded that the answer to my question was in the GitHub issue that I had just read. Hence I am working on taking more time to think… and I’ll also take the opportunity to refine my communication skills.

Last, I am extremely happy at Mozilla and I am super lucky to be part of the amazing Add-ons team. I would like to thank everyone in my team as well as all the folks I worked with so far! I wouldn’t be where I am today without you ❤️

This used to be a link to a tweet from me. I tweeted a screenshot with diff stats, showing a lot of code removed after I removed a lot of code in a project. ↩
This used to be a link to a tweet from me. I tweeted a screenshot with diff stats, showing a lot of changed code after having applied a python code formatter on a large codebase. ↩

Yes, it happened on Slack

2021-04-29T00:00:00+00:00

This is one of those moments worth calling out explicitly.

Yes, it happened on Slack

Here, it refers to a decision, an agreement, or some important results. All of these should NOT have been left on Slack alone. At the very least, the Slack threads or some key messages should have been copied into some more open and permanent places like Bugzilla or GitHub (in public issues).

It won’t come as a surprise; I don’t like Slack (but it wasn’t always like that). There is a reason for that: it is the antithesis of working in the open. What happens in Slack stays in Slack. What stays in Slack is basically lost forever. “Chat apps” aren’t the right tools for decision-making, especially when working with external contributors and distributed teams across the globe.

I understand the need for synchronous communication, but (1) we have Matrix at Mozilla, which is open at least, and (2) we should not use Slack for asynchronous communication. Let’s just use it for quick feedback, instant chats about sensitive topics, GIFs, and emojis on every other message. Jokes aside, it’s easier to restrict some content than to publish private content more broadly.

Working in the open is what makes Firefox and other Mozilla products so special: anyone can contribute. Each individual can find information about a decision on GitHub or Bugzilla. I personally dig into old GitHub issues at least once a week, usually with a question in mind like “why did we do that?”. Back then, everything was either relatively well documented on GitHub/Bugzilla or captured in broadly accessible Google Docs, which makes it possible to answer my question. Nowadays, it’s not uncommon for me to “request access” to some docs I have to read for my own work…

We should continue to use open and accessible platforms to capture not only the decisions but also the “why” (context), and keep them available for the future. Not only will this be useful to us, but it will also allow our contributors to participate even more and feel more “in the loop”.

Note: this article reflects my experience within my team at Mozilla, but the views expressed may be relevant beyond that context.

I got a promotion!

2021-02-26T00:00:00+00:00

Long story short, I have been promoted to Staff Software Engineer.

Julia Evans explains what a senior engineer’s job is and her blog post describes my role well enough, which is why I won’t go into details here. Instead, I chose to write a more personal “status update”.

First of all, Mozilla has a great [career path for engineers]¹, which doesn’t force folks who like to code to become managers, a very common practice in French companies (and maybe elsewhere, ugh!). It’s such a relief!

Second, this new title won’t change my day to day work right now: I have been promoted because I was already doing some of the job of a staff engineer and I likely proved that I was a good fit for this role. I still have many new things to learn, though, and that’s very exciting!

3615 My Life

I joined Mozilla as a frontend developer. I exclusively worked on the AMO frontend in 2018 and eventually became a major contributor. During this time, I started to maintain some side-projects (eslint config/plugin). After a year, I decided to become more proficient with python so I started to contribute to our main backend/API project. This allowed me to work on much bigger features by myself, and I learned a lot more about add-ons and the AMO platform.

In 2019, my main focus was on hardening the AMO platform, a topic that is unfortunately confidential. This work started as a research-y project because we didn’t really know what we could come up with. I chose to use what I learned during my PhD: I studied the “state of the art”. After that, I built several prototypes and presented the results of my initial work to different people, got feedback, iterated, and eventually proposed a plan to move forward. Some prototypes became “production-ready” and are now running in production while others have been shelved.

During this period, I also started a collaboration between a Machine Learning (ML) team and my own team. We wanted to give ML a try but we didn’t know exactly how. I looked into that on my own first! I wanted to be able to ask good questions and, to me, it was necessary to be more familiar with ML and have an idea of how things should be designed. I played with scikit-learn and Jupyter to have some preliminary results that I shared with the ML team along with a lot of questions to ask. I don’t know if that was the “right” thing to do but it worked and the collaboration is still on-going.

In 2020, I worked on various projects between my parental leave and the rounds of layoffs… I started to contribute to Firefox (more on that later) and I adopted a few more projects that needed some maintenance. I also realized that I could bridge the gap between the AMO and WebExtensions (Firefox) teams, so I tried (and continues) to do that.

I didn’t really have any goal in mind when I joined Mozilla (except not being fired because I was a fraud, maybe). Over time, I started to look into new topics because I needed to learn something new and things in front of me were interesting. I feel lucky to have been assigned to this security topic back in 2019, it had a huge impact on my career because I could show what I was able to do. I chose not to be too specialized because that’s not who I am anyway (I suck at being good at one thing so I try to be average on many things instead). I think that works well.

I wouldn’t be there without my amazing colleagues in the Add-ons team. Thanks to all of you! A special note to my current manager (who hired me too): you were already on my “list” of people who largely influenced my career and therefore my life, and you continue to have an immense positive impact. I’ll be forever grateful, thank-you.

Last but not least, I couldn’t end this section without mentioning my partner. She’s been very supportive and did an amazing job at taking care of our little one while I was at work last year <3

This now sounds like an Oscar speech so let’s talk about something else.

In other news

The Firefox codebase was (and still is) kinda scary to me. This is one of those things where I thought I could never contribute to it. That’s a huge project, with a lot of users (I know what you’re thinking!), and developed by many contributors every day. Thanks to my amazing self-confidence (follow the link if you don’t get the irony), I decided to contribute to Firefox roughly a year ago, and this became my personal development goal for the rest of the year. I landed trivial patches and made all the possible mistakes. I learned a lot with Rob and then Luca.

In Q3 2020, I worked on new AMO statistics for add-on developers, which involved various components² and required some Firefox changes. I was able to land some patches in Firefox in order to support the rest of my work. That was really cool because I worked on ALL the building blocks.

Last month, I got Commit Access Level 3 on Firefox! It’s rewarding because it means I earned the trust of my peers.

I am so happy!

This used to be a link to a tweet from @Gankra_:

i really like that mozilla has an engineer track that just tries to capture the depth/responsibility of the tasks you’re currently tackling, and doesn’t necessarily involve moving on to management roles

[screenshot of a spreadsheet with the Mozilla’s career ladder]

↩
I was working on a project involving some frontend work and a lot of backend changes for AMO. I also had to prototype the ETL queries and implemented a feature to collect data I needed in Firefox. ↩

Feature flags in real life

2020-09-22T00:00:00+00:00

Many folks are familiar with the concept of feature toggles (also known as feature flags) but they do not necessarily use them because <insert reason here>. This is a very powerful technique that allows teams to ship new features and/or experiments in a controlled way. My team uses different flavors of feature toggles on the AMO platform, and that is what I am going to describe in this article.

Backend toggles

The AMO server-side is mainly powered by a Django application and we are using Waffle to implement the different feature toggles. Waffle has three types of feature flippers: flags, switches and samples, depending on the needs. I am not very familiar with the last one, which seems to be a better packaged version of rand(), so I’ll only introduce the first two flippers.

Flags

Flags are probably what most people have in mind when thinking about feature toggles. They are convenient to roll out features according to various conditions, like specific users or percentage of traffic.

My team uses flags to progressively enable new features in production. This can be useful when the feature can only be fully tested in production, e.g., because it is not possible to set up a realistic (enough) environment or it has privacy implications. Flags can certainly be used for other purposes but I am mainly familiar with these ones.

This is how I shipped the new usage statistics on AMO to end users earlier this year for instance. That was handy to iterate quickly and give early access to Quality Assurance (QA) folks, Project/Product Managers (PMs), and key users (in this case, developers of very popular add-ons to measure the performance impacts). Later, we updated the flag configuration to perform a rollout (25/50/75/100%). During this rollout, users got access to a “beta mode” (the new feature I was working on) in addition to the legacy feature but it does not have to be this way.

It is also possible to use a toggle to change a feature entirely for everyone, and that is the strategy I used for the download stats on AMO lately. This is useful to preview a feature without risking a production incident!

Switches

Being able to turn a feature on and off for everyone in production can also be achieved by a switch. Switches cannot target specific users or things like that, but it is what we use the most on AMO.

For example, we have switches that act as emergency switches to quickly react to potential outages in production. Our kinda monolithic server-side application talks to some smaller services and if one of them goes crazy, we can quickly shunt it so that it does not take the entire platform down.

We also use switches to change parts of our application that run in the background like cron jobs or asynchronous tasks. In the case of the new AMO statistics, I used switches to change the data source of the tasks that compute particular values (e.g., average daily users, etc.). After having tested the new behavior in our non-production environments, we turned the switches on in production at a given time and we monitored the first executions.

Similar to flags, switches are great to ship big features incrementally and allow long periods of tests in non-production environments. That way, we can detect and fix most issues early, preventing disasters when we go “live”.

Frontend toggles

We do not have the exact same concept in our main frontend application, but we do have some sort of client-side feature toggles. We came up with a convention to implement switches on top of node-config and our very own client-side implementation for it. We use frontend switches quite often so that QA can verify the changes before they are deployed in production. In addition to that, we can start conversations with PMs and User eXperience (UX) people while we are implementing the changes.

Our feature flipper implementation may appear naive, it works great for us. We shipped new pages, homepage redesigns, and other minor features behind such switches. That being said, this approach is not as flexible as its server equivalent because it requires a deployment to update the values of the switches.

How do we test our code?

Django Waffle stores its configuration in the database and provides helper functions to create flags or switches in a test case. We usually write similar tests with the feature toggle enabled and disabled.

Most of our frontend code is written with React. We use a pattern that consists in passing a _config prop whose default value is the actual node config and we override it in the test case with a fake config object. That way, we can unit test all possible conditions:

import config from 'config';

function Welcome({ _config = config } = {}) {
  return (
    <h1>Hello, {_config.get('enableFeatureXYZ') ? 'XYZ' : 'World'}</h1>
  );
}

// test file
it('renders Hello, World when the XYZ feature is disabled', () => {
  const _config = getFakeConfig({ enableFeatureXYZ: false });
  expect(renderWelcome({ _config })).toHaveText('Hello, World');
});

it('renders Hello, XYZ when the XYZ feature is enabled', () => {
  const _config = getFakeConfig({ enableFeatureXYZ: true });
  expect(renderWelcome({ _config })).toHaveText('Hello, XYZ');
});

When adding a new behavior behind a toggle to an existing feature, we usually update the test suite to work as before and we add new test cases for the new behavior. This often implies the addition of very similar test cases but it is not so bad as we always plan to delete some code later on.

A note on code quality

Every time we introduce a Waffle flag, a switch or a frontend toggle, we file a GitHub issue to clean up the code once there is no need for it anymore. If the author forgets about it, this is usually raised during the code review. This is how we mitigate the risk of having spaghetti code. Some toggles (like emergency switches) are more permanent, though.

In the server codebase, we delete the Waffle flag or switch using a database migration, then we remove the old code (including the toggle) and we update the test suite accordingly.

Bonus: amo-info

I created a Firefox extension called “amo-info” to display various information about the public-facing part of the AMO platform. Among other things, this extension shows the configuration of our frontend toggles to quickly see which features are enabled/disabled in our different environments:

That’s it for today :-) Are you using feature toggles too? I’d be interested in knowing how you manage them and what you do differently than us. Don’t hesitate to get in touch!

Moziversary #2

2020-05-01T00:00:00+00:00

Today is my second Moziversary. I joined Mozilla as a full-time employee on May 1st, 2018, not too long after contracting with them via my previous company.

I am part of the Firefox Add-ons team and I work on AMO, which is much more than “just a website”. I spent 2019 working on the server stack as well as creating and deploying new security tools to cope with malicious activities. Everyone seems happy with my work, I received positive feedback from my peers and manager and I even “over-performed” last year. In 2020, I started to work on the Firefox codebase and that’s exciting!

Now, if I ask you to name the first thing about your current employer when you think about it, what would it be? For me, and that might sound dumb but it is the truth, my first thought is “Mozilla Firefox”, that piece of software I installed on every computer I could when I was 16-17 years old because “it was much faster than Internet Explorer” and… free. That was in the early 2000s.

My father was working for the main telecommunications company in France back then. Once my parents could afford a personal computer at home in the late 1990s (an IBM Aptiva <3), we were able to get 56k Internet, then 128k (ISDN) and later DSL. That’s how I met the Internet but it took me a few more years and bad grades in high school to grow an interest in computers.

I never imagined that I could work for a company whose icon was sitting on the Windows 98 Desktop of my parents’ computer one day. And yet, here I am, and that’s why Mozilla is and will always be special to me. It’s an immense part of my teenager memories, it reminds me where I come from (including my privilege).

Contrary to many of my colleagues, I wasn’t a volunteer before joining Mozilla and I knew little to nothing about Mozilla Corporation. I was following some of the Mozilla Foundation initiatives but I wasn’t a Mozillian. I fixed that since then ;-)

I am grateful to my current manager (who hired me) as well as all my colleagues in the Add-ons team and beyond. They are all amazing folks! I learned tons of things about everything, including myself, and these two years have been absolutely fantastic. Thanks y’all!