Route selection bounds updates through the compositor

cc/output/selection_handle.h

+// Copyright (c) 2012 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 CC_OUTPUT_SELECTION_HANDLE_H_
+#define CC_OUTPUT_SELECTION_HANDLE_H_
+
+#include "cc/base/cc_export.h"
+#include "ui/gfx/geometry/rect_f.h"
+
+namespace cc {
+
+struct CC_EXPORT SelectionHandle {
+  enum Type { LEFT, RIGHT, CENTER, NONE, IGNORED, TYPE_LAST = IGNORED };
+
+  SelectionHandle();
+  ~SelectionHandle();
+
+  Type type;
+  gfx::RectF bounds;
+  bool visible;

[aelias_OOO_until_Jul13, 2014/06/03 05:30:27]

This boolean feels a bit out of place here, since the other fields are
determined by Blink (in cc::Layer) but this is a mutable temporary value.  What
does the browser do with nonvisible handles anyway, could they be replaced with
nonexistent handles in the IPC transport?

[jdduke (slow), 2014/06/03 15:12:50]

I considered that.  The trouble is the way we handle dragging. We currently send
both endpoints when you start dragging a handle, including the position of the
"fixed" handle position. However, if we don't have the latest position for the
"invisible" handle, we'll get some wonky behavior.  I imagine the proper fix for
that is allowing you to independently update one of the handles from the
browser, but that may require a good amount of wiring.

+};
+
+inline bool operator==(const SelectionHandle& lhs, const SelectionHandle& rhs) {
+  return lhs.type == rhs.type && lhs.visible == rhs.visible &&
+         lhs.bounds == rhs.bounds;
+}
+
+inline bool operator!=(const SelectionHandle& lhs, const SelectionHandle& rhs) {
+  return !(lhs == rhs);
+}
+
+}  // namespace cc
+
+#endif  // CC_OUTPUT_SELECTION_HANDLE_H_