Add UMA metric for tracking listeners for blocking touch while fling is happening

Add UMA metric for tracking listeners for blocking touch while fling is happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could treat
all touchstart event listeners as passive while there’s an active fling animation.
We are adding a metric that records when touchstarts are successfully preventDefaulted()
during fling to measure breakage of event handlers.

BUG=607245
Committed: https://crrev.com/8f486d67c25c4c856ea02ecf0edc02757884bd46
Cr-Commit-Position: refs/heads/master@{#394179}

[lanwei, 2016-04-27 18:46:22]

Description was changed from

==========
fling

BUG=
==========

to

==========
Add UMA metric for tracking listeners for blocking touch while fling is
happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could
treat all touchstart event listeners as passive while there’s an active fling
animation. We are adding a metric
that records when touchstarts are successfully preventDefaulted() during fling
to measure breakage of event handlers.

BUG=607245
==========

[lanwei, 2016-04-27 18:46:22]

lanwei@chromium.org changed reviewers:
+ dtapuska@chromium.org, tdresser@chromium.org

[lanwei, 2016-04-27 18:46:54]

Description was changed from

==========
Add UMA metric for tracking listeners for blocking touch while fling is
happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could
treat all touchstart event listeners as passive while there’s an active fling
animation. We are adding a metric
that records when touchstarts are successfully preventDefaulted() during fling
to measure breakage of event handlers.

BUG=607245
==========

to

==========
Add UMA metric for tracking listeners for blocking touch while fling is
happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could
treat
all touchstart event listeners as passive while there’s an active fling
animation.
We are adding a metric that records when touchstarts are successfully
preventDefaulted()
during fling to measure breakage of event handlers.

BUG=607245
==========

[lanwei, 2016-04-27 19:01:57]

https://codereview.chromium.org/1923973002/diff/1/tools/metrics/histograms/hi...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1923973002/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:62550: +<enum
name="BooleanHandledTouchesOnPageload" type="int">
I will rename this one to be more general.

[dtapuska, 2016-04-27 19:05:13]

https://codereview.chromium.org/1923973002/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/input/gesture_event_queue.h (right):

https://codereview.chromium.org/1923973002/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/input/gesture_event_queue.h:116: bool
FlingInProgress() { return fling_in_progress_; }
const

https://codereview.chromium.org/1923973002/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/input/input_router_impl.cc (right):

https://codereview.chromium.org/1923973002/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/input/input_router_impl.cc:467: (ack.state ==
INPUT_EVENT_ACK_STATE_CONSUMED) ? HANDLED_TOUCHES
I presume the passive ones counted as unhandled is ok. Do we want to call the
passive ones out to see it increase so we can see the intervention taking place?

[lanwei, 2016-04-28 18:16:48]

Patchset #2 (id:20001) has been deleted

[lanwei, 2016-04-28 18:54:28]

Can you please take a look, and I am writing a test for fling flag?

[dtapuska, 2016-04-28 18:59:09]

https://codereview.chromium.org/1923973002/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1923973002/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/web/WebInputEvent.h:639: bool isFlingInProgress;
move this beside the other boolean and the struct size does not need to
increase.

[tdresser, 2016-04-28 19:02:41]

https://codereview.chromium.org/1923973002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/input/touch_event_queue.h (right):

https://codereview.chromium.org/1923973002/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/touch_event_queue.h:245: // True if a
GestureFlingStart happens and false after a GestureFlingCancel.
Have you confirmed that a GFC gets sent at the correct time on both the main and
compositor threads?

[lanwei, 2016-04-28 20:25:18]

https://codereview.chromium.org/1923973002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/input/touch_event_queue.h (right):

https://codereview.chromium.org/1923973002/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/touch_event_queue.h:245: // True if a
GestureFlingStart happens and false after a GestureFlingCancel.
On 2016/04/28 19:02:41, tdresser wrote:
> Have you confirmed that a GFC gets sent at the correct time on both the main
and
> compositor threads?

Yes, I tested for both the main and compositor threads, Fling gestures are sent
here.

https://codereview.chromium.org/1923973002/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1923973002/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/web/WebInputEvent.h:639: bool isFlingInProgress;
On 2016/04/28 18:59:09, dtapuska wrote:
> move this beside the other boolean and the struct size does not need to
> increase.

Nice, thanks!

[lanwei, 2016-05-03 21:23:45]

Patchset #3 (id:60001) has been deleted

[lanwei, 2016-05-03 23:44:29]

Patchset #3 (id:80001) has been deleted

[dtapuska, 2016-05-05 20:22:21]

https://codereview.chromium.org/1923973002/diff/120001/content/renderer/input...
File content/renderer/input/input_handler_manager.cc (right):

https://codereview.chromium.org/1923973002/diff/120001/content/renderer/input...
content/renderer/input/input_handler_manager.cc:224: if
(blink::WebInputEvent::isTouchEventType(input_event->type)) {
this seems odd to repeatedly set a state on touch events. Shouldn't the state
always be consistent irrespective of the input type that is processed?

Shouldn't the state just be replicated to the associated client all the time?

https://codereview.chromium.org/1923973002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1923973002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/web/WebInputEvent.h:637: bool shouldForceBePassive;
Combining this change with https://codereview.chromium.org/1955643002/

indicates to me that we actually have an instance where state variables don't
actually make sense.

For example consider this object:
dispatchType == ListenersForcedNonBlockingPassive
shouldForceBePassive == false

That is an incorrect state. I wonder if we should instead add a different
enumeration value on the DispatchType indicated
BlockingCandidateForForcedNonBlocking

which is a bit indicating; hey this is still a blocking event; but we want to
tag it for metrics purposes that it might be forced non-blocking under a
heuristic.

Thoughts?

[tdresser, 2016-05-06 19:01:31]

https://codereview.chromium.org/1923973002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1923973002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/web/WebInputEvent.h:637: bool shouldForceBePassive;
On 2016/05/05 20:22:21, dtapuska wrote:
> Combining this change with https://codereview.chromium.org/1955643002/
> 
> indicates to me that we actually have an instance where state variables don't
> actually make sense.
> 
> For example consider this object:
> dispatchType == ListenersForcedNonBlockingPassive
> shouldForceBePassive == false
> 
> That is an incorrect state. I wonder if we should instead add a different
> enumeration value on the DispatchType indicated
> BlockingCandidateForForcedNonBlocking
> 
> which is a bit indicating; hey this is still a blocking event; but we want to
> tag it for metrics purposes that it might be forced non-blocking under a
> heuristic.
> 
> Thoughts?
> 

Let's just call this "dispatchedDuringFling", and we can rename it later if
necessary.

That get's rid of the case where we have state that doesn't make sense.

[lanwei, 2016-05-09 17:03:54]

Patchset #5 (id:140001) has been deleted

[lanwei, 2016-05-09 17:04:07]

Patchset #5 (id:160001) has been deleted

[tdresser, 2016-05-09 19:31:09]

I'm not sure syncing the full state is the correct path forward here - wouldn't
we also need a "didStopFlinging"?

[tdresser, 2016-05-09 19:41:08]

On 2016/05/09 19:31:09, tdresser wrote:
> I'm not sure syncing the full state is the correct path forward here -
wouldn't
> we also need a "didStopFlinging"?

Lan pointed out that this information is already passed to the compositor.
InputHandlerProxy::MainThreadHasStoppedFlinging() is more accurate than I
thought.

[tdresser, 2016-05-09 19:48:46]

Do we need to distinguish between main and impl thread fling here? We might be
able to get away with just knowing if _any_ fling is happening.

https://codereview.chromium.org/1923973002/diff/180001/blimp/client/feature/c...
File blimp/client/feature/compositor/blimp_input_handler_wrapper.h (right):

https://codereview.chromium.org/1923973002/diff/180001/blimp/client/feature/c...
blimp/client/feature/compositor/blimp_input_handler_wrapper.h:52: void
DidStartFlinging(bool is_on_impl) override;
Put this next to DidStartFlinging.
Use an enum for the parameter instead of a bool - there might already be a
reasonable enum somewhere?

https://codereview.chromium.org/1923973002/diff/180001/content/renderer/input...
File content/renderer/input/main_thread_event_queue.h (right):

https://codereview.chromium.org/1923973002/diff/180001/content/renderer/input...
content/renderer/input/main_thread_event_queue.h:104: bool is_flinging = false);
Can we plumb the information about whether a fling is active separately from the
handle event call?

We should be able to tell the main thread event queue when fling starts and
stops, instead of adding this bit.

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/TouchEventManager.cpp (right):

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/TouchEventManager.cpp:256: if (event.type()
== PlatformEvent::TouchStart && event.dispatchedDuringFling()) {
Record another histogram for when events are dispatched outside of fling.

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/pub...
File third_party/WebKit/public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/pub...
third_party/WebKit/public/web/WebInputEvent.h:637: // events.
Maybe something like:

// Whether there was an active fling animation when the event was dispatched.

https://codereview.chromium.org/1923973002/diff/180001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1923973002/diff/180001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:12274: +<histogram
name="Event.Touch.TouchDispositionsDuringFling"
We need two histograms here, don't we?

[lanwei, 2016-05-12 03:31:51]

Patchset #7 (id:220001) has been deleted

[lanwei, 2016-05-12 11:50:37]

https://codereview.chromium.org/1923973002/diff/180001/blimp/client/feature/c...
File blimp/client/feature/compositor/blimp_input_handler_wrapper.h (right):

https://codereview.chromium.org/1923973002/diff/180001/blimp/client/feature/c...
blimp/client/feature/compositor/blimp_input_handler_wrapper.h:52: void
DidStartFlinging(bool is_on_impl) override;
On 2016/05/09 19:48:45, tdresser wrote:
> Put this next to DidStartFlinging.
> Use an enum for the parameter instead of a bool - there might already be a
> reasonable enum somewhere?

Done.

https://codereview.chromium.org/1923973002/diff/180001/content/renderer/input...
File content/renderer/input/main_thread_event_queue.h (right):

https://codereview.chromium.org/1923973002/diff/180001/content/renderer/input...
content/renderer/input/main_thread_event_queue.h:104: bool is_flinging = false);
On 2016/05/09 19:48:45, tdresser wrote:
> Can we plumb the information about whether a fling is active separately from
the
> handle event call?
> 
> We should be able to tell the main thread event queue when fling starts and
> stops, instead of adding this bit.

Done.

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/TouchEventManager.cpp (right):

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/TouchEventManager.cpp:256: if (event.type()
== PlatformEvent::TouchStart && event.dispatchedDuringFling()) {
On 2016/05/09 19:48:45, tdresser wrote:
> Record another histogram for when events are dispatched outside of fling.

Done.

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/pub...
File third_party/WebKit/public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1923973002/diff/180001/third_party/WebKit/pub...
third_party/WebKit/public/web/WebInputEvent.h:637: // events.
On 2016/05/09 19:48:45, tdresser wrote:
> Maybe something like:
> 
> // Whether there was an active fling animation when the event was dispatched.

Done.

https://codereview.chromium.org/1923973002/diff/180001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1923973002/diff/180001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:12274: +<histogram
name="Event.Touch.TouchDispositionsDuringFling"
On 2016/05/09 19:48:45, tdresser wrote:
> We need two histograms here, don't we?

Yes, I am adding one.

[lanwei, 2016-05-12 11:51:11]

Patchset #6 (id:200001) has been deleted

[tdresser, 2016-05-13 13:42:21]

LGTM!

https://codereview.chromium.org/1923973002/diff/240001/content/renderer/input...
File content/renderer/input/input_event_filter.h (right):

https://codereview.chromium.org/1923973002/diff/240001/content/renderer/input...
content/renderer/input/input_event_filter.h:91: void
SetIsFlingInMainThreadEventQueue(int routing_id, bool is_flinging);
SetIsFlingingInMainThreadEventQueue or
SetCurrentlyFlingingInMainThreadEventQueue.

This could be a method in the anonymous namespace, which took route_queues_ as a
parameter. I don't have a particularly strong preference either way.

https://codereview.chromium.org/1923973002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/TouchEventManager.cpp (right):

https://codereview.chromium.org/1923973002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/TouchEventManager.cpp:255: // Count the
handled touch starts while there is and isn't an active fling animation.
Report the touch disposition, split by whether there is an active fling
animation.

https://codereview.chromium.org/1923973002/diff/240001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1923973002/diff/240001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:12304: +    Records the disposition
(handled or not handled) of touch start events per
"per scroll" isn't quite right, as if the event is handled, we might not scroll.

I think you can just get rid of "per scroll".

Same below.

[lanwei, 2016-05-13 16:06:55]

Patchset #7 (id:260001) has been deleted

[lanwei, 2016-05-13 16:07:03]

Patchset #7 (id:280001) has been deleted

[lanwei, 2016-05-13 18:15:49]

https://codereview.chromium.org/1923973002/diff/240001/content/renderer/input...
File content/renderer/input/input_event_filter.h (right):

https://codereview.chromium.org/1923973002/diff/240001/content/renderer/input...
content/renderer/input/input_event_filter.h:91: void
SetIsFlingInMainThreadEventQueue(int routing_id, bool is_flinging);
On 2016/05/13 13:42:21, tdresser wrote:
> SetIsFlingingInMainThreadEventQueue or
> SetCurrentlyFlingingInMainThreadEventQueue.
> 
> This could be a method in the anonymous namespace, which took route_queues_ as
a
> parameter. I don't have a particularly strong preference either way.

Done.

https://codereview.chromium.org/1923973002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/TouchEventManager.cpp (right):

https://codereview.chromium.org/1923973002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/TouchEventManager.cpp:255: // Count the
handled touch starts while there is and isn't an active fling animation.
On 2016/05/13 13:42:21, tdresser wrote:
> Report the touch disposition, split by whether there is an active fling
> animation.

Done.

https://codereview.chromium.org/1923973002/diff/240001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1923973002/diff/240001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:12304: +    Records the disposition
(handled or not handled) of touch start events per
On 2016/05/13 13:42:21, tdresser wrote:
> "per scroll" isn't quite right, as if the event is handled, we might not
scroll.
> 
> I think you can just get rid of "per scroll".
> 
> Same below.

Done.

[lanwei, 2016-05-13 20:32:37]

Patchset #7 (id:300001) has been deleted

[lanwei, 2016-05-13 20:48:44]

lanwei@chromium.org changed reviewers:
+ jochen@chromium.org

[lanwei, 2016-05-13 20:50:55]

lanwei@chromium.org changed reviewers:
+ nyquist@chromium.org
- jochen@chromium.org

[lanwei, 2016-05-13 20:56:08]

lanwei@chromium.org changed reviewers:
+ cpu@chromium.org, isherman@chromium.org
- nyquist@chromium.org

[lanwei, 2016-05-13 20:57:07]

lanwei@chromium.org changed reviewers:
- cpu@chromium.org

[lanwei, 2016-05-13 20:59:30]

lanwei@chromium.org changed reviewers:
+ ilya sherman (away may 5-15)，jochen@chromium.org
- isherman@chromium.org

[lanwei, 2016-05-13 20:59:52]

lanwei@chromium.org changed reviewers:
+ isherman@chromium.org, jochen@chromium.org
- ilya sherman (away may 5-15)，jochen@chromium.org

[lanwei, 2016-05-13 21:02:18]

lanwei@chromium.org changed reviewers:
+ brettw@chromium.org
- jochen@chromium.org

[dtapuska, 2016-05-16 13:56:28]

On 2016/05/13 21:03:15, lanwei wrote:

lgtm

[lanwei, 2016-05-16 20:43:31]

lanwei@chromium.org changed reviewers:
- brettw@chromium.org

[lanwei, 2016-05-16 20:54:57]

lanwei@chromium.org changed reviewers:
+ sky@chromium.org

[lanwei, 2016-05-16 21:02:41]

lanwei@chromium.org changed reviewers:
+ nyquist@chromium.org, sievers@chromium.org

[lanwei, 2016-05-16 21:02:42]

sky@chromium.org: Please review changes in
third_party/Webkit/*

sievers@chromium.org: Please review changes in 
content/*

nyquist@chromium.org: Please review changes in 
blimp/*

isherman@chromium.org: Please review changes in
tools/metrics/histograms/histograms.xml

Thank you very much!

[sky, 2016-05-16 21:29:08]

On 2016/05/16 21:02:42, lanwei wrote:
> mailto:sky@chromium.org: Please review changes in
> third_party/Webkit/*
> 
> mailto:sievers@chromium.org: Please review changes in 
> content/*
> 
> mailto:nyquist@chromium.org: Please review changes in 
> blimp/*
> 
> mailto:isherman@chromium.org: Please review changes in
> tools/metrics/histograms/histograms.xml
> 
> Thank you very much!

I'm not a good reviewer for webkit. Please find a more local owner.

[lanwei, 2016-05-16 22:30:41]

lanwei@chromium.org changed reviewers:
- sky@chromium.org

[lanwei, 2016-05-16 22:44:09]

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

[lanwei, 2016-05-16 22:52:38]

lanwei@chromium.org changed reviewers:
- rbyers@chromium.org

[lanwei, 2016-05-16 22:53:25]

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

[lanwei, 2016-05-16 22:54:03]

lanwei@chromium.org changed reviewers:
+ tkent@chromium.org

[lanwei, 2016-05-16 22:54:04]

tkent@chromium.org: Please review changes in 

third_party/Webkit/*

Thank you very much!

[tkent, 2016-05-16 23:07:38]

third_party/WebKit lgtm

[Ilya Sherman, 2016-05-17 01:21:46]

https://codereview.chromium.org/1923973002/diff/320001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1923973002/diff/320001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:12406: +    the first touchmove events.
Only recorded after the page is fully loaded.
The first touchmove events per what?  Per page load?  Please clarify.

https://codereview.chromium.org/1923973002/diff/320001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:12415: +    the first touchmove events.
Only recorded before the page is fully loaded.
Ditto

[lanwei, 2016-05-17 02:11:08]

https://codereview.chromium.org/1923973002/diff/320001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1923973002/diff/320001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:12406: +    the first touchmove events.
Only recorded after the page is fully loaded.
On 2016/05/17 01:21:45, Ilya Sherman (Away May 5-15) wrote:
> The first touchmove events per what?  Per page load?  Please clarify.

Per scroll.

[Ilya Sherman, 2016-05-17 03:51:09]

histograms lgtm, thanks

[Rick Byers, 2016-05-17 13:36:44]

rbyers@chromium.org changed reviewers:
- rbyers@chromium.org

[lanwei, 2016-05-17 17:45:47]

lanwei@chromium.org changed reviewers:
+ haibinlu@chromium.org
- nyquist@chromium.org

[haibinlu, 2016-05-17 17:48:12]

lgtm

lgtm for blimp/client

[no sievers, 2016-05-17 18:45:33]

content lgtm

[lanwei, 2016-05-17 18:49:16]

The CQ bit was checked by lanwei@chromium.org

[lanwei, 2016-05-17 18:49:17]

The patchset sent to the CQ was uploaded after l-g-t-m from
tdresser@chromium.org, tkent@chromium.org, dtapuska@chromium.org
Link to the patchset: https://codereview.chromium.org/1923973002/#ps340001
(title: "Change comments in histogram")

[commit-bot: I haz the power, 2016-05-17 18:49:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1923973002/340001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1923973002/340001

[commit-bot: I haz the power, 2016-05-17 18:56:49]

Description was changed from

==========
Add UMA metric for tracking listeners for blocking touch while fling is
happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could
treat
all touchstart event listeners as passive while there’s an active fling
animation.
We are adding a metric that records when touchstarts are successfully
preventDefaulted()
during fling to measure breakage of event handlers.

BUG=607245
==========

to

==========
Add UMA metric for tracking listeners for blocking touch while fling is
happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could
treat
all touchstart event listeners as passive while there’s an active fling
animation.
We are adding a metric that records when touchstarts are successfully
preventDefaulted()
during fling to measure breakage of event handlers.

BUG=607245
==========

[commit-bot: I haz the power, 2016-05-17 18:56:51]

Committed patchset #8 (id:340001)

[commit-bot: I haz the power, 2016-05-17 19:03:00]

Description was changed from

==========
Add UMA metric for tracking listeners for blocking touch while fling is
happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could
treat
all touchstart event listeners as passive while there’s an active fling
animation.
We are adding a metric that records when touchstarts are successfully
preventDefaulted()
during fling to measure breakage of event handlers.

BUG=607245
==========

to

==========
Add UMA metric for tracking listeners for blocking touch while fling is
happening.

In the touch scrolling intervention proposal, alexclarke@ proposed that we could
treat
all touchstart event listeners as passive while there’s an active fling
animation.
We are adding a metric that records when touchstarts are successfully
preventDefaulted()
during fling to measure breakage of event handlers.

BUG=607245

Committed: https://crrev.com/8f486d67c25c4c856ea02ecf0edc02757884bd46
Cr-Commit-Position: refs/heads/master@{#394179}
==========

[commit-bot: I haz the power, 2016-05-17 19:03:02]

Patchset 8 (id:??) landed as
https://crrev.com/8f486d67c25c4c856ea02ecf0edc02757884bd46
Cr-Commit-Position: refs/heads/master@{#394179}