Some apps don't detect mouse input

[ask6155]

• Version:
  wayvnc: v0.9.1-e4ec935 (makepkg)
  neatvnc: v0.9.4-50fddde (makepkg)
  aml: v0.3.0-0-gb83f357 (makepkg)

• Provide context, including but not limited to
  I running wayvnc with wayvnc -f 40 -g -p -r 192.168.0.42 -o HEADLESS-1 &
  variables set in my zsh shell
  export WLR_BACKENDS=drm,libinput,headless WLR_HEADLESS_OUTPUTS=1 river
  I'm using river 0.3.7
  What VNC client are you using?
  AVNC on my android tablet
  Archlinux Kernel 6.13.5-arch1-1
  Nouveau Drivers Mesa 1:25.0.4-1

• Try to reproduce the problem while capturing a trace log:

Info: Capturing output HEADLESS-1
Info: >> Headless output 1 1920x1200+0x0 Power:UNKNOWN
Info: -- Samsung Electric Company S19F350 H4TJ903865 (VGA-2) 1366x768+0x0 Power:UNKNOWN
DEBUG: ../wayvnc/src/ctl-server.c: 809: Initializing wayvncctl socket: /run/user/1000/wayvncctl
DEBUG: ../wayvnc/src/ctl-server.c: 778: Connecting to existing socket in case it's stale
DEBUG: ../wayvnc/src/ctl-server.c: 785: Connect failed: Connection refused
DEBUG: ../neatvnc/src/server.c: 2150: Trying address: 192.168.0.42
DEBUG: ../neatvnc/src/server.c: 2165: Successfully bound to address
Info: Listening for connections on 192.168.0.42:5900
Info: New client connection from 192.168.0.3: 0x56b42a778300
DEBUG: ../neatvnc/src/server.c: 362: Client chose security type: 1
DEBUG: ../wayvnc/src/main.c: 1640: Configuring cursor capturing
DEBUG: ../wayvnc/src/main.c: 1656: Failed to capture cursor
Info: Starting screen capture
DEBUG: ../wayvnc/src/main.c: 1030: Acquired power state management. Waiting for power event to start capturing
DEBUG: ../wayvnc/src/main.c: 1383: Client connected, new client count: 1
DEBUG: ../wayvnc/src/ctl-server.c: 941: Enqueueing client-connected event: {"id":"1","address":"192.168.0.3","username":null,"seat":"default","connection_count":1}
DEBUG: ../wayvnc/src/ctl-server.c: 968: Enqueued client-connected event for 0 clients
Info: Client 0x56b42a778300 initialised. MIN-RTT during handshake was 1 ms
DEBUG: ../neatvnc/src/server.c: 546: Using color palette for client 0x56b42a778300
DEBUG: ../neatvnc/src/server.c: 560: Client 0x56b42a778300 chose pixel format: XRGB8888
DEBUG: ../neatvnc/src/server.c: 683: Client 0x56b42a778300 set encodings: tight,zrle,copyrect,hextile,rre,raw,cursor,desktop-size,extended-desktop-size,qemu-extended-key-event,extended-clipboard
DEBUG: ../wayvnc/src/buffer.c: 606: Reconfiguring buffer pool
DEBUG: ../wayvnc/src/buffer.c: 552: Using render node: /dev/dri/renderD129
Info: Choosing tight encoding for client 0x56b42a778300
DEBUG: ../neatvnc/src/server.c: 1655: Sending extended desktop resize rect: 1920x1200
Info: Frames captured: 3, average reported frame damage: 66.7 %
Info: Frames captured: 1, average reported frame damage: 0.0 %
Info: Frames captured: 1, average reported frame damage: 0.0 %
Info: Frames captured: 1, average reported frame damage: 0.0 %
Info: Frames captured: 1, average reported frame damage: 0.0 %
Info: Frames captured: 6, average reported frame damage: 47.9 %
Info: Frames captured: 44, average reported frame damage: 48.8 %
Info: Frames captured: 52, average reported frame damage: 39.7 %
Info: Frames captured: 60, average reported frame damage: 24.0 %
Info: Frames captured: 56, average reported frame damage: 18.3 %
Info: Frames captured: 54, average reported frame damage: 31.4 %
Info: Frames captured: 43, average reported frame damage: 24.0 %
Info: Frames captured: 43, average reported frame damage: 11.1 %
Info: Frames captured: 24, average reported frame damage: 17.4 %
Info: Frames captured: 38, average reported frame damage: 7.7 %
Info: Frames captured: 31, average reported frame damage: 0.1 %
Info: Frames captured: 6, average reported frame damage: 0.0 %
Info: Frames captured: 3, average reported frame damage: 0.0 %
Info: Frames captured: 3, average reported frame damage: 0.1 %
Info: Frames captured: 14, average reported frame damage: 87.2 %
Info: Frames captured: 39, average reported frame damage: 7.8 %
Info: Frames captured: 24, average reported frame damage: 32.6 %
Info: Frames captured: 55, average reported frame damage: 10.5 %
Info: Frames captured: 52, average reported frame damage: 16.8 %
Info: Frames captured: 53, average reported frame damage: 14.5 %
Info: Frames captured: 48, average reported frame damage: 19.9 %
Info: Frames captured: 31, average reported frame damage: 6.1 %
Info: Frames captured: 22, average reported frame damage: 91.6 %
Info: Frames captured: 17, average reported frame damage: 84.3 %
Info: Frames captured: 5, average reported frame damage: 60.0 %
Info: Frames captured: 0, average reported frame damage: -nan %
Info: Frames captured: 20, average reported frame damage: 20.6 %
Info: Frames captured: 15, average reported frame damage: 0.1 %
Info: Frames captured: 1, average reported frame damage: 0.0 %
Info: Frames captured: 3, average reported frame damage: 32.6 %
Info: Frames captured: 39, average reported frame damage: 2.5 %

• Describe how to reproduce the problem
  So I have created a dummy output which I use as the output in wayvnc
  I connect to wayvnc from my tablet and use my tablet as a second monitor
  Here is how I configure the second monitor using wlr-randr:

wlr-randr --output=HEADLESS-1 --custom-mode 1920x1200@60 --scale 1.25
wlr-randr --output=HEADLESS-1 --left-of VGA-2

Some apps like obsidian, brave, slack do not detect mouse input when on the dummy output which I cast to my tablet.
When I move these windows to the dummy output on vnc they no longer respond to mouse inputs.
They work when I bring them back to my real monitor
Some others apps like my terminal or thunderbird do work on the dummy output though.
Even if the app doesn't detect mouse input I can control the window using river commands. Keyboard input works too.

I suspect it has something to do with electron maybe because all the apps that don't work are written in electron.