We could consider renaming the Activity to make it clearer that it's the
main activity and doesn't just feature the homescreen but I'm concerned
that renaming it will break too many things (e.g. automation that starts
a specific activity). For quick fix, I added this comment.
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.
`init` blocks are executed before `val` initialization which is declared afterwards
in the class. In this case, we had `quitItem` and `reconnectToSyncItem` as lazy,
but declared after the `init` block which may need them. And so, while this compiles
just fine, in practice we run into an NPE as the `init` block tries to get the lazy's value.
Simply re-ordering initialization fixes the problem.
* For #8412: Passes error handling function to 'CustomTabWindowFeature'
Change required for showing error message when the app can't handle a specific
scheme. Implemented in AC:
https://github.com/mozilla-mobile/android-components/pull/6122
* Upgrade AC version
Co-authored-by: Sawyer Blatz <sdblatz@gmail.com>
In order to hide the time it takes for the account manager to be initialized
(which always involves disk IO, and often network IO), let's kick it off
after "visual completeness".
This makes sure that for most users, by the time they interact with the account
manager-related functionality (e.g. in Settings), it's ready to go.
Also, for signed-in users, this will establish background sync workers.
This refactor "reverses" relationship between these two classes, allowing
HomeMenu to inform its parent, HomeFragment, of any changes to the menu.
Once that's in place, we start observing account manager changes (once its ready)
for account problems.
This solves two problems:
- initialization of the account manager is no longer necessary to build a home menu
- home menu now starts observing changes to the account manager's state (before it was static)
Instead of always kicking off accountManager's init and telling it to sync right away in
'onResume', we move these tasks to some abstract point later on, whenever account manager
is available.
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.
* let animation in top toolbar mode play nicely.
* remove duplicate methods, make code readable.
* migrate getToolbarNavOptions method to BrowserAnimator, one method to rule them all.
* Update linting
Co-authored-by: ahmedmamdouh13 <ahmedmamdouh13196@gmail.com>
In order to eat the perceived performance costs, we initialize storage
once we're visually complete. This way, we're reducing chances of user performing
a UI action which will trigger storage init and delay said action.
Make sure that we actually lazily initialize our storage layers.
With this patch applied, storage layers (history, logins, bookmarks) will be initialized when first
accessed. We will no longer block GeckoEngine init, for example, on waiting for the logins storage
to initialize (which needs to access the costly securePrefStorage).
Similarly, BackgroundServices init will no longer require initialized instances of the storage
components - references to their "lazy wrappers" will suffice.
In practice, this change changes when our storage layers are initialized in the following ways.
Currently, we will initialize everything on startup. This includes loading our megazord, as well.
With this change, init path depends on if the user is signed-into FxA or not.
If user is not an FxA user:
- on startup, none of the storage layers are initialized
- history storage will be initialized once, whenever:
- first non-customTab page is loaded (access to the HistoryDelegate)
- first interaction with the awesomebar
- history UI is accessed
- bookmarks storage will be initialized once, whenever:
- something is bookmarked, or we need to figure out if something's bookmarked
- bookmarks UI is accessed
- logins storage will be initialized once, whenever:
- first page is loaded with a login/password fields that can be autofilled
- (or some other interaction by GV with the autofill/loginStorage delegates)
- logins UI is accessed
- all of these storages will be initialized if the user logs into FxA and starts syncing data
- except, if a storage is not chosen to be synced, it will not be initialized
If user is an FxA user:
- on startup, none of the storage layers are initialized
- sometime shortly after startup is complete, when a sync worker runs in the background, all storage
layers that are enabled to sync will be initialized.
This change also means that we delay loading the megazord until first access (as described above).
In order to target specific variants of Fenix, we're adding schemas that
are specific that app in order to avoid collisions with the other
variants and with other forks of fenix that may have the same schemas.
The current schema for variants:
- Fenix Nightly: `fenix-nightly://`
- Fenix Beta: `fenix-beta://`
- Everything else: `fenix://`
This monitor for hot start was intended to be used by FNPRMS to measure
hot start. However, hot start was deprioritized so it's now essentially
unused.
The a-c side of this work is in https://github.com/mozilla-mobile/android-components/pull/6128
This switches Fenix to use `SyncableLoginsStorage`, which caches a connection internally
on first access, and doesn't expose any lock/unlock APIs at the public boundary.
This patch removes the need to process() and then match() on every intent processor.
A successful process() means that we already matched. Doing this in two steps caused
issues when the process() failed but later the simple check in match() returned true.
After this patch lands I intent to remove the match() API from the IntentProcessor
interface in AC:
https://github.com/mozilla-mobile/android-components/issues/6097
