mozilla-mobile / mozilla-vpn-client

A fast, secure and easy to use VPN. Built by the makers of Firefox.
https://vpn.mozilla.org
Other
470 stars 113 forks source link

VPN fails to launch at startup on macOS #5907

Closed JKingZapata closed 10 months ago

JKingZapata commented 1 year ago

Description Having the "connect VPN at startup" setting enabled on 2.13 does not launch the client after a device startup. There is no indication that the client is running in the background. One has to manually search and open the client. When the client is manually opened, it automatically connects to the selected server.

Does it impact functionality or aesthetics? Yes Does this endanger users? What would be compromised and how likely is the threat? No How annoying is this for affected users? (Think about how much 'in the way' this is, relative to what the user is trying to do) Does it degrade the user experience significantly? Users could assume the client is automatically connecting after restarting their device and are unaware that they have to manually launch it. Is it legally sensitive? No

Centrality Secondary user journey

Technical Information Platform: macOS 13.1, 13.2 FX product: Mozilla VPN Version: 2.13 Region/Languages Network type: All

Steps to Reproduce

  1. Install VPN client on Mac
  2. Enable "connect VPN on startup" setting
  3. Restart device

Actual Results

Expected Results

┆Issue is synchronized with this Jira Bug

data-sync-user commented 1 year ago

➤ Andrea Marchesini commented:

Valentina Virlics are you able to reproduce this issue?

data-sync-user commented 1 year ago

➤ Valentina Virlics commented:

Andrea Marchesini Nope, I cannot reproduce this on 2.13 (2.202301272129) while on Ventura 13 (M1).

While having the “start on boot” feature enabled, after device restart, the VPN is automatically turned on.

bakulf commented 1 year ago

@JKingZapata can you provide logs?

data-sync-user commented 1 year ago

➤ Juan Zapata commented:

[^mac logs.txt] [^mozillavpn-2023-2-7.txt]

Andrea Marchesini Sorry I missed adding the logs when filing the bug. Here are a couple of logs we’ve collected

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

From a quick look, it seems like the API we’re currently using on macOS (https://developer.apple.com/documentation/servicemanagement/1501557-smloginitemsetenabled ( https://developer.apple.com/documentation/servicemanagement/1501557-smloginitemsetenabled|smart-link )) has been deprecated after macOS 13, in favor of a new one (https://developer.apple.com/documentation/servicemanagement/smappservice/3945413-register ( https://developer.apple.com/documentation/servicemanagement/smappservice/3945413-register|smart-link )). (2022 WWDC video for anyone curious: https://developers.apple.com/videos/play/wwdc2022/10096/?time=427 ( https://developers.apple.com/videos/play/wwdc2022/10096/?time=427|smart-link ))

Need to test that this fixes it, and if it does we’ll need some forking logic based on what version of macOS the user is running. (And potentially some upgrade logic that allows users to maintain the startup behavior when they upgrade macOS to 13.x or higher?)

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

That might not be it - I can’t replicate this myself when building main.

I do note both these logs are from x86_64 machines, while both myself and Valentina Virlics cannot reproduce it, but we’re on Apple Silicon machines.

Trying on 2.13 release downloaded from internet.

Could it be related to transitioning to new macOS version? (As in, you get this error when moving from old macOS to new one?) A thread to pull on, potentially.

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

Do we know if they turned it off on a system level? Could you ask them to open System Settings, then under General click Login Items - and confirm that the Mozilla VPN switch is turned on? I’m not sure if this is it, but worth checking - especially as I can’t replicate currently.

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

While there may be a bug to fix still (depending on what we hear back from the users), created 2 tickets for future work:

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

Was tested on an Intel-based mac running 13.2.1, and it seemed to work. I’m wondering if the users have it turned off at the system level.

data-sync-user commented 1 year ago

➤ Andrea Marchesini commented:

Santiago Andrigo something missing here is a proper error message. The app knows when the configuration of start on boot fails. We should inform the user instead of silently fail.

Peter Benvenuto can we add a contextual error message?

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

I’m not sure that we need to inform users about what they’ve done, given that removing an item from startup is a fairly conscious action (i.e. not done by mistake). I think we should make sure the checkbox for ‘Autoconnect on startup’ is checked off, for consistency’s sake. Are we doing that?

Having said that, all of the above is predicated on the notion that what caused this issue is the user disabling auto-start somewhere else in the OS. Are we sure that that’s what happened?

At least, though - we seem to have confirmed that this is not easily reproducible - which means that the impact is not as bad as originally suspected. Juan Zapata is this a single case or have you seen others?

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

To summarize a couple things:

data-sync-user commented 1 year ago

➤ Andrea Marchesini commented:

Santiago Andrigo we should inform the user when the app is unable to configure the login-item.

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Thanks Matt. Moving this to Medium given the lack of easy reproducibility.

Andrea Marchesini The way that I’m imagining this is that the user opts-in to ‘autoconnect on startup’ and we ARE able to add this to the startup sequence. If they disable it from some OS menu, then we should read this (requires https://mozilla-hub.atlassian.net/browse/VPN-4308 ( https://mozilla-hub.atlassian.net/browse/VPN-4308|smart-link )) and flip the checkbox off. But presumably, if the user changes their mind and flips it back ON, we are able to set it up again at the startup sequence. In other words, the app is able to configure the login-item, but it’s not able to secure it there if a-posteriori, the user removes it from some other part. This would also apply to Windows FWIW.

Or am I mischaracterizing the interaction here?

data-sync-user commented 1 year ago

➤ Andrea Marchesini commented:

Santiago Andrigo that “ARE” is the problem. It can be that the app is unable to add itself to the startup sequence. In that case there are 2 options:

I think we should inform the user. Using the new iOS/macOS API we know more what the error is.

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Do we know why we fail to register the app on startup?

Do we log / have telemetry about how often this happens?

If we can’t fix it, though, I agree we need messaging AND to uncheck the checkbox.

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

We don’t know why yet - we’re awaiting additional information from the users who reported this ( https://mozilla-hub.atlassian.net/browse/VPN-4126?focusedCommentId=656738 ).

I’m not sure we can log or add telemetry for this general situation (until we know why it’s happening, possibly could log that), as we’d be looking to log “app opened well after system start, and expected app to open on system start” - and we aren’t able to connect our app’s launch time and the system boot time.

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Yes, that kind of telemetry looks fairly weak.

Maybe a good next step is an epic to explore the new macOS APIs that Baku is mentioning. I’m hoping that we get to the point where either (a) it always succeeds, or (b) we know when it hasn’t. Or is there a more promising path?

data-sync-user commented 1 year ago

➤ Andrea Marchesini commented:

Unfortunately the API we use doesn’t expose error messages.

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Andrea Marchesini yes, but the spike would be about researching the new one, in the hopes that it works more often and gives error states when failing.

Or what would you suggest as next step?

data-sync-user commented 1 year ago

➤ Andrea Marchesini commented:

Santiago Andrigo basically what you are suggesting:

  1. switch to the new API asap (the old API must be kept for old macos versions)
  2. telemetry
data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Yes. Unless you can think of something better.

data-sync-user commented 1 year ago

➤ Robert Vass commented:

Hello! I am also able to reproduce this issue while using Mozilla VPN 2.15/2.16, on macOS 13.x.x.. After enabling the “Connect VPN on startup” feature from the client and rebooting my device, the following were observed ("Reopen windows when logging back in" option from OS is unchecked):

Also, I noticed that when checking "Connect VPN on startup”, the application added to "Open at login" (from System Preferences menu) is not recognized and the name that appears is "MozillaVPNLoginItem".

[^mozillavpn.txt]

!Screen Recording 2023-07-10 at 11.50.52.mov|width=3456,height=2234!

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Interesting. Matt Lichtenstein It seems like we WERE able to add something to the startup list, but we maybe added the wrong entry?

data-sync-user commented 1 year ago

➤ Bianca Hidecuti commented:

I am also able to reproduce this issue on Mozilla VPN 2.16/2.17 using MacOS 14.0 Sonoma.

cc: Matt Cleinman

data-sync-user commented 1 year ago

➤ Valentina Virlics commented:

Confirming this on Mac OS 13 while using latest builds from release branch - 2.17.0 (2.202309180609).

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Ok, this is an oldie that keeps on getting reported and we haven’t wrangled this bull by the horns. Upgrading to High priority. At the very least I would like to be convinced again that this is a corner case.

data-sync-user commented 12 months ago

➤ Gela Malek Pour commented:

Valentina Virlics Can you clarify if the VPN is already connected before the client is opened for the first time after a restart? Or does it connect as soon as the client is launched?

data-sync-user commented 12 months ago

➤ Valentina Virlics commented:

Gela Malek Pour I am performing the following steps: check “start on boot“ → turn OFF the VPN → quit the client → restart the macOS device, and:

Also, the Mozilla VPN app is not listed under device settings - “Open at login” section.

data-sync-user commented 10 months ago

➤ Gela Malek Pour commented:

Related: https://developer.apple.com/documentation/servicemanagement/smappservice ( https://developer.apple.com/documentation/servicemanagement/smappservice|smart-link )

data-sync-user commented 10 months ago

➤ Valentina Virlics commented:

Verified as fixed using 2.20.0 (2.202401041847) build on macOS 14 - M1.

While the start on boot option is enabled, VPN is OFF and quit, after a device restart the client is automatically opened and turned on with success.