MacViews a11y: Sync VoiceOver cursor with keyboard focus.

content/browser/accessibility/browser_accessibility_cocoa.mm

Index: content/browser/accessibility/browser_accessibility_cocoa.mm
diff --git a/content/browser/accessibility/browser_accessibility_cocoa.mm b/content/browser/accessibility/browser_accessibility_cocoa.mm
index 1b841569615e845be4cf624c2bf50d4f2b7e4ef7..d475cae9a03bed85040533fb9df277979bc59d90 100644
--- a/content/browser/accessibility/browser_accessibility_cocoa.mm
+++ b/content/browser/accessibility/browser_accessibility_cocoa.mm
@@ -12,6 +12,7 @@
 
 #include "base/mac/foundation_util.h"
 #include "base/mac/scoped_cftyperef.h"
+#import "base/mac/sdk_forward_declarations.h"
 #include "base/strings/string16.h"
 #include "base/strings/sys_string_conversions.h"
 #include "base/strings/utf_string_conversions.h"
@@ -107,11 +108,6 @@ const int kAXResultsLimitNoLimit = -1;
 
 extern "C" {
 
-// See http://openradar.appspot.com/9896491. This SPI has been tested on 10.5,
-// 10.6, and 10.7. It allows accessibility clients to observe events posted on
-// this object.
-void NSAccessibilityUnregisterUniqueIdForUIElement(id element);
-
 // The following are private accessibility APIs required for cursor navigation
 // and text selection. VoiceOver started relying on them in Mac OS X 10.11.
 #if !defined(MAC_OS_X_VERSION_10_11) || \
@@ -603,8 +599,11 @@ bool InitializeAccessibilityTreeSearch(
 }
 
 - (void)detach {
-  if (browserAccessibility_)
-    NSAccessibilityUnregisterUniqueIdForUIElement(self);
+  if (!browserAccessibility_)
+    return;
+  NSAccessibilityPostNotification(
+      self, NSAccessibilityUIElementDestroyedNotification);
+  NSAccessibilityUnregisterUniqueIdForUIElement(self);
   browserAccessibility_ = nullptr;
 }
 
@@ -2853,6 +2852,10 @@ bool InitializeAccessibilityTreeSearch(
   return browserAccessibility_->GetId();
 }
 
+- (BOOL)accessibilityNotifiesWhenDestroyed {
+  return YES;

[tapted, 2016/09/26 05:19:17]

Comment here why this is done? Reading the comment on NSAccessibility.h suggests
to me that this is the right thing to do - but does it solve a specific problem?
(and it look slike OSX provided accessibilityNotifiesWhenDestroyed in the 10.9
SDK to support a particular use case - now that we use it, is there a
possibility of conflict with the accessibilityShouldUseUniqueId stuff?)

[Patti Lor, 2016/09/28 00:29:14]

Ah - I think this might actually not be needed (at least, not while
accessibilityShouldUseUniqueId is also there). I just double checked this (for
Views) and having either or both accessibilityShouldUseUniqueId and
accessibilityNotifiesWhenDestroyed make VO faster than without, so probably only
one is needed. Inside the WebContents though I don't actually notice any
difference in speed when deleting these, only in the Views parts, which is kind
of strange - have no idea why it affects only Views.

Since the former uses a private thing, I went ahead and deleted that in favour
of accessibilityNotifiesWhenDestroyed (so am kind of guessing/assuming they do
the same thing), but let me know if you want to just keep it as is here and use
accessibilityNotifiesWhenDestroyed in AXPlatformNodeCocoa. I don't think they
actually conflict though. 

(To be clear, not having either will make VO really slow in Views only - it will
take at least a couple of seconds to catch up when keyboard focus is moved.)

+}
+
 - (BOOL)accessibilityShouldUseUniqueId {
   return YES;
 }