Using Google Analytics in Extensions

As an add-on developer, you may want to have usage reporting integrated into your add-on. This allows you to understand how your users are using the add-on in real life, which can often lead to important insights and code updates that improve user experience.

The most popular way to do this is to inject the Google Analytics script into your codebase as if it were a web page. However, this is incompatible with our review policies. Injecting remote scripts into privileged code – or even content – is very dangerous and it’s not allowed. Fortunately, there are ways to send reports to Google Analytics without resorting to remote script injection, and they are very easy to implement.

I created a branch of one of my add-ons to serve as a demo. The add-on is a WebExtension that injects a content script into some AMO pages to add links that are useful to admins and reviewers. The diff for the branch shouldn’t take much time to read and understand. It mostly comes down to this XHR:

let request = new XMLHttpRequest();
let message =
  "v=1&tid=" + GA_TRACKING_ID + "&cid= " + GA_CLIENT_ID + "&aip=1" +
  "&ds=add-on&t=event&ec=AAA&ea=" + aType;

request.open("POST", "https://www.google-analytics.com/collect", true);
request.send(message);

In my demo I do everything from the content script code. For add-ons with a more complex structure, you should set up a background script that does the reporting and have content scripts send messages to it if needed.

I set up my reporting so the hits are sent as events. You can read about reporting types and all the different parameters in the Google Analytics developer docs.

Thanks to the real-time tracking feature I could see that my implementation was working right away:

live-tracking

That’s it! With just a few lines of code you can set up Google Analytics for your add-on safely, in a way that meets our review guidelines.

Add-ons Update – Week of 2016/05/11

Firefox

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

In the past 3 weeks, 1387 listed add-ons were reviewed:

  • 1314 (95%) were reviewed in fewer than 5 days.
  • 40 (3%) were reviewed between 5 and 10 days.
  • 33 (2%) were reviewed after more than 10 days.

There are 67 listed add-ons awaiting review.

You can read about the recent improvements in the review queues here.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Compatibility Communications

Most of you should have received an email from us about the future compatibility of your add-ons. You can use the compatibility tool to enter your add-on ID and get some info on what we think is the best path forward for your add-on. This tool only works for listed add-ons.

To ensure long-term compatibility, we suggest you start looking into WebExtensions, or use the Add-ons SDK and try to stick to the high-level APIs. There are many XUL add-ons that require APIs that aren’t available in either of these options, which is why we ran a survey so we know which APIs we should look into adding to WebExtensions. You can read about the survey results here.

We’re holding regular office hours for Multiprocess Firefox compatibility, to help you work on your add-ons, so please drop in on Tuesdays and chat with us!

Firefox 47 Compatibility

The compatibility blog post for 47 is up and the bulk validation has been run.

Firefox 48 Compatibility

The compatibility blog post for Firefox 48 is coming up soon.

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.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to remove the signing override preference in Firefox 47.

The preference was actually removed recently in the beta channel (future Firefox 47), though this was done before the unbranded builds were available for testing. We’re trying to get those builds out as soon as possible to avoid more disruption. For now I suggest you use Developer Edition for testing or, if your add-on is restartless, you can also use the temporary load option.

Add-ons Update – Week of 2016/04/20

Firefox

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

In the past 3 weeks, 1226 listed add-ons were reviewed:

  • 1160 (95%) were reviewed in fewer than 5 days.
  • 45 (4%) were reviewed between 5 and 10 days.
  • 21 (1%) were reviewed after more than 10 days.

There are 73 listed add-ons awaiting review.

You can read about the recent improvements in the review queues here.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Compatibility Communications

Most of you should have received an email from us about the future compatibility of your add-ons. You can use the compatibility tool to enter your add-on ID and get some info on what we think is the best path forward for your add-on.

To ensure long-term compatibility, we suggest you start looking into WebExtensions, or use the Add-ons SDK and try to stick to the high-level APIs. There are many XUL add-ons that require APIs that aren’t available in either of these options, which is why we’re also asking you to fill out this survey, so we know which APIs we should look into adding to WebExtensions.

We’re holding regular office hours for Multiprocess Firefox compatibility, to help you work on your add-ons, so please drop in on Tuesdays and chat with us!

Firefox 47 Compatibility

The compatibility blog post for 47 is up. The bulk validation will be run soon. Make sure that the compatibility metadata for your add-on is up to date, so you don’t miss these checks.

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.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to remove the signing override preference in Firefox 47 (updated from 46).

Improving Review Time by Providing Links to Third Party Sources

Firefox

Earlier I wrote an article about submitting add-ons with sources attached, which is primarily needed for obfuscated or minified add-ons. I only briefly mentioned the specific cases where attaching sources is in fact NOT recommended. If you’ve determined you do not need to upload sources but you still want to profit from blazing fast review speeds, please read on.

To reiterate, you do not need to upload source code if your add-on only contains (minified) third-party libraries, or if the libraries you are calling via js-ctypes are system libraries or open source. What you need to do instead is provide links to the exact file versions in the repositories of the respective libraries. You should add these links in the “Notes to Reviewers” section when viewing or uploading your new version.

Just as with your add-on code, we review third-party library code for potential issues. When we notice a library is used more often, we can add the (sha256) checksum to a list of known libraries that are specially marked in the editor tools. Reviewers do not need to review this library again, which saves a lot of time.

The downside to using checksums is that the file must match exactly, down to the byte. A common issue we encounter is libraries being retrieved from non-official sites, for example CDNs. These sites may make slight changes, often something simple like white spaces, or adding/removing a source map URL. Similarly, some developers copy/paste the libraries into a text editor, which may result in different line endings.

Now to the important part: how to specify the repository links. You don’t need to do this for the common libraries mentioned in our list (currently: angular, backbone, backbone.localStorage, crypto.js, dojo, jquery, jqueryui, moment, mootools, prototype.js, scriptaculous, swfobject.js, underscore, yui). For all other libraries, we need the link to an exact copy of the file you have submitted, from the official website or repository. Here is an example:

Let’s say you are using the minified version of mousetrap version 1.4.2 because you haven’t had the chance to update to the latest version.

If the library is on github, you can usually find this version under the “releases” link, then clicking on the small tag icon next to the version number, then navigating to the file in the repository. For bonus points, if you are using the minifed version, also provide a link to the unminifed version beside it. If the library does not use github releases but instead just gives you a zip to download, provide the link to the zip instead.

Mentioning the links upfront will shorten the review time since we can check the library right away instead of asking you about it, making reviews faster. Leave a comment if you have any questions!