Don't work with active window

slpzc commented 6 months ago

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()

SnosMe commented 6 months ago

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

Rydez commented 5 months ago

@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.

SnosMe commented 5 months ago

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.

Rydez commented 5 months ago

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.

SnosMe commented 5 months ago

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.

SnosMe / uiohook-napi

Don't work with active window #42