Support DomCode on Android devices.

content/browser/renderer_host/input/web_input_event_builders_android.cc

 // Copyright 2013 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 "content/browser/renderer_host/input/web_input_event_builders_android.h"
 
 #include "base/logging.h"
 #include "content/browser/renderer_host/input/motion_event_android.h"
 #include "content/browser/renderer_host/input/web_input_event_util.h"
 #include "content/browser/renderer_host/input/web_input_event_util_posix.h"
+#include "ui/events/keycodes/dom/dom_code.h"
+#include "ui/events/keycodes/dom/keycode_converter.h"
 #include "ui/events/keycodes/keyboard_code_conversion_android.h"
 #include "ui/events/keycodes/keyboard_codes_posix.h"
 
 using blink::WebInputEvent;
 using blink::WebKeyboardEvent;
 using blink::WebGestureEvent;
 using blink::WebMouseEvent;
 using blink::WebMouseWheelEvent;
 using blink::WebTouchEvent;
 using blink::WebTouchPoint;
 
 namespace content {
 
 WebKeyboardEvent WebKeyboardEventBuilder::Build(WebInputEvent::Type type,
                                                 int modifiers,
                                                 double time_sec,
                                                 int keycode,
+                                                int scancode,
                                                 int unicode_character,
                                                 bool is_system_key) {
   DCHECK(WebInputEvent::isKeyboardEventType(type));
   WebKeyboardEvent result;
 
+  ui::DomCode dom_code = ui::DomCode::NONE;
+  if (scancode != 0)
+    dom_code = ui::KeycodeConverter::NativeKeycodeToDomCode(scancode);
+  if (dom_code == ui::DomCode::NONE)
+    dom_code = ui::DomCodeFromAndroidKeyCode(keycode);

[Sergey Ulanov, 2015/09/09 19:55:44]

I don't think this is the right approach. DomCodeFromAndroidKeyCode() assumes
QWERTY layout, so the translation is not correct for any other layout.

From https://source.android.com/devices/input/keyboard-devices.html

  On a US English (QWERTY) keyboard, the top-left alphabetic key is 
  labeled Q. On a French (AZERTY) keyboard, the key in the same 
  position is labeled A. Despite the label, on both keyboards the 
  top-left alphabetic key is referred to using the HID usage 0x07 0x0014 
  which is mapped to the Linux key code KEY_Q.

domCode must not depend on the keyboard layout, i.e. top left key must have the
same domCode in both English and French layouts. So unless we can verify that
QWERTY layout is selected we cannot be sure that the domCode we get here is
correct.

[dtapuska, 2015/09/09 20:00:13]

So what is your preferred fallback? Not to set the domcode at all?

The OSK generates keycodes for backspace, tab, space and enter.. but doesn't
fill in the scancode.

[Sergey Ulanov, 2015/09/09 20:20:30]

I'm not sure, but I think not setting it at all would be better than setting it
incorrectly. Gary would be the best person to answer this question.

The spec says the following (see
http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-chording-virtual ):
  Virtual keyboards are software-based sets of keys, in a variety of different 
  arrangements, commonly found on touch-screen devices. They are often modal,
with 
  the ability to switch between different dynamic sets of keys, such as
alphabetic, 
  numeric, or symbolic keys. Because of the lack of physical constraints, these 
  keyboards may present the widest range of characters, including emoticons and 
  other symbols, and may have keys not represented by Unicode [Unicode] or by
the 
  key values [DOM-Level-3-Events-key]. Wherever possible, however, virtual
keyboards 
  should produce the normal range of keyboard events and values, for ease of 
  authoring and compatibility with existing content.

Perhaps we can still map keyCode to domCode, but only for keys that don't change
position in different layouts (i.e. backspace, tab, space, enter)

   result.type = type;
   result.modifiers = modifiers;
   result.timeStampSeconds = time_sec;
   ui::KeyboardCode windows_key_code =
       ui::KeyboardCodeFromAndroidKeyCode(keycode);
   UpdateWindowsKeyCodeAndKeyIdentifier(&result, windows_key_code);
   result.modifiers |= GetLocationModifiersFromWindowsKeyCode(windows_key_code);
   result.nativeKeyCode = keycode;
+  result.domCode = static_cast<int>(dom_code);
   result.unmodifiedText[0] = unicode_character;
   if (result.windowsKeyCode == ui::VKEY_RETURN) {
     // This is the same behavior as GTK:
     // We need to treat the enter key as a key press of character \r. This
     // is apparently just how webkit handles it and what it expects.
     result.unmodifiedText[0] = '\r';
   }
   result.text[0] = result.unmodifiedText[0];
   result.isSystemKey = is_system_key;
 
@@ skipping 61 matching lines @@
   result.type = type;
   result.x = x;
   result.y = y;
   result.timeStampSeconds = time_sec;
   result.sourceDevice = blink::WebGestureDeviceTouchscreen;
 
   return result;
 }
 
 }  // namespace content