For faked key events from virtual keyboard, the character is set but dom key is not set. In such ca…

ui/events/event.cc

Index: ui/events/event.cc
diff --git a/ui/events/event.cc b/ui/events/event.cc
index fc87ca68350777906afd6c130b322858bb938f8d..0b406531afef906b5e483494381b95c7200706d4 100644
--- a/ui/events/event.cc
+++ b/ui/events/event.cc
@@ -749,6 +749,14 @@ void KeyEvent::SetExtendedKeyEventData(scoped_ptr<ExtendedKeyEventData> data) {
 }
 
 void KeyEvent::ApplyLayout() const {
+  // If the client has set the character (e.g. faked key events from virtual
+  // keyboard), it's client's responsibility to set the dom key correctly.
+  // Otherwise, set the dom key as unidentified.
+  // Please refer to crbug.com/443889.
+  if (character_ != 0) {
+    key_ = DomKey::UNIDENTIFIED;

[Shu Chen, 2014/12/19 08:29:21]

Not sure whether it's more appropriate to set as DomKey::CHARACTER.

[kpschoedel, 2014/12/19 16:08:51]

UNIDENTIFIED is fine for this CL, as it is defined as "unable to identify".
There is code in the Ozone xkbcommon interface that I will factor out for
non-Ozone to cover the special cases (e.g. character 8 -> DomKey::BACKSPACE) and
to cover non-character keys.

+    return;
+  }
 #if defined(OS_WIN)
   // Native Windows character events always have is_char_ == true,
   // so this is a synthetic or native keystroke event.