Add-ons Update – 2017/04

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

The Road to Firefox 57 (recently updated) 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,209 listed add-on submissions were reviewed:

  • 984 (81%) were reviewed in fewer than 5 days.
  • 31 (3%) were reviewed between 5 and 10 days.
  • 194 (16%) were reviewed after more than 10 days.

There are 821 listed add-ons awaiting review.

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 was run. Here’s the post for Firefox 54 and the bulk validation is pending.

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 to make sure that they continue to work correctly. You may also want  to review the post about upcoming changes to the Developer Edition channel.

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:

  • bkzhang
  • Aayush Sanghavi
  • saintsebastian
  • Thomas Wisniewski
  • Michael Kohler
  • Martin Giger
  • Andre Garzia
  • jxpx777
  • wildsky

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

Apply to Join the AMO Feature Board

Help people discover add-ons that make this browser do glorious things.

Do you have an eye for awesome add-ons? Can you distinguish a decent ad blocker from a stellar one? Interested in making a huge impact for millions of Firefox users? If so, please consider applying to join AMO’s Feature Board.

The board is comprised of a small group of community contributors who help select each month’s new featured add-ons. Every board serves for six months, then a new group of community curators take over. Now the time has come to assemble a new group of talented contributors.

Anyone from the add-ons community is welcome to apply: power users, theme designers, developers, and evangelists. Priority will be given to applicants who have not served on the board before, followed by those from previous boards, and finally from the outgoing board.

This page provides more information on the duties of a board member. To be considered, please email us at amo-featured [at] mozilla [dot] org and tell us how you’re involved with AMO and why you think you’d make a strong content curator. The deadline for applications is Friday, April 28, 2017 at 23:59 PDT. The new board will be announced shortly thereafter.

We look forward to hearing from you!

AMO Has a New Look on Android

The mobile version of addons.mozilla.org (AMO) recently debuted a new appearance. It’s not a complete redesign, but rather the start of an iterative process that will take months to fully transform AMO for mobile. The new look is also a preview of what’s to come for desktop AMO. Once the mobile design elements mature, we’ll apply the same concepts to desktop, likely sometime later this year.

“Parity between the two platforms is a high priority,” says Sr. Visual Designer Philip Walmsley. “We’re using mobile to test and learn what works, and uplifting that into the desktop designs. And anything new we discover along the way on desktop will be designed back into mobile, as well.”

Our main goal was to make browsing add-ons more intuitive and effortless. To that end, the new design presents content in a cleaner, more streamlined manner. There are fewer buttons to tap, but the ones that remain are bold and clear.

Illustrated in the images above, the homepage displays a subset of categories represented primarily though iconography… The density of information on an add-on detail page is more balanced now, with only essential information in clear view… and theme previews are bigger and screenshots more prominent.

There’s a bit more color, too. In general much of the aesthetic was in need of a modernizing overhaul. These recent changes are just the start. Plenty more to come. If you’re exploring the new AMO on your Android device and spot a bug, please feel free to let us know about it.

Add-on Compatibility for Firefox 54

If you haven’t yet, please read our roadmap to Firefox 57.

Firefox 54 will be released on June 13th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 54 for Developers, so you should also give it a look.

General

  • Remove -moz-appearance. This doesn’t apply to CSS sheets loaded using a chrome:// URL, but it does affect inline CSS styles in XUL and JavaScript code.

XPCOM and Modules

WebExtensions

Let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 54, I’d like to know.

The automatic compatibility validation and upgrade for add-ons on AMO will happen in a few weeks, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 53.

“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.