scheduler: Handle mouse wheel event disposition correctly

scheduler: Handle mouse wheel event disposition correctly

Previously the renderer scheduler would treat mouse wheel events as
prioritized events, but failed to keep track of whether they were
processed (and preventDefault()'ed) on the main thread or whether they
turned into a smooth scroll gesture. Making this distinction is
important because in the former case the main thread is doing custom
input handling (which we should be careful about scheduling) and in the
latter we are dealing with a regular scroll gesture handled either by
the main or the compositor thread.

This patch fixes the problem by adding explicit processing for the
MouseWheel event and a number of tests which cover all the relevant
scenarios.

BUG=654765
Committed: https://crrev.com/4867673a4d5bad7c3030ac7bab0ee5bf41a6f634
Cr-Commit-Position: refs/heads/master@{#431321}

[Sami, 2016-11-10 18:15:41]

Description was changed from

==========
scheduler: Handle mouse wheel event disposition correctly

Previously the renderer scheduler would treat mouse wheel events as
prioritized events, but failed to keep track of whether they were
processed (and preventDefault()'ed) on the main thread or whether they
turned into a smooth scroll gesture. Making this distinction is
important because in the former case the main thread is doing custom
input handling (which we should be careful about scheduling) and in the
latter we are dealing with a regular scroll gesture handled either by
the main or the compositor thread.

This patch fixes the problem by adding explicit processing for the
MouseWheel event and a number of tests which cover all the relevant
scenarios.

BUG=654765
==========

to

==========
scheduler: Handle mouse wheel event disposition correctly

Previously the renderer scheduler would treat mouse wheel events as
prioritized events, but failed to keep track of whether they were
processed (and preventDefault()'ed) on the main thread or whether they
turned into a smooth scroll gesture. Making this distinction is
important because in the former case the main thread is doing custom
input handling (which we should be careful about scheduling) and in the
latter we are dealing with a regular scroll gesture handled either by
the main or the compositor thread.

This patch fixes the problem by adding explicit processing for the
MouseWheel event and a number of tests which cover all the relevant
scenarios.

BUG=654765
==========

[Sami, 2016-11-10 18:15:41]

skyostil@chromium.org changed reviewers:
+ alexclarke@chromium.org

[alex clarke (OOO till 29th), 2016-11-10 18:19:49]

lgtm

[Sami, 2016-11-10 18:22:22]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2016-11-10 18:23:18]

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-11-10 19:46:51]

Description was changed from

==========
scheduler: Handle mouse wheel event disposition correctly

Previously the renderer scheduler would treat mouse wheel events as
prioritized events, but failed to keep track of whether they were
processed (and preventDefault()'ed) on the main thread or whether they
turned into a smooth scroll gesture. Making this distinction is
important because in the former case the main thread is doing custom
input handling (which we should be careful about scheduling) and in the
latter we are dealing with a regular scroll gesture handled either by
the main or the compositor thread.

This patch fixes the problem by adding explicit processing for the
MouseWheel event and a number of tests which cover all the relevant
scenarios.

BUG=654765
==========

to

==========
scheduler: Handle mouse wheel event disposition correctly

Previously the renderer scheduler would treat mouse wheel events as
prioritized events, but failed to keep track of whether they were
processed (and preventDefault()'ed) on the main thread or whether they
turned into a smooth scroll gesture. Making this distinction is
important because in the former case the main thread is doing custom
input handling (which we should be careful about scheduling) and in the
latter we are dealing with a regular scroll gesture handled either by
the main or the compositor thread.

This patch fixes the problem by adding explicit processing for the
MouseWheel event and a number of tests which cover all the relevant
scenarios.

BUG=654765
==========

[commit-bot: I haz the power, 2016-11-10 19:46:59]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-10 20:10:41]

Description was changed from

==========
scheduler: Handle mouse wheel event disposition correctly

Previously the renderer scheduler would treat mouse wheel events as
prioritized events, but failed to keep track of whether they were
processed (and preventDefault()'ed) on the main thread or whether they
turned into a smooth scroll gesture. Making this distinction is
important because in the former case the main thread is doing custom
input handling (which we should be careful about scheduling) and in the
latter we are dealing with a regular scroll gesture handled either by
the main or the compositor thread.

This patch fixes the problem by adding explicit processing for the
MouseWheel event and a number of tests which cover all the relevant
scenarios.

BUG=654765
==========

to

==========
scheduler: Handle mouse wheel event disposition correctly

Previously the renderer scheduler would treat mouse wheel events as
prioritized events, but failed to keep track of whether they were
processed (and preventDefault()'ed) on the main thread or whether they
turned into a smooth scroll gesture. Making this distinction is
important because in the former case the main thread is doing custom
input handling (which we should be careful about scheduling) and in the
latter we are dealing with a regular scroll gesture handled either by
the main or the compositor thread.

This patch fixes the problem by adding explicit processing for the
MouseWheel event and a number of tests which cover all the relevant
scenarios.

BUG=654765

Committed: https://crrev.com/4867673a4d5bad7c3030ac7bab0ee5bf41a6f634
Cr-Commit-Position: refs/heads/master@{#431321}
==========

[commit-bot: I haz the power, 2016-11-10 20:10:42]

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