Add InputEvent and EventPacket types for batched input delivery

Add InputEvent and EventPacket types for batched input delivery

With the BufferedInputRouter, browser input events will be batched into packets
before being sent to the renderer.  Add a common InputEvent type that provides
id'ed carriage of either WebInputEvents or general IPC input messages. Also add
a composite EventPacket type for batched InputEvent transport and dispatch.

BUG=245499
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=221905

[jdduke (slow), 2013-07-24 16:14:45]

PTAL.  This is the first patch pulled from the megapatch at
https://codereview.chromium.org/19220002/.  Both browser and renderer changes
depend on these common types, so I'm sending this first.

[nduca, 2013-08-12 23:31:58]

Cray idea: break up into add input event patch and then a packet one. The review
circle for input event is going to broader...

[nduca, 2013-08-12 23:32:40]

https://codereview.chromium.org/19624005/diff/10001/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/10001/content/common/input/inpu...
content/common/input/input_event.h:28: IPC::Message message;
also why's it pickled? I would have expected this to be pre-pickling and be a
web input event now and then eventually have the fields on it and be the type we
hand around in content to refer to input events...

[jdduke (slow), 2013-08-12 23:45:27]

https://codereview.chromium.org/19624005/diff/10001/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/10001/content/common/input/inpu...
content/common/input/input_event.h:28: IPC::Message message;
On 2013/08/12 23:32:40, nduca wrote:
> also why's it pickled? I would have expected this to be pre-pickling and be a
> web input event now and then eventually have the fields on it and be the type
we
> hand around in content to refer to input events...

Well, I'm considering doing away with this completely, and insteading making the
InputEvent just a regular IPC::Message.  The reason we shouldn't (can't?) use
WebInputEvent here is that there are other input message types we need to
support (InputMsg_SelectRange, InputMsg_MoveCaret, etc...) in the EventPacket. 
This is part of why I'd like to remove the |state| from being paired with the
InputEvent; at that point our EventPacket is simply a nice little vector of IPC
messages.

The advantage to this approach is that it introduces very little friction with
the current cc/renderer event dispatch; we don't have to change anything, we
just dispatch the EventPacket messages.  Down the road, I think we'll want to
look closer at what the Right input event type for content/ is, but I fear
adoption will take more momentum than we have currently.

If you can think of a better approach, I'm all ears :)

[jdduke (slow), 2013-08-12 23:48:15]

"insteading", while a typo, sounds like it would make a great addition to the
English language.

[jdduke (slow), 2013-08-14 20:24:23]

PTAL.  InputEvent is no longer a glorified container for an IPC::Message.  This
should make it a bit less painful to use another InputEvent-derivative in the
future.  I'm also not married to the names "WebEvent" or "GenericEvent", so if
you can think of a better alternative...

I think if aelias@ does review for content/browser and content/renderer, and you
can review this patch (content/common), we should be in pretty good shape.

[nduca, 2013-08-15 01:22:46]

https://codereview.chromium.org/19624005/diff/18001/content/common/input/gene...
File content/common/input/generic_event.h (right):

https://codereview.chromium.org/19624005/diff/18001/content/common/input/gene...
content/common/input/generic_event.h:16: class CONTENT_EXPORT GenericEvent :
public InputEvent {
GenericInputEvent since it subtypes from InputEvent

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
content/common/input/input_event.h:16: enum Type {
can we use pure inheritance here and make this a pure virtual base class? Then
use ipc traits to get this to serialize sanely across the wire (and or make
explicit methods for conversion to ipc messages.

reason being: it'd be nice to see on this class the things we expect out of all
input events but not how they're implemented serialized etc.

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
File content/common/input/input_event_state.h (right):

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
content/common/input/input_event_state.h:12: enum InputEventState {
InputEventDisposition or InputEventHandlingResult?

[jdduke (slow), 2013-08-15 15:23:44]

https://codereview.chromium.org/19624005/diff/18001/content/common/input/gene...
File content/common/input/generic_event.h (right):

https://codereview.chromium.org/19624005/diff/18001/content/common/input/gene...
content/common/input/generic_event.h:16: class CONTENT_EXPORT GenericEvent :
public InputEvent {
On 2013/08/15 01:22:46, nduca wrote:
> GenericInputEvent since it subtypes from InputEvent

Done.

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
content/common/input/input_event.h:16: enum Type {
On 2013/08/15 01:22:46, nduca wrote:
> can we use pure inheritance here and make this a pure virtual base class? Then
> use ipc traits to get this to serialize sanely across the wire (and or make
> explicit methods for conversion to ipc messages.
> 
> reason being: it'd be nice to see on this class the things we expect out of
all
> input events but not how they're implemented serialized etc.

I think we need some kind of residual type data here to be able to serialize
based any given InputEvent (e.g., a vector of InputEvent's).  I could be wrong
(I'd love to be wrong), but this is the pattern I've seen used elsewhere
(cc::DrawQuad).  Can the IPC traits macro magic accomplish this automatically?

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
File content/common/input/input_event_state.h (right):

https://codereview.chromium.org/19624005/diff/18001/content/common/input/inpu...
content/common/input/input_event_state.h:12: enum InputEventState {
On 2013/08/15 01:22:46, nduca wrote:
> InputEventDisposition or InputEventHandlingResult?

Hmm... Disposition sounds good.

[jdduke (slow), 2013-08-16 00:12:20]

PTAL.  Bringing in aelias@ as he's a bit more familiar with the
BufferedInputRouter code, and might have some additional insights in how these
types should be formulated.

If we agree that this is the right general approach, I'll add appropriate unit
tests for the "custom" serialization code in input_param_traits.cc.  Thanks.

[nduca, 2013-08-27 18:45:35]

https://codereview.chromium.org/19624005/diff/39001/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/39001/content/common/input/inpu...
content/common/input/input_event.h:18: GENERIC,
In your explanation to me of this, you described it as a "non-web" input event
type. I think thats a promising approach. NonWebInput, WebInput perhaps

https://codereview.chromium.org/19624005/diff/39001/content/common/input/inpu...
content/common/input/input_event.h:31: Type type;
This class still feels very structy/tightly-coupled-to-transport to me, but
strangely so.

It seems in the end state, we're going to want to have:
- a place to put fields on input events that is only relevant to the host side
of the input system
- a place to put fields on input events that is only relevant to the renderer
side of the input system
- a place to put stuff common to both
- a way to take a host input event and send its renderer-specific parts over to
the other side of the world

How does that map in this world?

[nduca, 2013-08-27 22:16:07]

stale comments

https://codereview.chromium.org/19624005/diff/39001/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/39001/content/common/input/inpu...
content/common/input/input_event.h:23: enum AckType {
DispositionRequirement

https://codereview.chromium.org/19624005/diff/39001/content/common/input/inpu...
content/common/input/input_event.h:26: ACK_CAN_CREATE_FOLLOWUP_EVENTS
ACK_REQUIRED_AND_CAN_CREATE_FOLLOWUP

https://codereview.chromium.org/19624005/diff/39001/content/common/input/inpu...
content/common/input/input_event.h:32: AckType ack_type;
AckType GetDispoitionRequirements() const = 0;

[jdduke (slow), 2013-08-30 22:34:18]

nduca@, please see patch set #10 delta from crrev.com/19220002 for relevant
changes to the core types, as per our discussion.  I put the changes there (the
mega patch), as they make more sense when viewed together with how they affect
browser and renderer-specific event dispatch.

[nduca, 2013-09-03 21:48:57]

lgtm thank you

[jdduke (slow), 2013-09-03 22:28:51]

palmer@: content/common/input_messages.h for security? Thanks.

[aelias_OOO_until_Jul13, 2013-09-03 22:31:09]

lgtm with nits

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
File content/common/input/input_param_traits.cc (right):

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
content/common/input/input_param_traits.cc:91: l->append("))");
Nit: unbalanced parens

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
File content/common/input/input_param_traits_unittest.cc (right):

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
content/common/input/input_param_traits_unittest.cc:24: const unsigned a_size =
a->web_event()->size;
nit: size_t

[jdduke (slow), 2013-09-03 22:52:14]

jamesr@, this is the first patch to land for the BufferedInputRouter, for which
the tracking patch can be found here codereview.chromium.org/19220002/ 

If you'd like to scrutinize this patch in detail, please feel free; I really
just wanted to make sure you were aware of these additions in case you had any
specific comments/questions/concerns before we started pushing forward.

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
File content/common/input/input_param_traits.cc (right):

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
content/common/input/input_param_traits.cc:91: l->append("))");
On 2013/09/03 22:31:10, aelias wrote:
> Nit: unbalanced parens

Hmm, I think this is balanced, we just have Payload nested inside InputEvent.

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
File content/common/input/input_param_traits_unittest.cc (right):

https://codereview.chromium.org/19624005/diff/49001/content/common/input/inpu...
content/common/input/input_param_traits_unittest.cc:24: const unsigned a_size =
a->web_event()->size;
On 2013/09/03 22:31:10, aelias wrote:
> nit: size_t

Done.

[jamesr, 2013-09-03 23:03:22]

Is there a higher-level description or design doc explaining these types and how
they interact?

[palmer, 2013-09-03 23:12:47]

https://codereview.chromium.org/19624005/diff/50018/content/common/input/even...
File content/common/input/event_packet.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/even...
content/common/input/event_packet.h:25: // |event| should be non-NULL and valid.
Should, or must? What happens if I pass a NULL or invalid event in?

https://codereview.chromium.org/19624005/diff/50018/content/common/input/even...
content/common/input/event_packet.h:30: InputEvents::const_iterator begin()
const { return events.begin(); }
It seems like these accessors exist to hide the exact implementation (i.e., the
fact that |events| is a vector), but |events| is public. So this interface is
"partially encapsulated", if you will. I would decide to either make |events|
and |id| private (and provide accessors for |id|), or make them public and not
have these wrapper functions.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_event.h:28: // |id| should be non-zero and |payload|
should be non-NULL.
But the implementation doesn't enforce this. If it really matters, you should
enforce it and have defined semantics for what happens if the caller doesn't
meet the interface requirements.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_param_traits.cc (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.cc:29: if (!p.payload())
Maybe this should be

    if (!p.valid())

?

And maybe check validity before doing any writes at all?

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.cc:68: if (!payload)
Similar question about checking validity here.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_param_traits.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.h:39: param_type temp(new P());
Just to make sure I understand: You allocate a new P so that you don't update
|r| in the event that ReadParam fails — you want to leave |r| unchanged in case
of failure. But, for performance, can you change the interface to be, "Dear
caller, if this returns false, don't count on |r| being what it was before." ?

It seems like invoking new potentially often while serializing for IPC could be
slow.

If it is too late to change this or woudl break existing code or if I don't know
what I am talking about, feel free to ignore me. Just a thought I had.

https://codereview.chromium.org/19624005/diff/50018/content/common/input_mess...
File content/common/input_messages.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input_mess...
content/common/input_messages.h:35:
IPC_ENUM_TRAITS(content::InputEvent::Payload::Type)
IPC_ENUM_TRAITS() is deprecated; use IPC_ENUM_TRAITS_MAX_VALUE (or MIN) instead.

http://www.chromium.org/Home/chromium-security/security-tips-for-ipc

https://codereview.chromium.org/19624005/diff/50018/content/common/input_mess...
content/common/input_messages.h:36: IPC_ENUM_TRAITS(content::InputEventAckState)
Might as well change this one now, too.

[jdduke (slow), 2013-09-03 23:19:38]

On 2013/09/03 23:03:22, jamesr wrote:
> Is there a higher-level description or design doc explaining these types and
how
> they interact?

Yes, we have
https://docs.google.com/a/chromium.org/document/d/1CAOBAiodu8HojJX7x5aTYZq0EO...,
which is slightly out of date but gives a brief overview of the overall design.

[jdduke (slow), 2013-09-04 17:53:24]

https://codereview.chromium.org/19624005/diff/50018/content/common/input/even...
File content/common/input/event_packet.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/even...
content/common/input/event_packet.h:30: InputEvents::const_iterator begin()
const { return events.begin(); }
On 2013/09/03 23:12:47, Chromium Palmer wrote:
> It seems like these accessors exist to hide the exact implementation (i.e.,
the
> fact that |events| is a vector), but |events| is public. So this interface is
> "partially encapsulated", if you will. I would decide to either make |events|
> and |id| private (and provide accessors for |id|), or make them public and not
> have these wrapper functions.

Less for hiding and more for convenience, really.  The members are public only
for automated serialization via macros, but I think stricter enforcement here is
worth the custom serialization code.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_event.h:28: // |id| should be non-zero and |payload|
should be non-NULL.
On 2013/09/03 23:12:47, Chromium Palmer wrote:
> But the implementation doesn't enforce this. If it really matters, you should
> enforce it and have defined semantics for what happens if the caller doesn't
> meet the interface requirements.

Well, it's enforced via DCHECK, though I suppose it's not really necessary as
the user could create an invalid event via the empty constructor (necessary for
serialization...)

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_param_traits.cc (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.cc:29: if (!p.payload())
On 2013/09/03 23:12:47, Chromium Palmer wrote:
> Maybe this should be
> 
>     if (!p.valid())
> 
> ?
> 
> And maybe check validity before doing any writes at all?

Done.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.cc:68: if (!payload)
On 2013/09/03 23:12:47, Chromium Palmer wrote:
> Similar question about checking validity here.

Done.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_param_traits.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.h:39: param_type temp(new P());
On 2013/09/03 23:12:47, Chromium Palmer wrote:
> Just to make sure I understand: You allocate a new P so that you don't update
> |r| in the event that ReadParam fails — you want to leave |r| unchanged in
case
> of failure. But, for performance, can you change the interface to be, "Dear
> caller, if this returns false, don't count on |r| being what it was before." ?
> 
> It seems like invoking new potentially often while serializing for IPC could
be
> slow.
> 
> If it is too late to change this or woudl break existing code or if I don't
know
> what I am talking about, feel free to ignore me. Just a thought I had.

Well, param_type* r is a pointer to any empty scoped_ptr, meaning nothing has
been new'ed or allocated before the call to Read(). That is, we only allocate
the memory once, and we swap the allocated pointer with the empty scoped_ptr
that was passed in. I'm not sure that we can get more optimal than that?

https://codereview.chromium.org/19624005/diff/50018/content/common/input_mess...
File content/common/input_messages.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input_mess...
content/common/input_messages.h:35:
IPC_ENUM_TRAITS(content::InputEvent::Payload::Type)
On 2013/09/03 23:12:47, Chromium Palmer wrote:
> IPC_ENUM_TRAITS() is deprecated; use IPC_ENUM_TRAITS_MAX_VALUE (or MIN)
instead.
> 
> http://www.chromium.org/Home/chromium-security/security-tips-for-ipc

Done.

https://codereview.chromium.org/19624005/diff/50018/content/common/input_mess...
content/common/input_messages.h:36: IPC_ENUM_TRAITS(content::InputEventAckState)
On 2013/09/03 23:12:47, Chromium Palmer wrote:
> Might as well change this one now, too.

Done.

[jdduke (slow), 2013-09-05 00:01:21]

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_param_traits.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.h:39: param_type temp(new P());
On 2013/09/04 17:53:24, jdduke wrote:
> On 2013/09/03 23:12:47, Chromium Palmer wrote:
> > Just to make sure I understand: You allocate a new P so that you don't
update
> > |r| in the event that ReadParam fails — you want to leave |r| unchanged in
> case
> > of failure. But, for performance, can you change the interface to be, "Dear
> > caller, if this returns false, don't count on |r| being what it was before."
?
> > 
> > It seems like invoking new potentially often while serializing for IPC could
> be
> > slow.
> > 
> > If it is too late to change this or woudl break existing code or if I don't
> know
> > what I am talking about, feel free to ignore me. Just a thought I had.
> 
> Well, param_type* r is a pointer to any empty scoped_ptr, meaning nothing has
> been new'ed or allocated before the call to Read(). That is, we only allocate
> the memory once, and we swap the allocated pointer with the empty scoped_ptr
> that was passed in. I'm not sure that we can get more optimal than that?

Or perhaps you meant we should go ahead and assign the allocated memory to the
scoped_ptr, and simply return false if ReadParam of the underlying value type
fails?  That seems reasonable.

[palmer, 2013-09-05 01:20:15]

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_event.h:28: // |id| should be non-zero and |payload|
should be non-NULL.
> Well, it's enforced via DCHECK, though I suppose it's not really necessary as
> the user could create an invalid event via the empty constructor (necessary
for
> serialization...)

Yeah, DCHECK is not really enforcement. But on a closer look, I think you can
get by here by referring to the |valid| function in the comment. Something like,
"A valid InputEvent has a non-zero |id| and a non-NULL |payload|."

(True enforcement happens at run-time in the browser process.)

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_param_traits.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.h:39: param_type temp(new P());
No, I think you are right. I was trying to figure out if there is a way we can
avoid new-ing if ReadParam fails, but I don't think we can do it in a way that
would really be better. (E.g. we could read into a stack-allocated P, but then
we'd need to copy the value into |*r| anyway, and then what have we gained...)
So, nevermind...

[palmer, 2013-09-05 18:56:29]

LGTM with some questions.

https://codereview.chromium.org/19624005/diff/106001/content/common/input/inp...
File content/common/input/input_param_traits.cc (right):

https://codereview.chromium.org/19624005/diff/106001/content/common/input/inp...
content/common/input/input_param_traits.cc:103: break;
Does it make sense to try to Initialize for unknown payload types? Maybe we
should just return false here?

https://codereview.chromium.org/19624005/diff/106001/content/common/input/inp...
content/common/input/input_param_traits.cc:122: break;
Similar question here. I don't know the semantically-right answer, just
wondering.

https://codereview.chromium.org/19624005/diff/106001/content/common/input/web...
File content/common/input/web_input_event_payload.cc (right):

https://codereview.chromium.org/19624005/diff/106001/content/common/input/web...
content/common/input/web_input_event_payload.cc:46: else if (event->type ==
WebKit::WebInputEvent::MouseWheel)
No isMouseWheelEventType method?

[jdduke (slow), 2013-09-05 19:31:48]

Awesome, thanks for review palmer@.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_event.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_event.h:28: // |id| should be non-zero and |payload|
should be non-NULL.
On 2013/09/05 01:20:15, Chromium Palmer wrote:
> > Well, it's enforced via DCHECK, though I suppose it's not really necessary
as
> > the user could create an invalid event via the empty constructor (necessary
> for
> > serialization...)
> 
> Yeah, DCHECK is not really enforcement. But on a closer look, I think you can
> get by here by referring to the |valid| function in the comment. Something
like,
> "A valid InputEvent has a non-zero |id| and a non-NULL |payload|."
> 
> (True enforcement happens at run-time in the browser process.)

Done.

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
File content/common/input/input_param_traits.h (right):

https://codereview.chromium.org/19624005/diff/50018/content/common/input/inpu...
content/common/input/input_param_traits.h:39: param_type temp(new P());
On 2013/09/05 01:20:15, Chromium Palmer wrote:
> No, I think you are right. I was trying to figure out if there is a way we can
> avoid new-ing if ReadParam fails, but I don't think we can do it in a way that
> would really be better. (E.g. we could read into a stack-allocated P, but then
> we'd need to copy the value into |*r| anyway, and then what have we gained...)
> So, nevermind...

Yeah, that crossed my mind.  This operation *should* be relatively sparse; only
a few input events should be passed around each frame, and even in the
pathological case that's something we can tackle with browser-side coalescing if
need be. Otherwise, I'd share your concerns.

https://codereview.chromium.org/19624005/diff/106001/content/common/input/inp...
File content/common/input/input_param_traits.cc (right):

https://codereview.chromium.org/19624005/diff/106001/content/common/input/inp...
content/common/input/input_param_traits.cc:103: break;
On 2013/09/05 18:56:30, Chromium Palmer wrote:
> Does it make sense to try to Initialize for unknown payload types? Maybe we
> should just return false here?

Yeah, I imagine it would also make sense to NOTREACHED() here. It should never
happen so returning false immediately is probably the best solution.

https://codereview.chromium.org/19624005/diff/106001/content/common/input/inp...
content/common/input/input_param_traits.cc:122: break;
On 2013/09/05 18:56:30, Chromium Palmer wrote:
> Similar question here. I don't know the semantically-right answer, just
> wondering.

Right, good catch.

https://codereview.chromium.org/19624005/diff/106001/content/common/input/web...
File content/common/input/web_input_event_payload.cc (right):

https://codereview.chromium.org/19624005/diff/106001/content/common/input/web...
content/common/input/web_input_event_payload.cc:46: else if (event->type ==
WebKit::WebInputEvent::MouseWheel)
On 2013/09/05 18:56:30, Chromium Palmer wrote:
> No isMouseWheelEventType method?

No, it does seem a bit odd.  I believe it's nonexistence is because there's only
just the one MouseWheelEvent type, whereas the other "EventType" queries are
classes of gestures that have multiple types.

[jdduke (slow), 2013-09-06 18:29:01]

jam@: PTAL for owners, particularly content/*.gypi and content/port.  Thanks!

[jam, 2013-09-06 21:22:34]

On 2013/09/06 18:29:01, jdduke wrote:
> jam@: PTAL for owners, particularly content/*.gypi and content/port.  Thanks!

gypi and port lgtm

[commit-bot: I haz the power, 2013-09-06 21:47:24]

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

[commit-bot: I haz the power, 2013-09-06 23:29:31]

Sorry for I got bad news for ya.
Compile failed with a clobber build on win_x64_rel.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_x64_re...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-09-06 23:38:52]

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

[commit-bot: I haz the power, 2013-09-07 07:07:54]

Change committed as 221905