This api had a bug stemming from the property name - authenticatedAccount which
may return even an unauthenticated account.
After the recent refactorings it was left unused so best to remove it to
prevent from future misuses.
This new method allows a single source of truth for getting the up-to-date
account status without clients interesting in this needing to know what to
check for.
As in the previous version of tabs tray when tray is expanded while in portrait
it should have a 40dp offset and when the tray is expanded while in landscape
it should have a 0dp offset - effectively making it fullscreen.
These values were set in code, always overriding the xml set value so I
removed that xml declaration.
Setup a new TabSheetBehaviorManager with all the dependencies it needs to
set the initial tray's behavior.
This same manager will later be called to update behavior's properties.
Glean v39 allows to specify types for event extra keys.
The old API is therefore deprecated.
To avoid to much churn right now and keep the build going let's suppress
the deprecation warnings.
- Renames `BrowserInteractor` to `DefaultBrowserTolbarInteractor`
- Renames `BrowserTooolbarViewInteractor` to `BrowserToolbarInteractor`
- Refactors `BrowserToolbarViewInteractor` interface from `BrowserToolbarView.kt` to `BrowserToolbarInteractor` as `BrowserToolbarInteractor`
* For #18877 - Support updated PromptRequest AC APIs
This issue stemming from a race condition is fully resolved in AC by adding
support for having multiple prompts at a time.
Fenix needs just a small change to support the AC refactoring.
* Update Android Components version to 91.0.20210603145049
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
We were crashing because we were specifying the wrong `CreditCardNumber` type when constructing the `UpdatableCreditCardFields`.
We only had the plaintext card number from the user input, but was placing it off as an encrypted card number, which resulted in the crash.
This is not visible in production, but only debug. It shows three variables
being used to change the settings screen (title, icon and title-punctuation).
In our current MVI implementation the View Interactors are first called in
response to a direct user action and contain methods following the
"onXXHappened" naming scheme and then delegate other Interactors / Controllers
for specific actions.
Controllers contain the business logic for actually updating the app's state
and offer methods following the "handleXXAction" naming scheme.
* Add preferences for enable/disable sync for cc and addresses
* Set pref visibility based on feature flags
* Helper function for pin warning preferences and set default values for cc and addresses to false.
* Kdocs for relevant sync functions in account settings
* Default visibility to false for credit cards and addresses in account settings
We now have a BrowserTrayList.
- Renamed from `BaseBrowserTrayList`.
- Removed the abstract `configuration` and used a `lateinit var`
instead.
- Removed `NormalBrowserTrayList` and `PrivateBrowserTrayList`.
Previously renaming a TopSite would bind that as a new item and in such update
the entire list. This could potentially leading changes in the list and then
it's ViewPager parent's layout.
This patch switches the code to use the existing TopSitePayload and so do a
partial update of an on-screen TopSite instead of rebind it as a new item.
If a layout is requested while showing <=4 TopSites on the second page, by
having "offscreenPageLimit = 1" the biggest height of ViewPager pages is used
preventing an edgecase where the ViewPager would hide half of the items from
the first page.
Index calculation for notifying changes while renaming a top site in the second
page was being wrongly calculated. Since it is page 2, we would need to take a
mod with the number of top sites per page to get the actual index of the top
site that was being renamed.
The main cause for this is that the `LifecycleProvider` needs to be set
to `State.RESUMED` to avoid the account manager's internal
`ObserverRegistry` from putting the UI observers into the paused state.
The rest of the changes is to rely the internal (safe) logic to
correctly sync and then update the tabs list.
* Show synced tabs or sync account in new tab menu
* Sync sign in item navigates to account settings
* Check account auth and get sync item title
* Look for sync sign in item on home menu for UI test
* Sync sign in menu item UI test
When we allow the homescreen to handle undo for the last tab, we no
longer need to handle this ourselves with our own binding.
In the future, we should re-think this logic to be more robust and less
spread out across multiple screens.
The test failed with the rewrite of the code because it violates
one of our assumptions that only one Activity will be started. However,
since it doesn't rely on observed behavior and we made up the events,
it's value is questionable so it seems okay to remove, especially for
the gain of conciseness in the code.
* Remove signed in as string from sync menu item
* Nav to sync account settings on click
For #18806: navigate to settings account page or sign in on clicking menu item.
* Confirm account exists and retrieve item title
* Remove string
For #18857 [Telemetry] Send a Glean event when users change their default browser
For #18855 [Telemetry] Send an event when users open the toolbar menu
For #18851 [Telemetry] Send an event when users click on the "set as default browser" entry in the toolbar menu
Previously, to fix a memory leak, we were removing the adapter reference
entirely in order to have the `onDetachedFromRecyclerView` callback
invoked. This causes a side-effect where we can no longer reference the
adapter any more when we re-attach.
The simpler solution is to just invoke the needed callback directly
instead.
* For #16900: implement async navgraph inflation
For #16900: removed nav graph from xml
For #16900: inflate navGraph programatically
For #16900: Made NavGraph inflation asynchronous
For #16900: Changed to block with runBlocking
For #16900: Refactored blocking call into a function
For 16900: NavGraph inflation is now async
We now attach the nav graph (or check if its attached) on every nav call ( an extension function for NavController).
This is done by checking the value of the job stored in PerfNavController.map which keeps track of the job with the NavController as a Key.
If the job hasn't been completed, it will block the main thread until the job is done. The job itself is responsible for attaching the navgraph
to the navcontroller (and the inflation of the latter too)
For 16900: rebased upstream master
For 16900: Rebase on master
For #16900: Fixed Async Navgraph navigation per review comments.
1)The Asynchronous method is now found in NavGraphProvider.kt. It creates a job on the IO dispatcher
2)The Job is tracked through a WeakHashMap from Controller --> NavGraph
3)The Coroutine scope doesn't use MainScope() anymore
4)The Coroutine is cancelled if the Activity is destroyed
5)The tests mockk the blockForNavGraphInflation method through the FenixReoboelectricTestApplication instead of calling the mock every setup()
For #16900: inflateNavGraphAsync now takes navController
For #16900: Pass lifecycleScope to NavGraphProvider
For #16900: removed unused mock
For #16900: Added linter rules for navigate calls
We need linting rules to make sure no one calls the NavController.navigate() methods
For #16900: Added TestRule to help abstract the mocks in the code
For 16900: Fix linting problems
For #16900: Cleaned duplicated code in tests
For #16900: cleaned up NavGraphTestRule for finished test
For #16900: had to revert an accidentally edited file
For #16900: rebased master
* For #16900: Review nits for async navgraph
This is composed of squash commits, the original messages can be found below:
-> DisableNavGraphProviderAssertionRule + kdoc.
Use test rule in RobolectricApplication.
Fix failing CrashReporterControllerTest
Fix blame by -> navigate in tests.
This commit was generated by the following commands only:
```
find app/src/test -type f -exec sed -i '' "/import org.mozilla.fenix.ext.navigateBlockingForAsyncNavGraph/d" {} \;
find app/src/test -type f -exec sed -i "" "s/navigateBlockingForAsyncNavGraph/navigate/g" {} \;
git checkout app/src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker
```
Fix various blame
This is expected to be squashed into the first commit so, if so, it'd
fix the blame.
Move test rule to helpers pkg.
add missing license header
Add import change I missed
fix unused imports
Replace robolectricTestrunner with test rule.
Improve navGraphProvider docs
Remove unnecessary rule as defined by robolectric.
add clarifying comment to robolectric
remove unnecessary space
* For #16900: nit fixes for MozillaNavigateCheck and lint fixes
3 squash commits:
*Changed violation message and fixed the lint rule for MozillaNavigateCheck
*Added suppression to NavController.kt
*Fixed detekt violations
* For 16900: Fixed failing tests
Co-authored-by: Michael Comella <michael.l.comella@gmail.com>
The StartupActivityStateProvider uses an imperative implementation,
driven by callbacks, to set the state of the application. This is hard
to follow as you need to understand which callbacks will be called in
which order. For example, to make sense of an implementation like this,
COLD, WARM, AND HOT would likely need to be implemented in separate
ActivityLifecycleCallbacks.
I feel the StartupStateProvider is an improvement because it leverages
the StartupActivityLog to query a linear state for a more understandable
implementation. Furthermore, it seems accessible to write COLD, WARM,
and HOT in the same class because they can all be approached the same
way.
We moved the collection dialog code out from the old fragment, because it
had nothing to do with tabs tray, and into the collections package to be
re-usable in other parts of the app.
In addition, we also make use of it in the new tabs tray's
NavigationInteractor.
* Issue #18862: Add new addBookmark BookmarksUseCase
* Issue #18862: Add class for state binding features
* Issue #18862: Add delete multiple tabs to tray interactor
* Issue #18862: Add new actions to navigation interactor
* Issue #18862: Enable select mode from main tray menu
* Issue #18862: Add menu when in select mode
* Close#18862: Add multi-select banner to tabs tray
* Close#18862: Add select support for handle UI
We apply various layout changes to the "handle" UI in the tabs tray when
switching modes. It isn't quite clear to my, why we do this, if it's
really needed to meet the end result, and if there is a better way.
For now, we're simplying moving over that logic that we can re-evaluate
at a later time.
With a dynamic bottom toolbar the browser extends all the way to the bottom of
the screen and so when the find in page bar is shown it will be so above the
bottom part of the browser which may contain exactly the searched for items.
To fix the browser must effectively be placed at the top of the newly shown
find in page bar.
FindInPageIntegration which already updated the toolbar to make room for the
find in page bar now receives more data based on which it will be able to
better update the layout of BrowserFragment to to support showing the find in
page bar.
Copied the TabsTouchHelper from the `tabtray` package here so we don't
need to re-write our own because there's nothing more to add.
We can hook this up with our tabs tray here by putting it in the
`BaseBrowserTrayList` for our normal and private tabs list.
China fxa related string
Add switch preference in settings to use local/global fxa server
inherit fennec FxA settings
Present or hide fxa switch according to isMozillaonline
Allow China fxa server auto login during migration
Removes the recyclerview-selection library and replaces it with the
SelectionHolder/SelectionInteractor with a Store.
This is an implementation that's similar to what we have in other UI
lists (library).
* [SDK-246] Change Nimbus `channel` input to use the same method as Glean
* Update app/src/main/java/org/mozilla/fenix/experiments/NimbusSetup.kt
Co-authored-by: Gabriel Luong <gabriel.luong@gmail.com>
* Create new menu order for new tab
* Add new tab menu navigation. Dynamically update menu when sync auth is needed. Make new tab menu and browser menu consistent.
* Lint
Lint and refactoring tests
* Tests for default toolbar menu
* Feature flag for request desktop site
Add todos for UI test issue 17979
Add todos for UI tests
Lower Android versions don't offer the possibility of opening system settings
at a specific preference. In this cases we already shown a sumo article
detailing the manual steps each user is expected to perform to change the
system set default browser.
Add multi-select mode to the BrowserTabsAdapter. It has the
functionality to:
- Enable multi-select mode on long-press.
- Enable multi-select mode when changed by an external function.
- Only works for normal tabs (as we currently have it).
Co-authored-by: "codrut.topliceanu" <codrut.topliceanu@softvision.ro>
Although not public APIs we can use specific extras in the Intent used to open
system settings such that the "Default browser" setting is highlighted to
provide a better UX for users looking to set Fenix as default.
* Add intent processor for locale changes
* Recreate notification and notify in the service
* Use locale use cases to update notification
* Use notification id instead of tag
* Add locale use cases and restore locale in application
* Send locale to service instead of string
* Controller tests for locale
* Update Android Components version to 74.0.20210323143308
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
* [SDK-218] Nimbus updates to provide app_name and channel
Provides the `app_name` and `channel` info to Nimbus.
* Update to A-C Nightly 74.0.20210319190549
Co-authored-by: Travis Long <tlong@mozilla.com>
Hopefully this will help us understand behavior of the
`application_on_create` probe, specifically that it seems to take longer
in telemetry than in does locally compared to `home_activity_on_create`
(comparing the medians to local runs)..
* For #17805 - Fix adjustResize deprecation
To handle the deprecation of `adjustResize` I've moved it from `styles.xml` and `AndroidManifest.xml` to `Activity.kt` as a fallback for devices with Android < 11. For Android 11 and up `setDecorFitsSystemWindows(false)` and `OnApplyWindowInsetsListener` will be used to handle app insets. Normal use activities should call `enableSystemInsetsHandling` in `onCreate` as to properly display system bars and for proper keyboard handling.
Only on API 23+ (minimum Android version needed for SecureAbove22Preferences)
and only if enabled by a Nimbus experiment.
The Nimbus experiment will have the key `fenix-android-keystore` and use the
default branches - "control" and "treatment".
Previously setting it might have been arbitrarily delayed, resulting in
this metrics missing from pings that get submitted earlier.
Setting it early should prevent that.
The performance impact is negligible, Glean dispatches recording that
data off-main-thread anyway.
This refactors SyncLoginsPreferenceView to SyncPreferenceView so that it be can be used in the
Credit cards preference for the equivalent "Sync cards across devices" preference.
* Feature flag for toolbar menu redesign. Add new items to menu and reorder.
* Handle toolbar items in menu controller
* Remove bookmark from toolbar nav
* Respect toolbar position
* Inline toolbar orientation checks
* Add Todos for bookmark UI tests
* Make variable names consistent
For #18150: Improve showing/hiding of "Select tabs" button in tabs tray
Payload argument is unavailable after first call of notifyItemChanged() as the
whole View need to be updated.
Inject a "isPrivate" lambda in the adapter so it will always know what tabs are
currently showing and so always ensure the expected behavior.
While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
We do this in order to make it easier to analyze in GLAM: see the metric
descriptions for more details.
Additionally, we change the time unit to milliseconds to make it easier
to analyze in GLAM.
This was the previous behavior for both the top and bottom toolbars.
Regressed when changing to use a new custom behavior for the top toolbar.
When entering fullscreen we will now collapse and hide the toolbar, allow the
browser to expand to the entire screen estate and then, when exiting fullscreen
expand the toolbar.
Collapsing and then expanding the toolbar will trigger the
EngineViewBrowserToolbarBehavior to place the browser below the toolbar.
When the user opts out of telemetry, we need to reset the user identifiers
used by the experiment system, so that there's no risk of tracking the
user across the reset event if they later decide to re-enable telemetry.
* For #17352 - Fixes deleted downloads reappearing
The `getDeleteDownloadItemsOperation` job would check fragment context not null after the fragment was stopped. Removing that check and only passing the downloadUseCase as a parameter fixes the problem.
Previously when the toolbar was on top the banner was inflated in the toolbar's parent - an AppBarLayout.
After migrating to use a custom behavior for scrolling the toolbar and not use
anymore the AppbarLayout for this we needed a new solution.
Using a new behavior to keep this banner in sync with the y translation of the
toolbar gives us most of the old behavior back.
* Feature flag for toolbar menu redesign. Add new items to menu and reorder.
* Handle toolbar items in menu controller
* Menu controller tests
* Make icons invisible
* Lint
* UI tests reflect design change
* Refactor test names
* Lint fixes
* UI tests
* For #17418 - Adds channel "ts" to TrackKey
This is used to track if the `InContentTelemetry` is a result of the user using the Google Top Site. It looks for `&channel=ts` within the uri.
* For #17418 - Adds TopSite PerformedSearch back in
* For #17418 - Check now looks for equality with GOOGLE_URL
* For #17418 - Adds test for topSite changes
The IntentReceiverActivity one is particularly useful to quickly determine
when we can begin executing code in the WARM VIEW case (i.e. "Set selection
begin here").
The HomeActivity one is useful for COLD start up analysis in similar
ways and to see the Activity transitions in WARM VIEW.
This comes to unify the experience (with improvements but also specific issues)
for the url toolbar irrespective of it being placed at the bottom or at the top
Going further this will ease development and ensure the best UX for users.
* Moved Nimbus setup from Analytics to its own file
* Change experiment identifiers to fit new run of the experiment
* Re-enable nimbus for debug and nightly builds
* ./gradlew ktlint && detekt
Add privacy notice related strings
Pop out privacy notice with onboarding
Using embeded geckoview to display details about privacy
Present or hide privacy pop window according to isMozillaOnline
Add activity_privacy_content_display.xml into layoutNotToTest due to EngineView
Arturo Mejia
codrut.topliceanu
Mugurell
Grisha Kruglov
Mihai Adrian Carare
Christian Sadilek
mcarare
Jonathan Almeida
Gabriel Luong
Sammy Khamis
Jan-Erik Rediger
Sebastian Kaspari
rxumoz
James Hugman
Roger Yang
ZianeA
Elise Richards
Ionut Cristian Bedregeanu
Codrut Topliceanu
kanish671
Dharan Aditya
Michael Comella
Kate Glazko
MarcLeclair
Sören Hentzschel
Travis Long
Kershan
yichiehc
Vitaly V. Pinchuk
Stefan Arentz
Victor
Ryan Kelly
ekager
Abhinav Gupta
jhugman
MickeyMoz
hwinnemo
mawen7