Background script import fails in version 3 Safari extension

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.

Post not yet marked as solved Up vote post of timbergski Down vote post of timbergski
2.8k views
Posted by
timbergski
Reply
Add a Comment

Replies

Same issue here - how can this be debugged?

Posted by
Georg-san
Up vote reply of Georg-san Down vote reply of Georg-san
Add a Comment

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";
Posted by
garyseven
Up vote reply of garyseven Down vote reply of garyseven

  • Update. A much better way. I should not have posted a proposed solution so quickly....I had only been developing a web extension for a week at that point ;-( See my next reply.

    —
    garyseven
Add a Comment

The manifest v3 does indeed want a:

"background" : {
 "service_worker" : "background.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.

Posted by
garyseven
Up vote reply of garyseven Down vote reply of garyseven
Add a Comment

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...

Posted by
AntonOfTheWoods
Up vote reply of AntonOfTheWoods Down vote reply of AntonOfTheWoods
Add a Comment