mozilla-vpn-client icon indicating copy to clipboard operation
mozilla-vpn-client copied to clipboard

Published 20 hours ago • verified publisher icon mozilla-mobile

Unable to reopen MozillaVPN after closing it on Linux if there's no system tray

Open dannycolin opened this issue 3 years ago • 4 comments

STR

  1. Open MozillaVPN for the first time
  2. Click on the close button in the titlebar
  3. Open MozillaVPN a second time

System information

OS: Fedora 35 DE: Gnome Shell 42 Mozilla VPN: Latest 2.7.x branch

Bug information

On Ubuntu, there's a system tray icon so when you close MozillaVPN it stays open in the background and can be reopen via the tray icon or launcher.

However on Fedora, there's on system tray since it uses Gnome Shell without any custom tweaks or extensions. That seems to interfere with MozillaVPN because if you close it and try to reopen it via the launcher, it never loads.

Installing Tray Icon Reloaded from extensions.gnome.org (a third-party extension) fixes the issue. This let me think the issue is related to Mozilla VPN or Gnome not knowing the application has been minimized in tray since there's no tray by default. It also happens on my second machine with Qtile (a different window manager) without, of course, a system tray.

┆Issue is synchronized with this Jira Bug

dannycolin avatar Apr 01 '22 12:04 dannycolin

Hey thanks for the bug report, I'm just trying to reproduce this and I don't seem to be having much luck here. Would you be able to provide us with a copy of the VPN logs after it fails to launch? You should be able to locate the log file at $(HOME)/.local/share/mozillavpn.txt That might shed some light on why you are unable to re-launch the VPN client.

When I tried this in my Fedora VM, it is certainly bothersome that there is no system tray icon, but after closing the VPN client, I am able to re-launch it back into the foreground using from the Gnome activities menu.

oskirby avatar Apr 07 '22 19:04 oskirby

Sure. I quickly looked at the log and this lines seems of interest.

[07.04.2022 18:33:59.178] Debug: (linux - LinuxNetworkWatcherWorker) Properties changed for interface org.freedesktop.NetworkManager.Device.Wireless
[07.04.2022 18:33:59.181] Debug: (linux - LinuxNetworkWatcherWorker) Access point did not changed. Ignoring the changes

See full log: https://gist.github.com/dannycolin/745b8af1a45e580080d8e61e55c4b93a

dannycolin avatar Apr 07 '22 22:04 dannycolin

So, examining the logs, it seems that the attempt to re-launch the UI started at time 07.04.2022 18:33:12.001 where we can see log messages such as UI starting and Started QML Debugging server on 0.0.0.0:1234 which indicates that this is a Debug build.

However, with the UI running, the client running in the background, it never should have gotten this far. The mechanism that does this is by checking for a UNIX domain socket at /tmp/mozillavpn.ui.sock and writing a wakeup command into it to bring the existing client process back into the foreground, and then exiting the new client process. This suggests that this mechanism is failing somehow.

After closing the VPN client, could you check if the socket at /tmp/mozillavpn.ui.sock exists. If it does, you should be able to bring it back to the foreground with the command: echo show | nc -U /tmp/mozillavpn.ui.sock. This test should determine if it's a failure of the existing client to wake up, or of the new client to detect the existing process (or both?)

oskirby avatar Apr 12 '22 18:04 oskirby

The file exists and the command does bring MozillaVPN back to the foreground.

dannycolin avatar Apr 13 '22 18:04 dannycolin