Private mode search with suggestion onboarding was overlapping "This time, search with: " text. Adjust constraints to allow it to show under onboarding when present.
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).
Created a dimension for the correct height that the EditText in the
fragment_edit_bookmark.xml has to have.
Co-authored-by: DrCesar <josuejacobstercero@gmail.com>
* 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
Instead of having a fixed width of 250dp the BrowserMenu will now have a
dynamic width between 250dp and 314dp allowing for a better fit for the menu
items it could display.
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)