Bug 94478 – Rename Gesture Events for Scrolling

• Component: UI Events
• Status: NEW

[Allan Sandfeld Jensen]

When I looked at implementing support for the scrolling gesture in WebKit2 for Qt, I realized the names are rather unintuitively named.

Here is what they do as far as I can tell:
ScrollBegin: Scroll at the current positition unlatched.
ScrollUpdate: Scroll at the current position latched (this event must ALSO be used for the beginning of the scroll since only ScrollUpdate latches).
ScrollEnd: Perform animated kinetic Scroll from this point.

When reading them, it seems like you should start with a ScrollBegin, update with ScrollUpdate and end with ScrollEnd, but this will always be incorrect. If you want unlatched scrolling, you must always send ScrollBegin, you you want latched scrolling you must always use ScrollUpdate, and you should never send ScrollEnd, unless the wheel-event is synthetic and send from hardware that doesn't do the kenetic scrolling internally (which most does).

I suggest renaming them: ScrollUnlatched, ScrollLatched and ScollByInertia

[Allan Sandfeld Jensen]

Strike most of my comment on ScrollEnd, I was suddenly thinking of wheel-events. What I meant was ScrollEnd should only be send if you want WebCore to handle the kinetic scrolling, if you implement kinetic scrolling differently or otherwise don't need it, you don't have to use it.

[Robert Kroeger]

I had thought to change the implementation of these events in a similar but not exactly the same fashion. To be precise, I had thought of altering the implementation of EventHandler::handleGestureEvent to handle the respective scroll events like so:

ScrollBegin: latch a target node, set up for a scroll.

ScrollUpdate: actually scroll the latched node. (I think it is desirable to have flags on the event to control how bubbling is handled. I can imagine wanting both bubbled and non-bubbled ScrollUpdate events.)

ScrollEnd: clean up any latched state.

FlingStart: initiate a inertial scroll. With the presumption that the finger is no longer touching the screen during the fling.

So a touchscreen scroll in pseudo regex would look like this:

ScrollBegin ScrollUpdate* (ScrollEnd | FlingStart)

This seems a lot like: ScrollUnlatched ScrollLatched* ScrollByInertia except for the addition of ScrollEnd. Are you open to retaining it?

[Allan Sandfeld Jensen]

(In reply to comment #2)
> So a touchscreen scroll in pseudo regex would look like this:
> 
> ScrollBegin ScrollUpdate* (ScrollEnd | FlingStart)
> 
Sounds good, though I would call FlingStart something else, also if were are to make a new better set of scroll gestures names, I would suggest adding ScrollCancel (The gesture turned out to be something else, so return to where the scroll started).

[Allan Sandfeld Jensen]

(In reply to comment #2)
> I had thought to change the implementation of these events in a similar but not exactly the same fashion. To be precise, I had thought of altering the implementation of EventHandler::handleGestureEvent to handle the respective scroll events like so:
> 
> ScrollBegin: latch a target node, set up for a scroll.
> 
> ScrollUpdate: actually scroll the latched node. (I think it is desirable to have flags on the event to control how bubbling is handled. I can imagine wanting both bubbled and non-bubbled ScrollUpdate events.)
> 
One problem though. GestureScrollBegin exists in it current form because that is the event Mac WebKit2 sends. So we need to continue to support scrolling gestures that does not latch.

[Robert Kroeger]

(In reply to comment #4)
> (In reply to comment #2)
> > I had thought to change the implementation of these events in a similar but not exactly the same fashion. To be precise, I had thought of altering the implementation of EventHandler::handleGestureEvent to handle the respective scroll events like so:
> > 
> > ScrollBegin: latch a target node, set up for a scroll.
> > 
> > ScrollUpdate: actually scroll the latched node. (I think it is desirable to have flags on the event to control how bubbling is handled. I can imagine wanting both bubbled and non-bubbled ScrollUpdate events.)
> > 
> One problem though. GestureScrollBegin exists in it current form because that is the event Mac WebKit2 sends. So we need to continue to support scrolling gestures that does not latch.

OK. So it sounds like we could add a new event type? LatchAtScrollStart maybe?

[Robert Kroeger]

Allan: are you working on this? I would like to fix this so unless you have a patch in progress, I'll put up a first cut of a possible renaming in the next few days.

[Allan Sandfeld Jensen]

(In reply to comment #6)
> Allan: are you working on this? I would like to fix this so unless you have a patch in progress, I'll put up a first cut of a possible renaming in the next few days.

I am working on other issues at the moment, so feel free to take over this one.