Update pad-gesture-fling test to accommodate short-circuited fling

Update pad-gesture-fling test to accommodate short-circuited fling

The pad-gesture-fling layout tests assumes the fling curve will generate a
minimum number of events.  This may not always hold, depending on the
fling curve parameters, the fling curve update frequency and whether the main
thread is slow.  Instead, impose a maximum limit on the number of fling updates
it takes to reach the minimum offset target, and use preventDefault() on the
mousewheel event to prevent the fling from terminating early.

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

[jdduke (slow), 2014-04-01 18:24:06]

bokan@: This isn't the cleanest solution, but it did resolve the issue on
Android (had trouble getting my linux build to run the layout test properly, so
we'll see...).

[bokan, 2014-04-01 18:37:10]

https://codereview.chromium.org/219243010/diff/1/LayoutTests/fast/events/touc...
File LayoutTests/fast/events/touch/gesture/pad-gesture-fling.js (right):

https://codereview.chromium.org/219243010/diff/1/LayoutTests/fast/events/touc...
LayoutTests/fast/events/touch/gesture/pad-gesture-fling.js:31: &&
actualWheelEventsOccurred < maximumWheelEventsExpected)) {
I don't think you need this last condition. If actual == maximum we wouldn't
eval here because of the ||, actual > maximum shouldn't happen since we should
have finished the test.

https://codereview.chromium.org/219243010/diff/1/LayoutTests/fast/events/touc...
LayoutTests/fast/events/touch/gesture/pad-gesture-fling.js:32:
shouldBeGreaterThanOrEqual(maximumWheelEventsExpected.toString(),
'actualWheelEventsOccurred');
This seems kind of weird, why would we want a maximum? (e.g. what happens in a
few years when we're running at 120Hz and generating way more events?)

Could we maybe just ensure we get at least 2 events? Really, a fling should
involve multiple events, we don't really care about the number otherwise...

[jdduke (slow), 2014-04-01 18:38:45]

https://codereview.chromium.org/219243010/diff/1/LayoutTests/fast/events/touc...
File LayoutTests/fast/events/touch/gesture/pad-gesture-fling.js (right):

https://codereview.chromium.org/219243010/diff/1/LayoutTests/fast/events/touc...
LayoutTests/fast/events/touch/gesture/pad-gesture-fling.js:31: &&
actualWheelEventsOccurred < maximumWheelEventsExpected)) {
On 2014/04/01 18:37:10, bokan wrote:
> I don't think you need this last condition. If actual == maximum we wouldn't
> eval here because of the ||, actual > maximum shouldn't happen since we should
> have finished the test.

OK I wasn't sure if |notifyDone()| forcefully terminates the test.

https://codereview.chromium.org/219243010/diff/1/LayoutTests/fast/events/touc...
LayoutTests/fast/events/touch/gesture/pad-gesture-fling.js:32:
shouldBeGreaterThanOrEqual(maximumWheelEventsExpected.toString(),
'actualWheelEventsOccurred');
On 2014/04/01 18:37:10, bokan wrote:
> This seems kind of weird, why would we want a maximum? (e.g. what happens in a
> few years when we're running at 120Hz and generating way more events?)
> 
> Could we maybe just ensure we get at least 2 events? Really, a fling should
> involve multiple events, we don't really care about the number otherwise...

Why 2? Why not 1?  Ideally we'd just keep going until the external timeout
fires?

[jdduke (slow), 2014-04-01 18:53:39]

OK, updated per offline discussion.

[bokan, 2014-04-01 19:01:53]

On 2014/04/01 18:53:39, jdduke wrote:
> OK, updated per offline discussion.

LGTM

[jdduke (slow), 2014-04-01 19:09:48]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-04-01 19:09:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/219243010/20001

[commit-bot: I haz the power, 2014-04-01 20:18:23]

Change committed as 170597