Generalized fix for serialization error/reset issues

chrome/renderer/resources/extensions/automation_custom_bindings.js

Index: chrome/renderer/resources/extensions/automation_custom_bindings.js
diff --git a/chrome/renderer/resources/extensions/automation_custom_bindings.js b/chrome/renderer/resources/extensions/automation_custom_bindings.js
index 10fd29d0609708f8dee99df03c2d0a9fd36de032..43419ff7ed8e697ee21bc01ffa2211580879936e 100644
--- a/chrome/renderer/resources/extensions/automation_custom_bindings.js
+++ b/chrome/renderer/resources/extensions/automation_custom_bindings.js
@@ -347,6 +347,14 @@ automationInternal.onAccessibilityTreeDestroyed.addListener(function(id) {
   DestroyAccessibilityTree(id);
 });
 
+automationInternal.onAccessibilityTreeSerializationError.addListener(function(id) {

[dmazzoni, 2016/11/22 18:11:42]

nit: wrap

[David Tseng, 2016/11/22 18:26:28]

Done.

+  // Possibly clear native focus.

[dmazzoni, 2016/11/22 18:11:42]

Is this necessary? Won't it fix itself when the new frame is retrieved?

[David Tseng, 2016/11/22 18:26:28]

Navigation could still occur before then, but likely not for long before the
reserialized frame comes back.
I removed it.

+  var focusedNodeInfo = GetFocusNative(DESKTOP_TREE_ID);
+  if (focusedNodeInfo && focusedNodeInfo.treeId == id)
+    automationUtil.focusedNode = null;
+  automationInternal.enableFrame(id);

[dmazzoni, 2016/11/22 18:11:42]

Does calling enableFrame() force it to reset?

I think we should either add a comment to enableFrame saying that
it must reset (otherwise we could accidentally try to optimize away
redundant calls to enableFrame), or else we should add a separate
resetFrame call.

[David Tseng, 2016/11/22 18:26:28]

Let's rename this to enableOrResetFrame (in another cl). That's how it's been
used and it's automation only (tree only mode).

+});
+
 var binding = automation.generate();
 // Add additional accessibility bindings not specified in the automation IDL.
 // Accessibility and automation share some APIs (see