Since probably the late iOS 17.4.x, 17.5.1 and still now in 17.6 beta our extension has been experiencing issues with the accompanying background script or service worker being permanently killed with no warning after about 30-45 seconds after initial installation (installation, not page load!). In all other browsers (including Safari on MacOS) unloading the service worker is part of the normal lifecycle to save memory and CPU if it is idle. In our extension the service worker is used only during the first 5-10 seconds of every page visit, so we are used to seeing it unload after that and consider this a good thing. However, normally, the service worker is able to wake back up when needed - which is no longer the case in iOS. Once dead, nothing a normal user would do can wake the service worker back up: No events like webNavigation or similar will trigger anymore Any attempt to call sendMessage to it from a content-script also does not wake up the service worker and instead returns undefined to the content script immediately Closing and opening Safari does not start it again The only two things that will give the service worker another 30-40 seconds of life is a reboot of the device or disabling and then re-enabling the extension. During those few second the extension is working perfectly. There are no errors or indications in the logs of what is going on and the extension works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail. It seems like a temporary workaround is to change the manifest to not load the service worker as a service worker by changing "background": { "service_worker": "service.js" } to "background": { "scripts": ["service.js"], "persistent": false } With this change (courtesy of https://forums.developer.apple.com/forums/thread/721222) the service worker is still unloaded but correctly starts up again when needed. Having to make this change does not seem to be consistent with manifest v3 specs though (see this part in Chrome’s migration guide as an example: https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field). According to the release notes of 17.6 beta this bug was supposedly fixed: “Fixed an issue where Safari Web Extension background pages would stop responding after about 30 seconds. (127681420)” However, this bug is not fixed - or at least not entirely fixed. It seems to work better for super simple tests doing nothing but pinging the service worker from the content script, but for the full blown extension there is no difference at all between 17.5.1 and 17.6. Has there been a change in policy about service workers and background scripts for Safari in iOS? Are anyone else seeing this issue? Also seemingly related: https://forums.developer.apple.com/forums/thread/756309 https://forums.developer.apple.com/forums/thread/750330 https://developer.apple.com/forums/thread/757926 https://forums.developer.apple.com/forums/thread/735307

Running extension either on physical device or simulator. When trying to get the console log in Safari > Develop > Device > The main page shows but when launching the popup.js extension it doesn't show in order to see console. Works fine iOS 17* Not available iOS 18 FB14109978

Hello, I've encoutered an issue with Safari App Extensions. My extension prints lots of suspect error logs in the Xcode console and inside Console.app. This happens basically whenever I make any interaction with the App Extension or with Safari. The most common and predictable error log I get is: No current extension context; trying most recent context (Subsystem: com.apple.SafariServices) However, I also sometimes get the following error messages, albeit less frequently, which may be related: No extension context for best match No extension context for remote object Error connecting back to host for remote object: NSCocoaErrorDomain, code: 4099 No known extension contexts for profile 00000000-0000-0000-0000-000000000000 Most recent extension context B7223E12-B563-45E0-97F8-50500BC6B994 does not have connection back to host; trying best match context I haven't been able to find anything about these error logs in Apple documentation or on the Internet, so I did a bit of empirical investigation. I reproduced the bug in the following basic scenario: I've created a new Safari App Extension project in Xcode by going to File > New > Project > Safari Extension App. I've selected "Safari App extension" for the type and "Swift" for the language. The project comes by default with a "SafariExtensionHandler.swift" file, which includes the following code: override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) { validationHandler(true, "") } No issues so far. If I add the following call: override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) { validationHandler(true, "") SFSafariApplication.getActiveWindow { window in // code } } There are still no error messages logged in the Console. However, if I do this instead: override func validateToolbarItem(in window: SFSafariWindow, validationHandler: @escaping ((Bool, String) -> Void)) { validationHandler(true, "") DispatchQueue.main.async { SFSafariApplication.getActiveWindow { window in // code } } } Then my Xcode console starts being spammed with "No current extension context; trying most recent context" error logs. With some more testing, it seems that the most common/predictable situation that causes the error log seems to be when calling any Safari API (e.g. SFSafariApplication.getActiveWindow{} or even SFSafariApplication.setToolbarItemsNeedUpdate()) outside of a direct method call provided by the Safari App Extension API. So making API calls directly from inside validateToolbarItem(in:, validationHandler:) or messageReceived(withName:from:userInfo:) calls is fine, but anything else causes "No extension context" logs. The bug even reproduces if you make a Safari API call directly inside of an @IBAction method call caused by a button click inside the Safari popover of the Safari App Extension. With this being the case, it seems to be impossible to make clean Safari API calls in an asynchronous or proactive way, which is problematic for our app extension use case and which seems to defeat the purpose of some of the API calls like SFSafariApplication.setToolbarItemsNeedUpdate(). Also, this seems to be a new issue. I've tested these scenarios on various macOS versions that I had on hand (specifically, on macOS 10.15 Catalina, macOS 13 Ventura and macOS 14 Sonoma) and the bug seems to reproduce only on macOS 14 Sonoma. The Safari App Extension behaves as expected on previous macOS versions, with no suspect error logs. Does anyone know what this issue is about?

Hello there! At our company we have started to deal with an issue in the latest iOS (17.5) version. It looks like the background script of the extension becomes unresponsive after a short amount of time (around 30 seconds) after performing more than one request to it within a range of 1 - 4 seconds. How it can be tested? Pretty simple example: // content.js const t = 4000 // Using less than 4000ms makes background script unresponsive async function requestNext() { return browser.runtime.sendMessage({ greeting: "getNext" }) } setInterval(async () => { const n = await requestNext() console.log("current is: " + n) }, 4000) // background.js let counter = 0 browser.runtime.onMessage.addListener((request, sender, sendResponse) => { console.log("Received request: ", request); if (request.greeting === "getNext") { counter++ sendResponse(counter); return true } }); Whenever the browser.runtime.sendMessage is executed too fast the background script will stop working. As far as we have been able to check this only can be reproduced after 17.4.1

I want to execute the modifyHeaders method using a Safari extension. However, it doesn't work when I execute it in Safari. It works in Chrome. Why is that? I used this document as reference: Part of manifest.json "declarative_net_request": {         "rule_resources": [{             "id": "ruleset",             "enabled": true,             "path": "rules.json"         }]     },     "host_permissions": [ "<all_urls>" ],     "permissions": [         "declarativeNetRequestWithHostAccess"     ] rules.json [     {       "id": 1,       "priority": 1,       "action": {         "type": "modifyHeaders",         "responseHeaders": [           {             "header": "Content-Disposition",             "operation": "remove"           }         ]       },       "condition": {         "regexFilter": ".*",         "resourceTypes": [           "main_frame",           "sub_frame"         ]       }     } ] [https://developer.apple.com/documentation/safariservices/safari_web_extensions/blocking_content_with_your_safari_web_extension]

I have integrated the Safari Content Blocking extension, and it works perfectly on the first run, effectively blocking content on Safari. However, after re-installing the app, I occasionally encounter the following error, despite the content blocker functioning as expected: "Failed to reload content blocker Error Domain=SFErrorDomain Code=3 "(null)"" What could be causing this intermittent error?

We are trying to implement ad blockers using the Safari web extension, and we are implementing this using the declarativeNetRequest, with a manifest version 2. We have added a json file which contains a rule set for over 22000 URLs, does content blocker have a limit to the number of rules we set in json? Although it does work fine, sometimes we see the behaviour different on simulators and on clearing the cache it works fine is this expected?

Hi, I have built a Safari App Extension for Mac. However, I want to remove the toolbar item from the extension. I have tried the following approach: Remove SFSafariToolbarItem dictionary from Info.plist Remove the toolbar icon pdf from the project Remove validateToolbarItem and popoverViewController from the extension handler. This does not remove the toolbar item. Instead I have a toolbar item that shows my App Icon just greyed out. On clicking that item, it show an option to "Manage Extension". What should I do to remove the toolbar item from my extension?

We had developed an iOS Safari web extension (which uses non-persistent background scripts) that functioned properly until iOS 17.3. However, I've encountered inconsistent behavior on iOS 17.4.1, 17.5, and 17.5.1. Upon further debugging, I noticed that the background scripts often become idle and are unloaded frequently. They are not loaded again even for the registered webNavigation events and only trigger when interacting with the extension popup menu. This is also mentioned here. I had tried this in both manifest versions 2 & 3. I had tried using service_worker for background scripts. But, none of it seems to resolve this issue. Could you please clarify if this is a bug or an intended behavior? Our extension relies on webNavigation events without users having to interact with the popup menu often.

In this version of iOS our web extension is not allowed to run after allowing it run on all sites via clicking the aA icon in safari. Quitting safari makes it work so it is like the permisions are set but the extension code is never injected into the browser, this behaviour has been replicated with multiple different extension form different vendors.

I'm experiencing a Safari Web Extension issue where the non-persistant background script seems to crash after 30 seconds even when the content script is messaging it. Here is a minimal-reproducible example. When running in an emulator, the background script will stay responsive forever. However, when running on a physical device, the background script becomes non-responsive after 30 seconds of activity. It never becomes responsive again until I toggle the extensions enable/disable toggle, after which it stays active for 30 seconds and then crashes again.

I'm working on this Mac Safari extension https://apps.apple.com/app/id6464076425 The installation of the app via Testflight stops without any success (only for me) As well as the installation via AppStore. This happens only to me. I tried it on another computer, and it installed successfully. Here are some videos: This makes the development and release process impossible until I solve this problem. I tried all the methods I could find online, such as: Deleting the currently installed app Restarting Safari Restarting my Mac Is there anything else I can do to fix this problem?

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.

I'm developing an extension on Xcode, trying to test on my iPhone 7 plus. When I connect my iPhone with my Mac that Xcode is running on, and click Run, the app shows up on my iPhone. But when I check Settings > Safari > Extensions, it says "NO EXTENSIONS INSTALLED. Extensions customize the way Safari works. Extensions can change the appearance or behavior of web content, add buttons to Safari, and more." I'm using : Xcode : Version 14.0.1 Mac OS monterey : Version 12.7.5 iPhone 7 plus : Version 15.8.2

I have an extension that opens the start page after installation with the URL: safari-web-extension://my-web-extension-page.html It's not possible on this page to open any link on a new tab if the link has attribute target="_blank" or even with "Command (⌘) + click" combination Are there any restrictions on pages with protocol safari-web-extension://?

Hello, I've test Apple spacial computing since few weeks now. I've hope working on spacial computer will give me more productive. At this time, safari extensions I use (bitwarden) was not available. There is no other web browser available. I've not find how to use xcode in my spacial computer. I've not find any native (not iPad) terminal tool. Mac screen sharing only give me one screen (and I've got 4 in my desk). This screen can be very big but I prefer having 4 little screen better a big one. And screen sharing is not usable using mouse at all. my mouse always disapear from my screen when sharing with my spacial computer. For all theses case, using spacial computing for working is not realist at this time in my specific case. I lost to many time using it instead of using a "real" computer. Hope this message can help you to upgrade software and give me all tools needed to use it to work. Best regards, Julien Boquet

I want to implement in-app purchases for my Mac Safari web extension. I can think of two ways: Draw the payment UI in an extension web page, and send a message to the native extension app to call StoreKit code. Open the container app from an extension web page, where the app draws the payment UI. I couldn't make #1 work with either StoreKit 2, which is async, and context.completeRequest(returningItems:) doesn't want to be called in a Task, saying context is not sendable) or StoreKit 1, where calling context.completeRequest(returningItems:) in paymentQueue(_:updatedTransactions:) for some reason doesn't return a response to the extension's web page. I couldn't make #2 work because I couldn't find a way to open the container app from the web extension. I registered a custom URL for my container app, but context.open that url does nothing. Web extensions that use IAP with #2 are available on the Mac app store, so it must be possible, could anyone shed some light on how to open the container app and pass the purchased info to the extension web page even if the container app is not open? Thanks in advance.

I am re posting this issue, as a solution still hasn't been provided. please see this original feedback ticket for all the details FB13744621 Any solution or workaround would be appreciated. Thanks

Steps to reproduce the problem: Have an extension which has a content_scripts section in its manifest that specifies a content script for some URLs. Open a tab at a URL that the extension should inject a content script in. What is the expected behaviour? The content script should execute on the page, and if you open the Developer Tools and go to the Console tab, then the extension should be listed inside of the "Extension Scripts" dropdown (the dropdown immediately to the right of the "Clear console" button). What went wrong? After prolonged inactivity, sometimes the content script doesn't show up in the Extension Scripts dropdown (which it would if it were executing). There's no evidence in the page's Developer Tools that the extension is active. It doesn't execute at all, there's no messages in the console related to it or its non-execution, and its content scripts don't show up in the Sources tab of Developer Tools. When the issue happens, the extension still shows up in the browser toolbar as an option.. The extension's icon shows up and functions normally. The extension background page is inspectable and seems to be running normally. Refreshing the webpage doesn't fix it. But once we open the ios App it starts working again. Safari version: 74 OS Version: OS X 10.14.5