Our app connects to the headend to get a IDP login URL for each connection session, for example: “https://myvpn.ocwa.com/+CSCOE+/saml/sp/login?ctx=3627097090&acsamlcap=v2” and then open embedded webview to load the page. (Note: the value of ctx is session token which changes every time). Quite often the webview shows blank white screen. After user cancel the connection and re-connect, the 2nd time webview loads the content successfully. The working case logs shows: didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called twice didReceiveAuthenticationChallenge is called decidePolicyForNavigationResponse is called didReceiveAuthenticationChallenge is called But the failure case shows: Filed to terminate process: Error Domain=com.apple.extensionKit.errorDomain Code=18 "(null)" UserInfo={NSUnderlyingError=0x11461c240 {Error Domain=RBSRequestErrorDomain Code=3 "No such process found" UserInfo={NSLocalizedFailureReason=No such process found}}} didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called decidePolicyForNavigationResponse is called If we stop calling evaluateJavaScript code to get userAgent, the blank page happens less frequently. Below is the code we put in makeUIView(): func makeUIView(context: Context) -> WKWebView { if let url = URL(string: self.myUrl) { let request = URLRequest(url: url) webview.evaluateJavaScript("navigator.userAgent") { result, error in if let error = error { NSLog("evaluateJavaScript Error: \(error)") } else { let agent = result as! String + " " + self.myUserAgent webview.customUserAgent = agent webview.load(request) } } } return self.webview } Found some posts saying call evaluateJavaScript only after WKWebView has finished loading its content. However, it will block us to send the userAgent info via HTTP request. And I don’t think it is the root cause since the problem still occurs with less frequency. There is no problem to load same web page on Windows desktop and Android devices. The problem only occurs on iOS and macOS which both use WKWebview APIs. Is there a bug in WKWebview? Thanks, Ying

Despite using the iPad in landscape mode, self-camera video is forced to portrait (Rotate 90 degrees). Only the video is portrait, even though the browser is in landscape orientation. Our app use getUserMedia() to get the video. The problem also happend in iPad Safari GoogleMeet. Details: The problem occurs even when the screen orientation is locked. After the video has been forced to portrait, rotating the iPad temporarily changes the video to landscape, but forces it to portrait again. It takes around 0 - 30 seconds before the video is forced to portrait. Both selfie camera and back camera I have confirmed this problem on the following devices iPad 8th iPadOS: 18.3.1 iPad10th iPadOS:18.3.1 iPadPro(M4) iPadOS:18.3.1 Some devices do not have this problem, even if they are the same model and OS version. I have tried the following restart factory reset Configuration changes (Settings > Apps > Safari) SETTINGS FOR WEBSITES Camera > Allow, Ask Microphone > Allow, Ask Advanced ＞ Feature Flags Reset All to Defaults Screen Orientation API (Locking / Unlocking) Screen Orientation API WebRTC AV1 codec Please help me to resolve this problom. Thanks.

PLATFORM AND VERSION iOS Development environment: Xcode 16.2, macOS 15.3.2 Run-time configuration: iOS 15-18 This happens in iOS, and leads to to the hybrid home page showing users as wrongly unauthenticated, since the at cookie is missing. For context, we have a JWT token that is stored in the Keychain, and on app launch, before any WKWebViews are created, we synchronize this to the WKWebsiteDataStore as an at cookie. We have analytics instrumentation on our websitef to show that WKWebView randomly refuses to send out any cookies. – The following is a snippet from an explanation to the WebKit Slack: We are having an issue on iOS, in which WKWebView loads pages (and even subsequent reloads) without any cookies, even though we have stored cookies in WKWebsiteDataStore.default() before hand right after application launch and becoming a key window. We reference this object, store it as a singleton, (as well as a process pool), and then all webview configurations are initialized with the same data store, the same process pool, every call on the main thread. From reading the source code, it seems that if the internal IPC logic fails, the APIs for deleting and setting data records and cookies fail without any feedback in completion handlers. This bug often happens when returning from the background on iOS after a few hours. Sometimes it happens on cold launches of the app. We have mitigated a similar issue (no cookies being sent) by implementing webViewWebContentProcessDidTerminate and reloading the webview ourselves, we found that whatever webview does to reload if that method is not implemented leads to cookies not being used. There have been multiple reports of WKWebView losing cookies in recent iOS versions, and we have tried to implement all of the workarounds listed. Setting a maximumAge to the cookies we store, and doing a _ = await websiteDataStore.dataRecords(ofTypes: Set([WKWebsiteDataTypeCookies])) before accessing or modifying websiteDataStore.httpCookieStore Question: is it safe to work with WKWebsiteDataStore before a WKWebView is added as a view, if so are there any timing considerations? Are there any logs that we can take a look at, this issue is very hard to reproduce, about 2% of our users face it at scale? Is there anything that could be happening within our process (runloop issues, timing) that could be causing this issue? See multiple reports from other companies that have faced the issue: "Now the Thermonuclear Problem with WKWebViewDataStorage" https://medium.com/axel-springer-tech/synchronization-of-native-and-webview-sessions-with-ios-9fe2199b44c9 STEPS TO REPRODUCE They don't exist, because the issue only happens at scale. We just know that no cookies are sent for a small percentage of requests. We believe this to be an issue in which Webkit fails to communicate internally with whatever IPC mechanisms it has. We have not been able to reproduce this issue consistently. The best we can give is that it happens after a few hours that the app is in the background. This happens regardless of whether the WKWebsiteDataStore is persistent or not, but seems to be much worse when it is persistent. Thus we have disabled persistnet data stores and relied on nonPersistent. The issue is bad enough that we are trying to move away from relying on cookies for iOS and just use request headers which we can only set on the top level request of WKWebView. DTS Case-ID: 13154329

We are encountering an issue where the Safari extension we are developing stops working while in use on relatively new iOS versions (confirmed on 17.5.1, 17.6.1, and 18). Upon checking the Safari console, the content script is displayed in the extension script, so the background script or Service Worker must be stopping. The time until it stops is about 1 minute on 17.5.1 and about one day on 17.6.1 or 18. When it stops, we would like to find a way to restart the Service Worker from the extension side, but we have not found a method to do so yet. To restart the extension, the user needs to turn off the corresponding extension in the iPhone settings and then turn it back on. As mentioned in the following thread, it is written that the above bug was fixed in 17.6, but we recognize that it has not been fixed. https://forums.developer.apple.com/forums/thread/758346 On 17.5.1, adding the following process to the background script prevents it from stopping for about the same time as on 17.6 and above. // Will be passed into runtime.onConnect for processes that are listening for the connection event const INTERNAL_STAYALIVE_PORT = "port.connect"; // Try wake up every 9S const INTERVAL_WAKE_UP = 9000; // Alive port var alivePort = null; // Call the function at SW(service worker) start StayAlive(); async function StayAlive() { var wakeup = setInterval(() => { if (alivePort == null) { alivePort = browser.runtime.connect({ name: INTERNAL_STAYALIVE_PORT }); alivePort.onDisconnect.addListener((p) => { alivePort = null; }); } if (alivePort) { alivePort.postMessage({ content: "ping" }); } }, INTERVAL_WAKE_UP); } Additionally, we considered methods to revive the Service Worker when it stops, which are listed below. None of the methods listed below resolved the issue. ① Implemented a process to create a connection again if the return value of sendMessage is null. The determination of whether the Service Worker has stopped is made by sending a message from the content script to the background script and checking whether the message return value is null as follows. sendMessageToBackground.js let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { // If infoFromBackground is null, Service Worker should have stopped. browser.runtime.connect({name: 'reconnect'}); // ← reconnection process // Sending message again infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; Background script browser.runtime.onConnect.addListener((port) => { if (port.name !== 'reconnect') return; port.onMessage.addListener(async (request, sender, sendResponse) => { sendResponse({ response: "response form background", message: "reconnect.", }); }); ② Verified whether the service worker could be restarted by regenerating Background.js and content.js. sendMessageToBackground.js export async function sendMessageToBackground(sendParam) { let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { executeContentScript(); // ← executeScript infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; } async function executeContentScript() { browser.webNavigation.onDOMContentLoaded.addListener((details) => { browser.scripting.executeScript({ target: { tabId: details.tabId }, files: ["./content.js"] }); }); } However, browser.webNavigation.onDOMContentLoaded.addListener was not executed due to the following error. @webkit-masked-url://hidden/:2:58295 @webkit-masked-url://hidden/:2:58539 @webkit-masked-url://hidden/:2:58539 ③ Verify that ServiceWorker restarts by updating ContentScripts async function updateContentScripts() { try { const scripts = await browser.scripting.getRegisteredContentScripts(); const scriptIds = scripts.map(script => script.id); await browser.scripting.updateContentScripts(scriptIds);//update content } catch (e) { await errorLogger(e.stack); } } However, scripting.getRegisteredContentScripts was not executed due to the same error as in 2. @webkit-masked-url://hidden/:2:58359 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58549 @webkit-masked-url://hidden/:2:58549 These are the methods we have considered. If anyone knows a solution, please let us know.

When I open com. apple. developer. web browser, I am unable to inject JavaScript into the webview through methods such as addUserScript. The console will prompt 'ignoring user script injection for non app bound domain'

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.

Seeing an issue in some versions of Safari (16.6, 18.3, 18.5) where an APNG converted to AVIF does not support transparency. Instead of a transparent background, the background is filled with black.

Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content. The EPUB content format is XHTML and uses namespaces (for the epub:type declaration). On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace: 0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968 1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940 2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984 3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708 4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636 5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304 6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268 7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488 8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52 9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228 10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268 I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html> I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not. It happens on iOS, macOS, and iPadOS. This has never been a problem in any earlier release of macOS / iOS.

It seems that in iOS 18.5+ built with Xcode 16.4+, there has been a breaking change since 18.4 with 16.3 within WebKit and how the navigationAction.sourceFrame property is initialized when implementing the decidePolicy delegate method. The flow goes: Implement a WKNavigationActionDelegate with decidePolicy Call WKWebView.loadHTMLString("some-string", baseURL: nil) Upon loading the HTML content, read the value of navigationAction.sourceFrame within the decidePolicy method of the WKNavigationActionDelegate On iOS 18.4 (and below) with Xcode 16.3 (and below); navigationAction.sourceFrame is <uninitialized> On iOS 18.5+ with Xcode 16.4+: navigationAction.sourceFrame is already initialized and is equal to navigationAction.targetFrame It appears that this change was made between minor versions of Xcode and is unexpected behavior of a minor version. Not only was this not called out in the release notes for Xcode 16.4 and iOS 18.5, but it's technically also a breaking change to the WebKit API. Can we get insight on why this change was made and what Apple's policy is on breaking changes between minor versions of Xcode/iOS?

Hello, I'm not able to get the webauthn attestation statement using the option (attestation.direct) on Safari. The answer I get is a fmt of none and a aaguid of zeros. The same code works on Chrome and I was able to get a none zero aaguid and a packed fmt attestation. Can you explain why this does not work on Safari ? Thank you.

Hello everyone, I am currently working on integrating a WebView into my macOS application, intended to allow users to browse tutorial webpages directly within the app. Although I’ve followed an example that appears syntactically correct, the WebView does not render any webpage content. Below is a code snippet for reference: import SwiftUI import WebKit struct HelpWebView: View { @State private var toggle = false @State private var page = WebPage() private var url: URL { toggle ? URL(string: "https://www.webkit.org")! : URL(string: "https://www.swift.org")! } var body: some View { WebView(page) .onAppear { page.load(URLRequest(url: url)) } .onChange(of: toggle) { page.load(URLRequest(url: url)) } .toolbar { Button("Reload", systemImage: "arrow.clockwise") { toggle.toggle() } } } } I would greatly appreciate any insights or suggestions on what might be causing this issue or how to resolve it. Thank you in advance for your help!

I am using the native SwiftUI WebView and WebPage APIs (iOS 26+) and would like to implement file download functionality using the native SwiftUI WebView. However, I have not been able to find any APIs equivalent to WKDownload. In WKWebView, the WKDownload API can be used to handle downloads. I am looking for a similar API or recommended approach in the native SwiftUI WebView that would allow downloading files. If anyone has guidance or suggestions on how to implement this, I would appreciate your help.

Dear Apple Developer Support, We are currently developing a system that requires the ability to edit Japanese vertical text within the Safari browser on iPhone. During our investigation, we encountered an issue that matches the following WebKit bug: 283620 – Caret Positioning Issues in Vertical Writing Mode We understand that this issue is being addressed in the following pull request: https://github.com/WebKit/WebKit/pull/39939 However, it appears that a complete fix has not yet been implemented. Given this situation, we would like to confirm the following: Is there any known workaround for this issue in iOS 17.5 or iOS 18.5 (the latest versions as of now)? If a workaround exists, could you please provide details? If not, could you share the expected timeline for a full resolution of this issue? Although this appears to be an open-source WebKit issue, we are reaching out to Apple because WebKit is tightly integrated with iOS and Safari, and ultimately delivered as part of the iPhone experience. Thank you very much for your support. Best regards, Takao Kurabayashi

Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2

In WKWebView, there is the WKUIDelegate method: func webView(_ webView: WKWebView, createWebViewWith configuration: WKWebViewConfiguration, for navigationAction: WKNavigationAction, windowFeatures: WKWindowFeatures) -> WKWebView? {} This delegate method provides a callback when a new window (for example, target="_blank") is requested in the web view. However, in native SwiftUI (iOS 26), WebView / WebPage APIs do not provide an equivalent delegate method to handle new window requests. As a workaround, I am using the following method: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy {} In this method, when action.target == nil, I treat it as a new window request. My question: Is relying on action.target == nil in decidePolicy a reliable and future-safe way to detect new window requests in SwiftUI’s WebView, or is there a better or more recommended approach for handling target="_blank" / new window navigation in the SwiftUI WebView APIs? Code: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy { guard let webPage = webPage else { return .cancel } // Handle case where target frame is nil (e.g., target="_blank" or window.open) // This indicates a new window request if action.target == nil { print("Target frame is nil - new window requested") // WORKAROUND: Until iOS 26 WebPage UI protocol is available, we handle new windows here // Try to create a new WebPage through UI plugins if handleCreateWebPage(for: webPage, navigationAction: action) != nil { // Note: The new WebPage has been created and published to the view return .allow } } return .allow }

Hi! I configure proxy for webview like DispatchQueue.main.async { self.webView.configuration.websiteDataStore.proxyConfigurations = [proxyConfiguration] } It is fine in iosiOS 17 however, it crashes in iOS 18.3. And the problem seems to be related to the left side of the equation. I tried to call print(self.webView.configuration.websiteDataStore.proxyConfigurations.count) in async block and got the same bad access error. But if stop at that line of code and call po self.webView.configuration.websiteDataStore.proxyConfigurations in debugger it returns 0 elements. Did anyone have the same problem? What may cause the exception?

I recently upgraded my device from IOS 18.4 to IOS 26. My web extension has disapeared from safari. I can see it in Settings > Apps > Safari > Extensions and when I turn it on and re-open safari. I just get a mesasge that says "{extension name} is no longer avaiable". I have tried Manifest V2 and Manifest V3 both yield the same results. The current production extension bundled with the IOS app has the same problem. I can no longer use or test my own extension !? Help please !

We’re seeing an issue in our Safari Web Extension where not all cookies from the Set-Cookie response header are accessible. We are using macOS 15.4 and Safari 18.4. In the webRequest.onHeadersReceived callback, the Set-Cookie header returned by Safari only includes some of the cookies set by the server. If multiple Set-Cookie headers are present, we seem to receive only a partial list, some cookies are missing entirely. In Chrome and Firefox, the same callback provides all cookies set by the server without issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

When I open the browser in Safari on iOS 26, I want to specify the background color for the header notch (where the time, battery, etc. are displayed) and the footer indicator area. Specifying the theme color in HTML as shown below did not change anything. <meta name="theme-color" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000"> The HTML below specifies the background color as green, but is it necessary to specify the background color directly in the body like this? Or is there some kind of metadata, like theme color? <!doctype html> <html lang="ja"> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width,initial-scale=1" /> <meta name="theme-color" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000"> <title>サンプル</title> </head> <body style="background:#00ff00"> <main> <p>テキスト</p> </main> <div id="overlay" role="dialog" aria-modal="true" data-test-id="health-warning-modal" style=" color:#000000; position:fixed; inset:0; z-index:30000; background:#2563eb; display:grid; /* 初期表示：表示中 */ align-items:center; justify-content:center; overflow-y:auto; " > <div style=" padding:60px 16px; display:flex; flex-direction:column; gap:20px; width:100%; box-sizing:border-box; " > <p style=" font-weight:700; text-align:center; margin-top:20px; font-size:28px; line-height:1.4; " > オーバーレイ </p> </div> </div> </body> </html>

It seems fetch() does not include credentials (cookie) even when credentials: include is used and Safari extension has host_permissions for that domain when using from a non-default Safari profile. It includes credentials (cookie) when using from the default profile (which has the default name Personal). Is there anyone who has this problem? I try to request in popup.js like this: const response = await fetch( url, { method: 'GET', mode: 'cors', credentials: 'include', referrerPolicy: 'no-referrer', } ); and it does not include the credentials (cookie) from host_permissions. I already posted https://developer.apple.com/forums/thread/764279, and opened feedback assistant (FB15307169). But it is still not fixed yet. (macOS 15.4 beta 3) I hope this is fixed soon.