I have observed Safari App starts crashing when running with my safari extension.
Our Safari extension polls the host app every 60s. The extension receives and completes requests in
func beginRequest(with context: NSExtensionContext)
(we always call context.completeRequest(...)). The crash is intermittent: beginRequest itself does not throw.
Looking for guidance about likely causes. I am attaching the snippet from crash report.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace RUNNINGBOARD, Code 3490524077
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1856f5c34 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x1857083a0 mach_msg2_internal + 76
2 libsystem_kernel.dylib 0x1856fe764 mach_msg_overwrite + 484
3 libsystem_kernel.dylib 0x1856f5fa8 mach_msg + 24
4 CoreFoundation 0x185822cbc __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x1858215d8 __CFRunLoopRun + 1208
6 CoreFoundation 0x185820a98 CFRunLoopRunSpecific + 572
7 HIToolbox 0x1912c327c RunCurrentEventLoopInMode + 324
8 HIToolbox 0x1912c64e8 ReceiveNextEventCommon + 676
9 HIToolbox 0x191451484 _BlockUntilNextEventMatchingListInModeWithFilter + 76
10 AppKit 0x189745a34 _DPSNextEvent + 684
11 AppKit 0x18a0e4940 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
12 Safari 0x1b801cce4 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 228
13 AppKit 0x189738be4 -[NSApplication run] + 480
14 AppKit 0x18970f2dc NSApplicationMain + 880
15 Safari 0x1b83dd0b0 SafariMain + 468
16 dyld 0x185396b98 start + 6076
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
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
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>
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.
Based on the "Build immersive web experiences with WebXR"-Video for visionOS there is no way to disable the consent prompts for entering an immersive experience or consent hand-tracking. For the microphone it's possible to "greenlight" specific websites for mic input, which works great.
I'd welcome it, if it were possible to add specific websites in the settings, in which those consent dialogs aren't shown each time.
In my opinion, the user interaction through a button that launches the experience would be sufficient to not disorient.
I’m experiencing an issue in WKWebView on iOS 26 Developer Beta 8. If a view's subview contains a WKWebView, using the CALayer's renderInContext method fails to capture the pixel at the current point, and the console outputs "unsupported surface format: &b38".
The following code snippet was functioning as expected on iOS 18 and iOS 26 beta 1. However, it no longer works in the latest beta.
Is this a known bug in the current iOS 26 betas, or is there a recommended workaround?
- (BOOL)isTransparentAtTouchPoint:(CGPoint)point layer:(CALayer *)layer {
unsigned char pixel[4] = {0};
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef context = CGBitmapContextCreate(pixel, 1, 1, 8, 4, colorSpace, (CGBitmapInfo) kCGImageAlphaPremultipliedLast);
CGContextTranslateCTM(context, -point.x, -point.y);
[layer renderInContext:context];
CGContextRelease(context);
CGColorSpaceRelease(colorSpace);
CGFloat alpha = pixel[3] / 255.0f;
return alpha < 0.01;
}
Hi guys, I'm trying to use sign in with apple in javascript, I followed the guider in the website, and almost find everything I can find in Google, but nothing help, here is my situation:
I create a new App: com.yuhan.test.app
I create a new service ID: com.yuhan.test.service
configure a domain and return url
domain: tts.perterpon.com
returnURL: https://tts.perterpon.com/login
create a new key for Sign In with Apple.
my html code is here, it's easy, but it always told me invalid_client, I think I have done anything I need to do, can somebody help me? Thank you so much.
you can test my online web site: https://tts.perterpon.com/login.html
`
const buttonElementNew = document.getElementById('appleid-signin');
buttonElementNew.addEventListener('click', async () => {
try {
const data = await AppleID.auth.signIn()
console.log('Try/Catch Data', data.authorization.id_token);
const formData = new FormData();
formData.append("token", data.authorization.id_token);
await fetch("", {
method: "POST",
body: formData,
});
// Handle successful response.
} catch (error) {
// Handle error.
}
});
</script>
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.
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.
I'm not loving the huge Favorites icons in Safari on MacOS 26, is there a way to reduce the size of them so that we can see more favorites on the list without scrolling down?
Hi Apple Team,
We’ve noticed a couple of issues with launching default App Clip in safari and would appreciate your guidance.
App Clip Popup Timing:
When launching the App Clip using default URL, we sometimes see the small App Clip popup appear before the App Clip banner is displayed. Ideally, the banner should appear first.
Cached URL Handling:
In certain cases, the App Clip appears to be using a cached URL instead of the most recent one. For example, when we invoke two different App Clip URLs with unique parameters, the App Clip sometimes launches using the previous URL’s data instead of the new one.
This behavior is inconsistent and makes it difficult to ensure users are directed to the correct experience each time. Could you please help us understand whether this is expected behavior or if there are any known issues or recommended solutions?
Thank you for your time and support.
Example
I have a Net8 Maui WebView app and whenever I use magnifier, it crashes.
The magnifier works on iOS18 and lower but crashes on iOS26+
Exception
**Type:** CALayerInvalidGeometry
**Value:** CALayer position contains NaN: [nan 65]. Layer: <CALayer:0x123e88e40; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x116f2f200; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x123e88e40>>; sublayers = (<CALayer: 0x125232df0>, <CALayer: 0x123e88e70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0>
Stacktrace
__exceptionPreprocess in unknown file [Line null, column null] (Not in app)
objc_exception_throw in unknown file [Line null, column null] (Not in app)
+[NSException raise:format:] in unknown file [Line null, column null] (Not in app)
CA::Layer::set_position in unknown file [Line null, column null] (Not in app)
-[CALayer setPosition:] in unknown file [Line null, column null] (Not in app)
-[UIView _backing_setPosition:] in unknown file [Line null, column null] (Not in app)
-[UIView setCenter:] in unknown file [Line null, column null] (Not in app)
-[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] in unknown file [Line null, column null] (Not in app)
__54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke in unknown file [Line null, column null] (Not in app)
-[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] in unknown file [Line null, column null] (Not in app)
-[_UIEditMenuContentPresentation _displayMenu:reason:] in unknown file [Line null, column null] (Not in app)
-[_UIEditMenuContentPresentation displayMenu:configuration:] in unknown file [Line null, column null] (Not in app)
__58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke in unknown file [Line null, column null] (Not in app)
__80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)
__109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)
__107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)
Topic:
Safari & Web
SubTopic:
General
The crash is specific to iOS 26.2 prior versions working fine.
WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage)
Name attribute is accessible but WKScriptMessage body attribute causes crash
The object seems to be not accessible(not in memory)
self.webkit.configuration.userContentController.add(self, name: "sampleHandler")
self.webkit.load(request)
func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
print(message.name) // works print(message.body) // crashes
}
I have a very specific issue that happens only on iOS Simulator version 18.4.
It does NOT happen when I run my app on a real iOS 18.4 device through Testflight.
My app displays a WebView (courtesy of Capacitor, url scheme capacitor://).
Inside that Webview I'm using Firebase JS API (11.2.0) and calling signInWithEmailAndPassword, which works well in all other contexts, i.e. browser, Android webview, iOS webview in all other Simulator versions, and on real devices.
Only when running in Simulator 18.4, I get a failed network request:
cannot parse response
Fetch API cannot load https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?... due to access control checks.
Failed to load resource: cannot parse reponse
error: FirebaseError: (auth/network-request-failed)
Everything is working correctly for both:
Capacitor app webview installed on a real 18.4 device with Testflight
Safari (non-webview) in the 18.4 Simulator
The issue is severe for us, because we are unable to develop our app and test it in the simulator on 18.4 Simulator before pushing it through Testflight internal release.
Request headers on the failed request (no response status or headers available).
Request
Accept: /
Content-Type: application/json
Origin: capacitor://localhost
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X) - AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148
X-Client-Version: Mobile/JsCore/11.2.0/FirebaseCore-web
X-Firebase-Client: (...)
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 !
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.
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 ?
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.
Topic:
Safari & Web
SubTopic:
General
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
Topic:
Safari & Web
SubTopic:
General