Please kindly improve the Safari browser side bar implementation further along with what The Browser Company has done with their Arc browser. Arc is about to retire soon too and they're willing to sell their SwiftUI code perhaps too for a decent pile of dollars, not the Jony Ive piles at least it should not. The toggle for side bar is nice and works perfect though!

Hello, After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project). Observed behavior On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return. This happens not only for: evaluateJavaScript("navigator.userAgent") but also for simple or even empty scripts, for example: evaluateJavaScript("") On previous macOS versions, the same calls typically returned in ~200 ms. Additional testing I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls. In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2. Question Is this a known issue or regression related to: iOS Apps on Mac, Swift + WKWebView, or behavioral changes in evaluateJavaScript on macOS 26.2? Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated. Thank you. Test Code Swift class ViewController: UIViewController { private var tmpWebView: WKWebView? override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. setupUserAgent() } func setupUserAgent() { let t1 = CACurrentMediaTime() tmpWebView = WKWebView(frame: .zero) tmpWebView?.isInspectable = true tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in let t2 = CACurrentMediaTime() print("[getUserAgent] \(t2 - t1)s") self?.tmpWebView = nil } } } Test Code Objective-C - (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions { NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; WKWebView *webView = [[WKWebView alloc] init]; dispatch_async(dispatch_get_main_queue(), ^{ [webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) { NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970]; NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime)); }]; }); }

I'm working on a Safari web extension that uses the nativeMessaging facility to communication with native code. When I want to notify the javascript extension from the embedding application, I use SFSafariApplication::dispatchMessage. As per the documentation, this call ... ensures that Safari is launched and that your extension is running before delivering the message. Everything works fine when the background script is running. However, after the background script gets unloaded at some point in time (non persistent background page, default behavior for a manifest V3 extension), the background script is not reloaded by the message from the native app (background script still appears unloaded in the developer menu of Safari, double-checked using a counter stored in browser.storage.local incremented on message reception). In this case, the completion handler of the application gets no error (error == nil) as if the message was correctly delivered. I was able to reproduce this behavior with the sample app delivered for WWDC20 (after upgrading the manifest from v2 to v3 to make it non-persistent). Is it supposed to work ? What I'm doing wrong ?

Hi, I am developing an OpenType font with the following cursive feature. feature curs { lookup cursivejoinrtl; # RIGHT_TO_LEFT flag set between Hah, Meem, Yeh and final Meem lookup rehwawcursive; # RIGHT_TO_LEFT flag clear between Waw and Hah } curs; Here is the rendering of the word وحميم in TextEdit. Using HarfBuzz I got the following result. The same rendering problem occurs when using Safari. It seems that is related to Core Text. I reported the issue to Feedback Assistant over a year ago but haven't had a response yet. So I'm posting the problem on this forum. Any support on this matter would be greatly appreciated.

WebRTC and Web Audio are essential for modern web applications, powering everything from real-time voice communication to accessibility tools. However, in iOS Safari, these technologies are suspended as soon as the screen locks or Safari goes into the background. This makes web-based calling, live audio spaces, broadcast sessions and assistive applications unreliable for iOS users. Why This Matters: It’s impractical and inefficient. Asking users to keep their screen on to continue a WebRTC call wastes more battery, as the display is one of the most power-intensive components of a device. Allowing WebRTC audio to run in the background would be more battery-efficient than forcing the screen to stay lit for extended periods. Competing platforms allow WebRTC to run in the background. Safari’s restriction puts web-based applications at a disadvantage compared to native apps. Many industries depend on persistent WebRTC audio, including telehealth, live broadcasting, and accessibility tools. This restriction forces developers to build native iOS apps instead of using the open web, limiting web innovation and increasing development costs. Proposed Solution: Apple could implement an explicit user permission for background WebRTC, similar to how background audio playback is already handled for media apps. This would balance user security with the need for uninterrupted real-time communication—without forcing users to keep their screens on unnecessarily. I would love to hear if anyone has found workarounds or if Apple has commented on potential improvements in future iOS versions.

Hello We've encountered an issue with WKWebView in the latest iOS 26 beta. When loading a PDF URL, the background of the PDF viewer now displays as a dark gray instead of the expected white. Device: iOS 26 Simulator/Device Component: WKWebView Issue: The background color of the loaded PDF is gray. Expected Behavior: The background should be white, as it has been in all previous iOS versions. Link for Testing: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf We confirmed that the same PDF and code render with a white background on iOS 26 and earlier. Questions: Is this an intentional change in iOS 26's WKWebView? If so, is there a new property or configuration setting available to control the background color of the PDF viewer within WKWebView? We would like to have the ability to set it back to white. Any insights, workarounds, or information on this matter would be greatly appreciated. Thank you.

DNR rules redirecting to an extension path lead to an error page: “Safari can’t open the page. The error is: “The operation couldn’t be completed. (NSURLErrorDomain error -1008.)” (NSURLErrorDomain:-1,008).” Here is a demo extension that replicates the bug: https://github.com/lenacohen/Safari-Test-Extensions/tree/main/dnr-extension-path-redirect This is an example of a redirect rule that leads to an error page instead of the extension path page: chrome.declarativeNetRequest.updateDynamicRules({addRules: [ { id: 2, priority: 1, action: { type: "redirect", redirect: { extensionPath: "/web_accessible_resources/test_redirect.html" } }, condition: { urlFilter: "||washingtonpost.com^", resourceTypes: [ "main_frame" ] } } ]}); The extension path is included in web_accessible_resources in the extension manifest: "web_accessible_resources": [{ "resources": [ "web_accessible_resources/test_redirect.html" ], I also submitted a bug report on Apple's Feedback Assistant: FB16607632

I'm building a progressive web app (PWA) and came to the conclusion that almost nobody knows that this feature exists - Add to Home Screen. Not many people even understand what a PWA is or that you can add it to the home screen. This feels unnatural compared to installing an app from a store. Why do we make it so hard for users? Could we not make this easier by having the ability to call this installation or show an install notification? Right now, when users visit a PWA on iOS, there's no way for developers to let them know they can install it. The "Add to Home Screen" option is tucked away in the Share menu, and most users never find it. I'd really like to be able to show them a friendly prompt. Comparing to other browsers, this is possible via the beforeinstallprompt event. This would make a huge difference for user experience. Right now the only way is to show iOS users a separate set of instructions with screenshots, which feels clunky compared to what's possible on other platforms. I'm curious - is there any reason why this hasn't been added to Safari yet? Other browsers have supported this for years now. Is there any progress being made on this, or is it being considered for the roadmap? It would be really helpful to know if this is something that will be worked on in the future. I know there's a lot on the roadmap, but this would really help developers create better installation experiences for our users. Thanks for considering this!

Hi, we are experiencing a strange issue with our Web App. Our web app runs entirely on the same domain , and we are making several AJAX requests to the same server. The Error occurs only on Iphones, the app works completely fine on androids and computers. Most of the requests work fine, but suddenly, one specific request always fails with the following error: XMLHttpRequest cannot load https://demo2.artios.cz/app37g/v105/php/endpoint.php due to access control checks What we have checked so far: ✅ CORS headers seem correct. Also we operate entirely on the same domain, client and server. ✅ The same request works fine in computer and android devices. ✅ The issue occurs only on iPhone (tested on Chrome and Safari). ✅ Some requests to the same endpoint pass, but suddenly, this specific request always fails. ✅ There is no OPTIONS preflight request logged in the network tab, but we use only simple requests. ✅ We are making a POST request with multipart/form-data. What is Your advice, or where I can find more info about this error? We do not think the CORS is the problem. We have tried to inspect with WebInspector but with no relevant answers. Thank You very much!

YouTube now requires a Referer to be sent to be able to embed Youtube videos, otherwise the videos won't work. But WKWebView doesn't send a Referer when using a custom scheme, so Youtube videos stopped working in that case. This affects Ionic apps, both using Cordova or Capacitor. There's an open issue for Cordova and another one for Capacitor. In these apps, the app is served using a custom scheme like capacitor://localhost or ionic://localhost. I tried modifying the Ionic WebView source code to force adding a referrer to the URL loaded using WKWebView's loadRequest: [request addValue:@"https://my.test.app" forHTTPHeaderField:@"Referer"]; [_engineWebView loadRequest:request] But the Referer is still not sent in the Requests, I guess because the app is using a custom scheme (e.g. capacitor://localhost). However, if I modify this code to force loading an "online URL" (using https) instead of capacitor://localhost, then the my.test.app Referer is sent to the requests. Is there any way to make WKWebView send a Referer when using a custom scheme?

Ever since the iOS and iPadOS 26.2 beta I can’t open Safari at all. Safari tries to open but crashes and goes back to my home screen. I’ve restored my devices and restarted everything and the same issue occurs. I didn’t have this problem on the beta 26.1 but this whole thing started on 26.2.

I have an extension which was working fine on older Safari version, but it is getting killed after I upgraded the browser to Safari 18 and higher. From the system logs I could see, Safari is sending the KILL signal to my browser 2024-11-12 13:51:01.536167-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] signal service: caller = Safari[45238], value = 0x9 2024-11-12 13:51:01.536453-0600 0xfab Default 0x0 382 7 WindowServer: (SkyLight) [com.apple.SkyLight:default] [ ConnectionDebug ] Closing conn 0xf955b, PID 45463 in session 257 on console2024-11-12 13:51:01.536474-0600 0x95b674 Default 0x0 1 0 launchd: [gui/503 [100018]:] service inactive: com.apple.xpc.launchd.unmanaged.SafariExtension.45463 2024-11-12 13:51:01.536479-0600 0x95b674 Default 0x0 1 0 launchd: [gui/503 [100018]:] removing inactive unmanaged service: com.apple.xpc.launchd.unmanaged.SafariExtension.454632024-11-12 13:51:01.537354-0600 0x95b907 Default 0x0 354 0 launchservicesd: [com.apple.processmanager:front-35286506] QUITTING: pid=45463 asn=0x-0x176176 foreground=0 wasFront=0 2024-11-12 13:51:01.537375-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] exited due to SIGKILL | sent by launchd[1], ran for 342ms 2024-11-12 13:51:01.537380-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] service state: exited 2024-11-12 13:51:01.537384-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] internal event: EXITED, code = 0 2024-11-12 13:51:01.537385-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] job state = exited Just before this, I see a macOS error 2024-11-12 13:51:06.789342-0600 0x95b74f Default 0x0 45238 0 Safari: (Security) [com.apple.securityd:security_exception] MacOS error: -67054 This occurs only in my customer machines but not in my test machines. I have verified the code signing, certificate validity & entitlements are fine.

Our current iOS application utilizes WKWebView to display a web application. We've observed intermittent deletion of non-expired 1st-party persistent cookies within this web application, leading to session drops. Here are our environment details and specific questions: Environment: App Build: Built with Xcode 16.2. WebView Class: WKWebView. Cookie Type: 1st-Party Persistent Cookie (Explicit expiration set, not a session cookie). Domain Configuration: The content server and the cookie-issuing server are the same (same IP address, same eTLD+1). The Cookie is set via the Set-Cookie HTTP Header on the server side. Questions: Automatic Deletion Policy: Are there any scenarios (e.g., related to iOS system behavior, Safari policies, or Intelligent Tracking Prevention (ITP)) where iOS or Safari might automatically delete non-expired 1st-party persistent cookies used by WKWebView? Deletion Conditions: If the answer to Q1 is Yes, under what specific conditions (e.g., memory pressure, inactivity, storage limits, specific ITP criteria) does this cookie deletion occur, and does the behavior differ significantly across various iOS versions? OS Update Impact: Are there any known specifications or documented cases where an iOS version update itself triggers the mass deletion of existing cookies stored in the WKWebsiteDataStore? Mitigation Strategy: If this automatic deletion is a known behavior, what mitigation strategies are officially recommended to ensure the persistence of essential 1st-party authentication cookies (e.g., manual synchronization with WKHTTPCookieStore or Keychain/UserDefaults)? Official Documentation: If the answer to Q1 is Yes, please provide URLs to any official Apple documentation or technical notes that detail the specifications or behavior of 1st-party persistent cookie deletion within WKWebView.

I’m developing a Safari App Extension and I want to debug the background.js script. However, I can’t find any tool or option to do this. When I run the extension from Xcode using the ProjectName Extension (macOS) scheme, I expect to see a “ProjectName” item under the Develop → Web Extension Background Content menu. But there’s nothing there. Has anyone encountered the same issue? How did you fix it? Environment: Manifest Version: V3 Safari: 26.0.1 (21622.1.22.11.15) Xcode: 26.0.1 (17A400)

I’m encountering an issue with CSS not displaying when using WKURLSchemeHandler to load local HTML files. When I package the app using Xcode 15.3 or above, the CSS styles do not display on iOS 17 or higher. However, on iOS 16.7.1, the CSS displays correctly. • If I use Xcode 15.2 to package the app, the CSS loads and displays correctly on all iOS versions. I am using WKURLSchemeHandler to intercept and load the local HTML files. Is there any known issue or workaround for this? You can now post this in the “Safari & Web” section of the Apple Developer forums for further assistance! // // CustomURLSchemeHandler.m // HTMLTest // // Created by lvxue on 2024/9/23. // // CustomURLSchemeHandler.m #import "CustomURLSchemeHandler.h" @implementation CustomURLSchemeHandler - (void)webView:(WKWebView *)webView startURLSchemeTask:(id<WKURLSchemeTask>)urlSchemeTask { NSURL *url = urlSchemeTask.request.URL; //NSString *filePath; NSString *filePath = [[NSBundle mainBundle] pathForResource:@"index" ofType:@"html" inDirectory:@"LoaclHtml.bundle/A4"]; if ([url.lastPathComponent hasSuffix:@".css"]) { filePath = [[NSBundle mainBundle] pathForResource:@"style" ofType:@"css" inDirectory:@"LoaclHtml.bundle/A4/css"]; } else if ([url.lastPathComponent hasSuffix:@".js"]) { filePath = [[NSBundle mainBundle] pathForResource:@"yourJSFileName" ofType:@"js" inDirectory:@"LoaclHtml.bundle/A4/js"]; } NSData *htmlData = [NSData dataWithContentsOfFile:filePath]; NSString *mimeType = [self mimeTypeForPath:filePath]; NSURLResponse *response = [[NSURLResponse alloc] initWithURL:url MIMEType:mimeType expectedContentLength:htmlData.length textEncodingName:@"utf-8"]; [urlSchemeTask didReceiveResponse:response]; [urlSchemeTask didReceiveData:htmlData]; [urlSchemeTask didFinish]; } - (void)webView:(WKWebView *)webView stopURLSchemeTask:(id<WKURLSchemeTask>)urlSchemeTask { } - (NSString *)mimeTypeForPath:(NSString *)path { NSString *fileExtension = [path pathExtension]; if ([fileExtension isEqualToString:@"html"]) { return @"text/html"; } else if ([fileExtension isEqualToString:@"css"]) { return @"text/css"; } else if ([fileExtension isEqualToString:@"js"]) { return @"application/javascript"; } else if ([fileExtension isEqualToString:@"png"]) { return @"image/png"; } else if ([fileExtension isEqualToString:@"jpg"] || [fileExtension isEqualToString:@"jpeg"]) { return @"image/jpeg"; } else if ([fileExtension isEqualToString:@"gif"]) { return @"image/gif"; } return @"application/octet-stream"; } @end code-block

We have a SAML-based SSO App Extension that uses WKWebView to load the SAML login request. This implementation has been working correctly on iOS versions prior to 26. However, starting with iOS 26, the extension consistently crashes when calling WKWebView.load(_:). The crash occurs inside WebKit, specifically in: /Library/Caches/com.apple.xbs/Sources/WebKit/Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp at WebKit::WebPageProxy::loadRequest(...) No app-level exception is thrown, and the extension terminates with: Thread 10: EXC_BREAKPOINT (code=1, subcode=0x1a31dbe00) It appears that WKWebView initialization or WebsiteDataStore creation is now restricted in extension contexts on iOS 26, but this change is not documented in the SDK release notes. Could you please confirm if this is an intentional sandbox restriction in iOS 26 or a regression in WebKit? Steps to reproduce: Implement an App Extension using ASAuthorizationProviderExtensionAuthorizationRequest. Create a WKWebView instance in the extension. Attempt to load a SAML login request (POST request with headers). Observe immediate crash on iOS 26 (works fine on earlier versions). Expected behavior: WKWebView should load the request or fail gracefully as in prior releases, without crashing the extension process. Request: Please clarify if WKWebView usage inside extensions is officially unsupported as of iOS 26, and if so, recommend an alternative approach for handling SSO flows.

We are experiencing a compatibility issue with our hybrid app related to the recent update in iPadOS 18.4, specifically concerning HTTPS connections. What are the key changes introduced in iPadOS 18.4 regarding HTTPS connections? Our app previously managed to bypass the DigitalSignature key usage missing error in the self-signed server certificate within the didReceiveAuthenticationChallenge method, as documented here: https://developer.apple.com/documentation/webkit/wknavigationdelegate/webview(_:didreceive:completionhandler:) . However, since the update to iPadOS 18.4, this method is no longer being called, resulting in direct failure of HTTPS connections. We are using cordova-ios 7.1. Thanks in advance for your help.

Hello, my application experiences crashes related to JavaScriptCore in iOS 17 and 18. I would like to consult about potential causes, to determine whether it is a bug in JavaScriptCore or an issue with my code implementation. First, the crash stack always includes the call to JSC::MarkedBlock::aboutToMarkSlow(unsigned int). In the iOS 17 version, the crash occurs on this line, typically JSC::MarkedBlock::aboutToMarkSlow(unsigned int) + 88. In iOS 18 and later, the stack crashes atJSC::MarkedBlock::dumpInfoAndCrashForInvalidHandle(WTF::AbstractLocker&, JSC::HeapCell*). I checked the source code of JavaScriptCore for both iOS 17.6 and iOS 18.2 and observed modifications in the implementation of aboutToMarkSlow. My question is under what circumstances could this crash occur? crash.log I have attached a crash log encountered in iOS 18, hoping you can provide more effective information for problem diagnosis, especially since there are specific details worth noting near the crash registers. INVALID HANDLE: MarkedBlock = 0x141158000; heapCell = 0x14115bfa0; type = 0 INVALID HANDLE: found 24 0s at beginning of block INVALID HANDLE: block in another VM: 1, block in another VM: 1; other VM is 0x1324b6000 Moreover, in iOS 18.4, due to the implementation of dumpInfoAndCrashForInvalidHandleV2, the message has changed to: INVALID HANDLE 587: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=0; totalzeros=0; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0; INVALID HANDLE 606: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0; INVALID HANDLE 615: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=1; isBlockInDir=1; foundInBlockVM=0; (Further INVALID HANDLE messages follow the same format) I hope this provides you with more information.

Starting in iOS 26 (tested on 26.1), when I use any of the “policy” methods of WKNavigationDelegate to return an action policy of cancel I get a trace like this printed to console: 1 0x18de71bbc WebKit::WebFramePolicyListenerProxy::ignore(WebKit::WasNavigationIntercepted) 2 0x18db3dd50 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)::$_0::operator()(WKNavigationActionPolicy, WKWebpagePreferences*) 3 0x100189e5c $sSo24WKNavigationActionPolicyVIeyBhy_ABIeghy_TR 4 0x100189d38 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctF 5 0x100189df4 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctFTo 6 0x18db255c0 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&) 7 0x18dea9848 WebKit::WebPageProxy::decidePolicyForNavigationAction(WTF::Ref<WebKit::WebProcessProxy, WTF::RawPtrTraits<WebKit::WebProcessProxy>, WTF::DefaultRefDerefTraits<WebKit::WebProcessProxy>>&&, WebKit::WebFrameProxy&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&) 8 0x18dea7a34 WebKit::WebPageProxy::decidePolicyForNavigationActionAsync(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&) 9 0x18d9cbbf4 void IPC::handleMessageAsync<Messages::WebPageProxy::DecidePolicyForNavigationActionAsync, IPC::Connection, WebKit::WebPageProxy, WebKit::WebPageProxy, void (IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)) 10 0x18d9c7728 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 11 0x18e49a0d8 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) 12 0x18df1908c WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&) 13 0x18d9dfc28 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 14 0x18e47f72c IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) 15 0x18e47fac4 IPC::Connection::dispatchIncomingMessages() 16 0x199ad3758 WTF::RunLoop::performWork() 17 0x199ad4eb0 WTF::RunLoop::performWork(void*) 18 0x1804563a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 19 0x1804562ec __CFRunLoopDoSource0 20 0x180455a78 __CFRunLoopDoSources0 21 0x180454c4c __CFRunLoopRun 22 0x18044fcec _CFRunLoopRunSpecificWithOptions 23 0x1926be9bc GSEventRunModal 24 0x18630f0d8 -[UIApplication _run] 25 0x186313300 UIApplicationMain 26 0x18554ac38 block_destroy_helper.15 27 0x10018a70c $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ 28 0x10018a67c $s16WebkitPolicyTrap11AppDelegateC5$mainyyFZ 29 0x10018a818 __debug_main_executable_dylib_entry_point 30 0x1000cd3d0 29 dyld 0x00000001000cd3d0 start_sim + 20 31 0x1002bab98 30 ??? 0x00000001002bab98 0x0 + 4297829272 This doesn’t happen in 18.6. Also, it doesn’t seem to have any negative consequences other than the console spam? But then, the navigation is being cancelled anyway, so maybe it’s trapping and just happens to have the effect of not loading the request? Anyway, I guess I can’t upload zips. But it’s pretty easy to reproduce. Just assign a WKWebView a navigationDelegate with an implementation like: func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, decisionHandler: @escaping @MainActor (WKNavigationActionPolicy) -> Void) { decisionHandler(.cancel) } and then have it .load() anything. Have I been doing this wrong and 26 exposes it? Or is this a bug in 26? If the latter, any downstream consequences I should be looking out for? macOS 15.7.1 (24G231) Xcode 26.1.1 (17B100) iOS 26.1 (23B86)

Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. During user testing we found that the tab title and tab URL properties are empty when obtaining the set of open windows via windows.get() after a Safari restart. We are testing with Safari 18.4 (20621.1.15.11.10). We have made a TestFlight version of our app and extension available to help with testing: https://testflight.apple.com/join/Va8Zdv9d. Screenshot and screen recording are attached to the Feedback ID supplied below. STEPS TO REPRODUCE Install Tabby via the TestFlight link Enable the Tabby for Safari extension in the Safari extensions dialog Grant permissions for Tabby for Safari to all windows all the time Within Safari, open two windows each with at least two tabs Within the Tabby app, ensure you see the windows and tabs listed correctly (tab title displayed for each) Quit and restart Safari Expected behavior Safari re-opens existing windows and Tabby displays title for each tab Observed Safari re-opens existing windows but within Tabby all tabs except the current tab are displayed with a title of “Start Page”. Under the hood the tab title and tab URL properties are empty when returned via a windows.get() call after Safari restarts. NAME AND APPLE ID OF APP Tabby - Browser Tab Manager 1586203406 FEEDBACK ASSISTANT ID FB16389506