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

Status: RESOLVED WONTFIX

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

Description

[Bogdan Maris, Desktop QA]

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

STR:
1. Open Nightly with new profile.
2. Wait for OpenH264 plugin to install.
3. Visit http://mozilla.github.io/webrtc-landing/pc_test.html 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.

Notes:
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)

Comment 1

[Benjamin Smedberg]

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.

Comment 2

[Bogdan Maris, Desktop QA]

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

Comment 3

[Benjamin Smedberg]

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?

Comment 4

[Gregory Szorc [: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.

Comment 5

[Benjamin Smedberg]

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?

Comment 6

[Bogdan Maris, Desktop QA]

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.

Comment 7

[Benjamin Smedberg]

ok, I don't think there's a bug we need to fix here.