Closed Bug 1232918 Opened 8 years ago Closed 8 months ago

[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`

Categories

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

defect

Tracking

()

RESOLVED FIXED
118 Branch
Tracking Status
firefox117 --- wontfix
firefox118 --- fixed

People

(Reporter: masayuki, Assigned: masayuki)

References

()

Details

(Keywords: dev-doc-complete, parity-chrome, parity-edge)

Attachments

(1 file)

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.
Whiteboard: [parity-Chrome]
Summary: [UI Events] Drop "OS" key value and Windows logo key on Windows should be "Meta" key → [UI Events-key] Drop "OS" key value and Windows logo key on Windows should be "Meta" key
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.
Summary: [UI Events-key] Drop "OS" key value and Windows logo key on Windows should be "Meta" key → [UI Events-key] Windows logo key on Windows should be "Meta" key
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-Chrome]
Priority: -- → P5
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.
Keywords: parity-edge
Summary: [UI Events-key] Windows logo key on Windows should be "Meta" key → [UI Events-key] Windows logo key on Windows and Linux should be treated as "Meta" key

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

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

Assignee: masayuki → nobody
Status: ASSIGNED → NEW

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.

Severity: normal → S3

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?

Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Priority: P5 → P3
Summary: [UI Events-key] Windows logo key on Windows and Linux should be treated as "Meta" key → [UI Events-key] Windows logo key on Windows and Linux should be treated as `Meta` key and change `OSLeft`/`OSRight` code values to `MetaLeft`/`MetaRight`
Summary: [UI Events-key] Windows logo key on Windows and Linux should be treated as `Meta` key and change `OSLeft`/`OSRight` code values to `MetaLeft`/`MetaRight` → [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`

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.

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

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

Pushed by masayuki@d-toybox.com:
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

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
Flags: needinfo?(masayuki)
Flags: needinfo?(masayuki)
Pushed by masayuki@d-toybox.com:
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
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch

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

You need to log in before you can comment on or make changes to this bug.