1916010 - Implement a ScrollDelegate-like API for driving dynamic toolbar movement

Status: NEW

(Core :: Panning and Zooming, task, P2)

Description

[Botond Ballo [:botond]]

As discussed during MozWeek, we'd like to transition the Fenix code for triggering dynamic toolbar movement from using the InputResultDetail API to using a new API.

The new API will be similar to ScrollDelegate but with the following differences:

• In addition to reporting the root scroll position, the API will need to report some auxiliary information. The exact details are to be determined, but early conversations with Markus suggest the API will need to report the start and stop of touch gestures.
• Unlike ScrollDelegate, the API should only report scrolling triggered by the user, not scrolling triggered by script on the site.
• Unlike ScrollDelegate, the API should send the information directly to the parent process, without a round trip to the content process.

This bug tracks implementing the described API.

Comment 1

[Petru-Mugurel Lingurar [:petru]]

I'm curious about the scenarios where we'd need auxiliary information.
This would mean complexity that I would hope to avoid.

Comment 2

[Markus Stange [:mstange]]

The only auxiliary information that I had in mind would be a boolean saying "Is the finger currently touching the screen", so that Fenix can ignore programmatic scrolls caused by the website JS. But Fenix could also track that state by looking at touch events itself.
It would be perfectly fine to implement this API with no auxiliary information. If we think we need more information, we can always add it later.

Comment 3

[Markus Stange [:mstange]]

Oh, I see now that comment 0 says that we'd simply skip reporting programmatic scrolls altogether in this API. That works too.

Comment 4

[Markus Stange [:mstange]]

Actually, I don't think that would work - for determining how much of the toolbar to reveal, Fenix will want to compare the current scroll position to what the scroll position was at the beginning of the gesture. So Fenix needs to know what the scroll position was at the beginning of the gesture. If the scroll position has changed between two gestures (e.g. due to programmatic scrolling), how would we get an accurate initial value, if we weren't notified of those between-gesture changes?

Comment 5

[Petru-Mugurel Lingurar [:petru]]

Thanks, that makes sense.
In my initial POC I was using a simple wrapper over previous/current scroll data (see runningHistory) but that can result in glitches in the case of interlaced programatic scrolls and also after switching tabs).
Was thinking of hacking workarounds in AC/Fenix (we can know when the user touches the screen or when tabs are changed) but Gecko sending the values that we're actually interested in without any additional code from us would be great! - for other integrators that wouldn't need this complexity also!

Comment 6

[Botond Ballo [:botond]]

I'm going to take a stab at implementing this.