Add setSelection function to automation API.

chrome/common/extensions/api/automation.idl

 // 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.
 
 // The <code>chrome.automation</code> API allows developers to access the
 // automation (accessibility) tree for the browser. The tree resembles the DOM
 // tree, but only exposes the <em>semantic</em> structure of a page. It can be
 // used to programmatically interact with a page by examining names, roles, and
 // states, listening for events, and performing actions on nodes.
 [nocompile] namespace automation {
@@ skipping 294 matching lines @@
   };
 
   // A listener for changes on the <code>AutomationNode</code> tree.
   callback TreeChangeObserver = void(TreeChange treeChange);
 
   // A single node in an Automation tree.
   [nocompile, noinline_doc] dictionary AutomationNode {
     // The root node of the tree containing this AutomationNode.
     AutomationNode root;
 
-    // Whether this AutomationNode is root node.
+    // Whether this AutomationNode is a root node.
     boolean isRootNode;
 
     // The role of this node.
     automation.RoleType role;
 
     // The $(ref:automation.StateType)s describing this node.
     object state;
 
     // The rendered location (as a bounding box) of this node within the frame.
     automation.Rect location;
@@ skipping 89 matching lines @@
     long textSelStart;
 
     // The character index of the end of the selection within this editable
     // text element; -1 if no selection.
     long textSelEnd;
 
     // The input type, like email or number.
     DOMString textInputType;
 
     //
+    // Tree selection attributes (available on root nodes only)
+    //
+
+    // The anchor node of the tree selection, if any.
+    AutomationNode? anchorObject;
+    // The anchor offset of the tree selection, if any.
+    long? anchorOffset;
+    // The focus node of the tree selection, if any.
+    AutomationNode? focusObject;
+    // The focus offset of the tree selection, if any.
+    long? focusOffset;
+
+    //
     // Range attributes.
     //
 
     // The current value for this range.
     double valueForRange;
 
     // The minimum possible value for this range.
     double minValueForRange;
 
     // The maximum possible value for this range.
@@ skipping 111 matching lines @@
     [nocompile] static void getDesktop(RootCallback callback);
 
     // Add a tree change observer. Tree change observers are static/global, they
     // listen to changes across all trees.
     [nocompile] static void addTreeChangeObserver(
         TreeChangeObserver observer);
 
     // Remove a tree change observer.
     [nocompile] static void removeTreeChangeObserver(
         TreeChangeObserver observer);
+
+    // Sets the selection in a tree. This creates a selection in a single
+    // tree (anchorObject and focusObject must have the same root).
+    // Everything in the tree between the two node/offset pairs gets included
+    // in the selection. The anchor is where the user started the selection,
+    // while the focus is the point at which the selection gets extended
+    // e.g. when dragging with a mouse or using the keyboard.  For nodes with
+    // the role staticText, the offset gives the character offset within
+    // the value where the selection starts or ends, respectively.
+    [nocompile] static void setDocumentSelection(
+        [instanceOf=AutomationNode] object anchorObject,
+        long anchorOffset,
+        [instanceOf=AutomationNode] object focusObject,
+        long focusOffset);

[not at google - send to devlin, 2015/10/05 12:56:02]

I'd make this an object with properties "anchorObject", "anchorOffset",
"focusObject", and "focusOffset". I.e. you'd call the function like:

chrome.automation.setDocumentSelection({
  anchorObject: ...,
  anchorOffset: ...,
  focusObject: ...,
  focusOffset: ...,
});

It'd more similar to the OO Range object
(https://developer.mozilla.org/en-US/docs/Web/API/Range) in that it has named
properties vs having a long constructor. Also, it's generally easier to read,
and idiomatic for extension APIs.

You could consider lifting the properties you've added to AutomationNode into a
shared data type (like SelectionRange) but personally I would't bother, since
it's simpler the way you have it, and more consistent with AutomationNode.

   };
 };