Right now, when the user navigates to the "Add Card" screen, the "Card Number"
title will be focused by default. Instead, let's make it so that the first
field for data entry is focused.
Since we're focusing the first field, let's also make sure that the soft
keyboard opens and that the cursor is placed at the end of whatever text has
already been input.
Right now, the soft keyboard will remain open when we exit the "Add Card"
screen. Let's make it so that the soft keyboard is automatically closed when
leaving this screen.
* Update Fenix release checklist
Updating this to reflect the latest process for releases for Firefox for Android.
* Incorporating feedback.
Incorporating review feedback.
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Rename in a separate patch for git to not merge this to previous changes and in
such think that the the old file was deleted and a new one was created.
Rename in a separate patch for git to not merge this to previous changes and in
such think that the the old file was deleted and a new one was created.
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.
To lighten-up our memory usage and startup performance, all of the RecentlyClosed
machinery was converted to use a light-weight TabState - specifically, it's missing
EngineSessionState, which is expensive to obtain during startup, and potentially
very costly to keep in-memory.
When we actually need EngineSessionState (at the point of restoration of a tab), we
read and rehydrate it using provided storage implementation.
