Per discussion with rnewman earlier today: * We want policy.jsm to drive triggering of the data submission info bar * Because the info bar is shared between Telemetry and Firefox Health Report, we can't have policy.jsm invocation from an XPCOM service hidden behind MOZ_SERVICES_HEALTHREPORT What I've done in this patch is create a new, always on XPCOM service tentatively called MetricsCollectionService. We should bikeshed about the name and the location of files in the tree. Anyway, this XPCOM service initializes a policy instance and starts it polling. The XPCOM service also exposes a HealthReporter instance iff FHR is enabled. Note that previously policy.jsm was bound to a HealthReporter instance. Because policy.jsm could some day drive Telemetry as well, we should probably reflect that in the API. Currently, things are FHR centric. Even the prefs still live in the "healthreport" branch! We could say follow-up on all this. Although, that would involve writing and maintaining migration code, which I don't care much for. I think we should do it right from the start. Anyway, this is something to look at. Splinter will likely fail with the patch because of file moving/renaming.

This patch actually works.

Comment on attachment 700587 [details] [diff] [review] Make data collection service generic, v2 Review of attachment 700587 [details] [diff] [review]: ----------------------------------------------------------------- Keep goin'.

Disclaimer: I haven't ran unit tests with this version of the patch. Waiting for build to finish. * XPCOM service and policy moved to /services/datareporting/ * This code is loaded if MOZ_DATA_REPORTING build variable is set. This variable is set if 1 of {Telemetry, FHR, Crash Reports} are enabled. It will presumably be enabled for all official Mozilla builds. * Policy is now instantiated very early in startup and isn't bound to HealthReporter instance. * Renamed HealthReporterPolicy to DataReportingPolicy. * Preferences moved under "datareporting." branch. * Split preferences into "datareporting.policy." for generic data reporting policy tracking and "datareporting.healthreport." for Health Report state. * DataReportingPolicy and the other types in policy.jsm need to be split because there is now a clear line between policy and FHR. This can be follow-up.

Fixed two very minor issues with patch that aren't worth commenting on.

Previously things were stored in the policy branch instead of healthreport. This didn't make any sense. There might be more of these prefs lingering. Please audit the list!

Comment on attachment 701233 [details] [diff] [review] Make data reporting service generic, v4 Combined review of both parts. Not using Splinter, sorry. * Fix removed-files/manifest. +const BRANCH = "datareporting."; -- ROOT_BRANCH, please. * Re policy/DataReportingService observer design: noting that this is half-way through a refactor. We really want several loosely coupled components: ** A policy object that *only* decides whether the user has made an election, and broadcasts accordingly ** A set of data upload services that listen for this and decide whether to start timers etc. ** A set of data uploaders that are driven by the upload services. Otherwise, looks good enough. Apologies in advance that a fair amount of this was reviewed through pattern recognition/instinct, rather than opening 20 editor buffers and spending five hours!

Comment on attachment 701233 [details] [diff] [review] Make data reporting service generic, v4 [Approval Request Comment] See uplift comment in bug 804745.

https://hg.mozilla.org/mozilla-central/rev/f2c240863a0c https://hg.mozilla.org/mozilla-central/rev/1761f4a9081c

Comment on attachment 701233 [details] [diff] [review] Make data reporting service generic, v4 https://bugzilla.mozilla.org/show_bug.cgi?id=804745#c37

Pushed to Aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/3a9faed791c8