Georg Fritzsche [:gfritzsche] Reporter
	Description • 10 years ago

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.

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 1 • 10 years ago

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

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 2 • 10 years ago

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

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 3 • 9 years ago

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.

	Benjamin Smedberg
	Comment 4 • 9 years ago

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

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 5 • 9 years ago

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.

	Benjamin Smedberg
	Comment 6 • 9 years ago

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.

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 7 • 9 years ago

(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.

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 8 • 9 years ago

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?

	Benjamin Smedberg
	Comment 9 • 9 years ago

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.

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 10 • 9 years ago

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.

	Dave Townsend [:mossop]
	Comment 11 • 9 years ago

(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.

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 12 • 9 years ago

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

	Benjamin Smedberg
	Comment 13 • 9 years ago

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.

	Dave Townsend [:mossop]
	Comment 14 • 9 years ago

(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.

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 15 • 9 years ago

(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

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 16 • 9 years ago

Filed bug 1177960 for the above.