Closed JKingZapata closed 10 months ago
➤ Andrea Marchesini commented:
Valentina Virlics are you able to reproduce this issue?
➤ 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.
@JKingZapata can you provide logs?
➤ 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
➤ 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?)
➤ 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.
➤ 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.
➤ 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:
➤ 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.
➤ 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?
➤ 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?
➤ Matt Cleinman commented:
To summarize a couple things:
➤ Andrea Marchesini commented:
Santiago Andrigo we should inform the user when the app is unable to configure the login-item.
➤ 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?
➤ 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.
➤ 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.
➤ 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.
➤ 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?
➤ Andrea Marchesini commented:
Unfortunately the API we use doesn’t expose error messages.
➤ 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?
➤ Andrea Marchesini commented:
Santiago Andrigo basically what you are suggesting:
➤ Santiago Andrigo commented:
Yes. Unless you can think of something better.
➤ 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!
➤ 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?
➤ 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
➤ Valentina Virlics commented:
Confirming this on Mac OS 13 while using latest builds from release branch - 2.17.0 (2.202309180609).
➤ 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.
➤ 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?
➤ 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.
➤ Gela Malek Pour commented:
Related: https://developer.apple.com/documentation/servicemanagement/smappservice ( https://developer.apple.com/documentation/servicemanagement/smappservice|smart-link )
➤ 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.
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
Actual Results
Expected Results
┆Issue is synchronized with this Jira Bug