Expose public interface for composited selection bounds

public/platform/WebSelectionBound.h

+// Copyright 2014 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 WebSelectionBound_h
+#define WebSelectionBound_h
+
+#include "public/platform/WebRect.h"
+
+namespace blink {
+
+// An endpoint for an active selection region.
+struct WebSelectionBound {
+    enum Type {
+        Caret,
+        SelectionLeft,
+        SelectionRight
+    };
+
+    explicit WebSelectionBound(Type type)
+        : type(type)
+        , layerId(0)
+    {
+    }
+
+    // The logical type of the endpoint. Note that this is dependent not only on
+    // the bound's relative location, but also the underlying text direction.
+    Type type;
+
+    // The id of the platform layer to which the bound should be anchored.
+    int layerId;
+
+    // The bound endpoint region in layer coordinates, not to be confused with
+    // the selection region.
+    WebRect layerRect;

[abarth-chromium, 2014/06/25 22:27:03]

Is this the rect of the handle itself?  It sounds like it might be a
one-dimensional rect that represents the edge of the selection...

Maybe this class would be better named WebSelectionEdge?

[jdduke (slow), 2014/06/25 22:58:10]

Hmm, I'm not actually sure if they're always one-dimensional (in the existing
unified patch), although for all intents and purposes I believe we've always
ignored the endpoint widths with the existing selection bound pipeline.  I'll
make sure that's enforced, as I can't see what use the width parameter would
have.

I somewhat prefer the name bound for the overall type, if only because it fits
with the existing concept of "selection bounds", but I'll rename the rect
variable to indicate the edge geometry.  Once all platforms are on board and we
can remove the current selection bounds plumbing, it may make sense to do some
renaming.

+};
+
+} // namespace blink
+
+#endif