Closed Bug 1991654 Opened 1 month ago Closed 4 days ago

Use scroll data from GeckoView for animating toolbar

Categories

(Firefox for Android :: Toolbar, task, P2)

All
Android
task

Tracking

()

RESOLVED FIXED
147 Branch
Tracking Status
firefox147 --- fixed

People

(Reporter: petru, Assigned: petru)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxdroid][group3])

Attachments

(4 files)

This should use the data bug 1990215 makes available to animate the bottom toolbar.
Special care is needed to also snap the toolbar to expanded or collapsed when the scroll ends to avoid leaving the toolbar shown in half.

Whiteboard: [fxdroid][group3]

@Botond Seems like the implementation in Fenix is easier than first thought and I already got a quick POC.
Seeing though a scenario that should probably be avoided in reporting scroll updates: the webpage being zoomed in/out.
Currently we infer such gestures and avoid scrolling the toolbar, seems like Chrome is doing the same (or was, their dynamic toolbar seems broken in recent releases).
I think this information is available to APZ so could it be used to avoid sending scroll updates when the page actually being zoomed in/out?

Flags: needinfo?(botond)

(In reply to Petru-Mugurel Lingurar [:petru] from comment #1)

@Botond Seems like the implementation in Fenix is easier than first thought and I already got a quick POC.

Nice!

Seeing though a scenario that should probably be avoided in reporting scroll updates: the webpage being zoomed in/out.
Currently we infer such gestures and avoid scrolling the toolbar, seems like Chrome is doing the same (or was, their dynamic toolbar seems broken in recent releases).
I think this information is available to APZ so could it be used to avoid sending scroll updates when the page actually being zoomed in/out?

Since the object passed as argument to the CompositorScrollDelegate, ScrollPositionUpdate, already has a zoom field, could the consumer of the delegate already accomplish this by checking whether the zoom has changed since the last update, and not moving the toolbar in response to the update in that case?

Flags: needinfo?(botond)
Flags: needinfo?(petru)

The plan is to use the previous name - EngineViewScrollingBehavior for the supertype
of this and also of a new behavior using the scroll data for animating the toolbar.

This will allow to easily switch between the current way of scrolling
the dynamic toolbar and the new one based on APZ scrolling data.

This will animate the bottom toolbar based on scroll data
exposed by GeckoView instead of inferring the scroll distances
based on intercepted MotionEvents.
As a result the dynamic toolbar will be always kept in sync
with the engine view being scrolled.

(In reply to Botond Ballo [:botond] from comment #2)

Since the object passed as argument to the CompositorScrollDelegate, ScrollPositionUpdate, already has a zoom field, could the consumer of the delegate already accomplish this by checking whether the zoom has changed since the last update, and not moving the toolbar in response to the update in that case?

Thank you!
Works better than I expected 😅.

Flags: needinfo?(petru)
Pushed by plingurar@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/06b4ab52c3eb https://hg.mozilla.org/integration/autoland/rev/1a76a2775d56 part 1 - Rename current scrolling behavior to EngineViewScrollingGesturesBehavior r=android-reviewers,skhan https://github.com/mozilla-firefox/firefox/commit/ad7bf747a5d4 https://hg.mozilla.org/integration/autoland/rev/9ce957c40272 part 2 - Use a generic EngineViewScrollingBehavior r=android-reviewers,Roger https://github.com/mozilla-firefox/firefox/commit/a13db57fbf6f https://hg.mozilla.org/integration/autoland/rev/a7417af900ff part 3 - Use new EngineViewScrollingDataBehavior r=android-reviewers,Roger
Status: ASSIGNED → RESOLVED
Closed: 4 days ago
Resolution: --- → FIXED
Target Milestone: --- → 147 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: