SyntheticGestureTarget implementation for injecting synthetic input events

content/browser/renderer_host/input/synthetic_gesture_target_base.h

+// Copyright 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_BROWSER_RENDERER_HOST_INPUT_SYNTHETIC_GESTURE_TARGET_BASE_H_
+#define CONTENT_BROWSER_RENDERER_HOST_INPUT_SYNTHETIC_GESTURE_TARGET_BASE_H_
+
+#include "base/time/time.h"
+#include "content/browser/renderer_host/input/synthetic_gesture_target.h"
+
+namespace ui {
+struct LatencyInfo;
+}
+
+namespace WebKit {
+class WebTouchEvent;
+class WebMouseEvent;
+class WebMouseWheelEvent;
+}
+
+namespace content {
+
+class RenderWidgetHostView;
+
+class SyntheticGestureTargetBase : public SyntheticGestureTarget {
+ public:
+  explicit SyntheticGestureTargetBase(RenderWidgetHostView* render_view);

[jdduke (slow), 2013/10/30 19:02:43]

Are there issues with holding a host view reference in the host widget?  Or will
the controller be destroyed if the view goes away?

[Dominik Grewe, 2013/10/30 19:11:59]

The controller (currently) lives in RWHI so is independent of the view as far as
I understand. Should we have RWHI instead? Then we can call
RenderWidgetHostImpl::GetView() whenever needed.

[jdduke (slow), 2013/10/31 00:52:51]

Either will probably be fine, though I'm not really an authority on View vs
Widget lifetimes so maybe somebody else can speak to that.

[aelias_OOO_until_Jul13, 2013/10/31 01:47:48]

Based on the comment in render_widget_host_impl.h (near view_), RWHI can outlive
RWHV.  I agree it seems safer to hold a pointer back to RWHI.

[kouhei (in TOK), 2013/10/31 04:26:36]

Done.

+  ~SyntheticGestureTargetBase();
+
+  virtual void QueueWebTouchEventToPlatform(
+      const WebKit::WebTouchEvent& web_touch,
+      const ui::LatencyInfo& latency_info);
+
+  virtual void QueueWebMouseWheelEventToPlatform(
+      const WebKit::WebMouseWheelEvent& web_wheel,
+      const ui::LatencyInfo& latency_info);
+
+  virtual void QueueWebMouseEventToPlatform(
+      const WebKit::WebMouseEvent& web_mouse,
+      const ui::LatencyInfo& latency_info);
+
+  // SyntheticGestureTarget:
+  virtual void QueueInputEventToPlatform(const InputEvent& event) OVERRIDE;
+
+  virtual void OnSyntheticGestureCompleted(
+      SyntheticGestureNew::Result result) OVERRIDE;
+
+  virtual base::TimeDelta GetSyntheticGestureUpdateRate() const OVERRIDE;

[aelias_OOO_until_Jul13, 2013/10/31 01:47:48]

Why should the target decide this rate?  Can we make the constant live in the
telemetry code instead?

+
+  virtual SyntheticGestureParams::GestureSourceType
+      GetDefaultSyntheticGestureSourceType() const OVERRIDE;

[aelias_OOO_until_Jul13, 2013/10/31 01:47:48]

Likewise, can telemetry decide this without asking the target?

+  virtual bool SupportsSyntheticGestureSourceType(

[aelias_OOO_until_Jul13, 2013/10/31 01:47:48]

Can we also remove this and just mandate that all targets must support all
types?

[aelias_OOO_until_Jul13, 2013/10/31 01:51:41]

Sorry, leftover comment before I noticed the Android implementation doesn't
support mouse events.  We don't have to add mouse event support to Android (even
though mice are actually supported on Android), although I'm still not sure this
method is useful for callers in practice for anything beyond DCHECKs.

+      SyntheticGestureParams::GestureSourceType gesture_source_type) const
+      OVERRIDE;
+
+ protected:
+  RenderWidgetHostView* render_view() { return render_view_; }
+
+ private:
+  RenderWidgetHostView* render_view_;
+
+  DISALLOW_COPY_AND_ASSIGN(SyntheticGestureTargetBase);
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_RENDERER_HOST_INPUT_SYNTHETIC_GESTURE_TARGET_BASE_H_