Intent to change: Align `KeyboardEvent.key` and `KeyboardEvent.code` values of Windows logo key and its modifier state

145 views
Skip to first unread message

Masayuki Nakano

unread,
Jul 13, 2023, 4:45:05 AM7/13/23
to dev-platform, Olli Pettay, Hsin-Yi Tsai, Karl Tomlinson

After implementing `KeyboardEvent.key`, `KeyboardEvent.code` and `KeyboardEvent.getModifierState()`, `.key` value for Windows Logo key was declared as "OS", `.code` value for it was declared as "OSLeft" or "OSRight" and the modifier state was "OS". However, after we shipped them, the standards changed the declarations. `.key` became "Meta" which is same as Command key in macOS, `.code` becaome "MetaLeft" and "MetaRight" and also Command keys in macOS will become "OSLeft"/"OSRight" to "MetaLeft"/"MetaRight", and the modifier state is also aligned to "Meta" which is enabled by Command key in macOS. I.e., the Windows Logo keys are treated as Command key in macOS in UI Events world. Therefore, we need to align these things to conform to the standards and align to Chrome.

Additionally, for applying "Meta" to Windows Logo keys in Linux, we need to reconsider about the legacy "meta" modifier state of Linux. Typically, it's mapped to Alt-Shift, but we use the highest priority modifier state of modifier keys, it's not exposed to the web within major distributions' default settings (i.e., exposed as "Alt" and "Shift" modifiers). However, if users customized key mapping to a modifier is pure Meta modifier key, it may be exposed on Firefox. I'm not sure how we should treat this. Currently, I'm think that it should be treated as "Alt" because typically "meta" state is mapped to Alt key, but it's just considered without concrete idea. So, I'm fully open about this issue.

Fortunately, the values are not meaningless values like `.keyCode` values. Therefore, web apps can handle Windows Logo key press like this code:

addEventListener("keydown", e => {
  if (e.key === "Meta" || e.key === "OS") {
    // Do something
  }
});

and also modifier state can be treated as:

if (e.getModifierState("OS") || e.metaKey) {
  // Do something
}

Therefore, the risk of this change is lower than changing `.keyCode` values since giving meanings to meaningless values require browser check, but it's not required in this case. (And anyway, Windows Logo key is not typically handled by applications including native apps since they are used for system-wide shortcut keys.)

So, listing up my intention is:

  • Change Windows Logo key .key values from "OS" to "Meta" in Windows/Linux
  • Change Windows Logo key .code values from "OSLeft"/"OSRight" to "MetaLeft"/"MetaRight" in Windows/Linux
  • Change Command key .code values from "OSLeft"/"OSRight" to "MetaLeft"/"MetaRight" in macOS
  • Change modifier state of Windows Logo keys from "OS" to "Meta" in Windows/Linux (affecting both .getModifierState() and .metaKey
  • Treat legacy meta key/modifier in Linux as "Alt" key/modifier

Bugs:

Specifications:

Platform coverage:

Windows/Linux and macOS (only for `.code`)

Preference:

Unfortunately, not controllable with prefs because the maps are hard coded and too many places refer the values.

DevTools bug:

N/A

Other browsers:

  • Blink: Already conformed to the standards
  • WebKit: Already conformed to the standards (.code values)

web-platform-tests:

This is not testable with WPT, but we have some mochitest-chrome tests:

-- 
Masayuki Nakano <masa...@d-toybox.com>
Working on DOM, Events, editor and IME handling for Gecko

Masayuki Nakano

unread,
Jul 20, 2023, 11:20:09 PM7/20/23
to dev-platform, Olli Pettay, Hsin-Yi Tsai, Karl Tomlinson
On 23/07/13 17:44, Masayuki Nakano wrote:

Additionally, for applying "Meta" to Windows Logo keys in Linux, we need to reconsider about the legacy "meta" modifier state of Linux. Typically, it's mapped to Alt-Shift, but we use the highest priority modifier state of modifier keys, it's not exposed to the web within major distributions' default settings (i.e., exposed as "Alt" and "Shift" modifiers). However, if users customized key mapping to a modifier is pure Meta modifier key, it may be exposed on Firefox. I'm not sure how we should treat this. Currently, I'm think that it should be treated as "Alt" because typically "meta" state is mapped to Alt key, but it's just considered without concrete idea. So, I'm fully open about this issue.


So, listing up my intention is:

  • Change Windows Logo key .key values from "OS" to "Meta" in Windows/Linux
  • Change Windows Logo key .code values from "OSLeft"/"OSRight" to "MetaLeft"/"MetaRight" in Windows/Linux
  • Change Command key .code values from "OSLeft"/"OSRight" to "MetaLeft"/"MetaRight" in macOS
  • Change modifier state of Windows Logo keys from "OS" to "Meta" in Windows/Linux (affecting both .getModifierState() and .metaKey
  • Treat legacy meta key/modifier in Linux as "Alt" key/modifier

Reply all
Reply to author
Forward
0 new messages