For this issue I filed a bug report on Feedback Assistant: FB16590857

Please read carefully my post on stackoverflow Also I created a repo on Github to test by yourself the method discussed in my post on Safari (MacOS & iOS newest versions) and on Chromium/Firefox. Happy testing :)

The question is: Is there (or will there soon be) a plan to improve the way Safari updates dynamic rules using the updateDynamicRules DNR API, so as to significantly reduce the current time (6/8 seconds) required to update? Asking is legal, answering is polite

I am well aware that Safari deletes an IDB database after 7 days of inactivity, but this is not the case I am referring to. I am using Safari with the web extension installed and running that interacts with the database. While browsing, I decide to delete Safari's history manually, and what happens? What happens is that not only the history is deleted, but also everything else (database, local storage,.... and the service worker is brutally taken down). But I had only asked to delete the history... BAH. Anyway, I found the solution. And it works on both macOS and iOS, in spite of Safari's nonsense. Thanks for all the countless (= 0) suggestions/information received regarding my problem.

Yes I know, if we don't use a.json and b.json Safari is able to set that one dynamic rule in a few msecs... Bravo! The 60,000 other rules from files are static, and Safari have already loaded, processed and sorted them at start (extension install time). And this happens without any waiting time. In fact the static rules are used correctly by Safari and do their job. Why then when asked to load even 1 dynamic rule does it take a biblical time? Does it stupidly reload everything from the beginning? As you know the use of DNR rules normally involves the use of static and dynamic rules simultaneously and dynamic rules can vary over time (otherwise why call them ‘dynamic’?) and all, I say ALL, existing compatible DNR browsers update them (add/remove via updateDynamicRules api) very quickly (5-7 msecs) except Safari (6-8 seconds). Which is absolutely not acceptable for serious work. Safari's problem, I suppose, is to throw all the rules (static and dynamic) into the same pot without any ‘cooking’ strategy. Everything is fine as long as nothing has to be added or taken out of the pot. But if I want to add even ‘a clove of garlic’, what does the cook (Safari) do? He takes everything out of the pot again, divides it again by ingredients, adds the new ingredient (the garlic) and throws everything back into the pot... this cook doesn't seem so smart to me. By the way... What do you suggest?

My Mac is with the latest version of everything, so YES Also I created a repo on Github to give you the ability to test it by yourself with wathever version of whatever.

same problem here. And as always a solution from Apple will come december 32th next year.

Service workers don't live forever... unless you give them something to do before they are shutted down by design. In the past this was the case for Chromium-based browsers, now also for Safari (and probably also for Firefox). For those who have this kind of problem, I suggest taking a look at (and studying) the post below and the related cited Github repositories (Highlander series), where a fully functional methodology for keeping a service worker active forever is exposed. https://stackoverflow.com/questions/66618136/persistent-service-worker-in-chrome-extension/75082732#75082732

Sadly, initiatorDomains (in iOS version 17beta) is still NOT working, together with modifyHeaders/responseHeaders. Using them will result in totally garbaged web pages. In iOS 17beta is now, instead, supported requestDomains.

In iOS >= 16.4 (and iOS 17 beta) getMatchedRules returns only: request.url, tabId, timeStamp **instead of: ** rule.ruleId, rule.ruleSetId, tabId, timeStamp as in all the OTHER browsers. So it returns something but doesn't return what is expected as specified in the documentation: Fixed result of getMatchedRules() to match other browsers. The declarativeNetRequest API is full of holes, despite Apple's insistence that they work in the documentation. Another example are responseHeaders/modifyHeaders that completely pack a Web site on Safari, while working perfectly on all other browsers.

https://developer.apple.com/documentation/safari-release-notes/safari-16_4-release-notes#Safari-Extensions

The requestDomains issue seems to be just the top of the iceberg... I added here a couple of images describing what happens when the extension runs. The Test extension works perfectly in Chrome and Firefox (with small adjustements). In Safari instead it's simply... confusing. While testing the extension I used some other (more complex and bigger) rulesets to check what happens... my doubt is that Safari "remembers" in some way ALL the rulesets I used and gives back strange behaviours... or maybe I have serious problems in my Mac 16 inch 2019 Intel core i7 with Ventura 13.3.1, Safari 16.4, Xcode 14.3, even if I reinstalled everything yesterday, just to be sure. Attachments: background.js (as txt), manifest.json, a ruleset background.js.txt manifest.json adstest.json