Add InputEvent and EventPacket types for batched input delivery

content/common/input/input_event.h

Index: content/common/input/input_event.h
diff --git a/content/common/input/input_event.h b/content/common/input/input_event.h
new file mode 100644
index 0000000000000000000000000000000000000000..e44da6964dd4e0fd17a2f1cafdd17330898796cf
--- /dev/null
+++ b/content/common/input/input_event.h
@@ -0,0 +1,37 @@
+// Copyright (c) 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_COMMON_INPUT_INPUT_EVENT_H_
+#define CONTENT_COMMON_INPUT_INPUT_EVENT_H_
+
+#include "content/common/content_export.h"
+#include "content/common/input/input_event_state.h"
+#include "content/common/input/input_event_type.h"
+#include "ipc/ipc_message.h"
+
+namespace content {
+
+class CONTENT_EXPORT InputEvent {
+ public:
+  InputEvent(int64 id, InputEventType type, const IPC::Message& message);
+  InputEvent();
+  ~InputEvent();
+
+  // The unique event id.
+  int64 id;
+
+  // Whether the event needs an ACK, or can create follow-up events.
+  InputEventType type;
+
+  // The pickled event payload.
+  IPC::Message message;

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

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]

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

+
+  // The current state of the event. This may change as the event is handled
+  // by various parts of the input pipeline, both in the browser and renderer.
+  InputEventState state;
+};
+
+} // namespace content
+
+#endif // CONTENT_COMMON_INPUT_INPUT_EVENT_H_