rofi -dmenu freezes if stdin is closed

[miseran]

Version

Version: 1.4.2

Configuration

https://gist.github.com/miseran/1298ad6f7fa7cb1b23e2d8c74d1c3a2d

Launch Command

( sleep 10; killall rofi; ) & rofi -dmenu <&-

What behaviour you see

Rofi grabs mouse and keyboard, but never opens a window, so all of X becomes unresponsive. Rofi needs to be killed some other way.
This didn't happen in 1.3.

Stdin is often closed for dmenu if arbitrary input is needed, without providing options. While there are other ways to do this (e.g. echo -n '' | rofi -dmenu), it would be nice if this way worked as well, or at least didn't lock everything up.

[DaveDavenport]

Hmm unexpected, will need to check.
I actually tried to improve the situation by checking if stdin is a tty. (rofi -dmenu in terminal should work now)

(fun, if I run in strace, it does not hang..)

[DaveDavenport]

(p.s. quick workaround: rofi -dmenu -async-pre-read 0 )

[DaveDavenport]

Wonder if there is a way to check that it is closed. The glib functions still tell me it is open :D.

[has2k1]

When embed in a script I had these -- myvar=$(rofi -dmenu) -- types of statements failing. As per the workaround, these -- myvar=$(rofi -dmenu -async-pre-read 0 ) -- work.

[DougBeney]

Happening to me with the drun option after updating my system today. I3-gaps, Arch, Xorg, Rofi 1.5.0-dirty.

[DaveDavenport]

@DougBeney Don't think that is related at all, more likely this:#763

[epitron]

Another way to trigger this bug is to fill up STDIN too slowly. eg:

while true; do echo hello; sleep 1; done | rofi -dmenu

Side question: how is the blocking pre-read supposed to make rofi feel more snappy? I just tried running find / | rofi -dmenu -async-pre-read 0, and I can't perceive any delay or slowdown...

[DaveDavenport]

It is more a livelock then a lock-up and a side effect of the implementation (not really a bug). Pass the -async-pre-read 0 to avoid it.

Not everytime, it tries to update the view (if changed) in idle time.. but it feels a tat slower (for smaller lists) as it only shows the list after on first redraw, not instantly.

[epitron]

Hmm... Maybe the default setting in -dmenu mode should be -async-pre-read 0 then, and people can manually setup a blocking prebuffer if they find it too slow.

I think another good idea is to not capture the keyboard until the rofi window has actually displayed...

[DaveDavenport]

Please don't start unrelated discussions in this issue (see rules). This has been discussed in other issues (#709 #494).