hotkey configuration disappears for some keys

[hg42]

I tried to assign a key to the findbar. When pressing Ctrl+^ the key display disappeared and it is no longer possible to set a new key. For some other keys a text replaces the key display, but it seems the checks do not cover all possibilities.

I would suggest to add a min-width/height to the key display so it never disappears (or some similar strategy). Eventually the background could be an indicator that the field is empty and covered by the key display if set. Though the state with an empty key display is probably different from an unset case. At least the Ctrl+^ doesn't work, so it's similar to an unset hotkey.

[hg42]

The height is zero, because this helps in d_findBarHotKey (tested via inspect)):

min-height: 20px;
background: lightgray;

[ssborbis]

I'm not seeing that issue with CTRL+6. Tested on win10 and ubuntu18.

I do see problems with key combos that are FF built-in commands like CTRL+5, CTRL+T, etc where function will execute (tab change), but the key does get set. Any other keys it fails on?

[hg42]

Ctrl-6 ? I talked about Ctrl-^ (circumflex) or is it on 6 for you ? We have it below Esctogether with a degree character (°). But that doesn't matter. I had several occasions where the key display was empty and I couldn't change the key afterwards. I solved it somehow, but with developer tricks.

Any other keys it fails on?

F13-F19 (on a mac keyboard) German umlaut ö Ctrl-< probably several more.

I get the feeling these are often keys that are catched and probably changed by someone else before it's delivered to CS. I also found that reloading the page works. The key that is displayed then, is the key that was set before, so I guess it was delivered as null or at least invalid in some way. It is not entirely consistent.

[ssborbis]

Looks like it will fail on keys outside of what I have defined in keyTable.js. I'll try to fallback to displaying the keycode for undefined keys. I based definitions off the standard US QWERTY board. Murca!

[hg42]

this node module claims to be independent on the keyboard layout: https://www.npmjs.com/package/is-hotkey is-hotkey - npm

it uses: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key

which I tested (using the linked CodePen). At least it assigns names to the keys that make sense. Some keys are linked to their Function instead of the key name printed on it. E.g. F13-F19 are LaunchApplication5-LaunchApplication11 (not exactly sure about F13 and F19, because I have assigned them to some system function, the library says "Unidentified"). All keys mentioned in my previous comment are decoded correctly.

[hg42]

This also works on Chrome. Interesting, that F13-F18 give me F13-F18 on Chrome. F19 shows a rectangle character (which I couldn't copy to here, may be it's a null or something weird).

[ssborbis]

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key

I checked that out, but there doesn't appear to be a way to get from keyCodes to KeyboardEvent.key. The whole Event.[which|key|code|keyCode|charCode] seems like a huge mess right now. The old standards are listed as depreciated and I'm not sure where to go. I'll stick with the keyTable and add missing chars where I can, default to the keyCode where I can't. I've already put the missing F keys in.

[hg42]

Looking at the example code I see that I misinterpreted the KeyboardEvent.key, it's simply the property of the usual Event. I thought it would be some additional functionality. And now I don't understand why this isn't enough to decode any key? (except multimedia keys on Windows), especially because it decodes all of my non-working keys?

[hg42]

@ssborbis currently the hotkeys are broken for special keys. Today, after updating the repo, I tried F13-F19 and they all gave me a "0" (seems to be code zero, so single digit codes look like the digit keys). F13-F19 work all like one key, so I can open the sidebar with any of them. I think it is a default code.

[hg42]

again, why isn't KeyboardEvent.key working for you? It decodes all my special keys to some meaningful name (not necessarily the key label, but good enough, e.g. LauncherX for Fxx). Doesn't it work on Windows? or on Chrome?

[ssborbis]

currently the hotkeys are broken for special keys.

I need to simulate some inputs. It would be so much easier to have a F13 key for testing!

again, why isn't KeyboardEvent.key working for you?

It's not so much that it's not working, it's that I can't convert the .keyCode arrays I use now to .key. There doesn't seem to be any function in the API for making the conversion. I'll need to find a conversion table or something and loop over the array to tease out the .key string.

[ssborbis]

I just tried simulating single key events [F13,F14, F15] when setting the sidebar hotkey and it appears to be working for me. I show the F13 string in the displayed hotkey button and the keycode is stored as it should be. What are you seeing after you 'click to set' the F13 key? A zero?

What keycode do you show for F13 on this page? https://keycode.info/

[hg42]

What are you seeing after you 'click to set' the F13 key? A zero?

I have assigned F13 and F19 to some OS function, so I can only tell something about F14 to F18

if I click the key config of the sidebar an press any of these keys, the key config completely disappears and I can no more click on it (seems to be size zero). The same for the highlight key config.

When I reload the settings page and go to the section again, I find the old key, so it wasn't changed.

But, if I do the same on the context menu key config, I get a very small button instead. The dashed selection rectangle seems to have no or zero sized content, so the button shrinks. But at least it doesn't disappear (the code seem s to be different).

What keycode do you show for F13 on this page? https://keycode.info/

F14 to F18 give me a big zero. They decode to F14="Launcher6" up to F18="Launcher10" in event.key and event.code is "F14" to "F18". Note I am now on Firefox 68. I think it was a little bit different on older versions [EDIT: when I tested it with developer tools, not the keycode.info page], but I cannot fully remember [the exact difference].

[ssborbis]

As soon as I figure out how to convert a user's current keyCode array to KeyboardEvent.key, I'll make the switch. I'd rather not make everyone reset all their hotkeys.

[hg42]

do you mean to convert his/her current configuration to the new version?

I think, converting the setting to a textual representation should work.

Currently you compare the event code with the stored code (regardless of it's coding).

Let's say, you have a transformation function (something like keyevent_to_keytextrepr), that should already exist in some way for displaying the key.

If you abstract the code with the conversion function in the storage and when receiving the event you should get an equivalent result when comparing the representation.

Now, if the function changes, because you are using a new source for the code in the event, the comparison is still abstract and works equivalent.

The change only fails for keys that result in a different representation.

There could be a table that provides known aliases of key names (those that change their representation or where the representation is not ). Or may be a permanent table for alternative names. The first entry could be the desired key name, the rest would be converted to this standard name whenever they are used.

[ssborbis]

I've started moving hotkeys to KeyboardEvent.key from KeyboardEvent.keyCode. I can't convert using a function or table so I'm using the same variable in options to store either a keyCode array or an object containing the relevant info ( key, mode keys ) and using some if ( Array ) else if ( Object ) conditionals in the hotkey listeners to convert from old-style array to new-style object when a hotkey is used.

So far the only keys affected are the sidebar and findbar hotkeys.

Be aware I did have a nasty bug where the first keyboard key typed overwrote the hotkeys, making that particular key unable to be used on webpages afterwards until the setting was cleared. I think it's fixed but just a heads up if you inexplicably can't type a particular key.

Changes are in the latest push.

(edit) Setting a hotkey in options should be displaying the .key text vs the keyCode -> conversion table -> text

[hg42]

this seems to work well... The two keys I assigned for some system wide (low level linux) hot keys result in "Unidentified" which is expected.

A minor suggestion: I wouldn't style the "Unidentified" as a hot key button (may be only as a text?) to be more clear that it's not a key.