It is possible that after migration users would already have Firefox PWAs on
their screen.
Since they already know about this functionality, we should not promote it to
them with the one-off `FirstTimePwaFragment`.
To query installed PWAs we'll use an API available only on Android >= 26 which
means that we will probably have half of users with PWAs still see the
onboarding but half which will not.
Problem was that we were trying to process menu changes (in response to account manager events) on some background thread as that's what account manager emits them on, so some code internally in PopupWindow's dismiss handling (i think, didn't dig very deeply here) was silently giving up and we'd get into a bad state.
The reason this seemingly only happened if you quickly opened a menu on startup is because account manager isn't initialized until sometime after the startup finished. So the trick was to open the menu (and register account manager state callbacks) before it got initialized, so that the callbacks are invoked.
This should also reproduce in other, much more obscure ways, e.g. if you open the menu right before sync is scheduled to run in the background, change FxA password on another connected client, and then eventually receive a onAuthenticationProblem callback.
- Renamed DownloadNotification and removed DownloadState.dismissed dependency
- Improved DynamicDownloadDialog behaviour when scrolling
- DynamicDownloadDialog remains attached to tab until dismissed
- Fixed onTryAgain not working for resumed DownloadDialogs
As the bookmark node data is loaded from storage every time the fragment's view is created, when the user navigates to the SelectFolderFragment and returns, the bookmark is loaded once again from storage, replacing the EditText's content (title and URL) which causes the loss of user input.
Validating that the loaded bookmark is different from the one that is already referenced in the fragment avoids unnecessarily replacing the `EditText`s values.