I have the same issue with firefox.
Also happens if steam opens [whatever the default file manager is], e.g. when clicking "show on disk" in a screenshot library.
I believe the current way is to start xdg-open and wait on it. But xdg-open calls desktop-dependent opener and it might be blocking. What is your desktop environment/window manager?
Probably Steam should use double-fork technique here.
@FreeSlave Yeah, in my case I'm not using a desktop environment. I have a thin window manager running on xinit. It should definitely double fork, ~and I think Steam does this correctly elsewhere, but perhaps just not in chat.~
Oh.. nevermind, it has the same problem when opening the link in the Help > About window.
This is the same as my issue #4727
I have just had this issue occur when opening a link for the first time, previously it only happened when steam opened the file manager.
I am using Steam beta from Dec 14 2018, firefox as the browser, thunar as the file manager.
If firefox is already running then when steam executes xdg-run it will tell the existing firefox process to open the new tab and everything is fine.
If firefox is not already running then steam will start it via xdg-run but then get stuck until I exit firefox.
Having the same issue for quite some time now. Also on Arch.
I've been experiencing this bug on Void so made a workaround: https://github.com/RunningDroid/steam-xdg-open
I use it by launching a script that changes my $PATH before exec'ing /usr/bin/steam but it's probably safe to just add it to the $PATH for your user.
I forgot about this bug. just had it happen again when I clicked a link on a users profile which opened firefox via xdg-open. I saw @RunningDroid fix for it by changing xdg-open, but is this an xdg-open bug or a steam client one?
I forgot about this bug. just had it happen again when I clicked a link on a users profile which opened firefox via xdg-open. I saw @RunningDroid fix for it by changing xdg-open, but is this an xdg-open bug or a steam client one?
That's a matter of opinion; it could be argued that it's a bug in xdg-open because it could double-fork (if it weren't written in shell) and avoid blocking the parent process, but it could also be argued that it's a Steam client bug because it doesn't work around xdg-open not double-forking (and breaks the user's expectations by freezing when they click on a link.)
@RunningDroid Given that essentially zero other applications have this issue, xdg-open not double-forking on its own doesn't seem like the bug.
Per #7419, I'll mention this is also a problem with Browse Local Files for an installed game if xdg-open blocks when launching the file manager.
Discussion of this behavior and why it exists in xdg-open here: https://unix.stackexchange.com/questions/74605/use-xdg-open-to-open-a-url-with-a-new-process
It looks like some work has been done to fix this in beta, but it's still not right. Steam no longer "freezes" for me when clicking a link which spawns the browser, or when clicking "show on disk" for the screenshots.
But, clicking a link or button a second time won't work until quitting the browser which spawned the first time. I found this out after clicking a link multiple times and wondering why it wasn't opening - after closing firefox it reopened with the next link and then continued to reopen firefox for every time I had clicked it.
So it looks like the link handling has been moved to another thread which works through a queue so the UI doesn't get stuck, but this thread is getting stuck. It also seems to be impossible to quit steam while anything is in the queue.
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
I clicked on a link in a message with no Chrome window open, and when the window opened, Steam froze (blocked) entirely. When I killed all the Chrome processes, Steam resumed.
Steps for reproducing this issue: