Since iPadOS 18.x WKWebView seems to have a bug within its Fullscreen API (which can be enabled via WKPreferences.isElementFullscreenEnabled). This bug has the effect that websites trying to make an element (for example a video player) fullscreen fail to do so. This does not always happen, most of the time the fullscreen mode does work fine, but sometimes (far too often to be ignored) it does not. If an instance of WKWebView shows this issue, it can not be "fixed" by reloading the page or loading other pages, this issue exists in this instance forever. My App is a web browser App so I can create and remove WKWebView instance easily (by opening or closing Tabs). And there are times where I never see this bug, and times where ever other tab shows this bug. It's totally unreliable. The App does not show any issues at all when running under iPadOS 17 or older. The issue is only present under iPadOS 18.x. After some testing I've found out that when the bug has affected an instance of WKWebView, the JavaScript call element.requestFullscreen() will work if the element is a video element, but does no longer work if it is another element (like a DIV). If an instance of WKWebView is not affected by this bug, element.requestFullscreen() will work for all HTML elements. Does anyone has experienced this bug as well? And maybe found a workaround? Or maybe found a pattern which helps to find out what exactly is triggering this bug?

Safari 18.0.1 on macOS 15.01 doesn't support the Passkey PRF extension during cross-device WebAuthn authentication when using QR code scanning, while it works correctly with iCloud passkeys. Steps to Reproduce: Clone and setup: git clone https://github.com/quocle108/passkey-prf-test yarn yarn start Test iCloud Passkey Flow: Open http://localhost:3000 in Safari Open DevTools (Cmd+Option+I) Click "Register" Choose "Passkey on iCloud" Expected console output: PRF supported: true Test Cross-Device Flow: Click "Register" Choose "Phone/Tablet" Scan QR with mobile device Expected: PRF supported: true PRF extension should be supported in cross-device flow, matching iCloud passkey behavior. Actual: PRF supported: false Cross-device flow returns empty extension results. Verify in Chrome Repeat steps 2-3 in Chrome Both flows return proper PRF extension results: PRF supported: true Test Environment: Browser: Safari 18.1.1 , Chrome 131.0.6778.70 OS: macOS 15.01 Mobile: iOS 18.x / Galaxy Note9 Android 10 Test repo: https://github.com/quocle108/passkey-prf-test

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.

Test Scenario: Initial Setup: Register a passkey on Chrome (MacBook) with cross-platform option The passkey syncs to iPhone via iCloud Both devices share same iCloud account Authentication Tests: Chrome on MacBook: Using hybrid transport (QR code with iPhone) → PRF output A Using platform authenticator → PRF output B (different) Safari on MacBook: Only uses platform authenticator → PRF output B Expected Behavior: When using same credential ID and salt, PRF output should be consistent across browsers/devices

The app I work on uses WKWebView to render customer data. In iPadOS 26, we observe that there is a delay when resizing the window (and thus the web view) before the content is re-rendered. The same behavior is visible in Safari. For demonstration purposes, consider this test page: https://phet-dev.colorado.edu/html/build-an-atom/0.0.0-3/simple-text-only-test-page.html Initially, the window is small: Then when the window is expanded, the content scales up temporarily: It eventually re-renders to the correct size, but then if you make the window small again, you get (temporarily): Is there anyway around this behavior? We would love to have the content reflow interactively.

This is problematic when opening links to other websites that require separate authentication. A typical example would be a Gmail web app, and then trying to open a link to a GitHub PR. In the 18.0 release notes, this is mentioned as Added support for opening links directly in web apps on macOS. (113034778 It'd be great if this could be customizable so that one could choose the old behavior.

We are seeing network errors in Outlook mail on iOS and MacOS safari browsers. As per current investigation, we notice these network error when the user tries to use outlook after leaving it open on Safari for a while. Observations: Issue present in both MacOS and iOS safari. Issue is not present in other webkit browsers like brave and edge on iOS. Issue is reproable on both mini and big owa on safari browser. Issue is not related to post requests being sent in different packets on safari browser. Requests are only blocked for outlook.office/outlook.live domains What does not fix this issue? Reloading the application Clearing cookie, local storage or session storage Unregistering service workers Redirecting to a different page and coming back to outlook domain Re authenticating the users What fixes this issue? Reconnecting to wifi or mobile network Reconnecting vpn Removing safari from background and reopening Flushing the dns in setting

There does not appear to be any way to use or create iCloud passkeys with a Safari Web Extension, either using the navigator.credentials API in an extension origin webpage such as the popover, or using the AuthenticationServices framework in the SafariWebExtensionHandler. I've setup an associated domain for my plugin, and I know it works for the host application. But I get errors trying to do so in the web extension target. createCredentialRegistrationRequests results in the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Application with identifier <ID> is not associated with domain <RPID> The other problem, assuming the entitlement works correctly for the web extension, is that there is no NSWindow to use as the presentation target from the SafariWebExtensionHandler. Trying to use the navigator.credentials.create JS API (which is the preferred method, frankly, in a web extension) results in the following error: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Chrome has a great solution for this that I believe should be adopted by Safari. If an extension has host permissions for a relying party it wants to claim, or if it has an associated domain entitlement for it, webauthn operations should be allowed.

We have an ObjC-based Mac App utility. A fair fraction of the functionality is built in JavaScript and resides in a couple of WKWebViews so that we can more easily share code with other platforms. Because it is a utility, usually the application will be hidden or at least not the frontmost application. But if the user hits a hotkey or provides certain other inputs, the app should respond immediately with a series of actions. In the Obj-C part of the code, we can do this to alert the system that our non-visible, non-active, application is doing something in response to the user input: [[NSProcessInfo processInfo] beginActivityWithOptions: NSActivityUserInitiatedAllowingIdleSystemSleep reason: @"Do the Thing"] To get the JavaScript to do the work needed, we call evaluateJavaScript:completionHandler: on one of the WKWebViews. The JavaScript performs a series of computations, then uses window.webkit.messageHandlers.xxxx.postMessage to return results to the ObjectiveC code, which then takes action based on various SDKs, and the user sees the result. The problem we are encountering is relatively infrequent, but it appears that macOS puts the 'Web Content' process (which every WKWebView has) to sleep, and sometimes delays of many seconds (sometimes over 15 seconds) occur between the evaluateJavaScript:completionHandler: call and the postMessage response. These observed delays are not related to complexity of the JavaScript computations or the amount of data being processed. Using the Console, we can see that evaluateJavaScript:completionHandler: seems to result in this message: 0x104682280 - [PID=0, throttler=0x1046e8498] ProcessThrottler::Activity::Activity: Starting background activity / 'WebPageProxy::runJavaScriptInMainFrameScriptWorld' Then shortly afterward: 0x104682280 - [PID=0, throttler=0x1046e8498] ProcessThrottler::Activity::invalidate: Ending background activity / 'WebPageProxy::runJavaScriptInMainFrameScriptWorld' So it seems that evaluateJavaScript:completionHandler: "wakes up" the WKWebView similar to the beginActivityWithOptions:. But many parts of our computation do some work, then expect the next "tick" in JavaScript to continue using the partial result to produce more work. I suspect that the delays are related to the WKWebView being put "back to sleep" before all the "next tick" code executes. Because these actions are taken in response to user invocation, delays of more than a fraction of a second are instantly noticeable and result in user dismay. Are there any configuration settings that can prevent the 'Web Content' process from going to sleep? Or (better) techniques or mechanisms that would force the process to "stay awake longer"? (Keeping in mind that the WKWebView is likely not visible, and/or the containing window may be hidden.)

Hi, I'm developing a PWA and I'm experiencing a host of strange issues exclusively with Safari and push notifications, none of which happen with other browsers (Chrome, Firefox, Edge, other Chromium-based browsers). I've been testing primarily on mobile, so it may be (although it's unlikely) that desktop Safari behave differently. The most severe issue is that the indexedDB global is undefined when the service worker is awoken by a push notification. This completely breaks things. I've recently updated to iOS 18.1.1 and I've seen this issue only recently, so it may be related to an update. The notifications endpoint keeps changing and notifications are missed. This issue is weird to make sense of, but the gist of it is that, after restarting the app, registration.pushManager.getSubscription() will, seemingly incorrectly, give null, triggering a call (in our app) to registration.pushManager.subscribe, which will give entirely different subscription information. "Deleted" notification endpoints keep on working (POSTing to them will return 201), instead of returning an error like Google, Microsoft & Mozilla do. This is perhaps not a critical, but it does complicate things on the backend, as we have few meaningful ways of automatically removing these endpoints. This may be related to 2 in that the endpoint is "created" but "forgotten". Sometimes (quite often) pushing a push notification will not result in any notification on the device, even if the handler has debug code to always display a notification for incoming messages. The endpoint will return a 201 response code. I've added some logic to our server to send a push notification as soon as a new push endpoint is seen, and this notification is shown, so it's the "background" notifications that are somehow missed. Testing shows that this may be related to 2, as in instances where the endpoint remains consistent, notifications seem to be delivered. Notification permissions are displayed inconsistently depending on the API used. Notification.permission seems to have the correct value, but navigator.permissions.query seems to always return 'prompt', regardless of the actual permission status. As a corollary to this, the onchange listener never seems to fire on Safari when a permission change occurs. I've searched in this forum, the Web and the WebKit bug tracker, and haven't been able to find anyone else experiencing these issues, other than the inconsistency of querying permissions. I suspect these are WebKit bugs, but it may also be that things are being done in a sequence that is "wrong" for Safari, which is not documented anywhere. Like I said, things work well in all other browsers. I have code to share where the issues can be reproduced reliably, but I don't at the moment have a minimal example. I would appreciate any help or direction with these matters.

I have a question. In the file located at /Library/Preferences/com.apple.networkd.plist, if the dict entry for enable_unified_http is set to true or if the value is missing, there is an issue where the video player does not run on MacOS Sequoia Safari 18.0. I found that setting it to false allows it to function properly. Could you explain what this setting does and whether it is possible to change this setting to false within the app?

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!

Hi, I was implementing Apple pay button by checking active wallet and at least one cards active. I am using applePayCapabilities as per DOCS but i am still getting the same type of response with apple pay wallet enabled and without apple pay wallet enabled on different devices as Loading the Apple Pay SDK: script.src = "https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js"; script.crossOrigin = "anonymous"; document.head.appendChild(script); script.onload = function() { console.log("Apple Pay SDK loaded successfully"); // Initialize Apple Pay or perform actions that require the SDK here }; script.onerror = function() { console.error("Error loading Apple Pay SDK"); }; Calling applePayCapabilities method: window.ApplePaySession.applePayCapabilities("merchant.com.example").then(r => console.log(r)) Output: {paymentCredentialStatus: "paymentCredentialsAvailable"} Image attachments of applePayCapabilities: Devices Config Used:- Chip - Apple M3 Pro macOs - Sequoia 15.0.1 memory - 36 GB Safari Version - 18.0.1

Hello I built a WordPress website with a three.js/react front page. On iOS chrome, Android chrome, and desktop chrome all is working well. However, on Safari mobile when the animation loads a downward swipe causes the page to refresh rather than scroll as is intended and working correctly on all the other browsers. Strangely, scroll up works initially and then downward scroll begins to work. I have tried various iterations of overscroll behavior but still cannot aolbe the issue. Any help would be appreciated.

I'm developing an application that needs smooth framerates within a wkwebview that interacts with native code. However, requestAnimationFrame by default is still throttled to 60hz even if all my target devices (the iPad Pro for example) have supported 120hz for a long time already. I noticed that the latest Safari in 18.3 beta supports unlocked framerates, but that's only under Safari feature flags. To my knowledge, these flags do not apply to WKWebView. Is there a way to enable unlocked framerate in WKWebView via requestAnimationFrame? (Calling JS at a faster rate from the native code side will not work, almost definitely, since WKWebView will still render at its own rate.) This is an experimental application for internal use and I'm okay if there are temporary beta solutions available.

I am working Web to App flow for my product. Tolink to my app from web service, I define uri scheme from app and use it from my web site. But, when I try to use this scheme from mobile safari web, It sometimes failed with message that uri is invalid. That is weird It failed SOMETIMES not always Even I tried with same url. In my device, there is current version app. Why this happen? How can I resolve this issue?

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.

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.

How can I make a background image take the entire screen in ios26? I've tried position fixed, sticky, env() css variables but nothing worked. It does it when in PWA mode, but I would like to do so in the browser too.

Since iOS 18.1 launched as a beta, we've been getting reports from end users on iPhone 15 Pro and iPhone 15 Pro Max specifically. They're reporting that our WebView is unable to load our local HTML content. I'm curious if anyone else has had their app or users run into this issue? So far I've tried installing the most recent XCode Beta 16B5014f and installed an 18.1 emulator, but our app worked fine. It's also working fine on all my real devices, but we don't have a 15 Pro to test on. I'm curious if this is related to the processor on these devices and how they are intended to support Apple's new AI coming in 18.1.