Closed Bug 1990215 Opened 10 months ago Closed 8 months ago

[composable toolbar] Surface scroll data from GeckoView

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

Details

(Whiteboard: [fxdroid][group3])

Attachments

(1 file)

In order to sync the dynamic toolbar movement with webpage scrolling we need to surface the GeckoSession.CompositorScrollDelegate data to Android-Components.

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. BrowserState is 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 BrowserStore middlewares + 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 through ReaderState.

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?

Flags: needinfo?(botond)
Depends on: 1990617

(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 CompositorScrollDelegate is 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!

Flags: needinfo?(botond)

(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.

Whiteboard: [fxdroid][group3]
Pushed by plingurar@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/ec94943015fd https://hg.mozilla.org/integration/autoland/rev/d718216397d5 Surface scroll data and scroll deltas from APZ to AC's EngineView r=android-reviewers,ohall,jonalmeida,skhan,m_kato
Status: ASSIGNED → RESOLVED
Closed: 8 months 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: