Hopefully the issue with the timestamps was simply that we were
recording them, but not copying them to the Sentry
breadcrumb class.
The issue with duplicate items looks like it could be a threading issue
to me and AFAICT when multiple threads report breadcrumbs, we are
currently mutating the array without any synchronization.
- Added new component that hooks into the new app-services error
reporter and listens for events. When it sees an event it submits it
to the crash reporter.
- Added support for customizing crash reports for these errors.
This adds a processType field to NativeCodeCrash which is read from
the GeckoView crash intent. This can have one of the following values:
* MAIN: indicating a fatal crash in the main process.
* FOREGROUND_CHILD: indicating a crash in a foreground child process (such as a
Gecko content process). The application may be able to recover from this.
* BACKGROUND_CHILD: indicating a crash in a background child process (such as
Gecko's GPU process). The engine will automatically recover from this, and the
crash will have barely been noticeable to the user, if at all.
The existing isFatal property is now calculated from the processType. It is true
for MAIN, and false for others.
We treat MAIN crashes as we did fatal crashes before: we do not send the intent
to the application, but do show the prompt or notification to the user, if
required.
We treat FOREGROUND_CHILD crashes as we did non-fatal crashes before: sending
the intent to the application if requested.
For BACKGROUND_CHILD crashes, we do _not_ send the intent to the application. As
the engine automatically recovers there is no need for the application to handle
the crash. Additionally, we choose to display the crash notification rather than
prompt, as we do not wish to interrupt the user's flow.
