Menus don't work with Linux client

[pkeller]

With the last couple of versions of the Linux Zoom desktop client, I find that some menus (including the main menu and the audio/video selection menu) don't work: they appear for a fraction of a second and then disappear again. The last version that worked is 5.17.5. Versions 5.17.10 and 5.17.11 show this problem, which makes the desktop client unusable in practice. One of the institutions that host meetings that I attend has a very strict policy on using up-to-date versions of the client, so using version 5.17.5 may not be a usable workaround for much longer.

I am using Gnome/Wayland on openSUSE 15.5.

This looks similar to a problem reported on the Fedora forums at https://discussion.fedoraproject.org/t/zoom-menus-dont-show/82677/1 but openSUSE 15.5 uses an older version of mutter (41.9) than that reported there.

For completeness I have attached zoom logs for working and non-working versions, although I can't see any significant difference between them.

Does anyone have any suggestions about how to fix this, or whether there might be a fix coming soon?

[emb]

I am grateful for your posting this.  I am on Debian/StumpWM and since the update I can no longer use Zoom.  If the menus appear at all, the menus disappear when any popout or menu is item used and it reverts to a full screen minimised version and the only way to try to get the menu back was kill the client.

I found this kludge fixed it.  https://community.zoom.com/t5/Meetings/The-app-window-gets-minimized-when-switching-workspaces-in/m-...

Maybe will work for you too?

[pkeller]

Thanks for the reply, but this looks like a different problem. I tried what you suggested, and it didn't make any difference.

I am pretty sure that this is specific to certain desktops. I see the same issue with Gnome/Xorg (so maybe not a Wayland-specific problem?). With IceWM it is OK but that is really not a great workaround though.

[user42]

I had the same problem (on xubuntu). I noticed the main window was losing focus for the brief moment the menu was popping up. Changing my window manager focus setting from "focus follows mouse" to "click to focus" fixes the problem. Annoying, but usable.

[pkeller]

Many thanks for finding this - changing the focus policy works for me  as well.

Although you deserve a lot of kudos for this, I'm not going to accept this workaround as a solution - the issue can only really be solved by Zoom developers fixing the Desktop client. If any of them read these forums, your finding should help them to narrow things down. I'll try to open a ticket with them about this.

Thanks again.

[whitwham]

Thanks for posting.  I am on Xubuntu too and I have exactly the same problem.  Hopefully someone will fix it soon.

[griff1123]

Cheers user42, have a virtual beer on me.

I was having the same issue on Fedora w/ XFCE.

Your well discovered workaround worked for me as well.

And I do agree with other users, this is a workaround not a solution . . . we are waiting Zoom developers.

[idallen]

The last two zoom upgrades give me a Linux client whose menus don't work.
The menus appear for a fraction of a second and then disappear.
Zoom is unusable.

I had to downgrade to 5.17.5 (2543) to get the menus working again.

I am using Ubuntu 20.04.6 LTS on an HPZ440 workstation.

I boot Ubuntu without the default desktop environment (via systemctl
set-default multi-user.target), then at the console I use "startx"
that brings up Xorg and the no-frills vtwm window manager.

Zoom worked fine up to version 5.17.5 (2543) and hasn't worked since
because of the above menu problem.

[pkeller]

Yes, it sounds like you are having the same problem as user42 and me. I have managed to open a ticket with Zoom about this using my company account, we will see if the Zoom developers respond.

In the meantime if you have set a focus-follows-mouse policy in your desktop settings, you can try to change to a click-to-focus policy to see if that helps as well. In the ticket I opened with Zoom, I wrote:

With a "click to focus" setting the Zoom client behaves correctly, however this is not an acceptable workaround. The Zoom client should be usable with any reasonable desktop configuration.

---

I'll keep this post updated with any progress on the ticket. If anyone else reading this who has a paid-for account is having the same problem, perhaps they could try to take it up with Zoom support as well? That way they know that I am not the only person who is having a problem here.

[devost]

Thanks for this solution. I am using Linux mint and I have the exact same problem. Changing my settings to "click to focus" worked.

[pkeller]

They responded to my ticket, asking for screenshots. Since screenshots can't really illustrate the incorrect behaviour, I gave them a couple of short videos showing the difference between versions 5.17.5 and 5.17.11. Let's see what they get back to me with.

I have no idea if the ticket is visible to anyone other than me, but just in case anyone else can see it the ticket number is TS0858206 

[shadroth]

Thank you very much for following up on this, it has been driving me nuts! I found the issue for me was that I had my focus set at "focus strictly under mouse". If I change to "focus follows mouse" then that works as well as "click to focus".

[GPhL]

Thanks for that. Could you tell us which distro/version of Linux and which desktop you are using?

[shadroth]

I'm using Kubuntu 22.04 LTS on a MSI Stealth GS66.

[JaminCollins]

As others have indicated switching to "click-to-focus" does rectify the issue, but also utter changes how a user interacts with their desktop environment.

An alternative is increasing the time before the focus follow the mouse.  While the popup does still disappear, I've found that increasing the time does give me enough time to make the change I need (audio/video) without altering how I interact with my desktop environment.

[pkeller]

The last that I have heard from Zoom on the progress of my ticket about this issue was on 25 March, telling me that the issue was with their team, and asking me to wait for an update from them. I haven't heard anything more from them since, but I'll post here when I do. I guess that we just have to be patient, and stick with verison 5.17.5 in the meantime.

[diannes]

Same problem here... Debian 12, XFCE4 and focus follows mouse.  Changing to click-to-focus is a non-starter for me; that policy makes the desktop unusable for me.

I've downgraded to 5.17.5 for now

[david101011 · Accepted solution]

I can confirm that the problem DOES NOT EXIST in latest version, 6.0.2.4680.

Looks like it is fixed in this version.  

I am seeing flickering though, so I suspect that the problem might come back.  Looks to me like the menu close functions aren't coded right.  

[pkeller]

Thanks for the heads up, a quick check shows that the issue seems to be fixed in this version for me too. I'll wait until the next time I have a meeting to be certain.

The behaviour of the menus was always a bit strange for me, time and a few more updates will tell if the problem has really been fixed.

[djeverett]

It has returned in the 6.1.x releases.  I've seen it again in 6.1.0.198 and 6.1.1.443.

[pkeller]

Both those releases work fine for me (I'm now using Gnome/Wayland 45.3). Maybe it depends on something like the focus settings again? If you experiment with your desktop settings and see if there are some settings that allow it to work, it would help to narrow down what the problem is.

[djeverett]

As before, the problem only exhibits if you have focus on hover.  With focus on click, the menus work.

[idallen]

I have no problem with menus for Zoom 6.1.1.443 on Linux Ubuntu 20.04.6 LTS using "startx" and the "vtwm" window manager.

[AJungstand]

I've the same problem with version 6.4.13. Both on a desktop (Linux Mint 21.3 with Mate 1.26 desktop and Kernel 6.8.0) as well as on a Laptop (Linux Mint 22.1 with Mate 1.26 desktop and Kernel 6.11.0) the problem is there. 

[zan1]

I had a workaround to double-tap (FINGER TAP, not a mouse click) the buttons, but 6.4.13 has, maddeningly, broken that. I now need to tap many multiples of times to actuate the buttons once.
Now I've noticed that a finger-tap on the laptop's touchpad (which usually acts as a 'click',) does NOT trigger the buttons. If I use my touchpad as a mouse (pressing in the lower-left touchpad corner) a double-click WILL actuate the buttons.

[AJungstand]

Meanwhile I've contacted Zoom support. The answer was to re-install the actual version (6.4.13.). There was no success, the problem is still there. I'll keep you updated.

[AJungstand]

I've tested it with an older version (6.4.0), this version is ok. There is a good description how to find older versions

Exact version numbers could be found on the release notes Page.

[mt61]

Thanks for your report. I have the same problem and it really is a fatal bug which makes the latest Linux versions impossible to use for me. I give online music lessons, and the Audio settings are THE most important for my use.

The latest version that I tried that seems to work for me is 6.4.6.1370. I am using Fedora 42 and installed the rpm version that I was able to download from https://zoom.us/client/6.4.6.1370/zoom_x86_64.rpm  

But the Zoom developers really should fix this properly.

[mt61]

Same problem here (I am on Fedora 42). Latest version I have found with a usable Audio settings window is 6.4.6.1370. I downloaded this one https://zoom.us/client/6.4.6.1370/zoom_x86_64.rpm 

[AJungstand]

For me version 6.4.6 is also ok and works. I've had a look to the release note's page. Version 6.4.6 is the last one before Zoom introduced a set of new and "enhanced features". I'd guess that there was one "enhancement" to much. I'm still in contact with Zoom support, just a few minutes ago I got the reply that the topic will forwarded to the next level of support. I'll keep you updated what happens. 

[AJungstand]

Meanwhile I got a reply from Zoom support. I've been asked to set the system locale to English (normal it's German for me). And it works! This means they found the root cause. Zoom support promised to provide a  permanent fix, which is  planned for deployment later this month.

[mt61]

I can confirm this trick worked for me too using

zoom 6.4.13.2309

Fedora 42

LANG=us_EN.UTF-8

It's a workaround, not a real fix, but at least I can use the latest ZOOM version now, and the developers now have a clue where to find the problem and the fix. That's promising.

[zan1]

Unfortunately doesn't work for me (already set to English US, but I tried English UK just for laughs, no good).
Since this is marked "resolved", in order to get proper attention and help newcomers I started a new issue: https://community.zoom.com/t5/Zoom-Meetings/Bug-Menu-buttons-broken-again-on-Linux-Zoom-version-6-4-...

[FF64]

Same with UBUNTU 24.04 the last update of zoom just kill the interface 

[AJungstand]

Update:
I got the info that a Zoom engineering teem is working on it. The fact that I didn't got an immediate answer like "re-install" or "restart" the computer is good sign for me. I've the impressions that they are really working on it.

[FF64]

with the new version 6.5 it works fine on ubuntu now  

[chuboe]

Posting for reference on PopOs 22.04 (pre cosmic).

I had to do the following to get PopOS to work correctly: using dconf-editor, set the org.gnome.desktop.wm.preferences.auto-rise to true. I did not change any other setting.

After restart, zoom popups worked as expected. Note that I use tiling window management; therefore, I have not witnessed any side-affects of this change.

Thanks to everyone for sharing! Chuck

[zan1]

I tried dconf editor (on Pop!_OS) but it didn't work. However, I just noticed that DOUBLE-clicking the menu buttons does work.

Irritating and glitchy, especially when I am paying for this software.

[mt61]

It seems two differerent issues - they may or may not be related - are mixed up in this thread:

1. Issue with non responding mouseclicks to open menus (Suggested fix: double-click, double-tap, etc.)

2. Opened dialog windows that are unreadable because they are squeezed and can't be resized. (Suggested fix: change LANG to us-EN.utf-8

[AJungstand]

You are probably right. For me it was only the topic No. 2 in your list. This is solved with the new version 6.5.0