Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of GestureTapBegin.

Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of GestureTapBegin.

GestureTapBegin is a synthetic event generated by the input system. If
a website captures a touch event and calls preventDefault() on it, the
GestureTapBegin event will not be generated.

This is problematic for site engagement, which is a primary consumer of
the DidGetUserInteraction API. Touch events which are captured by sites
cannot earn engagement because the event is never passed through.

This CL addresses the issue by changing DidGetUserInteraction to fire on
TouchStart events rather than GestureTapBegin. This has negligible
performance impact, and no real behavioural impact on the current API
consumers. Unit tests for methods based on DidGetUserInteraction are
updated to never send GestureTapBegin, and instead send TouchStart in
its place.

BUG=654976
Committed: https://crrev.com/26940224a3ebb4b7a8f4e632953d57f720301a17
Cr-Commit-Position: refs/heads/master@{#424932}

[dominickn, 2016-10-12 02:48:40]

The CQ bit was checked by dominickn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-12 02:48:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dominickn, 2016-10-12 03:28:40]

Description was changed from

==========
Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of
GestureTapBegin.

GestureTapBegin is a synthetic event generated by the input system. If
a website captures a touch event and calls preventDefault() on it, the
GestureTapBegin event will not be generated.

This is problematic for site engagement, which is a primary consumer of
the DidGetUserInteraction API. Touch events which are captured by sites
cannot earn engagement because the event is never passed through.

This CL addresses the issue by changing DidGetUserInteraction to fire on
TouchStart events rather than GestureTapBegin. This has negligible
performance impact, and no real behavioural impact on the current API
consumers. Unit tests for methods based on DidGetUserInteraction are
updated to never send GestureTapBegin, and instead send TouchStart in
its place.

BUG=654976
==========

to

==========
Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of
GestureTapBegin.

GestureTapBegin is a synthetic event generated by the input system. If
a website captures a touch event and calls preventDefault() on it, the
GestureTapBegin event will not be generated.

This is problematic for site engagement, which is a primary consumer of
the DidGetUserInteraction API. Touch events which are captured by sites
cannot earn engagement because the event is never passed through.

This CL addresses the issue by changing DidGetUserInteraction to fire on
TouchStart events rather than GestureTapBegin. This has negligible
performance impact, and no real behavioural impact on the current API
consumers. Unit tests for methods based on DidGetUserInteraction are
updated to never send GestureTapBegin, and instead send TouchStart in
its place.

BUG=654976
==========

[dominickn, 2016-10-12 03:28:41]

dominickn@chromium.org changed reviewers:
+ asanka@chromium.org, benwells@chromium.org, nasko@chromium.org,
tdresser@chromium.org

[commit-bot: I haz the power, 2016-10-12 03:54:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-12 03:54:59]

Dry run: This issue passed the CQ dry run.

[dominickn, 2016-10-12 04:00:45]

tdresser: PTAL at renderer_host
nasko: PTAL at content/public (comment update)
benwells: PTAL at engagement/
asanka: FYI (trivial unit test change)


Thanks!

[tdresser, 2016-10-12 12:09:59]

LGTM.

[nasko, 2016-10-12 23:55:07]

content/ comment update rubberstamp LGTM.

[benwells, 2016-10-13 00:09:12]

c/b/engagement lgtm

[dominickn, 2016-10-13 00:09:55]

dominickn@chromium.org changed reviewers:
- asanka@chromium.org

[dominickn, 2016-10-13 01:33:30]

The CQ bit was checked by dominickn@chromium.org

[commit-bot: I haz the power, 2016-10-13 01:33:50]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-13 01:39:51]

Description was changed from

==========
Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of
GestureTapBegin.

GestureTapBegin is a synthetic event generated by the input system. If
a website captures a touch event and calls preventDefault() on it, the
GestureTapBegin event will not be generated.

This is problematic for site engagement, which is a primary consumer of
the DidGetUserInteraction API. Touch events which are captured by sites
cannot earn engagement because the event is never passed through.

This CL addresses the issue by changing DidGetUserInteraction to fire on
TouchStart events rather than GestureTapBegin. This has negligible
performance impact, and no real behavioural impact on the current API
consumers. Unit tests for methods based on DidGetUserInteraction are
updated to never send GestureTapBegin, and instead send TouchStart in
its place.

BUG=654976
==========

to

==========
Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of
GestureTapBegin.

GestureTapBegin is a synthetic event generated by the input system. If
a website captures a touch event and calls preventDefault() on it, the
GestureTapBegin event will not be generated.

This is problematic for site engagement, which is a primary consumer of
the DidGetUserInteraction API. Touch events which are captured by sites
cannot earn engagement because the event is never passed through.

This CL addresses the issue by changing DidGetUserInteraction to fire on
TouchStart events rather than GestureTapBegin. This has negligible
performance impact, and no real behavioural impact on the current API
consumers. Unit tests for methods based on DidGetUserInteraction are
updated to never send GestureTapBegin, and instead send TouchStart in
its place.

BUG=654976
==========

[commit-bot: I haz the power, 2016-10-13 01:39:52]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-13 01:43:29]

Description was changed from

==========
Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of
GestureTapBegin.

GestureTapBegin is a synthetic event generated by the input system. If
a website captures a touch event and calls preventDefault() on it, the
GestureTapBegin event will not be generated.

This is problematic for site engagement, which is a primary consumer of
the DidGetUserInteraction API. Touch events which are captured by sites
cannot earn engagement because the event is never passed through.

This CL addresses the issue by changing DidGetUserInteraction to fire on
TouchStart events rather than GestureTapBegin. This has negligible
performance impact, and no real behavioural impact on the current API
consumers. Unit tests for methods based on DidGetUserInteraction are
updated to never send GestureTapBegin, and instead send TouchStart in
its place.

BUG=654976
==========

to

==========
Make WebContentsObserver::DidGetUserInteraction fire on TouchStart instead of
GestureTapBegin.

GestureTapBegin is a synthetic event generated by the input system. If
a website captures a touch event and calls preventDefault() on it, the
GestureTapBegin event will not be generated.

This is problematic for site engagement, which is a primary consumer of
the DidGetUserInteraction API. Touch events which are captured by sites
cannot earn engagement because the event is never passed through.

This CL addresses the issue by changing DidGetUserInteraction to fire on
TouchStart events rather than GestureTapBegin. This has negligible
performance impact, and no real behavioural impact on the current API
consumers. Unit tests for methods based on DidGetUserInteraction are
updated to never send GestureTapBegin, and instead send TouchStart in
its place.

BUG=654976

Committed: https://crrev.com/26940224a3ebb4b7a8f4e632953d57f720301a17
Cr-Commit-Position: refs/heads/master@{#424932}
==========

[commit-bot: I haz the power, 2016-10-13 01:43:31]

Patchset 1 (id:??) landed as
https://crrev.com/26940224a3ebb4b7a8f4e632953d57f720301a17
Cr-Commit-Position: refs/heads/master@{#424932}