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
Categories
(Firefox Health Report Graveyard :: Client: Desktop, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bmaris, Unassigned)
References
(Blocks 1 open bug)
Details
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)
Updated•10 years ago
|
Blocks: WebRTC-OpenH264
Whiteboard: [openh264-uplift]
Updated•10 years ago
|
Flags: firefox-backlog+
Comment 1•10 years ago
|
||
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.
Updated•10 years ago
|
Flags: needinfo?(bogdan.maris)
Reporter | ||
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
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)
Reporter | ||
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
ok, I don't think there's a bug we need to fix here.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Flags: firefox-backlog+ → firefox-backlog-
Updated•10 years ago
|
Whiteboard: [openh264-uplift]
Updated•6 years ago
|
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•