scheduler: Reset gesture state at start of a mouse drag

scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG=638212
Committed: https://crrev.com/1329d0ac5e235bd6a94ef3ac22947ea6acf67363
Cr-Commit-Position: refs/heads/master@{#413475}

[Sami, 2016-08-22 10:56:42]

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

[commit-bot: I haz the power, 2016-08-22 10:56:56]

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

[Sami, 2016-08-22 10:57:14]

Description was changed from

==========
scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG=638212
==========

to

==========
scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG=638212
==========

[Sami, 2016-08-22 10:57:15]

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

[Sami, 2016-08-22 10:57:23]

PTAL.

[Sami, 2016-08-22 11:10:36]

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

[commit-bot: I haz the power, 2016-08-22 11:10:50]

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

[alex clarke (OOO till 29th), 2016-08-22 11:30:10]

https://codereview.chromium.org/2266883002/diff/20001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc
(right):

https://codereview.chromium.org/2266883002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc:471:
if ((web_input_event.type == blink::WebInputEvent::MouseDown ||
Are we going to start blocking expensive tasks if the user clicks on something? 
Which ever way is decided, please add a test to lock in the behavior.

https://codereview.chromium.org/2266883002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc:532:
if (type != blink::WebInputEvent::Undefined) {
Perhaps handle this as a case in the switch?

[commit-bot: I haz the power, 2016-08-22 12:38:01]

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

[commit-bot: I haz the power, 2016-08-22 12:38:02]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Sami, 2016-08-22 13:25:15]

https://codereview.chromium.org/2266883002/diff/20001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc
(right):

https://codereview.chromium.org/2266883002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc:471:
if ((web_input_event.type == blink::WebInputEvent::MouseDown ||
On 2016/08/22 11:30:09, alex clarke wrote:
> Are we going to start blocking expensive tasks if the user clicks on
something? 
> Which ever way is decided, please add a test to lock in the behavior.

Right, we wouldn't want to do blocking based on a click. I've added a test.
Basically a mouse click now means main thread input handling, which can
prioritize compositing but won't block anything.

https://codereview.chromium.org/2266883002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc:532:
if (type != blink::WebInputEvent::Undefined) {
On 2016/08/22 11:30:09, alex clarke wrote:
> Perhaps handle this as a case in the switch?

Good idea -- makes more sense that way.

[alex clarke (OOO till 29th), 2016-08-22 14:59:55]

lgtm

[Sami, 2016-08-22 15:28:45]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2016-08-22 15:29:14]

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-08-22 17:16:33]

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

[commit-bot: I haz the power, 2016-08-22 17:16:34]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Sami, 2016-08-22 17:18:47]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2016-08-22 17:19:17]

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-08-22 18:05:13]

Description was changed from

==========
scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG=638212
==========

to

==========
scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG=638212
==========

[commit-bot: I haz the power, 2016-08-22 18:05:14]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-08-22 18:08:41]

Description was changed from

==========
scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG=638212
==========

to

==========
scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG=638212

Committed: https://crrev.com/1329d0ac5e235bd6a94ef3ac22947ea6acf67363
Cr-Commit-Position: refs/heads/master@{#413475}
==========

[commit-bot: I haz the power, 2016-08-22 18:08:42]

Patchset 4 (id:??) landed as
https://crrev.com/1329d0ac5e235bd6a94ef3ac22947ea6acf67363
Cr-Commit-Position: refs/heads/master@{#413475}