I have a working Chrome extension using manifest version 3, and I am following the
porting instructions
to turn it into a Safari extension on MacOS (Monterey) - using xcrun from the Xcode toolset. I have Safari v. 15.5.
There are two problems. First, the
documentation
says "Safari 15.4 and later supports manifest versions 2 and 3". So how come xcrun complains about all of the following keys:
manifest_version, icons, description, version, js, matches, service_worker, type, action, tabs, activeTab, storage, alarms, webNavigation, web_accessible_resources, name, css?
At least some of those are basic to v3 manifests.
Second, when I try to install it in Safari (it builds OK under Xcode despite the above "problem") I get an error. In my background (service worker) script I call
self.importScripts("Platform.js");
which should load said JavaScript file. It's in the same folder as the script that calls it.
This works in Chrome but fails in Safari with the error:
Failed to load resource: unsupported URL safari-web-extension://FE580C4D-9931-4639-ABF9-...../Platform.js
I tried changing that dynamic import to a static import:
import Platform from "./Platform.mjs";
(After converting Platform.js to a module Platform.mjs.) This also works on chrome but now my converted extension for Safari won't even load. I get:
The service_worker script failed to load due to an error.
But I can find no way of determining what that error is (there is no information in the service worker console).
I would appreciate help with either or both of these problems. Perhaps they are connected and there is something missing/wrong about my version 3 manifest - even though Chrome is happy with it.
Had the same or similar issue with manifest v3 and safari 16.1. First, be sure that all the code (.js, .html, .css) are included in the build for code signing on "Build Phases"::
Next, I was trying to use module support. In the manifest.json, i removed the :
"background": {
"service_worker": "background.js",
"type" : "module"
and replaced it with:
"background": {
"page" : "background.html"
the background.html then is a simple:
<script type="module" src="background.js"></script>
the background.js then uses an import on the first line as:
import * as common from "./common.js";
On Safari, I don't see support for "type" : "module", so, a better approach to maintain module support is to use a bundler like esbuild to generate the background.js from a collection of source files like background_base.js, common.js, etc :
./node_modules/.bin/esbuild background_base.js --bundle --outfile=background.js
This allows one to keep module support, for say testing, while producing a single background.js that web extensions appear to cooperate better with. No need for a legacy like background.html with script hack. Javascript import works for test environments and allows one to incorporate various libraries easily. I've replace all my content.js, popup.js and similar with the same pattern. In my environment, I use WebStorm to do the majority of editing (working with modules) and let XCode to do the final build and packaging after the esbuild scripts run. This also simplifies the manifest.json and the number of files I have to keep track of in XCode.
This is finally fixed! https://webkit.org/blog/13966/webkit-features-in-safari-16-4/#safari-web-extensions
And I even tested, and it even works :). I was very much not looking forward to any of these hacks (using "scripts" instead of "service_worker", and no type="module", etc) after starting to migrate my extension from Chrome and it turns out (almost) all of the bugs I was facing have been fixed in 16.4! Note to self - make sure your system is up-to-date before starting in-depth debugging...
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the
Apple Developer Forums Participation Agreement.
