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.
browser-menu v2: A new browser menu designed to work with lib-state.
This introduces a new API using immutable data classes to represent
options. Stateful functionality like the two-state button is replaced
with swapping out data classes and submitting a new list of options.
Internally this uses a recycler view and the view holders intentionally
do not map 1:1 to data classes. This way we can use different views
based on properties instead of introducing all new classes for every
combination of properties.
There are currently 3 Views interested in handling user's MotionEvents:
- GeckoView which renders web content
- SwipeRefreshLayout which handles pull down to refresh
- BrowserToolbar which can be dynamically hidden
Each of them have different behaviours based on different conditions so I
- removed the coupling of BrowserToolbar and Geckoview from `NestedGeckoView`.
It's `onTouchEventForResult` will now only set behaviour for GeckoView.
- created a new EngineView enum to expose the `PanZoomController` possible
result of how a specific user touch was handled to any components that have a
reference to an instance of EngineView without the need to have
`concept-engine` as a dependency.
- implemented specific behaviour in `SwipeRefreshFeature` for the pull down to
refresh functionality and in the `BrowserToolbarBottomBehavior` for the dynamic
navigation bar functionality.
Mapped PanZoomController's INPUT_RESULT to a new enum in order to not enforce
the need of including geckoview as a dependency in all components interested in
how a user's `MotionEvent` was handled and also because webview doesn't expose
such values so we needed a wrapper for it's handled or not boolean return.
At this point in the stack, we're not in control over what our
autocomplete providers are, what actions they'll do in order to
field our queries, etc. For example, some providers may hit the disk
and perform expensive DB queries internally. Some may even hit the
network, in theory!
In order to keep things perceptively speedy, let's run the actual work
off the main thread. This patch sets up a new pool thread to process
autocomplete requests. More than one thread is selected so that we maintain
liveliness during quick user input. Background tasks are cancelled as new
queries come in, and stale results are discarded.
