In a project to create a web extension for Safari, using scripting.registerContentScript() API to inject a bunch of scripts into web pages, I needed to manage a dynamic whitelist (i.e., web pages where the scripts should not be injected). Fortunately, scripting.registerContentScripts() gives you the option of defining a list of web pages to be considered as a whitelist, using the excludeMatches parameter in the directive, to represent an array of pages where the script should not be injected. Here just a sample of what I mean: const matches = ['*://*/*']; const excludeMatches = ['*://*.example.com/*']; const directive = { id: 'injected-jstest', js: ['injectedscript.js'], matches: matches, excludeMatches: excludeMatches, persistAcrossSessions: false, runAt: 'document_start' }; await browser.scripting.registerContentScripts([directive]) .catch(reason => { console.log("[SW] >>> inject script error:",reason); }); Of course, the whitelist (the excludeMatches array) is not static, but varies over time according to the needs of the moment. Everything works perfectly in Chromium browsers (Chrome, Edge, ...) and Firefox, but fails miserably in Safari. In fact, Safari seems to completely ignore the excludeMatches parameter and injects the script even where it should not. Has anyone had the same problem and solved it somehow? NOTE : To test the correctness and capabilities of the API in each browser, I created a simple repository on Github with the extension code for Chromium, Firefox and Safari (XCode project).

My Safari Web Extension uses a service worker and an IndexedDB database (IDB). For what hidden reason or perverse logic when deleting the Safari history all service workers are brutally shutted down and the database emptied of all its contents? And I heard about local storage too... It happens all the time in Safari macOS and iOS. Safari is the only browser in the world that takes the liberty of deleting what it shouldn't. Good Job indeed.

I created a Xcode project to test the DNR updateDynamicRules API performances on Safari (MacOS). https://github.com/radiolondra/TestUpdateDynamicRules Following the instructions in the README file, it's possible to test the extension on Chromium and Firefox browsers (on Windows). The project uses 2 json files containing static rules, enabled by default in the manifest file. These static rules are automatically installed in the browser when the extension is installed. Using the extension popup it is possible to add/remove just one very simple dynamic rule in the browser, a rule that acts on a predefined test domain (https://iana.org). What we want to measure is the time it takes for each browser to add/remove that one dynamic rule. The results for Safari are unacceptable to say the least: Safari: from 6000 to 8000 MILLISECONDS (6/8 seconds!) <<<<<<<<< Chrome: from 5 to 6 MILLISECONDS Firefox: from 5 to 7 MILLISECONDS Notice the time needed by Safari... It would be a good idea to take a look at this monstrosity. Thanks.

Safari extension MV3, MacBook Pro with Ventura 13.3.1, Safari 16.4 and Xcode 14.3 Although the “webkit features in Safari 16.4” claims to support requestDomains condition, any attempt to load a ruleset containing that condition fails. The extension’s manifest declares the permissions and the ruleset to use: "permissions": [ "declarativeNetRequestWithHostAccess", "declarativeNetRequestFeedback" ], "declarative_net_request": { "rule_resources": [ { "id": "ADS", "enabled": false, "path": "rules/adstest.json" } ] } This is the ruleset used for tests: [ { "id": 1, "priority": 1, "action": { "type": "block" }, "condition": { "requestDomains": ["testpages.kzar.co.uk"] } } ] The ruleset is enabled by the service worker with this function: function EnableDNRRules() { return new Promise( (resolve, reject) => { browser.declarativeNetRequest.updateEnabledRulesets( { enableRulesetIds: [ 'ADS' ] }, () => { console.log("LAST ERROR",browser.runtime.lastError) resolve(true); console.log("dNR rules enabled"); }); }); } The result in last error is: “Failed to apply rules” and rule is not used at all. If I enable the ruleset directly in manifest, and not using the function to load the ruleset, the rule is simply not applied (so not loaded at all). In Chrome and Firefox the same code/ruleset works fine, but not in Safari 16.4, although the docs say it works. Using different condition (e.g. urlFilter) works fine in Safari too. The expected behavior is to have requestDomains working too, as per 16.4 documentation.