Erlkönig: 2012-07-13-mozilla-x.shtml

I'm a heavy user of modifier keys in Linux (since X10, which is a long time ago now). My xmodmap (from a Kinesis contoured) is shown below.

Although normally a fvwm user, I have a plethora of keybindings when in Compiz, where I need to combine Meta, Alt, Super, and Hyper just to reach them all.

On keycap labels vs current keymaps

In X11, the expectation is that the physical label of a modifier (or any) key is irrelevant, the mappings as seen in xmodmap are paramount; KeySyms trounce KeyCodes, mod1 through mod5 trounce KeyCodes. Few Unix users appreciate an app trying to use the "real" key for something when the user expressly said to use a different one (like Dvorak, wild mod remappings, swapping backspace & delete, etc).

Using just KeySyms can fail if the down event happened outside of the window, where using the key "state" modifier mask is reliable.

On Meta vs Alt

Many apps used Meta and Alt equivalently because many Unix keyboards would only have one of the labels, and usually ended up using it for Meta if an actual key labelled "Meta" was lacking, since few American users needed the 'Alt'ernate character set functionality.

Since Alt was held to relate to which character was being typed, it would be misleading to call Alt a modifier. Consider needing to type a Meta-¶ (for say a "refill-paragraph" command or something), on a system where one can type Alt-P to get a ¶. It's then possible to use Meta-Alt-P to refill the paragraph, but the only command-like modifier is Meta; the Alt is just an artifact of accessing the character "¶".

I'd love everyone to just leave Alt alone so we could use it for Unicode. However, since modern PC keyboards often just have two Alt keys, and not everybody has immediately scribed "Meta" over one the way we'd have hoped, leaving some folks with no Meta at all - Alt has been press-ganged into being a mod by some apps.

If no Meta keys are in the keymap, this is actually quite reasonable (meaning use Alt's mod<N> if Meta is missing from the mod map). Just don't misconstrue it as ideal.

Some users have used Meta for other purposes, like for the window manager bindings (move window, resize window, etc - I mapped in Hyper on capslock for this purpose instead and much recommend this approach; Hyper+[some left-hand-key] gives a lot of options). For them, having both Alt & Meta mapped gives them a fallback plan - they can use Alt+N to evade their window manager snatching the key.

So there's a case for using *both* Alt and Meta (the bit-or of Alt's mod<N> and Meta's mod<N>) in Firefox that's perfectly reasonable - it just bollixes my plan for Alt and Unicode.

So the legacy approach in firefox and earlier still makes a lot of sense.

On Super/Hyper

Firefox doesn't actually use Super or Hyper, does it?

Various window managers have starting using Super or Hyper again and applications should usually avoid these, since the only reason Super/Hyper have been dragged in is because apps have already chewed up everything in Shift/Control/Alt/Meta. I use Hyper for my own window manager mappings to keep Super available for app keybinding expansion. Compiz clamps onto Super instead (and handled Hyper messily last time I checked, although it did work).

As Nakano said: "better to give higher priority to Meta than Super/Hyper.". He's right, although I'd have put it a lot more strongly, since Super and Hyper keys may be present but eaten up by the window manager, making all of the supposedly-available-to-firefox keys instead utterly unavailable due to the WM trapping them, or worse yet, just some of them.

Commentary in http://hg.mozilla.org/mozilla-central/rev/c9ce0e49040a says "Assume that Super or Hyper is always mapped to physical Win key.". This assumption looks questionable - for example, what's supposed to happen when both Super AND Hyper are mapped, and more notably, on a keyboard which doesn't even have a Windows key? I could be missing some scope around nsGtkKeyUtils.cpp, but it seems to be assuming that Unix only runs on PCs.

Super and Hyper should not be combined, conflated, or merged in Unix, save in the one case where both are mapped to the same underlying mod<N> with is really rare - since it's a bit unusual for either to be mapped to start with. Mapping them both to a "DOM Win key" sounds pretty wrong, but I'm not familiar enough with GTK+ to know if this is the only way to cope with some kind of deep braindamage in an underlying library.

Nakako says "Super/Hyper should be able to be a modifier key on Linux desktop". But:

• Each should be available as independent modifiers, plural
• On any Unix or Linux computer
• And on servers, laptops and so on as well.
• But nothing in Firefox's default should ever require them, since they will frequently be coöpted by window managers.
• Likely, they should be discourage in extensions default keybindings.

Karl says: KDE calls Mod4 "Meta". Random chance. And I'm not sure you meant "Meta" specifically. There is no predicting which mod<N> a user might user for a particular modifier key like Meta. In KDE's casemod4 might have been chosen just because is was fairly unused, and possibly because they think Super will be mapped to it. On mine, mod4 is Hyper, and both it and my mod3/Super ends up used window managers (as distinct mods). My Meta is on mod1. And everything works fine except Firefox.

Karl says: "I think it would be sensible for applications to stay away from using Super for shortcuts where possible, and as a convention leave them for global shortcuts,". Yes, and even more so for Hyper. I'd do everything possible to stay away from use of Super in Firefox defaults or in Addons, but if a user wants to map Super- or Hyper-something in, why stop him? I'd only force a convention on developers, rather than on the users.

On various assumption made by apps and WMs about Alt/Meta

If GTK+ is assuming mod1 = Alt and breaks if mod1 = Meta, then is it using KeySyms instead of the mod[12345] thing in the state mask? If so the user might need to change the key itself from "Alt" to "Meta", and map the result with xmodmap, so that the right modifier mapping can be located by GTK+. This doesn't sound like a problem with FF.

Emacs key usage is complicated by whether it's being used as an X app or via a terminal (and which one) and so on. The model Karl describes "Are you aware that if there is no separate Meta modifier, then emacs will treat the Alt modifier as Meta?" is basically what Firefox should probably do as well, noting that if the X session doesn't have a Meta or mod1 mapped in somehow, it's hard to do better unless you give the user an explicit choice.

Nakano says: "some users may want to enable Meta keys even if the modifier bit is shared with other modifiers.". Weird though it sounds, *all* the modifier keys could be mapped to mod1, the one usually regarded as Meta. If the code focuses on using the key state modifier mask instead of trying to track KeySyms, this would seem to be a nonissue.

Someone said: "If the keyval indicates it's a modifier key, we should use unshifted key's modifier keyval". Why? Meta-a and Meta-A certainly don't have to map to the same underlying command. I'd recommend letting them be distinct. Although this does juxtapose weirdly with Shift+Alt_L -> Meta_L, and I don't have a good answer to that one.

Deakin says: "Shouldn't it be considered to be the 'meta' key and be labelled as such [...]". No, this seems simple but clashes with a lot of actual use. Most linux users would map one or both Alts to Meta, and if the Win key got mapped, it would probably be to Super for compiz or something. And none of those can be counted upon.

Nakano says: "DOM Control key should be mapped to real Control key on each platform.". If "real" means the physical key with "Ctrl" printed on it, then his isn't a X-native approach - it notionally would override the modifier map, where control could be mapped to another key by the end user. Circumventing this would be suboptimal. However "Similarly, we're detecting the Mod1-5 meaning from the assigned keyvals on GTK." seems perfectly proper, so I don't understand that you seem to be stating different approaches for Control version Mod(N).

Nakano says: "current[ly] our implementation detects the meaning of Mod1-5 with the applied native keycode". Better with XKeySyms (especially if XMappingNotify causes them to be rechecked) but you may have meant this already with "applied", I can't tell.

Nakano says: "If the native key indicates Unix's Meta key, that should be labelled "Meta+N" in UI. However, if the keys are mapped to Super or Hyper key, "Win+N" is better because they have mapped as so.". Actually I would recommend Super+N or Hyper+N. The use of Win+ as equivalent to an ambiguous coupling of two distinct modifiers with different uses sounds suboptimal.

Suggestions

It's easy to see how having both Alt and Meta act as equivalent command modifiers in Firefox worked well for Unix users, despite making Alt unavailable for Unicode mappings. Alt == Meta is about a 90% solution, and implementation was straightforward.

My thoughts (although I must apologize for focusing mostly on X end-users rather than being more platform neutral or addressing extension authoring) is to stick with that in Unix, with some specifics:

1. Users should be able to set the modifier used by Firefox outright.
   • Show only the modifiers available (in X, check xmodmap, show their current KeySym bindings, and ideally recheck them when appropriate by watcing for XMappingNotify).
2. The "which-modifier" option *should* appear in the pretty-widgets UI.
3. Let the user be explicit about modifiers.
   • When the user picks from the list { Option, Alt, Meta, mod1, mod2, ..} save the exact choice made, but when using it, the Alt/Meta should be converted to a modN through the X modmap. This way, a user who chose Meta would be fine even if he moved it from mod1 to mod2, or conversely his choice of mod1 could be stable even if he didn't have a Meta or Alt.
   • There is a question about what to do if the explicitly chosen modifier isn't present. What currently happens if both Alt and Meta are missing and mod1 is empty? Does that guide what to do here?
   • Saving picks breaks down a bit if the idea is to have preferences follow a user around between different OSes, unless the preferences themselves are also kept in per-OS-specific items. If so, then it's fine. Extension developers doing OS-agnostic mapping might explain the strange Super/Hyper = DOM Win mixing, in which case just letting users map DOM Win to either Super or Hyper internally to FF would be handy, but I may be totally missing the real point here.
4. In X, be sure to focus on the key event state modifier mask.
   • Not some more creative-but-unstable approach of trying to track up/down state of keys based on KeySyms manually, or worse yet, KeyCodes. Hopefully evdev will never even come up in this context.
5. In X, store KeySyms or mod<N> rather then KeyCodes.
   • The user has enough to handle already getting them right in X without an application arguing that a keycode should map to some *other* character.
6. In X, the Alt and Meta default makes the best sense, especially with the aforementioned ability of the user to override it.