We need to port the addons provider. Note that the environment carries information about active addons, plugins, etc. already. We probably need to record the inactive ones here and also the addon counts.

Note that the main telemetry payload contains an addonDetails field. We may want to morph that or remove it in favor of this migration.

From payload.info, this should make the addons and flashVersion field redundant. See bug 1120982 for details.

For now we could mimic the approach of TelemetryEnvironment here: https://hg.mozilla.org/mozilla-central/annotate/df3daecd381f/toolkit/components/telemetry/TelemetryEnvironment.jsm#l889 https://hg.mozilla.org/mozilla-central/annotate/df3daecd381f/toolkit/components/telemetry/TelemetryEnvironment.jsm#l939 https://hg.mozilla.org/mozilla-central/annotate/df3daecd381f/toolkit/components/telemetry/TelemetryEnvironment.jsm#l855 To not block on addon data async collection we would watch for addon changes and record the latest addon states in a TelemetrySession.jsm member. Telemetry payload collection would use the latest states here: https://hg.mozilla.org/mozilla-central/annotate/df3daecd381f/toolkit/components/telemetry/TelemetrySession.jsm#l951 Note that we want to collect all addons here, not only active ones. Later we would ideally expand the AddonManagerPrivate telemetry details to cover this, but i don't think this is feasible short-term.

How is this supposed to show up in the session ping?

I don't understand the question. If its added to the payloadObj like described here: > Telemetry payload collection would use the latest states here: > https://hg.mozilla.org/mozilla-central/annotate/df3daecd381f/toolkit/ > components/telemetry/TelemetrySession.jsm#l951 ... it will be part of the session payload.

Is this supposed to show up in .addonDetails? main-ping.rst doesn't specify what the data format is of that. Note that we really don't need addon counts any more, since we have addon lists.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #6) > Is this supposed to show up in .addonDetails? main-ping.rst doesn't specify > what the data format is of that. No - addonDetails contains some internal measurements pushed from the AddonManager. There is also ping.payload.info.addons, which contains a list of active addons: https://hg.mozilla.org/mozilla-central/annotate/cf1060d8ce9f/toolkit/components/telemetry/TelemetrySession.jsm#l788 https://hg.mozilla.org/mozilla-central/annotate/cf1060d8ce9f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#l2407 We should add the list generated here next to that and remove info.addons after transition.

Benjamin, i was wondering - if we really need that data for active & inactive addons, it would actually easiest to collect this in the environment too (i.e. just not limit the collection there to active addons). Current desktop FHR doesn't differentiate active & inactive either and this seems easier for analysis too. Any counter arguments you can think off?

I really don't want to be in a position where upgrading, disabling, or uninstalling an inactive addon causes a new subsession. Really I don't want to record data about inactive addons at all: I don't think anybody is actually going to use it and it will just bloat our data storage for no good reason.

Yeah, i was wondering how useful it is, but i vaguely recall that we wanted to keep inactive addons. Active addons (extensions, plugins, gmp, theme) are covered already by the current environment data.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #9) > I really don't want to be in a position where upgrading, disabling, or > uninstalling an inactive addon causes a new subsession. > > Really I don't want to record data about inactive addons at all: I don't > think anybody is actually going to use it and it will just bloat our data > storage for no good reason. I'd really like to be able to track how many add-ons are becoming disabled when we turn on the signing requirements. Currently I can see how many will be tracked but once we turn it on they will vanish from the data, we won't know how many users are getting switched to signed add-ons compared with being stuck on old unsigned versions. It would also be useful for example for being able to examine similar situations with blocklisting issues.

(In reply to Dave Townsend [:mossop] from comment #11) > (In reply to Benjamin Smedberg [:bsmedberg] from comment #9) > > I really don't want to be in a position where upgrading, disabling, or > > uninstalling an inactive addon causes a new subsession. > > > > Really I don't want to record data about inactive addons at all: I don't > > think anybody is actually going to use it and it will just bloat our data > > storage for no good reason. > > I'd really like to be able to track how many add-ons are becoming disabled > when we turn on the signing requirements. Currently I can see how many will > be tracked but once we turn it on they will vanish from the data, we won't > know how many users are getting switched to signed add-ons compared with > being stuck on old unsigned versions. > > It would also be useful for example for being able to examine similar > situations with blocklisting issues. Can we track that more specifically by submitting a count of disabled addons? Or a more detailed breakdown of counts per disabling reason (blocklisted, userdisabled, click-to-play)?

Mossop's use-case is reasonable, but I suspect we can solve it this way: Periodically submit a separate "addons" ping which lists all addons, enabled or not, including the signing status and all that good stuff. Suggest that "periodically" be no more than once per week. Dave, I also suggest that you consider a separate ping submitted at the time you disable an addon because it doesn't meet signing requirements: we could graph those in realtime and count them more easily than the normal session tracking pings.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #13) > Mossop's use-case is reasonable, but I suspect we can solve it this way: > > Periodically submit a separate "addons" ping which lists all addons, enabled > or not, including the signing status and all that good stuff. > > Suggest that "periodically" be no more than once per week. > > Dave, I also suggest that you consider a separate ping submitted at the time > you disable an addon because it doesn't meet signing requirements: we could > graph those in realtime and count them more easily than the normal session > tracking pings. Sounds somewhat similar to bug 1062386, I'm not sure how this helps though (mind you I have only the basic idea of getting data from FHR). Getting info on the number of users that see add-ons disabled when we first flip on signing is one thing, but after that we want to track how many users are still missing their add-ons.

(In reply to Dave Townsend [:mossop] from comment #14) > (In reply to Benjamin Smedberg [:bsmedberg] from comment #13) > > Mossop's use-case is reasonable, but I suspect we can solve it this way: > > > > Periodically submit a separate "addons" ping which lists all addons, enabled > > or not, including the signing status and all that good stuff. > > > > Suggest that "periodically" be no more than once per week. > > > > Dave, I also suggest that you consider a separate ping submitted at the time > > you disable an addon because it doesn't meet signing requirements: we could > > graph those in realtime and count them more easily than the normal session > > tracking pings. > > Sounds somewhat similar to bug 1062386, I'm not sure how this helps though > (mind you I have only the basic idea of getting data from FHR). Getting info > on the number of users that see add-ons disabled when we first flip on > signing is one thing, but after that we want to track how many users are > still missing their add-ons. Do we need to know which specific addons are affected or is it enough to keep track of the numbers per user? If we go with a separate ping, this is a minimal example: https://hg.mozilla.org/integration/fx-team/rev/c418add0c07f

Filed bug 1177960 for the above.