Return a enumeration of the state of handling of InputEvents.

third_party/WebKit/public/platform/WebInputEventResult.h

Index: third_party/WebKit/public/platform/WebInputEventResult.h
diff --git a/third_party/WebKit/public/platform/WebInputEventResult.h b/third_party/WebKit/public/platform/WebInputEventResult.h
new file mode 100644
index 0000000000000000000000000000000000000000..0694239d3fffdeeb83a9bff012a7988306df17ef
--- /dev/null
+++ b/third_party/WebKit/public/platform/WebInputEventResult.h
@@ -0,0 +1,18 @@
+// Copyright 2015 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 WebInputEventResult_h
+#define WebInputEventResult_h
+
+namespace blink {
+
+enum class WebInputEventResult {
+    NotHandled, // consumed by neither script or default handler
+    HandledScript, // consumed by a script handler (ie. preventDefault called)

[Rick Byers, 2015/11/23 21:59:55]

I wonder, is "script" too restrictive here?  What if we have a case where we
handle the event in C++ outside the default handler.  I know this violates
Anne's model for DOM events, but I think a couple places may exist and it may be
necessary for some layered-platform scenarios.

So we could call this HandledNonDefault or maybe even just Handled.

Or maybe 'Script' is the best way to describe this concisely and we should just
clarify in the comment that in rare cases this may still mean C++ code.

Or maybe (after looking at your use cases) the real distinction here IS script
vs. internal.  In which case HandledScript vs. HandledInternal may be the right
terminology.

The key question is: for all cases where you're saying HandledDefaultHandler,
are we sure that logic runs only when the event has gone unhandled in JS, and is
never run via dispatching a synthetic event from JS.

+    HandledDefaultHandler // consumed by a default handler
+};
+
+} // namespace blink
+
+#endif // WebInputEventResult_h