“Build Your Own WebExtension Add-on” Campaigns Around the World

We recently partnered with the Mozilla Open Innovation team to launch an activity that would introduce developers to WebExtensions and guide them through the experience of creating new add-ons with the APIs. The “Build Your Own WebExtension Add-on For Firefox” activity launched in February as part of Mozilla’s Activate campaign to mobilize Mozillians around the world to have impact in key areas of the organization’s mission. This activity will run until the end of 2017.

Mozilla communities in Tamilnadu, Switzerland, and Brazil answered the call-to-action and recently hosted events using the Activate curriculum. To date, 54 people have attended these events, and participants have submitted seven new add-ons to addons.mozilla.org. (If you are curious to see what they have built, take a look at this this collection on AMO.)

If you’re interested in hosting an event, read on to find out how our communities have organized their events, and what they would recommend for best practices!

Tamilnadu

Viswaprasanth Ks has been a passionate member of the add-ons community since he started contributing to Mozilla in 2012. He recently led an add-ons track at the Tamilnadu community’s 24 Hour Hackathon, where 25 participants brainstormed and created their own extensions to solve real-world problems.

What we learned

Encourage participants to learn JavaScript and have them start learning extension development from the mdn-web extension repo, recommends Viswaprasanth. Those with less familiarity with HTML and JavaScript might need additional support to complete the activity. Plus, the examples listed in the mdn-web extension repo have been carefully evaluated as being good starting places for beginning developers.

Picture of participants at 24 Hour Hackathon

Photo by Viswaprasanth Ks

Switzerland

Michael Kohler slated this activity for one of Mozilla Switzerland’s monthly meet-ups and tapped long-time add-ons contributor Martin Giger to mentor a group of 10 participants. Attendees found the workshop to be a relaxing introduction to extension development and left the event feeling empowered and confident in their abilities to create add-ons using WebExtensions APIs.

What we learned

Anticipate that it will take 90 minutes to complete Part I of the curriculum. “We used around 90 minutes to get to a working first example, including the intro,” Michael reports. If you are only able to complete Part I during an event, consider scheduling a follow-up event where participants can continue creating extensions in a fun, supportive atmosphere.

Martin Giger speaks at Mozilla Switzerland meet up

Photo by Michael Kohler

Brazil

What can 22 Brazilians and 30 liters of beer accomplish in one day? Quite a bit, according to Andre Garzia’s blog post about his recent event. After a discussion about extension development and a group brainstorming session, participants organized themselves into small groups and worked on ten add-ons.

What we learned

Provide some starter ideas to those who want to go beyond the initial tutorial and build their own original add-on. Andre writes in his post, “We knew from the start that telling people to come out with add-on ideas out of the blue would not be an effective way to engage everybody. People have different ways to come up with ideas and some don’t enjoy coming up with an idea on the spot like this. To help people out, we made a clothesline where we hung add-on ideas up. Each idea had a description, suggested APIs to use and a difficulty/complexity rate. Attendees were encouraged to browse our hanging ideas and take one to implement if they felt like it.”

Note: if you need help developing a list of starter ideas, take a look at this list of requests from users on Discourse.

Printed ideas for add-ons on a clothesline

Photo by Andre Garzia

Have you conducted an add-ons development workshop for your community or are you interested in hosting one? Tell us about it on Discourse!

The add-ons team would like to extend a hearty thank you to Viswaprasanth Ks and Daniele Scasciafratte for providing input and tutorials for the “Build Your Own WebExtension Add-on” activity, and to Michael Kohler, Viswaprasanth Ks, and Andrew Garzia for coordinating these events.

Migrating ColorZilla to WebExtensions

ColorZilla lets you get a color reading from any point in your browser, quickly make adjustments to it, and paste it into another program. It also generates gradients and more, making it an indispensable add-on for designers and artists.

For more resources on updating your extension, please check out MDN. You can also contact us via these methods.

Can you provide a short background on your add-on? What does it do, when was it created, and why was it created?

ColorZilla is one of the earliest Firefox add-ons—in fact, it’s the 271st Firefox add-on ever created (currently there are over 18,000 add-ons available on AMO). The first version was released almost 13 years ago in September 2004. ColorZilla was created to help designers and web developers with color-related tasks—it had the first-ever browser-based eyedropper, which allowed picking colors from any location in the browser and included a sophisticated Photoshop-like color-picker that could perform various color manipulations. Over the years the add-on gained recognition with millions of users, won awards and was updated with many advanced features, such as DOM color analyzers, gradient editors etc.

What add-on technologies or APIs were used to build your add-on?

Because the core of the ColorZilla codebase was written in the very early days, it used fairly low-level APIs and services.

Initially, ColorZilla relied on native XPCOM components for color sampling from the browser window. The first release included a Windows XPCOM module with a following release adding native XPCOM modules for MacOSX and Linux. After a few years, when new APIs became available, the native XPCOM part was eliminated and replaced with a Canvas JavaScript-based solution that didn’t require any platform-specific modules.

Beyond color sampling, ColorZilla used low-level Firefox XPCOM services for file system access (to save color palettes etc), preferences, extension management etc. It also accessed the browser content DOM directly in order to analyze DOM colors etc.

Why did you decide to transition your add-on to WebExtensions APIs?

There were two major reasons. The first reason was Firefox moving from single process to Electrolysis (e10s). With add-ons no longer able to directly access web content, it would have required refactoring large portions of the ColorZilla code base. In addition, as ColorZilla for Chrome was released in 2012, it meant that there was a need to maintain two completely separate code bases, and to implement new features and capabilities for both. Using WebExtensions allowed seamless supporting of e10s and code-sharing with ColorZilla for Chrome, minimizing the amount of overhead and maintenance and maximizing the efforts that could be invested in innovation and new capabilities.

Walk us through the process of how you made the transition. How was the experience of finding WebExtensions APIs to replace legacy APIs? What are some advantages and limitations?

Because ColorZilla for Chrome was already available on the market for about 5 years and because WebExtensions are largely based on Chrome extension APIs, the most natural path was to back-port the Chrome version to Firefox instead of porting the legacy Firefox extension code base to WebExtensions.

The first step of that process was to bring all the WebExtensions APIs used in the code to their latest versions, as ColorZilla for Chrome was using some older or deprecated Chrome APIs and Firefox implementation of WebExtensions is based on the latest APIs and doesn’t include the older versions. One such example is updating older chrome.extension.onRequest API to browser.runtime.onMessage.

The next step was to make all the places that hard-coded Chrome—in UI, URLs, etc—to be flexible and detect the current browser. The final step was to bridge various gaps in implementation or semantics between Chrome and Firefox—for example, it’s not possible to programmatically copy to clipboard from background scripts in Firefox. Another example is the browser.extension.isAllowedFileSchemeAccess API that has a slightly different semantic—meaning in Chrome, the script cannot access local files, and in Firefox, it cannot open them, but can still access them.

WebExtensions, as both a high-level and multi-browser set of APIs, has some limitations. One example that affected ColorZilla is that the main add-on button allows only one action. So the “browser action” cannot have a main button action and a drop-down containing a menu with more options (also known as a “menu-button” in the pre-WebExtensions world). With only one action available when users click on the main button, there was a need to come up with creative UI solutions to combine showing a menu of available options with auto-starting the color sampling. This allowed users to click on the web content and get a color reading immediately. This and other limitations require add-on developers to often not just port their add-ons to new APIs, but re-think the UI and functionality of their add-ons.

The huge advantages of the final WebExtensions-based ColorZilla is that it’s both future-proof, supporting new and future versions of Firefox, and multi-browser, supporting Chrome, Edge and other browsers with a single code base.

Note: This bug is meant to expand the capability of menu-buttons in the browserAction API.

What, if anything, is different about your add-on now that it is a WebExtension? Were you able to transition with all the features intact?

The majority of the functionality was successfully transitioned. The UI/UX of the add-on is somewhat different and some users did need to adjust to that, but all the top features (and more!) are there in the new WebExtensions version.

What advice would you give other legacy add-on developers?

First, I suggest going over the WebExtensions API and capabilities and doing a feasibility analysis of whether the legacy add-on functionality can be supported with WebExtensions. Some legacy add-ons leverage low-level APIs and access or modify Firefox in a very deep or unique way, which wouldn’t be possible with WebExtensions. Then, if the functionality can be supported, I suggest mapping the UI/UX of the legacy add-on to the new sets of WebExtensions requirements and paradigms—browser actions, popup windows etc. Following implementation, I suggest extensive testing across different platforms and configurations—depending on the complexity of the add-on, the porting process can introduce a range of issues and quirks. Finally, once the new WebExtensions-based version is released, my advice is to be ready to listen to user feedback and bug reports and quickly release new versions and address issues, to minimize the window of instability for users.

Anything else you’d like to add?

One advice for Mozilla is to better support developers’ and users’ transition to WebExtensions—the process is quite effort-intensive for developers, and user-facing issues, quirks and instabilities that might be introduced due to these changes might be frustrating for both add-on authors and their users. One thing Mozilla could improve, beyond supporting the developer community, is to really shorten the add-on review times and work with developers to shorten the cycle between user bug reports, developer fixes and the release of these fixes to the users. This will really minimize the window of instability for users and make the entire process of moving the Firefox add-on ecosystem to WebExtensions so much smoother. My advice for add-on authors on this front is to engage with the AMO editors, understand the review process and work together to make the review process as fast and smooth possible.

April’s Featured Add-ons

Firefox Logo on blue background

Pick of the Month: Bulk Media Downloader

by InBasic
Manage large media downloads—audio, images, and video—with this lightweight tool.

“Very useful.”

Featured: Desktop Messenger for Telegram™

by Elen Norphen
Put Telegram right in your toolbar.

“Easy to locate groups, delete messages, and know everything stays secures. Keep up the good work!!!.”

Featured: Google™ Keep

by Philip Tholus, Morni Colhker
Have a notepad with you at all times.

“We have this proxy security stuff at work, and I can’t connect to Google Keep at work. No extensions worked in Chrome, and only one extension worked with FireFox. This way firefox became my default browser. Thank you.”

Featured: Font Finder (revived)

by Andy Portmen
Instantly analyze any font you find on the internet. This is a great tool for designers and developers.

“With one click, an entire paragraph’s font family, color (both hex and RGB), spacing, transformation, and element details are shown. “

Nominate your favorite add-ons

Featured add-ons are selected by a community board made up of add-on developers, users, and fans. Board members change every six months. Here’s further information on AMO’s featured content policies.

If you’d like to nominate an add-on for featuring, please send it to amo-featured [at] mozilla [dot] org for the board’s consideration. We welcome you to submit your own add-on!

Friend of Add-ons: Prasanth

Please meet our newest Friend of Add-ons, Prasanth! Prasanth became a Mozillian in 2015 when he joined the Mozilla TamilNadu community and became a Firefox Student Ambassador. Over the last two years, he has contributed to a variety of projects at Mozilla with great enthusiasm. Last year, he organized a group of eleven participants to test featured add-ons for e10s compatibility.

In January, Prasanth became a member of the Add-ons Advisory Board, and has emerged as someone very adept at finding great add-ons to feature. “Prasanth has shown a true talent for identifying great add-ons,” comments Scott DeVaney, Editorial & Campaign Manager for the add-ons team.

In addition to organizing community events and contributing to the Advisory Board, Prasanth is also learning how to write scripts for testing automation and helping contributors participate in QA bugdays.

Of his experience as a contributor at Mozilla, Prasanth says,

“Contributing in an open source community like Mozilla gave me the opportunity to know many great contributors and get their help in developing my skills. It showed me a way to rediscover myself as a person who loves open source philosophy and practices.”

In his spare time, Prasanth enjoys hanging out with friends and watching serials like The Flash and Green Arrow.

Congratulations, Prasanth, and thank you for your contributions to the add-ons community!

Are you a contributor to the add-ons community or know of someone who should be recognized? Please be sure to add them to our Recognition Wiki!

Update on Compatibility Milestones

The Road to Firefox 57 has been updated with a couple of changes to the timeline:

  • Firefox won’t run in multiprocess mode unless all enabled add-ons have the multiprocessCompatible flag set to true or are WebExtensions. This means that developers who haven’t set this flag don’t have to worry about multiprocess compatibility and can focus on WebExtensions and the Firefox 57 deadline.
  • The multiprocess compatibility shims will be removed earlier, starting with the Nightly and Developer Edition channels. Their purpose was to ease the transition to multiprocess compatibility, but given the change in the previous point, they aren’t really needed anymore. Removing them will help track performance issues.

None of these changes should require any immediate action from developers, but let us know if you have any questions or concerns.

Migrating AdBlock for Firefox to WebExtensions

AdBlock for Firefox is a fast and powerful ad blocker with over 40 million users. They are in the process of transitioning to WebExtensions, and have completed the first step of porting their data using Embedded WebExtensions. You can read more about the AdBlock extension here.

For more resources on updating your extension, please check out MDN. You can also contact us via these methods.

  1. Please provide a short background on your add-on. What does it do, when was it created, and why was it created?

    We created our original Firefox extension in 2014. We had seen some early success on Chrome and Safari and believed we could replicate that success on Firefox, which had developed a good community of users that downloaded add-ons for Firefox. It seemed like a natural place for us to be.

  1. What add-on technologies or APIs were used to build your add-on?

    The Firefox Add-On SDK was being promoted at the time, which wasn’t compatible with the Chrome Extension API, so we went through the Chrome code to identify areas where we could leverage work we had done previously. Since the APIs were a little different, we ended up having to modify some modules to use the Firefox Add-on SDK.

  1. Why did you decide to transition your add-on to WebExtensions APIs?

    With the Firefox SDK set to be deprecated, we knew our extension would slowly become unusable, so it made sense to transition to the WebExtension API. The benefit, from our standpoint, was that by using this API our software would be on a similar codebase and have similar features and functionalities to what we do on some of the other browsers we support.

  2. Walk us through the process of how you are making the transition. How was the experience of finding WebExtensions APIs to replace legacy APIs? What are some advantages and limitations?

    Last year we ported our Chrome extension to Edge, so when Firefox announced its plans, we had a good idea of what we wanted to do and how to go about it. Also, we were familiar with the WebExtension API from our years working on Chrome, but we knew we needed to educate ourselves on the differences. Fortunately, the Firefox documentation on the difference was very helpful in that education process. These pages, in particular, were helpful:

    https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Comparison_with_the_Add-on_SDK

    https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities

    We did run into a few challenges. Chrome allows us to create an alert message or a confirm message from the background page (e.g., “Are you sure you want do this…”), and Firefox doesn’t allow us to do that. We use that type of messaging in our Chrome extension that we had to find a workaround for, which we were able to do. For us, this impacted our ability to message our users when they were manipulating custom filters within AdBlock, but was not a major issue.

    We hope to land Permission capabilities in Firefox 54, and you can read about its implementation progress in the WebExtensions in Firefox 53 blog post.

  1. What, if anything, will be different about your add-on when it becomes a WebExtension? Will you be able to transition with all the features intact?

    Anecdotally, the extension appears to be faster, specifically around page load times. But the big advantage, from our perspective, is that we will be able to manage the transition with almost all of our features intact. As a result, we aren’t losing any meaningful functionality of AdBlock, which was our main concern before we embarked upon this transition.

    We did notice that a few of the APIs that AdBlock utilizes are not available on Firefox for Android, so we are currently unable to release a new version of AdBlock that supports Firefox for Android. We hope to address this issue in a coming version of AdBlock.

    We have lots of work planned for Android in upcoming releases, with the goal of making ad blockers possible in Firefox 57.

  1. What advice would you give other legacy add-on developers?

    Make sure you have a migration plan that is well-tested on various versions and operating systems before you start migrating user data. One thing we learned the hard way, when we migrated our users’ data, we generated some migration messages to the console, but those message were not persisted.  It would have been more helpful to use if the messages were persisted for a period of time, to aid with debugging any user issues.

    Embedded Extensions are available as of Firefox 51 to help you transfer your user data.

  1. Anything else you’d like to add?

    If you are going to upgrade your extension, only do what’s necessary to get the current functionality working first. Don’t try and do too much in the release that you are using to migrate users over.

Privacy Features, Tab Tools & Other New WebExtensions

Tabzen is great for tab hoarders.

As of late March, addons.mozilla.org (AMO) has around 2,000 listed add-ons built with WebExtensions APIs, the new cross-browser standard for writing add-ons. Average daily installs for them total more than 5,000,000. That’s nice momentum as we hurtle towards the Firefox 57 release.

Volume aside, I continue to be impressed with the quality of content emerging…

Smart HTTPS (revived) is the WebExtensions version of one of my favorite yet simple security add-ons—it changes HTTP addresses to the secure HTTPS. Disconnect for Facebook (WebExtension) is another fine privacy tool that prevents Facebook from tracking your Web movement by blocking all Facebook related requests sent between third-party sites.

While we’re talking Facebook, you know what annoys me? Facebook’s “suggested posts” (for some reason I get served a lot of “suggested” content that implies I may have a fatty liver). Kick Facebook Suggested Posts puts an end to that nonsense.

History Cleaner conveniently wipes away your browsing history after a set amount of time, while History Zebra features white and black lists to manage specific sites you want to appear (or not) in your browsing history.

Tab Auto Refresh lets you set timed refresh intervals per tab.

Don’t Touch My Tabs! protects against hyperlinks that try to hijack your previous tab. In other words, when you typically click a link, it grants the new page control over the one you clicked from, which is maybe not-so awesome for a number of reasons, like reloading the page with intrusive ads, or hackers throwing up a fake login to phish your info.

Speaking of tabs, I dig Tab Auto Refresh because I follow a couple of breaking news sites, so with this add-on I set certain tabs to refresh at specific time intervals, then I just click over every so often to catch the latest.

Tabzen is another dynamic tab tool that treats tab management in a familiar bookmarking fashion.

Turn any Reddit page into literally the darkest corner of the Web with dark page themer Reddit Slate Night 2.0 (while we’re on the Reddit tip, this comment collapser presents a compelling alternate layout for perusing conversations).

Dark Mode turns the entire internet goth.

Link Cleaner removes extraneous guck from your URLs, including tracking parameters from commerce sites Amazon and AliExpress.

These are awesome add-ons from very creative developers! It’s great to see such diverse, interesting WebExtensions crop up.

If you’re a developer of a legacy add-on or Chrome extension and want more info about the WebExtensions porting process, this should help. Or if you’re interested in writing a WebExtension from scratch, check this out.

Migrating to WebExtensions? Don’t Forget Your Users

Stranded users feel sadness.

If you’re the developer of a legacy add-on with an aim to migrate to WebExtensions, here are a few tips to consider so your users aren’t left behind.

Port your user data

If your legacy add-on stores user data, we encourage you to take advantage of Embedded WebExtensions to transfer the data to a format that can be used by WebExtensions. This is critical if you want to seamlessly migrate your users—without putting any actionable burden on them—to the new WebExtensions version when it’s ready. (Embedded WebExtensions is a framework that contains your WebExtension inside of a bootstrapped or SDK extension.)

Testing beta versions

If you want to test a WebExtensions version of your add-on with a smaller group of users, you can make use of the beta versions feature on addons.mozilla.org (AMO). This lets you test pre-release beta versions that are signed and available to Firefox users who want to give them a spin. You’ll benefit from real users interacting with your new version and providing valuable feedback—without sacrificing the good reputation and rating of your listed version. We don’t recommend creating a separate listing on release because this will fragment your user base and leave a large number of them behind when Firefox 57 is released.

Don’t leave your users behind

Updating your listing on AMO when your WebExtension is ready is the only way to ensure all of your users move over without any noticeable interruption.

Need further assistance with your migration journey? You can find real-time help during office hours, or by emailing webextensions-support [@] mozilla [dot] org.

Add-ons Update – 2017/03

Here’s the state of the add-ons world this month.

The Road to Firefox 57 explains what developers should look forward to in regards to add-on compatibility for the rest of the year. Please give it a read if you haven’t already.

The Review Queues

In the past month, 1,414 listed add-on submissions were reviewed:

  • 1132 (80%) were reviewed in fewer than 5 days.
  • 31 (2%) were reviewed between 5 and 10 days.
  • 251 (18%) were reviewed after more than 10 days.

There are 594 listed add-ons awaiting review.

We met last week to discuss the state of the queues and our plans to reduce waiting times. There are already some changes coming in the next month or so that should help significantly, but we have larger plans that we will share soon that should address this recurring problem permanently.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Add-on reviewers are critical for our success, and can earn cool gear for their work. Visit our wiki page for more information.

Compatibility

The blog post for 53 is up and the bulk validation will be run soon. Firefox 54 is coming up.

Multiprocess Firefox is enabled for some users, and will be deployed for most users very soon. Make sure you’ve tested your add-on and either use WebExtensions or set the multiprocess compatible flag in your add-on manifest.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Recognition

We would like to thank the following people for their recent contributions to the add-ons world:

  • Piotr Drąg
  • Niharika Khanna
  • saintsebastian
  • Atique Ahmed Ziad
  • gilbertginsberg
  • felixgirault
  • StandB
  • lavish205
  • numrut
  • fitojb
  • totaki
  • ingoe

You can read more about their work in our recognition page.

WebExtensions in Firefox 54

Firefox 54 landed in Developer Edition this week, so we have another update on WebExtensions for you. In addition to new APIs to help more developers port over to WebExtensions, we also announced a new Office Hours Support schedule where developers can get more personalized help with the transition.

New APIs

A new API for creating sidebars was implemented. This allows you to place a local HTML file inside the sidebar. The API is similar to the one in Opera. If you specify the sidebar_action manifest key, Firefox will create a sidebar:

To allow keyboard commands to be sent to the sidebar, a new _execute_sidebar_action was added to the commands API which allows you trigger the showing of the sidebar.

The ability to override the about:newtab with pages inside your extension was added to the chrome_url_overrides field in the manifest. Check out the example that uses the topSites API to show the top sites you visit .

The privacy API gives you the ability to flip certain Firefox preferences related to privacy. Although the preferences in Chrome and Firefox aren’t a direct mapping, we’ve mapped the Firefox preferences that makes sense to the APIs. Currently implemented are: networkPredictionEnabled, webRTCIPHandlingPolicy and hyperlinkAuditingEnabled.

The protocol_handler API lets you easily map protocols to actions in your extension. For example: we use irccloud at Mozilla, so we can map ircs:// links to irccloud by adding this into an extension:

  "protocol_handlers": [
    {
      "protocol": "ircs",
      "name": "IRC Mozilla Extension",
      "uriTemplate": "https://irccloud.mozilla.com/#!/%s"
    }
  ]

When a user clicks on an IRC link, it shows the application selector with the IRC Mozilla Extension visible:

This release also marks the landing of the first sets of devtools APIs. Quite a few APIs landed including: inspectedWindow.reload(), inspectedWindow.eval(), inspectedWindow.tabId, network.onNavigated, and panels.create().

Here’s an example of the Redux DevTools extension running on Firefox:

Backwards incompatible changes

The webRequest API will now require that you’ve requested the appropriate hosts’ permissions before allowing you to perform webRequest operations on a URL. This will be a backwards-incompatible change for any extension which used webRequest but did not request the host permission.

Deletes in storage.sync are now encrypted. This would be a breaking change for any extensions using storage.sync on Developer Edition.

API Changes

Some key events were completed in some popular APIs:

  • webRequest.onBeforeRequest is initiated before a server side redirect is about occur and webRequest.onAuthRequired is fired when an authentication failure occurs. These allow you to catch authentication requests from servers, such as proxy authentication.
  • webNavigation.onCreatedNavigationTarget event has been completed. This is fired when a new window or tab is created to be navigated to.
  • runtime.onMessageExternal event has been implemented. This is fired when a message is sent from another extension.

Other notable bugs include:

Android

Notably in Firefox 54, basic tabs API support was landed for Android. The API support focuses on the parts of the API that make sense for Android, so some tab methods and events are deliberately not implemented.

This is an important API in its own right, but other key APIs did not have good support without this. By landing this, Android WebExtensions got much better webNavigation and webRequest support. This gives us a clear path to getting ad blockers, the most common extension type on Android.

Contributors

A big thank you to our contributors Rob Wu, Tomislav Jovanovic and Tushar Saini who helped out with this release.