Add a WebContentsImpl API to snapshot the accessibility tree.

content/browser/web_contents/web_contents_impl.cc

Index: content/browser/web_contents/web_contents_impl.cc
diff --git a/content/browser/web_contents/web_contents_impl.cc b/content/browser/web_contents/web_contents_impl.cc
index 6626ab0c93e3221f62e0920b824deca043d82f7c..c94689ca8d1a1646eb77270aaeec0e5aa49d81d1 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -722,6 +722,12 @@ void WebContentsImpl::RemoveAccessibilityMode(AccessibilityMode mode) {
   SetAccessibilityMode(RemoveAccessibilityModeFrom(accessibility_mode_, mode));
 }
 
+void WebContentsImpl::RequestAXTreeSnapshot(AXTreeSnapshotCallback callback) {
+  // TODO(dmazzoni): this only returns the accessibility tree from the main
+  // frame and everything in the same site instance.

[Charlie Reis, 2015/04/02 23:09:06]

How will this work for OOPIFs?

[dmazzoni, 2015/04/03 22:49:42]

Yes - to address this and your question above, here's why it's not so trivial to
implement OOPIF support as-is. RIght now the OOPIF accessibility code assumes
that you first enable accessibility for the frame, then every time
RenderFrameHostImpl::OnAccessibilityEvents is called we update
FrameAccessibility with the information about which frame is the child of which
host element in its parent frame.

In order to do a snapshot, we'd need to send a request to each frame, then take
the responses and use that info to combine everything into one frame tree. At a
minimum it will mean refactoring out the part of OnAccessibilityEvents that
deals with the frame info and putting that somewhere else that we could also
call from here.

Basically it's making me think that there must be a way to simplify the current
code.

I've been hung up on the idea that I don't want to put a |process id, routing
id| pair directly into an accessibility tree since the data structure is defined
in ui/accessibility (outside of content/) and is also used by views/ and
chromeos/ - I don't like the idea of sticking a field called "routing id" there,
it feels like it's leaking a content/ internal implementation detail out.

I still like the idea of a frame accessibility id - I'd have each AX tree on the
renderer side make a blocking call to the browser process to get its own frame
accessibiltiy id and the id of any child frames it knows about. That way the
returned accessibility trees would be trivial to reassemble/compose into a
larger tree, it'd make the whole FrameAccessibility class unnecessary.

We could use the frame tree node id for this, or we could make up a new id, it
doesn't really matter.

This is nearly exactly the same issue we have trying to implement the automation
API, where an extension process is now the one trying to compose multiple trees
into one - but the extension process doesn't have the ability to directly query
the frame tree node map. That's why I really lean towards the idea of making
each frame's accessibility tree really contain globally-unique ways to identify
its child frames, rather than the process_id/routing_id pair we're using now,
which requires extra work to interpret.

[Charlie Reis, 2015/04/06 21:56:51]

I'm open to the idea of using a different set of IDs for your case, but there's
still two requirements:

1) We need to be able to verify that renderer isn't lying about which
accessibility trees it can access.  It's a security bug if evil.com's renderer
process can generate fake content for a chrome:// page, for example.

2) We shouldn't be using synchronous IPCs for it.  Sync IPCs have caused a lot
of headaches in the past, and on top of that they're limited to the IO thread. 
Most of the accessibility stuff is on the UI thread, right?  (Feel free to chat
with jam@ for more reasons not to use sync IPCs.)

[dmazzoni, 2015/04/09 18:39:01]

Note that this is a sync IPC from the renderer to the browser, which is how the
renderer currently gets a routing ID for a new frame. I'm not sure how this is
any different.

Actually it'd probably work fine to use async IPCs. We can just write the logic
so that accessibility messages aren't sent while we're waiting on one of those
IPCs to get frame IDs.

Anyway, let's defer this to a follow-up changelist. I'm hoping it will be
possible to land this change in the meantime.

[Charlie Reis, 2015/04/10 20:18:07]

Which IPC are you referring to by "this is a sync IPC?"
Agreed.

+  GetMainFrame()->RequestAXTreeSnapshot(callback);
+}
+
 void WebContentsImpl::ClearNavigationTransitionData() {
   FrameTreeNode* node = frame_tree_.root();
   node->render_manager()->ClearNavigationTransitionData();