1249060 - Targeting e10s based on developer set flag for compatibility

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect, P2)

Description

[:shell escalante]

The idea is to create an "allow list" of the most popular add-ons that we know work with e10s.  The "allow list" will determine if e10s is enabled when firefox is updated.  If a Firefox user has add-ons that are not on the "allow list", they just won't get e10s turned on.   

This approach provides the smoothest experience for the end-user, while testing e10s with a broader audience and introducing more add-ons.  

This work will be built upon the targeting code being tested in Beta until 2/25 - which excludes any users with add-ons from having e10s turned on.

Comment 1

[:shell escalante]

Hi Felipe, Hi Dave, did the code go well enough in the experiment to iterate on for the "allow list"?  If yes - do we know who we should ask about doing the work?  Is it Felipe?

BDS suggested that if we have the capability to adapt the list on the fly that would be ideal, but i don't want to add a lot of work for something that should be a temp fix. Is it much more complex/risky to have the "allow list" accessed via server so it's adaptable?

Comment 2

[Dave Townsend [:mossop]]

(In reply to :shell escalante from comment #1)
> Hi Felipe, Hi Dave, did the code go well enough in the experiment to iterate
> on for the "allow list"?  If yes - do we know who we should ask about doing
> the work?  Is it Felipe?

My understanding is that it went well. Felipe or really anyone could do it for the simple case...

> BDS suggested that if we have the capability to adapt the list on the fly
> that would be ideal, but i don't want to add a lot of work for something
> that should be a temp fix. Is it much more complex/risky to have the "allow
> list" accessed via server so it's adaptable?

Making it able to change on the fly is a lot more work.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

(In reply to :shell escalante from comment #1)
> Hi Felipe, Hi Dave, did the code go well enough in the experiment to iterate
> on for the "allow list"?  If yes - do we know who we should ask about doing
> the work?  Is it Felipe?

Yeah, it went well. We tested that the code runs appropriately. Just to be clear, the code tested doesn't yet include any whitelist check, but adding a static one to it will be fairly simple. I'll probably do that work but I don't think we need to start working on it right now.

> 
> BDS suggested that if we have the capability to adapt the list on the fly
> that would be ideal, but i don't want to add a lot of work for something
> that should be a temp fix. Is it much more complex/risky to have the "allow
> list" accessed via server so it's adaptable?

Yeah, making it via server will be complex, but we do have a simpler plan to allow for dynamic updates. The plan is to use the system add-on that will be used for the staged rollout (from bug 1249845).  Adding a whitelist to this add-on and making the existing blocking code use it will require some work, but it's a lot easier.

The plan was to start testing this new rollout add-on now on 46, but after today's meeting it was decided to re-use the experiment system now (to avoid any risks on changing what the data looks like), and test the add-on later (probably once it makes to beta 47).

Comment 4

[:shell escalante]

Hi Mossop,  I adapted the User Story based on PM. we are now going to use the developer set flag (multiprocessCompatible:true) in the install.rdf to target "compatible add-ons" in addition to any built with webextensions.  

this removes the "allow list" upkeep and freshness issue - but is the mechanism we were looking at adapting before still an option to go off of information in the install.rdf file in the XPI?  https://developer.mozilla.org/en-US/Add-ons/Install_Manifests .  

The compatibility info lives only in the install.rdf and not the AMO database.  this may be a good reason to make it live in AMO as well though....

Comment 5

[Dave Townsend [:mossop]]

It should be ok to do that on the client side yes.

Comment 7

[:shell escalante]

felipe landed this functionality - closing