Expose whether a ScrollUpdate is the first such in the sequence

Expose whether a ScrollUpdate sequence has been partially prevented

This bit is useful for better understanding how the touch sequence that
gave rise to a given scroll sequence was handled by the page. In
particular, this affords the gesture consumer an opportunity to limit
itself if part of the gesture was consumed by the page's touch handler,
e.g., disabling a pull-to-refresh styled overscroll effect if the
initial motion was preventDefault'ed,
https://codereview.chromium.org/679493002.

Chromium-side wiring for this data will be added in
https://codereview.chromium.org/712133003.

BUG=428429
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=185068

[jdduke (slow), 2014-10-31 03:56:29]

jdduke@chromium.org changed reviewers:
+ rbyers@chromium.org

[jdduke (slow), 2014-10-31 03:56:30]

rbyers@: Sigh, it's a shame to have to abuse WebInputEvent here for reasons that
are (currently) specific to content/, though I suppose it's not without
precedent. This patch has me on the verge of implementing content::GestureEvent,
content::TouchEvent, etc... types. Initially those would probably just be
derivatves of their corresponding Web*Event counterparts, but at least we could
add fields as necessary (e.g., ui::LatencyInfo or scroll delta hints or this
additional bit) without burdening Blink.

Anyhow, the need for this bit is due to the fact that the first touchmove is no
longer special. Thus, the initial scroll sequence can be prevented but later
resumed, and it's impossible to tell that such prevention occurred without also
listening to the touch stream. I discovered this in implementing the Android
pull-to-refresh effect (https://codereview.chromium.org/679493002/); a number of
sites activate their own pull-to-refresh by preventing the first (or first
several) touchmoves, but then not preventing them. This bit is used to avoid
double handling the initial motion.

https://codereview.chromium.org/690173002/diff/1/public/web/WebInputEvent.h
File public/web/WebInputEvent.h (right):

https://codereview.chromium.org/690173002/diff/1/public/web/WebInputEvent.h#n...
public/web/WebInputEvent.h:460: int isFirstUpdate;
I'm not a big fan of this variable name... maybe "derivedFromFirstTouchmove"?
That doesn't feel a lot better either...

[tdresser, 2014-10-31 13:41:25]

tdresser@chromium.org changed reviewers:
+ tdresser@chromium.org

[tdresser, 2014-10-31 13:41:25]

I think we should behave consistently here between native p2r and GestureNav.

I'm not entirely sure that we want to give special precedence to the first
touchmove here. Can you give examples of the sites that stop preventDefaulting
once the pull to refresh effect has started?

[jdduke (slow), 2014-10-31 15:45:33]

On 2014/10/31 13:41:25, tdresser wrote:
> I think we should behave consistently here between native p2r and GestureNav.
> 

Absolutely yes, though p2r isn't a common desktop effect, and GestureNav only
effects lateral motion.

> I'm not entirely sure that we want to give special precedence to the first
> touchmove here. Can you give examples of the sites that stop preventDefaulting
> once the pull to refresh effect has started?

http://scores.espn.go.com/nba/gamecast?gameId=400578293&version=mobile&date=2...
has a p2r effect that stops preventing (you can tell because if you keep
overscrolling you'll see the glow)

http://www.marketwatch.com/story/yahoo-reports-third-quarter-2014-results-201...
has a drag-down effect that stops preventing (again you can tell because if you
keep overscrolling, you'll see the glow).

Both of these effects conflict with native p2r. The key bit here is that, if you
only listen to a gesture event sequence, there's currently no way to tell that
you're getting a partial scroll stream. This leads to logical double-handling of
the gesture. Given that we're in violation of the spec by not treating the first
touchmove as special, I'm inclined to do what we can to accommodate sites that
are following the spec.

[tdresser, 2014-10-31 16:50:01]

On 2014/10/31 15:45:33, jdduke wrote:
> On 2014/10/31 13:41:25, tdresser wrote:
> > I think we should behave consistently here between native p2r and
GestureNav.
> > 
> 
> Absolutely yes, though p2r isn't a common desktop effect, and GestureNav only
> effects lateral motion.
> 
> > I'm not entirely sure that we want to give special precedence to the first
> > touchmove here. Can you give examples of the sites that stop
preventDefaulting
> > once the pull to refresh effect has started?
> 
>
http://scores.espn.go.com/nba/gamecast?gameId=400578293&version=mobile&date=2...
> has a p2r effect that stops preventing (you can tell because if you keep
> overscrolling you'll see the glow)
> 
>
http://www.marketwatch.com/story/yahoo-reports-third-quarter-2014-results-201...
> has a drag-down effect that stops preventing (again you can tell because if
you
> keep overscrolling, you'll see the glow).
> 
> Both of these effects conflict with native p2r. The key bit here is that, if
you
> only listen to a gesture event sequence, there's currently no way to tell that
> you're getting a partial scroll stream. This leads to logical double-handling
of
> the gesture. Given that we're in violation of the spec by not treating the
first
> touchmove as special, I'm inclined to do what we can to accommodate sites that
> are following the spec.

I've changed the errata of the spec, and we are in alignment with it.
https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touc...

I agree that in practice, the use of p2r and gesturenav are distinct, but I
think the same principles should apply.

[jdduke (slow), 2014-10-31 16:53:53]

On 2014/10/31 16:50:01, tdresser wrote:
> I've changed the errata of the spec, and we are in alignment with it.
>
https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touc...
> 

OK, but we can hardly fault pages for not following the errata in the short term
=/

> I agree that in practice, the use of p2r and gesturenav are distinct, but I
> think the same principles should apply.

Yup, whatever bits we add here should be plumbed through to GestureNav.

[tdresser, 2014-10-31 17:13:32]

On 2014/10/31 16:53:53, jdduke wrote:
> On 2014/10/31 16:50:01, tdresser wrote:
> > I've changed the errata of the spec, and we are in alignment with it.
> >
>
https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touc...
> > 
> 
> OK, but we can hardly fault pages for not following the errata in the short
term
> =/

Absolutely, I'm just worried about adding complexity to the platform, and
restricting what's possible unnecessarily.
For example, what if a page does want to prevent the native p2r until some pull
down header is visible, but then would like the native pull to refresh to start
triggering?

> 
> > I agree that in practice, the use of p2r and gesturenav are distinct, but I
> > think the same principles should apply.
> 
> Yup, whatever bits we add here should be plumbed through to GestureNav.

[jdduke (slow), 2014-10-31 17:27:10]

On 2014/10/31 17:13:32, tdresser wrote:
> Absolutely, I'm just worried about adding complexity to the platform, and
> restricting what's possible unnecessarily.
> For example, what if a page does want to prevent the native p2r until some
pull
> down header is visible, but then would like the native pull to refresh to
start
> triggering?

That's a possibility, though I question its sanity :)

Reasoning about interop with a default platform action can already be a
difficult affair. For better or worse, preventDefault has been fashioned as a
preventative hammer, not a selective scalpel. In the case of a platform default
p2r, the action is sufficiently destructive that the platform can afford to be
selective about the conditions under which its activated.

All I'm asking is that we provide the gesture consumer more context for the
input gesture, allowing it to make more informed decisions.

[tdresser, 2014-10-31 17:36:33]

On 2014/10/31 17:27:10, jdduke wrote:
> On 2014/10/31 17:13:32, tdresser wrote:
> > Absolutely, I'm just worried about adding complexity to the platform, and
> > restricting what's possible unnecessarily.
> > For example, what if a page does want to prevent the native p2r until some
> pull
> > down header is visible, but then would like the native pull to refresh to
> start
> > triggering?
> 
> That's a possibility, though I question its sanity :)
> 
> Reasoning about interop with a default platform action can already be a
> difficult affair. For better or worse, preventDefault has been fashioned as a
> preventative hammer, not a selective scalpel. In the case of a platform
default
> p2r, the action is sufficiently destructive that the platform can afford to be
> selective about the conditions under which its activated.
> 
> All I'm asking is that we provide the gesture consumer more context for the
> input gesture, allowing it to make more informed decisions.

I agree that providing more context is good.

I'm not 100% convinced that native p2r and gesture nav should only pay attention
to the disposition of the first touch move.

[jdduke (slow), 2014-11-05 03:21:21]

https://codereview.chromium.org/690173002/diff/1/public/web/WebInputEvent.h
File public/web/WebInputEvent.h (right):

https://codereview.chromium.org/690173002/diff/1/public/web/WebInputEvent.h#n...
public/web/WebInputEvent.h:460: int isFirstUpdate;
On 2014/10/31 03:56:30, jdduke wrote:
> I'm not a big fan of this variable name... maybe "derivedFromFirstTouchmove"?
> That doesn't feel a lot better either...

OK, so adding a global "isPartialGestureStream" (as discussed offline) is a
little awkward, and ambiguous in the context of other gesture types. What about
a flag for "wasPreviousUpdatePrevented" for GSU/GPU events?

[mfomitchev, 2014-11-05 18:13:18]

> I'm not 100% convinced that native p2r and gesture nav should only pay
attention
> to the disposition of the first touch move.

GestureNav already sort of works this way, at least in relation to scrolling: if
the gesture results in horizontal page scroll, continuing to overscroll will not
engage GestureNav - you need to perform a new gesture.

[jdduke (slow), 2014-11-05 19:47:37]

On 2014/11/05 18:13:18, mfomitchev wrote:
> > I'm not 100% convinced that native p2r and gesture nav should only pay
> attention
> > to the disposition of the first touch move.
> 
> GestureNav already sort of works this way, at least in relation to scrolling:
if
> the gesture results in horizontal page scroll, continuing to overscroll will
not
> engage GestureNav - you need to perform a new gesture.

So, if the initial part of the touch sequence is consumed by the page
(preventDefault'ing the first touchmove, say), then stops and the generated
scroll events goes unconsumed, will GestureNav be triggered? That's the scenario
we're trying to avoid with pull-to-refresh, as it's not uncommon for sites to
have a pull-to-refresh effect that consumes only the initial motion of the touch
sequence.

[jdduke (slow), 2014-11-05 23:06:36]

Rick, do you have any opinions here? For the purposes of pull-to-refresh, it's
sufficient to know either we have a partial gesture sequence or that the GSU is
the first such (or that the previous was prevented). I'm not sure of any other
immediate use cases here, so I'm not sure how general we should make this...

[tdresser, 2014-11-06 17:43:49]

On 2014/11/05 23:06:36, jdduke wrote:
> Rick, do you have any opinions here? For the purposes of pull-to-refresh, it's
> sufficient to know either we have a partial gesture sequence or that the GSU
is
> the first such (or that the previous was prevented). I'm not sure of any other
> immediate use cases here, so I'm not sure how general we should make this...

Just to clarify, does wasPreviousUpdatePrevented mean "some previous update was
prevented" or "the immediately proceeding update was prevented"?

I think I'm in favor "some previous update was prevented"

wasPreviousUpdatePrevented sounds fine with me, and upon further consideration,
I think that using wasPreviousUpdatePrevented for both p2r and GestureNav sounds
reasonable.

[Rick Byers, 2014-11-07 03:44:02]

On 2014/11/06 17:43:49, tdresser wrote:
> On 2014/11/05 23:06:36, jdduke wrote:
> > Rick, do you have any opinions here? For the purposes of pull-to-refresh,
it's
> > sufficient to know either we have a partial gesture sequence or that the GSU
> is
> > the first such (or that the previous was prevented). I'm not sure of any
other
> > immediate use cases here, so I'm not sure how general we should make this...
> 
> Just to clarify, does wasPreviousUpdatePrevented mean "some previous update
was
> prevented" or "the immediately proceeding update was prevented"?
> 
> I think I'm in favor "some previous update was prevented"
> 
> wasPreviousUpdatePrevented sounds fine with me, and upon further
consideration,
> I think that using wasPreviousUpdatePrevented for both p2r and GestureNav
sounds
> reasonable.

That sounds fine to me.  We'll want to be clear (in a comment at least) that
it's referring to the sequence only (not ANY previous update event).  Even
"sequenceInterrupted" or "updateInSequencePrevented"?

Regardless, I'm fine with adding a bit here with whatever name as long as it's
clearly documented.

[jdduke (slow), 2014-11-07 05:07:49]

jdduke@chromium.org changed reviewers:
+ aelias@chromium.org

[jdduke (slow), 2014-11-07 05:07:49]

OK, updated with a clearer comment. +aelias@ for Source/web owner review.

[aelias_OOO_until_Jul13, 2014-11-07 22:33:39]

Source/web lgtm, still needs public/web OWNERS

[Rick Byers, 2014-11-10 19:24:51]

This LGTM

But please update the description to link to the chromium patch that sets this
bit (once you finish teasing that apart from your patch that adds the new
Android UI)

[jdduke (slow), 2014-11-10 21:26:35]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-11-10 21:27:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/690173002/20001

[commit-bot: I haz the power, 2014-11-10 22:01:49]

Committed patchset #2 (id:20001) as 185068