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.
This is a speculative fix for the intermittent issue. Typically, these
intermittents are caused by mocked lambdas but there is no mocked lambda
here. If this doesn't work, one `any()` argument fills in for a lambda:
it's possible that's causing the failure.
Unfortunately, I can't verify this fix easily because the "run test until
failure" option was removed from Android Studio.
See b3f5c87585 for a prior attempt to
address the intermittents in this class.
This is a bug we noticed after landing search term grouping.
An adapter can submit an empty list of items to the `ConcatAdapter`
early. This has the side-effect of triggering our `observeFirstInsert`
too soon and therefore updating the visibility to show the empty tray
placeholder and never switches back.
Our solution is to keep a constant observer on the adapter so we can
perform the visibility check on every insert/remove.
Co-authored-by: Roger Yang <royang@mozilla.com>
* For #21236: Separate tabs with the same search term into a different section in tabs tray
* Issue #21236: Scroll to selected tab + various tab fixes for groupings
* Issue #21236: Fix failing test
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>
The test as it exists relies on the robolectric lifecycle, which is hard
to predict, so it doesn't seem worth fixing the test. Writing the test
any other way would require excessive mocking, which also seems
impractical.
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-mobile#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 #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.
AndiAJ
Mozilla L10n Automation Bot
Gabriel Luong
Arturo Mejia
Oana Horvath
Travis Long
Aaron Train
Sebastian Kaspari
Michael Comella
rayanHappy
Christian Sadilek
Elise Richards
Grisha Kruglov
Jonathan Almeida
Roger Yang
rxu
Mugurell
Jan-Erik Rediger
Rohan Maity
bendk
Noah Bond
mcarare
Noah Bond
czlucius
Mickey Moz
codrut.topliceanu