These are mostly mechanical changes to replace usage of `testHasValue`
with `testGetValue`.
`testGetValue` will now return `null` instead of throwing an exception
if no data is available.
This avoids having to pass another LifecycleOwner from outside and will ensure
the View is update only in the bounds of it being attached.
The observe-update code is moved to bind(..) as that seems like a more
idiomatic callback for updating an already constructed View rather than
createView() which should only create and return a View.
This change mitigates it being set only once in FenixApplication and then
being reset after the first ping is sent.
By having "application" lifetime once set in FenixApplication will be available
in all future contile pings for that application run.
It's easier to modify the explanation of the heuristics in code comments
rather than command line strings so I moved the failure explanations
into code comments, allowing me to simplify the test failure error messages.
We want this test to be self service for the fenix team so the meaning
of the documentation was updated. Additionally, we clarified why each
heuristic exists to make the test more accessible to self service.
* For #25397 - Telemetry for credit card save and update
* Use Fenix Issue fro Bugs
Co-authored-by: Gabriel Luong <gabriel.luong@gmail.com>
Co-authored-by: Roger Yang <royang@mozilla.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
When the search event is from the search widget while PIP is active, the search fragment opens after the screen is unlocked. This avoids the issue of the search page opening in landscape mode and also the app doesn't crash.
Co-Authored-By: Mugurell <Mugurell@users.noreply.github.com>
Co-authored-by: indu <indu@ramkystech.com>
This fixes the following two scenarios resulting in improper recordings:
- sponsored stories were recorded as shown as part of the impressions recording
for all the stories (both recommended and sponsored). Separated the two.
- sponsored stories were not recorded as shown if the user doesn't scroll.
This could happen if just toggling categories which would result in a new list
of stories to show. Will recheck after the time to settle if the composable is
shown.
The toolbar may appear over the Pocket stories causing our functionality for
reporting when a specific story is visible to misreport.
At the moment hardcoding the toolbar height in the visibility checks seems like
the best solution to ensure reliable data.
A new way to be able to reliably record actual impressions of sponsored stories
was needed and based on this data we can ensure we are promoting fresh stories
(with fewer impressions) or the ones with a higher priority.
The design asks for a new row in between the primary and the secondary text so
I went with making "ListItemTabSurface" public allowing for customizing the
content it will show but keeping the same layout and general UX.
PocketStoriesChange was called only once - to clean the shown stories when the
user gets to the homescreen and the Pocket feature is disabled - useful for the
situations in which the user returns after disabling the feature in settings.
Populating the store with recommended stories to show was already happening
based on 'PocketStoriesCategoriesChange' and sponsored stories will be added by
using 'PocketSponsoredStoriesChange' so renaming 'PocketStoriesChange' will
help on reducing any confusion in the future.
Also added documentation for all Pocket related actions from AppStore and
removed the 'UndocumentedPublicClass' detekt suppressions.
The default was already 8. This is now being moved closer to the source from
where the stories to be shown are emitted.
With the addition of sponsored stories at fixed positions having to support a
variable number of stories being returned from AppState#getFilteredStories
means increased complexity with no benefit.
