+1, though Testflight supports MacOS now, it would be better if we can just sign and install Safari webext locally. Safari WebExt is not a typical MacOS app, it is closely coupled with browser. It seems none of the popular test automation framework has the privilege to config the Mac privacy settings and "allow unsigned extension" in Safari developers settings Compared with for Chromium, Firefox, the test automation is straightforward, this limitation brings a lot of difficulties to the e2e testing.

Found the solution, this API will resolve: https://developer.apple.com/documentation/safariservices/sfsafariapplication/2202266-showpreferencesforextension.

Just to be more detailed, when I migrating to WebExt, I didn't remove the AppExt bundle in my app. So the app have both AppExt and WebExt, and WebExt has the SFSafariAppExtensionBundleIdentifiersToReplace key to replace the AppExt. I was hoping the app can be compatible with both Safari 12/13 and Safari 14+. Is this a valid practice? Thank you very much

Thanks bweinstein, that's sounds a plan. Actually, I tried the FileManager.default, if I can copy files across different targets, e.g, copying the AppExt's UserDefaults file my-app-extension.plist to file:///Users/username/Library/Containers/WebExt bundle identifier/Data/Library/Preferences, problem is solved. But seems FileManager.default can only operate file in current process files.

It is related to using shared UserDefaults among different targets. To do that, I need to set both the AppExtension and WebExtension to the same app group. Unfortunately, my AppExtension doesn't have app group before, after I set the AppExtension to an app group ("my-app-extension", same as the suiteName in getting UserDefaults), The AppExtension can't get the previous storages. Looks it is impossible to resolve the issue.

Thanks bweinstein, the feedback is created https://feedbackassistant.apple.com/feedback/8978683

Hi bweinstein, From the MDN, the event will be trigger when installed or upgraded. Yes, I have created the feedback 8695776 - https://feedbackassistant.apple.com/feedback/8695776 Thank you

Hi structankit, Did you figure out the solution? I made a mistake in one of my reply, it is NOT fixed for me on Safari 14610.1.26 either, still need to manually grant.

Thanks timothy, it works!

Update: it seems still need to manually grant the permission when it is first time install. Safari will remember the grant, so it is the only one time config, but according to https://developer.apple.com/documentation/safariservices/safari_web_extensions/managing_safari_web_extension_permissions If the host permission is listed in manifest, seems extension should not ask for grant

Another interesting finding is, seems we can not pass the API as a parameter function apiTest(method){ 	method({}, function(result) { 		console.log('Result', result); 	}); } apiTest(browser.tabs.query); This works in Chrome, but not working in Safari

I updated Safari 14 from Version 14.0 (14610.1.20) to Version 14.0 (14610.1.26), seems this issue is resolved. Thanks

Thanks a lot @timothy for pointing out all these Yes, I added the URL to manifest permission (it seems the wild cards url https://*/ has no effect on unblocking CORS), and the CORS request works fine in the background. Thank you for the help!

Hi @timothy, I re-tested my extension, actually it is my server issue, after I added the following headers in response Access-Control-Allow-Origin: safari-web-extension://<guid> Access-Control-Allow-Headers: <some request header we sent> Safari background page makes the requests successfully. However, this is still something extension developers may concerns about, should Safari check the CORS in the extension background page? I feel that the background page is not a normal webpage, extension developers may make API requests to the servers out of their control, if this CORS limit is applied, then a lot of the background requests will fail because of this web-extension protocol Origin Compared with Chrome and Firefox, these browsers always approve the CORS request even if the origin mismatch. Just would like to know if Apple have any plan remove this CORS limit in background page. Thanks a lot