Safari Version 14.0.1 (16610.2.11.51.8)
I am porting a Chrome/Firefox/Edge extension to Safari Web Extension. Mostly, the process was painless, I am, however, seeing quite different behavior in the tab ids generated by Safari compared to Chrome, Firefox, and Edge. My extension has callbacks for each of these browser.webNavigation events:
browser.webNavigation.onBeforeNavigate
browser.webNavigation.onCommitted
browser.webNavigation.onDOMContentLoaded
In each of these I rely on the tab id for various future tab targeting operations. When opening a new tab, the details object passed to each of these callbacks has a non-zero tabId on Chrome, Firefox, and Edge. However, in Safari, the tabId is always zero. To debug, I added one more callback:
browser.webNavigation.onCompleted
At this point Safari finally has a non-zero tabId in the details param. Needless to say this is causing some consternation with achieving the same outcomes as tab tracking on Chrome, Firefox, and Edge. It's like Safari is treating new tabs as "non tabs" until navigation completes. You can even see it when trying to get the tab by tabId=0:
browser.tabs.get(tabId) // tabId=0 here
	.then(tab => {
		// tab is undefined
	});
Seems like this might be a bug. I can't imagine why the behavior is so different from other browsers. Any ideas on how to work around?
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
System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
1. System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
2. System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
After updating Xcode to the latest version we observed that SFSafariViewController is not loading web pages on Xcode 16 Simulator with iOS 18, whenever it is presented the View Controller is empty (does not load any content) and the app freezes, but other screens that use WKWebView are working normally.
Also, during tests on physical devices with iOS 18 it seems to work just fine, so it might be just a IDE version problem.
Is anyone experiencing the same issue?
If so, did anyone find a solution for it?
As with the adoption of MV3 standards among all major browser vendors that allow browser extensions at the client-side, I understand that this is the same with Safari as well, as mentioned here (https://www.wwdcnotes.com/notes/wwdc22/10099/). However, as with Firefox, browsers may choose to adopt them incompletely and with few changes. I had a few questions regarding how Safari views this transition and what would be the next steps from here.
Thus, it would be really great if the browser team could provide your insights on any or all of the following points:
Would Safari adopt the exact standards proposed by the Chromium ecosystem such as with functionalities like header-based modifications in the coming days.
What would be the general timeline be for this in general?
Does this also translate to the fact that existing standards with MV2 standards would not be allowed to operate any further, as with the timeline with Chromium?
Regards
Hello,
I am facing a strange issue on iOS 18. After upgrading to iOS 18, I noticed the following problem:
When connected to mobile data (with Wi-Fi turned off) and trying to upload a file larger than 1MB, the connection times out. However, if I repeat the same action using Wi-Fi, everything works fine.
I have tested this issue in various ways, but nothing seems to resolve it. It appears that iOS 18 might have introduced a bug.
You can replicate the issue using this site: https://video.online-convert.com/convert-to-mp4 (Note: this is not my page, but I found the same issue here).
From the server access logs, I see successful pre-flight requests, but the main POST request never follows, which suggests that the client is not sending the request.
On iPads after updating to iPadOS 16.4, Safari often "looses" the session cookie provided by PlayFramework: When the browser requests assets (js scripts) or when additional data is fetched by JavaScript, the session cookie is not included in the request.
These secondary requests will redirect through our IAM because no session cookie is present. The IAM redirects back to the original domain with a payload so that the login session can be resumed. A new Set-Cookie header is sent in the response with the new session cookie.
This causes the framework to issue a new CSRF token (that is part of the session cookie) which is different from the old one that was already rendered into a hidden form input. The browser stores this new token and includes it when it POSTs the form. The token in the body of the request is now different from the one in the cookies, causing the CSRF check to fail.
We have tried different devices (Android, Windows, MacBook, and iPads) on different versions. The problem only occurs with Safari on iPad/MacBook running version 16.4, 16.4.1, or 16.5 beta. The problem cannot be reproduced using Chrome on iPad. Furthermore, the problem does not occur with private browsing in Safari.
Some things we ruled out:
Same behaviour on devices managed by MDM and on open devices.
PlayFramework version is now updated to the latest 2.8 version.
Using a separate cookie for the CSRF token (instead of the play session cookie) does not make a difference either.
Modifying the Cache-Control header to cache responses more aggressively or not at all does not help.
Has anyone also experienced this or similar problems?
Environment
• Device: iOS 26 Developer Beta 5 (23A5308g)
• Xcode: 16.3
Short description
The app crashes the moment the user tries to long-press to select text inside a WKWebView, double-tap an image with Text (magnifier appears)
The exception is CALayer position contains NaN. frame = (nan,0;0,48) chorPoint=(inf, 0) and it is thrown in the UI process.
Build & run any project that hosts a WKWebView. Inject the following CSS via script (this is what we do to suppress the native callout menu):
WKWebView *webView = [[WKWebView alloc] initWithFrame:self.view.bounds
configuration:[WKWebViewConfiguration new]];
NSString *js =
@"document.documentElement.style.webkitUserSelect='none';"
"document.documentElement.style.webkitTouchCallout='none';";
[webView evaluateJavaScript:js completionHandler:nil];
[self.view addSubview:webView];
Incident Identifier: EE6FB046-5087-4F15-A72D-A74965347A30
CrashReporter Key: 29e8e58e02a07557adb4ce3f463d764f3ce8bbd5
Hardware Model: iPhone16,1
Process: wallet [642]
Path: /private/var/containers/Bundle/Application/4B4E609A-C8BF-4C56-AB2A-1638249B98A5/wallet.app/wallet
Identifier: xxxx
Version: xxxx
AppStoreTools: 16F7
AppVariant: 1:iPhone16,1:18
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: xxxxx
Date/Time: 2025-08-06 12:05:24.0732 +0800
Launch Time: 2025-08-06 11:49:40.3802 +0800
OS Version: iPhone OS 26.0 (23A5308g)
Release Type: Beta
Baseband Version: 3.02.02
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: SIGNAL 6 Abort trap: 6
Terminating Process: wallet [642]
Triggered by Thread: 0
Application Specific Information:
abort() called
Last Exception Backtrace:
0 CoreFoundation 0x185e058c8 __exceptionPreprocess + 164
1 libobjc.A.dylib 0x182d797c4 objc_exception_throw + 88
2 CoreFoundation 0x185e908d4 -[NSException initWithCoder:] + 0
3 QuartzCore 0x18678a874 CA::Layer::set_position(CA::Vec2<double> const&, bool) + 160
4 QuartzCore 0x1869a7270 -[CALayer setPosition:] + 52
5 UIKitCore 0x18c4ac564 -[UIView _backing_setPosition:] + 176
6 UIKitCore 0x18cefdf0c -[UIView setCenter:] + 220
7 UIKitCore 0x18cd9f794 -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] + 936
8 UIKitCore 0x18cd9f3c0 __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke + 104
9 UIKitCore 0x18ced1060 -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] + 384
10 UIKitCore 0x18cd9f2e4 -[_UIEditMenuContentPresentation _displayMenu:reason:] + 304
11 UIKitCore 0x18cd9f0d8 -[_UIEditMenuContentPresentation displayMenu:configuration:] + 64
12 UIKitCore 0x18ced0344 __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke + 260
13 UIKitCore 0x18ced1f8c __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke + 80
14 UIKitCore 0x18cc8403c __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke + 180
15 UIKitCore 0x18cc84584 __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke + 148
16 WebKit 0x1a05ae5d4 ***::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) + 64
17 WebKit 0x1a05bb468 ***::Detail::CallableWrapper<***::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, ***::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(***::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, ***::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) + 196
18 WebKit 0x19fcf5db8 ***::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(***::UniqueRef<IPC::Encoder>&&, ***::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) + 64
19 WebKit 0x19fce54f0 IPC::Connection::dispatchMessage(***::UniqueRef<IPC::Decoder>) + 340
20 WebKit 0x19fcf5aa0 IPC::Connection::dispatchIncomingMessages() + 536
21 JavaScriptCore 0x19a8f85d4 ***::RunLoop::performWork() + 552
22 JavaScriptCore 0x19a8f838c ***::RunLoop::performWork(void*) + 36
23 CoreFoundation 0x185da6230 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
24 CoreFoundation 0x185da61a4 __CFRunLoopDoSource0 + 172
25 CoreFoundation 0x185d83c6c __CFRunLoopDoSources0 + 232
26 CoreFoundation 0x185d598b0 __CFRunLoopRun + 820
27 CoreFoundation 0x185d58c44 _CFRunLoopRunSpecificWithOptions + 532
28 GraphicsServices 0x224ce0498 GSEventRunModal + 120
29 UIKitCore 0x18b6c84b8 -[UIApplication _run] + 792
30 UIKitCore 0x18b66cbc0 UIApplicationMain + 336
31 wallet 0x1046f8558 0x1046f4000 + 17752
32 dyld 0x182dcdb18 start + 6332
I'm working on a web browser App that's distributed via the App Store. This app renders web pages using WKWebView.
Our users are requesting a way for us to allow them to play videos in Picture in Picture. After some investigation, we noticed that in order to allow PiP videos in our browser in the sandboxed environment, we need to add the com.apple.PIPAgent entitlement under the com.apple.security.temporary-exception.mach-lookup.global-name option.
We tried to submit our app with this entitlement, but unfortunately, we were rejected:
Guideline 2.4.50) - Performance
We've determined that one or more temporary entitlement exceptions requested for this app are not appropriate and will not be granted:
com.apple.security.temporary-exception.mach-lookup.global-name
com.apple.P|PAgent
We would like to have access to this entitlement so we can offer PiP to our users.
We already created a radar about this as well: FB13814428
Additionally, we have another radar (FB13557716) regarding allowing the usage of a private flag _allowsPictureInPictureMediaPlayback, which would also be required to enable us to use PiP.
Is there any way in which we can currently enable PiP? Would opening a TSI help here?
I've been having this problem ever since updating my Mac (2024 M3 Macbook Air) to Sequoia where splitscreen basically doesn't work. By "splitscreen," I'm referring to when I hover over the green button in the top left of my browser, go to "full screen", and choose two browsers to see simultaneously. What's happening is that the screens will split, then whichever browser's green button I used will have the tabs stuck in full screen formation. Say I have 5 tabs open on a Chrome browser and I split the screen with finder using the green button on the Chrome browser. The 2 right-most tabs on Chrome will be cut off into oblivion, and only the first 3 will be visible, but if I try to click them, they don't go to the right place. Clicking in the general location of where the 5 tabs SHOULD be in the minimized screen does yield the change of tab, but I can't actually SEE the tabs in their minimized form. I've attached a screenshot because I know it's probably hard to understand what I'm saying. This also doesn't occur 100% of the time, only like 95% of the time. Lol.
Topic:
Safari & Web
SubTopic:
General
Since probably the late iOS 17.4.x, 17.5.1 and still now in 17.6 beta our extension has been experiencing issues with the accompanying background script or service worker being permanently killed with no warning after about 30-45 seconds after initial installation (installation, not page load!).
In all other browsers (including Safari on MacOS) unloading the service worker is part of the normal lifecycle to save memory and CPU if it is idle. In our extension the service worker is used only during the first 5-10 seconds of every page visit, so we are used to seeing it unload after that and consider this a good thing. However, normally, the service worker is able to wake back up when needed - which is no longer the case in iOS.
Once dead, nothing a normal user would do can wake the service worker back up:
No events like webNavigation or similar will trigger anymore
Any attempt to call sendMessage to it from a content-script also does not wake up the service worker and instead returns undefined to the content script immediately
Closing and opening Safari does not start it again
The only two things that will give the service worker another 30-40 seconds of life is a reboot of the device or disabling and then re-enabling the extension. During those few second the extension is working perfectly.
There are no errors or indications in the logs of what is going on and the extension works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail.
It seems like a temporary workaround is to change the manifest to not load the service worker as a service worker by changing
"background": {
"service_worker": "service.js"
}
to
"background": {
"scripts": ["service.js"],
"persistent": false
}
With this change (courtesy of https://forums.developer.apple.com/forums/thread/721222) the service worker is still unloaded but correctly starts up again when needed. Having to make this change does not seem to be consistent with manifest v3 specs though (see this part in Chrome’s migration guide as an example: https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field).
According to the release notes of 17.6 beta this bug was supposedly fixed:
“Fixed an issue where Safari Web Extension background pages would stop responding after about 30 seconds. (127681420)”
However, this bug is not fixed - or at least not entirely fixed. It seems to work better for super simple tests doing nothing but pinging the service worker from the content script, but for the full blown extension there is no difference at all between 17.5.1 and 17.6.
Has there been a change in policy about service workers and background scripts for Safari in iOS?
Are anyone else seeing this issue?
Also seemingly related:
https://forums.developer.apple.com/forums/thread/756309
https://forums.developer.apple.com/forums/thread/750330
https://developer.apple.com/forums/thread/757926
https://forums.developer.apple.com/forums/thread/735307
I wrote a code like the example below to execute javascript code that has no return value.
let webView: WKWebView
// after load complete
let result = await webView.evaluateJavascript("someFunction()") // :0: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value
but when i use method with completion handler manner, it doesn't be crashed. but Xcode enforces me to use 'await' keyword and warning is bordering me
await webView.evaluateJavaScript("someFunction()", completionHandler: nil) // warning: Consider using asynchronous alternative function
The differnce I found is the different signature. Completion handler version has Optional result type, but async/await version has just Any result type
func evaluateJavaScript(_ javaScriptString: String,
completionHandler: ((Any?, Error?) -> Void)? = nil)
func evaluateJavaScript(_ javaScriptString: String) async throws -> Any
my Xcode version is 13.2.1. Hope to fix it soon.
When WKWebView loads a site that has username and password on different pages, standard "Passwords" button above keyboard does nothing. Reproducible on both physical device and simulator. At the same time, Safari works fine in this case.
Any chance to fix this behavior in the upcoming iOS updates?
Here's video demonstrating the issue:
and a sample code to reproduce it (nothing specific, just bare WKWebView with default configuration):
class ViewController: UIViewController {
private let webView = WKWebView(frame: .zero)
override func viewDidLoad() {
super.viewDidLoad()
view.addSubview(webView)
}
override func viewDidLayoutSubviews() {
super.viewDidLayoutSubviews()
webView.frame = view.bounds
}
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
webView.load(URLRequest(
url: URL(string: "https://accounts.google.com/")!
))
}
}
Everything was working fine for 4 years.
But since Ventura, when the WKWebView is in focus, the keyDown event are not happening. Not only they don't fire inside of web page input box, but they won't register in the app either.
As long as a WKWebView is in focus, the keyboard events won't work.
The app does not receive the key events, and the web page will not receive the js events keyDown and friends. This is particularly painful with auto complete input box.
Test with an empty project with only a WKWebView with this page
https://www.toptal.com/developers/keycode/for/d
It does work fine on iPhone and iPad.
Message to Apple : You force us to use your Safari engine, yet it is always broken. Don't wait for 8 months to fix it this time, we would be tempted to go full web and skip native app with all the store certification problems.
Hello everyone,
I am currently facing an issue with a Cordova-based app using WKWebView. In our app, we handle page navigation within the WebView. We’ve implemented a back button at the top of the page, which successfully triggers history.goBack() when clicked. However, we also want to support the native left edge pan gesture (swipe back) to trigger history.back().
The issue is that, while the swipe back gesture works most of the time, there are cases where instead of navigating to the immediate previous page, it behaves as if it’s going back to the first page (or initial page). This only occurs on iOS versions 17.5.1 and above. I’ve already set allowsBackForwardNavigationGestures to true, and the back button itself works perfectly.
Has anyone experienced a similar issue, where the swipe back gesture sometimes skips pages and seems to return to the first page on iOS 17.5.1 or later? Any suggestions on how to fix or troubleshoot this would be greatly appreciated.
Thank you!
Title: SafariViewService Recurring "Hard Refresh" Issue on iOS 18.0.1
Hello,
Many of my app users are experiencing a recurring "hard refresh" issue related to SafariViewService, which appears only on iOS 18.0.1 across various iPhone models. Users on earlier iOS versions are not encountering this problem.
Our app relies on SafariViewService, and the logs show an event triggered by an EXC_GUARD exception with a termination reason from LIBXPC, causing the app to stop. Below are key details from the log report:
App Version: 4.1.2 (build 4.1.1.0)
OS Version: iPhone OS 18.0.1
Exception Type: EXC_GUARD
Subtype: GUARD_TYPE_USER
Termination Reason: LIBXPC, XPC_EXIT_REASON_FAULT
Device Model: iPhone 11 Pro Max
Process Path: [Removed]
Here’s an excerpt from the logs:
...
{"codes":"0x6000000000000007, 0x0000000000000009","reason":9,"message":"namespc 7 reason_code 0x0000000000000009","subtype":"GUARD_TYPE_USER","type":"EXC_GUARD","rawCodes":[Removed],"namespc":7},
"termination" : {"flags":518,"code":9,"namespace":"LIBXPC","indicator":"XPC_EXIT_REASON_FAULT"},
...
I would greatly appreciate any guidance on resolving this issue, particularly if there are known concerns with inter-process communication (LIBXPC) in iOS 18.0.1 or advice on how to manage the EXC_GUARD exception more effectively.
Full log details are in the attachment.
Thank you for your help!
ExcUserFault_SafariViewService-2024-10-10-102717 (1).ips
ExcUserFault_OnixWorker.Maui-2024-10-10-102718 (1).ips
Thank you for your help!
I'm experiencing a Safari Web Extension issue where the non-persistant background script seems to crash after 30 seconds even when the content script is messaging it.
Here is a minimal-reproducible example. When running in an emulator, the background script will stay responsive forever. However, when running on a physical device, the background script becomes non-responsive after 30 seconds of activity. It never becomes responsive again until I toggle the extensions enable/disable toggle, after which it stays active for 30 seconds and then crashes again.
Safari cannot open the page due to the error 'WebKit encountered an internal error.' We are using https://github.com/stleamist/BetterSafariView.git, and it was working fine before we updated to Xcode 16.
Hi everyone,
I’m encountering a serious reliability issue with message passing in my Safari extension on iOS 18.4.1 and iOS 18.5
In my extension, I use the standard messaging API where the background script sends a message to the content scrip. The content script is listening using:
browser.runtime.onMessage.addListener(handler);
This setup has been working reliably in previous versions of iOS, but since updating to iOS 18.4.1 and iOS 18.5, I’ve noticed that messages sent from the background script are not consistently received by the content script. From my logs, I can confirm that:
The background script is sending the message.
The content script’s listener is not always triggered.
There are no errors or exceptions logged in either script.
It seems as if browser.runtime.onMessage.addListener is either not getting registered in time or failing silently in some instances.
This issue is intermittent and does not occur all the time.
Has anyone else experienced similar issues in iOS 18.4.1 and 18.5? Are there any known changes or workarounds for ensuring reliable communication between background and content scripts in this version?
Any help or insights would be greatly appreciated.
Thanks!
Recently we started noticing in Safari v18.2 browser an unexpected useragent set for https://www.espn.com pages like -
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" (recognized as Chrome by most UA detection logic) and breaks our video playback in some scenarios.
When digging into this we came across site specific quirks and the "Disable site-specific hacks" setting which fixed the playback functionality and set a more expected UA - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.2 Safari/605.1.15".
Is the unexpected UA being set somewhere in Safari/Webkit? Can this be removed so site functionality works without needing to find the "Disable site-specific hacks" setting?