Closed Bug 1249060 Opened 4 years ago Closed 3 years ago

Targeting e10s based on developer set flag for compatibility

Categories

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

defect

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---

People

(Reporter: shell, Assigned: Felipe)

References

()

Details

(Whiteboard: [e10s throttling] triaged)

User Story

only add-ons that have self identified as e10s compliant can be part of the e10s activation audience at first -in addition to all add-ons that are webextensions.  

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.

Scenarios:
~version number matters (adblock plus 2.7.1 works, but not earlier)
~capability to allow add-ons built with webextensions 
~capability to allow add-ons with flags (may not be turned on for initial round)
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.
User Story: (updated)
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?
Flags: needinfo?(felipc)
Flags: needinfo?(dtownsend)
(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.
Flags: needinfo?(dtownsend)
(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).
Flags: needinfo?(felipc)
Priority: -- → P2
Whiteboard: [e10s throttling] triaged
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....
User Story: (updated)
Flags: needinfo?(dtownsend)
Summary: Targeting e10s based on "allow list" for add-ons → Targeting e10s based on developer set flag for compatibility
It should be ok to do that on the client side yes.
Flags: needinfo?(dtownsend)
Duplicate of this bug: 1229093
Blocks: e10s-addons
Blocks: e10s-addons-deploy
No longer blocks: e10s-addons
Blocks: 1299304
No longer blocks: e10s-addons-deploy
felipe landed this functionality - closing
Assignee: nobody → felipc
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.