AccountObserver listeners were being triggered correctly, however, during every time
we open HomeFragment, home menu gets re-created, which causes us to re-run the initialization
block. Before this patch, the init block would never touch the account manager.
After this patch, it will query it if account manager has already been initialized.
This replaces the StartupTaskManager we had with a more general class.
New implementation is a thread-safe "gated task executor", which either
runs the task right away if it's marked as 'ready', or queries it to be
executed later on.
This ability to either execute or queue a task will be useful later on in the
commit series.
Cache the list of installed browsers. Calling `Browsers.all`
the application directly redundantly recalculates the list.
Accessing the list of installed browsers through this cache
will reduce that overhead.
* For #5694 & #6054: Adds preference screen for toolbar
* For #5694: Adds changing toolbar position functionality
* No issue: Updates telemetry links to actually work lol 😬
* For #6054: Adds toolbar position to core ping
* For #4281: small ToolbarMenu refactor
This makes it easier to see how items are ordered in the menuItems list
* For 4281: add QAB buttons to menu
* For 4281: removed menu back button per mocks
I double checked with UX, and we'll be relying on the hardware back button for its functionality
* For 4281: add content descriptions for bookmarking
* For 4281: updated BrowserToolbarController for new functionality
* For 4281: provided simple dependencies to browser controller
More complex changes will be in a following commit, for review readability
* For 4281: move toolbar controller dependencies up to BaseBrowserFragment
The functionality they control is being moved into the toolbar menu, which is shared by both normal tabs and custom ones
* For 4281: removed (now unused) code related to QAB
* For 4281: fix test compilation after QAB removal
Tests still need to be expanded to include added functionality
* For 4281: updated menu to show if url is bookmarked
This sloppy workaround is required because TwoStateButton requires that `isInPrimaryState` be a synchronous call, and checking whether or not the current site is bookmarked is quite slow (10-50 MS, in my tests). After days of work and many attempted solutions, this was the least abhorrent among them.
https://github.com/mozilla-mobile/android-components/issues/4915 was opened against AC to evaluate potentially supporting async `isInPrimaryState` functions.
https://github.com/mozilla-mobile/fenix/issues/6370 was opened against Fenix to investigate the unexpectedly slow call to `BookmarkStorage`.
* For 4281: update reader mode switch
* For 4281: selectively show/hide menu items
* For 4281: add reader mode appearance
* For 4281: update bookmark button when it is clicked
* For 4281: removed unused QAB code
* For 4281: removed QAB robot, updated UI tests
* For 4281: removed QuickActionSheet metrics
Since this behavior now lives in the toolbar, it is tracked via Event.BrowserMenuItemTapped
* For 4281: fixed lint errors
* For 4281: add new strings for buttons added to menu
This is necessary because the location change (from QAB to toolbar menu) could affect the grammar in some languages
* For 4281: remove outdated TODOs
* For 4281: removed QAB container
* For 4281: removed back button reference from UI test
This button no longer exists
* For 4821: Fixes a visual defect (extra padding on top of toolbar)
* For 4281: update copy on reader mode
* For 4281: fixed review nits
* Do not launch in Private Mode
When the app launches do not launch in Private Mode in order to prevent usage leaks to other users of the device.
* Issue #4780: add comments to use private mode
* For #4780: write tests for clear private mode on create app
* For #4780: clear private mode when privacy notification is removed
The previous solution would result in a crash because the passed in
viewTreeObserver that would trigger onPreDraw would be invalid.
The proposed solution is simpler and ensures we'll always use the right
viewTreeObserver.
`FragmentPreDrawManager` is general enough that can be used by other Fragments
also, so I've added it to the `utils` package.
This cleans up how we're displaying account state in the main preference UI.
Before when it worked, it worked mostly accidentally.
'launch' wrapper around "update ui" methods would trigger a race condition
between binding the account pref view holder and actually updating that view
with values. Sometimes the "update view with values" would happen after view
was bound, and the UI will be correct. Most of the time it would happen before,
and so there will be nothing to update and we'd get into an inconsistent state.
This also splits up the "accountpreference" into two: account is good,
and account needs re-auth. This greatly simplifies their management.
This patch fixes a few issues:
- it was an extension on a CoroutineScope, but that was quite misleading
since the Main dispatcher would be always used regardless of what dispatcher
the owning CoroutineScope was configured with.
- timing was reliant on exact value of the undocumented Snackbar.LENGTH_LONG duration
- coroutine cancellation relied on cooperation of the 'operation' suspend function,
which we can't depend on
New 'allowUndo' fully controls its timing, doesn't imply a dispatcher to its consumers,
and doesn't rely on cooperation of passed-in suspend blocks for cancellation to work.
Grisha Kruglov