I have an app which has at least two extensions: A Content Blocker extension with a request handler that returns an appropriate NSExtensionItem as part of beginRequest. A different file URL is returned depending upon if the content blocking is on or off by a user setting A Safari Web Extension that includes a toolbar button and popover that enables users to enable or disable the ad blocking of the content blocker extension All three targets (App, Content Blocker appex and Web Extension appex) use an App Group default to read and set the on or off status of the content blocking. When the user changes the content blocking status, the app group default is updated and SFContentBlockerManager.reloadContentBlocker(...) is called. The Content Blocker extension reads the default and then returns the appropriate file URL. The issue is, I have noticed that whenever SFContentBlockerManager.reloadContentBlocker(...) is called from the app, Safari always applies the correct rules from the returned file URL. However sometimes when SFContentBlockerManager.reloadContentBlocker(...) is called from the Safari Web Extension using native messaging, Safari does NOT apply the correct rules from the returned file URL. Using logging I have confirmed that the Content Blocker extension always returns the appropriate file URL irrespective if called as a result of the app or the web extension. Despite this, Safari does not seem to always apply the returned file URL rules when it is called from the Safari Web Extension appex. In these cases, quitting Safari and relaunching it seems to make it apply the rules correctly (obviously this is applying it due to its launch state, not due to the Web extension appex asking it to do so at that point). All targets have access to the App Group location where the active content blocking file URL belongs and the inactive content blocking file URL is within the Safari content blocker target as a resource. I don't think this is a memory status issue as I cannot see the Content Blocker extension being killed when it returns complex rules --- the fact it always works when called via the app also seems to rule this possibility out. This brings up a number of questions: Is calling SFContentBlockerManager.reloadContentBlocker(...) from a different appex, of the same app target and app group supported? (it seems to work sometimes and did work in previous versions of the app). Is there an issue that the Content Blocker extension sometimes returns a file URL that perhaps the calling Web Extension appex may not have access to (even though Safari should via the Content Blocker extension)? Any other ideas of why this may not be working correctly? Has anyone else experienced this? It seems to happen on both iOS and macOS Safari using the same codebase.

The order nor -webkit-order properties of a child element of a flex parent dosen't work in Safari 18.3. Works correctly in FireFox and Chrome.

We use a direct link mechanism in our app that attempts to open the app if it's already installed; otherwise, it redirects the user to the App Store. However, when the app is not installed, Safari displays an alert saying: "Safari cannot open the page because the address is invalid." This popup appears to be caused by attempting to open a custom URL scheme that doesn't resolve. what is the recommendation from apple to have a smooth transition to our mobile App Here’s a sample link we’re using: https://new.oneclear.com/Asset/fe5f7fb6-205a-40f8-9efe-71678361aa2c?t=NTA0NQ==

Hi! I'm trying to implement ASWebAuthenticationSession to log in to my app via the web app backend. However, I'm a bit confused about the cookies that this has access to. When I set prefersEphemeralWebBrowserSession=false it does not seem to use the cookies from Safari. Or at least, I'm logged into my web app in Safari, but when I use ASWebAuthenticationSession I still have to log in again. Does it not share session cookies with Safari? I did notice that if I don't use an ephemeral session, once I log out and try to log back in my app does automatically log me in but that's actually unhelpful in my opinion because now I have no way to clear that session because it only lives in the ASWebAuthenticationSession context. If that's the case I may as well use the ephemeral session then because it seems to have only drawbacks.

Hi all, I'm developing an application that uses WKWebView to display a web application which I augment with iOS native utilities such as Speech to Text and IAP. The application also uses Service workers, so we define AppBound Domains in the info.plist file. Everything works for this, but when we deploy on a device the application will crash and say we need these entitlements com.apple.developer.web-browser-engine.networking, com.apple.developer.web-browser-engine.rendering, com.apple.developer.web-browser-engine.webcontent, com.apple.runningboard.assertions.webkit From what I can see, we do need all of them. However Apple suggest submitting a request to be an Altnerative Browser (https://developer.apple.com/support/alternative-browser-engines) This is not appropriate for the application in my view since one requirement of being an alternative browser is that you don't modify the resources on the web site - we of course do since we inject javascript in order to bridge between iOS and the contents of the webview. How are people navigating this issue? I assumed it would be common given the use of Tauri etc. to build similar types of applications, but I don't see much about it. Thank you!

I am encountering an issue where we are unable to run or launch Safari Driver in our automation tests using macOS. When attempting to run safaridriver -p 8888 from the terminal, we receive the following error message: ERROR: safaridriver could not launch because it is not configured correctly or you need to authenticate. Re-run safaridriver(1) and pass the '--enable' flag to configure and/or authenticate. For more information, consult the safaridriver(1) man page. Despite running sudo safaridriver --enable as an administrator (even as root), the issue persists. I’ve searched through various online forums and GitHub repositories but couldn’t find a working solution. Some references are: Apple Developer Forum Thread: https://forums.developer.apple.com/forums/thread/762321 GitHub Issue: https://github.com/SeleniumHQ/selenium/issues/11381

iOS18的app中加载了自己开发的H5页面，H5页面有个input输入框，每次输入框聚焦的时候，都会弹出键盘滑行键入的提示：“滑动手指将字母拼成词以快速键入”，应该怎么修改，达到不每次都弹出这个提示呢

Hello all, I'm building a web application in ASP.NET MVC (.NET Framework 4.7.2), from this web app I need to send push notifications to users. For the ones who are logged in with windows/android, everything works as expected, but I can't manage to get it work on the apple side. If I use the same methods to subscribe to push notifications, it shows me the popup that asks the user to enable push notifications, and then I get an endpoint like this: https://web.push.apple.com/QKC1Muic0H7... It doesn't work using this (taking the part after https://web.push.apple.com/), I keep getting "Bad device token" (trying to send the notification via APNS). Then I found out that there is another method to register the device from the frontend, and this one should give me the real device token: window.safari.pushNotification.requestPermission But this one doesn't show me the popup, it gives me "denied" without a reason. I'm trying to a test application which is here https://pwa.vctplanner.it, the web push id is web.it.vctplanner, I created a push package downloadable from POST https://pwa.vctplanner.it/api/v2/PushPackages/web.it.vctplanner, and the code from the frontend is this: function registerSafariPush() { // Controlla se Safari Push Notifications è disponibile if (!('safari' in window) || !('pushNotification' in window.safari)) { console.log("Safari Push Notifications non supportate su questo browser."); return; } // Il tuo Website Push ID registrato su Apple Developer var websitePushId = "web.it.vctplanner"; // Controlla lo stato della permission var permissionData = window.safari.pushNotification.permission(websitePushId); switch (permissionData.permission) { case 'default': // L'utente non ha ancora deciso window.safari.pushNotification.requestPermission( 'https://pwa.vctplanner.it', // URL del server che serve il Push Package websitePushId, {}, // dati opzionali da inviare al server function (permission) { if (permission.permission === 'granted') { console.log("Notifiche push abilitate!"); sendSubscriptionToServer({ endpoint: permission.deviceToken }); } else { console.log("Notifiche push non abilitate dall'utente."); } } ); break; case 'denied': // L'utente ha negato console.log("Notifiche push negate."); break; case 'granted': // L'utente ha già autorizzato console.log("Notifiche push già autorizzate."); sendSubscriptionToServer({ endpoint: permissionData.deviceToken }); break; } } Any suggestions of what I'm missing? Is there a complete guide to how generate the push package? Thank you

Crash Stack: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x19ba3bb04) frame #0: 0x000000019ba3bb04 CoreFoundation`forwarding.cold.2 + 92 frame #1: 0x000000019b8ab718 CoreFoundation`forwarding + 1288 frame #2: 0x000000019b8ab150 CoreFoundation`_CF_forwarding_prep_0 + 96 frame #3: 0x000000019df230b0 CoreText`TCFRef<CTRun*>::Retain(void const*) + 40 frame #4: 0x000000019e052050 CoreText`CreateFontWithFontURL(__CFURL const*, __CFString const*, __CFString const*) + 476 frame #5: 0x000000019e052874 CoreText`TCGFontCache::CopyFont(__CFURL const*, __CFString const*, __CFString const*) + 144 frame #6: 0x000000019df27dcc CoreText`TBaseFont::CopyNativeFont() const + 232 frame #7: 0x000000019df8ee64 CoreText`TBaseFont::GetInitializedGraphicsFont() const + 152 frame #8: 0x000000019df26d70 CoreText`TBaseFont::CopyVariationAxes() const + 296 frame #9: 0x000000019df2d148 CoreText`TDescriptor::InitBaseFont(unsigned long, double) + 768 frame #10: 0x000000019df21358 CoreText`TDescriptor::CreateMatchingDescriptor(__CFSet const*, double, unsigned long) const + 604 frame #11: 0x000000019df251f8 CoreText`CTFontCreateWithFontDescriptor + 68 frame #12: 0x00000001bff8dfb8 WebCore`WebCore::createCTFont(__CFDictionary const*, float, unsigned int, __CFString const*, __CFString const*) + 124 frame #13: 0x00000001bff8e8bc WebCore`WebCore::FontPlatformData::fromIPCData(float, WebCore::FontOrientation&&, WebCore::FontWidthVariant&&, WebCore::TextRenderingMode&&, bool, bool, std::__1::variant<WebCore::FontPlatformSerializedData, WebCore::FontPlatformSerializedCreationData>&&) + 228 frame #14: 0x00000001c128eef4 WebKit`IPC::ArgumentCoder<WebCore::Font, void>::decode(IPC::Decoder&) + 1352 frame #15: 0x00000001c1333ca4 WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::ArgumentCoder<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>, void>::decodeIPC::Decoder(IPC::Decoder&) + 480 frame #16: 0x00000001c1333a5c WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::Decoder::decode<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>() + 28 frame #17: 0x00000001c1333804 WebKit`std::__1::optional<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>> IPC::Decoder::decode<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>>() + 156 frame #18: 0x00000001c121f368 WebKit`IPC::ArgumentCoder<WebCore::AttributedString, void>::decode(IPC::Decoder&) + 172 frame #19: 0x00000001c121f124 WebKit`std::__1::optionalWebCore::AttributedString IPC::Decoder::decodeWebCore::AttributedString() + 28 frame #20: 0x00000001c12594ec WebKit`IPC::ArgumentCoder<WebCore::DictionaryPopupInfo, void>::decode(IPC::Decoder&) + 76 frame #21: 0x00000001c12d0660 WebKit`std::__1::optionalWebCore::DictionaryPopupInfo IPC::Decoder::decodeWebCore::DictionaryPopupInfo() + 28 frame #22: 0x00000001c12ceef0 WebKit`IPC::ArgumentCoder<WebKit::WebHitTestResultData, void>::decode(IPC::Decoder&) + 1292 frame #23: 0x00000001c1338950 WebKit`std::__1::optionalWebKit::WebHitTestResultData IPC::Decoder::decodeWebKit::WebHitTestResultData() + 28 frame #24: 0x00000001c1ec7edc WebKit`WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 31392 frame #25: 0x00000001c1fb8f28 WebKit`IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 frame #26: 0x00000001c19ab2c0 WebKit`WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 frame #27: 0x00000001c1fb3254 WebKit`IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) + 252 frame #28: 0x00000001c1fb3768 WebKit`IPC::Connection::dispatchIncomingMessages() + 576 frame #29: 0x00000001b9ab90c4 JavaScriptCore`WTF::RunLoop::performWork() + 204 frame #30: 0x00000001b9ab9fec JavaScriptCore`WTF::RunLoop::performWork(void*) + 36 frame #31: 0x000000019b8cc8a4 CoreFoundation`CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 frame #32: 0x000000019b8cc838 CoreFoundation`__CFRunLoopDoSource0 + 176 frame #33: 0x000000019b8cc59c CoreFoundation`__CFRunLoopDoSources0 + 244 frame #34: 0x000000019b8cb138 CoreFoundation`__CFRunLoopRun + 840 frame #35: 0x000000019b8ca734 CoreFoundation`CFRunLoopRunSpecific + 588 frame #36: 0x00000001a6e39530 HIToolbox`RunCurrentEventLoopInMode + 292 frame #37: 0x00000001a6e3f348 HIToolbox`ReceiveNextEventCommon + 676 frame #38: 0x00000001a6e3f508 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #39: 0x000000019f442848 AppKit`_DPSNextEvent + 660 frame #40: 0x000000019fda8c24 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 frame #41: 0x000000019f435874 AppKit`-[NSApplication run] + 480 frame #42: 0x000000019f40c068 AppKit`NSApplicationMain + 888 frame #43: 0x00000001ca56a70c SwiftUI`merged generic specialization <SwiftUI.TestingAppDelegate> of function signature specialization <Arg[0] = Existential To Protocol Constrained Generic> of SwiftUI.runApp(__C.NSResponder & __C.NSApplicationDelegate) -> Swift.Never + 160 frame #44: 0x00000001ca9e09a0 SwiftUI`SwiftUI.runApp<τ_0_0 where τ_0_0: SwiftUI.App>(τ_0_0) -> Swift.Never + 140 frame #45: 0x00000001cad5ce68 SwiftUI`static SwiftUI.App.main() -> () + 224 frame #46: 0x0000000105943104 MyApp Dev.debug.dylib`static MyMacApp.$main() at :0 frame #47: 0x0000000105943c9c MyApp Dev.debug.dylib`main at MyMacApp.swift:24:8 frame #48: 0x000000019b464274 dyld`start + 2840

I am calling fetch with a POST on page1 in Safari. No special cache parameters on the fetch call. The response from the server is a 303 redirect to page2 The second page -- page2 -- is in my browser's cache with cache-control "public, max-age=31536000, immutable". For some reason, the page2 redirect is causing a server hit to re-GET the second page every time instead of pulling from cache. If I instead directly get the second page by doing a fetch on page2, there is no server hit. If I do this on Chrome or Firefox, it behaves as I would expect, pulling page2 from the cache with no server hit. In case it matters, the fetch is coming from within an iFrame. Also, if I change the original POST to a GET, the problem still happens. I am using a pretty old version of Safari on my Mac, so I could chalk it up to that, but I am getting the same behavior with Safari on my iPhone with iOS 18.3.2 Any ideas? Thanks.

We have a Safari extension that's been up on the App Store for about 18 months with no apparent issues. This week, however, while working on an update, we uninstalled the production version on our test machines and installed a developer version. When we had some issues, we tried to go back to the production version downloaded from the App Store, but we get an pop saying "Unable to download App." In the log, the most obviously relevant error is 'Operation not permitted'. This occurs on several machines and different logins on those machines in both norma and safe modes. However, on another machine that never had one installed, we could still install the app from the app store, so I suspect there is something left behind that needs to be removed, but I don't know what. FWIW, I see the download directory getting created under /Applications, but it is promptly removed when the failure popup appears. Any suggestions?

After the first installation (out of AppStore) of the extension in the browser, the content script is correctly inserted into the page (twice for some reason) and a message is sent from the root of the content script to the background script, which responds correctly. However, if an event handler is registered within the content script, within which the message is also sent to the background script, it will never reach the background script. window.addEventListener("message", function (event) { // We only accept messages from ourselves if (event.source !== window) { return; } if (event.data.source && event.data.source === appIdentification) { browser.runtime.sendMessage(event.data); } }, false); It does not matter with what delay the event handler is called (i.e. the background script is not asleep). If I refresh the page or close and reopen the browser and reload the page, everything works correctly and the message sent from the event handler is already delivered to the background script. The event handler is used so that the extension code is uniform for all browsers (Chrome, Safari, Edge, Opera, Firefox), i.e. it is not intended to use externally_connectable for sending messages from the webpage directly to the background script, which Safari should support. The expected behavior is that the extension will work even after the first installation, as is the case with other browsers. Procedure: Enter the test website: https://www.mssf.cz/testapp/check_client.aspx Do the initial installation of the extension (could be downloaded from here: https://1drv.ms/f/c/76f4c93826df41a0/Ej5MQX9ctyhHv_P9_t_6uAwB05ET-nzXuMhPeu56nOgkWg?e=cudqRJ) Set a breakpoint in the event handler for "message" within the content script, open the background script and set a breakpoint in the event handler for onMessage Click on the "Validate certificate" button on the page loaded in point 1 Step through the content script to the point where the message is sent to the background script, the breakpoint within the background script is never hit, which is an error, the message should come to the background script

I want to confirm the specifications and behavior of Safari. We have a system built on Microsoft Azure that uses Azure AD B2C for authentication. When we logging in, there is a phone authentication feature where a call is made to the registered phone number. However, this phone authentication does not work properly only on iPhone's Safari. The specific situation is listed below: When performing phone authentication on iPhone's Safari, a call is made from Azure AD B2C, and pressing the # button on the Safari screen can be done. But then, it transitions to an error screen. We tried multiple iPhone devices and multiple iOS versions, but the result was the same. But when accessing the system on a PC, and performing phone authentication, it works without any errors. Also when we use browsers other than Safari (for example, Google Chrome and Firefox) on the iPhone, the phone authentication works without any errors, too. Even with Safari, if the device displaying the login screen and the device making the call are different, phone authentication works without any errors, too.(it fails if they are the same device). We reached out Microsoft about this issue, and they responded that: The Azure resource called FrontDoor at the front end of Azure AD B2C supports the HTTP/2 protocol, and HTTP/2 protocol is used in communication with Safari. In Safari's HTTP/2 communication, when a call is received while the screen is displayed, a reset packet is sent to the web server (in this case, the web server is FrontDoor). This interrupts the session, causing a session termination error on the Azure AD B2C side, and phone authentication fails. Therefore, we would like to ask you the following two points: In HTTP/2 communication, does the Safari browser send a reset packet to the web server when it receives a phone call? If so, what is the cause of this behavior? And are there any measures to prevent the reset packet from being sent?

From a mail app or similar, when opening a webpage in Safari as an external browser, JavaScript on the webpage stops running if Safari goes into the background. Is there a way to prevent this from happening? Sample code for the counter: Behavior: Upon returning from the background, the counter continues for about 7-8 seconds but does not progress further. For example, if Safari is kept in the background for about 20 seconds and then brought back, the counter stops at around 7-8 seconds and only resumes counting after returning to the foreground. Expectation: The counter should continue running even if Safari goes into the background.

What happens if Safari is uninstalled or disabled on iOS? Will SFafariviewcontroller still work? Kind regards

Hello there, For a video like this <video src="blob:safari-web-extension://***" autoplay="" loop="" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; object-fit: cover; z-index: -1;"></video>, no matter if its local or remote, blob or mp4 files, is constantly being reloaded (refetched? revalidated?) if the loop tag is added. I can confirm there is actual constant traffic from the server based on my server logs. I am running iOS/macOS 26.

Hi Apple Developer Community and Support, We are implementing Apple Pay on the Web and are encountering a persistent issue with merchant validation when the ApplePaySession is initiated from a JavaScript application running within a cross-origin iframe. Our Setup: Top-Level Domain: https://application.my.com/ (where the Apple Pay button is displayed, and the iframe is embedded) iFrame Content Origin: https://cashier.my.com/ (Our custom JavaScript application that handles the Apple Pay integration and directly calls our Payment Service Provider's (PSP) API for merchant validation). iFrame allow attribute: The iframe correctly includes allow="payment *". The Problem: When a user clicks the Apple Pay button, the ApplePaySession is successfully created and the Apple Pay sheet opens in Safari iOS. This suggests the browser recognizes the allow="payment *" attribute and allows the API calls. However, during the session.onvalidatemerchant callback, our JavaScript code makes a direct API call to our PSP (Nuvei)'s endpoint. This call consistently fails with an "Invalid domain name!" error, and the Apple Pay sheet then shows "Payment Not Completed." PSP's Diagnosis: Our PSP (Nuvei) has investigated and stated that for this specific endpoint (getAppleValidationApiFlow.do), "there is no explicit way to pass domain to the endpoint and domain for which session is issued is based on 'Referer' header." Our Question for Apple: Given that Safari 17+ now supports allow="payment" for cross-origin iframes to enable Apple Pay APIs, we have the following questions: What is Apple's official guidance or expectation regarding the Referer header for ApplePaySession.onvalidatemerchant calls when the ApplePaySession is instantiated from a cross-origin iframe? Is it expected that the Referer header for calls originating from the iFrame will always be the iFrame's origin? Does Apple's merchant validation process (when the PSP calls apple-pay-gateway.apple.com/paymentservices/startSession) itself rely on or interpret the Referer from the initial client-to-PSP call? Are there recommended best practices or standard approaches for PSP integrations in this cross-origin iFrame scenario to ensure the Referer validation (or equivalent domain validation) is correctly satisfied? We're trying to understand if our PSP's specific reliance on the Referer for this validation is a standard requirement implicitly set by Apple for this flow, or if there are other architectural approaches that should allow this scenario to work seamlessly. Thank you for any insights or guidance you can provide.

I'm trying to use ES6 module imports in a Safari Web Extension, but despite enabling "type": "module" in the manifest, imports are not functioning as expected. Specifically when working with a project structure that includes multiple directories. A root directory containing the manifest.json and main entry point scripts A scripts/ folder housing core functionality modules A common/ directory for shared utilities, constants, and helper functions A background.js file in the root that attempts to import from these various directories When trying to import modules from the scripts/ and common/ directories into my background.js, I'm encountering complete import failures. How can I correctly implement cross-directory module imports in Safari Web Extensions?

Since Safari requires a macOS app as a container for Web Extensions, is there a way to establish native messaging directly from SafariWebExtensionHandler using stdin/stdout? Or does Safari enforce a different communication mechanism? I’d like to keep the same approach as other browsers. Any guidance on making this work would be appreciated!

We would appreciate it if you could provide the detailed flow of recurring payments and the unsubscribe process using the Apple Pay JS API, specifically in cases where the PSP decrypts the Apple Pay token before sending it to the payment gateway. Thank you very much for your kind assistance.