If permissions are changed the app process is restarted with the same
happening for the previously running app components.
SearchDialogFragment used for searches will check if qr scanning was in
progress and resume if needed.
PairFragment used for signing-in will start scanning on itself.
Android-Components will avoid resuming the scan functionality if the camera
permission is missing and so allow to request the permission again without the
camera permission related system calls causing issues.
If the app is opened from the search widget and the MR onboarding is shown then
the backstack will have the following structure:
- root, homeFragment, searchDialogFragment, onboardingFragment
as opposed to otherwise
- root, homeFragment, searchDialogFragment.
This patch allows to avoid the MR onboarding fragment causing the
SearchDialogFragment to not know that below it is the HomeFragment and
consequently not applying transparency or propagate user touches to the parent
Activity.
This avoids having to pass another LifecycleOwner from outside and will ensure
the View is update only in the bounds of it being attached.
The observe-update code is moved to bind(..) as that seems like a more
idiomatic callback for updating an already constructed View rather than
createView() which should only create and return a View.
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.
Assuming the InlineAutocompleteEditText is not being recreated (and I
did not verify this), it's unnecessary to traverse the view hierarchy
to find it more than once so this patch removes the unnecessary
traversals.
Home screen isn't actually visible in case we're displaying awesomebar
search results. The navigation is thus unnecessary and actually causes visual
jankiness as we display home for a moment before covering it up with
search results.
* Navigate to home on toolbar click. Handle back press from search dialog
Update tests to show home behind search dialog. Remove unused test.
Jump back in show all button is clickable behind search dialog
Recently saved bookmarks show all button is clickable behind search dialog
* Add feature flag
* Past explorations show all button is clickable behind search dialog
Handle keyboard in controllers instead of viewholders. Update tests.
Allow collections to be visible behind search dialog
Dismiss keyboard and search dialog with navigateUp instead of just dismissing the keyboard
Verify navigateUp in tests
Adding ignore for flaky UI test
Only resize home behind search dialog
Add ignore for collection intermittent test
Cleanup
DreVla
Madalin Valceleanu
Mugurell
mcarare
mike a
Alexandru2909
Timshel
Roger Yang
Alexandru2909
Gabriel Luong
jknair
Christian Sadilek
Grisha Kruglov
Arturo Mejia
Sebastian Kaspari
Michael Comella
Elise Richards