1232918 - [UI Events-key][UI Events-code] Windows logo key on Windows and Linux should be treated as `Meta` key and change `OSLeft`/`OSRight` code values to `MetaLeft`/`MetaRight`

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P3)

Description

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

At TPAC 2015, we agreed with that we should drop "OS" key which is used only on Windows. Instead of that, any browsers haven't activate "Meta" modifier key state on Windows. Therefore, "OS" key should be replaced by "Meta" key on Windows.

Comment 1

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

Hmm, Linux also uses "OS" for "Super" for now and Chrome maps "Super" to "Meta" (https://bugs.chromium.org/p/chromium/issues/detail?id=613152) but this is really breaking the definition of the Spec. Until the issue 613152 is fixed, we shouldn't touch the Linux implementation. So, we should change "OS" on Windows to "Meta" for now.

Comment 3

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 4

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

All other browsers set KeyboardEvent.key value of Windows Logo keys to "Meta". For compatibility with them, we should do:

1. Map VK_LWIN and VK_RWIN to "Meta" on Windows (Currently mapped to "OS").
2. Map GDK_Super_L, GDK_Super_R, GDK_Hyper_L and GDK_Hyper_R to "Meta" (Currently mapped to "OS").
3. Adjust modifier state for the new key value.
4. Get rid of "OS" from key and code values completely.

And perhaps, on Linux, we should use unmodified modifier key value to decide KeyboardEvent.key value because Alt+Shift is mapped to Meta key by most distributions. Therefore, we set key value of Alt+Shift to "Meta", but Chromium simply sets "Alt". On the other hand, Meta key may be mapped to Windows Logo key separately, with GNOME Tweaks. This means that some users may use such key mapping. Even in such case, I hope AltLeft/AltRight key should cause "Alt", OSLeft/OSRight should cause "Meta". So, perhaps, we should keep mapping GDK_Meta_L and GDK_Meta_R to "Meta", but ignore at mapping to Alt+Shift.

Comment 5

[Pierre Ossman]

We would very much like to avoid "Meta" being used for two different keys to keep things sane in noVNC. For us it would work fine to say "Alt" even if the system is reporting XK_Meta_*.

For reference, but report with Chrome about them using the same name for two different keys:

https://bugs.chromium.org/p/chromium/issues/detail?id=1020141

Comment 7

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

Resetting assignee which I don't work on in this several months.

Comment 8

[Adam Katz]

In comment 1 above, it is noted that this bug is on hold until Chromium 613152 is resolved, which happened in 2017. If I'm reading that right, Chromium now interprets the Windows key as Meta. Chromium 539979 removed support for event.getModifierState("OS") given the conclusions in w3c/uievents-key#9.

The MDN docs for getModifierState § Modifier keys on Gecko say that on Linux (GTK), the Super key and Hyper key both trigger "OS" (but this is later marked as deprecated in § Browser compatibility). That table also has rows for "Super" and "Hyper" that are marked as "Not supported" for all platforms.

This should hopefully clear the way for this bug to get resolved, that we can treat the Windows/Super/OS key as Meta.

I personally dislike the idea of changing modifier key identity based on Shift (Shift+Alt = Meta, Shift+OS = Hyper). As one of those oddball power tweakers who have actually mapped Hyper to a key on their keyboards, I'd love to see "Hyper" (and a event.hyperKey method) implemented as well (I understand that this is better proposed to a standards body). This would enable a straightforward (Shift-free) way to handle Meta and Hyper while still allowing a web developer to code their own polyfill to implement the older Shift+Alt = Meta and Shift+Meta = Hyper logic.

Update: I see w3c/uievents-key#29 notes the code spec has pushed the Super and Hyper keys to legacy status: "These keys are not found on modern standard keyboards." I've always considered Super and Windows to be synonymous, at least from a Linux perspective, and the whole "Meta" term is confusing due to Linux traditionally using Meta to refer to Alt (at least, that's my recollection; the idea of Shift+Alt = Meta is not ringing any bells, and I'm a >20y Linux veteran). I still don't see any harm in implementing "Hyper" as its own modifier, but event.hyperKey is probably unnecessarily confusing.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Please note that with the following PR on GitHub the MDN documentation has been updated to refer to MetaLeft and MetaRight: https://github.com/mdn/content/issues/27459

Is it intentional that so far no-one mentioned MacOS, which is also affected?

Comment 10

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

Intent to change: https://groups.google.com/a/mozilla.org/g/dev-platform/c/S859KrLKSBU

Comment 11

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

In strictly speaking, OSLeft/OSRight -> MetaLeft/MetaRight should be handled in another bug, but the related tests are same ones. Therefore, I'd like to change them with .key value changes.

Comment 12

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

Attachment: Bug 1232918 - Map Windows Logo keys in Win/Linux to `Meta` and rename `OSLeft`/`OSRight` to `MetaLeft`/`MetaRight` r=smaug!,#dom-core

When we implement KeyboardEvent.key, its value for Windows Logo key was
declared as OS, but now the spec declares it as Meta.
https://www.w3.org/TR/uievents-key/#key-Meta

When we implement KeyboardEvent.code, its value for Windows Logo keys in
Win/Linux and Command keys in macOS are declared as OSLeft/OSRight, but
now the spec declares them as MetaLeft/MetaRight.
https://w3c.github.io/uievents-code/#code-MetaLeft

This patch remaps and renames them.

Depends on D183480

Comment 13

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

The patch will be landed after the next merge (i.e., will be fixed in 118).

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/33e3c6593d4b
Map Windows Logo keys in Win/Linux to `Meta` and rename `OSLeft`/`OSRight` to `MetaLeft`/`MetaRight` r=smaug,webdriver-reviewers,jdescottes

Comment 15

[Cristian Tuns]

Backed out for causing mochitest failures in test_autoplay_policy_key_blacklist.html

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | dom/media/autoplay/test/mochitest/test_autoplay_policy_key_blacklist.html | Caught exception [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsITextInputProcessor.keydown]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: resource://testing-common/WrapPrivileged.sys.mjs :: doApply :: line 117" data: no] Component returned failure code: 0x80070057 (NS_ERROR_ILL

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4e6febc59baa
Map Windows Logo keys in Win/Linux to `Meta` and rename `OSLeft`/`OSRight` to `MetaLeft`/`MetaRight` r=smaug,webdriver-reviewers,jdescottes,media-playback-reviewers,karlt

Comment 17

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/4e6febc59baa

Comment 18

[Hamish Willee]

FF118 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/28844