Slow 1Password mini performance on Catalina
I know Catalina is still in beta so this may improve over time, but I just wanted to report slow 1Password mini performance particularly when 1Password is locked. The mini window will take 4-5 seconds to appear. Once I enter my password, it's generally quicker to pull up when filling websites.
1Password Version: 7.3.2.BETA-0
Extension Version: 4.7.5.90
OS Version: macOS 10.15 19A471t
Sync Type: 1Password
Comments
-
Hi @mbesemann!
Thank you for reporting this. Has this started happening with a specific version of 1Password for Mac, or did you start noticing this as soon as you installed the beta of Catalina?
0 -
I’m pretty sure it’s been since I installed Catalina. Unfortunately I’m not running the latest beta either (it won’t show me the update, go figure :P) so it’s possible performance has gotten better in the latest beta.
0 -
@mbesemann: Can you please give the latest 1Password Beta a go and see if that helps? Here are the instructions to switch to the Beta channel ;)
0 -
@mbesemann: Ah, interesting. While I'd doubt that performance would necessarily be linked to that, it may point to a deeper issue as well. Honestly, if it were me, I'd just do a clean install of the latest release if it wasn't even allowing me to update to it. I'm not convinced that will make a difference specifically for 1Password, it may be prudent.
0 -
I am on MacOS Version 10.15 Beta (19A512f) and 1Password 7 Version 7.3.2.BETA-2 (70302002).
My 1Password Mini loads within half a second to a second.0 -
Thank you for sharing this information @Penguinlay!
And welcome to the forum! :)
0 -
@brenty: I just updated to Catalina beta 9 (19A573a) which came out today (unfortunately I'm not able to do a clean install at this time). The issue still seems to be present, there is a slight delay when 1Password is locked, but when it's unlocked performance is snappy. Here is a short video to demonstrate the difference (sorry for the quick cut between the two scenarios):
0 -
Thanks for the video! Indeed, 1Password needs to decrypt some data on the fly when first unlocking, but after that it can be much quicker to open and display information. A lot will depend on the Mac and macOS, but we'll see if there are further optimizations we can make on our end to speed things up over time. Cheers! :)
0 -
@ag_ana, hi thanks for the welcome! Sorry for the late reply.
Three points for me that I noticed.
One is every time Chrome Canary is reinstalled, need to copy the NativeMessagingHosts from Chrome manually for the extension sync to work. It doesn't work automatically in Chrome Canary like in Chrome. I have them installed via Homebrew so sometimes they update in-app but sometimes they do via terminal if I catch them from my automatic update script first.
Second is for both Chrome and Canary:
If I am manually putting in the master password on extension, it takes about one second to two seconds.
But, if the desktop app is already unlocked and the extension is checking it and decrpting, then it takes two to three times longer.Third, after the browser is updated, the auto sync stops working unless master password is entered manually once after the update.
I am currently on:
Version 80.0.3950.0 (Official Build) canary (64-bit) for Chrome Canary
Version 78.0.3904.70 (Official Build) (64-bit) for Chrome
Mac OS Catalina Version 10.15.1 Beta (19B86a)
1.17.2 for 1PasswordX on both Chrome and Canary
1Password 7 Version 7.4.BETA-0 (70400000) 1Password Beta desktop app0 -
every time Chrome Canary is reinstalled
@Penguinlay: What do you mean exactly? Are you having all of Canary's data cleared and then installing a new version?
after the browser is updated, the auto sync stops working unless master password is entered manually once after the update.
Can you elaborate on this?
If I am manually putting in the master password on extension, it takes about one second to two seconds. But, if the desktop app is already unlocked and the extension is checking it and decrpting, then it takes two to three times longer.
That sounds like we're getting back onto the topic of performance of 1Password mini. It's worth noting that the browser should not be involved at all, as that's all handled by the native app. But that does sound like the opposite of what I'd expect, so I'm wondering if you see the same behaviour in Safari and Firefox, and if there are other "customizations" you've "home-brewed" that might be impacting processing and storage performance. Very odd.
0 -
What do you mean exactly? Are you having all of Canary's data cleared and then installing a new version?
Now that I think of it, update is fine with the extension on both Chrome and Chrome Canary. The problem is only when I fresh reinstall them. If I fresh reinstall Chrome, the extension works fine without tinkering with the NativeMessagingHosts file. But, in Chrome Canary's case, I have to copy NativeMessagingHosts file from Chrome to it manually for the extension sync to work properly.
after the browser is updated, the auto sync stops working unless master password is entered manually once after the update.
Say the extension is unlocked on now. It is also on 1Password desktop app since they are in sync. Now, I update the browser from within the browser with their build in update. After the update, the sync no longer works even though the 1Password desktop app is still unlocked. I need to enter the master password once on extension to unlock it.
That sounds like we're getting back onto the topic of performance of 1Password mini. It's worth noting that the browser should not be involved at all, as that's all handled by the native app. But that does sound like the opposite of what I'd expect, so I'm wondering if you see the same behaviour in Safari and Firefox, and if there are other "customizations" you've "home-brewed" that might be impacting processing and storage performance. Very odd.
I don't have any customizations from homebrew. It only handles the version check and update/upgrade. The application binary is as it is out of the box official versions.
Suppose I just restart the computer. Then, 1Password desktop app is locked as expected. Now, I lanuch the browser. The extension is hanging on that loading screen with an option to enter master password. I don't know how long is the hanging period since I didn't wait for it to finish as I know 1Password Desktop is locked so I always enter the master password in this case. After that, it's only about one second till I can use the password.
Now, suppose the 1Password Desktop app is unlocked. Then, after the browser is launched the first time, it took about three seconds till the extension is unlocked.0 -
Now that I think of it, update is fine with the extension on both Chrome and Chrome Canary. The problem is only when I fresh reinstall them. If I fresh reinstall Chrome, the extension works fine without tinkering with the NativeMessagingHosts file. But, in Chrome Canary's case, I have to copy NativeMessagingHosts file from Chrome to it manually for the extension sync to work properly.
@Penguinlay: To be clear, neither 1Password nor any extensions have anything to do with that; that's all just the browser, which we have no control over. But yeah, that's what I would expect with Canary, as it doesn't take care of setting this up for you. Chrome will setup NativeMessagingHosts; Canary will not.
Say the extension is unlocked on now. It is also on 1Password desktop app since they are in sync. Now, I update the browser from within the browser with their build in update. After the update, the sync no longer works even though the 1Password desktop app is still unlocked. I need to enter the master password once on extension to unlock it.
Correct. Browser updates break the connection with extensions until they are complete and the browser is restarted. At that point, because of that, you will need to unlock in the browser again, as that connection was reset completely during the update. It's possible that could change in the future, but only time will tell.
I don't have any customizations from homebrew. It only handles the version check and update/upgrade. The application binary is as it is out of the box official versions. Suppose I just restart the computer. Then, 1Password desktop app is locked as expected. Now, I lanuch the browser. The extension is hanging on that loading screen with an option to enter master password. I don't know how long is the hanging period since I didn't wait for it to finish as I know 1Password Desktop is locked so I always enter the master password in this case. After that, it's only about one second till I can use the password.
Now, suppose the 1Password Desktop app is unlocked. Then, after the browser is launched the first time, it took about three seconds till the extension is unlocked.
Thanks for clarifying. I'm not able to reproduce that, and we've had no other reports, so it does seem like it may be something specific to your setup, but we'll see if we can discover what might cause that.
0 -
Just wanted to provide an update on my situation: I'm still seeing rather poor performance on Catalina (almost unusable) when interacting with the full application (not just the browser extension).
Granted, I am running on a Hackintosh, but I get pretty excellent performance out of all my other apps.
I get the spinning beach ball trying to do almost anything (searches, switching between categories) and I often have to force quit 1Password. Is there a way I can troubleshoot this?
I'm on Catalina 10.15.4 and 1Password 7.5.BETA-0
0 -
I don't think we test 1Password on Hackintosh since it's not a supported configuration, but you could try generating a diagnostics report and check the logs inside it. That is probably the best way to troubleshoot this.
0 -
I just wanted to mention to everyone here that I resolved the issue by uninstalling everything and going back to the production release: https://discussions.agilebits.com/discussion/112554/7-5-beta-0-hangs-constantly-on-2-different-machines-7-4-3-is-fine
I may try installing 7.5 again at some point, just to see if it was perhaps some leftover files that were making 1Password hang.
0 -
I'm also experiencing this with 1Password 7.5.BEATA-0 (2016 Macbook Pro Catalina). Whenever I search, I get a noticeable lag that has never been there before. I guess I'll reinstall 1Password, mini, and plugins when I get a chance.
0 -
Thank you for the update! :+1:
0 -
Just wanted to give an update on this since the production version of 7.5 is now out - I'm still experiencing very slow 1Password mini speed (the time the window takes to first appear after hitting the keyboard shortcut) so I reverted to 7.4.3 (see also https://discussions.agilebits.com/discussion/112554/7-5-beta-0-hangs-constantly-on-2-different-machines-7-4-3-is-fine)
0 -
Do you see the same behavior even on the latest beta (7.6.BETA-0), which we released two days ago?
0 -
Let us know how it goes or if you spot any issues in the beta. Thanks.
0 -
@ag_tommy still seeing performance issues - not sure if it's because I'm running a Hackintosh, or I have a lot of menubar items (I know, it's a problem :blush: )
Here's an interesting screen recording I took - a performance comparison between 1Password on my native Catalina desktop and within a Big Sur VM. There's an overlay to help you see when I hit the keyboard shortcut and you can see the delay between when I hit the keys and when 1Password mini appears. It's basically instant in Big Sur (keys don't get captured in that scenario but you get the idea).
Very strange!
P.S.: On Catalina I'm running 7.6-BETA-4 while the VM is running 7.5.
0 -
The Hackintosh might be a reason for this, yes. Unfortunately I don't have one to test this here :(
0 -
Understood. Unfortunately we're not in a position to troubleshoot issues on Hackintosh systems.
Ben
0 -
@Ben for sure, I totally get it.
For anyone who's curious: I'm not sure yet, but I may have found the culprit: when I boot up my machine with only 1 monitor connected, 1Password is snappy, as soon as i turn on the 2nd monitor, it introduces the delay.
As for why that is, I have absolutely no idea...
0 -
I'm on a MacBook Pro with 4 external displays of various resolutions attached, and I don't see that behavior here. We may have to chalk that up to your config.
0