(not currently active) Ted Mielczarek Assignee
	Description • 15 years ago

bug 539843 adds an API to submit crash reports. It takes an "id" parameter, which it expects to be the filename (sans extension) of a minidump in the "Crash Reports/pending" directory. It's also, conveniently, the exact data I provide on the PluginCrashed event in my patch in bug 541076. However, currently the OOP crash reporting paths don't move the minidumps from $profile/minidumps to Crash Reports/pending, which means the crash reporting UI has to do it. (The temporary UI in oopcrashdialog.js does this right now.)

We can't simply have the C++ move them to pending always, because that will break the test harnesses' ability to notice crashes and display a stack. The test harnesses currently set MOZ_CRASHREPORTER_NO_REPORT=1 to suppress launching of the crash reporter, which is why the minidumps stay in $profile/minidumps. We can honor that variable in the OOP case, but that will make writing a browser-chrome test for plugin crash reporting difficult, since the minidump won't wind up in pending as expected.

I don't really know what the right solution is here. Perhaps honoring the env var, but also providing a way for individual tests to override that setting?

	(not currently active) Ted Mielczarek Assignee
	Comment 1 • 15 years ago

Ok, this does basically what I described. I included a test that verifies that unsetting MOZ_CRASHREPORTER_NO_REPORT in a mochitest will let a minidump produced in that test be moved to pending, so we can use that to write a browser-chrome test for dolske's UI.

	(not currently active) Ted Mielczarek Assignee
	Comment 2 • 15 years ago

If the diff looks wonky in bugzilla's diff viewer, it's because I "hg cp"ed test_crash_notify.xul to a new file.

Also, I did some gratuitous tab-removal in the Makefile.in.

	(not currently active) Ted Mielczarek Assignee
	Comment 3 • 15 years ago

The test here depends on bug 541076.

	Justin Dolske [:Dolske]
	Comment 4 • 15 years ago

Updated to apply cleanly.

	Justin Dolske [:Dolske]
	Comment 5 • 15 years ago

Pushed http://hg.mozilla.org/mozilla-central/rev/748f275c6f1f

	(not currently active) Ted Mielczarek Assignee
	Comment 7 • 15 years ago

Comment on attachment 426271 [details] [diff] [review]
Leak quietly, rev. 1

We're leaking it either way, so whatever.

	Justin Dolske [:Dolske]
	Comment 8 • 15 years ago

In no way does this bug depend on bug 203764.

	Benjamin Smedberg
	Comment 9 • 15 years ago

http://hg.mozilla.org/projects/firefox-lorentz/rev/45d6586d3505

	Benjamin Smedberg
	Comment 10 • 15 years ago

http://hg.mozilla.org/projects/firefox-lorentz/rev/a7a1e08a510b

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 11 • 15 years ago

Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed

	Benjamin Smedberg
	Comment 12 • 15 years ago

Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430