* 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 #10505 - Adjusts wordmark margins
* For #10505 - Removes topsite header, fixes collections header size and removes divider
* For #10505 - Restyle the top site items on the homescreen
Added an extension function that pops the backstack of the fragment so the user is redirected to the Logins and passwords screen.
This is done to force the user to re-authenticate if he wants to re-enter the saved logins flow.
Additionally, some UI elements are being hidden on each Fragment since they were remained visible on the Logins and passwords screen's UI.
- Changed the visibility check to check just for the permissions shown instead of all the permissions in WebsitePermissionsState
- Added bottom padding to the permissions root view so there is balanced padding on top and bottom
For some text and colors, we were using the default styling where
possible. These styles contain references that react to theme changes
like dark mode. Since the migration UI does not respect these changes,
we should not use them.
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.
* Create editable view and fragment. Update login info page to display options menu with edit and delete.
* Create feature flag for edit. Check flag in the login detail fragment and default to just delete.
* Add three-dot kebab options menu in login detail fragment. Add title to the login item.
* Nav to and from edit view on save and back pressed.
* Save login through AC login manager. Clear text in editable field on button click.
* Match colors, fonts, dimens to UX specs for edit logins. Enable password reveal/hide and clearing text fields.
* Refactoring logins fragments. Using component Login object for consistency.
Fetch login list when saved logins are opened. Fetch login details when detail view is opened.
Revert "Fetch login list when saved logins are opened. Fetch login details when detail view is opened."
This reverts commit 44fe17166c3332b330229258b2e8982832672e3b.
* Using parcelable login and Login component class to pass ids and items between fragments
* Retrieve login from storage when viewing login details.
Rename login logic for consistency.
Ktlint cleanup
Fix nits and naming consistency.
* UX consistency for login detail and edit login pages
* Rebasing with logins sort - updating logins store.
* Rebasing with logins sort - merging fragments and controllers.
* Lint and removing unused files.
* UX cleanup.
* Update string description
Currently we support sorting by name and by last used. Also, the selected
option is saved in shared preferences so that the last option chosen by
the user is properly displayed even after the app was restarted.
* 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.
Setting the `navigationBarColor` is done in the ThemeManager for the
attached activity. Since the migration UI is separate from that, we did
not get this for free.
This hides the keyboard after committing a URL in the
Toolbar right before we navigate from the SearchFragment
to the BrowserFragment. If the BrowserFragment is being
displayed before the keyboard is gone an expensive
resize of the engine view (content) is triggered when the
keyboard finally goes away. This is to prevent that.
We need to access the data in stat to get the process start time, so we
can calculate the time from process start until application.init for the
frameworkStart probe.
If we just use the HomeFragment itself, we end up with a memory leak since the lifecycle events
that would clean up the registry (e.g. destroy) won't run (if the fragment is retained in the backstack, for example).
* 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
This is triggered on collection expanding or shrinking that is animated.
The animation has android:fillEnabled="true" android:fillAfter="true".
This interferes with set visibility to gone and the click still triggers.
Disabling button avoids changing animation or force clearing it.
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?
Added a new option in Private browsing menu to allow or prevent screenshots from being taken while in private mode by adding or removing the FLAG_SECURE flag from the home activity's window.
This method is called whenever the activity is initialized to account for the browsing mode being changed and whenever the setting from the Private browsing menu is changed.
The setting is by default set to true (screenshots are allowed to be taken)
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
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.
As far as I can tell, we never actually exercise the a-s libraries in Fenix tests currently (this was one of the presumed reasons for having a direct dependency).
In a different branch I've started work on adding end-to-end tests, but currently that's blocked on trying to figure out to load native libraries in tests (somehow, fenix's setup is different than what we have in A-C, not yet clear to me in what way).
Another reason for a direct dependency (i think) is that we needed it to configure a `fenix` megazord. This could be solved via a `support-megazord-fenix` a-c component that provides the correct transient dependencies,
but we can also just switch to use the `full` megazord instead, which is essentially what fenix megazord is at this point. A-S team wants to remove the fenix megazord, so this will help. This is what this patch does.
* For #8565: Create custom SharedPreferenceUpdater for String Preferences
* For #8565: Use custom updater to correctly update DropDownPreference
* For #8565: Set default values for dropDown preferences
* For 8565: add tests for findEntriesValue
* For 8565: clarified findEntryValue
Co-authored-by: Severin Rudie <Baron-Severin@users.noreply.github.com>
Added kapt plugin + dependencies in order to be able to use Room
Added recent apps to share fragment (top 6)
Extracted dimens of share_to_apps.xml in the dimens file
Jeff Boek
Jonathan Almeida
Tiger Oakes
Gabriel Luong
ekager
Mihai Eduard Badea
ValentinTimisica
David Walsh
apoorv9990
Sawyer Blatz
Christian Sadilek
Roger Yang
mcarare
Mugurell
Sebastian Kaspari
Simon Chae
Grisha Kruglov
sraturi
codrut.topliceanu
Juan Goncalves
Emily Kager
Mihai Branescu
Elise Richards
Tiger Oakes
Arturo Mejia
Michael Comella
Mihai Adrian
Sören Hentzschel
Chenxia Liu
Jovan Gerodetti
Falaye Iyanuoluwa
Vlad Filippov
Michael
Abhay Agarwal
Michael Droettboom
MickeyMoz
Edouard Oger
mcarare
Amaan Marfatia
Kate Glazko
ValentinTimisica
Severin Rudie
Severin Rudie
Jim Porter
Josh Vocal
Andrew Gaul
Harshal Lele
Will Hawkins
MarcLeclair
Sparky93
Dennis Schubert
Mihai Branescu