Last ditch effort to prevent against crashes caused by ACTION_DOWN event being
null in GestureDetector.SimpleOnGestureListener#onScroll.
We can use the fact that the parameters are platform types and so can consider
the first parameter (that should be the ACTION_DOWN MotionEvent) being null so
that we won't automatically crash in such situations.
This will result in the toolbar not being animated as a result of a scroll
gesture by the user.
More investigations about why the ACTION_DOWN event is null are to be done in
android-components/issues/8552.
8357: For https://github.com/mozilla-mobile/android-components/issues/8356 - Speculative fix for BrowserGestureDetector IAE r=pocmo a=Mugurell
Try to resolve a situation in which system's GestureDetector calls us as a
callback with null parameters, so triggering an IllegalArgumentException.
A possible explanation could be that not all MotionEvents are passed to the
GestureDetector, situation which this patch tries to fix.
Co-authored-by: Mugurell <Mugurell@users.noreply.github.com>
Try to resolve a situation in which system's GestureDetector calls us as a
callback with null parameters, so triggering an IllegalArgumentException.
A possible explanation could be that not all MotionEvents are passed to the
GestureDetector, situation which this patch tries to fix.
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.
7610: Format mozac_browser_toolbar_displaytoolbar.xml r=pocmo a=gabrielluong
This fixes an unneeded indentation in `mozac_browser_toolbar_displaytoolbar.xml`
Co-authored-by: Gabriel Luong <gabriel.luong@gmail.com>
7102: Make sure the bottom toolbar is never stuck invisible r=Mugurell a=miDeb
Closes https://github.com/mozilla-mobile/android-components/issues/7101. This is my attempt to solve this issue. Essentially, if the user is scrolling upwards, but the toolbar is not being scrolled and not already showing or animating up, just forceExpand it.
Co-authored-by: Michael <michael.debertol@gmail.com>
Although the fields BrowserGestureDetector want to modify through reflection
should be a stable part of the Android framework it was seen that on some
devices they do not exist.
Nothing more we can do in these cases than just prevent the reflection
exceptions bubbling up and potentially crash client apps.
We'll now have a more in-depth understanding of user's gestures based on which
we can trigger different BrowserToolbar behaviors depending on if the user is
scrolling or zooming.
The ConstraintLayout parent will still inform us about when the scroll begins
and when the scroll ends but then actually incrementally updating the toolbar's
translation will be done in response to GestureDetector callbacks.
This also allows us to easily differentiate between horizontal and vertical
scrolls and only react for the latter.
If the user's gestures as inferred as zoom gestures (multi-finger scale or
quick-scale) the toolbar should not be animated.
This scenario is though affected by the fact that normally scroll gestures have
a much higher sensitivity (a 1 pixel movement is enough for a gesture to be
considered a scroll gesture) and so it is possible that even in the case of a
desired zoom gesture the scroll callbacks will be fired first.
When the gesture is identified as a zoom gesture we will immediately snap the
toolbar up/down but there might be a minor visual glitch because of this.
In an effort to reduce such races between scroll and zoom gestures I've lowered
the sensitivity of the ScaleDetector, this having the other effect that
multi-finger scrolls must now be more precise. Pinching while zooming will now
more often mean a zoom gesture and not animate the toolbar.
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.
