Use scroll data from GeckoView for animating toolbar
Categories
(Firefox for Android :: Toolbar, task, P2)
Tracking
()
| 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.
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Comment 1•1 month ago
|
||
@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?
Comment 2•1 month ago
|
||
(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?
Updated•1 month ago
|
| Assignee | ||
Comment 3•1 month ago
|
||
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.
| Assignee | ||
Comment 4•1 month ago
|
||
This will allow to easily switch between the current way of scrolling
the dynamic toolbar and the new one based on APZ scrolling data.
| Assignee | ||
Comment 5•1 month ago
|
||
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.
| Assignee | ||
Comment 6•1 month ago
|
||
(In reply to Botond Ballo [:botond] from comment #2)
Since the object passed as argument to the
CompositorScrollDelegate,ScrollPositionUpdate, already has azoomfield, could the consumer of the delegate already accomplish this by checking whether thezoomhas 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 😅.
Comment 8•4 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/1a76a2775d56
https://hg.mozilla.org/mozilla-central/rev/9ce957c40272
https://hg.mozilla.org/mozilla-central/rev/a7417af900ff
Description
•