for #7225, refactored and cleanup the branch.
for #7225, change strict mode policy only on main process.
for #7225, setting thread policy inside a seperate thread to keep it from getting overridden in activities.
for #7225 removed Handler().postAtFrontOfQueue as a solution due to unknown side effects. moved the enableStrictMode function to be static so we can reuse it.
for #7225 lint check
for #7225 created strict mode manager and moved enabledStrictMode function inside it.
for #7225 removed penalty death on network
for #7225 added allow disk access on thread for already existing violation
strict mode running in main process to see if it passes the gitlab check, will revert it if it doesnt
allowed diskread for super.onCreate for home activity
added comments for disk violation oncreate homeactivity
added fragment manager inside strictmode manager
allowed disk read for onboarding
allowed disk read for cachedTopSites
* For #11171 - Removes feature flag for the new tab tray
* For #11171 - Removes all tab references from homeFragment
* For #11171 - Fixes unit tests
* For #11171 - Gets UI tests to compile and HomeScreenTest to pass
* For #11171 - Fixes `deleteMultipleSelectionTest`
* For #11171 - Fixes `openHistoryItemInNewPrivateTabTest`
* For #11171 - Fixes `openHistoryInPrivateTabTest`
* For #11171 - Fixes `openHistoryInNewTabTest`
* For #11171 - Fixes `openNewPrivateTabTest`
* For #11171 - Fixes tabbedBrowsingTests
* For #11171 - Fixes SettingsPrivacyTest
* For #11171 - Fixes TopSitesTest
* For #11171 - Fixes lint errors
* Ignore
* For #11056 - Removes unused argument when navigating to the collection creation fragment
* For #11056 - Moved the collection creation navigation logic to the TabTrayDialogFragment
* For #11056 - Moves navigating to the share screen from home/browser to the TabTrayDialogFragment
* For #11056 - We moved tab selection logic from home/browser to the tab tray dialog
* For #11056 - Moved new tab tapped logic to the tab tray dialog fragment
* For #11056 - Removes all interactor logic for the TabTrayDialogFragment
* For #11056 - Migrates the presentation / navigation around the TabTrayDialog to the androidx navigation library
* For #1063 - Adds feature flag and pref for new tab tray
* For #1063 - Swaps add tab to tab tray button when newTabTray is enabled
* For #1063 - Creates hidden preference to use new tab tray
* For #1063 - Hides tabs on home screen when setting is enabled
* For #1063 - Navigate to new tab tray from browser with setting enabled
* For #1063 - Fixes regression where we dont show the new tab message with no tabs and no collections
* For #1063 - Fixes crash when toggling to private mode on the home screen
* For #1063 - combines both settings. Cleans up lint errors
See https://github.com/mozilla-mobile/fenix/issues/4046 for a detailed discussion of this.
In short, this patch removes code that would conditionally hide desktop bookmarks depending
on the signed-in state of the browser.
* For #9751 - Cleans up homeFragment directions
* For #9751 - Uses global actions for fragments not owned by homeFragment
* For #9751 - Cleans up SearchFragment directions
* For #9751 - Removes settings action from DeleteBrowsingDataFragment
* For #9751 - Removes browser action from SettingsFragment
* For #9751 - Adds ManagePhoneFeature global action
* For #9751 - Clean up unused deletebrowsingfragment actions
* For #9751 - Cleans Up HistoryFragment actions
* For #9751 - Removes Home -> Search action
* For #9751 - Removes the Bookmark -> Browser action
* For #9751 - Cleans up bookmark fragment actions
* For #9751 - Cleans up actions from ShareController
* For #9751 - Removes defaultBrowserFragment to browserFragment action
* For #9751 - Removes about -> browser action
* For #9751 - Adds global action to TrackingProtectionFragment
* For #9751 - Removes exception -> browser action
* For #9751 - Removes login -> browser action
* For #9751 - Fixes LoginFragment directions
* For #9751 - Removes ExternalAppBrowser directions
* for #9751 - Cleans up actions
* For #9751 - Fixes unit tests
* For #9751 - Addresses nits in PR
They were both in their packages by themselves, which feels unnecessary.
Unfortunately, a utils pkg is discouraged by kotlin but we don't have a
better place for them right now. Maybe an annotations/ pkg for the
latter?
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>
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).
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.
Workaround for issue described in:
https://github.com/mozilla-mobile/android-components/issues/5989
For debug builds it is unnecessary to use the actual location provider since those builds
do not have an API key configured. With that patch we replace the location provider with
a dummy implementation in debug builds.
This new event will be sent when the user has successfully migrated from Fennec
to Fenix.
This event will only be sent to Leanplum and not to the other telemetry
services like Glean or Adjust.
Co-authored-by: ValentinTimisica <valentin.timisica@softvision.ro>
Tiger Oakes