We've noticed that geckoview_example is ~300ms faster than fenix in cold page
load tests on arewefastyet for the Pixel 2. We suspect the main
difference is because geckoview_example runs with conditioned profiles
and fenix does not.
This PR is foremost an experiment to see if that's true because, after bug
1587542, we cannot run get results for fenix perftest PRs (i.e. it needs to be
merged into main). If we find that the results are not noisy, however, we
could end up leaving this in the tree. We've previously seen excessive
noise with fenix start up tests with conditioned profiles which is why
conditioned profiles are not currently enabled.
The Glean core native code is now shipped through GeckoView directly
(through its `-omni` packages).
For local tests we need a library matching the host-platform, which is
available in the glean-native package.
* [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.
