[SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

gebeer · 2024-01-08 04:11:54

Hi there,

I am running https://cursor.sh/ editor which is a VsCode clone from their official AppImage on dwm WM.

When I open a file chooser dialogue from within the app, my mouse cursor turns from arrow into a hand symbol and I cannot click anywhere on the screen, even outside the file chooser dialogue or outside the electron app. Keyboard navigation inside the file chooser works just fine. I can close the file chooser dialogue with either Ctrl+q or Esc.

Other than that the app seems to work fine. I can drag/drop folders into the app to work on them.

I have vscodium installed on the same setup and there everything is working as expected. So I suspect that this is an Electron and/or AppImage related problem.
I can rule out issues with my mouse, since it is working perfectly fine everywhere else and the issue also happens with the laptop's mousepad.

The AppImage is started through a desktop entry. Starting it from the CLI yields same behaviour. Desktop entry Exec line:

Exec=/home/gbr/Applications/cursor_b6913c0342069000aa206b0d0220ab05.AppImage --no-sandbox %U

It seems like something is grabbing my mouse. As soon as I open the file chooser, mouse pointer turns from arrow into hand symbol. Mouse clicks are reported through

sudo libinput debug-events

but have no effect anywhere on my screen as soon as I open the file chooser.
journalctl doesn't ouput anything related. Also starting AppImage through CLI with ELECTRON_ENABLE_LOGGING=true, doesn't yield anything specific. I tried extracting the AppImage and running the contained executable. Same results.

I have no idea how to debug this further. Any help would be much appreciated.

Last edited by gebeer (2024-01-09 08:26:30)

seth · 2024-01-08 07:55:53

sleep 10; xdotool key "XF86LogGrabInfo"; printf '\a'

Then open the file dialog and wait until xdotool fired (\a is the audible bell…)

This will print all grabs into the xorg log.

Do you get the same behavior on eg. openbox?

gebeer · 2024-01-08 08:28:34

seth wrote:

sleep 10; xdotool key "XF86LogGrabInfo"; printf '\a'
Then open the file dialog and wait until xdotool fired (\a is the audible bell…)
This will print all grabs into the xorg log.
Do you get the same behavior on eg. openbox?

Here's the log: https://0x0.st/HI-Q.0.log
Unfortunately, I can't make sense out of it. Could need some help with that :-)

I don't have openbox. But on a separate Arch install with Wayland hyprland WM, file dialogues work fine.

seth · 2024-01-08 08:45:16

[ 22642.330] Active grab 0x5800000 (xi2) on device 'Virtual core pointer' (2):
======================================
[ 22642.330]       client pid 46019 /tmp/.mount_cursorsWMl6x/cursor --no-sandbox 
======================================
[ 22642.330]       at 22635596 (from active grab) (device thawed, state 1)
[ 22642.330]       xi2 event mask for device 2: 0x7001c00
[ 22642.330]       owner-events true, kb 1 ptr 1, confine 0, cursor 0x0
[ 22642.330] (II) End list of active device grabs

cat /proc/46019/comm
realpath /proc/46019/exe

hyprland won't help, you could just install and run openbox for a test (or a different, but prefereably non-tiling, WM)

gebeer · 2024-01-08 09:44:27

I installed openbox and tested behaviour. Same as with dwm.

dwm outputs:

cat /proc/46019/comm
cursor

realpath /proc/46019/exe
/tmp/.mount_cursorM9Mb1G/cursor

seth · 2024-01-08 13:12:33

So the xorg log had the right process, it's just weird - any idea what that is?
Hints in the binary?
It's on a tmpfs so it's likely copied there, probably by the cursor.sh editor

gebeer · 2024-01-09 02:22:50

Unfortunately, I have no idea what that is.
Have no experience in debugging binaries, also.

Since I cannot interpret the log snippet you extracted from my log, myself, I gave it to GPT-4. This is what it had to say:

Active Grab: An "active grab" means that a specific client (application or process) has taken exclusive control of the mouse input. This is common in scenarios like dragging a window or a pop-up menu, where the system temporarily gives control to a specific application to handle mouse events exclusively.
Client Information: The client holding the grab is identified by the process ID (PID) 46019 and is located at /tmp/.mount_cursorsWMl6x/cursor --no-sandbox. This indicates the process is related to the Electron app, as it's running from a temporary mount point typical of AppImages (/tmp/.mount_...).
Device: The device under grab is 'Virtual core pointer', which is a generic identifier for the primary mouse input in Xorg.
Xi2 Event Mask: This refers to the type of events that the grab is interested in. 0x7001c00 is a bitmask representing specific event types like motion, button presses, etc.
Owner-events: This being true indicates that the client will receive its own events (the events generated by itself), and both keyboard (kb) and pointer (ptr) events are mentioned, which means it has control over both.
State of Device: The device is 'thawed', meaning it's actively processing events, and 'state 1' typically refers to normal operation without any modifiers (like Shift or Ctrl keys being pressed).
Confine and Cursor: 'confine 0' means the cursor is not confined to a specific window or region, and 'cursor 0x0' indicates there's no special cursor being used by the grab.
The log suggests that the Electron app, when opening the file chooser, is grabbing control of the mouse but not releasing it properly, leading to the issue you're experiencing. This could be due to a bug in the app or an incompatibility with your system configuration. Since you now have the PID of the process causing the issue, you could further investigate this process or report it to the app developers for more targeted assistance.

I'll try and contact the developers about this. Thanks @seth for looking into this.

seth · 2024-01-09 08:07:29

ShitGPT4 wrote:

elaborate rendition of the xevent docu to make it look like i've to say something intelligent of importance

The xorg log doesn't "suggest", it *tells* you that a process "cursor" w/ the PID 46019 spawned by the binary /tmp/.mount_cursorM9Mb1G/cursor is grabbing the mouse.
Unless ScatGPT knows what "/tmp/.mount_cursorM9Mb1G/cursor" is, it's answer is just noise and then jumping to conclusions and

SethGPT wrote:

It's on a tmpfs so it's likely copied there, probably by the cursor.sh editor

could at least reason on the binary and did a better job at couching the accusal of a suspect as "probable"

But since that "AI-first code generator" is literally called "cursor" it's *very* probably just its binary.
Upstream bugs
https://github.com/getcursor/cursor/issues/1107
https://github.com/getcursor/cursor/issues/1023

It was probably also developed using AI…

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

gebeer · 2024-01-09 08:24:14

seth wrote:

ShitGPT4 wrote:
elaborate rendition of the xevent docu to make it look like i've to say something intelligent of importance
The xorg log doesn't "suggest", it *tells* you that a process "cursor" w/ the PID 46019 spawned by the binary /tmp/.mount_cursorM9Mb1G/cursor is grabbing the mouse.
Unless ScatGPT knows what "/tmp/.mount_cursorM9Mb1G/cursor" is, it's answer is just noise and then jumping to conclusions and
SethGPT wrote:
It's on a tmpfs so it's likely copied there, probably by the cursor.sh editor
could at least reason on the binary and did a better job at couching the accusal of a suspect as "probable"
But since that "AI-first code generator" is literally called "cursor" it's *very* probably just its binary.
Upstream bugs
https://github.com/getcursor/cursor/issues/1107
https://github.com/getcursor/cursor/issues/1023
It was probably also developed using AI…
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Had a good laugh reading your comments. Thanks again for your help and the useful links.
Cheers

Arch Linux

#1 2024-01-08 04:11:54

[SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#2 2024-01-08 07:55:53

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#3 2024-01-08 08:28:34

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#4 2024-01-08 08:45:16

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#5 2024-01-08 09:44:27

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#6 2024-01-08 13:12:33

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#7 2024-01-09 02:22:50

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#8 2024-01-09 08:07:29

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

#9 2024-01-09 08:24:14

Re: [SOLVED] Mouse Unresponsive in Electron App File Chooser on DWM

Board footer