* [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>
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.
* Issue mozilla-mobilehttps://github.com/mozilla-mobile/fenix/issues/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>
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.
* Update Android Components version to 93.0.20210901143120.
* For https://github.com/mozilla-mobile/fenix/issues/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>
This is to investigate the intermittent mockk class
generation/loading issues. Since we can not reproduce
locally and the failures are intermittent they could
be caused by us running unit tests in parallel.
* 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 https://github.com/mozilla-mobile/fenix/issues/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.
For details on the root cause, see the commit. We replaced the similar
proguard rules because:
- the key line was returning false instead of true
- the other line had the same outcome as the written code. I believe it
was a micro-optimization. Since perf seems fine without it, let's
remove it
I benchmarked this change on COLD MAIN first frame. We see an
improvement of 89ms:
- before: 1346ms
- after: 1257ms
This test seems to be hacking at the binding between Fenix and the
BrowserToolbar to simulate toolbar events passing to the Fenix
interactor.
This is rather clumsy test that relies on the magic working of mockk
instead of following a general unit testing strategy that would commonly
require the class to be re-written to allow for better testing instead.
It is far safer to remove this test since we are not guaranteeing
anything in it and instead we see intermittent failures that make us
lose more time.
So therefore.. 🔥
The expectation is that replacing `return` with `answers` will compute
the return value for the extension function again in order to avoid the
error, "no answer found for: Settings".
Theoretically, this should marginally decrease the duration of our unit
test suite. In my testing, for 1 iteration each (i.e. noise is very
possible), the duration changed from 9m 32s to 8m 21s – a 71s
improvement.
---
To identify tests that were running with robolectric that didn't need to
be, I removed the @RunWith(FenixRobo... from all relevant files:
sed -i '' "/@RunWith(FenixRobolectric/d" app/src/test/**/*.kt
I ran the tests and discovered which ones failed from the Classes tab of
the index.html test result file. Something like:
tests = document.querySelectorAll('table')[3].querySelectorAll('tr');
failureElements = tests.querySelectorAll('.failures');
// TODO: extract the test names
Then I copied these results to a text file and compared them to all the
files that had robolectric test runners to figure out which ones still
pass:
comm -1 -2 failures.txt changed_files.txt > robolectric_not_needed.txt
And undid the changes to the failing files:
for i in $(cat robolectric_not_needed.txt); do git checkout $i; done
Then I removed the import statements on those files:
for i in $(cut changed_files.txt); do sed -i '' "/import.*RunWith/d" $i; done
for i in $(cat changed_files.txt); do sed -i '' "/import.*RobolectricTestRunner/d" $i; done
* 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
Arturo Mejia
Elise Richards
Mozilla L10n Automation Bot
Michael Comella
Noah Bond
Roger Yang
Christian Sadilek
czlucius
Mickey Moz
codrut.topliceanu
Gabriel Luong
AndiAJ
Oana Horvath
Sebastian Kaspari
Mugurell
Grisha Kruglov
mcarare
rxu
Rohan Maity
Jonathan Almeida
Aaron Train
Steven Knipe
Vitaly V. Pinchuk