Closed Bug 1053748 Opened 10 years ago Closed 10 years ago

[FHR] Crashing gmp using media.gmp.plugin.crash pref does not store data in FHR


(Firefox Health Report Graveyard :: Client: Desktop, defect)

34 Branch
Not set


(Not tracked)



(Reporter: bmaris, Unassigned)


(Blocks 1 open bug)


Reproduced on latest Nightly 34.0a1 (buildID: 20140813030201).

1. Open Nightly with new profile.
2. Wait for OpenH264 plugin to install.
3. Visit and start a h.264 video call
4. Set pref 'media.gmp.plugin.crash' as 'false' (you need to create it)
5. While the call is on, change the pref value to 'true'
6. Submit a crash report.
7. Visit about:healthreport
8. Search for crash data:
eg: "org.mozilla.crashes.crashes": {
          "_v": 5,
          "gmplugin-crash": 1,
          "main-crash": 1,
          "main-crash-submission-succeeded": 1

Expected result: First crash records data in FHR.

Actual result: First crash does not record data in FHR.

1. This issue does not happen every time, sometime I have data but not the same structure as the example from above.
2. Possibly the cause of this bug is bug 1049501.
3. I`ve seen this only on Linux platform. (testing on Ubuntu 14.04 32bit)
Depends on: 1009765
Whiteboard: [openh264-uplift]
Flags: firefox-backlog+
Does the crash still not show up even after you wait a few minutes and restart Firefox? There is an inherent delay between recording crashes in the crash manager and having them show up in FHR.
Flags: needinfo?(bogdan.maris)
After waiting for about 10 minutes, the crash still does not appear in FHR, but after a restart the crash does appear in FHR.

"org.mozilla.crashes.crashes": {
     "_v": 5,
     "gmplugin-crash": 1,
     "main-crash-submission-succeeded": 1
Flags: needinfo?(bogdan.maris)
It sounds like this is working as expected, then. gps can you confirm that a delay between adding a crash to the CrashManager and having it show up in the FHR payload is expected? And is there a way for QA to force a refresh using the browser console, for faster testing?
Flags: needinfo?(gps)
You can force an FHR collection by going to about:healthreport.

The crashes FHR provider does not ensure the CrashManager is up-to-date before grabbing data. That's arguably an oversight and is a one-line fix (plus tests) to correct, if desired.
Flags: needinfo?(gps)
I don't understand what "CrashManager is up-to-date" means in this context. GMP crashes don't write event files, they send the crash directly to the crash manager. So the CrashManager should always be up to date.

Bogdan, you are getting the data delay specifically by loading about:healthreport, right?
Flags: needinfo?(bogdan.maris)
I may have made a mistake in the STR from comment 0. I have about:healthreport opened in a tab when I crash the plugin. After submitting the crash I reload the tab with FHR and the data is not there, no data is written even if I close and reopen FHR in new tab/new window. Not having about:healthreport opened in a tab and opening FHR after the crash does store data. Sorry for the confusion.
Flags: needinfo?(bogdan.maris)
ok, I don't think there's a bug we need to fix here.
Closed: 10 years ago
Resolution: --- → WONTFIX
Flags: firefox-backlog+ → firefox-backlog-
Whiteboard: [openh264-uplift]
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.