RFC: Use GeckoView reported scroll distances for dynamic app features

[Mugurell]

Proposing a better collaboration between GeckoView and the apps having GeckoView informing apps about the distance a webpage is scrolled. Optionally collaborating with other app features by handing off the scroll distance for the parent / siblings to consume first.

  RFC doc - https://github.com/mozilla-mobile/android-components/blob/0ae1fbfe22ff0bcb1e2f77b1f23ad39ddc0da280/docs/rfcs/0009-geckoview-dynamic-features.md

Prior discussions - https://github.com/mozilla-mobile/android-components/issues/10585

 

---

The code commits show how easy we could then use that data to integrate a dynamic toolbar or pull to refresh in the app. (Currently just a proof of concept using scroll data straight from Android. Later for GeckoView to inform about the actual distances).

Dynamic toolbar composable	Pull to refresh composable

Pull Request checklist

• [ ] Quality: This PR builds and passes detekt/ktlint checks (A pre-push hook is recommended)
• [ ] Tests: This PR includes thorough tests or an explanation of why it does not
• [ ] Changelog: This PR includes a changelog entry or does not need one
• [ ] Accessibility: The code in this PR follows accessibility best practices or does not include any user facing features

After merge

• Milestone: Make sure issues closed by this pull request are added to the milestone of the version currently in development.
• Breaking Changes: If this is a breaking change, please push a draft PR on Reference Browser to address the breaking issues.

[Mugurell]

Having looked more at this I think the cooperative nature of the NestedScrollingChild Android contract will pose significant challenges but I’m fairly sure we can avoid that for at least v1 and have GeckoView just report the distance it scrolled, after scrolling.

Otherwise the normal flow would be:

• onTouchEvent(ev: MotionEvent) is called for GeckoView. This is where it would need to infer everything about the MotionEvent and call the below dispatch methods.
• dispatchNestedPreScroll is called first on itself to first inform the parent about a scroll starting and allowing it to react first.
  • onNestedPreScroll is called in the parent which can consume any scroll distance and report about this.
  • GeckoView can then consume any scroll distance left unconsumed by the parent.
• dispatchNestedScroll is called then on itself for Geckoview to consume any scroll in progress and then inform the parent.
  • onNestedScroll is called in the parent which can consume any remaining scroll distance GeckoView didn't consume

And the same ceremony would be duplicated for fling events with similar callbacks.

[Mugurell]

Tried looking at how Chrome handles this scenarios and while not having a complete pictyure it seems that:

• the dynamic toolbar seems to function similar to Fennec's toolbar - a platform View that is screenshotted when needed to be animated. (The bottom toolbar expressly states this).

• pull to refresh (and overscroll effects) seemed to have been migrated from the compositor-based approach to the platform library based implementations in this PR with the functionality receiving the scroll distance to consume.

[gabrielluong]

Hey @Mugurell This project moved to a new repository. It is now developed and maintained at: https://github.com/mozilla-mobile/firefox-android