MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler needs to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
Committed: https://crrev.com/b94b06c07b4dada802959a10f8753d3b1a2dcc03
Cr-Commit-Position: refs/heads/master@{#421082}

[tapted, 2016-07-29 07:50:20]

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

[commit-bot: I haz the power, 2016-07-29 07:50:33]

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

[tapted, 2016-07-29 07:53:19]

Description was changed from

==========
MacViews: Send scrollWheel events as ui::ET_SCROLL

BUG=355659, 615948
==========

to

==========
MacViews: Send scrollWheel events as ui::ET_SCROLL

BUG=355659, 615948
==========

[commit-bot: I haz the power, 2016-07-29 08:56:38]

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

[commit-bot: I haz the power, 2016-07-29 08:56:39]

Dry run: This issue passed the CQ dry run.

[tapted, 2016-08-15 08:50:18]

Description was changed from

==========
MacViews: Send scrollWheel events as ui::ET_SCROLL

BUG=355659, 615948
==========

to

==========
MacViews: Send scrollWheel events as ui::ET_SCROLL

Overview CL: http://crrev.com/2189583004

BUG=355659, 615948
==========

[tapted, 2016-09-22 05:32:19]

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

[commit-bot: I haz the power, 2016-09-22 05:32:31]

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, 2016-09-22 06:10:35]

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

[commit-bot: I haz the power, 2016-09-22 06:10:36]

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...)

[tapted, 2016-09-22 06:30:17]

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

[commit-bot: I haz the power, 2016-09-22 06:30:30]

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

[tapted, 2016-09-23 03:27:46]

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

[commit-bot: I haz the power, 2016-09-23 03:28:07]

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

[tapted, 2016-09-23 03:28:30]

Patchset #2 (id:20001) has been deleted

[tapted, 2016-09-23 03:28:42]

Patchset #2 (id:40001) has been deleted

[tapted, 2016-09-23 03:40:41]

Description was changed from

==========
MacViews: Send scrollWheel events as ui::ET_SCROLL

Overview CL: http://crrev.com/2189583004

BUG=355659, 615948
==========

to

==========
MacViews: Send scrollWheel events as ui::ET_SCROLL

Overview CL: http://crrev.com/2189583004

BUG=355659, 615948, 640457
==========

[tapted, 2016-09-23 03:40:57]

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

[commit-bot: I haz the power, 2016-09-23 03:41:14]

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

[tapted, 2016-09-23 03:56:48]

Description was changed from

==========
MacViews: Send scrollWheel events as ui::ET_SCROLL

Overview CL: http://crrev.com/2189583004

BUG=355659, 615948, 640457
==========

to

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler need to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (whose concrete type is
cc::LayerTreeHostImpl).

Overview CL: http://crrev.com/2189583004

BUG=355659, 615948, 640457
==========

[tapted, 2016-09-23 03:56:48]

tapted@chromium.org changed reviewers:
+ sadrul@chromium.org

[tapted, 2016-09-23 04:02:25]

Description was changed from

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler need to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (whose concrete type is
cc::LayerTreeHostImpl).

Overview CL: http://crrev.com/2189583004

BUG=355659, 615948, 640457
==========

to

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler need to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (whose concrete type is
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

[tapted, 2016-09-23 04:29:25]

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

[commit-bot: I haz the power, 2016-09-23 04:29:45]

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, 2016-09-23 05:31:56]

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

[commit-bot: I haz the power, 2016-09-23 05:31:57]

Dry run: This issue passed the CQ dry run.

[tapted, 2016-09-23 06:50:00]

Description was changed from

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler need to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (whose concrete type is
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

to

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler need to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

[tapted, 2016-09-23 06:50:21]

Patchset #6 (id:140001) has been deleted

[tapted, 2016-09-23 06:54:24]

tapted@chromium.org changed reviewers:
+ sky@chromium.org
- sadrul@chromium.org

[tapted, 2016-09-23 06:58:09]

Hi sky, please take a look. (Time for the next instalment of elastic scrolling
now that I'm back from vacation :). Thanks!

[sky, 2016-09-23 17:47:09]

I'm not a good reviewer for the all the mac event changes. Is there someone else
you can get to review them? Perhaps avi or thakis?

https://codereview.chromium.org/2193153002/diff/180001/content/browser/render...
File
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm
(right):

https://codereview.chromium.org/2193153002/diff/180001/content/browser/render...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:598:
EXPECT_EQ(123, [mac_event deltaX]);
123->delta_x and next line 321->delta_y?

https://codereview.chromium.org/2193153002/diff/180001/ui/events/cocoa/events...
File ui/events/cocoa/events_mac_unittest.mm (right):

https://codereview.chromium.org/2193153002/diff/180001/ui/events/cocoa/events...
ui/events/cocoa/events_mac_unittest.mm:79: std::vector<NSEvent*>* events);
Is there an equivalent to std::unique_ptr you can use to own the NSEvent?

https://codereview.chromium.org/2193153002/diff/180001/ui/events/event_consta...
File ui/events/event_constants.h (right):

https://codereview.chromium.org/2193153002/diff/180001/ui/events/event_consta...
ui/events/event_constants.h:168: enum EventMomentumPhase {
Is there a reason not to use an enum class here? Of course it would mean
changing the names from EM_PHASE_NONE to NONE, but enum class has many benefits.

[tapted, 2016-09-26 03:36:23]

Description was changed from

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler need to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

to

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler needs to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

[tapted, 2016-09-26 07:58:50]

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

[commit-bot: I haz the power, 2016-09-26 07:59: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, 2016-09-26 08:57:33]

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

[commit-bot: I haz the power, 2016-09-26 08:57:34]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[tapted, 2016-09-26 11:12:20]

tapted@chromium.org changed reviewers:
+ avi@chromium.org

[tapted, 2016-09-26 11:12:21]

+avi - could you take a look at the Mac Event handling and test event creation?
Also the sdk_forward_declarations change to get array subscripting syntax (see
below).

Also for OWNERS in:
 - base/mac/sdk_forward_declarations.h
 - c/b//renderer_host/input/web_input_event_builders_mac_unittest.mm

Thanks!

https://codereview.chromium.org/2193153002/diff/180001/content/browser/render...
File
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm
(right):

https://codereview.chromium.org/2193153002/diff/180001/content/browser/render...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:598:
EXPECT_EQ(123, [mac_event deltaX]);
On 2016/09/23 17:47:08, sky wrote:
> 123->delta_x and next line 321->delta_y?

Done.

https://codereview.chromium.org/2193153002/diff/180001/ui/events/cocoa/events...
File ui/events/cocoa/events_mac_unittest.mm (right):

https://codereview.chromium.org/2193153002/diff/180001/ui/events/cocoa/events...
ui/events/cocoa/events_mac_unittest.mm:79: std::vector<NSEvent*>* events);
On 2016/09/23 17:47:08, sky wrote:
> Is there an equivalent to std::unique_ptr you can use to own the NSEvent?

Done (made this more idiomatic).

scoped_nsobject works in a collection, but it's a little clumsy to use for the
autoreleased pointers returned by the cocoa_test_event_utils:: methods. There's
precedent for std::pair<NSEvent*> in t cocoa_test_event_utils.h too - but you
are correct that it's a little strange to put autoreleased ObjC objects into C++
collections.

The idiomatic ObjectiveC way to do this would be to return an NSArray*, which
will manage reference counts properly. NSArray syntax is historically kinda
gross, but since we only support 10.9+ there's a small tweak to
sdk_forward_declarations.h that will avoid most of the grossness.

https://codereview.chromium.org/2193153002/diff/180001/ui/events/event_consta...
File ui/events/event_constants.h (right):

https://codereview.chromium.org/2193153002/diff/180001/ui/events/event_consta...
ui/events/event_constants.h:168: enum EventMomentumPhase {
On 2016/09/23 17:47:08, sky wrote:
> Is there a reason not to use an enum class here? Of course it would mean
> changing the names from EM_PHASE_NONE to NONE, but enum class has many
benefits.

Done - No reason not to, apart from consistency with the others in this header.

https://codereview.chromium.org/2193153002/diff/220001/base/mac/sdk_forward_d...
File base/mac/sdk_forward_declarations.h (right):

https://codereview.chromium.org/2193153002/diff/220001/base/mac/sdk_forward_d...
base/mac/sdk_forward_declarations.h:121: -
(id)objectAtIndexedSubscript:(NSUInteger)idx;
@avi: can you think of a reason not to do this? It avoids "error:
'objectAtIndexedSubscript:' is only available on macOS 10.8 or newer
[-Werror,-Wunguarded-availability]" when using the subscripting syntax that came
with Xcode 4.4. I think it's safe now we only support 10.9+ (but it's almost
hard to believe nobody's added it yet :).

[Avi (use Gerrit), 2016-09-26 14:41:44]

I'm OK with all the files that you called me out as an owner for. LGTM

The rest all look reasonable. I can LG them too, though I'm wondering if
someone's done more recent event work than I have. Last time I dealt with
scrollwheels was years ago.

https://codereview.chromium.org/2193153002/diff/220001/base/mac/sdk_forward_d...
File base/mac/sdk_forward_declarations.h (right):

https://codereview.chromium.org/2193153002/diff/220001/base/mac/sdk_forward_d...
base/mac/sdk_forward_declarations.h:121: -
(id)objectAtIndexedSubscript:(NSUInteger)idx;
On 2016/09/26 11:12:21, tapted wrote:
> @avi: can you think of a reason not to do this? It avoids "error:
> 'objectAtIndexedSubscript:' is only available on macOS 10.8 or newer
> [-Werror,-Wunguarded-availability]" when using the subscripting syntax that
came
> with Xcode 4.4. I think it's safe now we only support 10.9+ (but it's almost
> hard to believe nobody's added it yet :).

I'm OK with you doing this. Maybe a compiler peep like Nico or Mark has an
issue.

Why not add the NSDictionary one while you're at it, though?

[sky, 2016-09-26 16:42:32]

LGTM

[tapted, 2016-09-27 00:38:23]

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

[commit-bot: I haz the power, 2016-09-27 00:39:05]

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

[tapted, 2016-09-27 01:25:29]

On 2016/09/26 14:41:44, Avi wrote:
> The rest all look reasonable. I can LG them too, though I'm wondering if
> someone's done more recent event work than I have. Last time I dealt with
> scrollwheels was years ago.

Doesn't look like it :). There's some stuff around scrolling at a higher level,
but I did some archaeology on the mac-specific stuff - the mouse event code in
web_input_event_builders_mac.mm (and its various moves/renames) have been
largely untouched since 2009 (http://crrev.com/12488) - just an Apple change
from 2011 (http://wkrev.com/96613). http://wkbug.com/24813 has some notes about
the CGEvent usage there (and why it's not ideal) - we still need CGEvent APIs to
construct testing events, but I've been able to avoid it so far for
ui/events/cocoa/events_mac.mm . WebKit seems to have moved away from them
already -
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/mac/PlatformEven...

https://codereview.chromium.org/2193153002/diff/220001/base/mac/sdk_forward_d...
File base/mac/sdk_forward_declarations.h (right):

https://codereview.chromium.org/2193153002/diff/220001/base/mac/sdk_forward_d...
base/mac/sdk_forward_declarations.h:121: -
(id)objectAtIndexedSubscript:(NSUInteger)idx;
On 2016/09/26 14:41:44, Avi wrote:
> On 2016/09/26 11:12:21, tapted wrote:
> > @avi: can you think of a reason not to do this? It avoids "error:
> > 'objectAtIndexedSubscript:' is only available on macOS 10.8 or newer
> > [-Werror,-Wunguarded-availability]" when using the subscripting syntax that
> came
> > with Xcode 4.4. I think it's safe now we only support 10.9+ (but it's almost
> > hard to believe nobody's added it yet :).
> 
> I'm OK with you doing this. Maybe a compiler peep like Nico or Mark has an
> issue.
> 
> Why not add the NSDictionary one while you're at it, though?

Done.

[tapted, 2016-09-27 01:46:10]

The CQ bit was unchecked by tapted@chromium.org

[tapted, 2016-09-27 01:46:16]

The CQ bit was checked by tapted@chromium.org

[tapted, 2016-09-27 01:46:17]

The patchset sent to the CQ was uploaded after l-g-t-m from avi@chromium.org,
sky@chromium.org
Link to the patchset: https://codereview.chromium.org/2193153002/#ps240001
(title: " NSDictionary subscripting")

[commit-bot: I haz the power, 2016-09-27 01:46:49]

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-09-27 02:16:34]

Description was changed from

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler needs to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

to

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler needs to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

[commit-bot: I haz the power, 2016-09-27 02:16:35]

Committed patchset #10 (id:240001)

[commit-bot: I haz the power, 2016-09-27 02:19:07]

Description was changed from

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler needs to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457
==========

to

==========
MacViews: Send Mac scrollWheel NSEvents as ui::ET_SCROLL (ui::ScrollEvent).

On Mac, mouse wheel ticks and two-finger trackpad scroll events both
arrive via -[NSView scrollWheel:]. These are currently converted to a
ui::MouseWheel. However, ui::MouseWheel doesn't have the necessary event
phase information that the cc::InputHandler needs to properly calculate
scroll elasticity.

ui::ScrollEvent is a closer fit, but Mac generates a continuous event
"stream" through the momentum portion of a scroll "flick". To support
this, add an EventMomentumPhase enum, and populate the ScrollEvent with
it.  EventMomentumPhase is a simplified representation of the phase
information on the native NSEvent: it hides states that don't matter to
the scrolling machinery for the cc::InputHandler (i.e.
cc::LayerTreeHostImpl).

Elastic scrolling overview CL: http://crrev.com/2189583004

Add test coverage by fleshing out cocoa_test_event_utils::
TestScrollEvent(..). Fixes possible flakiness in tests using that method
since it didn't previously set event flags explicitly to zero. The
result could be that NSEvent uses the current global keyboard state to
populate its event flags, which could be influenced by tests running in
parallel.

BUG=355659, 615948, 640457

Committed: https://crrev.com/b94b06c07b4dada802959a10f8753d3b1a2dcc03
Cr-Commit-Position: refs/heads/master@{#421082}
==========

[commit-bot: I haz the power, 2016-09-27 02:19:08]

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