Bug 40999 – Implement getModifierState for KeyboardEvent

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: DOM

[Erik Arvidsson]

Right now there is no way to determine if AltGraph is pressed in the keyboard event.

[Hironori Bono]

This is just for your information.
Even though WebKit has the 'altGraphKey' property for identifying whether an alt-graph key is pressed, it does not work as expected. (It is Bug 38241 <https://bugs.webkit.org/show_bug.cgi?id=38241>.)

Regards,

[Blindauer]

Hi
Something can be done while DOM3 spreads out for web developers.

Currently, as the first comment says, there is no way to know if the altGr key is pressed.

Firefox fixed this problem recently in their release 15

This problem affect some javascripts application, like noVNC or guacamole
(https://github.com/kanaka/noVNC/issues/21, http://guac-dev.org/trac/ticket/136 )


The javascript test page is http://guac-dev.org/pub/tests/key-event-test.html

Currently webkit based browsers return a keyCode 0 for the AltGr Key. Firefox, since version 15 return the value 225.

Can a patch be made to return the same value for webkit browsers ?

[Masayuki Nakano]

(In reply to comment #2)
> Currently webkit based browsers return a keyCode 0 for the AltGr Key. Firefox, since version 15 return the value 225.

It depends on platform. On Windows, applications cannot know whether right-alt key is AltGr or not AFAIK. Therefore, only Gecko for Linux (GTK) sets the individual keycode.

See also:
https://developer.mozilla.org/en/DOM/KeyboardEvent#getModifierState%28%29
# Meta key support on Linux is going to be back Fx17.

[Alexey Proskuryakov]

The bug's platform is PC/Mac OS X 10.5. But OS X is only supported on Mac computers, and there is no AltGr key on Mac keyboard. There are left and right Option keys, which are mapped to left and right Alt for DOM.

[Blindauer]

(In reply to comment #4)
> The bug's platform is PC/Mac OS X 10.5. But OS X is only supported on Mac computers, and there is no AltGr key on Mac keyboard. There are left and right Option keys, which are mapped to left and right Alt for DOM.


I've perhaps made a BR for a wrong platform, for a adjacent bug, I'll reopen one related

[Eric Seidel (no email)]

I suspect we should change the platform of the bug, arv?  I've never seen an AltGraph key on a Mac.  I suspect that arv just happened to be on a mac when filing this bug.

http://en.wikipedia.org/wiki/AltGr_key

I've lived in countries where all of the windows keyboards had AltGraph keys for years.  I expect that users in AltGraph countries would want this information exposed to the web. :)

[Erik Arvidsson]

(In reply to comment #6)
> I suspect we should change the platform of the bug, arv?  I've never seen an AltGraph key on a Mac.  I suspect that arv just happened to be on a mac when filing this bug.

Yeah, I don't think I choose Mac manually.

Based on the Wikipedia article Mac keyboards don't have AltGraph.

[Chris Rebert]

All the other major browsers already support KeyboardEvent.getModifierState(); see https://github.com/Fyrd/caniuse/pull/1985/files

[Chris Rebert]

KeyboardEvent.getModifierState() is useful for purposes besides AltGr, including on Macs; this bug should really be marked "Platform: All". (Looks like nobody has even mentioned non-AltGr use cases thus far.)

For example, the 'Accel' virtual modifier key (http://www.w3.org/TR/DOM-Level-3-Events-key/#keys-modifier ) allows you to write keyboard shortcut event handlers without having to detect what OS you're on, since the browser determines for you whether Ctrl or ⌘Command is the customary modifier key for keyboard shortcuts on the user's OS).

[Alexey Proskuryakov]

> since the browser determines for you whether Ctrl or ⌘Command is the customary modifier key

This seems like a pretty questionable feature in its own, please file a separate bug about it. OS X has plenty of shortcuts that don't involve the Command key (for example, all the Emacs key bindings, but also many more).

[Masayuki Nakano]

(In reply to comment #10)
> > since the browser determines for you whether Ctrl or ⌘Command is the customary modifier key
> 
> This seems like a pretty questionable feature in its own, please file a
> separate bug about it. OS X has plenty of shortcuts that don't involve the
> Command key (for example, all the Emacs key bindings, but also many more).

"Accel" virtual modifier is dropped from the latest spec because there is no API to retrieve its caption. So, anyway, web apps need to check platform for documenting or showing shortcut key list to users. Therefore, UI Event guys decided that only "Accel" virtual modifier making reduce platform check doesn't make sense.


And also, "Meta" key is now mapped to Windows key on Windows (that was mapped "OS"). So, on Windows, during pressing Windows key, .getModifierState("Meta") should return true. Of course, .metaKey too. (On Linux, Windows Logo key may mapped any keys, therefore, pressing Window key on Linux may activate "Super" modifier in most environments.)

[Chris Rebert]

> "Accel" virtual modifier is dropped from the latest spec because there is no API to retrieve its caption.

The inability to get a caption is a fair criticism, though I'm sad they've apparently kicked the can down the road on a proper solution to the problem of platform-generic keyboard shortcuts. The Web's promises of WORA continue to need many asterisks..

[Chris Rebert]

*** This bug has been marked as a duplicate of bug 162855 ***