Bug Report:
Safari refuses to render content that is position: fixed or position: sticky if it goes below the iOS 26 navigation controls at the bottom of the browser. Since the controls are transparent and floating, this is a problem as fixed content is effectively unable to reach the bottom of the page. Attempting to move it below 100vh causes it to be cut off rather than rendering behind the navigation elements.
Here is some code reproducing the issue:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<style>
html,
body {
margin: 0;
padding: 0;
background-color: #363636;
}
#just-a-bird {
position: fixed;
bottom: -100px;
width: 300px;
height: auto;
background: red;
}
</style>
</head>
<body>
<img id="just-a-bird"
src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Cattle_tyrant_%28Machetornis_rixosa%29_on_Capybara.jpg/640px-Cattle_tyrant_%28Machetornis_rixosa%29_on_Capybara.jpg">
</body>
</html>
Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hello all,
As you may know, the company ProofPoint is an Apple partner, and is engaged (I think) to reduce misuse of icloud emails.
We have two servers solely set up for our web-app, which is a specialised forum for apartment owners.
The new servers were established about the same time, with the same provider, with clean new IP addresses - and as mentioned above, are only used for this web-app.
During a testing phase a YEAR ago, we became aware that our in-house icloud emails weren't receiving notifications via the app, and further investigations revealed that the cause was that ProofPoint had placed a block on that server's IP.
We immediately, via their website form initiated a Support Ticket, which, the site indicated was lodged, BUT we have never received any response to that Ticket, nor have we received any response to four subsequent Tickets we initiated - nothing. In over a year!!
Yesterday, we contacted Apple support, but the devices area of support is the main section and they said it wasn't an issue they could assist with.
Some relevant matters:
SPF: DKIM: DMARC:
are, I believe all configured correctly (and Gmail gives a PASS to all of them).
The IP is not blacklisted by any list we are aware of.
Our other server's IP isn't blocked by ProofPoint.
So, literally at wits end, I'm reaching out to the developer subscribers here to see if they have any suggestions for us.
We currently are unable to accept any new subscriber that is using an icloud email address, and that's an absurd situation to be in.
Surely we don't have to go to the trouble and inconvenience of obtaining a new IP because of this!!! But when we can't get ANY response to the Support Tickets, it's really hard.
Thanks
Topic:
Safari & Web
SubTopic:
General
For many years, I've noticed that although in native code I can handle continuous and simultaneous Apple pencil and touch inputs using UIKit, Safari and WKWebView's PointerEvents only seem to allow you to use one input type at a time. i.e. Apple Pencil down blocks touch input until lifted and touch input blocks Apple Pencil input. It's as though requiresexclusivetouchtype has been set in the underlying webkit implementation. There's decades of research (e.g. https://dl.acm.org/doi/10.1145/1866029.1866036 ) and several existing native applications in production showing that multimodal inputs open-up many unique and useful applications and interactions. Even a simple "hold object with finger" + "draw with stylus" controls are the norm. I recently built a native application using multimodal simultaneous inputs, but this is impossible to port to web due to the unexpected behavior of PointerEvents (and touch events, and mouse events; any variant exhibits the same behavior). I've researched and attempted to apply every possible flag, change, and css code to get this working, but I think the behind-the-scenes implementation is what's blocking the simultaneous touch types.
This is unexpected and undesired behavior because it's inconsistent with the native behavior. If it's unintended, it's a big priority to fix for creating better user experiences on the iPad. If it's intended, I do not believe that's reasonable (even if it might be more complex and used for more advanced applications). Please expose a way to support simultaneous touch types in iPadOS/iOS in both Safari and WKWebView.
At minimum, may we have a discussion on how to support the desired behavior? The simplest solution I can think of is to provide a webkit-platform-specific boolean in Safari and WKWebView called requiresExclusiveTouchType, which is set to False by default to keep the current behavior, and settable to True to get the more flexible behavior I'm expecting.
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.
Hello,
In iOS 26 beta, we are seeing an unexpected behavior when using SwiftUI WebView (or a custom WKWebView via UIViewRepresentable).
When an alert is presented above the WebView, the WebView immediately reloads to its initial page. The alert itself also disappears instantly, making it impossible for the user to interact with it.
This issue occurs both with the new SwiftUI WebView / WebPage API and with a wrapped WKWebView. The problem was not present in previous iOS versions (iOS 17/18).
Steps to reproduce:
Create a SwiftUI view with a WebView (pointing to any URL).
Add a toolbar button that toggles a SwiftUI alert.
Run the app on iOS 26 beta.
Tap the button to trigger the alert.
Expected behavior:
The WebView should remain as-is, and the alert should stay visible until the user dismisses it.
Actual behavior:
As soon as the alert appears, the WebView reloads and resets to the initial page. The alert disappears immediately.
Minimal Example:
struct ContentView: View {
@State private var showAlert = false
var body: some View {
NavigationStack {
WebView(URL(string: "https://apple.com")!)
.toolbar {
ToolbarItem(placement: .topBarTrailing) {
Button("Close") {
showAlert = true
}
}
}
.alert("Confirm close?", isPresented: $showAlert) {
Button("Cancel", role: .cancel) {}
Button("Close", role: .destructive) {}
}
}
}
}
I'm using Xcode Version 26.0 beta 7
Thanks for your help.
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
Topic:
Safari & Web
SubTopic:
General
On iOS 18 only, I've been getting this error from the didFailToContinueUserActivityWithType in AppDelegate, the activity needed for universal links. It didn't happen on previous versions of it.
Has anyone encountered this ?
We’re encountering an issue when trying to add non-standard headers to outgoing requests using Declarative Net Request (DNR) rules in our Safari Web Extension.
Tested on macOS 15.4 with Safari 18.4.
Specifically, when attempting to add a custom header such as "X-Custom-Header" using a DNR rule, the header does not appear in the request. We are able to add standard headers like "Authorization" and "Cookie" to the request successfully using the same method.
This behavior suggests that Safari may be filtering or blocking non-standard headers when set via DNR rules, unlike other browsers.
In Chrome and Firefox, the same rule adds the "X-Custom-Header" header without any 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.
Hello,
I am experiencing an issue when trying to open the browser on my Apple Watch SE 2 running the latest version, watchOS 11.6. When I attempt to visit any website, the browser opens and displays the URL at the top as if it is loading, but the screen remains black and no content is displayed.
The internet connection is available, and all other apps on the watch work normally. This issue occurs only with the browser.
I would appreciate any guidance or solution to resolve this problem.
Thank you for your assistance.
I'm building a macOS Google Chrome extension.
I need to be able to send messages from the Chrome extension to the macOS app
What's the set up flow?
I've heard about native messaging, but I struggle to implement it.
I've heard about XPC, but not sure JS can send messages to a macOS XPC service.
I reported this bug one year ago in https://developer.apple.com/forums/thread/746406, but as it is not been fixed yet, I'm going to try by opening this new incident report.
iOS is not working for the Unicode Variation Selector-15 (U+FE0E) for all the characters.
Can you please apply that variation selector to all your Unicode characters?
I) Steps to reproduce the issue:
navigate in safari to the page https://eurovot.com/vs.htm
II) Expected result:
as the 1st column of characters have the Variation Selector-15 (U+FE0E) applied, and the 2nd column have the Variation Selector-16 (U+FE0F) applied, the first column should always display text characters (in orange) and the second column emoji characters.
III) Error result:
some characters are working fine in the 1st column and displayed as text (in orange colour), but some other aren't displayed as text, they wrongly displayed as emojis instead.
Topic:
Safari & Web
SubTopic:
General
Our iOS app uses React Native Webview (based on top of WKWebView) to display content. This webview stays in memory throughtout the app's lifecycle. We are observing a high number of webview content process terminations - around 15% of our sessions. (https://developer.apple.com/documentation/webkit/wknavigationdelegate/webviewwebcontentprocessdidterminate(_:))
What could be the reasons for it? Is there a way to know for sure?
Is the 15% of sessions number something that other apps also experience, or should this be lower?
Thanks!
Topic:
Safari & Web
SubTopic:
General
"The Referer header allows a server to identify referring pages that people are visiting from or where requested resources are being used. "
This header is never forwarded to server when the user is browsing the website in a WebView. This is properly maintained by other browsers but not in-app.
How do I include it?
Topic:
Safari & Web
SubTopic:
General
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.
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.
Topic:
Safari & Web
SubTopic:
General
How to allocate the width of each column when customizing the rendering of HTML tables on iOS with limited screen width
Topic:
Safari & Web
SubTopic:
General
I recently noticed that putting the app on background for some time, then switching back to it again causes the WKWebView to reload the current page, same with just hitting f5 on it. How do we disable this behavior?
//Is my post method correct because google and claude are telling me I must use content type for the json and use .setvalue. I thought that my process was correct because I encode the data to turn into json and then make the request
func createTask(_ task: Task) async throws -> Task {
if let url = URL(string: "(baseURL)/todos"){
var request = URLRequest(url: url)
request.httpMethod = "POST"
let encoder = JSONEncoder()
do{
let data = try encoder.encode(task)
request.httpBody = data
let (data, response) = try await URLSession.shared.data(for: request)
return task
//we want to make encoder and then turn the data into json and put it in body
}
catch{
throw JSONErrors.encodingFailed
}
}
else{
throw URLError(.badURL)
}
}
When the “Use Strong Password?” dialog appears and I select “Not Now” to manually enter my own password, the password I type is displayed in plain text instead of being masked. Since the input field is of type="password", the entered characters should be hidden as is standard for password inputs.
Is there a way to prevent this behavior and ensure that the password is properly hidden even after dismissing the strong password suggestion dialog?
Topic:
Safari & Web
SubTopic:
General
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?