[Bug] Crash when tapping on "Retry" when the tab wasn't sent

[sflorean]

Prerequisites

Sign in with the same account on Desktop and on Firefox Preview.

Steps to reproduce

1. On Android, open a webpage and tap Share from the main menu (don't tap on the account displayed).
2. On Desktop - your account - Manage account and change the password.
3. Immediately after the password is changed, go to Android and tap on the desktop account (displayed at step 1).
4. Tap on "Retry" from the snackbar.

Expected behavior

"Unable to send RETRY" toast is presented. Same as for step 3.

Actual behavior

Firefox Preview crashes.

Note

On Nightly, after performing step 4, no error is displayed again.

Device information

• Android device: Xiaomi MiPad 2 (Android 5.1), OnePlus 5T (Android 9).
• Fenix version: 3.1.0 - beta 3

retrycrash.txt

┆Issue is synchronized with this Jira Task

[Mugurell]

Could not reproduce the crash but I see another issue on various devices:
After pressing retry the current snackbar is dismissed but another new one isn't shown.
Trying to track this issue down was a rabbit hole but with enough logs in our code and in the com.google.android.material.snackbar package I got to see that

• when user presses retry we dismiss the current snackbar and the dismiss animations starts
• if the same action fails we again showFailureWithRetryOption()
• if we call show before dismiss finishing (and we can't force this because an "anonymous" ValueAnimator is used to animate and finally inform about the snackbar being dismissed) SnackbarManager just thinks we want to show an already shown snackbar and reschedules the dismiss timeout. In this time the ValueAnimator still updates the dismiss animation and will finally call onViewHidden which will remove the initial snackbar from the screen
  meaning that the second snackbar we wanted to show will not appear on the screen anymore

This seems to be a bug in the material.snackbar lib that we can't overcome. Indeed it's because of the method calls not being properly synchronized and can be avoided if for example the server action takes a longer time to execute and ultimately fail so that there is enough time for the initial snackbar to be fully dismissed so the call to show a new one will succeed but in our usecase it's very easy to have it reproduced.

Using a new instance of a FenixSnackbar seems to come with it's own share of issues. Will update this comment after investigating a bit more.

[Mugurell]

@sflorean Does the crash still reproduces for you?
I tried to but I can't reproduce. I think the issue causing the crash was fixed following some other work.

[sflorean]

@Mugurell the crash is not reproducible on Beta build - 4.2.0-beta.3 and the "Unable to send RETRY" snackbar is displayed again if it is tapped. However, on Nightly the snackbar is not displayed anymore after being displayed 3 times.

[Mugurell]

@sflorean Then maybe we can close this and based on Chenxia's comment we should think again about supporting consecutive snackbars if there are other scenarios also for this particular issue?