Background script import fails in version 3 Safari extension

Question

Created Jul ’22

Replies 6

Boosts 6

Views 3.5k

Participants 7

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.

Boost

Answer 1

saroyanm OP

Aug ’22

Yeah, same issue here, currently this is blocking our extension support in Safari. I have noticed similar issue has also been reported in https://developer.apple.com/forums/thread/711341.

0

Answer 2

Glench OP

Sep ’22

I'm also running into this. Any solutions found?

0

Answer 3

Georg-san OP

Nov ’22

Same issue here - how can this be debugged?

0

Answer 4

garyseven OP

Dec ’22

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"::

Screenshot 2022-12-29 at 9.29.34 AM.png

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";

0

Answer 5

garyseven OP

Jan ’23

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.

0

Answer 6

AntonOfTheWoods OP

Apr ’23

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

0