Fix Chrome OS virtual keyboard accessibility

chrome/browser/extensions/api/automation_internal/automation_internal_api.cc

Index: chrome/browser/extensions/api/automation_internal/automation_internal_api.cc
diff --git a/chrome/browser/extensions/api/automation_internal/automation_internal_api.cc b/chrome/browser/extensions/api/automation_internal/automation_internal_api.cc
index 916d4407f866693ab9a494cfae2ec2a73ae01343..d84aa66b8761d26881297a2746d967832cecc263 100644
--- a/chrome/browser/extensions/api/automation_internal/automation_internal_api.cc
+++ b/chrome/browser/extensions/api/automation_internal/automation_internal_api.cc
@@ -461,6 +461,8 @@ AutomationInternalPerformActionFunction::Run() {
 ExtensionFunction::ResponseAction
 AutomationInternalEnableDesktopFunction::Run() {
 #if defined(USE_AURA)
+  content::BrowserAccessibilityState::GetInstance()->EnableAccessibility();

[David Tseng, 2017/04/06 16:45:43]

I don't understand why this is necessary if the hosting view has a child tree
id. We enable the child tree id extension side. This is still needed I think
because of the reset case. When an extension is toggled off then on again, with
a renderer that already has accessibility enabled, we need to reset and resend
the renderer's tree contents. Does that make sense?

[dmazzoni, 2017/04/06 19:26:03]

I'm open to other solutions but I couldn't come up with something else
simple.

Currently the way we enable accessibility for most frames is that
we detect the ui::AX_ROLE_WEB_VIEW, cast it to a views::WebView,
and get a pointer to the WebContents.

In this particular case, the virtual keyboard is a pure aura WIndow
on the screen, it's not inside of a WebView or any View at all.

How are we going to know that this aura Window is really a
RenderWidgetHostViewAura? And if so how would we get its
tree id? Note that on creation it doesn't typically have a
routing id yet, so we'd have to be able to listen for a callback
to know when it's ready and fire an accessibility event on it.

One "clean" solution would be to add some accessibility
support to aura::Window, but that seems kind of heavyweight.
I didn't want to go that route if there was a simpler solution
since this is just a rare corner case.

Can you think of a more straightforward way to do it?
I'd be especially interested if you could come up with a way to
do it without magic strings and typecasting.

Finally, aside from the reason why I did it this way, once the extension
knows about the child tree, wouldn't it still be able to reset it if needed?
It's not clear to me how calling EnableAccessibility here means that
we can't later reset.

[David Tseng, 2017/04/06 20:00:32]

What happened with storing the child tree id as a window property? I thought you
had a cl out for that?

[dmazzoni, 2017/04/07 23:34:08]

OK, see latest patch set. I figured out a way to do it.

+
   const AutomationInfo* automation_info = AutomationInfo::Get(extension());
   if (!automation_info || !automation_info->desktop)
     return RespondNow(Error("desktop permission must be requested"));