Not until Safari supports the Web Extensions API. Please see https://stackoverflow.com/questions/47435082/will-safari-ever-support-webextensions-api

Let's reopen this as Apple just announced that they will support the WebExtension API with the upcoming Safari release. It's unclear if it's only available for the next OS version or for all.

https://hacks.mozilla.org/2020/06/welcoming-safari-to-the-webextensions-community/ - According to this, Mojave, Catalina and Big Sur are the supported macOS versions.

Plus it's confirmed that Native Messaging will be supported:
https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_between_the_app_and_javascript_in_a_safari_web_extension

...but I haven't been able to test it yet because it needs a beta version of Big Sur and XCode both.

@varjolintu Both Xcode 12 and Safari 14 are now available on macOS Catalina.

xcrun safari-web-extension-converter keepassxc-browser
converted the extension into an xcode project with the following warning:

Warning: The following keys in your manifest.json are not supported by your current version of Safari. If these are critical to your extension, you should review your code to see if you need to make changes to support Safari:
	css
	browser_action
	all_frames
	options_ui
	applications
	contextMenus
	storage
	scripts
	commands
	notifications
	webRequest
	default_locale
	tabs
	webNavigation
	nativeMessaging
	clipboardWrite
	version
	version_name
	name
	web_accessible_resources
	activeTab
	run_at
	webRequestBlocking
	js
	matches
	manifest_version
	icons
	description

I can see that some of these might be a problem for normal functioning. Hope you can at least get simple auto fill to work though. All the best.

@vyashole I haven't tried it out yet, but seems strange if nativeMessaging gives a warning because it should be supported.

@varjolintu the warning says it is not supported by the current version of safari i have. Maybe I'm missing something here.

Native messaging is supported according to https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_between_the_app_and_javascript_in_a_safari_web_extension

Anyway it is past midnight where I live. I'll go sleep now. Will check it out tomorrow.

App Name: KeePassXC-Browser
App Bundle Identifier: com.yourCompany.KeePassXC-Browser
Language: Swift
Is this correct? [yes]: 
Warning: The following keys in your manifest.json are not supported by your current version of Safari. If these are critical to your extension, you should review your code to see if you need to make changes to support Safari:
	notifications
	webRequestBlocking
	applications

That's what it's outputting for me with Safari (Version 14.0 (15610.1.28.1.9, 15610)) with Xcode Version 12.0 beta 2 (12A6163b) on 10.15.5.

Lets see how this goes. (Haven't tried the custom browser option yet as Safari is not supported in the current KeePassXC release).

EDIT: I need to inspect the sample code later to see if there's any changes needed for KeePassXC or the proxy:
https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_a_web_extension_s_native_app

See: https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_between_the_app_and_javascript_in_a_safari_web_extension

Safari ignores the application.id parameter and only sends the message to the containing macOS app’s native app extension.

This means the safari extension will have to be bundled with either KeePassXC or a standalone proxy.

See: https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_between_the_app_and_javascript_in_a_safari_web_extension

Safari ignores the application.id parameter and only sends the message to the containing macOS app’s native app extension.

This means the safari extension will have to be bundled with either KeePassXC or a standalone proxy.

True. A proxy would be the correct place for it, and I'm gonna do the implementation soon.

Hi @varjolintu
Have you found time to work on this yet? I'm not asking for an ETA, but just letting you know that I am very interested in this feature, and while I can't be very useful in actual coding, I'll be glad to help out by testing, sharing logs, etc. Let me know in case any help is required.

@vyashole I have problems compiling the code (event the example one, Native Messaging Demo Extension). Even when I already have latest Catalina, XCode 12 and Safari 14, the code gives me Cannot find SFExtensionMessageKey in scope error and I have no idea how to solve it.

EDIT: If I create a new project it works, so gotta look this some more.
EDIT 2: Succeeded finally building it.
EDIT 3: I can already send messages to the extension, but sending from extension to application doesn't work yet.

I've been looking at the possible implementation and it seems the best solution for this is to wrap an own application for macOS that contains the extension + the Safari code. In this way we can provide a new Safari Web Extension version for each release. Otherwise we'd need to release a new KeePassXC version for macOS for each extension update, and that is not gonna work.

They always gotta be special....

They always gotta be special....

Indeed. I almost thought this thing would be easy to do. Basically we have to write an own "proxy" application that works only with Safari.

Basically we have to write an own "proxy" application that works only with Safari.

I am not a developer, but I have reseached this topic a little bit.
How I understand it, the extension needs to be distributed as an app. But the app does not necessarily need to contain any functionality. It can be more ore less an empty shell that just contains the extension.
But it could also be in included in the main Keepassxx App. Of course if you want to be able to release the extension separately I would also go for the empty shell.

I found a guy who has created a Safari extension that just adds a reload button.
He has written about it, maybe that is helpful.
https://hypercritical.co/safari-reload-button/

@rennefJ this is a native messaging problem, not an extension problem. We can deploy an extension without blinking, the problem is the proxy application that supports the native messaging back to KeePassXC seems to have to be deployed WITH the extension. No other browser requires that.

Luckily the XCode project loads the extension source files as references so there's no need to copy files around.

So, basically, the current part that is missing is:

• Listen on the socket for any message from KeePassXC
• If it landed, send a message to the JavaScript code

Does JavaScript allow that? From the docs it looks like it imposes a request/reply schema…

@vit9696 This is used for listening to broadcast messages:
https://github.com/keepassxreboot/keepassxc-browser/blob/develop/keepassxc-browser/background/client.js#L340=

@varjolintu so far I have not seen an ability to send random message from Safari Extension in Swift to Safari Extension in JavaScript. You might have to poll the Swift side for such messages.

Actually not. There is a feature allowing you do this, though it works differently: https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_between_the_app_and_javascript_in_a_safari_web_extension#3600049

vit9696@21b2349 this seems to work for me, but you will have to adapt the message receiving code to handle the fields correctly.

good news, how is going with this feature now?

Is there anything else besides coding that can be helped with/provided for?

looking forward to seeing this!

Just hang on. Like said before, I'll post updated when I have something new.

@varjolintu thanks for all your efforts
Contribution made on open collective

Just hang on. Like said before, I'll post updated when I have something new.

I know it's done when it's done, but did you discover any problems? It seemed like you where making great progress in April or did you just have no time for this project? Again thanks for your effort!

@mietzen Not enough time for everything :) 1.8.x releases took a big effort, along with Manifest V3 changes, Webauthn investigation etc.. I'll get back to this when I know I have a longer time period to focus just on one thing. Thanks!

"Outgoing Network Connections" entitlement needed to be added to the sandbox so Unix Domain sockets can be connected. My old computer didn't have such requirement, so I was stuck for a moment. Also changed the App Group to org.keepassxc.KeePassXC instead of just KeePassXC.

@vit9696 Btw, I tried your socket polling code and it works, but only when you open the popup or somehow else activate the message transfer with the extension. Currently I'm having hard time to figure out where and how to make a passive version of it that always runs in the background. Any ideas?

I do not think this is easily doable, as in my understanding the extensions are not run in the background. However, it can be just my ignorance of how web extensions work.

@vit9696 Btw, I tried your socket polling code and it works, but only when you open the popup or somehow else activate the message transfer with the extension. Currently I'm having hard time to figure out where and how to make a passive version of it that always runs in the background. Any ideas?

Hey there, I am just butting in real quick and maybe you know all of this already but here goes.

With browser extensions there are 3 scripts that can run:

• Content scripts, i.e. a script that is injected on the webpage and will only run on pages specified in the manifest.
• Popup scripts, i.e. the scripts that you can use in the popup's page of the extension.
• Background scripts, as the name suggests those scripts run in the background.

And all of those scripts can communicate together by using the message API. From the last few messages of the discussion my guess is that you're searching for those background scripts. However there has been a change since manifest v3 which make background scripts less powerful: they can't be persistent anymore... But there is something else that could be useful: service workers. Those work as persistent background scripts. Here are some links you may find useful: on background scripts, on service workers and some apple doc.

I don't know what you have on your mind for this extension. But I could see things working with only a non-persistent background script. I hope that was at least a little bit useful :)

Good luck !

@gencys Thanks. Gotta check if using V3 with a service worker could solve my problem. Luckily there's already a PR for Manifest V3 so I can just copy that one to the Safari extension.

So, how is it going? Can we maybe help with anything?

So I came across this developer tool, for safari web extensions, that enables the conversion of chromium extensions, to safari ones. It requires xCode developer tools to be installed, after which we can run the following command to convert it:
xcrun safari-web-extension-converter ./downloads/keepassxc-browser

Any news? Can I help testing? I want to kick my 1Password... :-)

@varjolintu Is this still being worked on? I may get time to look into it, I have worked on Safari extensions before.. Is #1035 up to date?

@davidkessler-ch I have hit a dead end, and don't know how to continue.

Hi, what dead end did you hit?

Hi, what dead end did you hit?

The background script that listens to socket messages is only active when doing something. It's not working as a passive script.

If I understand the protocol (https://github.com/keepassxreboot/keepassxc-browser/blob/develop/keepassxc-protocol.md) correctly, it is only relevant for database-locked and database-unlocked signals. Are these absolutely required, or could'n they be replaced with some sort of status polling or on-demand calls in case of locked database ?

If I understand the protocol (https://github.com/keepassxreboot/keepassxc-browser/blob/develop/keepassxc-protocol.md) correctly, it is only relevant for database-locked and database-unlocked signals. Are these absolutely required, or could'n they be replaced with some sort of status polling or on-demand calls in case of locked database ?

Those signals are also sent when switching to another database. Maybe when Protocol V2 is implemented, these kind of things are no longer relevant. It might be that a polling function is needed. Gotta experiment some.

is there something I can do to help with this issue? I have a MacBook and Xcode and know how to code

I strongly vote for this feature :) The feature is opened for 6 years…

Using @varjolintu's great work as a launchpad; I will attempt to add support for safari on MacOS in #2295.
Let me know if anyone is still interested or could assist.

I am interested in helping. I have recently been experimenting with porting other, less complex WebExtensions to Safari and would like to see this one ported next. What is the current status of it and what still needs to be worked on? Do you have a GitHub Project or Issue tracking the list of to-do items?

@penguin359 #1035 The status is currently stalled, because I haven't had time to look at this any further.