* Bug 1820211 - Adds `tabKilled` event to track when a tab was killed with form data.
- Also includes if the tab was the active tab and whether the app was in the foreground.
* Bug 1820211 - Adds tests for TelemetryMiddleware and StoreLifecycleObserver
* Bug 1820211 - Renames CheckFormDataAction to UpdateHasFormData
- Removes @property hasFormData comment from sessionState
- Moves checking formdata from TabContentMiddleware to SessionPrioritizationMiddleware
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Whenever the ".crashed" property of the currently displayed
TabSessionState -> EngineState is true we will show an in-app crash reporter
with the usual close tab / restore tab options and also the option to report
all current non-fatal crashes to Mozilla if the setting for sending the crash
reports is enabled in app settings.
This closely mimics the previous crash reporter UI but there might be some
subtle differences stemming from migrating to using a ComposeView.
Whenever the ".crashed" property of the currently displayed
TabSessionState -> EngineState is false we will set the in-app crash reporter
to have a View.GONE visibility effectively removing it from the layout.
The functionality for receiving the non-fatal crashes from the AC CrashReporter
through an Intent is still kept and these crashes will be persisted in memory
until the user closes / restores a tab and so also makes a decision about
sending or not these crashes.
Currently more tabs can crash following just one since more share the same
process and as such there is no way to differentiate between them or link a
certain Crash to a certain tab.
They will all be acted upon at once from any tab the user chooses to close or
restore.
Matthew Tighe
rahulsainani
Gabriel Luong
Noah Bond
iorgamgabriel
Jeff Boek
Titouan Thibaud
mcarare
MatthewTighe
Mugurell
mike a
Jonathan Almeida
Jonathan Almeida