Makes sure the keyboard typing isn't blocked when InputMethod::OnFocus() is not correctly called.

ui/base/ime/input_method_auralinux.cc

Index: ui/base/ime/input_method_auralinux.cc
diff --git a/ui/base/ime/input_method_auralinux.cc b/ui/base/ime/input_method_auralinux.cc
index ca9931f06f777e215e9012f9da4b9f1e3bb9fdca..439c1233bedc1fb9c2a4051332a8a08b7a6aedcc 100644
--- a/ui/base/ime/input_method_auralinux.cc
+++ b/ui/base/ime/input_method_auralinux.cc
@@ -46,6 +46,16 @@ bool InputMethodAuraLinux::OnUntranslatedIMEMessage(
 void InputMethodAuraLinux::DispatchKeyEvent(ui::KeyEvent* event) {
   DCHECK(event->type() == ET_KEY_PRESSED || event->type() == ET_KEY_RELEASED);
   DCHECK(system_toplevel_window_focused());
+  if (!system_toplevel_window_focused()) {
+    LOG(ERROR) <<
+        "Key event got without the top-level window being activated.";

[sky, 2016/01/07 16:24:42]

Under what conditions does this happen? It seems like you're working around a
bug in the rest of the code.

[Shu Chen, 2016/01/08 02:04:11]

Yes, exactly. crbug.com/569339 causes a lot of complaints, but it is hard to
repro.
The log here is help us to hunt down the root cause.
I'm trying to add more logs at multiple places and put those logs here (I will
upload a new patch soon).

The following OnFocus() call is to ease the pain for users (the bug can cause
user lose I think).

[yukawa, 2016/01/08 02:21:20]

My understanding is the same to what Shu explained.  Given that we have
sufficient reporters in crbug.com/569339 who can relatively easily reproduce
this issue, having only logging code in this CL is also fine to me.

+    // There are random issues that the keyboard typing doesn't work.
+    // The root cause might be the InputMethod::OnFocus() is not correctly
+    // called when the top-level window is activated
+    // (in DNWA::HandleActivationChanged).
+    // Calls OnFocus here to unblock the keyboard typing.
+    OnFocus();
+  }
 
   // If no text input client, do nothing.
   if (!GetTextInputClient()) {