Targeting e10s based on developer set flag for compatibility

RESOLVED FIXED

Status

()

Toolkit
Add-ons Manager
P2
normal
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: shell, Assigned: Felipe)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(e10s+)

Details

(Whiteboard: [e10s throttling] triaged, URL)

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)
(Reporter)

Description

2 years ago
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.
(Reporter)

Updated

2 years ago
tracking-e10s: --- → ?
tracking-e10s: ? → +
(Reporter)

Updated

2 years ago
User Story: (updated)
(Reporter)

Comment 1

2 years ago
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)
(Assignee)

Comment 3

2 years ago
(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)
(Reporter)

Updated

2 years ago
Priority: -- → P2
Whiteboard: [e10s throttling] triaged
(Reporter)

Comment 4

2 years ago
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)
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1229093
(Reporter)

Updated

2 years ago
Blocks: 905436
(Reporter)

Updated

2 years ago
Blocks: 1281274
No longer blocks: 905436
(Reporter)

Updated

2 years ago
Blocks: 1299304
(Reporter)

Updated

2 years ago
No longer blocks: 1281274
(Reporter)

Comment 7

a year ago
felipe landed this functionality - closing
Assignee: nobody → felipc
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.