Call XkbSetDetectableAutoRepeat() on Chrome start-up

Call XkbSetDetectableAutoRepeat() on Chrome start-up so the server does not send KeyRelease events when the user holds a key.

Without this, superfluous DOM key event might be sent to a page, which is bad for compatibility reasons. Note that Gdk (used by Chrome for Linux) calls the Xkb function during its initialization.

BUG=138092
TEST=see the bug for demo html; confirmed only one KeyUp DOM event is sent to the page even when a key is long-pressed.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=147863

[Yusuke Sato, 2012-07-20 04:20:39]

Sadrul, could you have a look at this?

[sadrul, 2012-07-20 17:24:50]

LGTM. But I am not entirely sure if something else needs to change after this
change. Perhaps derat@ would know better.

[Yusuke Sato, 2012-07-20 17:28:35]

+derat
Please let me know if you have a comment.

[Yusuke Sato, 2012-07-20 20:29:31]

Let me add my comments first. I believe the change is safe for the following
reasons:

- For a web page, eliminating the excessive KeyRelease events would be a good
thing because that is the standard compliant behavior. Chrome for
Windows/Mac/Linux and other browsers don't send such release events to a page
either.
- Views UIs (e.g. Omnibox) don't care about KeyRelease events. There are no
accelerators that are triggered on KeyRelease. One exception on Chrome OS is
'Shift+Alt+Release' accelerator for changing keyboard layout, but even the
accelerator is not affected by this change because modifier-only key-press does
not trigger key-repeat.

[Daniel Erat, 2012-07-23 14:50:30]

lgtm

[Yusuke Sato, 2012-07-23 15:41:25]

+mark
Could you do an owners review?

[Mark Mentovai, 2012-07-23 15:42:08]

lgtm

[commit-bot: I haz the power, 2012-07-23 15:51:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yusukes@chromium.org/10800050/1

[commit-bot: I haz the power, 2012-07-23 17:03:54]

Change committed as 147863