1256618 - Elements cannot be activated by clicking remote control

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Gary Chen [:xeonchen]]

Attachment: 0001-Add-VK_SELECT-support.patch

Step to reproduce:
1. connect to a nexus player with B2G installed, and the remote control is already paired.
2. in settings app, navigate to an element with sub-menu, e.g. Wi-Fi.
3. click the button located in the center of direction keys.

Result: nothing happened
Expected result: entering sub-menu

[1] mentions we should activate the element by some kind of trigger,
but in [2], only |NS_VK_RETURN| is handled.

My experiment is that the element can be triggered successfully by add support for |VK_SELECT|.
Are we going to support more keys such as 'Accept' or 'Select' listed in [3]?

[1] https://www.w3.org/TR/DOM-Level-3-Events/#event-flow-activation
[2] https://dxr.mozilla.org/mozilla-central/rev/d6ee82b9a74155b6bfd544166f036fc572ae8c56/dom/base/Element.cpp#3045
[3] https://www.w3.org/TR/DOM-Level-3-Events-key/

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8730653 [details] [diff] [review]
0001-Add-VK_SELECT-support.patch

Does the remote control has a button to cause VK_RETURN? If not so, I think that the button located in the center of direction key should cause VK_RETURN because the remote control cannot use on some web pages which listen to Enter key events.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Chromium also maps DPAD_CENTER to VK_RETURN:
https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/keycodes/keyboard_code_conversion_android.cc&q=KEYCODE_DPAD_CENTER&sq=package:chromium&type=cs&l=463

Comment 3

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Thanks @masayuki, then we should change the mapping from NS_VK_SELECT to NS_VK_RETURN here: https://dxr.mozilla.org/mozilla-central/source/widget/gonk/GonkKeyMapping.h#50

Comment 4

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Another question: should we also change the key name mapping from "Accept" to "Return" at https://dxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMKeyName.h#355 ?
The key code / key name mapping looks not synchronized to me.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #4)
> Another question: should we also change the key name mapping from "Accept"
> to "Return" at
> https://dxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMKeyName.
> h#355 ?

Perhaps, yes. But please keep it. The attribute is still experimental until Chrome supports it in default settings. And I'll update some key values at once for conforming to the latest draft.

> The key code / key name mapping looks not synchronized to me.

Yes. key values are clearer defined but keyCode isn't defined by any standards. Therefore, keyCode is decided with the other browser's behavior.

Comment 6

[Gary Chen [:xeonchen]]

Seems S.C. already answered the questions

Comment 7

[Gary Chen [:xeonchen]]

Attachment: MozReview Request: Bug 1256618 - change VK_SELECT to VK_RETURN; r=masayuki

Review commit: https://reviewboard.mozilla.org/r/40735/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/40735/

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8731586 [details]
MozReview Request: Bug 1256618 - change VK_SELECT to VK_RETURN; r=masayuki

https://reviewboard.mozilla.org/r/40735/#review37501

Let's try this.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/39e5c2cf1a5d

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/39e5c2cf1a5d