Hi Apple engineers!
We are making an iOS browser and are planing to deliver a feature that allows enterprise customers to use a MAM key to set a PAC file for proxy. It's designed to support unmanaged device so the MDM based solutions like 'Global HTTP Proxy MDM payload' or 'Per-App VPN' simply don't work.
After doing some research we found that with WKWebView, the only framework allowed on iOS for web browsing, there's no API for programmatically setting proxy. The closes API is the WKURLSchemeHandler, but it's for data management not network request interception, in other word it can not be used to handle HTTP/HTTPS request well.
When we go from the web-view level to the app level, it seems there's no API to let an app set proxy for itself at an app-level, the closest API is Per-App VPN but as mentioned above, Per-App VPN is only available for managed device so we can't use that as well.
Eventually we go to the system level, and try to use Network Extension, but there's still obstacles. It seems Network Extension doesn't directly provide a way to write system proxy. In order to archive that, we may have to use Packet Tunnel Provider in destination IP mode and create a local VPN server to loop back the network traffic and do the proxy stuff in that server. In other word, the custom VPN protocol is 'forward directly without encryption'. This approach looks viable as we see some of the network analysis tools use this approach, but still I'd like to ask is this against App Store Review Guidelines?
If the above approach with Network Extension is not against App Store Review Guidelines, I have a further question that, what is the NEProxySettings of NETunnelNetworkSettings for? Is it the proxy which proxies the VPN traffic (in order to hide source IP from VPN provider) or it is the proxy to use after network traffic goes into the virtual private network?
If none of the above is considered recommended, what is the recommended way to programmatically set proxy on WKWebView on an unmanaged device (regardless of where the proxy runs, web-view/app/system)?
General
RSS for tagExplore 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
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.
I am posting here because we have an urgent issue affecting the operation of our service and are in need of a solution after our own analysis has come up with few answers.
Beginning in iOS 18.2.x, we experienced exactly the same issue as the author of this thread, as we are also operating a service that allows for device certificate login for users configured to require one:
https://developer.apple.com/forums/thread/767374
The author seems to have resolved the issue but the fix mentioned in the thread did not resolve our problem for iOS devices with iOS 18.2.x installed and the contents of that private support ticket are, of course, not visible to us. Furthermore, we have a different issue that surfaced with the release of iOS 18.3.x.
Namely, the issue in iOS 18.3.x is more severe than the one in iOS 18.2.x, in that instead of simply taking a long time for the certificate/identity selection dialog to appear, it simply fails immediately and is returning a “no certificate selected” response to our server.
One thing to note here is that, curiously, if we wait for several seconds (about 10-15 seconds) this behavior is not replicated. So, it seems there is potentially something going in the background, and the certificate selection process will only occur successfully like before if we wait. This is a very unideal workaround.
After entering user credentials, we have the user navigate to a dedicated certificate authentication page. On the BIG IP side, upon users visiting this page, we have it configured to apply an SSL profile that contains appropriate CAs for the given user, and then requests to the browser that a new connection requiring a certificate be made.
We are investigating this by checking logs in in a variety of places:
We can verify in BigIP logs that a response is being returned to the server without a certificate included. For the sake of our application, this is handled as a “user did not select a certificate” event, and thus the attempted login is failed. Using the MacOS “Console” application, we are able to see the following logs from the “trustd” process of the target iOS 18.3.x device:
Failure case:
debug 11:19:49.648581+0900 trustd XPC [com.apple.WebKit[1034]/1#25 LF=0] operation: trust_evaluate (8)
debug 11:19:49.648766+0900 trustd complex trust settings anchor
Successful case (after waiting 10-15 seconds after initial login page load/before moving to certificate page):
debug 11:26:02.803153+0900 trustd XPC [MobileSafari[1031]/1#169 LF=0] operation: trust_evaluate (8)
debug 11:26:02.804219+0900 trustd non ev score: 121 <private>
There appears to be no attempt by MobileSafari to initiate the display of a certificate selection window in the failure cases. The iOS device is swift to return a response with no certificate selected to Big IP, and the result of “no certificate selected” is thus propagated through Big IP and ultimately to our web service.
Does anyone have any advice or information on the following?
Recommended tools to gather more data that may be pertinent.
Any ideas on changes in iOS 18.2.x+ that could have resulted in the behavior changing as described above?
If more information is necessary, I will do my best to supply it. Thank you in advance!
Topic:
Safari & Web
SubTopic:
General
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
Is this code invalid on a phone running xcode16 iOS18?
Class cls = NSClassFromString(@"WKBrowsingContextController");
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
if ([(id)cls respondsToSelector:sel]) {
[(id)cls performSelector:sel withObject:@"http"];
[(id)cls performSelector:sel withObject:@"https"];
}
}
Topic:
Safari & Web
SubTopic:
General
I want to migrate from a Safari App Extension to a Safari Web Extension, but don't know how to get rid of the message, telling users that my extension can access their passwords. Here is a message which I see:
I was thinking that this might be because all Safari Web Extension get this type of access, but I have a Safari Web Extension which does not require such level of access:
Here is the manifest:
{
"manifest_version": 2,
"default_locale": "en",
"name": "__MSG_extension_name__",
"description": "__MSG_extension_description__",
"version": "1.1",
"icons": {
"48": "images/icon-48.png"
},
"background": {
"scripts": [
"background.js"
],
"persistent": true
},
"browser_action": {
"default_popup": "popup.html",
"default_icon": {
"16": "images/toolbar-icon-16.png"
}
},
"permissions": [
"nativeMessaging", "tabs"
]
}
and here is the Info.plist file:
Here is the entire code of the extension:
https://github.com/kopyl/web-extension-simplified
Hey Guys
My PWA video playback and even youtube videos stopped working after updating iOS to 26.0.1.
The video thumnails appear fine and if i try to play the video, it remains stuck.
If i restart the phone, the video plays for a second in the PWA and then stops again and entire app gets stuck.
Request apple team to fix this issue at the earliest. This is hampering all my iOS users who install the PWA on their device homescreen and use it as app.
FYI strangely EVERYTHING WORKS FINE ON iOS SAFARI browser including videos playback If i open it as a web app.
so this seems like a specific PWA issue on latest ios 26.0.1
Topic:
Safari & Web
SubTopic:
General
I'm using the new iOS 26 WebPage/WebView for SwiftUI in a NavigationStack. The initial load works as expected, but when loading items from the back/forward lists, the content jumps beneath the navigation bar:
struct WebPageTestView: View {
var webPage = WebPage()
var body: some View {
NavigationStack {
WebView(webPage)
.toolbar {
Button("Back") {
if let backItem = webPage.backForwardList.backList.last {
webPage.load(backItem)
}
}
Button("Forward") {
if let forwardItem = webPage.backForwardList.forwardList.first {
webPage.load(forwardItem)
}
}
}
}
.task {
webPage.isInspectable = true
webPage.load(URL(string: "https://domchristie.co.uk/"))
}
}
}
I have run this on the iOS 26.0 and 26.1 Simulators and get the same issue.
The demo website does not use any JavaScript.
I was able to replicate this behaviour using a wrapped WKWebView and calling the .ignoresSafeArea(.all) modifier.
Hi,
My app is using JavascriptCore to run the business logic in a javascript environment.
We are randomly seeing crashes when users move the app back to the foreground.
These crashes are reported by Firebase (I am attaching an example). I also tried to find them in Organizer, but the stacktraces don't match and I am not sure if they are pointing to the same error (I attach one just in case).
I was trying to investigate a little bit about this, but I could find any explanation about what pas_reallocation_did_fail would mean.
Here is our implementation:
-(void) enqueueCallback:(JSValue *)callback withArguments:(NSArray *)args exclusive:(BOOL)exclusive {
[self enqueueBlock:^{
@autoreleasepool {
[callback callWithArguments:args];
}
} exclusive:exclusive];
}
Basically, every JS block is enqueued and then run by a dedicated thread specific to our JSContext.
Can I get some help?
Thanks in advance!
Crashlytics.txt
2024-08-30_10-00-01.2572_-0400-f757f8306eda9679ec1b2ff90fbc66c4eb1fbee7.crash
Background
On iOS 18.4 beta, setting a content inset on a WKWebView causes touch events inside the web view to be offset by the content inset amount. In other words, if the web view has a top content inset of 75 points, I must tap 75 points above the intended element for the touch to register correctly. This makes any web content unusable when a content inset is present.
A sample app demonstrating the issue is available here: GitHub - iOS18.4-Webview-Bug.
The issue does not occur in iOS 18.3 or 18.2.
Bug Report
The bug has been reported and fixed at WebKit Bug 289715 and also filed as rdar://147075945.
Question
Will the fix be included in the upcoming iOS 18.4 beta release (Beta 5) or soon thereafter?
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.
I am encountering an issue where we are unable to run or launch Safari Driver in our automation tests using macOS. When attempting to run safaridriver -p 8888 from the terminal, we receive the following error message:
ERROR: safaridriver could not launch because it is not configured correctly or you need to authenticate. Re-run safaridriver(1) and pass the '--enable' flag to configure and/or authenticate.
For more information, consult the safaridriver(1) man page.
Despite running sudo safaridriver --enable as an administrator (even as root), the issue persists.
I’ve searched through various online forums and GitHub repositories but couldn’t find a working solution. Some references are:
Apple Developer Forum Thread: https://forums.developer.apple.com/forums/thread/762321
GitHub Issue: https://github.com/SeleniumHQ/selenium/issues/11381
Hi,
How are we supposed to handle links with target="_blank" in the new SwiftUI WebView? I don't see anything in WebPage.NavigationDeciding or elsewhere that corresponds to the delegate method used for WKWebView.
Hello,
After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project).
Observed behavior
On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return.
This happens not only for:
evaluateJavaScript("navigator.userAgent")
but also for simple or even empty scripts, for example:
evaluateJavaScript("")
On previous macOS versions, the same calls typically returned in ~200 ms.
Additional testing
I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls.
In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2.
Question
Is this a known issue or regression related to:
iOS Apps on Mac,
Swift + WKWebView, or
behavioral changes in evaluateJavaScript on macOS 26.2?
Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated.
Thank you.
Test Code Swift
class ViewController: UIViewController {
private var tmpWebView: WKWebView?
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
setupUserAgent()
}
func setupUserAgent() {
let t1 = CACurrentMediaTime()
tmpWebView = WKWebView(frame: .zero)
tmpWebView?.isInspectable = true
tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in
let t2 = CACurrentMediaTime()
print("[getUserAgent] \(t2 - t1)s")
self?.tmpWebView = nil
}
}
}
Test Code Objective-C
- (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions {
NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970];
WKWebView *webView = [[WKWebView alloc] init];
dispatch_async(dispatch_get_main_queue(), ^{
[webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) {
NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970];
NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime));
}];
});
}
Starting in iOS 26 (tested on 26.1), when I use any of the “policy” methods of WKNavigationDelegate to return an action policy of cancel I get a trace like this printed to console:
1 0x18de71bbc WebKit::WebFramePolicyListenerProxy::ignore(WebKit::WasNavigationIntercepted)
2 0x18db3dd50 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)::$_0::operator()(WKNavigationActionPolicy, WKWebpagePreferences*)
3 0x100189e5c $sSo24WKNavigationActionPolicyVIeyBhy_ABIeghy_TR
4 0x100189d38 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctF
5 0x100189df4 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctFTo
6 0x18db255c0 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)
7 0x18dea9848 WebKit::WebPageProxy::decidePolicyForNavigationAction(WTF::Ref<WebKit::WebProcessProxy, WTF::RawPtrTraits<WebKit::WebProcessProxy>, WTF::DefaultRefDerefTraits<WebKit::WebProcessProxy>>&&, WebKit::WebFrameProxy&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)
8 0x18dea7a34 WebKit::WebPageProxy::decidePolicyForNavigationActionAsync(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)
9 0x18d9cbbf4 void IPC::handleMessageAsync<Messages::WebPageProxy::DecidePolicyForNavigationActionAsync, IPC::Connection, WebKit::WebPageProxy, WebKit::WebPageProxy, void (IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&))
10 0x18d9c7728 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
11 0x18e49a0d8 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&)
12 0x18df1908c WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&)
13 0x18d9dfc28 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
14 0x18e47f72c IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>)
15 0x18e47fac4 IPC::Connection::dispatchIncomingMessages()
16 0x199ad3758 WTF::RunLoop::performWork()
17 0x199ad4eb0 WTF::RunLoop::performWork(void*)
18 0x1804563a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
19 0x1804562ec __CFRunLoopDoSource0
20 0x180455a78 __CFRunLoopDoSources0
21 0x180454c4c __CFRunLoopRun
22 0x18044fcec _CFRunLoopRunSpecificWithOptions
23 0x1926be9bc GSEventRunModal
24 0x18630f0d8 -[UIApplication _run]
25 0x186313300 UIApplicationMain
26 0x18554ac38 block_destroy_helper.15
27 0x10018a70c $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ
28 0x10018a67c $s16WebkitPolicyTrap11AppDelegateC5$mainyyFZ
29 0x10018a818 __debug_main_executable_dylib_entry_point
30 0x1000cd3d0 29 dyld 0x00000001000cd3d0 start_sim + 20
31 0x1002bab98 30 ??? 0x00000001002bab98 0x0 + 4297829272
This doesn’t happen in 18.6. Also, it doesn’t seem to have any negative consequences other than the console spam? But then, the navigation is being cancelled anyway, so maybe it’s trapping and just happens to have the effect of not loading the request?
Anyway, I guess I can’t upload zips. But it’s pretty easy to reproduce. Just assign a WKWebView a navigationDelegate with an implementation like:
func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, decisionHandler: @escaping @MainActor (WKNavigationActionPolicy) -> Void) {
decisionHandler(.cancel)
}
and then have it .load() anything. Have I been doing this wrong and 26 exposes it? Or is this a bug in 26? If the latter, any downstream consequences I should be looking out for?
macOS 15.7.1 (24G231)
Xcode 26.1.1 (17B100)
iOS 26.1 (23B86)
Hello WebKit Team,
I’m writing to ask if iOS provides a native way to intercept AJAX (XMLHttpRequest or fetch) calls inside WKWebView.
On Android, this is handled via:
shouldInterceptRequest(WebView view, WebResourceRequest request)
but iOS currently seems to have no equivalent.
We’ve tried:
WKURLSchemeHandler → works only for custom schemes
URLProtocol with WKProcessPool → unreliable for AJAX in WebView
JavaScript injection → partial and unofficial
Could you please clarify:
Is there a recommended native approach to intercept AJAX requests?
If not supported, is it planned for future releases?
Any official workaround or guidance?
This is critical for debugging, analytics, and compliance in hybrid apps.
Sometimes Safari is rendering the icon for an active extension in its original provided colored representation, other times Safari is applying an overlay color in line with the system's highlight color.
This difference can even be seen seen on the Safari Extensions Developer home page: https://developer.apple.com/safari/extensions/images/extensions-hero-large_2x.png
You will notice that Grammarly's icon is shown in it's original color format, while the others aren't.
Example of extensions where the icon is shown in color:
Bitwarden
Grammarly
1Password
Consent-O-Matic
I've compared the source code of Bitwarden and Consent-o-Matic with my own extension and cannot find any differences in the settings or image properties (resolution, DPI, file type, color profile). If I take the exact PNG source files from said open source extensions and replace them in my own source code, these icons show up in full color.
Does this perhaps mean there is a bug in Safari's processing of the icons where it fails to overlay the icon with the highlight color in some cases?
I and I assume many developers with me would like to understand what determines this difference. Ideally, there is a consistent UX where the end user has the choice between icons in color or highlight color overlay.
The application I'm currently working on uses WebKit. Based on the crash analytics, we have noticed that some of our users are experiencing an unusual behavior in the app's WebKit view with macOS 15.3.2. These errors are reported for this version of the OS. The error in the crash log is a SIGABRT error, but there is no relevant information available to address it. In some crash logs, we found this error: "NSInternalInconsistencyException: Returned WKWebView was not created with the given configuration" but there is not any particular way to address it. Is there a way to identify the cause of this error? Alternatively, has anyone encountered this issue and found a solution?
OS Version: macOS 15.3.2 (24D81)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Crashed Thread: 0
Application Specific Information:
Returned WKWebView was not created with the given configuration.
Thread 0 Crashed:
0 CoreFoundation 0x303111e74 __exceptionPreprocess
1 libobjc.A.dylib 0x3027b6cd4 objc_exception_throw
2 CoreFoundation 0x303111d6c +[NSException raise:format:]
3 WebKit 0x34e85cb20 WebKit::UIDelegate::UIClient::createNewPage
4 WebKit 0x34e8a4a80 WebKit::SOAuthorizationCoordinator::tryAuthorize
5 WebKit 0x34e9f04f8 WebKit::WebPageProxy::createNewPage
6 WebKit 0x34ef994c8 WebKit::WebPageProxy::didReceiveSyncMessage
7 WebKit 0x34f0830cc IPC::MessageReceiverMap::dispatchSyncMessage
8 WebKit 0x34ea753b0 WebKit::WebProcessProxy::didReceiveSyncMessage
9 WebKit 0x34f07cfb4 IPC::Connection::dispatchSyncMessage
10 WebKit 0x34f07d3b0 IPC::Connection::dispatchMessage
11 WebKit 0x34f078c50 IPC::Connection::SyncMessageState::ConnectionAndIncomingMessage::dispatch
12 WebKit 0x34f07f4f4 ***::Detail::CallableWrapper<T>::call
13 JavaScriptCore 0x33f3520c0 ***::RunLoop::performWork
14 JavaScriptCore 0x33f352fe8 ***::RunLoop::performWork
15 CoreFoundation 0x30309f8a0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
16 CoreFoundation 0x30309f834 __CFRunLoopDoSource0
17 CoreFoundation 0x30309f598 __CFRunLoopDoSources0
18 CoreFoundation 0x30309e134 __CFRunLoopRun
19 CoreFoundation 0x30309d730 CFRunLoopRunSpecific
20 HIToolbox 0x319aeb52c RunCurrentEventLoopInMode
21 HIToolbox 0x319af1344 ReceiveNextEventCommon
22 HIToolbox 0x319af1504 _BlockUntilNextEventMatchingListInModeWithFilter
23 AppKit 0x30a7cd844 _DPSNextEvent
24 AppKit 0x30b133c20 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
25 AppKit 0x30a7c0870 -[NSApplication run]
26 AppKit 0x30a797064 NSApplicationMain
27 <unknown> 0x182780274 <redacted>
Thread 0 name: t-main-ui Crashed:
0 CoreFoundation 0x303111e74 __exceptionPreprocess
1 libobjc.A.dylib 0x3027b6cd4 objc_exception_throw
2 CoreFoundation 0x303111d6c +[NSException raise:format:]
3 WebKit 0x34e85cb20 WebKit::UIDelegate::UIClient::createNewPage
4 WebKit 0x34e8a4a80 WebKit::SOAuthorizationCoordinator::tryAuthorize
5 WebKit 0x34e9f04f8 WebKit::WebPageProxy::createNewPage
6 WebKit 0x34ef994c8 WebKit::WebPageProxy::didReceiveSyncMessage
7 WebKit 0x34f0830cc IPC::MessageReceiverMap::dispatchSyncMessage
8 WebKit 0x34ea753b0 WebKit::WebProcessProxy::didReceiveSyncMessage
9 WebKit 0x34f07cfb4 IPC::Connection::dispatchSyncMessage
10 WebKit 0x34f07d3b0 IPC::Connection::dispatchMessage
11 WebKit 0x34f078c50 IPC::Connection::SyncMessageState::ConnectionAndIncomingMessage::dispatch
12 WebKit 0x34f07f4f4 ***::Detail::CallableWrapper<T>::call
On iOS 26 Beta, WKWebView consistently crashes when interacting with pages that use -webkit-user-select: none.
This issue does not reproduce in Safari, but only when the same content is loaded inside a WKWebView.
Steps to Reproduce:
Install iOS 26 Beta.
Open a WKWebView that loads a webpage with the following style applied globally:
-webkit-user-select: none;
Perform the following gesture sequence inside the WKWebView:
Double tap anywhere in the web content.
On the second tap, keep your finger pressed (do not lift).
While still holding the second tap, drag your finger across the screen (pan).
This sequence reliably produces the crash.
Expected Result:
No crash. The gesture should either be ignored or handled gracefully.
Actual Result:
The app crashes 100% of the time with the following exception:
#0 0x000000013f1a0874 in __pthread_kill ()
#1 0x00000001357522ec in pthread_kill ()
#2 0x00000001801ad950 in abort ()
#3 0x00000001802fa26c in __abort_message ()
#4 0x00000001802ea1a4 in demangling_terminate_handler ()
#5 0x0000000180077218 in _objc_terminate ()
#6 0x00000001802f9758 in std::__terminate ()
#7 0x00000001802fc7c0 in __cxxabiv1::failed_throw ()
#8 0x00000001802fc7a0 in __cxa_throw ()
#9 0x000000018009c1bc in objc_exception_throw ()
#10 0x00000001804f38f8 in +[NSException raise:format:] ()
#11 0x000000018c5fb570 in -[CALayer setPosition:] ()
#12 0x0000000185d02414 in -[UIView _backing_setPosition:] ()
#13 0x00000001867ec978 in -[UIView setCenter:] ()
#14 0x0000000186666468 in -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ()
#15 0x0000000186666088 in __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke ()
#16 0x00000001867b3ed4 in -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] ()
#17 0x0000000186665fb0 in -[_UIEditMenuContentPresentation _displayMenu:reason:] ()
#18 0x0000000186665de4 in -[_UIEditMenuContentPresentation displayMenu:configuration:] ()
#19 0x00000001867b3260 in __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ()
#20 0x00000001867b4c98 in __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ()
#21 0x000000018653ff80 in __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ()
#22 0x0000000186540448 in __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke ()
#23 0x000000018dba84f8 in WTF::Detail::CallableWrapper<WTF::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call ()
#24 0x000000018dca14cc in WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call ()
#25 0x000000018e2d5c54 in IPC::Connection::dispatchMessage ()
#26 0x000000018e2d6118 in IPC::Connection::dispatchIncomingMessages ()
#27 0x00000001997f9c58 in WTF::RunLoop::performWork ()
#28 0x00000001997fa930 in WTF::RunLoop::performWork ()
#29 0x000000018044d4dc in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#30 0x000000018044d424 in __CFRunLoopDoSource0 ()
#31 0x000000018044cc0c in __CFRunLoopDoSources0 ()
#32 0x000000018044bd84 in __CFRunLoopRun ()
#33 0x0000000180446e24 in _CFRunLoopRunSpecificWithOptions ()
#34 0x00000001924c19bc in GSEventRunModal ()
#35 0x00000001862217a8 in -[UIApplication _run] ()
#36 0x00000001862259d0 in UIApplicationMain ()
Same issues below.
https://developer.apple.com/forums/thread/796799
https://developer.apple.com/forums/thread/796501
https://developer.apple.com/forums/thread/796874
https://developer.apple.com/forums/thread/796686
Typically, you can use the @@extension_id special string to reference the absolute path into the bundled resources of an extension, such as an image or a custom font, in a CSS file.
However, this broke with Safari 18.
Consider this section in a popup.css file:
.card-icon {
height: 16px;
width: 20px;
background-image: url(safari-web-extension://__MSG_@@extension_id__/images/card.svg);
background-size: 20px 16px;
}
In Safari 17.4, once loaded in the browser, @@extension_id is replaced with E8BEA491-9B80-45DB-8B20-3E586473BD47, and the background-image reads as so:
background-image: url(safari-web-extension://E8BEA491-9B80-45DB-8B20-3E586473BD47/images/card.svg);
But as of Safari 18, the @@extension_id just collapses to an empty string, and the background-image reads as so:
background-image: url(safari-web-extension:///images/card.svg);
and the svg fails to load with the following error: "Failed to load resource: You do not have permission to access the requested resource."
This is a regression, does to match the behavior of the other major browsers, and should be fixed.
Filed with Feedback ID: FB15104807