[Go Faster] updating and localizing system add-ons

Robert Helmer rhelmer at mozilla.com
Wed Sep 2 22:53:30 UTC 2015

I've changed the subject line since we're not really talking about the
challenges of moving Hello to an add-on anymore (those have been

More below.

On Tue, Sep 1, 2015 at 9:33 AM, Mike Connor <mconnor at mozilla.com> wrote:
> We've done locale-limited features in the recent past ("Flare" search UI
> rolled by locale through 34/35/36), via a locale-driven pref.  There's also
> absearch, which could be trivially extended/duplicated to roll out other
> settings by language/region/etc.
> In an ideal world, system add-ons will be able to embed some sort of flag to
> indicate locale/region compatibility, and Firefox will determine whether to
> load the add-on at all based on that flag. If the add-on strings get
> updated, we push a new update, Firefox sees that the locale is now
> supported, and we can then load for those users.  We could supplement with
> an absearch-like microservice if we want to do a phased rollout.  (And I
> think we'll want to be able to do a non-binary rollout of potential new
> features.)

System add-ons update info comes in as a set (according to the PRD and
patches under review). Current discussions are leaning toward this set
coming from the update service. We could customize the set on the
server side according to product/version/locale if necessary just like
we can for MAR updates - I think we want to avoid dealing with a
combinatorial explosion here so we probably don't want to use this
capability normally, but it's available.

Add-ons can certainly check the locale and gracefully degrade features
if desired - I think if we want to make such fine-grained decisions
then the add-on itself is probably in the best position to make them.

>From a quick look at the code, I believe the current Pocket
implementation does this. It checks the list of enabled locales (which
is in a pref) on startup to determine if it should show up in the UI:

Right now to me it feels like the server-side should be used for
things like phased roll-out (ensuring that the rollout itself is
working and not busting users), and the client side should be used for
things like localization and a/b testing (this puts the team working
on the add-on, who presumably are the most informed and have the most
to gain, in control without dependencies on other teams).

All that said - I think we have the ability to mix and match
client/server logic here, and we have the latitude to change our minds
if we don't like how things are going. Using existing systems and
services gives us a way to reduce dependencies and gives us some
immediate benefits (like shipping features faster) , but there's no
reason we can't for example later change the set to come from a
microservice that exerts more fine-grained control if we decide we
don't like having these decisions made on the client.

More information about the Gofaster mailing list