Uzbl

Because it is reading stdin. See:

http://github.com/dequis/uzbl/commit/97526404f52875d82d584f18420be72fdc300d93

I find that fix rather unclean.
I'm no expert in this field but I have the feeling what we should do is intercept when we're about to be backgrounded, and stop listening on stdin when that happens. When we're forgrounded we may start listening again, though I'm not sure if that's useful at all. In fact I'm not sure about any of this.

http://www.unix.com/linux/52750-question-about-background-processes.html

Ok, so I've been investigating a bit how CTRL-Z works.
First SIGTSTP is sent, then SIGSTOP. You can handle SIGTSTP, but not SIGSTOP. Going to background means receiving SIGCONT.

Of the apps i've checked that seemed to have good stop handling, bash and lftp (readline), both ignore SIGTSTP, so you can't use CTRL-Z directly. Instead, they provide a "suspend" command that is supposed to do cleanup, but didn't change much. Sending bash to background kills the parent bash (!). lftp seems to handle it better, since it is designed to stay working on background, but sending SIGSTOP triggers the same behavior. The "suspend" command does nothing more than sending itself SIGSTOP, but it does get it out of the readline loop.

After this it may seem strange that they took this approach, instead of handling SIGTSTP and getting out of that readline loop. But I think I know why: they can't get out of the readline loop, just like we can't get out of a blocking stdin read call. And they are all blocking, because of the I/O buffer.

Clean solution? Add a suspend command, ignore SIGTSTP (disallow ctrl-z).

16:38 < dxdx> oh, Dieterbe: i think i have the solution to the stdin problems. instead of reading it as default, read it only if config file is "-", as in uzbl -c-
17:07 < Dieterbe> dxdx: hmm... yeah maybe

http://github.com/dequis/uzbl/commit/ed39cbe56f8923407604a1306a179529521ecd26

But it's uzbl -c -, with a space between.