Complete live region support in ChromeVox Next.

chrome/common/extensions/api/automation.idl

Index: chrome/common/extensions/api/automation.idl
diff --git a/chrome/common/extensions/api/automation.idl b/chrome/common/extensions/api/automation.idl
index f9037c5878f85f3214f68d1043a126e0fc590f90..41f236511770006d80bdfab9bcf77f5056fb50f4 100644
--- a/chrome/common/extensions/api/automation.idl
+++ b/chrome/common/extensions/api/automation.idl
@@ -317,6 +317,12 @@
     TreeChangeType type;
   };
 
+  enum TreeChangeObserverMask {

[David Tseng, 2015/11/24 18:46:30]

This isn't really a mask since I don't think they're bit-wise orable?

[dmazzoni, 2015/11/30 22:00:46]

Changed to Filter.

+    noTreeChanges,
+    liveRegionTreeChanges,
+    allTreeChanges
+  };
+
   // A listener for changes on the <code>AutomationNode</code> tree.
   callback TreeChangeObserver = void(TreeChange treeChange);
 
@@ -571,8 +577,14 @@
     // screen views. Note this API is currently only supported on Chrome OS.
     [nocompile] static void getDesktop(RootCallback callback);
 
+    // Set the type of tree change events you want to receive when
+    // calling addTreeChangeObserver.
+    [nocompile] static void setTreeChangeObserverMask(

[Peter Lundblad, 2015/11/20 13:42:59]

I assume this mask is per extension.  IN any case, since you can add more
than one observer, I think it'd make sense to allow a separate mask per
observer. That would allow diferent parts of the user of this api todo
be less coupled.

[dmazzoni, 2015/11/23 20:16:50]

That would be ideal, but it would significantly complicate the implementation so
I'd prefer to leave it like this for now.

The issue is that the mask is implemented in C++, but the registration of
observers happens in the JS bindings layer. The significant performance benefit
of this change happens because we can avoid calls from C++ into JS for the vast
majority of tree changes now.

I'm open to fixing this later if we actually need it. OK to leave it like this
for now?

[David Tseng, 2015/11/24 18:46:30]

I think, this looks a little like re-inventing the node-based eventing we have
(just articulated a little differently). Having listeners there that add
listeners for specific events, looks kind of like what we're adding onto here.

[dmazzoni, 2015/11/26 00:08:04]

The exception here is the onRemoved callback. Right now it gets called *before*
the node gets removed, but when the tree is in a possibly inconsistent state.

Getting rid of the tree change observers and replacing them with events would
mean:

* Rewriting the unserialization algorithm to compute the set of nodes that will
be removed before actually removing anything
* Potentially extra overhead due to event bubbling, etc.

I'm not convinced that events are better than tree change observers. Node that
the HTML DOM has both events and mutation observers, and the original mutation
events actually had to be deprecated because of similar performance issues.

I think what'd be ideal would be to make the tree change observers a lot like
mutation observers, where you could specify exactly what types of changes you're
interested in, and scope it to just part of the tree. The question is how much
we want to take on now, since we don't need all of that for live regions.

+        TreeChangeObserverMask mask);
+
     // Add a tree change observer. Tree change observers are static/global, they
-    // listen to changes across all trees.
+    // listen to changes across all trees. Note that you must also call
+    // setTreeChangeObserverMask for this to do anything.
     [nocompile] static void addTreeChangeObserver(
         TreeChangeObserver observer);