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.

1 response

  1. That Random Guy wrote on :

    This is not enough. You need to find a way to allow functionality that’s similar to CTR. Saying, “that’s not possible anymore” is not sufficient or acceptable at this point. You can’t completely abandon a model and framework without allowing for these set functions and capabilities to be tweaked with either natively or through some other venue. Allowing for users to tweak with the interface in terms of customization is a grand achievement and should be considered a priority. Maybe the devs aren’t well-versed in this as others are, but UI design plays a grand role in overall usability and efficiency of use. The default [now] Australis UI is probably the WORST UI in history. The only reason it’s been adopted, and you deny all you want, is because Google implemented it in Chrome. Making the tabs farther from where the user will already be focused is not practical from a usability perspective. Nor is it efficient. Rendering the back-and-forward buttons as a single object while making one smaller than the other is also inefficient. Why should the user be forced to be more accurate when trying to hit a target? The button should be symmetrical in size to be consistent and to allow for an easier travel path. Why should the location bar’s drop down list span the entire screen? It used to be more efficient when the user only had to scan a couple of mm to read the hyper link. Now, you’re forcing them to go all the way to the end of the window just to read a URL? Again, the only reason Firefox even implemented this was to copy Chrome, yet again. What’s sad is that you presume to be aware of these common/relevant design principles and yet you don’t fully implement it in the entire UI concept. For example, they recently made a change to the Downloads window when clicking on the associated icon on the toolbar. The window is now partitioned, making the user have to do less and have to think less. It used to be that the “open in file location” button was a simple circled hot spot. The problem with this is that it required the user to be more accurate in where they hit the target. That’s a usability no-no. In contrast, now the actual function has a better defined space block for the user to more easily click on. Just from that, we can ASSUME that the developers are aware of good design practice, but they don’t implement it the way they should. You’re continuously coming out with excuses with regard to UI tweaking with web-extensions and it’s getting old. Forcing a lackluster and counterproductive UI does not aid the user in anything. You make the experience WORSE by trying to force a PRESUMED aesthetic improvement/style. Google Chrome has the WORST interface in any browser that I’ve seen yet. Firefox has obviously continuously tried to copy their competitors to gain an edge in the “market”. The problem with this is that Chrome is the WORST entity to obtain influence from. I’ve already described so as to why this is so. Even your developers have to ADMIT that the default design is lacking. It’s by no means productive. Applying a “minimal design” to give the user the IMPRESSION that the UI looks better than it is, is RIDICULOUS. You’re just giving them the PERCEPTION that their experience is better than what it is. Your browser lacks definitive USABILITY because you choose to continuously SELL OUT and not make AMENDS to your errors. You think that because you got it to work once, just because Google did it, that all of the sudden that makes it hunky-dory. Well , it’s not. As a person with visual disabilities, I find your attention to detail IN THIS REGARD to be severely DISAPPOINTING. There is NOTHING you can say to change my mind about the default interface. Less isn’t always better, and that stands true in this case. You need to stop making users have to do more when it comes to something a simple as looking at a drop down list. It may LOOK pretty, but from an ease-of-use stand-point, it’s NOT PRACTICAL. It deters from the main goal, which is READING THE URL. It’s the same with tabs. Why would you ever think putting tabs ON TOP of the location bar as a good idea? Please, tell me, where is it that a user’s cursor is MOST likely to be in any given scenario? I’m willing to bet that it’s ON THE CONTENT OF THE PAGE. NOT THE BROWSER ELEMENTS. Time and time again I’ve watched you try and fix what just simply isn’t broken. I’m tired of the developers trying to “outwit” users with the excuse of a “better” browser. It’s not going to work. From an HCI perspective, from a USABILITY perspective, and from a COMMON SENSE stand point, you’re messing with what shouldn’t be messed with. Nobody told you to tweak around with the location bar. Nobody told you to change the tabs bar position. Nobody told you to change to Australis. Nobody told you to change things that didn’t need changing. The ONLY thing that’s good about Australis is the icons. The icons are flat and simple. They’re easy on the eyes, and relatively minimal. Only in THAT sense, is “minimal” good. Making the interface useless be taking away it’s ease-of-use factor is beyond me. You obviously need to go back to school if you can’t follow through basic and KEY heuristics. You’re supposed to be making browsing easier, not more difficult. Stop changing things that don’t need changing. Web extensions is not bad at face value, but if you start turning on the very things that actually HELP you, then what’s the point of it all? There is nothing stopping you from adding in some basic functionality to what we’re asking. CTR doesn’t even make the browser any slower than it already is. Not only that, but the browser has to load it’s styling somehow. Whether you like it or not, this is a function that’s staying. So, why not give us the option to do what we want if you’re not even going to let people create for it?