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.
* New undoDeleteBookmarkFolderTest smoke UI test
* Improve coverage for deleteNonEmptyBookmarkFolderTest UI smoke test
Co-authored-by: AndiAJ <andiaj@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>
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.
* 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
* 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>
This doesn't seem to be a high value test: increasing the view hierarchy
depth will only result in a performance problem on low end devices
if there is enough content on the new layer to cause the traversal to
take longer. It's more likely to result in a hard-to-workaround false
positive so we can remove it, like component init count.
This check doesn't seem high value because initializing a component
only indicates a performance problem if it's slow, which is not most
components, so it's likely to result in many false positives. To fix
the intermittent, we won't lose much if we remove it.
Compared with my local runs, CI sees +1 runBlockingIncrement calls so seems to
take other code paths. As such, we search for a range of rather than a single
value. The main downside I can think of is this could make the test trickier to
debug but we can wait and see if that's a problem in practice before taking
action on it.
This test wasn't running in CI
https://github.com/mozilla-mobile/fenix/issues/20386 so we changed the
CI configuration so that it will. However, the test was then failing so
this is the revision that unignores the test.
I wonder if componentInit count is useful - it seems like it'd cause
more false positives than not - but I figure we can leave it in and see
how it goes.
* 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
The changes from #19090 did not fix the issue consistently, and are
causing failures intermittently on-unrelated PRs.
Disabling these tests again until we have another fix for #19090.
Noah Bond
Oana Horvath
Christian Sadilek
mcarare
Brais Gabín
Aaron Train
Matt Tighe
Gabriel Luong
Andrei Joltan
AndiAJ
Mugurell
Roger Yang
Arturo Mejia
Grisha Kruglov
mike a
Noah Bond
Elise Richards
Sebastian Kaspari
Michael Comella
codrut.topliceanu
Jonathan Almeida