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.

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'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?

正文：大家好， 当设备连接到没有互联网的 Wi-Fi SSID（例如，硬件设备的 AP）时，我看到 NSURLSession（multipathServiceType = NSURLSessionMultipathServiceTypeInteractive）和 WKWebView 之间的行为存在令人费解的差异。我正确启用了多路径授权，在这种情况下： NSURLSession 请求会自动回退到蜂窝网络并成功（无需用户干预，快速切换）。 WKWebView 加载失败或停滞：Web 内容未出现，即使系统网络路径得到满足并确认了真正的 Internet 可访问性，Web 视图似乎也没有使用蜂窝路径。 环境： iOS 版本：（例如 iOS 18.4） 设备：（例如 iPhone 15 Pro） 多路径权利：在应用程序中启用，使用 NSURLSessionMultipathServiceTypeInteractive 连接的 SSID：硬件设备 Wi-Fi，无需外部互联网 预期回退：一旦 Wi-Fi 没有互联网，就会自动到蜂窝网络，如 NSURLSession 所观察到的那样 我做了什么/观察到什么： 使用多路径的 NSURLSession 按预期工作：NSURLSessionConfiguration *cfg = [NSURLSessionConfiguration defaultSessionConfiguration];cfg.multipathServiceType = NSURLSessionMultipathServiceTypeInteractive;NSURLSession *session = [NSURLSession sessionWithConfiguration：cfg];NSURLRequest *req = [NSURLRequest requestWithURL：[NSURL URLWithString：@“https://www.apple.com/library/test/success.html”]];NSURLSessionDataTask *task = [session dataTaskWithRequest：req completionHandler：^（NSData *data， NSURLResponse *resp， NSError *err） { NSLog（@“NSURLSession result： %@， error： %@”， resp， err）; }];[任务简历];连接到设备 Wi-Fi（无外部 Internet）时，会话会悄悄地切换到手机网络并成功完成。 相同情况下WKWebView加载失败：[self.webView loadRequest：[NSURLRequest requestWithURL：[NSURL URLWithString：@“https://www.apple.com/library/test/success.html”]]];Web 视图要么显示负载失败，要么只是挂起，即使较低级别的监视报告网络路径已满足并且真正的 Internet 连接可用。 网络路径监控逻辑： 我使用 C API nw_path_monitor来监视nw_path_status_satisfied。 一旦观察到满意，我就会使用nw_connection（例如，连接 tohttps://www.apple.com/library/test/success.html）执行真正的连接检查，以验证真实的互联网流量是否可以通过蜂窝网络流动。 该检查通过，确认回退到手机网络，但 WKWebView 仍不会加载内容。同时，相同条件下的 NSURLSession 请求会立即成功。 示例日志记录跟踪：[+] nw_path_status_satisfied=1， hasWiFi=1， hasCellular=1 [+] Internet 连接测试：准备就绪（通过 nw_connection） [-] WKWebView 加载失败/停滞 [+] NSURLSession 请求成功完成 问题： 为什么当 Wi-Fi 没有 Internet 时，具有多路径服务类型的 NSURLSession 无缝使用蜂窝网络，但 WKWebView 不表现出相同的回退行为？WKWebView 是否不以相同的方式接受系统的多路径回退？在这种情况下，它是否使用不同的网络堆栈或忽略多路径授权？ 是否有一种受支持的方法可以强制 WKWebView 像 NSURLSession 一样运行？ 例如，我是否可以通过启用多路径的 NSURLSession 桥接内容，并通过自定义方案将其注入 WKWebView？ 是否有任何 WKWebView 配置标志、首选项或策略启用相同的自动接口切换？ 与原始 NSURLSession 相比，WKWebView 处理网络接换、路径满意度或多路径的方式是否存在已知限制或记录在案的差异？ 我排除/尝试过的： 已验证多路径授权是否包含且处于活动状态。 确认的网络路径“满足”，并且在调用 [webView loadRequest：] 之前，真正的 Internet 可访问性成功。 将 WKWebView 加载延迟到连接验证之后。 观察到 NSURLSession 请求在相同的连接条件下成功。 任何对内部差异、推荐的解决方法或 Apple 推荐的模式的见解，以使 Web 内容在“没有互联网的 Wi-Fi”+ 自动回退到蜂窝场景中变得健壮，我们将不胜感激。 谢谢！

Good morning fellow developers, For a while i am struggeling with providing sound to my users on IOS (Safari on Mac is no problem and every other device is not a problem) (we have an existing phone system and made a chat as well), the case is very simple: the notification sound is only for users who are logged in and online for chat. i have tried multiple things: Audio play with javascript (start with mute, play when user clicks a button so the sound is familiar, play when user clicks a button and directly pause it and continue when needed) PWA: the dashboard has been made available as pwa and notifications using google firebase. The popup does show for notifcations to be allowed (and receiving the notifications does work on any other device) But any IOS device cannot register. The information i find is that notifications were supported with 16.4 or higher but also have been deprecated around IOS 17, auto play is not allowed. We have an app in development for our product as well were we will have a notification which will handle this, but that is not the solution we can use now. Long story, short question: is it still somehow possible to push a notification to the user when using the PWA or play a sound in the browser (based on an ajax function). The app/website wont be in the background, so it will always be on the screen. Languages we use: html/javascript (mostly vanilla)/php

I am currently developing a Chrome, Firefox and Safari web extension, and I am facing a CSP issue on the content script on Safari. The extension I develop has a content script that injects an img tag in the DOM of web pages the user is visiting. That img tag fetches its content at a specific URL. On Chrome and on Firefox, the img tag content fetches the content at the URL with no issue on every web pages, including those that set the CSP header img-src. On Safari, I'm getting the following error on web sites that set the img-src CSP header: Refused to load https://axxlfrmnpq.cloudimg.io/www.macifavantages.fr/wp-content/uploads/2021/06/Garmin-logo.png?func=bound&w=225&h=113 because it does not appear in the img-src directive of the Content Security Policy. Here is the actual CSP img-src header content of the web page where, on Safari, the injected img tag does not load the content at https://axxlfrmnpq.cloudimg.io/www.macifavantages.fr/wp-content/uploads/2021/06/Garmin-logo.png?func=bound&w=225&h=113: Content-Security-Policy: img-src https://secure.adnxs.com https://www.facebook.com https://.garmin.cn 'self' data: .garmin.com .trustarc.com .truste.com https://static.garmincdn.com https://www.google.com https://www.google.co.uk https://prefmgr-cookie.truste-svc.net https://res.cloudinary.com https://res.garmin.com https://.criteo.com https://.doubleclick.net https://www.googleadservices.com https://px.adentifi.com https://rtb.adentifi.com https://.teads.tv https://www.googletagmanager.com https://bat.bing.com https://.yahoo.com https://sync.outbrain.com https://*.google-analytics.com https://stats.g.doubleclick.net https://static.hotjar.com https://script.hotjar.com .akamaihd.net https://.tealiumiq.com https://deploytealium.com https://pixel.mediaiqdigital.com; My question is, is the page CSP blocking the img tag injected in the web page by the extension's content script? If so, is this behavior documented somewhere, or is it a Safari bug? I saw there is a similar post on the forum, but I couldn't find if the issue is a bug or if it's the expected behavior on Safari: https://developer.apple.com/forums/thread/651542?login=true. Thank you very much for your help.

We're embedding the Power BI reports into our portal by using JS library. While testing them, we found that mobile layout of the reports don't work as we expect on iOS devices (tested in Chrome and Safari). There are two principals issues: 1) the site is automatically refreshed when the users filter the data (we reduced them to lower expression) and 2) the site also crashes after a while using the dashboard by applying different filters.

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?

please network best link wifi perfile very issue in wifi

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.

My website ccflood.us is a simple map that uses a CSV file for the data that is displayed on the map. It uses the ESRI JS API. Recently the points on the map began missing the text in the boxes only on Apple devices that have been upgraded to iOS 18. Has anyone also had this happen to their site? If you have upgraded to iOS 18, try this site on your iPhone then look at it on an Android phone or your desktop browser. You should seet the values in the boxes and a "+" at points that have no value. If you've had this happen with your site or have heard of a fix, please reply to this post.

Environment • Device: any iPhone running iOS 26 Developer Beta 5 (23A5308g) • Xcode: 16.3 Short description The app crashes the moment the user tries to long-press to select text inside a WKWebView, double-tap an image with Text (magnifier appears) The exception is CALayer position contains NaN. frame = (nan,0;0,48) chorPoint=(inf, 0) and it is thrown in the UI process. Build & run any project that hosts a WKWebView. Inject the following CSS via script (this is what we do to suppress the native callout menu): WKWebView *webView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:[WKWebViewConfiguration new]]; NSString *js = @"document.documentElement.style.webkitUserSelect='none';" "document.documentElement.style.webkitTouchCallout='none';"; [webView evaluateJavaScript:js completionHandler:nil]; [self.view addSubview:webView]; Incident Identifier: EE6FB046-5087-4F15-A72D-A74965347A30 CrashReporter Key: 29e8e58e02a07557adb4ce3f463d764f3ce8bbd5 Hardware Model: iPhone16,1 Process: wallet [642] Path: /private/var/containers/Bundle/Application/4B4E609A-C8BF-4C56-AB2A-1638249B98A5/wallet.app/wallet Identifier: xxxxxxx Version: xxxx AppStoreTools: 16F7 AppVariant: 1:iPhone16,1:18 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: xxxxxx Date/Time: 2025-08-06 12:05:24.0732 +0800 Launch Time: 2025-08-06 11:49:40.3802 +0800 OS Version: iPhone OS 26.0 (23A5308g) Release Type: Beta Baseband Version: 3.02.02 Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: wallet [642] Triggered by Thread: 0 Application Specific Information: abort() called Thread 0 Crashed: 0 libsystem_kernel.dylib 0x22da0f0cc __pthread_kill + 8 1 libsystem_pthread.dylib 0x1e097b7e8 pthread_kill + 268 2 libsystem_c.dylib 0x191361f1c abort + 124 3 libc++abi.dylib 0x182e7a808 __abort_message + 132 4 libc++abi.dylib 0x182e69484 demangling_terminate_handler() + 304 5 libobjc.A.dylib 0x182d7bf28 _objc_terminate() + 156 6 wallet 0x1068ff8c8 0x1046f4000 + 35698888 7 libc++abi.dylib 0x182e79bdc std::__terminate(void (*)()) + 16 8 libc++abi.dylib 0x182e7d314 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 9 libc++abi.dylib 0x182e7d2bc __cxa_throw + 92 10 libobjc.A.dylib 0x182d7992c objc_exception_throw + 448 11 CoreFoundation 0x185e908d4 +[NSException raise:format:] + 128 12 QuartzCore 0x18678a874 CA::Layer::set_position(CA::Vec2<double> const&, bool) + 160 13 QuartzCore 0x1869a7270 -[CALayer setPosition:] + 52 14 UIKitCore 0x18c4ac564 -[UIView _backing_setPosition:] + 176 15 UIKitCore 0x18cefdf0c -[UIView setCenter:] + 220 16 UIKitCore 0x18cd9f794 -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] + 936 17 UIKitCore 0x18cd9f3c0 __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke + 104 18 UIKitCore 0x18ced1060 -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] + 384 19 UIKitCore 0x18cd9f2e4 -[_UIEditMenuContentPresentation _displayMenu:reason:] + 304 20 UIKitCore 0x18cd9f0d8 -[_UIEditMenuContentPresentation displayMenu:configuration:] + 64 21 UIKitCore 0x18ced0344 __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke + 260 22 UIKitCore 0x18ced1f8c __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke + 80 23 UIKitCore 0x18cc8403c __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke + 180 24 UIKitCore 0x18cc84584 __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke + 148 25 WebKit 0x1a05ae5d4 WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) + 64 26 WebKit 0x1a05bb468 WTF::Detail::CallableWrapper<WTF::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) + 196 27 WebKit 0x19fcf5db8 WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) + 64 28 WebKit 0x19fce54f0 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 340 29 WebKit 0x19fcf5aa0 IPC::Connection::dispatchIncomingMessages() + 536 30 JavaScriptCore 0x19a8f85d4 WTF::RunLoop::performWork() + 552 31 JavaScriptCore 0x19a8f838c WTF::RunLoop::performWork(void*) + 36 32 CoreFoundation 0x185da6230 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 33 CoreFoundation 0x185da61a4 __CFRunLoopDoSource0 + 172 34 CoreFoundation 0x185d83c6c __CFRunLoopDoSources0 + 232 35 CoreFoundation 0x185d598b0 __CFRunLoopRun + 820 36 CoreFoundation 0x185d58c44 _CFRunLoopRunSpecificWithOptions + 532 37 GraphicsServices 0x224ce0498 GSEventRunModal + 120 38 UIKitCore 0x18b6c84b8 -[UIApplication _run] + 792 39 UIKitCore 0x18b66cbc0 UIApplicationMain + 336 40 wallet 0x1046f8558 0x1046f4000 + 17752 41 dyld 0x182dcdb18 start + 6332

We are encountering a download issue in Safari 18.2 on macOS Sequoia 15.2 where file downloads initiated by our AngularJS application (such as Excel exports) are silently blocked. There are no errors in the browser console, and the download does not occur. Interestingly, after testing on Safari 18.3 with Sequoia 15.3, the downloads worked as expected. However, the problem reappeared on Safari 18.4 with Sequoia 15.4. We suspect that recent changes in Safari’s security or download handling may be preventing downloads triggered via asynchronous JavaScript (e.g., AJAX calls) that are not initiated directly by user interaction. We would appreciate any insights, suggestions, or possible workarounds from the community. Looking forward to your guidance on this matter.

Dear Apple Developer Support Team, I am writing regarding critical issues we are facing with Safari web push notifications in our application iLiveMyLife.io, which is severely impacting our ability to maintain reliable communication with our users. Issue Description: We are experiencing persistent problems with Safari push notification tokens expiring or becoming invalid without any notification to our server. This creates several critical issues: Users stop receiving notifications without any indication of failure Our notification delivery system has no way to detect token expiration The expiration appears to happen frequently (seemingly almost daily in some cases) There is no reliable mechanism to re-establish push communication without users manually revisiting the app Technical Impact: Our messaging functionality becomes completely unreliable We must resort to email or SMS as fallback mechanisms, which is not feasible for a real-time communication platform This makes building any reliable messaging application on Safari practically impossible The Broader Context: What makes this situation particularly challenging is that all potential alternative browser APIs that could help address this issue appear to be deliberately disabled or restricted in Safari: Background Service Workers don't function in the background on iOS Safari Background Sync API is not supported WebSockets cannot operate when the app is closed There's no way to programmatically check the validity of push tokens The combination of these limitations creates a situation where developers have no viable technical path to build reliable notification systems for PWAs on Safari. This appears to be a systematic restriction rather than individual API limitations. Requested Information: Is there a recommended approach to detect Safari push token expiration? Are there alternative notification mechanisms for PWA applications on Safari that offer more reliability? Is there documentation on the lifecycle of Safari push tokens that could help us implement proper handling? Are there plans to improve the Web Push API implementation in Safari to address these reliability issues? Could you clarify if these limitations are intentional design decisions or technical constraints that might be addressed in future updates? Business Impact: This issue fundamentally undermines our platform's core functionality. For a collaborative tool, reliable notifications are essential - users cannot collaborate effectively if they miss updates because their push tokens silently expired. The current state creates confusion among our users, who don't understand why they suddenly stop receiving notifications. Any guidance or assistance you could provide would be greatly appreciated. We're committed to providing an excellent experience on Safari, but the current push notification limitations make this extremely challenging. Thank you for your time and consideration. Best regards, Ilya

I am trying to build and run a Safari Web Extension from Xcode and I have enabled "Allow unsigned extensions" in Safari settings. However, I see the below pop up: And, if click on the "Quit and Open Safari Extensions Preferences..." button, the project stops running on Xcode and nothing happens. What can be the issue? The extension works and runs fine if I get it from the Mac App Store and this only happens when running from Xcode. I even tried completely uninstalling the mac app store version and still facing the same issue.

Merhaba ben Müslüm İkuz blog sayfam için Safari tarayıcıdan siteye çok fazla istek geliyor. Sayaçlara girdiğimde uygulama safari olarak gözüküyor ve binlerce sayfa isteği gelmiş. Bu bir siber saldırı mı ? site adress https://ikuz.com.tr/

Hi, We have a native application with a webview part. When we open the app, we load webview resources in a false foreground. The webview communicates with the native part to query local variables, among other things. We have noticed that for the past few weeks, when the biometric component is presented to enter the fingerprint or faceId, while the component is displayed, the webview does not respond. We do not see the calls made by the webview, nor can we respond to them. Even if you open the Safari debugger, the webview does not respond UNTIL you close the biometric component in the native part. This has created a big problem in our app, and we wanted to know if it is an issue you had on your radar. Thank you very much.

Hello, I’m working on a cross-origin WebAuthn implementation where a parent page embeds an iframe from a different origin to perform authentication. According to the WebAuthn Level 3 spec (Section 7.1.1), when crossOrigin is true, the clientDataJSON may include topOrigin—but Safari does not seem to populate this field. Observed Behavior: Chrome/Firefox: Include topOrigin in clientDataJSON when crossOrigin: true. Safari (macOS/iOS): Omits topOrigin even though crossOrigin is correctly set to true. Example clientDataJSON from Safari: { "type": "webauthn.get", "challenge": "...", "origin": "https://iframe-origin.example.com", "crossOrigin": true // Missing `topOrigin` (expected: parent origin) } Questions: Is this an intentional omission in Safari for privacy/security reasons? Are there specific requirements (e.g., HTTP headers, permissions policies) needed for Safari to expose topOrigin? Is there a known workaround to reliably obtain the top-level origin in cross-origin WebAuthn flows? System Info: Version 18.4 (20621.1.15.11.10) OS: Sequoia Version 18.4 (20621.1.15.11.10) Reproduction Steps: Parent page (https://parent.example.com) embeds an iframe (https://webauthn-rp.example.com). The iframe calls navigator.credentials.get() with a WebAuthn challenge. Safari returns clientDataJSON with crossOrigin: true but no topOrigin. Code Snippet (iframe): const credential = await navigator.credentials.get({ publicKey: { challenge: new Uint8Array(/* ... */), rpId: 'webauthn-rp.example.com', allowCredentials: [], hints: [], userVerification: "preferred", } }); console.log(JSON.parse(atob(credential.response.clientDataJSON))); Has anyone encountered this? Any insights would be greatly appreciated!

ios drop file wrong file name I use the following simple JS code to drag file from the browser to the desktop. Works perfect on MacOS. onDragStart(event, ucpView) { let file = new BrowserFile([this.file.fileContent], this.file.displayName, { type: 'application/ucp-scenario' }); const fileURL = URL.createObjectURL(file); event.dataTransfer.setData("DownloadURL", `application/octet-stream:${file.name}:${fileURL}`); event.dataTransfer.setData("text/uri-list", fileURL); } but on iOS it keeps nameing the file Text1.txt Text2.txt ... and ignores the DownloadURL whats the best way to get it workng on both OS?

I have a UI application built with the Vue framework, using Vuetify for the UI components. There's a div with the class v-application--wrap, which is provided by Vuetify. This class internally includes the following style rule. .v-application--wrap { backface-visibility: hidden; display: flex; flex: 1 1 auto; flex-direction: column; max-width: 100%; min-height: 100vh; position: relative; } The pages were rendering correctly up to version 18.3, but after upgrading to version 18.4, we encountered layout issues related to height. Upon investigation, we discovered that the min-height property was no longer being interpreted or applied correctly. Replacing min-height with height resolved the issue, and the pages began loading as expected. Any insights into why this behavior is occurring would be greatly appreciated.