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.