Your design, printed on our next t-shirt!

Amy Tsay

4

Screenshot 2015-03-23 16.27.34

Mozillians love their t-shirts. And Firefox users love their add-ons. Add-ons let you completely customize your browser, from the way it looks to the way it behaves. To celebrate the community of add-on developers from all over the world who make this possible, we’re creating limited-edition t-shirts to send as thank-you gifts.

To make this celebration more participatory, we are taking submissions for the design. If you’d like the chance to have your artwork featured on this special shirt, please submit a design!

THEMES

Your design should be an artistic representation of the following themes, so be creative! (Your artwork should not be a reinterpretation or alteration of a Mozilla or Firefox logo, although an original representation of a fox or red panda would be ok.) Branding will be added to the back or arm of the t-shirt by our Creative staff.

  • Personalization — a browsing experience unique to you
  • Openness — anyone can make an add-on and there are thousands to choose from
  • Productivity — be more productive by customizing your browser to help you work better

Here are some resources to help:

REQUIREMENTS

  • Artwork must be submitted in EPS (vector art) format – if file size is over 10MB, please upload to Dropbox and send a link
  • Email your submission, along with your name or alias, to amo-tshirt-contest@mozilla.com

If you have a particular t-shirt color in mind, please include it in your email as well. We can’t guarantee it will be printed on a shirt of that color, but it will help to know what the artist intended. Limit 3 designs per entrant.

DESIGN SELECTION

  • A panel of judges will select three designs, and community voting will decide the final design.
  • The judges will consider:
    • How well the design represents the contest themes
    • Visual appeal
    • Uniqueness
    • Whether the design would look good on a t-shirt
  • The judges are:

IMPORTANT DATES

  • Deadline: submit your design by Thursday, April 30, 2015 at 11:59PM Pacific Standard Time
  • Finalists announcement: the three finalists will be announced on or about May 18, 2015
  • Community vote: community voting will close on or about June 2, 2015
  • Winner announcement: the final design will be announced on or about June 12, 2015, and qualifying add-on developers will be able to start reserving their shirts.
  • T-shirt printing: t-shirts bearing the winning design will begin shipping in July or August 2015.

FINE PRINT

Employees of Mozilla are not eligible to participate.

All designs submitted must be your own work. Do not include artwork or logos belonging to others.

Your designs remain your exclusive property. By submitting a design, you grant Mozilla, and its designees, the right to edit, publish, copy, display, and distribute your design, alone and in combination with other material, without compensation. This includes, but is not limited to, displaying your design on a website for public voting, and reproduction on t-shirts for distribution.

Your designs may not: (i) contain vulgar, offensive, obscene, lewd, or indecent language, behavior or imagery; (ii) defame, libel or otherwise violate the rights of any third party; (iii) violate or facilitate the violation of any federal, state or local laws or ordinances; or (iv) target anyone because of his or her membership in a certain social group, including race, gender, color, religion, belief, sexual orientation, disability, ethnicity, nationality, age, gender identity, or political affiliation, or contain a symbolic representation of any group that targets anyone because of his or her membership in a certain social group. Designs that are, in Mozilla’s sole opinion, inappropriate, objectionable, harmful, inconsistent with our image, or otherwise not in compliance with these rules, may be disqualified, and we may remove any design that has been posted for any of these reasons.

All designs that are uploaded and made available for viewing by the general public will be deemed posted at the direction of the person who submitted the design within the meaning of the Digital Millennium Copyright Act and the Communications Decency Act.

The designs selected by the judges will be posted on a website and the community will be invited to vote for the best design. The design receiving the most votes will be the one that Mozilla uses on the limited edition Add-ons t-shirt. If there is a tie in the community voting, the judges will select the overall winner.

We ask that you not employ any means that is inconsistent with getting an honest picture of the community’s genuine opinion of your design to obtain votes. Examples of inappropriate activities include automated reviews, use of contest services, payoffs or promises to others in exchange for votes.

Any personal information you provide in connection with your participation in this project will be used only for purposes relating to this project, and will not be communicated to third-parties without prior permission or as otherwise specified in our Privacy Policy located at https://www.mozilla.org/en-US/privacy.

You agree to hold harmless Mozilla, its officers, directors, employees, divisions, affiliates, and subsidiaries, from any claim by any third party relating to any intellectual property or other rights in the design you submitted.

Add-ons Update – Week of 2015/03/18

Jorge Villalobos

4

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

  • Most nominations for full review are taking less than 8 weeks to review.
  • 153 nominations in the queue awaiting review.
  • Most updates are being reviewed within 4 weeks.
  • 61 updates in the queue awaiting review.
  • Most preliminary reviews are being reviewed within 6 weeks.
  • 161 preliminary review submissions in the queue awaiting review.

If you’re an add-on developer and would like to see add-ons reviewed faster, 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.

Firefox 37 Compatibility

The Firefox 37 compatibility blog post is up. The automatic AMO validation will be run this week.

Also, if you host your add-ons outside of AMO, give this update a look. It affects the way the domain whitelist for add-on installation works.

Firefox 38 Compatibility

The Firefox 38 compatibility blog post was published yesterday. The automatic AMO validation will be run next month.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition (formerly known as Aurora) 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

We recently announced that we will require extensions to be signed in order for them to continue to work in release and beta versions of Firefox. If you’re an extension developer, please read the post and participate in the discussions. We will be posting a followup shortly, expanding on the reasons behind this initiative.

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running each content tab in a different one. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

We will be talking more about these changes in this blog in the future. For now we recommend you start looking at the available documentation.

Add-on Compatibility for Firefox 38

Jorge Villalobos

3

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

Update: also, make sure you check out this followup on 38 and 38.0.5.

General

XPCOM

New!

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

The automatic compatibility validation and upgrade for add-ons on AMO will probably happen early next month, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 37.

Firefox 37 – Domain whitelisting disabled for non-HTTPS pages

Jorge Villalobos

5

If you have installed add-ons from sites other than AMO, you might be familiar with the domain whitelist. When you try to install an add-on from a third party site, you’ll see a doorhanger notification asking you if you want to allow that site to install software. The domain whitelist in Firefox allows you remove that notification for specific domains, which is useful if you install add-ons frequently from those domains.

A recent security bug fix in Firefox changed the way the whitelist works. Starting with Firefox  37 (to be released on March 31st), the doorhanger notification will always show up if you try to install an add-on from a page that is loaded with a plain HTTP connection. In other words, the domain whitelist will only work if the page the add-on is installed from is HTTPS. The URL to the XPI can still be plain HTTP, but the page that triggers the installation must be HTTPS.

The “extensions.install.requireSecureOrigin” preference can be set to false in order to revert this change. Also, this doesn’t affect automatic add-on updates in any way, even if they happen over plain HTTP.

March 2015 Featured Add-ons

Amy Tsay

6

Pick of the Month: Toolbar Buttons

by Michael B.

Toolbar Buttons adds toolbar buttons to the Customize Toolbar window in several programs including Firefox, Thunderbird and SeaMonkey. Some of the buttons make commonly preformed actions quicker, and others add new functionality.

“These buttons are colorful and smart!”

Also Featured

RequestPolicy by Justin Samuel

Be in control of which cross-site requests are allowed. Improve the privacy of your browsing by not letting other sites know your browsing habits. Secure yourself from Cross-Site Request Forgery (CSRF) and other attacks.

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, so there’s always an opportunity to participate. Please follow this blog to find out when we are selecting a new board.

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

JPM Replaces CFX For Firefox 38

Erik Vold

5

The Python based command line tool, CFX, was what we’ve used to build, run, and test add-ons which used the Add-on SDK in the past.  Last August, we released CFX 1.17 and there are no plans to release a new version.  We are replacing CFX with JPM which is a NodeJS based equivalent that works on Firefox 38 and higher and will be accepted on AMO.

For now, you can continue to use CFX as AMO will still accept those add-ons but it is recommended that you start using JPM tool as it is the only one receiving updates.

Why We Switched

We’ve made the new tool for a number of reasons: For one, the Python tool supported a number of features which we wanted to deprecate.  Also, building the tool with JavaScript instead of Python so that it may eventually be used in Firefox with the WebIDE and finally we wanted to replace the old third party module system that was invented for CFX with NPM.

If you are familiar with CFX then this guide on switching to JPM should prove useful.

Advantages

  • JPM is easier to install, especially on Windows.
  • JPM is easier to release, because CFX is Python based and is distributed as a zip file. JPM is Node-js based and is distributed through NPM.
  • JPM produces smaller XPIs, because no extra files are produced*.
  • JPM supports NPM packges.

We hope you enjoy JPM!

Find the source on github! and the issue tracker too!

*JPM produces an install.rdf and minimal bootstrap.js for now, in future versions it will not.

Add-ons Update – Week of 2015/02/25

Jorge Villalobos

11

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

  • Most nominations for full review are taking less than 8 weeks to review.
  • 115 nominations in the queue awaiting review.
  • Most updates are being reviewed within 2 weeks.
  • 57 updates in the queue awaiting review.
  • Most preliminary reviews are being reviewed within 6 weeks.
  • 85 preliminary review submissions in the queue awaiting review.

If you’re an add-on developer and would like to see add-ons reviewed faster, 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.

Firefox 37 Compatibility

The Firefox 37 compatibility blog post is up. The automatic AMO validation will be run in the coming weeks.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition (formerly known as Aurora) 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

We recently announced that we will require extensions to be signed in order for them to continue to work in release and beta versions of Firefox. If you’re an extension developer, please read the post and participate in the discussions. We will be posting a followup this week, expanding on the reasons behind this initiative.

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running each content tab in a different one. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

We will be talking more about these changes in this blog in the near future. For now we recommend you start looking at the available documentation.

Add-on Compatibility for Firefox 37

Jorge Villalobos

6

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

General

XPCOM

New!

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

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

Changes in Active User Counts on AMO

Jorge Villalobos

5

Add-on developers might have noticed a recent reduction in their active daily users counts on AMO. This was due to large gaps in the daily stats where the daily user count for various days was 0. It’s a problem we encounter with some frequency, so this time around the AMO devs did some deeper investigation into the matter.

Some malformed update pings were causing the log parsing to fail, leading to the empty stats days. The agreed solution was to perform stricter validation on the data before it is processed. This means that some daily usage stats will be slightly lower than before. We’re only filtering out data that we believe is malformed, so it should be a negligible amount for all add-on stats.

The fix was pushed live yesterday, and the missing data has already been backfilled. So, all stats should be back to normal now. Please check your add-on stats on AMO and let us know if you notice anything strange.

Introducing Extension Signing: A Safer Add-on Experience

Jorge Villalobos

364

Update: some of the details in the plan (particularly the timeline) have changed since this post was published. Please refer to this documentation page for the latest information.

This year will bring big changes for add-on development, changes that we believe are essential to safety and performance, but will require most add-ons to be updated to support them. I’ll start with extension signing, which will ship earlier, and cover other changes in an upcoming post.

The Mozilla add-ons platform has traditionally been very open to developers. Not only are extensions capable of changing Firefox in radical and innovative ways, but developers are entirely free to distribute them on their own sites, not necessarily through AMO, Mozilla’s add-ons site. This gives developers great power and flexibility, but it also gives bad actors too much freedom to take advantage of our users.

Extensions that change the homepage and search settings without user consent have become very common, just like extensions that inject advertisements into Web pages or even inject malicious scripts into social media sites. To combat this, we created a set of add-on guidelines all add-on makers must follow, and we have been enforcing them via blocklisting (remote disabling of misbehaving extensions). However, extensions that violate these guidelines are distributed almost exclusively outside of AMO and tracking them all down has become increasingly impractical. Furthermore, malicious developers have devised ways to make their extensions harder to discover and harder to blocklist, making our jobs more difficult.

We’re responsible for our add-ons ecosystem and we can’t sit idle as our users suffer due to bad add-ons. An easy solution would be to force all developers to distribute their extensions through AMO, like what Google does for Chrome extensions. However, we believe that forcing all installs through our distribution channel is an unnecessary constraint. To keep this balance, we have come up with extension signing, which will give us better oversight on the add-ons ecosystem while not forcing AMO to be the only add-on distribution channel.

Here’s how it will work:

  • Extensions that are submitted for hosting on AMO and pass review will be automatically signed. We will also automatically sign the latest reviewed version of all currently listed extensions.
  • Extension files that aren’t hosted on AMO will have to be submitted to AMO for signing. Developers will need to create accounts and a listing for their extension, which will not be public. These files will go through an automated review process and sent back signed if all checks pass. If an add-on doesn’t pass the automated tests, the developer will have the option to request the add-on to be manually checked by our review team. A full review option will also be available for non-AMO add-ons, explained further ahead.
  • For extensions that will never be publicly distributed and will never leave an internal network, there will be a third option. We’ll have more details available on this in the near future.
  • There will be a transition period of two release cycles (12 weeks total) during which unsigned extensions will only generate a warning in Firefox.
  • After the transition period, it will not be possible to install unsigned extensions in Release or Beta versions of Firefox. There won’t be any preferences or command line options to disable this.
  • Installation of unsigned extensions will still be possible on Nightly and Developer Edition, as well as special, unbranded builds of Release and Beta that will be available mainly for developers testing their extensions.

All Firefox extensions are affected by this change, including extensions built with the Add-ons SDK. Other add-on types like themes and dictionaries will not require signing and continue to install and work normally. Signature verification will be limited to Firefox, and there are no plans to implement this in Thunderbird or SeaMonkey at the moment.

What this means for developers

For developers hosting their add-ons on AMO, this means that they will have to either test on Developer Edition, Nightly, or one of the unbranded builds. The rest of the submission and review process will remain unchanged, except that extensions will be automatically signed once they pass review.

For other developers, this is a larger change. For testing development versions, they’ll have the same options available as AMO add-on developers. For release versions, however, we’re introducing the required step of uploading the extension file to AMO for signing. For most cases, this step will be automatic, but in cases where the extension doesn’t pass these tests, there will be the option to request a manual code review.

In the case of developers who want their extensions to be side loaded (installed via an application installer rather than using the usual Web install method) the review bar will be higher, equal to fully reviewed add-ons on AMO (with the exception of AMO content restrictions). This is a convenient installation avenue for software that comes bundled with an extension, for example an antivirus application that includes a Firefox extension that interacts with it.

One important improvement that signing brings about is that the extension install experience will be renewed and improved. Extensions that meet the full review standard will have a smoother and friendlier install experience, regardless of where they’re hosted. Here’s an early mockup of how this will work:

Installation flowThe plan is to have this system working, at least in the transition stage, in Q2 this year. So, we will probably introduce extension signing warnings on Firefox 39.

Discussion

We welcome comments on this post, but if you want to debate the merits of this plan, please do so in the add-ons user experience list. That’s where the people driving the project will read and respond to your concerns.