WIP Add getCoalescedEvents API using vector of WebInputEvents

content/common/DEPS

Index: content/common/DEPS
diff --git a/content/common/DEPS b/content/common/DEPS
index 66adccce7df099b68495bdbba966ba90a7a1e58e..bbe00edb5ea6d4c2be8910e4e44ff6cddbdce651 100644
--- a/content/common/DEPS
+++ b/content/common/DEPS
@@ -9,6 +9,7 @@ include_rules = [
   # No inclusion of WebKit from the browser, other than strictly enum/POD,
   # header-only types, and some selected common code.
   "-third_party/WebKit",
+  "+third_party/WebKit/public/platform/CoalescedWebInputEvent.h",

[Navid Zolghadr, 2016/11/16 17:17:38]

Dave, is this okay to include such a object like CoalescedWebInputEvent here? It
doesn't seem to be inline with the comment above. If not I won't be able to
modify the ScopedWebInputEventWithLatencyInfo to contain a coalesced event and I
should find another place to keep that structure.

[jbroman, 2016/11/22 15:27:37]

Is there a lot of value to doing this, as opposed to just carrying around
std::vector until we call into Blink? Yes it's another copy, but I think we'd
rather move toward having _less_ Blink code running in the browser process, not
more. (It's tricky, because using certain Blink classes requires Blink to be
initialized, which it is not in the browser process.)

[Navid Zolghadr, 2016/11/22 15:38:04]

So you are suggesting something like what I had in the patchset 1 right?

[jbroman, 2016/11/22 16:02:39]

Discussed offline. It'd be nice not to expand this list at all, but something
that was at least all in the header (and doesn't require linking any non-inline
Blink code) would probably be okay. Do check with esprehn@ and content/OWNERS,
though, because this is likely to be controversial.

[Navid Zolghadr, 2016/11/22 16:59:54]

esprehn@, jochen@ what do you think about this?
We need a class here (in this patched it is called CoalescedWebInputEvent which
represents both the WebInputEvent and all its coalesced events. Not that the
WebInputEvent is a polymorphic class and we seem to have a custom logic for
deletion instead of using virtual destructors. Here is some context in the
design doc:
https://docs.google.com/a/chromium.org/document/d/1x-e8fH3I0DBrmrNufPQwRJHMYn...

So is it okay to have the code outside of Blink to depend on such a class? If no
what if we move the code in the CoalescedWebInputEvent.cpp file (which is mainly
a container logic) to the CoalescedWebInputEvent.h?

   "+third_party/WebKit/public/platform/WebAddressSpace.h",
   "+third_party/WebKit/public/platform/WebCString.h",
   "+third_party/WebKit/public/platform/WebDisplayMode.h",