I'm going to move this to geckodriver so that we can better triage / handle this particular feature. If possible I would like to give it some priority so that we can analyze crash reports for wdspec tests. This would also involve bug 1433495, which is the only dependency now.

With the profile handling changes for wdspec tests in our CI this bug might not be that important anymore given that the profile remains, but we will have to check if triggering a crash by eg. navigating to about:crashparent or about:crashcontent allows us to analyze the generated minidump.

I'll check that next week.

Loading about:crashcontent or about:crashparent currently fails in wpt the following way and no crash report being detected / printed to the log:

0:14.25 pid:20090 1653936265738	Marionette	DEBUG	0 -> [0,4,"WebDriver:Navigate",{"url":"about:crashcontent"}]
 0:14.25 pid:20090 1653936265741	Marionette	TRACE	[25] Received event beforeunload for about:blank
 0:14.31 pid:20090 1653936265800	Marionette	TRACE	Remoteness change detected. Set new top-level browsing context to 30
 0:14.31 pid:20090 A content process crashed and MOZ_CRASHREPORTER_SHUTDOWN is set, shutting down
 0:14.32 pid:20090 1653936265813	Marionette	TRACE	[30] Received event beforeunload for about:blank
 0:14.32 pid:20090 1653936265813	Marionette	TRACE	[30] Received event beforeunload for about:blank
 0:14.33 pid:20090 1653936265823	Marionette	TRACE	Received observer notification quit-application
 0:14.33 pid:20090 1653936265823	Marionette	INFO	Stopped listening on port 56639
 0:14.33 pid:20090 1653936265823	Marionette	DEBUG	Marionette stopped listening
 0:14.35 pid:20090 1653936265842	Marionette	TRACE	Canceled page load listener because the top-browsing context has been closed
 0:14.35 pid:20090 1653936265843	Marionette	DEBUG	0 <- [1,4,null,{"value":null}]
 0:14.36 pid:20090 1653936265847	webdriver::server	DEBUG	<- 200 OK {"value":null}
 0:14.36 INFO STDOUT: PASSED
 0:14.36 pid:20090 1653936265848	webdriver::server	DEBUG	-> POST /session/d3f5c4d3-66d4-40e9-ac8c-c61a3337ce1e/timeouts {"implicit": 0}
 0:14.36 pid:20090 1653936265851	webdriver::server	DEBUG	Teardown session
 0:14.36 pid:20090 1653936265851	geckodriver::marionette	ERROR	Failed to close browser connection: Socket is not connected (os error 57)
 0:14.36 pid:20090 1653936265851	webdriver::server	DEBUG	<- 500 Internal Server Error {"value":{"error":"unknown error","message":"Failed to decode response from marionette","stacktrace":""}}
 0:14.36 INFO STDERR: Ignored exception unknown error (500): Failed to decode response from marionette
 0:14.36 pid:20090 1653936265852	webdriver::server	DEBUG	-> GET /session/d3f5c4d3-66d4-40e9-ac8c-c61a3337ce1e/window
 0:14.36 pid:20090 1653936265852	webdriver::server	DEBUG	<- 404 Not Found {"value":{"error":"invalid session id","message":"Tried to run command without establishing a connection","stacktrace":""}}
 0:14.36 pid:20090 JavaScript error: chrome://remote/content/marionette/cert.js, line 55: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsICertOverrideService.setDisableAllSecurityChecksAndLetAttackersInterceptMyData]
 0:14.36 INFO STDERR: Ignored exception invalid session id (404): Tried to run command without establishing a connection

It doesn't look like that wptrunner tries to find the minidump files at all for the used geckodriver profile. James, I assume we need a check_crash implementation for our pytestrunner class to actually get this working?

This will enable processing minidump files as long as we're using the
original wptrunner-set profile. If we start Firefox using a different
profile (as we do in some new-sessiont tests) any crashes there won't
be reported.

https://hg.mozilla.org/mozilla-central/rev/f6c96680b7b4