QA/Desktop Firefox/Firefox Health Report

From MozillaWiki
Jump to: navigation, search

Firefox Health Report

Project Lead Mike Connor [:mconnor]
Dev Lead Gregory Szorc [:gps]
QA Lead Anthony Hughes [:ashughes]
Status [ON TRACK] Signed off for Firefox 21 Beta

Firefox 21


  • about:healthreport
  • dashboard for valid payloads
  • dashboard for broken payloads
  • opt-in/out
  • jank

FIXED Bug Verifications

Queries: target-milestone:21, status-firefox21:fixed

  • bug 849879 FHR User-Facing Tips for v1
  • [DONE] bug 850483 Send blocklist ping info as part of FHR payload
  • [DONE] bug 827910 Only report "extension" and "plugin" types for full add-on details
  • [DONE] bug 828720 FHR performance Telemetry
  • [DONE] bug 828546 Firefox Health Report provider to record Places metrics
  • [DONE] bug 829953 about:healthreport resets everytime you close that tab
  • [DONE] bug 830090 Access key for "Choose What I Share" button in info bar is broken
  • [DONE] bug 833612 Session restored time being reported as -1
  • [DONE] bug 841554 Ensure FHR search engine works in non en-US locales
  • [DONE] bug 843816 Detect duplicate sessions
  • [DONE] bug 852782 Update URL to final health report URL

Automated Tests

Manual Tests

  • [DONE] Load about:healthreport
  • [DONE] Show/hide details
  • [DONE] Learn more
  • [DONE] Enable/disable reporting
  • [DONE] Show report
  • [DONE] Verify through dogfooding that FHR does not cause additional jank

P1 Bugs

Query: bugzilla

  • [DONE] bug 849947 FHR submission counts vs Blocklist ping
  • [DONE] bug 830464 Obtain Privacy sign-off on all notification bar, pref pane, about:healthreport behavior
  • [DONE] bug 832547 FHR user-facing page design
  • [DONE] bug 840124 Implement postMessage API for remote report
  • [DONE] bug 849879 FHR User-Facing Tips for v1
  • [DONE] bug 852308 FHR error reporting policy for non-pre-release channels

bug 860477 about:healthreport loads slowly

Firefox 21b2
Platform Network First Run Reload New Tab Restart Clear Cache
Windows 7 (Intel Core2Quad @ 2.4GHz, 8GB RAM, 5400RPM HDD) 100Mbps Ethernet 2.7s 1.5s 1.1s 2.4s 1.9s
Windows 8 (AMD C70 @ 1GHz, 2GB RAM, 5400RPM HDD) 36Mbps WiFi 8.0s 3.0s 2.4s 5.2s 3.2s
Windows 8 (AMD C70 @ 1GHz, 2GB RAM, 5400RPM HDD) 100Mbps Ethernet 7.3s 3.9s 2.3s 5.1s 2.9s
Mac OSX 10.8 (Intel Core2Duo @ 2.4GHz, 2GB RAM, 5400RPM HDD) 36Mbps WiFi 5.3s 1.3s 0.9s 1.5s 2.9s
Mac OSX 10.8 (Intel Core2Duo @ 2.4GHz, 2GB RAM, 5400RPM HDD) 100Mbps Ethernet 2.3s 1.0s 0.9s 1.4s 2.5s
Ubuntu 12.04 (Intel i7-3520M @ 2.9GHz, 8GB RAM, 5400RPM HDD) 36Mbps Wifi 4.2s 1.1s 1.7s 2.5s 2.4s
Ubuntu 12.04 (Intel i7-3520M @ 2.9GHz, 8GB RAM, 5400RPM HDD) 100Mbps Ethernet 4.7s 1.2s 1.5s 1.8s 2.3s

Interfacing with FHR

With the exception of about:healthreport, everything about the feature is in the background. This makes it somewhat difficult to test and inspect because there is nothing to see.

FHR is attached to the;1 XPCOM service, which should always be present and running in Firefox 21 and newer. The FHR-specific functionality is attached to an object on this service:

 let reporter = Cc[";1"]

However, this property is lazy-loaded after app startup. Currently, we wait 45s on the first profile run and 10s on subsequent profile runs (these numbers may change).

When the healthReporter instance is constructed, it starts a long chain of asynchronous events required to initialize the instance. It opens a SQLite database, loads probes, etc. The construction on first profile run is one of the most expensive operations FHR will perform (it needs to create a DB and populate its schema, etc). It is important that you don't attempt to access any properties or functions on the .healthReporter instance until the promise returned by onInit() has resolved. e.g.

 let reporter = Cc[";1"].getService(Ci.nsISupports).wrappedJSObject.healthReporter;
 reporter.onInit(function onInitialized() { // This is when FHR is finally initialized. });

If you attempt to do anything before onInit() resolves, whatever you were trying to do may fail.

Once the FHR service is initialized, it starts monitoring the world and data is fed into it. All data is stored in a SQLite database, healthreport.sqlite in the profile directory.

Data upload is performed automatically and is scheduled for 24 hour intervals. Data upload will not occur until the user has been presented with a notification of Mozilla's data collection practices and privacy policy. For Firefox, this will manifest as a notification bar *on all windows and all tabs* sometime after the first app run with FHR present and before the first scheduled FHR upload. This is currently 12 hours after process start, although this may change.


All preferences for FHR are in the datareporting. branch. This branch has the following sub-branches:

Where all the FHR-specific preferences live.
Preferences containing state for Mozilla's data collection and privacy policies.
Contains a history of previous and current session state. These preferences are periodically migrated to FHR's database.

The following preferences are relevant to testing:

When we last uploaded a document to the server
The ID of the current document on the server
Level of logging to write to the Error Console. Set to Debug or Trace for lots of additional logging. By default, only errors are recorded.
When the next data submission is scheduled to occur. To trigger a soon'ish data submission, decrement the 3rd from front digit by 1 and wait up to a minute for the upload to be triggered. e.g. 13**6**4059453630 -> 13**5**4059453630.
Whether the data submission policy has been accepted. We will not submit data to the server unless this is true.