SnosMe / uiohook-napi

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Don't work with active window

slpzc opened this issue · comments

If I make the window inactive, it works without problems.
However, if I make the window active, it is as if it stops working

uIOhook.on('keydown', (e) => {
    if (e.keycode === UiohookKey.T) {
      if(!isPressed) isPressed = true;
      else if(isPressed) return;
      mainWindow.webContents.send('responseAudioButton', true);
      console.log('[DBG KEY]: SEND PRESSED!')

    }
  })
  uIOhook.on('keyup', (e) => {
    if (e.keycode === UiohookKey.T) {
      if(isPressed) isPressed = false;
      else if(!isPressed) return;
      mainWindow.webContents.send('responseAudioButton', false);
      console.log('[DBG KEY]: SEND UNPRESSED!')
    }
  })

  uIOhook.start()

What you describe matches the Windows UIPI behaviour. Less privileged app can't listen to events of more privileged process.

@SnosMe could you explain this a bit more? I've been struggling with this issue for awhile now. I'm using a similar library (iohook) in an electronjs app. On Mac, it works fine. But, on Windows, when I connect to a WebRTC server, it only works if I have any other window in focus. Even if I use "Run as Administrator" when starting the terminal which is running the electron app. I can see that the electron process is "Elevated" in task manager.

For some reason this only happens when I'm using a third party lib from dyte.io to connect to their WebRTC server. Unfortunately the third party lib isn't open source :( But, I'm curious if you might know what could cause the events to stop firing.

As I said Windows only doesn't call hook when focus is on Elevated window and nodejs started as not elevated.
I have no issues when Desktop itself is focused.
Webrtc has no connection to this, as always use minimal reproducible example strategy.

Webrtc has no connection to this, as always use minimal reproducible example strategy.

It would seem that WebRTC is in fact the culprit because it uses low-level keyboard events to determine whether or not to cancel noise made by a user's keyboard, and registering multiple such events on the same application seems to be Windows limitation.

A few links documenting the issue:

Unfortunately, Chromium devs have marked this as won't fix because it's an issue with CEF and not chromium itself. I haven't found a workaround yet.

Well, you did better research on this one. And if Windows doesn't support multiple hooks from the same process, then what can we do? It's also separate issue from the one about UIPI here.