Setting max width for the search view in language settings and saved logins screens. Removed SyncAuthClosed event from LocaleSettingsFragment, an apparent copy-paste.
This introduces a separate HistoryDB type at the PagedHistoryProvider
layer, that doesn't need to deal with positions. Positioning logic in
HistoryDataSource becomes a type conversion between the new type and an
existing History type that UI and ItemKeyedDataSource API is written against.
With this refactor, we entirely eliminate nullability from these types.
We were converting Long timestamps into Ints (and getting negative
numbers back), and treating that as, basically, a position for the
paging API; the paging API would pass us back the obscure negative
number back as an offset, and we'll mishandle it resulting in an
infinite loop.
This patch removes all of the Long -> Int conversions, and introduces an
explicit 'position' that is calculated once we have a full page of
results completed.
Compose enforces a DropdownMenuItem having at least a 64dp height
(48 dp height + 8dp vertical padding) so we need to ensure the parent
doesn't hardcode a smaller height.
We re-use the same ViewHolders in search term groups, so when we need to
cast to a AbstractBrowserTrayList for tab reordering, we need to check
our parent correctly first.
* Adds basic support for tab reordering via drag-and-drop selected tabs
* ktlint/detekt formatting
* Use defaultTabsFilter (now not private) instead of getter
* Convert from position+filter API to target+placeAfter
Unfortunately I still need the filter passed around a bit
* Handle inactive tabs' holder being children of the RecyclerView of the normal tabs
Don't go through LayoutManager needlessly
* Non-working use tabID the whole way. Does not compile.
* Fix to do direct tab ID and use grid setting directly
* Remove non-null assertion. Now fully works for "other" tabs.
* Prevent grouped tabs from being dragged
* Remove unused import
* Add/fix comments
* Do API version check and use deprecated startDrag if too old.
* Build process fails: both outdated and too new, so reverting to just too new
* Use deprecated function and suppress warning
* fix space
* Suppress "TooManyFunctions" on DefaultTabsTrayController
* Repeatedly update tab movement during drag
* Remove multi-tab movement, only allow dragging if tab groups disabled, fix tab positioning during movement
I'm forced to suppress LongParameterList to get the settings information where it needs to go though
* Remove settings argument and corresponding long args suppression: instead get settings from parent AbstractBrowserTrayList's context
* New UI: Select a tab and then, while holding down, start dragging
* Revert to using before/after boolean to accomodate delays
Move drag transparency to start of drag
* Use new BlankDragShadowBuilder and DraggableItemAnimator to handle tab movement
* Replace Pair<>s with data classes
* Only drag if exactly 1 tab selected, don't consume drag event if not used
* Auto-scroll tab tray while dragging near top/bottom edge
* Remove unexpected scrolling on tab bind (triggered when tab is selected)
* Fix broken scroll behavior during dragging
* Cleanup for ktlint/detekt
* Constantly set elevation during drag in case of update
Clean code at drag start
* Add custom drag start behavior
* Add drag distance constant, do all touch-drag behavior in OnTouchListener
* Disable parent vertical scrolling on drag start, fix detekt ComplexCondition
* Minor cleanup/comments
* Revert removal of scroll on bind, this was related to something different
* Correction to prepareForDrop to match documentation- doesn't seem to have any effect
* Simplify via unchecked typecast, use ViewCompat
* Use ViewConfiguration.scaledTouchSlop instead of arbitrary 30px
* Added tabReorderingFeature flag, split drag interactor to separate function to satisfy complexity requirement
Co-authored-by: Steven Knipe <ssk97@case.edu>
Co-authored-by: ssk97 <knipesteven@gmail.com>
Co-authored-by: Sebastian Kaspari <s.kaspari@gmail.com>
One important issue was that the items are smaller that the width of the
screen and so a bit of the next column would be showing also and user could
interact with this only peaking items and a long press would open a dropdown
menu with no place to anchor it.
To mitigate this:
- the items will now snap to the next position when scrolling so that we'll
always show at least one column in it's entirety.
- menus are enabled only if more than half of the item is visible effectively
disabling clicks on that peaking area of neighbour columns.
This patch also updates the divider for history groups which previously wasn't
showing.
* For #22516 - Fixed show all button alignment with section headers on the Homepage
* For #22516 - Added correct content description back in for recently visited show all button
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* For #22534 - Update homescreen section name to "Recently visited"
* For #22534 - Show both history highlights and groups in Recently visited
For now the metadata groups don't support scoring so as an interim solution we
will show up to 9 items, evenly distributes, first favoring groups sorted by
date then history highlights pre-sorted by default.
Tapping a history highlight will switch to it's already open tab if available
or create a new one in which to load it if needed.
A "Remove" option will also be available for history highlights to remove it
from the screen and also from history.
Currently removing a group / highlight will not query new ones to again show up
to 9 items, this will be implemented separately.
* For #22534 - Rename and refactor historymetadata to recentvisits
The updated feature supports more than history metadata so updating the overall
naming scheme seems needed.
To signal that this is a homescreen feature the entire package is moved to home
* For #22534 - Update UI tests to account for the new items space on the screen
Saw failures about not finding the collection section on screen.
This is probably happening because w are now adding the recent visits to
homescreen above the collections section pushing it off screen.
Since the collections might be obstructed by the toolbar shown on top as a
quick solution we'll scroll to the next homescreen section so that the
collections will be shown above in their entirety.
* Update app/src/main/java/org/mozilla/fenix/home/recentvisits/RecentVisitsFeature.kt
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
* Update app/src/main/java/org/mozilla/fenix/home/recentvisits/RecentVisitsFeature.kt
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
Co-authored-by: Gabriel Luong <gabriel.luong@gmail.com>
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* For #22410 - Refactored tab sorter metrics into a middleware
* For #22410 - Created distribution metric for tab group sizes
* For #22410 - Created tests for tabs tray middleware
* For #22410 - Merge fixes
* For #22410 - Added PR number to metric
* For #22410 - Fixed unit tests post merge. Added waitUntilIdle to new tests.
* For #22410 - Added missing line to middleware to have the Store process actions
* For #22410 - Updated metric expiration to December
* For #22410 - PR Feedback
* For #22410 - Removed else from middleware when
This is needed to prevent removed search groups from coming back after
user interacts with the tab. E.g. if we don't fire this action, upon
interaction with the tab after a corresponding search group was removed
we will end up creating metadat with the deleted 'searchTerms' (they'll
be read from the 'historyMetadata' state on the tab).
At this point we probably want to start encapsulating all of this in a
use case - let's do that separately in
https://github.com/mozilla-mobile/android-components/issues/11309, and
just fix the bug for now.
This patch fixes two problems:
1) We were treating "direct tab load" as an event which applies
uniformally to all tabs, even though it's actually an event which
happens for a specific tab. This lead to background tabs (pages opened as new tab)
setting the direct load flag, and then a simultaneously loading
parent tab would incorrectly interpret that flag for itself.
The patch switches this tracking from a simple boolean (are we direct
loading?) to a set of tab IDs that are currently direct loading.
2) In a case when a background tab was loading with a parent who's
search terms were cleared by a direct load, we were not trying to
lookup search terms on the background tab's historyMetadata key,
which exists to capture search terms for this exact scenario.
The patch adds an additional fallback lookup for that path.
This moves the group removal logic to the place where the groups are
actually formed. This helps clean-up the fragment code a bit, and
removes the awkward 'allow mutate some random internal state' API from
the provider.
* For #22146 - Added counter for home screen views
* For #22146 - Added PR number to metrics
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Setting this value in FenixApplication.onCreate was buggy because of a race
with restoring BrowserState.
Setting it here would ensure a better granularity of the events and so to more
accurate reporting.
* For #22145 - Added telemetry to the opening screen preference.
* For #22145 - Added PR number to metric
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* For #22298 - Added telemetry to inactive tabs CFR
* For #22298 - added PR issue number to metrics
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
findLoginToUpdate() should be suspend, but I didn't get mark it that way
on the initial logins work. Let's make this one suspend, then I can
update findLoginToUpdate() in a-c.
This allows querying from all throughout the app which of the current tabs are
inactive while taking into consideration whether the feature is enabled or not
such that when the feature is disabled it will always return an empty result.
Changing the download file name length to the max allowed by AS (251 char, won’t compile if more; max would be 260 for latest windows versions, but generally it is 255), and changing the UI test to check if the long file name is fully visible.
Changing the downloaded dialog layout to properly display really long file names.
Our boundary conditions for matching search groups to visits was wrong.
This change switches the boundary buffer to only be applied to history
items, not the metadata items.
In other words, when checking if any of the metadata items match the
current "page" of history, we'll be looking to see if the item falls
within this time window:
buffer - oldest history item <= metadata item <= newest history item +
buffer
There's a separate problem with buffer though: it's reset to 0 when requested
offset is >0, but that requires a larger refactor of this code, for a
separate PR.
When you want to look at one of these markers, you usually want to look
at all three so I found that having them on a single track was easier to
follow. Since they run in sequence, they should never overlap and that
should minimize confusion.
* For #22075 - Added event to track the count of recent bookmarks
* For #22075 - Added data review issue number
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* For #22107 - Added probe to track if the Recent tabs / jump back in section is visible
* For #22107 - Fixed lint errors
* For #22107 - added data review number to metric
* For #22166 - fixed expiration date
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
A quantity probe in the metrics ping means we'll loose the granularity events
provided but it will be easier to extract the values.
For reporting whether the inactive tabs feature is enabled or not we already
have the "preferences.inactive_tabs_enabled" probe so I didn't duplicate this.
When deciding if we should include a history group within the "page of
history" results on the History View UI, we used to look at the most
recent timestamp of the metadata items within the group, and see if that
falls within the range of the timestamps of the history page, +/- some
buffer.
This assumes that each metadata entry will have a corresponding history
item. However, that's not true - when restarting the app, the selected
tab will be restored, and when opening History View right after we'll
record some metadata for it. However, we won't record a history visit
during the app restore for the selected tab.
That's all correct, but the assumption around group matching to history is now incorrect.
This patch changes the logic to instead look at every item within the
group, and see if any of them match the time window of the current
history page. This has a side-effect of also displaying search groups
multiple times on diffenent pages of history, if it makes sense to do so chronologically.
I think that's fine, it reflects reality at least (e.g. items within the
group may have been visited at very different points in time).
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
The onLayout marker may be redundant to onGlobalLayout marker but I'm not
sure yet so let's leave them both in and observe if that's the case.
Here's a profile with the markers: https://share.firefox.dev/3lZaOQb
Assuming the InlineAutocompleteEditText is not being recreated (and I
did not verify this), it's unnecessary to traverse the view hierarchy
to find it more than once so this patch removes the unnecessary
traversals.
* 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.
