Taskbar icon unresponsive with 2023-04-04 Steam client beta

[DonKatsu]

Your system information

• Steam client version (build number or date): 1680644306
• Distribution (e.g. Ubuntu): Fedora 37 KDE
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes
• System Information gist

Please describe your issue in as much detail as possible:

After updating Steam to 1680644306, double clicking/right clicking the steam icon in the taskbar does nothing. Launching steam through console reveals this message when clicking the icon: (steam:430666): LIBDBUSMENU-GLIB-WARNING **: 19:23:23.723: About to Show called on an item wihtout submenus. We're ignoring it.

Steps for reproducing this issue:

1. Launch Steam
2. Double click/right click the taskbar icon

[kisak-valve]

Hello @DonKatsu, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

[rLy07]

I also have the same issue on Arch, gist.

[smcv]

If you completely exit from Steam, then re-run it with STEAM_RUNTIME_PIN_32BIT_GTK=1 in the environment, like this:

STEAM_RUNTIME_PIN_32BIT_GTK=1 steam

does that avoid this issue?

(You should see a warning message Warning: $STEAM_RUNTIME_PIN_32BIT_GTK will be removed in a future version when you do that - but if the change that is reverted by STEAM_RUNTIME_PIN_32BIT_GTK=1 is causing this issue for you, then we'll have to re-think that.)

[smcv]

It looks like you're both using KDE Plasma, which is probably significant.

[ElaborateCalculator]

It looks like you're both using KDE Plasma, which is probably significant.

Sorry, same problem on XFCE: gist

Running with

STEAM_RUNTIME_PIN_32BIT_GTK=1 steam

restores the expected behaviour when clicking on the icon

[smcv]

OK, please use that workaround for now. I'm looking at reverting the change.

[smcv]

@kisak-valve, please could you retitle this to indicate that it's a beta regression?

[tatokis]

@smcv In reply to https://github.com/ValveSoftware/steam-for-linux/issues/8577#issuecomment-1497450839 (since I didn't realise it's a very recent regression, as it's been happening in the past sometimes), I think it's more appropriate to continue the conversation here.

I'm on Ubuntu 20.04 with Unity. https://gist.github.com/tatokis/f6e47baca1a7a9202752401f224d52e2 The above was generated after having manually made the symlink in the runtime (with the SNI working).

$ dpkg-query -f '${Package}\t${Version}\t${Status}\n' -W libgtk2.0-0 libdbusmenu-glib4 libdbusmenu-gtk4 libdbus-1-3
libdbus-1-3 1.12.16-2ubuntu2.3  install ok installed
libdbus-1-3 1.12.16-2ubuntu2.3  install ok installed
libdbusmenu-glib4   16.04.1+18.10.20180917-0ubuntu6 install ok installed
libdbusmenu-gtk4    16.04.1+18.10.20180917-0ubuntu6 install ok installed
libgtk2.0-0 2.24.32-4ubuntu4    install ok installed
libgtk2.0-0 2.24.32-4ubuntu4    install ok installed

[rLy07]

@smcv Just to confirm using STEAM_RUNTIME_PIN_32BIT_GTK=1 steam also working on KDE as well.

[smcv]

since I didn't realise it's a very recent regression, as it's been happening in the past sometimes

I think there might be two things happening that end up with the same symptom.

One (this issue) is a very recent regression, in yesterday's beta: in the beta, we intentionally stopped "pinning" GTK 2 to the Steam Runtime's old version in favour of allowing the OS's newer version to be used (because the more old versions we force to be used, the more bugs we're likely to encounter). Unfortunately, on at least some OSs and desktop environments this led to a regression (this issue), so I'm looking at reverting that intentional change.

The other (#8577) seems to be much older: in older versions of Steam, the runtime was meant to always "pin" the 32-bit GTK 2, libdbusmenu-gtk and libdbusmenu-glib to the versions from Steam Runtime 1 'scout' if there was a 32-bit copy of the corresponding library installed system-wide, so that the Steam Runtime's copy would override the system copy. In your case, for some reason that I don't yet understand, that pinning was unintentionally not always effective for all users on all occasions, and sometimes re-running the runtime's setup scripts or applying workarounds by hand was necessary to make it do the right thing.

[smcv]

@tatokis Please could you try:

dpkg-query -f '${Package}:${Architecture}\t${Version}\t${Status}\n' -W libgtk2.0-0 libdbusmenu-glib4 libdbusmenu-gtk4 libdbus-1-3

(sorry, I should have asked for the ${Architecture} the first time.)

What I suspect will happen is that you have libdbusmenu-* for amd64 only, and the other two libraries for both amd64 and i386. (But I could be wrong: you might have libdbusmenu-* for i386 only.)

[tatokis]

@smcv Understood. Thank you for the explanation.

I'd like to note that while debugging this initially, I first tried deleting the pin symlinks entirely for libdbusmenu*, and that changed nothing. I then manually deleted the .so files from the runtime and ended up with no SNI and the Steam UI being scaled massively as if I was on a 4K screen.

Of course, the runtime has been reset after performing the above actions.

Additionally, while debugging, when comparing the old and new runtime pins, I saw a dead symlink to libSDL in the old (stable) runtime, but I don't think it was relevant. Complete speculation on my end: maybe it encountered a broken one and gave up somewhere. Thought it was worth mentioning.

What I suspect will happen is that you have libdbusmenu- for amd64 only, and the other two libraries for both amd64 and i386. (But I could be wrong: you might have libdbusmenu- for i386 only.)

I noticed that too while running the command and actually checked to see. The i386 -gtk4 and -glib4 packages are simply not available at all from the repos, so only amd64 is installed.

libdbus-1-3:amd64   1.12.16-2ubuntu2.3  install ok installed
libdbus-1-3:i386    1.12.16-2ubuntu2.3  install ok installed
libdbusmenu-glib4:amd64 16.04.1+18.10.20180917-0ubuntu6 install ok installed
libdbusmenu-gtk4:amd64  16.04.1+18.10.20180917-0ubuntu6 install ok installed
libgtk2.0-0:amd64   2.24.32-4ubuntu4    install ok installed
libgtk2.0-0:i386    2.24.32-4ubuntu4    install ok installed

$ LANGUAGE=en apt-cache policy libdbusmenu-glib4:i386
N: Unable to locate package libdbusmenu-glib4:i386
$ LANGUAGE=en apt-cache policy libdbusmenu-gtk4:i386
N: Unable to locate package libdbusmenu-gtk4:i386

[smcv]

Additionally, while debugging, when comparing the old and new runtime pins, I saw a dead symlink to libSDL in the old (stable) runtime, but I don't think it was relevant. Complete speculation on my end: maybe it encountered a broken one and gave up somewhere. Thought it was worth mentioning.

Thanks, that's interesting. Any dangling symlink in pinned_libs_* is a bug - the symlink should either be absent, or present and pointing to the actual library in steam-runtime/[usr/]lib/*/ - so certainly something was wrong there, and after the fix for the immediate regression is out, I'll think about whether it could have been related.

I first tried deleting the pin symlinks entirely for libdbusmenu*, and that changed nothing

That's expected. The part of Steam that is responsible for the tray icon is an i386 process, so if you only have a system copy of libdbusmenu* for amd64, then Steam has no choice but to use the runtime's i386 copy of libdbusmenu*, and therefore it doesn't matter whether the pin symlinks are there or not.

I then manually deleted the .so files from the runtime and ended up with no SNI and the Steam UI being scaled massively as if I was on a 4K screen

Manually deleting libdbusmenu*.so.* from the runtime would have resulted in Steam being completely unable to load them. I have no idea why that would affect the UI scaling (that seems like weird action-at-a-distance), but in any case that isn't a supported or supportable situation.

[tatokis]

Thanks, that's interesting. Any dangling symlink in pinnedlibs is a bug - the symlink should either be absent, or present and pointing to the actual library in steam-runtime/[usr/]lib// - so certainly something was wrong there, and after the fix for the immediate regression is out, I'll think about whether it could have been related.

It doesn't happen in the latest beta, so it's possible that whatever was causing that is now fixed.

Manually deleting libdbusmenu.so. from the runtime would have resulted in Steam being completely unable to load them. I have no idea why that would affect the UI scaling (that seems like weird action-at-a-distance), but in any case that isn't a supported or supportable situation.

Yeah, the idea was to force it to use the system ones. I hadn't realised that there were no i386 system packages at that point.

[DonKatsu]

Taskbar functionality is restored for me with Steam 1680735902. I assume the reversion was included, but it's not mentioned in the release notes.

[rLy07]

Fixed for me as well, thanks!

[ElaborateCalculator]

Confirmed working correctly for me with Steam 1680744168, thanks

[smcv]

Taskbar functionality is restored for me with Steam 1680735902. I assume the reversion was included, but it's not mentioned in the release notes.

The latest Steam client beta 1680744168 includes the runtime version with a partial revert (0.20230405.47155). Steam Runtime changes often don't get into the Steam client release notes, for whatever reason.

I can't confirm or deny 1680735902 having the same change, but it doesn't really matter either way, as long as the latest version in each public branch of Steam (beta and general-availability) is working.

@kisak-valve: because this issue report was specifically for a beta regression and never affected the general-availability branch, I think we should close this issue now that it's fixed in the beta.

If anyone else is experiencing similar symptoms after making sure they have the latest version (either beta or general availability), let's use #8577 to represent that. As I said above, we don't understand why it's inconsistent/intermittent (we would usually expect it to either work for everyone or fail for everyone), but I'm going to see whether I can make the script more robust, and that might help.

[kisak-valve]

Closing as fixed.