Implement computedRole and computedName (behind a flag)

Source/core/dom/AXObjectCache.cpp

Index: Source/core/dom/AXObjectCache.cpp
diff --git a/Source/core/dom/AXObjectCache.cpp b/Source/core/dom/AXObjectCache.cpp
index d9e64928a742bd192e0877b4ca151e9e930461d7..484efe7dc3a3296665dbef88d5ff91d28178e10e 100644
--- a/Source/core/dom/AXObjectCache.cpp
+++ b/Source/core/dom/AXObjectCache.cpp
@@ -40,4 +40,35 @@ AXObjectCache::~AXObjectCache()
 {
 }
 
+ScopedAXObjectCache::ScopedAXObjectCache(Document& document)
+    : m_document(document)
+    , m_cache(0)
+{
+    if (AXObjectCache* existingCache = document.axObjectCache()) {
+        m_cache = existingCache;
+        m_isScoped = false;
+    } else {
+        m_isScoped = true;
+    }
+}
+
+ScopedAXObjectCache::~ScopedAXObjectCache()
+{
+    if (m_isScoped)
+        delete m_cache;
+}
+
+AXObjectCache* ScopedAXObjectCache::get()
+{
+    if (!m_cache && m_isScoped)
+        m_cache = AXObjectCache::create(m_document);

[adamk, 2014/12/16 01:54:48]

This looks like a pretty heavy operation; is this something we'd really want to
do upon accessing a DOM property?

[aboxhall, 2014/12/16 04:15:26]

It's not as heavy as it might appear - this is essentially just a constructor
(https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...)

It only lazily creates the actual cache, so in many cases this cache will only
ever have one object in it.

I'm not really sure what the alternative would be - we probably don't want to
always create the cache when we create the document, but it will need to be
created at some point for these methods to work.

[adamk, 2014/12/16 18:25:14]

It's "just" a constructor, but that constructor itself constructs:

5 HashMaps
2 HashSets
1 Timer
1 Vector
So my lack of understanding of Blink's accessibility code is clearly showing: it
seems like the bit of information we want is pretty small. It looks like the
only method we use on AXObjectCacheImpl is getOrCreate(), whose statefulness
mostly seems to be about caching AXObjects, something that we don't make any use
of if we're about to destroy the cache anyway.

Would it be possible to extract some of the logic from getOrCreate and use it
statically in the case where there's no AXObjectCache?

[dmazzoni, 2014/12/16 19:18:19]

No, the problem is that computing the role or name of an accessible object may
be recursive - i.e. it may have to compute the role of its parent, etc - so we
need the AXObjectCache to own any additional AXObjects that end up getting
created implicitly, so it can delete them all when it goes out of scope.

I think we really shouldn't worry about it at this point - this is just an
experimental API and optimizing it isn't the primary concern.

If we did want to optimize it, I'd first try to amortize the cost by keeping the
AXObjectCache around for one microtask, then look into making AXObjectCache
initialization faster. I think there are some potential optimizations we could
do once we've permanently switched to Oilpan too.

But not creating an AXObjectCache would require major, major refactoring and
special cases, which is not what we want to do at this point.

[adamk, 2014/12/16 19:25:24]

Okay, looking at this from the other direction, why not just create the
Document's AXObjectCache if one of these APIs is used? If we're not interested
in optimization, that seems like the easiest thing to do, instead of adding a
whole new case to deal with?

+    ASSERT(m_cache);
+    return m_cache;
+}
+
+AXObjectCache* ScopedAXObjectCache::operator->()
+{
+    return get();
+}
+
 } // namespace blink