Used `runTestOnMain` where `MainCoroutineRule` was used or needed to be used,
`runTest` elsewhere.
Extra effort for removing all `runBlocking` occurrences in unit tests.
`kotlinx.coroutines.test.runTest` is a test specific API that seems like a more
appropriate way for running tests in a coroutine than the general
`kotlinx.coroutines.runBlocking` api.
- Refactor out all usages of TestCoroutineDispatcher and TestCoroutineScope
- Refactor MainCoroutineRule to now use UnconfinedTestDispatcher by default.
This dispatcher will eagerly enter all launch or async blocks being more suited
to our codebase.
This also required updating room to >= 2.4.0.
This new version adds a deprecation of the `MigrationTestHelper` api used in
`LoginExceptionStorageTest` that is to be later fixed in https://github.com/mozilla-mobile/android-components/issues/11765.
`activity_compose` was also update to the latest stable version to ensure a
better match with the latest stable version for compose.
Used 1.6.10 for Kotlin although 1.6.20 is available to prevent any issues with
Compose 1.1.1 reported as an error at compile time:
"e: This version (1.1.1) of the Compose Compiler requires Kotlin version 1.6.10
but you appear to be using Kotlin version 1.6.20 which is not known to be
compatible. Please fix your configuration (or
`suppressKotlinVersionCompatibilityCheck` but don't say I didn't warn you!)."
This also required updating room to >= 2.4.0.
This new version adds a deprecation of the `MigrationTestHelper` api used in
`LoginExceptionStorageTest` that is to be later fixed in https://github.com/mozilla-mobile/android-components/issues/11765.
activity_compose was also update to the latest stable version to ensure a
better match with the latest stable version for compose.
These follow a few more simple patterns I was able to find:
- the testDispatcher is not used anywhere else: remove it
- the testDispatcher is used to set a main dispatcher: this is redundant
to the test rule so remove it both the dispatcher & the main dispatcher
- the testDispatcher is actually used elsewhere: for simplicity, change
the reference to point at the MainCoroutineRule.
Adds `showAddonsInMenu` in WebExtensionBrowserMenuBuilder to allow the option of removing `Add-ons`
item even if another extensions are displayed
Add unit tests to test if 'Add-ons' item visibility is updated properly
A BrowserMenuCompoundButton setup with compound drawables and used in our
BrowserMenu configured with a DynamicWidthRecyclerVIew will return a width
smaller with the size + padding of the compound drawables.
By replacing the default `inherit` layout direction for the initial onMeasure
we ensure the menu will also count the bounds of the compound drawables.
ExpandableLayout uses adapter based indexes to identify children.
In dynamic menus with list items being hidden this could lead to invalid
calculations and even to exceptions for indexes bigger that the then current
children count in the list.
To reconcile this we'll calculate a valid lastVisibleItemIndexWhenCollapsed and
stickyItemIndex to be used before the operations in calculateCollapsedHeight().
Because the code is now clearly tightly coupled to RecyclerView this patch also
refactors a previous general ViewGroup type to RecyclerView and because of this
part of the previous tests needed some adjustments.
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
ExpandableLayout needs to iterate through all items until the one set as the
limit of the collapsible menu and accumulate the distance.
It adds the items height and margins but also erroneously the padding.
Stop counting the padding if height is counted. Height contains any vertical
padding set.
If the menu starts as collapsed and it has a sticky footer set the bottom item
until which the menu should be collapsed must be shown on top of the sticky
item's view.
As an edgecase, if the same item is the limit of the collapsed menu and also
the sticky footer that will be the last item shown in the collapsed menu but
will be shown with full height.
The most important new responsibilities are to update the view of the sticky
item.
BrowserMenu's background is only set on the parent's layout so the Adapter will
have to set that same background to the sticky item's view such that other
items scrolling underneath it will be totally obscured.
Because the menu's background can be set in multiple ways (by setting a value
for mozac_browser_menu_background / by passing a MenuStyle or like in Fenix
having a default theme for all "above" views) BrowserMenu will offer a new
backgroundColor property that as the single source of truth for this which can
then be used by the Adapter.
Most of the menu items should support this new property and allow AC clients to
configure the menus such that a specific menu item will not be scrolled
off-screen but rather anchored to the top/bottom of the menu following where
the menu is anchored.
Vertical LinearLayoutManager configured with StickyItemPlacement such that:
- if StickyItemPlacement.TOP the sticky item will not be scrolled upwards
off-screen
- if StickyItemPlacement.TOP the sticky item will not be scrolled downwards
off-screen
Refactored the code so that touches/scrolls are still swallowed while the
menu is expanding after which ExpandableLayout should let all MotionEvents
pass through to be handled by menu items children.
