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>
It was previously just waiting for the application to be idle, which
is not a reliable check in case the navigation to home is triggered
on completion of an async operation i.e., the app / main thread may
be idle, but the navigation to home hasn't completed yet.
goToHomeScreen further needs to wait for the browser fragment's
home button to exist before clicking it.
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.
* New undoDeleteBookmarkFolderTest smoke UI test
* Improve coverage for deleteNonEmptyBookmarkFolderTest UI smoke test
Co-authored-by: AndiAJ <andiaj@users.noreply.github.com>
* For https://github.com/mozilla-mobile/fenix/issues/22534 - Update homescreen section name to "Recently visited"
* For https://github.com/mozilla-mobile/fenix/issues/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 https://github.com/mozilla-mobile/fenix/issues/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 https://github.com/mozilla-mobile/fenix/issues/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>
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.
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.
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.
