Implement AutomationNode.querySelector().

extensions/common/extension_messages.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.
 
 // IPC messages for extensions.
 // Multiply-included message file, hence no include guard.
 
 #include <string>
 #include <vector>
 
@@ skipping 732 matching lines @@
                      int /* element_instance_id */,
                      int /* guest_instance_id */,
                      base::DictionaryValue /* attach_params */)
 
 // Tells the browser to create a mime handler guest view for a plugin.
 IPC_MESSAGE_CONTROL4(ExtensionHostMsg_CreateMimeHandlerViewGuest,
                      int /* render_frame_id */,
                      std::string /* embedder_url */,
                      std::string /* mime_type */,
                      int /* element_instance_id */)
+
+// Sent when a query selector request is made from the automation API.
+// acc_obj_id is the accessibility tree ID of the starting element.
+IPC_MESSAGE_ROUTED3(ExtensionMsg_AutomationQuerySelector,
+                    int /* request_id */,
+                    int /* acc_obj_id */,
+                    base::string16 /* selector */)

[palmer, 2014/11/01 00:20:48]

What is the lexical/syntactic structure of these strings? Size limits, et c.? (I
have not read the other files in this CL yet.)

Are they CSS selectors? Can we limit their size, and verify that they correctly
parse as CSS selectors?

[aboxhall, 2014/11/03 17:27:11]

Yes, they're CSS selectors. Where should the size limits and verification go?

[aboxhall, 2014/11/03 22:35:19]

Actually, after looking into this further, I'm not sure this is technically
feasible. The CSS parser is in Blink, so I think I'd have to send an IPC to
parse it anyway, and I don't think there's any obvious value to pick for the
size length. I found at least one other point where we (eventually) send a
querySelector through an extension_messages IPC message:
https://code.google.com/p/chromium/codesearch#chromium/src/extensions/browser...
- so at least this isn't a regression? :)

+
+// Result of a query selector request.
+// result_acc_obj_id is the accessibility tree ID of the result element; 0
+// indicates no result.
+IPC_MESSAGE_ROUTED3(ExtensionHostMsg_AutomationQuerySelector_Result,
+                    int /* request_id */,
+                    std::string /* error */,

[palmer, 2014/11/01 00:20:48]

What's the range of these errors? Constrained, or infinite/large?

My instinct is normally to pass an error enum and then have the recipient
stringify it with a switch/case or an array of strings. (Benefits: Smaller and
faster IPC messages, less potentially-hostile data in the recipient's address
space, strongly-typed errors.)

[aboxhall, 2014/11/03 17:27:11]

An enum sounds good; should it live in this file?

[aboxhall, 2014/11/03 22:35:19]

Done.

+                    int /* result_acc_obj_id */)