Hi everyone,
We’ve recently run into an issue with Apple Pay on the web and would appreciate some clarification.
Background:
Previously, we integrated Apple Pay without using the Apple Pay JS SDK.
We relied on ApplePaySession.canMakePayments() to check availability, and it worked fine.
After Apple announced support for browsers beyond Safari, we switched to the Apple Pay JS SDK.
According to Apple’s documentation, we should now use applePayCapabilities() for capability checks in third-party browsers.
Our current behavior:
We implemented applePayCapabilities().
Initially, it was returning either paymentCredentialStatusUnknown or paymentCredentialsUnavailable.
Based on those values, we displayed the Apple Pay button.
The problem:
About a week ago, on the same device/browser, applePayCapabilities() started returning applePayUnsupported.
Setup: MacBook Pro 13-inch (M1, 2020), Google Chrome Version 136.0.7103.93.
The Apple documentation says: “Don’t show an Apple Pay button or offer Apple Pay” when the result is applePayUnsupported.
However, at the same time, canMakePayments() is returning true.
This creates a direct conflict between the two recommendations:
canMakePayments() → true ⇒ show the button.
applePayCapabilities() → applePayUnsupported ⇒ don’t show the button.
Question:
What’s the correct approach here?
Should we prioritize applePayCapabilities() and hide the button, or is it acceptable to continue relying only on canMakePayments() as the source of truth for showing Apple Pay?
Any insights from others who’ve run into this contradiction would be very helpful.
Thanks in advance!
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
Summary:
Content scripts injected via manifest continue to receive and respond to chrome.tabs.sendMessage() calls even after the user has navigated away from the original page, causing messages intended for the current tab to be handled by zombie contexts from previous pages.
Environment:
Safari/iOS Version: 18.5
Extension Manifest: Version 3
Expected Behavior:
When a user navigates from Page A to Page B:
Page A's content script context should be destroyed.
chrome.tabs.sendMessage(currentTabId, message) should only reach Page B's content script
Only Page B should be able to respond to action button clicks (or other background to content messages).
Actual Behavior:
When navigating from Page A to Page B:
Page A's content script context persists as a "zombie".
chrome.tabs.sendMessage(currentTabId, message) reaches zombie context instead of the Page B's one. Hence, it looks like the extension is broken because the content script does not respond to the background messages.
Details:
Tab ids are properly recognized by both background and content script
The problem does not always occur; it occurs on random occasions. It's quite easy to have it reproduced.
It can be reproduced easier if user clicks ext icon during site loading (before it fully loaded), triggering ActionClick (ext icon click) event and then sending a msg upon it to the content script
Regardless of whether the content script is injected into the tab using manifest.json, registerContentScripts, or executeScript, the problem is still there
Once the problem occurs, e.g. user is on macys.com but zombie injected content script believes it's google.com (a previous page), even refreshing the tab doesnt change anything - zombie context is still there (thinking it's still google.com) . Changing a domain to something completely different one could help though. Then going back to macys.com could still lead to the described issue.
A zombie content script does not have access to the page's console function and others.
Example communication
Sending following message from the background to the content script using chrome.tabs.sendMessage()
{
"tab": {
"id": 155,
"active": true,
"url": "https://www.macys.com/",
"title": "Macys.com"
}
}
Results in the content-script zombie context response (the url is taken from the window.location.href)
"message": {
"type": "ActionClicked",
"data": {}
},
"response": {
"data": {
"windowUrl": "https://www.google.com/",
"contentReached": true,
"timestamp": "1,753,138,945,272",
}
}
}
Subject: Apple Pay JS - "Payment Was Cancelled by the User" Issue (Braintree + Server-Side Validation)
Issue
I am implementing Apple Pay using Braintree with server-side validation. However, when initiating the payment process, I receive the following error:
[Log] Payment was cancelled by the user: (apple-pay-test-ucxp.onrender.com, line 286)
Additionally, the console logs an ApplePayCancelEvent with:
sessionError: {code: "unknown", info: {}}
Despite successfully fetching merchant session validation data from the backend and completing merchant validation, the payment process does not proceed.
Setup Details
Payment Processor: Braintree (Apple Pay integration)
Backend API: Fetching merchant session validation via createPaymentSessionGet
Payment Processing: Using Braintree nonce tokenization
Client-Side Code (Key Sections)
session.onvalidatemerchant = async (event) => {
try {
const merchantSession = await fetch(
"https://api.paybito.com:9443/ApplePay/api/apple-pay/createPaymentSessionGet",
{
method: "GET",
headers: { "Content-Type": "application/json" },
}
).then((res) => res.json());
session.completeMerchantValidation(merchantSession);
} catch (err) {
console.error("Merchant validation failed:", err);
session.abort();
}
};
session.onpaymentauthorized = async (event) => {
try {
const payload = await applePayInstance.tokenize({
token: event.payment.token,
});
const response = await fetch(
"https://api.paybito.com:9443/ApplePay/api/braintree/process-payment",
{
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ nonce: payload.nonce }),
}
).then((res) => res.json());
if (response.success) {
session.completePayment(ApplePaySession.STATUS_SUCCESS);
} else {
session.completePayment(ApplePaySession.STATUS_FAILURE);
}
} catch (err) {
console.error("Payment authorization failed:", err);
session.completePayment(ApplePaySession.STATUS_FAILURE);
}
};
Observations
Merchant validation completes successfully.
The error occurs before onpaymentauthorized executes.
Session error code is unknown, making debugging difficult.
Questions
Has anyone encountered this issue before?
Could this be related to how the validation session is fetched from the backend?
Is there a way to obtain more meaningful debug information from Apple Pay?
Any insights would be greatly appreciated!
We're having trouble connecting to local area network websockets in Safari in the latest iOS26 Beta 3 (iPhone 14), both secure and unsecure. Code works < iOS26 & macOS, etc.
--
Unsecure behaviour: need to call connectWebSocket() twice, establishes connection reliably. Calling connectWebSocket() once, will sometimes work, sometimes not.
--
Secure behaviour: Error in debug console, even though the certificate has been accepted and the page is loaded as https. Error:
WebSocket connection to 'wss://192.168.1.81/api/webSocket' failed: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “192.168.1.81”, which could put your confidential information at risk.
--
let apiEndpoint = window.location.hostname;
if (apiEndpoint == null || apiEndpoint == '') {
apiEndpoint = "192.168.1.81";
}
function connectWebSocket() {
if (webSocket && webSocket.readyState == 1) {
return;
}
if (webSocket) {
webSocket.close();
}
webSocket = new WebSocket(
(window.location.protocol === 'https:' ? "wss://" : "ws://") + apiEndpoint + "/api/webSocket",
);
webSocket.onerror = (error) => {
console.log("WebSocket error", error);
};
webSocket.onopen = () => {
console.log("WebSocket connected");
webSocket.send("volume");
webSocket.send("isPlaying");
};
webSocket.onmessage = (event) => {
const msg = event.data;
if (!msg) return;
if (msg.startsWith("volume")) {
const volume = parseInt(msg.replace('volume:',''));
const slider = document.getElementById("volumeSlider");
slider.value = volume;
slider.style.background = `linear-gradient(to right, #007bff ${volume}%, white ${volume}%)`;
} else if (msg.startsWith("isPlaying")) {
const url = msg.replace('isPlaying:', '');
let matchedEntry = null;
let coverToSelect = null;
categories.forEach((category, catIdx) => {
category.entries.forEach((entry, entryIdx) => {
if (entry.url === url) {
matchedEntry = entry;
coverToSelect = document.querySelector(`.cover[category-idx="${catIdx}"][entry-idx="${entryIdx}"]`);
}
});
});
if (matchedEntry && coverToSelect) {
selectCover(coverToSelect, true);
showNowPlayingBar(matchedEntry);
const top = coverToSelect.getBoundingClientRect().top + window.scrollY - 150;
window.scrollTo({ top, behavior: 'smooth' });
}
}
};
webSocket.onclose = () => {
console.log("WebSocket closed, retrying...");
setTimeout(connectWebSocket, 1000);
};
}
document.addEventListener("visibilitychange", () => {
if (document.visibilityState === "visible") {
connectWebSocket();
}
});
connectWebSocket();
I’m observing an intermittent issue with a Safari Web Extension on macOS 15.7 (Safari 26.0.1). After installing the Safari extension from the App Store, it appears under Settings → Extensions, but the enable checkbox is often missing.
Sometimes, after restarting Safari multiple times, the checkbox becomes visible. However, even when I manage to enable the extension, reopening Safari often hides the checkbox again.
However, I don't see this issue in safari 26 with macOS 26
I’d like to know if this behavior is a known issue with Safari 26 or macOS 15.7?
Any workaround available?
I'm a web developer of WebRTC based web app for video and audio calls. After updating to iOS 26.1 beta I noticed, that my app can't use microphone anymore.
When I'm calling to getUserMedia with audio set to true, Safari returns error "No AVAudioSessionCaptureDevice device".
Other WebRTC demo apps also can't access microphone on this firmware.
And maybe it's connected somehow, but safari can't detect connected AirPods Pro 2 as an input device.
So, this bug brakes any WebRTC app, that uses microphones.
Adding Stack Trace for your reference:
thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1a6efe5b8)
frame #0: 0x00000001a6efe5b8 WebCoreWebCore::BaseAudioSharedUnit::BaseAudioSharedUnit() + 668 frame #1: 0x00000001a6efe044 WebCoreWebCore::CoreAudioSharedUnit::singleton() + 80
frame #2: 0x00000001a9521fe4 WebCoreWebCore::CoreAudioCaptureSource::create(WebCore::CaptureDevice const&, WebCore::MediaDeviceHashSalts&&, WebCore::MediaConstraints const*, std::__1::optional<WTF::ObjectIdentifierGeneric<WebCore::PageIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>>) + 360 frame #3: 0x00000001a94f180c WebCoreWebCore::RealtimeMediaSourceCenter::getUserMediaDevices(WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WebCore::MediaConstraintType&) + 356
frame #4: 0x00000001a94f22cc WebCoreWebCore::RealtimeMediaSourceCenter::validateRequestConstraintsAfterEnumeration(WTF::Function<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&, WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&, WTF::Function<void (WebCore::MediaConstraintType)>&&, WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&) + 356 frame #5: 0x00000001a94fb394 WebCoreWTF::Detail::CallableWrapper<WebCore::RealtimeMediaSourceCenter::enumerateDevices(bool, bool, bool, bool, WTF::CompletionHandler<void ()>&&)::$_0, void>::~CallableWrapper() + 164
frame #6: 0x00000001a814bbe8 WebCoreWTF::Detail::CallableWrapper<WebCore::AVCaptureDeviceManager::refreshCaptureDevicesInternal(WTF::CompletionHandler<void ()>&&, WebCore::AVCaptureDeviceManager::ShouldSetUserPreferredCamera)::$_0::operator()()::'lambda'(), void>::call() + 520 frame #7: 0x00000001ab7f1aac JavaScriptCoreWTF::RunLoop::performWork() + 524
frame #8: 0x00000001ab7f1880 JavaScriptCoreWTF::RunLoop::performWork(void*) + 36 frame #9: 0x00000001935e7d0c CoreFoundationCFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28
frame #10: 0x00000001935e7ca0 CoreFoundation__CFRunLoopDoSource0 + 172 frame #11: 0x00000001935e6a24 CoreFoundation__CFRunLoopDoSources0 + 232
frame #12: 0x00000001935e5c64 CoreFoundation__CFRunLoopRun + 840 frame #13: 0x000000019360a730 CoreFoundationCFRunLoopRunSpecific + 572
frame #14: 0x00000001e0fb5190 GraphicsServicesGSEventRunModal + 168 frame #15: 0x0000000196239f34 UIKitCore-[UIApplication _run] + 816
frame #16: 0x0000000196238164 UIKitCore`UIApplicationMain + 336
frame #17: 0x000000010811bec4 AppName.debug.dylibmain at AppDelegate.swift:25:13 frame #18: 0x00000001bae06a58 dyldstart + 5964
We’re currently working on an OTT-based application where we integrate Google Ad Manager to serve video ads. As part of the ad experience, users often see a “Learn More” CTA (Call to Action) on these ads.
As per our current requirement, when a user taps “Learn More” on an ad:
• The link should open in Safari (i.e., an external browser) on iOS devices
• The Safari browser should ideally open in portrait orientation, as the ad content and layout are optimised for portrait mode
However, based on our understanding and technical constraints on iOS, it appears that:
• Orientation control is restricted to the app’s own context.
• Once Safari is launched via UIApplication.shared.open, we no longer have control over how it behaves in terms of orientation.
• iOS system behaviour determines Safari’s orientation based on the device’s physical orientation and Safari’s own internal configuration.
Could you please confirm if there’s any supported way (via SDK, deep link config, or otherwise) to enforce portrait orientation in Safari when opening such external URLs from within an iOS app?
If this is not technically feasible, we would appreciate any best practices or alternatives you can suggest for ensuring a consistent user experience.
Topic:
Safari & Web
SubTopic:
General
I'm testing web extension to safari on iOS. I've built and added extension application to simulator, but on safari settings shows no extensions.
I'm using Xcode 16.3 beta 2 with Simulator iOS 18.4 (22E5216h), tested on iPhone 16.
https://app.screencast.com/oUq4EMonmfT7u
https://app.screencast.com/MCquvHzmZi8QS
We are using WebKit in our app and recently started noticing a crash occurring on iOS 17 and earlier versions. The crash log shows the following error:
Thread 0 Crashed:
0 WebKit 0x00000001a38593cc WebKit::WebPageProxy::updateActivityState(WTF::OptionSet<WebCore::ActivityState>) + 220 (WebPageProxy.cpp:2544)
1 WebKit 0x00000001a39cb1e0 WebKit::WebPageProxy::dispatchActivityStateChange() + 132 (WebPageProxy.cpp:2653)
2 WebKit 0x00000001a3f541f8 WTF::Detail::CallableWrapper<WebKit::WebPageProxy::scheduleActivityStateUpdate()::$_5::operator()() const::'lambda'(), void>::call() + 52 (Function.h:53)
3 JavaScriptCore 0x00000001a48317ec void WTF::dispatchWorkItem<WTF::(anonymous namespace)::DispatchWorkItem>(void*) + 60 (WorkQueueCocoa.cpp:48)
4 libdispatch.dylib 0x00000001964f5dd4 _dispatch_client_callout + 20 (object.m:576)
5 libdispatch.dylib 0x00000001965045a4 _dispatch_main_queue_drain + 988 (queue.c:7898)
6 libdispatch.dylib 0x00000001965041b8 _dispatch_main_queue_callback_4CF + 44 (queue.c:8058)
7 CoreFoundation 0x000000018e623710 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 (CFRunLoop.c:1780)
8 CoreFoundation 0x000000018e620914 __CFRunLoopRun + 1996 (CFRunLoop.c:3149)
9 CoreFoundation 0x000000018e61fcd8 CFRunLoopRunSpecific + 608 (CFRunLoop.c:3420)
10 GraphicsServices 0x00000001d34d01a8 GSEventRunModal + 164 (GSEvent.c:2196)
11 UIKitCore 0x0000000190c5890c -[UIApplication _run] + 888 (UIApplication.m:3713)
12 UIKitCore 0x0000000190d0c9d0 UIApplicationMain + 340 (UIApplication.m:5303)
After investigating, we found that this crash was addressed in this https://github.com/WebKit/WebKit/pull/24778 WebKit PR. However, our app is still crashing for users on older iOS versions where this fix is not available.
Is there a known workaround to prevent this crash on affected iOS versions? Any guidance would be greatly appreciated.
Device: iPhone 15pro, ios26.0 (23A 341)
IOS version: 26.0 (23A 341)
When using position: sticky; bottom: 0, the div is expected to stick to the bottom of the viewport when the browser toolbar hides while scrolling. However, it stops at the height where the toolbar was, instead of moving down with the disappearing toolbar.
In the image below, the red-bordered navigation shows the situation where it does not stick to the bottom.
i
I'm developing a web extension for Safari on iOS using MV3.
The extension is working fine in Chrome, but in Safari I experience some seemingly random issues. I would like to debug it, but here is my problem.
I have my iPhone connected via cable to Mac, and it works fine with XCode, so I assume this part is OK.
I open Safari or Safari Tech Preview (doesn't matter) on my Mac, developers options are enabled, and in the Develop menu, under my iPhone section, there are things I can debug. There is an entry "[Ext name] - Extension Service Worker" but when I click it, it's empty. Web inspector pops up, but there are no network requests, no logs, nothing. I know the extension is working, because I can stream log to my HTTP server, but I don't see them here at all. I can use console to trigger commands like chrome.storage.local.get(null, console.log) and it shows my local store, so why I don't see any logs? Also, the background script is not visible in the Sources tab, just one weird request:
navigator.serviceWorker.register('safari-web-extension://E3449EA7-EC25-4696-8E6C-[ID HERE]/background.js');
</script>
Any ideas what went wrong? The entire team of 4 people has the same issue and we can't move forward because of that.
Also, the Develop => Service workers or any other menu section doesn't show my service worker. Logs for websites running on my phone are visible and in general web inspector for them works fine.
Our app encountered a new crash since beta5(23A5308g) released last week,and it seems the crash is not solved yet in beta6(23A5318c).The crash stack below
`-[UIView _backing_setPosition:]
-[UIView setCenter:]
-[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:]
___54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke
-[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:]
-[_UIEditMenuContentPresentation _displayMenu:reason:]
-[_UIEditMenuContentPresentation displayMenu:configuration:]
___58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke
___80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke
___109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke
___107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke
WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&)
WTF::Detail::CallableWrapper<IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)> >(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::{lambda(IPC::Connection*, IPC::Decoder*)#1}, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*)
WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRefIPC::Encoder&&, WTF::OptionSetIPC::SendOption, std::__1::optionalIPC::ConnectionAsyncReplyHandler, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*)
IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder)
IPC::Connection::dispatchIncomingMessages()
WTF::RunLoop::performWork()
WTF::RunLoop::performWork(void*)
_CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION
___CFRunLoopDoSource0
___CFRunLoopDoSources0
___CFRunLoopRun
__CFRunLoopRunSpecificWithOptions
_GSEventRunModal
-[UIApplication _run]
_UIApplicationMain
main main.m
start
Hi all,
With version 18.4 beta, I have a problem with the display of webviews in the app. In particular, the app of my bank has webviews inside it, and as they are not loading, I am unable to access it. Can you help me? Thank you.
After upgrading to Safari version 18, we encountered an issue with my extension’s background script not being able to access cookies. Previously, in Safari versions 17 and below, the extension worked as expected. Now, when the extension tries to retrieve cookies using browser.cookies.getAll(), it returns an empty list. However, if we open the extension’s developer tools, the cookies are visible and accessible.
It seems that Safari only provides cookie data after the developer tools have been opened. However, after relaunching Safari and launching the extension without opening the developer tools, browser.cookies.getAll() still returns an empty list.
Has anyone else experienced this?
STEPS TO REPRODUCE
Download this minimal app : https://www.icloud.com/iclouddrive/0bajlhnuQaG6T5NsFKXEB0U9Q#test%5Fcookies
Compile test_mv2 extension (in test_cookies.getAll.zip).
Launch test_mv2.app and activate extension.
Click on the extension's button (browserAction).
Open the developer tools.
Observe an empty list of cookies.
Click on the extension's button (browserAction).
Cookies are retrieved as expected.
Dear Apple Developer Experts,
We're experiencing an intermittent issue with WKWebView in our macOS application where local HTML file access is occasionally denied by the sandbox, despite proper implementation and permissions. We seek your guidance in understanding and resolving this issue.
Issue Description:
The WKWebView occasionally fails to load local HTML files stored in the app's Contents/Resources directory
Error occurs in WebKit Networking Process with sandbox denial
Issue is intermittent and can be resolved by app restart or WebKit Networking Process restart
Affects all local HTML files in the same directory once the issue occurs
Technical Details:
Error from Kernel Log:
2025-02-07 14:57:17.179821 +0800 kernel Sandbox: com.apple.WebKit.Networking(58661) deny(1) file-read-data /Applications/DingTalk.app/Contents/Resources/webcontent/contact-2024.html
WKWebView Delegate Error (captured in WKNavigationDelegate method):
(void)webView:(WKWebView *)webView didFailProvisionalNavigation:(WKNavigation *)navigation withError:(NSError *)error
Error Details:
Domain: NSPOSIXErrorDomain
Code: 1
Description: "Operation not permitted"
UserInfo: {
networkTaskMetricsPrivacyStance: Unknown,
_NSURLErrorFailingURLSessionTaskErrorKey: LocalDataTask <3694CA1E-481B-4E06-975D-E3A56AD56C0F>.<1>,
_kCFStreamErrorDomainKey: 1,
_kCFStreamErrorCodeKey: 1
}
Key Observations:
Error is captured in WKNavigationDelegate's didFailProvisionalNavigation method
The issue affects all local HTML files in the same directory once it occurs
Temporary workarounds we've discovered:
Restarting the application completely resolves the issue
Without restarting the application, terminating the "WebKit Networking Process" via Activity Monitor causes the process to automatically restart, and this resolves the issue and load works again
Additional Information:
We've collected complete system diagnostics (system_logs.logarchive) at the time of failure
The issue appears similar to discussions in Apple Developer Forums (https://developer.apple.com/forums/thread/110072), though we're uncertain if it's the same root cause
We've prepared a minimal demo project demonstrating:
Our release version app can be downloaded from: https://dtapp-pub.dingtalk.com/dingtalk-desktop/mac_dmg/Release/M1-Beta/DingTalk_v7.6.45_43521682_universal.dmg?spm=0.0.0.0.UuwovG&file=DingTalk_v7.6.45_43521682_universal.dmg for examining our app's codesign, sandbox, and entitlements configurations if needed
Important Investigation Finding:
We attempted to simulate the issue by using chmod 000 /path/to/test.html, but this produces a different error:
CopyError Domain=NSURLErrorDomain
Code=-1102
Description="You do not have permission to access the requested resource."
UserInfo={
NSLocalizedDescription=You do not have permission to access the requested resource.,
NSErrorFailingURLStringKey=file:///Users/sunus/Library/Developer/Xcode/DerivedData/WKWebViewLocalDemo-eumardnlfbmwgnhkaadglsrrhzhs/Build/Products/Debug/WKWebViewLocalDemo.app/Contents/Resources/test.html,
NSUnderlyingError=0x600003aedc50 {Error Domain=kCFErrorDomainCFNetwork Code=-1102 "(null)"}
}
This error is distinctly different from our original issue's "Operation not permitted" error, suggesting that the sandbox denial we're experiencing is not a simple file permission issue.
Questions:
Is this a known issue with the WebKit sandbox in recent macOS versions?
Are there recommended best practices or workarounds to prevent this sandbox denial?
Could this be related to the WebKit Networking Process's sandbox configuration?
Are there additional diagnostics or logs we should collect to help investigate this issue?
We appreciate your assistance in investigating this issue. Please let us know if you need any additional information or clarification.
STEPS TO REPRODUCE
Open App
Then loads the local file in /WKWebViewLocalDemo.app/Contents/Resources/test.html
PS, We also submit a DTS & Feedback
DTS:Case-ID: 11876957
Feedback-ID: FB16493282
sysdiagnose is in the Feedback-ID: FB16493282 is uploaded
I am creating a Safari Web Extension.
There are two calls let say, call1 and call2 which gets executed in sequence by browser, call1 gives a 302 type response and redirects to call2.
When creating DNR rule for adding "Cookie" in the request header of call1, the same cookie gets added to the request header of call2 as well(Same is the case for other headers/custom headers as-well). Because of this the set-cookie present in response header of call1 is not sent in the request header of call2, and returns 400 response.
The same setting is working fine for other browsers chrome & firefox.
Is this a bug or DNR works differently for safari ?
currently "webRequestBlocking" works in safari for manifest v3, is there any development of it getting removed just like it's removed in chrome in mv3.
Title: Content Overlapping Address Bar After Clicking Links in Safari, tested on iPhone 11 (iOS 18.1.1)
Description:
When browsing in Safari on iPhone (iOS 18.1.1), the one-tab bar (address bar) collapses as expected when scrolling down a page. However, after clicking on a link and loading the next page, the content appears to overlap the collapsed address bar. This results in parts of the content being hidden or obscured by the address bar, which affects the user experience, especially on mobile devices with limited screen space. This issue is reproducible on Next.js applications and can be observed on websites such as rotterdam.nl and halderberge.nl.
Steps to Reproduce:
Enable the One-Tab Bar: Go to Settings > Safari and enable the one-tab bar feature.
Open the website rotterdam.nl or halderberge.nl in Safari on an iPhone 11 (iOS 18.1.1).
Scroll down the page so that the top address bar collapses.
Click on any link on the page to load a new one.
Once the new page loads, observe that the content appears on top of the collapsed address bar, causing parts of the content to be hidden or obscured.
Expected Result:
The content should not overlap or be hidden behind the collapsed address bar after the page reloads. The layout should adjust properly without interference from the address bar, providing a smooth user experience.
Actual Result:
When the new page loads, the content overlaps or appears on top of the collapsed address bar, causing parts of the content to be hidden or obscured.
Device(s) Affected:
iPhone 11 running iOS 18.1.1.
OS Version:
iOS 18.1.1
Technical Notes:
To address this issue, the following solutions have been attempted with no success:
Viewport Meta Tag:
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
This was added to help ensure proper layout on mobile devices, but did not resolve the issue.
CSS Safe Area Insets:
body {
padding-top: env(safe-area-inset-top);
}
This CSS rule was applied to account for the safe area and prevent content from being hidden under the address bar, but it did not solve the overlapping issue.
Scroll Position Adjustment (for scroll-to-top button):
Adjusting the scroll behavior by changing the scroll position to {top: 1} instead of {top: 0} was a successful workaround to keep the address bar collapsed when clicking the "scroll to top" button. However, this did not resolve the issue when navigating between pages or changing routes, where the content still overlaps the collapsed address bar.
The issue of fixed elements with
{ bottom: 0 }
moving up when scrolling still persists.
It seems to be a general issue with the IOS 26 release.
It affects other browser too. I tested on browsers such as Safari, Chrome, Firefox, Edge and Bravo.
With the exception of Edge, all the others display the behavior.
Device: iPhone 15 Pro
IOS Version: 26.0.1
Hi all,
Chrome has it already - animation-timeline aka scroll-animations.
I can nowhere find any informations on what's the status in Safari/Webkit.
Seems like they do not have it on the agenda at all?
Does anyone know anything - I wanted to push a feature request for that - but also seem there is no feature request list anymore for webkit.
See: https://www.w3.org/TR/scroll-animations/
Cheers and kind regards!