Done. It's here: https://gist.github.com/stahara/9f0923f832a5bec64a0e16998fd9517e

I also edited it into the original issue report.

I'm seeing a reappearance of the black browser window bug too (also on Arch Linux), but what's weird is I only see it when I launch Steam from the app launcher. When I run steam from the terminal, everything works as normal. Which makes it really frustrating and hard to troubleshoot, since I can't get any of the error messages because the error doesn't happen when running from the terminal.

@stahara: Do you maybe have environment variable PS4 set to something that contains variable expansion like ${foo} for non-interactive shells, like the reporter of #8054 did? Or perhaps you have BASH_ENV set to something that is not safe for non-interactive shells?

Is your steamwebhelper.sh the same as https://gist.github.com/smcv/b4f4f18f127c8893c05604c8753e280f?

If you have not modified it, you can see for yourself that steamwebhelper.sh line 48 doesn't mention FUNCNAME; but perhaps the variable is getting evaluated by the shell as a side-effect of set -x (which was not really meant to be there either, it's a piece of leftover debugging from when we were getting the solution to #7935 working). A future Steam version should drop the set -x, but I don't think that change is in a release yet.

Workaround: if you run Steam as env -u PS4 steam or PS4="" steam that might avoid this.

The use of set -u in steamwebhelper.sh was meant to be there to increase robustness by making the script "fail safe" in broken situations where a variable we thought was set is actually unset ("unofficial strict mode"); but it seems like it might break more user configurations than we had anticipated. If this is widespread, then we'll have to stop using "unofficial strict mode" and take the risk of introducing worse bugs.

If my guess about PS4 is correct, you can make it more less likely to break things by using ${foo-} instead of ${foo}. (The same thing is a good idea for PS0 up to PS3 if you use variable expansion in those.)

@gardotd426: "The black browser bug" is a symptom, not a bug. All it means is that steamwebhelper cannot start up correctly, which could happen for any number of reasons: until we can find a way to see an error message, we do not have any evidence about whether you are experiencing the same bug (same root cause) as @stahara, or not.

Unfortunately, we are unlikely to be able to diagnose what bug (root cause) is triggering this for you without more information.

If you are using systemd and a well-integrated desktop environment like GNOME, you might find that stdout/stderr from Steam ends up in the systemd Journal. Please look for error messages there?

Or, you could try editing /usr/bin/steam (or /usr/games/steam or /usr/bin/steam-runtime or whatever name your distribution uses for it) to insert

exec > "$HOME/steam.log" 2>&1

near the beginning, and then look at $HOME/steam.log for error messages?

Or, if you think you might be seeing the same root cause as in #8054, you could try

echo "$PS4"

in a shell, to check whether your debug-string "prompt" PS4 contains variable expansions like ${foo} (which were the root cause of #8054, and maybe this issue too). If it does, try disabling (commenting out) any custom PS4 setting that you might have in shell initialization files such as ~/.bashrc, ~/.profile, ~/.bash_profile, ~/.bash_login and their equivalents in /etc, and seeing whether this resolves it.

what's weird is I only see it when I launch Steam from the app launcher. When I run steam from the terminal, everything works as normal.

I think this might point towards this being triggered by some environmental thing. For example, if it involves PS4, perhaps we might find that you're setting PS4 during early login (so it is set for everything, including your GUI), to a value that involves variable expansions like ${foo}. If you are setting foo on entry to an interactive shell, then Steam would work fine when run from an interactive shell, but would not work when run from a GUI launcher that is not a child/descendant of an interactive shell and therefore does not have foo set.

My goodness, you nailed it. Thank you! It was, indeed, my custom PS4.

A future Steam version should drop the set -x

Steam client beta 1632409172 (2021-09-23) no longer has this, so your PS4 environment variable shouldn't cause that problem any more in the beta.

@gardotd426, please try with the Steam client beta and see whether it resolves whatever issue you are having. If it does not, please gather as much information as you can (as described in my previous comment), and then open a separate issue with that information.

Confirmed. I have re-enabled that PS4 environment variable and the new Steam client beta update has no issues. Thanks for all your help!