This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23751 - "Select" key is not defined in the latest ED
Summary: "Select" key is not defined in the latest ED
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-07 03:58 UTC by Masayuki Nakano
Modified: 2014-04-07 21:33 UTC (History)
3 users (show)

See Also:


Attachments

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).