Feature Request: Support option to launch Crash Modal Dialogue to collect User Feedback at Crash Time

[zsd4yr]

This request came out of discussions in #1197

We maintain a custom out-of-proc crash collector and have instrumented it with Google Breakpad and the Sentry Native SDK. We have our own dialog for gathering User Feedback and this feedback is incredibly useful for tracking down bugs and issues, especially in development / nonpublic user facing scenarios.

We are eager to take advantage of Sentry features like Backends, Screenshots, and Breadcrumbs by refactoring this system to make use of Google Crashpad as a backend for Sentry and deprecating our own out-of-proc handler.

However, in order to do that, we would need support for collecting User Feedback at-crash-time through a Sentry Crash Modal Dialogue. We can't move our own dialogue into the crashing-app as it would be unsafe to do so (a memory crash in the primary app would make this unsafe, for example).

Ideally this would be supported on all UI platforms - Xbox, Playstation, PC -- but my guess is that will take time to work out with each of those Operating System owners. To start, I think PC would be great!

[bruno-garcia]

I played around with building a x-plat UI to collect user feedback that we could spawn from the SDK when a crash happens. Didn't get super far (it's quite ugly and used some early versions of stuff) but I might get into this for hackweek: https://github.com/bruno-garcia/sentry-crash-reporter

[bruno-garcia]

Just came up on a call. Writing in to keep track

[jpnurmi]

Hi @zsd4yr, what kind of information do you pass to the Crash Modal Dialogue you are using?

I have experimented with this kind of approach:

1. On startup, register a path to an external feedback handler executable

   sentry_options_set_feedback_handler_path(options, "/path/to/my/feedback-app");

2. When capturing a crash, the feedback handler is spawned and detached with the following information passed in

   • Command-line argument: path to an envelope/event dumped on the disk
   • Environment variables: SENTRY_DSN and SENTRY_EVENT_ID

The command-line argument allows using almost any app for debugging and testing. Text editor, web browser, anything that is capable of handling a single argument and displaying a plain-text JSON file. The two environment variables are the bare minimum to be able to send user feedback to Sentry without having to read and parse the event on disk but if the details are needed - it's all there in the event file.

For example, a feedback handler could do something like this:

// for illustration only - missing all error handling
SentrySdk.Init(Environment.GetEnvironmentVariable("SENTRY_DSN"));

// using var event = JsonDocument.Parse(File.ReadAllText(args[0]));
// ...

SentrySdk.CaptureFeedback(
    comments,
    email,
    name,
    null, // replayId
    null, // url
    SentryId.Parse(Environment.GetEnvironmentVariable("SENTRY_EVENT_ID"))
);

Would this work for your use case?

Edit: Taking a step back on the environment variables. It gets ugly to plumb those for Crashpad. The proposal is to read the first line from the envelope instead. It contains both the DSN and the event ID.

[zsd4yr]

Hey @jpnurmi this is great

Typically the state we collect on a crash is just a description of the crash and then we prepend any relevant context in case the user wants to change any of them or include any addition attachments, etc...

[bruno-garcia]

letting the user add attachments serve what purpose? I'm not familiar with use cases for this capability

two main use cases I see:

1. Crash data is sent automatically. Feedback app pops up for optional additional user input.
2. Crash dump is collected, passed the the feedback app which can display the data to the user, collect optional feedback and let the user decide if they submit the report or not
   The first is a lot easier and imo ideal because the crash dump is sent automatically

On the second one, specially if folks can edit the dump data, can result in corrupt events (due to modifications), missed dump collection (since users opt out) etc.