Move middle-click autoscroll to synthetic fling.

Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt
similar on DPI=1 and 60fps at high speed, and with more range than before
at low speeds.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964
Review-Url: https://codereview.chromium.org/2918053002
Cr-Commit-Position: refs/heads/master@{#479931}
Committed: https://chromium.googlesource.com/chromium/src/+/5971e47dc08dbb773f58fd6fb13b1df7917fd295

[aelias_OOO_until_Jul13, 2017-06-02 02:11:54]

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

[commit-bot: I haz the power, 2017-06-02 02:12:24]

Dry run: 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, 2017-06-02 02:15:23]

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

[commit-bot: I haz the power, 2017-06-02 02:15:24]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[aelias_OOO_until_Jul13, 2017-06-02 02:38:09]

Description was changed from

==========
[WIP] Middle-click autoscroll

BUG=644488
==========

to

==========
[WIP] Middle-click autoscroll

BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-02 18:17:12]

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

[commit-bot: I haz the power, 2017-06-02 18:17:44]

Dry run: 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, 2017-06-02 19:30:31]

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

[commit-bot: I haz the power, 2017-06-02 19:30:31]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[aelias_OOO_until_Jul13, 2017-06-13 00:51:42]

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

[commit-bot: I haz the power, 2017-06-13 00:51:59]

Dry run: 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, 2017-06-13 03:16:15]

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

[commit-bot: I haz the power, 2017-06-13 03:16:16]

Dry run: This issue passed the CQ dry run.

[aelias_OOO_until_Jul13, 2017-06-14 04:10:53]

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

[commit-bot: I haz the power, 2017-06-14 04:11:06]

Dry run: 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, 2017-06-14 04:13:38]

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

[commit-bot: I haz the power, 2017-06-14 04:13:39]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[aelias_OOO_until_Jul13, 2017-06-14 04:48:33]

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

[commit-bot: I haz the power, 2017-06-14 04:48:53]

Dry run: 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, 2017-06-14 07:11:28]

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

[commit-bot: I haz the power, 2017-06-14 07:11:29]

Dry run: This issue passed the CQ dry run.

[aelias_OOO_until_Jul13, 2017-06-14 22:02:26]

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

[commit-bot: I haz the power, 2017-06-14 22:03:05]

Dry run: CQ is trying da patch.

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

[aelias_OOO_until_Jul13, 2017-06-14 22:15:15]

Description was changed from

==========
[WIP] Middle-click autoscroll

BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic, I refactored it into a
separate state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.

BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-14 22:22:51]

Description was changed from

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic, I refactored it into a
separate state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.

BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic, I refactored it into a
separate state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-14 22:24:02]

Description was changed from

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic, I refactored it into a
separate state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-14 22:26:19]

Description was changed from

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-14 22:31:05]

Description was changed from

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-14 22:33:09]

aelias@chromium.org changed reviewers:
+ bokan@chromium.org

[aelias_OOO_until_Jul13, 2017-06-14 22:33:45]

Hi bokan@, PTAL.

[commit-bot: I haz the power, 2017-06-15 00:32:27]

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

[commit-bot: I haz the power, 2017-06-15 00:32:28]

Dry run: This issue passed the CQ dry run.

[bokan, 2017-06-15 17:40:13]

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/Node.cpp (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/Node.cpp:2355: if (LocalFrame* frame =
GetDocument().GetFrame()) {
Nit: no braces

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/EventHandler.cpp (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:812: mouse_event.button !=
WebPointerProperties::Button::kMiddle) {
Does this mean that if the cursor leaves the window we'll cancel the auto scroll
if we were in the "toggle" mode but not if we were in the "holding" mode? Is
this the behaviour today?

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/MouseEventManager.h (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/MouseEventManager.h:129: IntPoint
LastKnownMousePosition();
Should this eventually become a FloatPoint as well? i.e. is the only reason you
didn't make it so because it could affect current callers? If so, could you add
a comment/TODO?

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/page/AutoscrollController.cpp (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/AutoscrollController.cpp:256: if
(middle_click_mode_ == kMiddleClickInitial && is_middle_button) {
Nit: no braces

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/AutoscrollController.cpp:263: void
AutoscrollController::StopMiddleClickAutoscroll(LocalFrame* frame) {
I don't see where you reset the cursor on stopping. Is it maybe the cursor
update timer is firing because a layout is triggered on on mouse up usually?
Should we explicitly call EventHandler::ScheduleCursorUpdate here?

[bokan, 2017-06-15 21:22:06]

I'm OOO tomorrow and all my replies were nits/questions so lgtm.

[aelias_OOO_until_Jul13, 2017-06-15 22:17:13]

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

[commit-bot: I haz the power, 2017-06-15 22:17:57]

Dry run: CQ is trying da patch.

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

[aelias_OOO_until_Jul13, 2017-06-15 22:19:54]

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/Node.cpp (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/Node.cpp:2355: if (LocalFrame* frame =
GetDocument().GetFrame()) {
On 2017/06/15 at 17:40:12, bokan wrote:
> Nit: no braces

Done.

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/EventHandler.cpp (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:812: mouse_event.button !=
WebPointerProperties::Button::kMiddle) {
On 2017/06/15 at 17:40:12, bokan wrote:
> Does this mean that if the cursor leaves the window we'll cancel the auto
scroll if we were in the "toggle" mode but not if we were in the "holding" mode?
Is this the behaviour today?

Yes, that's the preexisting behavior.

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/MouseEventManager.h (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/MouseEventManager.h:129: IntPoint
LastKnownMousePosition();
On 2017/06/15 at 17:40:13, bokan wrote:
> Should this eventually become a FloatPoint as well? i.e. is the only reason
you didn't make it so because it could affect current callers? If so, could you
add a comment/TODO?

Yes.  I added a TODO.

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/page/AutoscrollController.cpp (right):

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/AutoscrollController.cpp:256: if
(middle_click_mode_ == kMiddleClickInitial && is_middle_button) {
On 2017/06/15 at 17:40:13, bokan wrote:
> Nit: no braces

Done.

https://codereview.chromium.org/2918053002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/AutoscrollController.cpp:263: void
AutoscrollController::StopMiddleClickAutoscroll(LocalFrame* frame) {
On 2017/06/15 at 17:40:13, bokan wrote:
> I don't see where you reset the cursor on stopping. Is it maybe the cursor
update timer is firing because a layout is triggered on on mouse up usually?
Should we explicitly call EventHandler::ScheduleCursorUpdate here?

Good catch, there was a cursor reset bug if you released without moving on
sufficiently simple pages.  I added a call to ScheduleCursorUpdate, and I also
added some cursor shape logging to the tests to have more coverage here (though
the test framework is layout-happy enough I couldn't find a way to fail on this
exact bug, it's probably good enough).

[aelias_OOO_until_Jul13, 2017-06-15 22:26:52]

aelias@chromium.org changed reviewers:
+ kenrb@chromium.org

[aelias_OOO_until_Jul13, 2017-06-15 22:26:53]

+kenrb for view_messages.h security OWNERS

[kenrb, 2017-06-15 22:58:59]

ipc lgtm

[aelias_OOO_until_Jul13, 2017-06-15 23:02:27]

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

[commit-bot: I haz the power, 2017-06-15 23:02:46]

Dry run: 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, 2017-06-15 23:09:35]

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

[commit-bot: I haz the power, 2017-06-15 23:09:36]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[aelias_OOO_until_Jul13, 2017-06-15 23:09:40]

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

[commit-bot: I haz the power, 2017-06-15 23:10:03]

Dry run: 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, 2017-06-15 23:17:18]

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

[commit-bot: I haz the power, 2017-06-15 23:17:19]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)

[aelias_OOO_until_Jul13, 2017-06-15 23:53:56]

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

[commit-bot: I haz the power, 2017-06-15 23:54:19]

Dry run: 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, 2017-06-16 00:01:36]

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

[commit-bot: I haz the power, 2017-06-16 00:01:37]

Dry run: Try jobs failed on following builders:
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)

[aelias_OOO_until_Jul13, 2017-06-16 00:20:50]

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

[commit-bot: I haz the power, 2017-06-16 00:21:22]

Dry run: CQ is trying da patch.

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

[aelias_OOO_until_Jul13, 2017-06-16 00:25:00]

Description was changed from

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt pretty
similar on DPI=1 and 60fps.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt
similar on DPI=1 and 60fps at high speed, and more responsive than before
at low speeds.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-16 00:25:18]

Description was changed from

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt
similar on DPI=1 and 60fps at high speed, and more responsive than before
at low speeds.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt
similar on DPI=1 and 60fps at high speed, and with more range than before
at low speeds.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964
==========

[aelias_OOO_until_Jul13, 2017-06-16 00:27:44]

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

[commit-bot: I haz the power, 2017-06-16 00:27:55]

Dry run: 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, 2017-06-16 00:34:18]

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

[commit-bot: I haz the power, 2017-06-16 00:34:19]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)

[aelias_OOO_until_Jul13, 2017-06-16 01:27:15]

The CQ bit was checked by aelias@chromium.org

[aelias_OOO_until_Jul13, 2017-06-16 01:27:16]

The patchset sent to the CQ was uploaded after l-g-t-m from bokan@chromium.org,
kenrb@chromium.org
Link to the patchset: https://codereview.chromium.org/2918053002/#ps220001
(title: "Delete redundant cursor shape print")

[commit-bot: I haz the power, 2017-06-16 01:27:46]

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, 2017-06-16 02:39:41]

CQ is committing da patch.

Bot data: {"patchset_id": 220001, "attempt_start_ts": 1497576435872700,
"parent_rev": "0c7f6df48120d44213fabf09fb6b6b0cfe0c5f27", "commit_rev":
"af5258d9186d71bd30ee356108c8158de90dffe1"}

[commit-bot: I haz the power, 2017-06-16 02:39:54]

CQ is committing da patch.

Bot data: {"patchset_id": 220001, "attempt_start_ts": 1497576435872700,
"parent_rev": "9ede2cde5727eecdb377b57b32c5226d1d41c8ce", "commit_rev":
"5971e47dc08dbb773f58fd6fb13b1df7917fd295"}

[commit-bot: I haz the power, 2017-06-16 02:40:06]

Description was changed from

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt
similar on DPI=1 and 60fps at high speed, and with more range than before
at low speeds.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964
==========

to

==========
Move middle-click autoscroll to synthetic fling.

Middle-click autoscroll is the Windows feature where after clicking
middle mouse button, the page then scrolls at a velocity depending
on the distance of the mouse cursor from the start point.  It's
one of the few remaining scroll modalities still doing scroller latching
and animation entirely on the Blink main thread.  This patch moves
it to the standard fling animation codepaths, allowing these scrolls
to run on the compositor thread.

Notes:
- Middle-click autoscroll comes in "holding" and "toggle" modes.  This
was implicit in the previous "CanStop" logic: I refactored it into a
more explicit state machine.
- Device-scale-factor correctness seems to have regressed with the
"page zoom for DSF" refactor.  Middle-click autoscroll velocity became
faster and deadzone smaller on higher-DPI.  I brought back DPI normalization.
- I didn't match the exact previous velocity curve as the formula is
quite strange as well as framerate-dependent.  I tweaked values on a
simple exponentiation formula until I found something that felt
similar on DPI=1 and 60fps at high speed, and with more range than before
at low speeds.
- This type of fling is frequently zero-velocity without actually ending
(i.e. preserving the scroller latching), when the mouse cursor is within
the deadzone.  Thus FlingStart([0,0]) events are legal and expected.
- As a next step, I plan to move selection autoscroll and
drag-and-drop autoscroll to the same mechanism.  Then stuff like
autoscroll_layout_object_ and ScheduleMainThreadAnimation will be deleted
entirely.

TEST=fast/events/middleClickAutoscroll-*
BUG=727964

Review-Url: https://codereview.chromium.org/2918053002
Cr-Commit-Position: refs/heads/master@{#479931}
Committed:
https://chromium.googlesource.com/chromium/src/+/5971e47dc08dbb773f58fd6fb13b...
==========

[commit-bot: I haz the power, 2017-06-16 02:40:07]

Committed patchset #12 (id:220001) as
https://chromium.googlesource.com/chromium/src/+/5971e47dc08dbb773f58fd6fb13b...