Safari Extension Error: “Non-persistent background content cannot listen to webRequest events.” after macOS 15.4 / Safari 18.4 Update We’re seeing the following error in the Safari Extensions tab after updating to macOS 15.4 and Safari 18.4: “Non-persistent background content cannot listen to webRequest events.” This error did not appear prior to the update, and we haven’t found any official documentation stating that webRequest API is no longer supported in Safari. In our extension (Manifest V3), we are using the webRequest.onHeadersReceived callback to intercept response headers and read updated cookies. While the functionality itself still works as expected. we’re able to access the response headers and this error is now shown in the Extension settings page. We are not seeing this issue in other browsers (Chrome, Firefox) using the same Manifest V3 setup. Is there any plan to deprecate webRequest support in Manifest V3 for Safari? We’d appreciate any clarification or guidance on how to handle this going forward.

I have a very specific issue that happens only on iOS Simulator version 18.4. It does NOT happen when I run my app on a real iOS 18.4 device through Testflight. My app displays a WebView (courtesy of Capacitor, url scheme capacitor://). Inside that Webview I'm using Firebase JS API (11.2.0) and calling signInWithEmailAndPassword, which works well in all other contexts, i.e. browser, Android webview, iOS webview in all other Simulator versions, and on real devices. Only when running in Simulator 18.4, I get a failed network request: cannot parse response Fetch API cannot load https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?... due to access control checks. Failed to load resource: cannot parse reponse error: FirebaseError: (auth/network-request-failed) Everything is working correctly for both: Capacitor app webview installed on a real 18.4 device with Testflight Safari (non-webview) in the 18.4 Simulator The issue is severe for us, because we are unable to develop our app and test it in the simulator on 18.4 Simulator before pushing it through Testflight internal release. Request headers on the failed request (no response status or headers available). Request Accept: / Content-Type: application/json Origin: capacitor://localhost Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: cross-site User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X) - AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 X-Client-Version: Mobile/JsCore/11.2.0/FirebaseCore-web X-Firebase-Client: (...)

We’re encountering an issue when trying to add non-standard headers to outgoing requests using Declarative Net Request (DNR) rules in our Safari Web Extension. Tested on macOS 15.4 with Safari 18.4. Specifically, when attempting to add a custom header such as "X-Custom-Header" using a DNR rule, the header does not appear in the request. We are able to add standard headers like "Authorization" and "Cookie" to the request successfully using the same method. This behavior suggests that Safari may be filtering or blocking non-standard headers when set via DNR rules, unlike other browsers. In Chrome and Firefox, the same rule adds the "X-Custom-Header" header without any issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

We’re seeing an issue in our Safari Web Extension where not all cookies from the Set-Cookie response header are accessible. We are using macOS 15.4 and Safari 18.4. In the webRequest.onHeadersReceived callback, the Set-Cookie header returned by Safari only includes some of the cookies set by the server. If multiple Set-Cookie headers are present, we seem to receive only a partial list, some cookies are missing entirely. In Chrome and Firefox, the same callback provides all cookies set by the server without issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

When a DNR rule is set for a specific URL and the request receives a server-side redirect (e.g., 302) to a different URL that does not match the urlFilter, the rule still seems to apply to the redirected request. We are using macOS 15.4 and Safari 18.4. For example, consider two sequential calls: call1 and call2. call1 triggers a 302 redirect to call2. A DNR rule is created to add a "Cookie" header to call1 based on its URL. Unexpectedly, the same cookie is also added to call2, even though call2's URL does not match the rule's urlFilter. This results in the Set-Cookie response from call1 being ignored, and call2 receiving the manually set cookie instead—leading to incorrect behavior. This issue doesn't occur in Chrome or Firefox, where the rule is not applied to the redirected request if the URL no longer matches. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

In our web application some functionalities will allow user to upload multiple images (More than 25 images) in a single page It is working find in all OS and browsers except iOS When user try to upload images directly from camera there will be some overlaps, duplication, missing etc. This is happening in both Safari and Chrome, we had a thorough check in our application and found every thing is working fine from our end You can reproduce the issue by creating a web page which accept more than 50 images (we tried the same in ASP MVC Core & PHP) and showing the images in order access the page through your iPhone using Safari or Chrome Try to upload images directly from your camera, try sequential images (Image of a stop watch, or some thing like that) so that you can easily identify the order of files uploaded and check the listing page of uploaded image (Try these steps multiple times) You can find some images are duplicated and some are missing

Safari Version 14.0.1 (16610.2.11.51.8) I am porting a Chrome/Firefox/Edge extension to Safari Web Extension. Mostly, the process was painless, I am, however, seeing quite different behavior in the tab ids generated by Safari compared to Chrome, Firefox, and Edge. My extension has callbacks for each of these browser.webNavigation events: browser.webNavigation.onBeforeNavigate browser.webNavigation.onCommitted browser.webNavigation.onDOMContentLoaded In each of these I rely on the tab id for various future tab targeting operations. When opening a new tab, the details object passed to each of these callbacks has a non-zero tabId on Chrome, Firefox, and Edge. However, in Safari, the tabId is always zero. To debug, I added one more callback: browser.webNavigation.onCompleted At this point Safari finally has a non-zero tabId in the details param. Needless to say this is causing some consternation with achieving the same outcomes as tab tracking on Chrome, Firefox, and Edge. It's like Safari is treating new tabs as "non tabs" until navigation completes. You can even see it when trying to get the tab by tabId=0: browser.tabs.get(tabId) // tabId=0 here 	.then(tab => { 		// tab is undefined 	}); Seems like this might be a bug. I can't imagine why the behavior is so different from other browsers. Any ideas on how to work around?

Hello, I'm not able to get the webauthn attestation statement using the option (attestation.direct) on Safari. The answer I get is a fmt of none and a aaguid of zeros. The same code works on Chrome and I was able to get a none zero aaguid and a packed fmt attestation. Can you explain why this does not work on Safari ? Thank you.

Hi, when I display an HTML page with a on Safari iOS, I get a nice UI. Great! At the first look I see a video frame with an arrow-in-a-circle button in the middle. Very nice. I click on the arrow and I get a fullscreen view while the video begins to play. I watch the video then I pause it then I click on the top-left x button. So I go back to my html page and the video is perfectly there as it was before. But, there is an annoying new detail. The video frame is really dark, it still presents all the controls and a "different" arrow button to play it again. In other words that nice video-frame, that nice picture, is not longer visible on the page. That nice page with nice pictures has now an almost-black rectangle. Too bad. Sure I can click on the video (outside the controls) then the controls and the black overlaying frame disappear. I can see that nice picture again. Finally. Well, but the arrow-in-a-circle button to play the video disappeared. Now the user cannot longer understand that's a video to play. It looks just like any other pictures to admire statically. Is any way to get the previous first look of the video? The one clear, with the current frame and the arrow-in-a-circle look?