Please meet Oriol Brufau, our newest Friend of Add-ons! Oriol is one of 23 volunteer community members who have landed code for the WebExtensions API in Firefox since the technology was first introduced in 2015. You may be familiar with his numerous contributions if you have set a specific badge text color for your browserAction, highlighted multiple tabs with the tabs.query API, or have seen your extension’s icon display correctly in about:addons.

While our small engineering team doesn’t always have the resources to implement every approved request for new or enhanced WebExtensions APIs, the involvement of community members like Oriol adds considerable depth and breadth to technology that affects millions of users. However, the Firefox code base is large, complex, and full of dependencies. Contributing code to the browser can be difficult even for experienced developers.

As part of celebrating Oriol’s achievements, we asked him to share his experience contributing to the WebExtensions API with the hope that it will be helpful for other developers interested in landing more APIs in Firefox.

When did you first start contributing code to Firefox? When did you start contributing code to WebExtensions APIs?

I had been using Firefox Nightly, reporting bugs and messing with code for some time, but my first code contribution wasn’t until February 2016. This was maybe not the best choice for my first bug. I managed to fix it, though I didn’t have much idea about what the code was doing, and my patch needed some modifications by Jonathan Kew.

For people who want to start contributing, it’s probably a better idea to search Bugzilla for a bug with the ‘good-first-bug’ keyword. (Editor’s note: you can find mentored good-first-bugs for WebExtensions APIs here.)

I started contributing to the WebExtensions API in November 2017, when I learned that legacy extensions would stop working even if I had set the preference to enable legacy extensions in Nightly. Due to the absence of good compatible alternatives to some of my legacy add-ons, I tried to write them myself, but I couldn’t really do what I wanted because some APIs were buggy or lacked various features. Therefore, I started making proposals for new or enhanced APIs, implementing them, and fixing bugs.

What were some of the challenges to building and landing code for the WebExtensions API?

I wasn’t very familiar with WebExtensions APIs, so understanding their implementation was a bit difficult at first. Also, debugging the code can be tricky. Some code runs in the parent process and some in the content one, and the debugger can make Firefox crash.

Initially, I used to forget about testing for Android. Sometimes I had a patch that seemed to work perfectly for Linux, but it couldn’t land because it broke some Android tests. In fact, not being able to run Android tests locally in my PC is a big annoyance.

What resources did you use to overcome those challenges?

I use https://searchfox.org, a source code indexing tool for Firefox, which makes it easy to find the code that I want to modify, and I received some help from mentors in Bugzilla.

Reading the documentation helps but it’s not very detailed. I usually need to look at the Firefox or Chromium code in order to answer my questions.

Did any of your past experiences contributing code to Firefox help you create and land the WebExtensions APIs?

Yes. Despite being unfamiliar with WebExtensions APIs at first, I had a considerable experience with searching code using Searchfox, using ‘./mach build fast’ to recompile only the frontend, running tests, managing my patches with Mercurial, and getting them reviewed and landed.

Also, I already had commit access level 1, which allows me to run tests in the try servers. That’s helpful for ensuring everything works on Android.

What advice would you give people who want to build and land WebExtensions APIs in Firefox?

1. I didn’t find explanations for how the code is organized, so I would first summarize it.

The code is mainly distributed into three different folders:

/browser/components/extensions/:

/mobile/android/components/extensions/

/toolkit/components/extensions/

The ‘browser’ folder contains the code specific to Firefox desktop, the ‘android’ is specific to Firefox for Android, and ‘toolkit’ contains code shared for both.

Some APIs are defined directly in ‘toolkit’, and some are defined differently in ‘browser’ and ‘android’ but they can still share some code from ‘tookit’.

2. APIs are defined using JSON schemas. They are located in the ‘schemas’ subdirectory of the folders above, and describe the API properties and methods, determine which kind of parameters are accepted, etc.

3. The actual logic of the APIs is written in JavaScript files in the ‘parent’ and ‘child’ subdirectories, mostly the former.

Is there anything else you would like to add?

The existing Webextension APIs are now more mature, useful and reliable than they were when support for legacy extensions was dropped. It’s great that promising new APIs are on the way!

Thanks, Oriol! It is a pleasure to have you in the community and and we wish you all the best in your future endeavors.

If you are interested in contributing to the WebExtensions API and are new to Firefox’s infrastructure, we recommend that you onboard to the Firefox codebase and then land a patch for a good-first-bug. If you are more familiar with Firefox infrastructure, you may want to implement one of the approved WebExtensions API requests.

For more opportunities to contribute to the add-ons ecosystem, please visit our Contribution wiki.