Bug 23751 - "Select" key is not defined in the latest ED
"Select" key is not defined in the latest ED
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: DOM3 Events
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Travis Leithead [MSFT]
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 03:58 UTC by Masayuki Nakano
Modified: 2014-04-07 21:33 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Masayuki Nakano 2013-11-07 03:58:41 UTC
There was "Select" key. It's used for VK_SELECT on Windows (both IE and Firefox). This is different from "MeditaSelect". Windows defines VK_LAUNCH_MEDIA_SELECT with other value.

I think that this should be defined in 6.3.6 UI Keys.
Comment 1 Gary Kacmarcik 2013-11-14 09:09:33 UTC
I'm not sure what VK_SELECT actually is, and I don't know of any keyboard layouts that would generate this VKey.

We should not include |key| values unless we can point to a layout that can generate the value -- that's the test we've been applying for the GDK_ keys as well.

Travis, do you know of any way to generate this key value?
Comment 2 Travis Leithead [MSFT] 2013-11-19 22:50:16 UTC
(In reply to Gary Kacmarcik from comment #1)
> I'm not sure what VK_SELECT actually is, and I don't know of any keyboard
> layouts that would generate this VKey.
> 
> We should not include |key| values unless we can point to a layout that can
> generate the value -- that's the test we've been applying for the GDK_ keys
> as well.
> 
> Travis, do you know of any way to generate this key value?

I chatted with our DOM keyboard events guru, and he didn't have any idea how to cause this VK to be generated short of programmatically sending it. So maybe this key can go.
Comment 3 Masayuki Nakano 2013-11-25 08:08:36 UTC
If we don't need to define "Select", I don't understand why D3E needs to define other similar keys which are used on ancient computer such as "Play", "Pause", "Cancel", "CrSel", "ExSel", "EraseEof", "Again", "Attn", "Execute" and "Clear".

Some of them are defined by Windows as virtual keycode and some of them are used by special keys of Japanese keyboard actually. However, they are just recycled, not represents the function. Therefore, browsers need to map them proper key names with checking keyboard layout. See VK_ATTN for example.
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Key_names
Comment 4 Masayuki Nakano 2013-12-10 08:26:01 UTC
I tested Sun keyboard's special keys:
              Windows                    Linux
Help:                                    Help
Stop:                                    Cancel
Again:                                   Redo
Props:                                   SunProps
Undo:                                    Undo
Front:                                   SunFront
Copy:                                    XF86Copy
Open:                                    XF86Open
Paste:                                   XF86Paste
Find:                                    Find
Cut:                                     XF86Cut
確定(Kakutei): VK_NONCONVERT              Muhenkan
変換(Henkan):  VK_CONVERT                 Henkan_Mode
日本語On-Off:  VK_OEM_COPY/VK_OEM_FINISH  Hiragana-Katakana/Romaji
Compose:      VK_APPS                    Menu
かな:          Right-Alt                  Alt_R

確定/変換/日本語On-Off/Compose/かな are mapped as keys on normal JIS keyboard. So, we don't need to worry about them.

For Help - Cut, only Linux generates specific key event (Help is supported on Mac too, though).