As with the adoption of MV3 standards among all major browser vendors that allow browser extensions at the client-side, I understand that this is the same with Safari as well, as mentioned here (https://www.wwdcnotes.com/notes/wwdc22/10099/). However, as with Firefox, browsers may choose to adopt them incompletely and with few changes. I had a few questions regarding how Safari views this transition and what would be the next steps from here. Thus, it would be really great if the browser team could provide your insights on any or all of the following points: Would Safari adopt the exact standards proposed by the Chromium ecosystem such as with functionalities like header-based modifications in the coming days.  What would be the general timeline be for this in general?  Does this also translate to the fact that existing standards with MV2 standards would not be allowed to operate any further, as with the timeline with Chromium? Regards

The extension popups don't seem to support the dark mode media query. The only way the query gets detected is when a color-scheme is added: <meta name="color-scheme"content="light dark">

Hi! I'm working on a web extension for Safari and I need to send messages from the containing application to JavaScript. For this I use the method class func dispatchMessage( withName messageName: String, toExtensionWithIdentifier identifier: String, userInfo: [String : Any]? = nil ) async throws of the SFSafariApplication class. If the site is opened in Safari in normal mode, everything works as expected. However, if the site is "docked", the messages are not transmitted to this "Web App".

I've been unable to successfully get a webpage to send a message to a Safari web extension, no matter what I try doing. I've added the following to my manifest.json file, and it's running manifest v3 { "externally_connectable": { "matches": [ "*://mywebsite.com/*", "*://localhost:3000/*" ] } } My web page executes the following code snippet. I've tried this both while running my site locally (on localhost) and pushed to production. let safariExtensionId = "co.companyname.productname.Extension (ABCD1234)" browser.runtime.sendMessage(safariExtensionId, { greeting: "hello"}, function(response) { console.log("Received response from background page"); console.log(response.farewell); } ); In the Safari web extension's background.js file, I've added the following onMessageExternal listener: browser.runtime.onMessageExternal.addListener((message, sender, sendResponse) => { console.log("Received message from the sender."); console.log(message.greeting); sendResponse({ farewell: "Goodbye!" }); }); This is directly copied from the instructions in this WWDC video: https://developer.apple.com/documentation/safariservices/messaging-between-a-webpage-and-your-safari-web-extension It's also extremely difficult to debug what's happening since the extensions service working frequently does not appear in the Web Extension Background Content menu Is there something I'm doing wrong, or a bug I'm not aware of?

Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. As of macOS 15.4 / Safari 18.4 the tab OnAttached and tab onDetached events are no longer received. After some testing we verified that the events were working properly as of macOS 15.3 / Safari 18.3 but appear to have been broken in macOS 15.4. Note a similar issue was reported previously for Safari 17.6 and was fixed in macOS 15.0 (FB14324177). We have made a TestFlight version of our app (Tabby) available to simplify debugging via https://testflight.apple.com/join/Va8Zdv9d. To reproduce the issue: Install the Tabby TestFlight build on macOS 15.4 or 15.4.1 Open Safari, go to Safari settings and select the Extensions tab Enable the Tabby extension and grant permissions to all windows all the time Open a Safari window with at least 3 tabs Note the open window and tabs displayed in Tabby In Safari, perform a tab detach by dragging a tab out of the window Expected behavior Within Safari the detached tab should now be in it’s own window, and via the onDetached event Tabby should update to show the tab in it’s own window AND removed from the original window. Observed Safari fails to send the onDetached event and Tabby will continue to display the detached tab in its original window in addition to the new window. You can also use the repro steps above to observe the onDetached event being received or not by Tabby in the Safari developer console. The same steps but re-attaching the tab to the original window can be used to observe the onAttached event being received or not. We’ve attached two screen recordings to the Feedback ID below, one showing the events working on macOS 15.3, and one showing the events failing to be received on macOS 15.4.1. Note it also fails on macOS 15.4. FEEDBACK ID: FB17367977

Hi! I'm working on a web extension for Safari and I need to send messages from the containing application to JavaScript. For this I use the method class func dispatchMessage( withName messageName: String, toExtensionWithIdentifier identifier: String, userInfo: [String : Any]? = nil ) async throws of the SFSafariApplication class. If the site is opened in Safari in normal mode, everything works as expected. However, if the site is "docked", the messages are not transmitted to this "Web App". Is it possible to somehow link the container application to the docked website so that messages from the application are received by this "Web App"? That you.

We have an existing Safari App Extension distributed outside the App Store (self-distributed). Recently, we converted another browser extension to a Safari Web Extension and used the same bundle ID as the original application to avoid any change on the CX side. After distributing this updated app, we noticed that the Safari extension was disabled on users' machines, and users are now required to manually re-enable it in Safari's preferences. Is this the expected behavior and is there way to avoid this for future updates ?

When our Safari Web Extension makes a api request from its background script (registered via "scripts" in manifest.json, e.g., "background": { "scripts": ["js/background.bundle.js"] }) to our authenticated API endpoint (https://api-domain/user), the Cookie header is not included in the request. This occurs only when the extension is running within a non-default Safari User Profile. This causes our API to treat the user as unauthenticated. The exact same extension code, manifest, and API call work correctly (Cookie header is present and user is authenticated) when the extension is running in the Default Safari User Profile.

updateDynamic rules is blocking ads on my device with iOS 17.4, but on my iOS 18 device the same code is not blocking ads. Is this a known issue?

Hello, According to the documentation: If you provide your extension in macOS and don’t want to use the Mac App Store for distribution, you can sign and notarize your extension’s app with a Developer ID to distribute it outside the Mac App Store. However, I found this to be untrue in practice. Even after signing and notarising the Safari extension correctly, it is not possible to enable it in Safari without turning on "allow unsigned extension". This makes it impossible to distribute your Developer ID–signed and notarized extension outside the Mac App Store. I would like to distribute my web extension directly to employees in my organization using MDM without having each user manually enable "allow unsigned extension" for it to work. Any way to make it work? The documentation is quite confusing in this aspect, it says "Safari only supports signed extensions" but my extension is rejected even if notarised and signed.

使用direct distribution进行分发时，safari web extension 在safari setting 中显示没有权限读取、修改或传输任何网页的内容。 但是我在看公证日志显示插件是正常的公证的 这导致safari extension 无法使用。 公证日志 https://www.coupert.com/img/2025-04-10/notarization-log.json