* For #21903 - Added telemetry for interacting with inactive tabs
* For #21903 - Added missing inactive tab delete count event to delete all event
* For #21903 - Added PR numbers to metrics
* For #21903 - Updated broken unit tests. Resolved critical lint warning.
* For #21903 - Fixed inactive tabs setting toggle metric
* For #21903 - Updated FenixApp unit test
* For #21903 - Updated newline character in Metrics. Set inactive tab metrics' lifetime to default. Updated expiration to Nov 2022. Refactored inactive tabs metric to be a single metric.
* PR: addendum for last commit that missed a file
* For #21903 - Changed logic check for reporting inactive tab count
* PR: fixed merge conflict
* For #21903 - Removed tab close tracking when the user closes ALL inactive tabs
* For #21903 - Removed individual tab close metric verify from CLOSE ALL test
* For #21903 - Updated inactive tabs toggle setting expiration to match the expiration of the other events
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Remove redundant calls to setHasOptionsMenu(false)
Fix memory leaks for credit card and login fragments
* Fixes:
Add link to issue tracker
Use activity?.invalidateOptionsMenu() instead of setHasOptionsMenu(false)
Move it inside of 'if' statement to avoid unintended issues when called improperly
Revert changes to AddLoginFragment.kt
* Fix call invocation to redirectToReAuth() from AddLoginFragment.kt
Fix 'when' statement in redirectToReAuth() to use AddLoginFragment
Co-authored-by: Vitaly V. Pinchuk <vetal.978@gmail.com>
Fetching a set of logins from the store is quite expensive. This commit
avoids doing that while navigating back and forth between the list and
detail views:
- retain processes logins state when navigating into detail view
- use the `get` storage api to obtain specific login, instead of
`list().filter {...}`
- avoid re-sorting retained logins when navigating back into the list
view
Switched to always using `Login` instead of the `SavedPassword` alias.
Made `MasterPasswordTipProvider.saveLogins()` call
`importLoginsAsync()`. This is needed because it's the only method that
inputs a `Login` rather than a `LoginEntry`.
Moved the `SavedLoginsStorageController.kt.syncAndUpdateList` call
to inside `add()` and `update()`. This simplifies the error handling a
bit.
Refactored dupe-checking code to use findLoginToUpdate()
Refactored `AddLoginFragment` / `EditLoginFragment` to put the username
error handling code all in 1 method. I think it's easier to follow the
logic of showing/hiding the error labels when it's all in one place.
This fixes issues #24103 and #24104. I would love to address #24102,
but I'm not sure what the correct behavior is there so I just kept that
the same.
At this moment, we have two extension methods that have duplicate
functionality to construct search term groupings. One on `List<Tab>` and
one on `List<TabSessionState>`. The former is used for everything
related to tabs piped through the `TabsFeature` and the latter is for
consumers of `BrowserState` directly.
The bug occurs because our implementation of search groupings was
updated only on the former extension, but the `HeaderBinding`, that
observes the BrowserState and updates the title visibility, was using
the latter.
Ideally, we remove this duplication when we no longer have separate data
classes for consumers of `TabsFeature`, but this intermediary fix should
suffice.
Before this patch, this was the behavior - 'remove' button is clicked, we'd ask
the storage to remove metadata (on its IO thread), then navigate to Home
Screen.
This resulted in a race we could end-up on the Home Screen before delete
finishes, so the search groups do not appear to be removed (but,
refreshing the Home Screen again shows that they are removed).
This also resulted in an unnecessary navigation which felt very janky
(screen will "scroll" to the top) and was way more work than necessary.
After this patch, we:
- dispatch two actions (on browserstore, on homefragmentstore) which
remove the search groups from any relevant in-memory state; any UI bound to
this state will be automatically "refreshed"
- no longer navigate as part of the remove action, so the UI doesn't
move and removal happens "in-place"
It seems like we no longer need to use rotation for the chevron, since
we are now using two different icons within the `ic_chevon` that change
depending on the `state_activated`.
This helps identify file IO. Unfortunately, with this marker, it's
difficult to separate code we own from code we don't own. However, I
wasn't sure what the best implementation would be to address that
(e.g. ideally, we would ignore violations in code we don't own rather than
annotate the markers) so I thought we can land it this simple way and
improve it incrementally.
* For #21437 - Relocated Home-related settings to its dedicated sub screen
* For #21437 - Updated show top sites toggle text
* PR: Fixed lint warning. Reverted preference keys
* PR: added ignore for UI test
* PR: Added ignore for UI test
The bottom gray border of the header item from the Inactive Tabs section was correctly set when collapsing or expanding said section, but not on init. So if the section was initialized collapsed the gray border would not be present.
This regressed in our previous fix that made sure child tabs don't
mistakenly get moved out of the group if their parent is navigated
away, or in case the child tabs are redirected.
However, when a subsequent load occurs in any tab in the group the
search terms need to be cleared and the tab removed from the group
to prevent false positives.
* For #21360 - Added toggle for search term tab groups
* For #21360 - Lint cleanup
* PR: Added missing licenses and possibly fixed UI test
* PR: Added a "scrollTo" to potentially fix a UI test
* PR: Added potential fix for alwaysStartOnHomeTest
* PR: Added temporary ignore to alwaysStartOnHomeTest
* PR: added missing ignore comment
* For #21360 - Added missing feature flag driven visibility logic
Co-authored-by: Sebastian Kaspari <s.kaspari@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Home screen isn't actually visible in case we're displaying awesomebar
search results. The navigation is thus unnecessary and actually causes visual
jankiness as we display home for a moment before covering it up with
search results.
* Issue mozilla-mobile#21319 - Moved inactive tabs to the top of the normal tabs tray.
* Issue mozilla-mobile#21319 - Added a delete icon to delete ALL inactive tabs.
* Issue mozilla-mobile#21319 - Changed default inactive time period to 14 days
* Issue mozilla-mobile#21319 - Hooked inactive tabs setting to UI code
Inactive tabs setting is also disabled when the user has selected the one day or week auto-close tab setting.
* Issue mozilla-mobile#21319 - File and Lint cleanup
* PR: Fixed bug causing grouped tabs to also show in "Other" when marked as inactive but inactive is OFF in Settings
* PR: Fixed lint warnings
* PR: Removed redundant feature check
* PR - Ignore test until search term tab groups switch is done
These double comparisons are easier to read and see the pattern of on one line
so I'd rather keep them on one line. Additionally, it's difficult to
test each change individually so I'd rather not make additional changes.
To do this, I suppressed the max line length warning.
This commit was generated primarily by a macro that:
- appends `== component &&`
- appends `== item`
- (if applicable) Skips to the ending brace
- Go down one line and move cursor to the front of the line to prep for repeat
My only intervention was to skip extra lines to line it up to run again
and specify how many times in a row it should run.
---
The `to` in this code is an infix function that calls instantiates a
Pair under the hood. Subjectively observed, when this method is called
it generally hits the else case so 35 Pairs are instantiated each call -
that's 560 bytes. This method is called frequently - for example, an estimated
4 times each time a letter is typed on the homescreen and a measured 116 times
in a simple navigation (see the issue). The latter generates an estimated
63.4 KiB.
It was straightforward to remove these allocations so that's what this
change does.
The primary risk from this change is that it's difficult to test each
case to ensure it's working.
- stick to one naming scheme: rename articles to stories and use this all
throughout the app.
- add some spacing above the new section (as per the current design)
We currently have a 15s buffer to match metadata to its corresponding
visit. However, a existing metadata record can be updated more than
15s after it was created e.g. when closing the tab and updating
the view time.
We discovered that in a tab restore scenario we were recording view time
observations that were wrong - we'd record time deltas as-if user was
looking at the page while the browser wasn't running.
This happens because when we record a viewTime observation, we compare
current time with lastAccess time of the tab. In a restore scenario,
that lastAccess time happens to be from when the browser was last
running - which could be days ago.
The simplest solution was to not record a viewTime observation if the
url for a tab didn't change during a load event. To achieve this, we
needed to change which action we were using as a proxy for "navigation
events" - UpdateUrlAction contains the new url, allowing us to compare
against the current tab url.
Alternative solutions would be to keep using loading actions, but
dispatch a lastAccess event before performing a metadata update. This
would have worked, but would result in two lastAccess events being
dispatched for each navigation event instead of just one.
We only instrument onCreate because it's the only one with an
implementation.
While declaring this as a function that accepts a lambda is less
fragile, we've previously had issues with it such as suspected memory
leaks when used for telemetry. Therefore, we go with the simpler
approach.
This is a bug we noticed after landing search term grouping.
An adapter can submit an empty list of items to the `ConcatAdapter`
early. This has the side-effect of triggering our `observeFirstInsert`
too soon and therefore updating the visibility to show the empty tray
placeholder and never switches back.
Our solution is to keep a constant observer on the adapter so we can
perform the visibility check on every insert/remove.
Co-authored-by: Roger Yang <royang@mozilla.com>
* For #21236: Separate tabs with the same search term into a different section in tabs tray
* Issue #21236: Scroll to selected tab + various tab fixes for groupings
* Issue #21236: Fix failing test
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>
* [WIP] New Layout for adding login and 'add login' button in 'SavedLoginsListView' to launch it.
Fixed bindings.
* [WIP] Removed "reveal password" button
* [WIP] Added interactor for the add login screen
* [WIP] Trying to check for duplicates
* [WIP] Renaming "addNew..." with "add..."
* [WIP] Check for duplicates
* [WIP] Fixes after merge
* Cleaning up the layout and making edit text for hostname selectable
* Error handling on add login screen. Tests for interactors and controllers
Co-authored-by: Vitaly V. Pinchuk <vetal.978@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Issue mozilla-mobile#21140 - Updated recent tab logic to show media tab and second-to-last tab, if the media tab was the last active tab.
* Fixed RecentTabsListFeatureTest unit test
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Update Android Components version to 93.0.20210901143120.
* For #21043 - Integrate AC changes
* Fix breaking API changes of RestoreAction
Co-authored-by: Mugurell <Mugurell@users.noreply.github.com>
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
* Add telemetry probes for recent bookmarks on home screen. Tests for controller.
* Make the events into counters in the metrics ping
Update tests to reflect new metrics
Add data review link for new metrics
Mock new settings for startup metrics tests
Update metrics
Add test for recent bookmark glean events
* Recent bookmarks controller tests
Two new events are added:
- "inactive_tabs_expanded" for when the inactive tabs section is expanded
- "inactive_tabs_collapsed" for when the inactive tabs section is collapsed
For tracking when an inactive tab is opened / closed I've repurposed the
existing tabs tray telemetry (since the functionality uses the same code)
- tabs_tray.opened_existing_tab
- tabs_tray.closed_existing_tab
to support an extra "source" key indicating the feature from which a tab was
opened or closed. The current values for this new key are:
- "Tabs tray" for when a tab was opened/closed from tabs tray
- "Inactive tabs" for when a tab was openes/closed from the Inactive tabs
section of the tabs tray.
This means no code will be generated by Kotlin Android Extensions for caching
views and also for @Parcelize annotated classes.
As recommended in the official documentation
https://developer.android.com/topic/libraries/view-binding/migration#gradle
we need to switch on using `kotlinx.parcelize.Parcelize` instead of
`import kotlinx.android.parcel.Parcelize`
For #17917 - Remove the `kotlin-android-extensions` plugin
This means no code will be generated by Kotlin Android Extensions for caching
views and also for @Parcelize annotated classes.
As recommended in the official documentation
https://developer.android.com/topic/libraries/view-binding/migration#gradle
we need to switch on using `kotlinx.parcelize.Parcelize` instead of
`import kotlinx.android.parcel.Parcelize`
This ensures that we do not attempt places initialization before
Megazord.init() finishes, and that touching BrowserStore does not
kick-off places initialization (due to the `cleanup` call being a
side-effect of creating metadata middleware, used as part of the
BrowserStore).
Glean initialization happens before initialize megazord, and it touches
core.store BrowserStore instance, kicking-off places initialization on
an IO thread (due to the cleanup call), which raced megazord
initialization on the main thread.
App init sequence is a bit of a mine-field, so this patch takes the easy
way out and doesn't attempt to re-order initialization sequence. Also,
initializing places as a side-effect of touching BrowserStore was also,
clearly, a bug.
This allows recording part of history metadata to ride the trains.
The UI features are still guarded by the secret settings flag (or,
enabled on debug builds).
The bug here was that we'd try to record `now - 0` as a viewTime delta.
This isn't just an obviously wrong value to record, but it will also
overflow our storage - we'll end up with a value on disk that doesn't
fit into an i32, but HistoryMetadata.total_view_time is i32 in our Rust
struct. Once that happens, reads that touch this bad row will result in
an overflow and a crash.
* Navigate to home on toolbar click. Handle back press from search dialog
Update tests to show home behind search dialog. Remove unused test.
Jump back in show all button is clickable behind search dialog
Recently saved bookmarks show all button is clickable behind search dialog
* Add feature flag
* Past explorations show all button is clickable behind search dialog
Handle keyboard in controllers instead of viewholders. Update tests.
Allow collections to be visible behind search dialog
Dismiss keyboard and search dialog with navigateUp instead of just dismissing the keyboard
Verify navigateUp in tests
Adding ignore for flaky UI test
Only resize home behind search dialog
Add ignore for collection intermittent test
Cleanup
This differs from `tab_view_setting` which tells us what the user's tab
setting is at startup. It does not tell us if the user explicitly
changed it instead of just using the default (which was recently
changed in #19809).
We use make the inactive tabs section of the tabstray collapsible in
this change, with a technical quirk: we want to make the "isExpanded"
state of the tabs stay for the lifetime of the app and not the tabs
tray, but this functionality does not exist.
In this patch, we're storing the UI state in a singleton class that
exists for the lifetime of the app, but a more concrete solution is to
use an AppStore that holds content like this, which we can land in a
future patch.
* Remove references to preferences.open_links_in_private and preferences.private_search_suggestions in tests. These metrics have been expired and may be removed.
* Add ignores for performance metrics that have expired.
* Remove tabs_tray.cfr.dismiss and tabs_tray.cfr.go_to_settings telemetry probes.
* Remove metrics controller from signature and remove in tests
To remove the flash on refresh of the topsites list we have to use submitList, however using this too high up in the hierarchy of our listAdapters within listAdapters will cause children to refresh at once. The solution to this is to use submitList lower. Using it in TopSitesPagerAdapter.kt to update the TopSitesAdapter is the way to go. I've also had to use a dummy item for the "removed" Topsite ( with id = -1) so I can manually diff that before using submitList.
The reducer in this middleware assumes the SessionState is always a
TabSessionState which holds the lastMediaAccess. This is true for the
lastAccess long which is a persistent state.
The list of MediaSessionActions however can also come from Custom Tabs
which relies on a CustomTabSessionState.
For now, the temporary fix is to disable this feature by removing the
middleware and no longer adding the last accessed media to the
recent tabs list ("Jump back in") to avoid crashing users while we think
of a real fix.
The change to the function makes it so when the Settings.kt class is initialized, the isDefaultBrowser, which calls the
BrowserCache, won't get called right away. `isDefaultBrowser()` is known to take quite a while on start up on the G5+ (approx
30-40ms).
Apparently, it had been using the wrong mapping this whole time. I can't
wrap my head around fenix's glean wrapper so I'm not sure if this
resulted in bugs or if my change changes the behavior. However, I don't
think anyone is using this probe so I'm requesting to remove it. If we
don't end up removing it, then we can check for bugs/changes in
behavior. This isn't ideal but I'd rather not spend the time on it if we
don't have to.
* Title and button for home screen recently saved bookmarks section
Create bookmark item view with favicon and title
* View holders and interactors for recently saved bookmarks
Recent bookmark item view holder binding
Create adapter for recent bookmarks. Implement controller methods. Implement view holder bindings for items
Top level adapter for recent bookmarks section
Retrieve list of recent bookmarks on home
View holders and interactors for recently saved bookmarks
Recent bookmark item view holder binding
Create adapter for recent bookmarks. Implement controller methods. Implement view holder bindings for items
Top level adapter for recent bookmarks section
Retrieve list of recent bookmarks on home
Update list on app start and when bookmarks are added
View holders and interactors for recently saved bookmarks
Recent bookmark item view holder binding
Create adapter for recent bookmarks. Implement controller methods. Implement view holder bindings for items
Top level adapter for recent bookmarks section
Retrieve list of recent bookmarks on home
Update list on app start and when bookmarks are added
Make a use case for retrieving and updating the list of recently saved bookmarks
Add adapter items and define header viewholder binding
Use session interactor for header button clicks. Bind in the adapter
* Retrieve list of bookmarks asynchronously on home
Interactor and controller tests
Address review comments
Split up tests for recent bookmarks
Update to new interactors
Dark mode and light mode styles
Refactor bookmarks home stuff
* Add RecentBookmarksFeature to home
Move interactor to SessionControlInteractor
Clean up lint, styles, and dimens.
* Bookmarks use case tests for retrieving recently saved bookmarks. Linting.
* View holder tests
* Match ux to designs for colors, margins, and scrolling
* Clean up clean up
* Tests for the view bound feature
* Controller test
* Clean up: check state of store in feature tests; ellipsize textviews for bookmark item; remove unused attr; format
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>
This adds a toggle/switch to the debug settings menu that causes Nimbus to use the "preview" collection rather than the "main" collection when it initializes. Since it is only applied during init, it does require a restart in order to take effect.