Can't join meeting from link if Zoom already running

[takluyver]

One thing that I didn't include in my brief tests before #443 was merged: joining a Zoom meeting from a link. With Zoom 5.17.5.2543, this seems to be broken if the Zoom client is already running - the 'launch meeting' page opens in Firefox, but Zoom doesn't do anything, and clicking the 'Launch Meeting' button on the page also has no effect.

I can work around it by quitting Zoom (so the tray icon is gone) and then opening the page or clicking the button again.

I'm looking for clues on what's going wrong.

[muelli]

thanks for reporting the issue and providing a work around.

Do you happen to know whether this is also a problem for the non-flatpaked version?

[takluyver]

I don't know at present. It's an obvious thing to try, but I'm also not entirely sure how they interact if both apps are there claiming to handle zoommtg:// URLs. And I need to use Zoom today, which puts a limit on my experimentation. :wink:

[jmcfarlane]

Am seeing the same (fc39)

[takluyver]

One small clue I've found: launching Zoom a second time, as a link in the browser does, the new process (actually a handful of processes) hangs around invisibly - it's not starting and immediately exiting, as I had first assumed. But I don't really know where that gets us.

I've tried launching Zoom under strace, but that produced so much information I couldn't find any particular clues. I might try it again some time when I have more time to dig in.

I know quite a few programs, like browsers, check when starting up if another instance is running, and if so, send any command line arguments over to the existing instance before exiting. E.g. Firefox does this over D-Bus. I assume Zoom is doing something similar, but I don't know precisely how. Does anyone have ideas how it might have implemented this? Or does Flatpak manage this somehow? :confused:

[ettancos]

Hm, I thought I managed, but false alarm, none of the xdg-open works when zoom has started most annoying is that I couldn't get the authenticated SSO link to do anything neither from firefox nor from terminal with xdg-open. Not even if I close zoom.

[ghost]

I'm having the same issue on Fedora39. I also tried the .tar.xz but the issue persisted.

[takluyver]

Thanks for testing that. That suggests that it's an issue with Zoom as a whole rather than the Flatpak packaging. If that is the case, the only thing I know of to do is post on the Zoom community forums about the issue.

[takluyver]

I've just tested with the RPM version from Zoom's download page, and it does work for me - I can use a link to join a meeting when Zoom is already running.

Using strace on that, I can see it's using a socket /tmp/qtsingleapp-zoom-3e8, and an associated lock file, to communicate from the new instance to the existing one. Googling points to the QtSingleApp library. I think that should work inside Flatpak, but it's not even trying to create the socket. :confused: Edit: it is creating the socket in /run/flatpak/app/us.zoom.Zoom, and sometimes it seems to work, other times not.

[takluyver]

I now seem to have it in a state where flatpak run us.zoom.Zoom zoommtg://... gets stuck, but starting a shell with flatpak run --command=bash us.zoom.Zoom and then launching zoom zoommtg://... in there works as expected. I don't know how those are different.

(I tried deleting my ~/.zoom and ~/.var/app/us.zoom.Zoom folders, to reset zoom as if I was installing it on a new machine. That seemed to solve the problem for a minute, but then it happened again.)

[ettancos]

Update: I might have done something wrong, I repeated the tests on 5.17.1.1840 from the "tar.xz" without successfully opening the link while using flatpak on that version i can open links left and right

Thanks for those findings @takluyver I suspect they changed some internals that broke this version, I ran strace as well on the sso link, open message goes through, same as for you

just using the tar.xz download

second zoom xdg-open zoommtg://...

connect(51, {sa_family=AF_UNIX, sun_path="/tmp/qtsingleapp-zoom-35cc0e"}, 110) = 0
getsockname(51, {sa_family=AF_UNIX}, [28 => 2]) = 0
getpeername(51, {sa_family=AF_UNIX}, [2 => 31]) = 0
(...)
write(51, "\0\0\3\246@@u zoommtg://XXX.zoom.u"..., 938) = 938
write(12, "\1\0\0\0\0\0\0\0", 8)        = 8
(...)
read(51, "ack", 3)                      = 3
(...)
write(2, "Exit zoom as another zoom instan"..., 47Exit zoom as another zoom instance is running!

first zoom that was open shows that it receives the parameter and acks it, but then nothing happens, nothing breaks

accept4(57, {sa_family=AF_UNIX}, [110 => 2], SOCK_CLOEXEC) = 127
getsockname(127, {sa_family=AF_UNIX, sun_path="/tmp/qtsingleapp-zoom-35cc"}, [28 => 31]) = 0
(...)
read(127, "\0\0\3\246@@u zoommtg://XXX.zoom.u"..., 938) = 938
write(16, "\1\0\0\0\0\0\0\0", 8)        = 8
(...)
write(127, "ack", 3)                    = 3
write(16, "\1\0\0\0\0\0\0\0", 8)        = 8
(...)
close(127)                              = 0

[maufl]

I had the same problem, downgrading to the previous commit fixed it! sudo flatpak update --commit=04aaf2b043d0887115d5954ca5af88146d48a512021a0770e95b5cff5f7d00e9 us.zoom.Zoom

[takluyver]

@ettancos the @@u being sent & received in your strace looks suspicious. That's a marker for flatpak run - it treats arguments between @@u and @@ markers as URLs, but AFAIK the target program shouldn't see the markers. I'm not sure where they're coming from if you're using the .tar.xz download, but I assume they'd mess things up if Zoom does get those.

Looking back at my own strace logs, I spotted there seem to be two singleton mechanisms at play: the qtsingleapp socket already mentioned, and a Chromium SingletonSocket which is created under ~/.zoom/data/cefcache.

I haven't worked out how these two fit together, but it looks like if Zoom sends the command-line arguments over the qtsingleapp socket, it works as expected, but if it sends them over the SingletonSocket socket, it doesn't. :confused:

[heyakyra]

Is there no known workaround on an up-to-date flatpak install of Zoom? Am completely unable to log in still, at least on Fedora 39 and 49, Firefox flatpak and Chrome .rpm, but if I can get to a URL like https://[company-subdomain].zoom.us/saml/mobile_success?token=[token string], then could that be manually translated into some zoommtg:// URL to open?

[takluyver]

There seem to be multiple, possibly related issues. This thread is about joining meetings from links in the browser, for which the workaround seems to be to quit Zoom first and then open the link in the browser - it works as long as Zoom isn't already running.

If you're having issues logging in, look at e.g. #446 or #451.

I briefly looked into how the zoommtg:// link is generated, but it's undocumented (probably deliberately) and the Javascript that does it is obfuscated. Whatever broke opening links seemed to come later, after the zoommtg:// URL got to the operating system, so I didn't pursue digging into that.

[takluyver]

I think I've figured out what's going on. This is educated guesswork, but...

I mentioned before that there are two 'singleton' mechanisms at play: Chromium's SingletonSocket & a Qt-based qsingleapp, both working with Unix sockets. I think the Qt one is the one that actually works - the Chromium one is not normally in use, and doesn't work if you try to use it.

The way that Zoom uses Chromium, it looks for the SingletonSocket in a folder like ~/.zoom/data/cefcache/$PID/SingletonSocket. Without Flatpak, each running process has a unique PID, and therefore will create its own SingletonSocket, effectively bypassing this singleton mechanism entirely. Then a later piece of the code uses the qtsingleapp mechanism instead.

But Flatpak puts Zoom in a PID namespace, so each time you launch Zoom it sees its own PID as a consistent small number (it seems to get 4 on my system). So it doesn't use a unique directory for SingletonSocket, but instead it sees the SingletonSocket from the previous process and writes a message to it - which doesn't actually work, but diverts it from using the qtsingleapp mechanism that does work.

Using flatpak run --command=bash us.zoom.Zoom and launching Zoom from 'inside' the sandbox appears to work because bash takes up an extra PID, so Zoom gets a different PID from when you run it without bash, and therefore doesn't see the socket.

If I'm right about this, I think it should be possible to work around it by removing the symlinked sockets before launching Zoom.

[takluyver]

456 seems to work around this issue for me, but it would be good if other people can test it too. You can install the test version with:

flatpak install --user https://dl.flathub.org/build-repo/94766/us.zoom.Zoom.flatpakref

[fhausmann]

456 seems to work around this issue for me, but it would be good if other people can test it too. You can install the test version with:

flatpak install --user https://dl.flathub.org/build-repo/94766/us.zoom.Zoom.flatpakref

Nice, this fixes the issue for me. Thank you!