[composable toolbar] Surface scroll data from GeckoView
Categories
(Firefox for Android :: Toolbar, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox147 | --- | fixed |
People
(Reporter: petru, Assigned: petru)
References
Details
(Whiteboard: [fxdroid][group3])
Attachments
(1 file)
|
Bug 1990215 - Surface scroll data and scroll deltas from APZ to AC's EngineView r=#android-reviewers
48 bytes,
text/x-phabricator-request
|
Details | Review |
In order to sync the dynamic toolbar movement with webpage scrolling we need to surface the GeckoSession.CompositorScrollDelegate data to Android-Components.
| Assignee | ||
Comment 1•10 months ago
|
||
Prior similar work was done for supporting properly placing the reader mode content - bug 1820404 / 1535 GH PR which added the GeckoSession scroll data to ReaderState.
I would prefer to not go through our BrowserState but rather expose a StateFlow from the EngineView which already exposes scroll related data.
Advantages:
- avoid spurious updates when the page is scrolled.
BrowserStateis already a very big object updated and observed from multiple places so the scroll updates would just add more pressure. - avoid delays from our MVI model which would have the scroll updates go through the entire list of
BrowserStoremiddlewares + reducer to then be observed by the toolbar code.
In my tests this would take 1ms from receiving the APZ callback to using this data where we need it vs ~4ms I observe for the scroll data we currently use throughReaderState.
Disadvantages:
- missing previous scroll data when going back to or restoring a tab (if we'd persist the scroll information together with other data from
BrowserState)
@Botond Would you think it's possible to have APZ send the current scroll position whenever a new CompositorScrollDelegate is registered - probably through the same callback just to ensure we have the baseline without needing to persist this for each tab?
Comment 2•10 months ago
|
||
(In reply to Petru-Mugurel Lingurar [:petru] from comment #1)
@Botond Would you think it's possible to have APZ send the current scroll position whenever a new
CompositorScrollDelegateis registered - probably through the same callback just to ensure we have the baseline without needing to persist this for each tab?
That should be doable, yeah. I filed bug 1990617 about it.
Let me know to what extent this is blocking your work, and I will prioritize it accordingly. Thanks!
| Assignee | ||
Comment 3•10 months ago
|
||
(In reply to Botond Ballo [:botond] from comment #2)
That should be doable, yeah. I filed bug 1990617 about it.
Let me know to what extent this is blocking your work, and I will prioritize it accordingly. Thanks!
That's great, thank you!
I can just account for that and move on but we'd need this before using the new behaviour in official releases - in a few weeks.
| Assignee | ||
Comment 4•10 months ago
|
||
| Assignee | ||
Updated•10 months ago
|
| Assignee | ||
Updated•10 months ago
|
Comment 6•8 months ago
|
||
| bugherder | ||
Description
•