[BUG] Holding down command and then hitting a sequence of keys, doesn't trigger Command+X keys after first

[natew]

Describe the bug

I have roughly this:

<GlobalHotKeys keyMap={{
  COMMAND_1: 'command+1',
  COMMAND_2: 'command+2',
  COMMAND_3: 'command+3',
}} handlers={{
  COMMAND_1: () => console.log(1),
  COMMAND_2: () => console.log(2),
  COMMAND_3: () => console.log(3),
}} />

Expected behavior

1. Hold down Command
2. Press 1 => 1
3. Press 2 => 2

I don't see 2 being logged in pre7.

Platform (please complete the following information):

• Version of react-hotkeys
• Browser Chrome
• OS: Mac Mojave

Are you willing and able to create a PR request to fix this issue?

If you point me roughly at the area!

[greena13]

Hi @natew,

I'm not sure why you are seeing this on pre7. If you were using pre8, I'd guess it was likely a regression introduced by trying to address #183 or #177.

The first step would be to upgrade to v2.0.0-pre8 and see if it fixes it (I don't think it will).

If you want to take a stab at tracing the issue, I suggest you enable verbose logging and pay attention to the Key history: lines:

configure({logLevel: 'verbose'});

An array of key combinations is maintained - it's the keys attribute you need to pay attention to.

• Each key has two arrays as values, one for the current state and one for the previous state.
• Each of these has 3 elements, one for each key event (keydown, keypress, keyup).
• Each element can take on one of 3 values (0 = unseen (hasn't happened yet), 1 = seen, 2 = simulated)

HotKeys (F0📕-E6❤️-C0🔺-P0🔺:) Key history: [
    {
        "keys": {   // 1st combination: 'a'
            "a": [
                [       // Previous state
                    1,  // Seen keydown
                    1,  // Seen keypress
                    0  // Not seen keyup
                ],
                [        // Current state
                    1,   // Seen keydown
                    1,   // Seen keypress
                    1   // Seen keyup
                ]
            ]
        },
        "ids": [
            "a"
        ],
        "keyAliases": {}
    },
    {
        "keys": {  // 2nd combination: 'b'
            "b": [
                [
                    1,
                    1,
                    0
                ],
                [
                    1,
                    1,
                    1
                ]
            ]
        },
        "ids": [
            "b"
        ],
        "keyAliases": {}
    }
].

The ids attribute of the combination must contain a match for your key combination, and the combination's current state must match your key event (in this case, implicitly keydown).

Once you get familiar with the logs, you will know more about why it's failing.

The GlobalKeyEventStrategy and its parent AbstractKeyEventStrategy are the relevant files. Start with the handleKeyDown to orient yourself.

Let me know how you get on. Here to help.

[natew]

Any chance you'd be open to consult on this for a short term? Would be really helpful for our team, let me know. I don't see your email anywhere public, feel free to email on the one in my profile.

[greena13]

@natew, Sure, I'll do what I can. I've sent you an email.

[greena13]

Hey @natew,

I have been looking into this and I was wondering if the example above are the actual key combinations you're binding to, or if they are for demonstration, only. When I press cmd+1, cmd+2 in a Chrome browser, it changes between tabs. This is a different use case than a cmd+ that doesn't change browser tabs.

If you are using cmd+1 etc in your app, are you preventing the browser default behaviour?

Just trying to make sure I'm solving the right problem. Thanks.

[natew]

Ah yea this is in an electron app. I can confirm even with ignoreRepeatedEventsWhenKeyHeldDown: false it still doesn't work "properly" in this case, whereas it was previously.

I tried with ctrl+1, etc and it does work properly! So seems to be just a command thing.

[greena13]

Thanks for your further information, @natew.

It helped me arrive at what I believe is the best (but not perfect) solution in #207. Please see #207 for a description of the underlying issue if you're interested. Otherwise, the next release which I'm putting together should restore your Cmd+X key combinations to their original functionality.

[greena13]

Should now be available in v2.0.0-pre9.