1Password 7 no longer distinguishes between Safari and Safari Technology Preview & Other Confusion

xz4gb8

Current Behavior on Mojave:
Clicking on Keyhole will direct 1Password to incorrect Safari instance.
1Password 7 now always directs credential input to the Default Browser choice between Safari and Safari Technology Preview, even making the Default the active window regardless of being invoked by the other Apple browser.

Expected Behavior:
Clicking on Keyhole should direct 1Password to the Safari instance where Keyhole is clicked.
Prior to this latest change, invoking 1P in either of the two Safari browser instances directed the input to the browser where 1P was invoked.

Workaround:
Manual Direction of 1Password must done.
Now one must explicitly switch Default Browser between the two browsers to diagnose different browser behavior as in, for example, testing a bank login.

Consequence:
Life is more complicated.
Since 1Password 7 now manages Safari extensions (as if by magic) this behavior makes testing Safari Technology Preview while retaining mainstream Safari for backups quite difficult to control.

Other Notes:
I conjecture that 1Password 7 is now checking which Safari browser instance is the default and proceeding accordingly, ignoring or unable to determine the invoking program or process.
I have no explanation why Safari has the BETA-0 extension while Safari Technology Preview has the 7.2.1 extension.
I did not experience this behavior in Mojave betas prior to change to automatic installation of Safari 1P extensions.
1P update is set to Beta stream everywhere.
All software updates indicate currency.
On High Sierra 10.13.6, with 1Password 7 7.1.2, extension 4.7.3, Safari and Safari Technology Preview act independently with 1P7.
Firefox is unaffected everywhere.

---

1Password Version: 7.2.2.BETA-0 (70202000)
Extension Version: 7.2.2.BETA-0 and 7.2.1 from 1Password 7
OS Version: 10.14 (18A391)
Sync Type: AgileBits Cloud

rudy

To use the extension with STP, STP must be the default browser. All other default browsers will result in the messages going to default Safari.

xz4gb8

@rudy,

Exactly as I have discovered. And that is a problem for those generous enough to be part of Apple's unpaid test personnel.

Is this due to some limitation in Apple's APIs or is it a deliberate design decision?

Thanks.

rudy

@xz4gb8,

For those curious: https://developer.apple.com/documentation/safariservices/sfsafariapplication/2823941-dispatchmessagewithname?language=objc

Unfortunately not a whole lot of wiggle room there.

rudy

@xz4gb8,

The old Safari extension used WebSockets to connect to 1Password and was entirely javascript/css.

The new Safari App Extension connects to the 1Password Extension Helper over an XPC connection and is a combination of native code, and to a far lesser extent javascript with almost no css. The SAE is detected by a process on the system called pkd which Safari makes use of to find the presence of the extension inside 1Password. the different versions between STP and Safari would indicate to me that either you've got two copies of 1Password installed, or pkd/STP didn't yet detect the change. Sometimes the preferences window doesn't refresh in Safari when the extension has been updated.

When Safari detects the native extension is on the system it will proceed with removing the old Safari extension if its present, making it less messy to migrate from the old to the new.

xz4gb8

@Rudy

Thanks for the link. Quoting apple, "The message is sent to the user's default version of Safari." We will have to just work around this "helpful" change by Apple. I'm certain there is a security-related reason in there somewhere, so I won't complain.

On High Sierra: Only one version of 1Password, so I still can't explain two version of the extension. Both browsers have the Keyhole icon left of the address field. Well, that problem will be ignored when that system is updated to Mojave.

On Mojave: The only difference between Safaris is the position of the Keyhole icon. In Safari Technology Preview it is now in the upper right (as in Firefox) rather then left of the address field.

The good news - on Mojave, the behavior is consistent, repeatable, and in accord with available documentation.

rudy

@x4gb8,

We've filed a radar with them about the API deficiency. When that API was added Safari Tech Preview wasn't yet a thing, so I think the caveat was their way of addressing the shortcoming without having to go through new API or API modification approvals.

I don't think the position of the icon is a cause for concern. On the development team some people ended up with the icon on the left and some on the right in Safari itself. The way to tell the old extension from the new one is going to be that the old one doesn't look like the current menubar icon. You should be able to right click on the toolbar and choose the customize toolbar command to move it wherever you'd like.

Unless you've manually installed 7.2+ on the High Sierra system you'd still be on a pre-Safari App Extension version of 1Password, so that might explain why they've stuck around. But having two present might've been the result of switching from our direct download extension to the Safari Extension Gallery version at some point (it was a required migration because Safari 12 drops support for direct download legacy extensions).

xz4gb8

Well, today I wiped the boot drive on a 10.13.6 system and installed production Mojave. Both Safari and Safari Technology Preview received 7.2.1 from 1Password. I did have to manually enable the extension in Preferences > Extensions.

I'm going to have to get new reading glasses for this small white letters on black scheme!

KevinSayHi

---

macOS: 10.14 (18A391)
1Password: 7.2 (70200017)
Safari Technology Preview: Release 66 (Safari 12.1, WebKit 14607.1.7.2)
Safari: 12.0 (14606.1.36.1.9)
Safari extension version: 7.2 (from 1Password.app)

I just encountered the strange behavior where using the 1Password extension in Safari Technology Preview in any way would launch Safari (details below). Safari/Safari Technology Preview isn't my main browser, I use them very sparingly, so I can't say for sure, but I believe back in macOS High Sierra, the 1Password extension for Safari/Safari Technology Preview was installed as a .safariextz, and there was no such issue.

Take https://discussions.agilebits.com/entry/signin for instance. Open this page in Safari Technology Preview, and use ⌘\ to fill in the credentials. Safari.app would immediately launch in the foreground. One saving grace is that the credentials are actually filled into the Safari Technology Preview page. If we don't try to fill in credentials, but instead use ⌥⌘\ to bring up the search interface — again, Safari.app pops up. Having another app pop up whenever the extension is used is simply a usability nightmare. Hope this is something that could be fixed on the 1Password side, rather than another crazy limitation of Safari.

KevinSayHi

Just realized I haven't updated to 7.2.1. Same issue after the update.

Also, I guess this thread should belong to "Saving and Filling in Browsers"? Sorry for posting under the wrong topic.

rudy

@KevinSayHi,

See my answers in this thread.

KevinSayHi

@rudy Thanks, and sorry about the dupe.

Lars

@KevinSayHi - no worries! Glad rudy was able to shed some light on the situation with 1Password 7 for Mac's App Extension and Safari Technology Preview. :)

mcdado

So, as of today, hitting the 1Password keyboard shortcut in Safari TP without it being the default browser opens standard Safari. There is no workaround in the foreseeable future?

Lars

@mcdado - that's correct, due to changes in Mojave and Safari 12, as rudy elaborated earlier in this thread. Apologies for the inconvenience; this isn't something we can fix in the code, and I'm unaware of any workarounds that wouldn't be more trouble than they're worth.

danimal

Thank you @rudy, and @Lars, for the explanation on this. It's a bummer but it's good to know there's a clear answer and you've done as much as you can on it.

Lars

@danimal - you're quite welcome! Sorry this is no longer as configurable as it used to be.

jladicos

This is a bummer as it means disabling Bumpr to make 1Password work reliably.

Ben

Sorry for the inconvenience @jladicos!

Ben

ryansebiz

Here's to hoping Apple can fix this in your radar.

Lars

@ryansebiz - we'll keep our fingers crossed. :)

xz4gb8

Could you consider using the bundle identifier to distinguish Safari and Safari Technical Preview?

( "com.apple.Safari" versus "com.apple.SafariTechnologyPreview" )

rudy

@xz4gb8,

Unfortunately that's not how the API works. There isn't a way to direct it to a specific version of Safari: https://developer.apple.com/documentation/safariservices/sfsafariapplication/2823941-dispatchmessage

xz4gb8

Thank you. I knew that 'cause you told me earlier in this thread.

I should let late night bright ideas cook overnight, reviewing the context before clicking Post Comment. Mea culpa.

mcdado

What if you create a separate app extension with different signature for the tech preview?
Sorry I don’t know anything about it but looking at the method signature I thought you could have a different identifier

rudy

@mcdado,

That would cause two extensions to show up in all Safaris, and doesn't change the logic on Apple's side that determines which Safari to 'wake up', unfortunately.