What happened to Safari's browser auto-fill shortcut on 1P8?

I've found some additional details:

• Assigning the "browser auto-fill" shortcut in 1Password to another key combination doesn't help.
• If 1Password is already unlocked, then browser auto-fill works as expected. Pressing the key combination for auto-fill in Safari correctly enters in usernames and passwords and auto-submits. However, if 1Password is locked, then pressing the key combination for auto-fill displays the main 1Password window to unlock, and after entering the master password displays Quick Access (with no suggestion to fill for the current website even, it's as if someone pressed the key combination for Quick Access on the desktop). Closing out of Quick Access and pressing the key combination for auto-fill a second time then properly fills credentials and submits as expected.

In 1Password 7, regardless of the lock state, the shortcut key for browser auto-fill would trigger the unlock of 1Password (if required) and automatically fill and submit login information.

How can I make 1Password 8 work in this same way that 1Password 7 did?

Bumping this thread. I can see 1Password team members have been replying to other threads that are newer than this one. It's a little frustrating to have seem to have fallen through the cracks. Can someone from the 1Password team please take a look and provide some suggestions?

Thanks @Jack.P_1P, I'll keep an eye on my inbox.

@ictflyguy unfortunately I have nothing to share. I had a back and forth with support in which they first tried to suggest that this was somehow the expected behaviour of Universal Autofill, then when shown a screen recording of the issue said they couldn't reproduce the issue and to try the latest beta, which I did try but the issue persists there too. They then said they filed an issue with the development team and "please be patient", which was mildly amusing/irritating as they didn't mention that once you upgrade to the beta version you can't easily downgrade back to stable since the database on the beta isn't backwards compatible with stable. For me, moving from stable to beta didn't solve anything but introduced new issues and left me in an annoying spot.

I ended up completely blowing away the 1Password 8 installation and going back to 1Password 7 for the time being. I couldn't keep 8 and just hope that issues get sorted out sooner rather than later. I continued to dig into the issue though and eventually came across this post by a 1Password employee. Most notable is this quote:

Close! Safari is actually the one browser where we're explicitly not reaching out to the browser extension to perform fills right now, instead relying entirely on accessibility-based filling (when using CMD + ). This is due to some challenges we've had getting the Safari extension to quickly and reliably perform actions when requested by the desktop app. We're actively working on this issue and we hope to be able to use the Safari extension to perform fills when using CMD + \ in the future, just like every other browser.

This might explain a lot. It turns out that in 1Password 8, the app-to-browser extension link just doesn't exist for Safari and it relies on Universal Autofill instead (as if Safari was a different non-browser app). This is the only time this limitation appears to be mentioned - other employees answering similar questions act as if this link does exist and should be functional (take a look at this example where an employee replies to that poster's issue suggesting: "It's possible that the delay you're seeing is coming from how the extension and app communicate to fill via the shortcut." - even though this communication does not exist in 1Password 8, as we now know from a developer), it's not mentioned in any release notes despite it being a known issue and a clear limitation of Safari integration. I for one do not think 1Password 8 should have launched with this limitation and should have waited until the underlying issues preventing a full Safari integration were resolved, or at the very least should have appeared in release notes/blog posts as a known limitation so customers could understand the potential consequences of upgrading.

As a multi-year customer of 1Password, I can't help but be disappointed. "Please be patient" is not a great answer when key functionality doesn't work. I can go back to 1Password 7, sure - and I have done that - but AgileBits' commitment to continued support for 1Password 7 is unclear, given that they openly stated that it will receive zero support originally and had to walk back that statement to "important security updates only" when they saw how upset customers were with that. If it were me personally, I'd be fine with taking that risk, but it's my family that this impacts - who took a fair amount of convincing to use a password manager in the first place and were frustrated at the whole concept because 1Password 8 did not work for them. Now I'm stuck with them using a questionably-supported "legacy" version because the "new, in-support" version doesn't work the way it's expected to.

My subscription will be due up near the end of July so we'll see what the state of 1Password 8 is come then. Hopefully these issues are ironed out, otherwise I'll be looking at alternatives to move to. I have no real intention of staying on 1Password 7 long-term.

I agree. Unfortunately it took another customer diving deep into logs to discover that the 1Password app to Safari browser extension doesn't work as advertised and only when presented with evidence does a developer come along and admit that this is the case. I do understand to some degree why they don't necessarily want to be forthcoming with these limitations; the reception of 1Password 8 as a whole doesn't seem to have been great and I would imagine they're not eager to give more reasons to those undecided if they want to stay with 1Password and push them over the fence.

The irony however is not lost on me in that I originally posted this in the Mac section of the forum and it was silently moved to the 1Password in the Browser section, which clearly seems to be the wrong section given what we know now.