Implement DOM3 KeyboardEvent.key and KeyboardEvent.code

[Wezarus]

Here are some bugzilla entries (not sure, if I've picked the most relevant ones, just hope to point you in the right direction):

Bug 912858 - Implement KeyboardEvent.key for printable keys (except dead key handling) - This was introduced with Firefox 29 (I think)
Bug 680830 - Implement DOM3 KeyboardEvent.key
Bug 842927 - Implement DOM3 KeyboardEvent.key only for non-printable key, first - this may not required, included it for completeness

Bug 1126673 - Enable KeyboardEvent.code in default settings of release build - This was introduced in Firefox 38

These two properties are needed for the VimFx extension, which is a very useful light-weight alternative to Pentadactyl and Vimperator and allows efficient control of various browser actions with the keyboard without changing the browser UI the way those two extensions do. Its latest release version 0.5.17 (and the latest in their dev branch on Github, which contains many other improvements) however has switched from using the KeyboardEvent.keyCode property to KeyboardEvent.key, which in Pale Moon evaluates to the string "MozPrintableKey" for printable keys, instead of to a string containing the letter typed, e.g. "j". This makes the extension not function at all. Here is a more detailed Pale Moon support request that I filed with the extension developers a few months back, which was recently rejected (surprise, surprise).

The KeyboardEvent.code support is needed for VimFx's "Ignore keyboard layout" setting. It's a very nice feature that allows you to have an active keyboard layout other than US English and when you press a key, it's mapped to its US English equivalent and the action bound to it is performed. It used to exist as a preference in the extension settings, but with the release of Firefox 38, the extension devs have made it a requirement and that feature is indeed quite handy.

If you decide to implement this, I'd be perfectly happy to help by testing a private build, if you deem it necessary.

[Moonchild]

And what spec is this in, exactly?

[Wezarus]

Um, this one? Link taken from the first comment in the first bug. Search for "KeyboardEvent.key" and the second occurrence takes you to a Warning with some info.

Look, I'm really not familiar with the specifications (or their drafts). I only wrote DOM3, because it was written that way in the title of the bugzilla entries.

[Wezarus]

Is there any chance you'll add this functionality?

[Moonchild]

I'm sorry but considering it is only used for one extension that I know of, for one uncommon feature in it, it is very low on the priority list. If you really wish to have this feature then I'd suggest you try and port the patches across to our code base and submit a pull request - no real time frame for this on our agenda at the moment.

EDIT: Made a note in our issue tracker for this request: https://github.com/MoonchildProductions ... issues/114

[Wezarus]

I think you might have misunderstood me a little. I have a tendency to write long posts, so mea culpa on this one . "KeyboardEvent.key" is required by the extension to function. It uses the property to determine which key or key combination has been pressed and that's the primary function of an extension that allows you to bind keys to actions. Since Pale Moon currently just returns the string literal "MozPrintableKey" for printable keys instead of a string, containing the letter that was pressed ("j" or "d", etc.), the extension is rendered completely unusable. "KeyboardEvent.code" was indeed used for an optional feature, but was recently made a requirement too.

That said, I completely understand this being low priority on your long TODO list. Still, I'd be great, if you could maybe revisit this some time down the road, when you don't have other pressing issues with the Iguana of Oz among other things.

[Moonchild]

I'm sorry to hear the CimFx have gone this route; because of this hard requirement you will have to use either perfectly working alternative extension OR use an older version of VimFx that does not have this requirement until such time as this can be tackled and the functions implemented (either by our dev team or by an independent contributor who wishes to make this compatibility bridge). This is why an issue has been opened as an enhancement on GitHub -- Anyone is free to pick this up and offer an integration patch for these functions by cloning the repository, making the changes, building, testing them, and then making a pull request to merge the code back into the main repo which will be appreciated and welcomed. Pale moon offers open development and welcomes community contributions of all sizes - working together to improve it!

As you understood, we do have more important things on our list - first and foremost making this engine transition happen, adding WebP support (and hopefully JPEG XR support as well), updating the VP8/VP9 lib for better compatibility with recently-encoded videos, updating CSP, updating security, etc. etc. - all things that will impact the vast majority of Pale Moon users which does mean that smaller compatibility issues with very specific extensions due to the extension developers' choices of targeting Firefox's moving target exclusively (instead of keeping broader support for different browsers) will have to be put on the backburner.