Fix Chrome OS virtual keyboard accessibility

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

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/extensions/api/automation_internal/automation_internal_api.h"
 
 #include <stdint.h>
 
 #include <memory>
 #include <vector>
@@ skipping 443 matching lines @@
   ui::AXActionData data;
   ExtensionFunction::ResponseAction result =
       ConvertToAXActionData(params.get(), &data);
   rfh->AccessibilityPerformAction(data);
   return result;
 }
 
 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"));
 
   using api::automation_internal::EnableDesktop::Params;
   std::unique_ptr<Params> params(Params::Create(*args_));
   EXTENSION_FUNCTION_VALIDATE(params.get());
 
   // This gets removed when the extension process dies.
   AutomationEventRouter::GetInstance()->RegisterListenerWithDesktopPermission(
@@ skipping 46 matching lines @@
     int result_acc_obj_id) {
   if (!error.empty()) {
     Respond(Error(error));
     return;
   }
 
   Respond(OneArgument(base::MakeUnique<base::Value>(result_acc_obj_id)));
 }
 
 }  // namespace extensions