ISAC Client is crashing on macOS 15.4 Beta 1 which is from from the WebKit engine the underlying framework of WKWebView. And the "ResourceLoadNotifier" is from WebKit's internal framework.It seems to be related to resource loading failure which is potentially triggered by changes in macOS 15.4 Beta.

Hi all! I have been working on a web speech recognition service using the Web Speech API. This service is intended to work on smartphones, primarily Chrome on Android and Safari (or WebKit WebView) on iOS. In my specific use case, I need to set the properties continuous = true and interimResults = true. However, I have noticed that interimResults = true does not always work as expected in WebKit. I understand that this setting should provide fast, native, on-device speech recognition with isFinal = false. However, at times, the recognition becomes throttled and slow, yielding isFinal = true and switching to cloud-based recognition. To confirm whether the recognition is cloud-based, I tested it by disabling the internet connection before starting speech recognition. In some cases, recognition fails entirely, which suggests that requiresOnDeviceRecognition = false is being applied. (Reference: SFSpeechRecognitionRequest.requiresOnDeviceRecognition) I believe this is not the expected behavior when setting interimResults = true. I have researched the native services used by the Web Speech API on iOS devices, and the following links seem relevant: • SFSpeechRecognizer • SFSpeechRecognitionRequest.shouldReportPartialResults • SFSpeechRecognizer.supportsOnDeviceRecognition • Recognizing speech in live audio • Apple Developer Forums Discussion I found that setRequiresOnDeviceRecognition and setShouldReportPartialResults appear to be set correctly, but apparently, they do not work as expected: WebKit Source Code

On iOS 18, when setting the src attribute of an tag to a custom scheme (e.g., myapp://image.png) or an HTTP URL (http://example.com/image.png), if crossorigin="anonymous" is applied, the image fails to load. Additionally, images affected by this issue cannot be drawn to a , as the browser treats them as tainted and blocks access to their pixel data. This issue did not occur in previous iOS versions and seems to be a regression in iOS 18. Steps to Reproduce: Open an HTTPS-hosted H5 page in Safari on iOS 18. Add an tag with crossorigin="anonymous" and set src to either: A custom scheme: <img src="myapp://image.png" crossorigin="anonymous"> An HTTP URL (even from the same origin): <img src="http://example.com/image.png" crossorigin="anonymous"> Observe that the image does not load. Attempt to draw the image onto a and retrieve its data: const canvas = document.createElement("canvas"); const ctx = canvas.getContext("2d"); const img = new Image(); img.crossOrigin = "anonymous"; img.src = "http://example.com/image.png"; // or "myapp://image.png" img.onload = () => { ctx.drawImage(img, 0, 0); try { console.log(canvas.toDataURL()); // Expect base64 image data } catch (error) { console.error("Canvas is tainted:", error); } }; Notice that the image is blocked, and any attempt to access pixel data results in a CORS error. Expected Behavior: * The image should be displayed if it is accessible under normal CORS rules. * The API should allow access to the image data unless explicitly blocked by the server’s CORS policy. Actual Behavior: The image fails to load when crossorigin="anonymous" is applied. The API does not allow access to the image data, treating it as tainted. Removing crossorigin="anonymous" allows the image to display in some cases, but this is not a viable workaround when CORS enforcement is required. Regression: Works correctly on: iOS 17 and earlier Broken on: iOS 18 Environment: Device: iPhone/iPad iOS Version: 18.0+ Browser: Safari Suggested Fix: Apple should investigate this regression and allow custom schemes and HTTP images to be correctly handled under CORS policies when crossorigin="anonymous" is set. If the source allows cross-origin requests, Safari should not block the image or its use in .

I am experiencing a critical issue with WKWebView navigation in iOS 18.2 beta, specifically regarding the function webView.loadFileURL(_:allowingReadAccessTo:). In previous versions of iOS, this function works as expected when loading valid file URLs from the app’s local directory (e.g., Application Support). However, in iOS 18.2 beta, the function fails to complete the navigation, producing a provisional navigation failure with WebKitErrorDomain, code 102 (Frame load interrupted). This issue severely impacts our app’s ability to load essential local resources, breaking core functionality. Here’s a summary of the troubleshooting steps and findings: File and Directory Verification: The url provided to loadFileURL is valid. Both the file path and parent directory exist within the app’s sandbox, and the directory is accessible. Configuration: The code specifies the parent directory in the allowingReadAccessTo parameter to meet sandboxing requirements, which works on iOS 18.1 and prior releases. Testing on Stable iOS Versions: The issue is exclusive to iOS 18.2 beta; testing on earlier stable iOS releases confirms that the function works as intended. Impact: This regression severely disrupts the app’s navigation and content loading, effectively blocking access to local resources required for the WKWebView to display content properly. The error log returned in the console is as follows: > Error Domain=WebKitErrorDomain Code=102 "Frame load interrupted" UserInfo={_WKRecoveryAttempterErrorKey=<WKReloadFrameErrorRecoveryAttempter: 0x303dd67e0>, NSErrorFailingURLStringKey=file:///var/mobile/Containers/Data/Application/4D128818-7E51-460E-B5D4-D2D70363EFA0/Library/, NSErrorFailingURLKey=file:///var/mobile/Containers/Data/Application/4D128818-7E51-460E-B5D4-D2D70363EFA0/Library/, NSLocalizedDescription=Frame load interrupted} We suspect this may be due to a change in WebKit permissions in iOS 18.2 beta that affects local file handling within WKWebView. Given that the our app relies heavily on these resources, we kindly request this issue be addressed promptly. If any additional information or sample code is required, please let us know, and we will gladly provide further details to assist in resolving this issue. Thank you for your attention and support. Best regards, Isabela