In [comment 1](#c1) above, it is noted that this bug is on hold until [Chromium 613152](https://bugs.chromium.org/p/chromium/issues/detail?id=613152) is resolved, which happened in 2017. If I'm reading that right, Chromium now interprets the Windows key as Meta. [Chromium 539979](https://bugs.chromium.org/p/chromium/issues/detail?id=539979) removed support for `event.getModifierState("OS")` given the conclusions in [w3c/uievents-key#9](https://github.com/w3c/uievents-key/issues/9). The [MDN docs for getModifierState § Modifier keys on Gecko](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/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](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/getModifierState#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.
Bug 1232918 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In [comment 1](#c1) above, it is noted that this bug is on hold until [Chromium 613152](https://bugs.chromium.org/p/chromium/issues/detail?id=613152) is resolved, which happened in 2017. If I'm reading that right, Chromium now interprets the Windows key as Meta. [Chromium 539979](https://bugs.chromium.org/p/chromium/issues/detail?id=539979) removed support for `event.getModifierState("OS")` given the conclusions in [w3c/uievents-key#9](https://github.com/w3c/uievents-key/issues/9). The [MDN docs for getModifierState § Modifier keys on Gecko](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/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](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/getModifierState#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](https://github.com/w3c/uievents-key/issues/29) notes the [code spec](https://w3c.github.io/uievents-code/#key-legacy) 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.